From pierre.peloso@alcatel-lucent.com Fri Oct 1 12:50:28 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70ED13A6E0E for ; Fri, 1 Oct 2010 12:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY0gyNHhy7z4 for ; Fri, 1 Oct 2010 12:50:27 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 2231B3A6E0F for ; Fri, 1 Oct 2010 12:50:26 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o91JpEh6005743 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 1 Oct 2010 21:51:14 +0200 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 1 Oct 2010 21:51:14 +0200 From: "PELOSO, PIERRE (PIERRE)" To: "'CCAMP'" Date: Fri, 1 Oct 2010 21:51:14 +0200 Thread-Topic: [CCAMP] Poll to adopt draft-bernstein-ccamp-wson-signaling-07.txt as CCAMP WG document Thread-Index: ActWlWYufBQVOiB8TSeEwa9ClCjUTwCETKNwAj7OMkA= Message-ID: References: <000c01cb58a7$abd38560$037a9020$@co.uk> In-Reply-To: <000c01cb58a7$abd38560$037a9020$@co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [CCAMP] Poll to adopt draft-bernstein-ccamp-wson-signaling-07.txt as CCAMP WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Oct 2010 19:50:28 -0000 =20 Yes/support I would also express comments in line with Dan ones, concerning the bidirec= tional issues. Regards, - Pierre -----Message d'origine----- De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de D= aniel King Envoy=E9 : lundi 20 septembre 2010 11:39 =C0 : 'CCAMP' Objet : Re: [CCAMP] Poll to adopt draft-bernstein-ccamp-wson-signaling-07.t= xt as CCAMP WG document Yes/Support.=20 =09 I think the document is a good platform to build on. There are issues that = need to be resolved, including the optimization of bi-directional allocatio= ns. A bidirectional lightpath using different wavelengths also needs to be = addressed.=20 Thanks, Dan. -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A (ATTLABS) Sent: Friday, September 17, 2010 7:23 PM To: CCAMP Subject: [CCAMP] Poll to adopt draft-bernstein-ccamp-wson-signaling-07.txt as CCAMP WG document All, This starts a two week poll on adopting draft-bernstein-ccamp-wson-signaling-07.txt as a CCAMP WG document. Please indicate your support or otherwise by responding to this message (ye= s/support or no/do not support). Please send your responses by Oct. 1. Deborah and 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 david.black@emc.com Fri Oct 1 17:02:59 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6B03A6DBD; Fri, 1 Oct 2010 17:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.423 X-Spam-Level: X-Spam-Status: No, score=-106.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xAou3wDRCFz; Fri, 1 Oct 2010 17:02:57 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 1E3323A6D7C; Fri, 1 Oct 2010 17:02:56 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9203ZI4021785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2010 20:03:35 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Fri, 1 Oct 2010 20:03:29 -0400 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o92036ox022682; Fri, 1 Oct 2010 20:03:07 -0400 Received: from mxhub02.corp.emc.com ([10.254.141.104]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Oct 2010 20:03:06 -0400 Received: from mx14a.corp.emc.com ([169.254.1.11]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Fri, 1 Oct 2010 20:03:06 -0400 From: To: , , , , Date: Fri, 1 Oct 2010 20:03:04 -0400 Thread-Topic: Gen-ART review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt Thread-Index: ActFQEwoDqeODIKORP6xaxUmwryiTgcgw0Cw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1BD03FE@MX14A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2010 00:03:06.0475 (UTC) FILETIME=[30C353B0:01CB61C5] X-EMM-MHVC: 1 Cc: david.black@emc.com, adrian.farrel@huawei.com, ccamp@ietf.org, dbrungard@att.com Subject: [CCAMP] Gen-ART review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 02 Oct 2010 00:02:59 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Summary: This draft is basically ready for publication, but has nits that should be = fixed before publication. After the -06 version was posted, IESG discussion resulted in a couple of R= FC Editor notes that address the open issues from the Gen-ART review of -05= . The following 3 IANA-related nits still need attention: - In Section 4.1, remove the note to IANA after 2) and instead insert this = instruction into Section 7. - In Figure 4, the type is TBA. Add an instruction to Section 7 for IANA t= o fill this in after it is allocated. =20 - In the fourth bullet in Section 7, please state that the registry is crea= ted by the MLN-EXT draft if that is the case. It looks like IANA has figured out at least the third of these, but follow-= up w/IANA is already needed because one of the RFC Editor Notes removes an = IANA Action. That follow-up should be used to confirm that the planned IAN= A Actions match what was intended. The entire Gen-ART review of the -05 version is below. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Thursday, August 26, 2010 1:01 PM > To: 'gen-art@ietf.org'; donald.fedyk@alcatel-lucent.com; hshah@force10net= works.com; > nabil.n.bitar@verizon.com; attila.takacs@ericsson.com > Cc: Black, David; Lou Berger; Deborah Brungard; Adrian Farrel; Daniel Kin= g; 'ccamp@ietf.org' > Subject: Gen-ART review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.txt >=20 > I am the assigned Gen-ART reviewer for this draft. For background on Gen-= ART, please see the FAQ at > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq . >=20 > Please resolve these comments along with any other comments you may recei= ve. >=20 > Summary: > This draft is on the right track, but has open issues, described in the r= eview. >=20 > This draft describes the use of a GMPLS control plane to configure explic= it forwarding in Ethernet > bridges for PBB-TE (Provider Backbone Bridge Traffic Engineering). >=20 > In general, the draft is in good shape; the two open issues are in Sectio= n 5.1.2 and are minor: > - Is the "has to allocate a VID" statement in Section 5.1.2 correct when = shared forwarding > is in use as described in Section 3.1 ? > - The error value: MPLS Label allocation failure (9) appears to be incons= istent with the > second bullet in Section 7 that requests IANA to allocate a new error va= lue: "PBB-TE > Ethernet Label VID allocation failure" (suggested value: 35?) for this = case. >=20 > Nits: >=20 > In Section 2, what are the I and B components of an IB-BEB? Interface an= d Bridge? >=20 > In Figure 1, the VIP acronym is not in Section 2's list of acronyms. >=20 > In Section 4.1, remove the note to IANA after 2) and instead insert this = instruction into Section 7. >=20 > In Figure 4, the type is TBA. Add an instruction to Section 7 for IANA t= o fill this in after it is > allocated. >=20 > In the fourth bullet in Section 7, please state that the registry is crea= ted by the MLN-EXT draft if > that is the case. >=20 > idnits 2.12.04 ran clean. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 From Adrian.Farrel@huawei.com Sat Oct 2 01:16:59 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4D43A6C0D; Sat, 2 Oct 2010 01:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqSlEGQj7nuE; Sat, 2 Oct 2010 01:16:58 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 7F7233A6BFD; Sat, 2 Oct 2010 01:16:58 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9N001RTLPO2H@usaga01-in.huawei.com>; Sat, 02 Oct 2010 01:17:48 -0700 (PDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9N003N4LP5GL@usaga01-in.huawei.com>; Sat, 02 Oct 2010 01:17:47 -0700 (PDT) Date: Sat, 02 Oct 2010 09:11:32 +0100 From: Adrian Farrel To: david.black@emc.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1BD03FE@MX14A.corp.emc.com> Cc: ccamp@ietf.org, david.black@emc.com, nabil.n.bitar@verizon.com, gen-art@ietf.org, dbrungard@att.com, donald.fedyk@alcatel-lucent.com Subject: Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 08:16:59 -0000 Thanks David, [snip] > The following 3 IANA-related nits still need attention: > > - In Section 4.1, remove the note to IANA after 2) and instead > insert this instruction into Section 7. This is already the first bullet point in Section 7. The RFC Editor will spot "suggested value" in 4.1 and update it. > - In Figure 4, the type is TBA. Add an instruction to Section 7 for IANA > to fill this in after it is allocated. RFC Editor has the practice of searching for TBA and replacing with the values assigned by IANA. > - In the fourth bullet in Section 7, please state that the registry is > created > by the MLN-EXT draft if that is the case. This was already added in -06 Thanks, Adrian From david.black@emc.com Mon Oct 4 06:13:05 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87D83A6F87; Mon, 4 Oct 2010 06:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG-HcD95Eg2P; Mon, 4 Oct 2010 06:13:04 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id CD9723A6CAA; Mon, 4 Oct 2010 06:13:03 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o94DDbnu014633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Oct 2010 09:13:38 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 4 Oct 2010 09:13:33 -0400 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o94DDHil005127; Mon, 4 Oct 2010 09:13:18 -0400 Received: from mxhub01.corp.emc.com ([10.254.141.103]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Oct 2010 09:13:18 -0400 Received: from mx14a.corp.emc.com ([169.254.1.11]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Mon, 4 Oct 2010 09:13:16 -0400 From: To: Date: Mon, 4 Oct 2010 09:13:06 -0400 Thread-Topic: Gen-ART review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt Thread-Index: ActiCnRZKPR0TuLMSUeAo84YagOe0gBu16PA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1BD04BE@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1BD03FE@MX14A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2010 13:13:18.0088 (UTC) FILETIME=[E91CD880:01CB63C5] X-EMM-MHVC: 1 Cc: david.black@emc.com, gen-art@ietf.org, nabil.n.bitar@verizon.com, ccamp@ietf.org, dbrungard@att.com, donald.fedyk@alcatel-lucent.com Subject: Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Oct 2010 13:13:05 -0000 That'll suffice, Thanks, --David > -----Original Message----- > From: Adrian Farrel [mailto:Adrian.Farrel@huawei.com] > Sent: Saturday, October 02, 2010 4:12 AM > To: Black, David > Cc: lberger@labn.net; dbrungard@att.com; daniel@olddog.co.uk; ccamp@ietf.= org; Black, David; gen- > art@ietf.org; donald.fedyk@alcatel-lucent.com; hshah@force10networks.com;= nabil.n.bitar@verizon.com; > attila.takacs@ericsson.com > Subject: Re: Gen-ART review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.= txt >=20 > Thanks David, >=20 > [snip] >=20 > > The following 3 IANA-related nits still need attention: > > > > - In Section 4.1, remove the note to IANA after 2) and instead > > insert this instruction into Section 7. >=20 > This is already the first bullet point in Section 7. > The RFC Editor will spot "suggested value" in 4.1 and update it. >=20 > > - In Figure 4, the type is TBA. Add an instruction to Section 7 for IA= NA > > to fill this in after it is allocated. >=20 > RFC Editor has the practice of searching for TBA and replacing with the > values assigned by IANA. >=20 > > - In the fourth bullet in Section 7, please state that the registry is > > created > > by the MLN-EXT draft if that is the case. >=20 > This was already added in -06 >=20 > Thanks, > Adrian >=20 From DanielC@orckit.com Tue Oct 5 06:26:11 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207F53A6F46 for ; Tue, 5 Oct 2010 06:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPdYtg13tZ8u for ; Tue, 5 Oct 2010 06:26:07 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id 35F7C3A6C4C for ; Tue, 5 Oct 2010 06:26:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6490.FF3271EC" Date: Tue, 5 Oct 2010 15:27:02 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130617FDAD@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on GMPLS protection object Class-Num in RFC 4872 Thread-Index: ActkkP7XTx0QCBUuT7eRGS7IIzeYTQ== From: "Daniel Cohn" To: Subject: [CCAMP] Question on GMPLS protection object Class-Num in RFC 4872 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2010 13:26:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6490.FF3271EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I noticed that, unlike other objects in RFC 4872, the GMPLS protection object Class-Num (37) is not explicitly specified in the xxbbbbbb form as per RFC 2205, section 3.10 Future Compatibility.=20 =20 I see two possible interpretations of this fact: =20 1.- This object is implicitly encoded in the Class-Num =3D 0bbbbbbb = form, meaning that a transit LSR that does not support this object should reject the entire message and return "unknown object class". Therefore an LSP with protection type specified in the GMPLS protection object cannot be established thru LSRs that don't support the object. =20 2.- The decision on the encoding of the two high-order bits is left to the LSP head, depending on the desired behavior for transit LSRs that don't support the GMPLS protection object. =20 Can you please let me know your thoughts on this? =20 Thanks, =20 Daniel Cohn System Engineer Orckit-Corrigent ------_=_NextPart_001_01CB6490.FF3271EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I noticed that, unlike other objects in RFC 4872, = the GMPLS protection object Class-Num (37) is not explicitly specified in the = xxbbbbbb form as per RFC 2205, section 3.10 Future Compatibility.

 

I see two possible interpretations of this = fact:

 

1.- This object is implicitly encoded in the = Class-Num =3D 0bbbbbbb form, meaning that a transit LSR that does not support this = object should reject the entire message and return “unknown object = class”. Therefore an LSP with protection type specified in the GMPLS protection object = cannot be established  thru LSRs that don’t support the = object.

 

2.- The decision on the encoding of the two = high-order bits is left to the LSP head, depending on the desired behavior for transit = LSRs that don’t support the GMPLS protection object.

 

Can you please let me know your thoughts on = this?

 

Thanks,

 

Daniel Cohn

System Engineer

Orckit-Corrigent

------_=_NextPart_001_01CB6490.FF3271EC-- From lberger@labn.net Tue Oct 5 16:48:22 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DAD23A6F40 for ; Tue, 5 Oct 2010 16:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMvq6+uMA3cn for ; Tue, 5 Oct 2010 16:48:21 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 398B43A6EAC for ; Tue, 5 Oct 2010 16:48:21 -0700 (PDT) Received: (qmail 18313 invoked by uid 0); 5 Oct 2010 23:49:20 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 5 Oct 2010 23:49:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=horNTJApgksMpj/yPknv+X5+GwcSGlCMxczmDB08gY9fEsOoeYPC7klgRcSbjk1BV1utsN8ILk5g9GFVW8CPSwr9JwnlKk9KBHapE1MXUNpnfBMp6IVmYGVJrfc3CKJc; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1P3HG3-0007M6-Sc; Tue, 05 Oct 2010 17:49:19 -0600 Message-ID: <4CABB9BE.4010709@labn.net> Date: Tue, 05 Oct 2010 19:50:22 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Daniel Cohn References: <44F4E579A764584EA9BDFD07D0CA08130617FDAD@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130617FDAD@tlvmail1> Content-Type: text/plain; charset=windows-1252; 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@ietf.org Subject: Re: [CCAMP] Question on GMPLS protection object Class-Num in RFC 4872 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2010 23:48:22 -0000 Daniel, There's not much room for interpreting this: [RFC 3473] 6. Protection Object The use of the Protection Object is optional. The object is included to indicate specific protection attributes of an LSP. The Protection Object uses Class-Number 37 (of form 0bbbbbbb). [RFC2205] o Class-Num = 0bbbbbbb The entire message should be rejected and an "Unknown Object Class" error returned. Lou On 10/5/2010 9:27 AM, Daniel Cohn wrote: > Hi, > > I noticed that, unlike other objects in RFC 4872, the GMPLS protection > object Class-Num (37) is not explicitly specified in the xxbbbbbb form > as per RFC 2205, section 3.10 Future Compatibility. > > I see two possible interpretations of this fact: > > 1.- This object is implicitly encoded in the Class-Num = 0bbbbbbb form, > meaning that a transit LSR that does not support this object should > reject the entire message and return “unknown object class”. Therefore > an LSP with protection type specified in the GMPLS protection object > cannot be established thru LSRs that don’t support the object. > > 2.- The decision on the encoding of the two high-order bits is left to > the LSP head, depending on the desired behavior for transit LSRs that > don’t support the GMPLS protection object. > > Can you please let me know your thoughts on this? > > Thanks, > > Daniel Cohn > > System Engineer > > Orckit-Corrigent > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From DanielC@orckit.com Wed Oct 6 01:03:39 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B53A3A6E7E for ; Wed, 6 Oct 2010 01:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52dLKNEfPihP for ; Wed, 6 Oct 2010 01:03:38 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id 94CAB3A6DE2 for ; Wed, 6 Oct 2010 01:03:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 10:04:34 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130617FF1E@tlvmail1> In-reply-to: <4CABB9BE.4010709@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Question on GMPLS protection object Class-Num in RFC 4872 Thread-Index: Actk5++TFwKMcxVQTYy3Lfujjq82igAREqkA References: <44F4E579A764584EA9BDFD07D0CA08130617FDAD@tlvmail1> <4CABB9BE.4010709@labn.net> From: "Daniel Cohn" To: "Lou Berger" Cc: ccamp@ietf.org Subject: Re: [CCAMP] Question on GMPLS protection object Class-Num in RFC 4872 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Oct 2010 08:03:39 -0000 Hi Lou, thanks for pointing me to RFC 3473, I agree the wording there is unambiguous.=20 It would have been helpful if RFC 4872 mentioned this too. Regards, Daniel -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, October 06, 2010 1:50 AM To: Daniel Cohn Cc: ccamp@ietf.org Subject: Re: [CCAMP] Question on GMPLS protection object Class-Num in RFC 4872 Daniel, There's not much room for interpreting this: [RFC 3473] 6. Protection Object The use of the Protection Object is optional. The object is included to indicate specific protection attributes of an LSP. The Protection Object uses Class-Number 37 (of form 0bbbbbbb). [RFC2205] o Class-Num =3D 0bbbbbbb The entire message should be rejected and an "Unknown Object Class" error returned. Lou On 10/5/2010 9:27 AM, Daniel Cohn wrote: > Hi, > > I noticed that, unlike other objects in RFC 4872, the GMPLS protection > object Class-Num (37) is not explicitly specified in the xxbbbbbb form > as per RFC 2205, section 3.10 Future Compatibility. > > I see two possible interpretations of this fact: > > 1.- This object is implicitly encoded in the Class-Num =3D 0bbbbbbb form, > meaning that a transit LSR that does not support this object should > reject the entire message and return "unknown object class". Therefore > an LSP with protection type specified in the GMPLS protection object > cannot be established thru LSRs that don't support the object. > > 2.- The decision on the encoding of the two high-order bits is left to > the LSP head, depending on the desired behavior for transit LSRs that > don't support the GMPLS protection object. > > Can you please let me know your thoughts on this? > > Thanks, > > Daniel Cohn > > System Engineer > > Orckit-Corrigent > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Wed Oct 6 04:03:10 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2983A711B for ; Wed, 6 Oct 2010 04:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz0v4-N6qoXb for ; Wed, 6 Oct 2010 04:03:09 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 02A8B3A7118 for ; Wed, 6 Oct 2010 04:03:08 -0700 (PDT) Received: (qmail 10760 invoked by uid 0); 6 Oct 2010 11:04:08 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 6 Oct 2010 11:04:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=19gXnDQATnp4k3T6BwJeAhTRuB/GXevJRMYHkH/4b1/0+ytWOlo3eEUCmrwsuGZodOlT3HdoBqVcrjZ54CPeBK22/6LsJjVWCR/rTLnmVOoqVlT6M63DOfcneVOCQcqV; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1P3Rn6-0000Ro-Eg; Wed, 06 Oct 2010 05:04:08 -0600 Message-ID: <4CAC57AB.7070901@labn.net> Date: Wed, 06 Oct 2010 07:04:11 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Daniel Cohn References: <44F4E579A764584EA9BDFD07D0CA08130617FDAD@tlvmail1> <4CABB9BE.4010709@labn.net> <44F4E579A764584EA9BDFD07D0CA08130617FF1E@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130617FF1E@tlvmail1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] Question on GMPLS protection object Class-Num in RFC 4872 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Oct 2010 11:03:10 -0000 I don't see RFC 4872 (i.e., "PROTECTION object: Class-Num = 37") as any less ambigious. Lou On 10/6/2010 4:04 AM, Daniel Cohn wrote: > Hi Lou, thanks for pointing me to RFC 3473, I agree the wording there is > unambiguous. > > It would have been helpful if RFC 4872 mentioned this too. > > Regards, > > Daniel > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, October 06, 2010 1:50 AM > To: Daniel Cohn > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] Question on GMPLS protection object Class-Num in > RFC 4872 > > Daniel, > There's not much room for interpreting this: > > [RFC 3473] > 6. Protection Object > > The use of the Protection Object is optional. The object is > included > to indicate specific protection attributes of an LSP. The > Protection > Object uses Class-Number 37 (of form 0bbbbbbb). > > [RFC2205] > o Class-Num = 0bbbbbbb > > The entire message should be rejected and an "Unknown > Object Class" error returned. > > Lou > > > > On 10/5/2010 9:27 AM, Daniel Cohn wrote: >> Hi, >> >> I noticed that, unlike other objects in RFC 4872, the GMPLS protection >> object Class-Num (37) is not explicitly specified in the xxbbbbbb form >> as per RFC 2205, section 3.10 Future Compatibility. >> >> I see two possible interpretations of this fact: >> >> 1.- This object is implicitly encoded in the Class-Num = 0bbbbbbb > form, >> meaning that a transit LSR that does not support this object should >> reject the entire message and return "unknown object class". Therefore >> an LSP with protection type specified in the GMPLS protection object >> cannot be established thru LSRs that don't support the object. >> >> 2.- The decision on the encoding of the two high-order bits is left to >> the LSP head, depending on the desired behavior for transit LSRs that >> don't support the GMPLS protection object. >> >> Can you please let me know your thoughts on this? >> >> Thanks, >> >> Daniel Cohn >> >> System Engineer >> >> Orckit-Corrigent >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > From db3546@att.com Thu Oct 7 08:34:20 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEAE63A6EE5 for ; Thu, 7 Oct 2010 08:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.162 X-Spam-Level: X-Spam-Status: No, score=-106.162 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35w+IJew-b2H for ; Thu, 7 Oct 2010 08:34:19 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with SMTP id BE5753A6C4C for ; Thu, 7 Oct 2010 08:34:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-12.tower-167.messagelabs.com!1286465633!39780721!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24286 invoked from network); 7 Oct 2010 15:33:54 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Oct 2010 15:33:54 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o97FXI7T030845 for ; Thu, 7 Oct 2010 11:33:18 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o97FXDeQ030749 for ; Thu, 7 Oct 2010 11:33:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Oct 2010 11:33:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Closed: Poll to adopt draft-bernstein-ccamp-wson-signaling-07.txtas CCAMP WG document Thread-Index: ActWlWYufBQVOiB8TSeEwa9ClCjUTwPnpxqA References: From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: Re: [CCAMP] Closed: Poll to adopt draft-bernstein-ccamp-wson-signaling-07.txtas CCAMP WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Oct 2010 15:34:21 -0000 All, This poll has been closed. We have accepted the draft as a ccamp working group document. Authors, please re-publish the draft with no other changes than file name and version as: draft-ietf-ccamp-wson-signaling-00.txt Thanks, Deborah and Lou -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Friday, September 17, 2010 2:23 PM To: CCAMP Subject: [CCAMP] Poll to adopt draft-bernstein-ccamp-wson-signaling-07.txtas CCAMP WG document All, This starts a two week poll on adopting draft-bernstein-ccamp-wson-signaling-07.txt as a CCAMP WG document. Please indicate your support or otherwise by responding to this message (yes/support or no/do not support). Please send your responses by Oct. 1. Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Thu Oct 7 08:46:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEFC53A6F42 for ; Thu, 7 Oct 2010 08:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.314 X-Spam-Level: X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chi+gGF8iB6q for ; Thu, 7 Oct 2010 08:46:36 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 3D7933A6E12 for ; Thu, 7 Oct 2010 08:46:36 -0700 (PDT) Received: (qmail 14054 invoked by uid 0); 7 Oct 2010 15:47:38 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 7 Oct 2010 15:47:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=1tFPTpDwWR5iHcHKMabAQusWiSksqlhWEEPx0AbwL2UqRfJyGj0bvT1da21b4oGNSI36Ez14feI5A+KnF+Zfzqn3nXCp7SRHZhYxJvK90Ek2WuwNw7HzUSSvgnsXMIZU; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1P3sh0-0007Wr-Dn for ccamp@ietf.org; Thu, 07 Oct 2010 09:47:38 -0600 Message-ID: <4CADEBAF.5080703@labn.net> Date: Thu, 07 Oct 2010 11:47:59 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] Reminder: cutoff dates X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Oct 2010 15:46:38 -0000 All, Please keep in mind the upcoming cutoff dates: (from http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79) 2010-10-06 (Wednesday): Preliminary agenda published for comment. 2010-10-11 (Monday): Working Group Chair approval for initial document (Version -00) submissions by 17:00 PT (24:00 UTC). 2010-10-15 (Friday): Final agenda to be published. 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (24:00 UTC), upload using IETF ID Submission Tool. 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT (24:00 UTC), upload using IETF ID Submission Tool. 2010-10-27 (Wednesday): Draft Working Group agendas due by 17:00 PT (24:00 UTC), upload using IETF Meeting Materials Management Tool. Lou (and Deborah) From root@core3.amsl.com Thu Oct 7 09:15:13 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A25773A6FC7; Thu, 7 Oct 2010 09:15:10 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101007161513.A25773A6FC7@core3.amsl.com> Date: Thu, 7 Oct 2010 09:15:11 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-wson-signaling-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Oct 2010 16:15:13 -0000 --NextPart 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 : Signaling Extensions for Wavelength Switched Optical Networks Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-wson-signaling-00.txt Pages : 21 Date : 2010-10-07 This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Such extensions are necessary in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment with bidirectional LSPs, and choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signaling-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-wson-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-07090607.I-D@ietf.org> --NextPart-- From db3546@att.com Thu Oct 7 10:42:38 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC3E3A70DA for ; Thu, 7 Oct 2010 10:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.195 X-Spam-Level: X-Spam-Status: No, score=-106.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEqe6-LpCPfC for ; Thu, 7 Oct 2010 10:42:37 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 393613A714B for ; Thu, 7 Oct 2010 10:42:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-7.tower-129.messagelabs.com!1286473418!33977531!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24337 invoked from network); 7 Oct 2010 17:43:39 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Oct 2010 17:43:39 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o97Hh3c8021667 for ; Thu, 7 Oct 2010 13:43:03 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o97Hgx3A021620 for ; Thu, 7 Oct 2010 13:43:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Oct 2010 13:43:33 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Closed: Poll to adoptdraft-li-ccamp-lmp-behavior-negotiation-01.txt as CCAMP WG document Thread-Index: ActWljJNmTb8WIVJSdeskzWEdPvX7wPnt8EA References: From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: Re: [CCAMP] Closed: Poll to adoptdraft-li-ccamp-lmp-behavior-negotiation-01.txt as CCAMP WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Oct 2010 17:42:38 -0000 All, This poll has been closed. We have accepted the draft as a ccamp working group document. Authors, please re-publish the draft with no other changes than file name and version as: draft-ietf-ccamp-lmp-behavior-negotiation-00.txt Thanks, Deborah and Lou -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Friday, September 17, 2010 2:29 PM To: CCAMP Subject: [CCAMP] Poll to adoptdraft-li-ccamp-lmp-behavior-negotiation-01.txt as CCAMP WG document All, This starts a two week poll on adopting draft-li-ccamp-lmp-behavior-negotiation-01.txt as a CCAMP WG document. Please indicate your support or otherwise by responding to this message (yes/support or no/do not support). Please send your responses by Oct. 1. Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Thu Oct 7 12:24:06 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3EE3A6FE5 for ; Thu, 7 Oct 2010 12:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 304yi40cznVE for ; Thu, 7 Oct 2010 12:24:03 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id DA79E3A6CBE for ; Thu, 7 Oct 2010 12:24:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1286479503!50576130!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 5820 invoked from network); 7 Oct 2010 19:25:04 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Oct 2010 19:25:04 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o97JOSlU007753 for ; Thu, 7 Oct 2010 15:24:28 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o97JOOAM007673 for ; Thu, 7 Oct 2010 15:24:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Oct 2010 15:24:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] WG Last Call ondraft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt Thread-Index: ActWlERNScNb6YrJRsGIC45dE2RaygPwMqnw References: From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: Re: [CCAMP] WG Last Call ondraft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Oct 2010 19:24:06 -0000 This WG Last Call has ended. -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Friday, September 17, 2010 2:15 PM To: CCAMP Subject: [CCAMP] WG Last Call ondraft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt All, This is to start a two-week working group last call on draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt. This working group last call ends Oct. 1. Please send your comments to the CCAMP mailing list. Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From root@core3.amsl.com Fri Oct 8 03:30:49 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8F4D43A684C; Fri, 8 Oct 2010 03:30:13 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101008103029.8F4D43A684C@core3.amsl.com> Date: Fri, 8 Oct 2010 03:30:13 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lmp-behavior-negotiation-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2010 10:30:50 -0000 --NextPart 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 : Behavior Negotiation in Link Management Protocol Author(s) : D. Li, D. Ceccarelli Filename : draft-ietf-ccamp-lmp-behavior-negotiation-00.txt Pages : 8 Date : 2010-10-07 The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS) networks. Various proposals have been advanced to provide extensions to the base LMP specification. This document provides a generic procedure for LMP implementations that do not recognize or do not support any one of these extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-behavior-negotiation-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-behavior-negotiation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-08032811.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Oct 8 14:00:01 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CCF273A6961; Fri, 8 Oct 2010 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101008210001.CCF273A6961@core3.amsl.com> Date: Fri, 8 Oct 2010 14:00:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2010 21:00:01 -0000 --NextPart 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 : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-wson-framework-07.txt Pages : 55 Date : 2010-10-08 This document provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular, it examines the Routing and Wavelength Assignment (RWA) problem. This document focuses on topological elements and path selection constraints that are common across different WSON environments as such it does not address optical impairments in any depth. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-wson-framework-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-08135232.I-D@ietf.org> --NextPart-- From wwwrun@rfc-editor.org Sun Oct 10 17:09:07 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D87E3A68AF; Sun, 10 Oct 2010 17:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98sPPr7NnY74; Sun, 10 Oct 2010 17:09:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 76E403A68B2; Sun, 10 Oct 2010 17:09:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5D10AE06F0; Sun, 10 Oct 2010 17:10:14 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101011001014.5D10AE06F0@rfc-editor.org> Date: Sun, 10 Oct 2010 17:10:14 -0700 (PDT) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 6001 on Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 00:09:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6001 Title: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) Author: D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, JL. Le Roux Status: Standards Track Stream: IETF Date: October 2010 Mailbox: dimitri.papadimitriou@alcatel-lucent.com, martin.vigoureux@alcatel-lucent.fr, shiomoto.kohei@lab.ntt.co.jp, dbrungard@att.com, jean-louis.leroux@rd.francetelecom.com Pages: 24 Characters: 52501 Updates: RFC4202, RFC4203, RFC4206, RFC4874, RFC4974, RFC5307 I-D Tag: draft-ietf-ccamp-gmpls-mln-extensions-12.txt URL: http://www.rfc-editor.org/rfc/rfc6001.txt There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Sun Oct 10 17:09:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51883A68B3; Sun, 10 Oct 2010 17:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.914 X-Spam-Level: X-Spam-Status: No, score=-101.914 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhU2OJMFe5HW; Sun, 10 Oct 2010 17:09:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 8E7DC3A68AF; Sun, 10 Oct 2010 17:09:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 69677E06FC; Sun, 10 Oct 2010 17:10:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101011001027.69677E06FC@rfc-editor.org> Date: Sun, 10 Oct 2010 17:10:27 -0700 (PDT) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 6002 on Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 00:09:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6002 Title: Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions Author: L. Berger, D. Fedyk Status: Standards Track Stream: IETF Date: October 2010 Mailbox: lberger@labn.net, donald.fedyk@alcatel-lucent.com Pages: 10 Characters: 23090 Updates: RFC3471, RFC3473, RFC3945, RFC4202, RFC4203, RFC5307 I-D Tag: draft-ietf-ccamp-gmpls-dcsc-channel-ext-04.txt URL: http://www.rfc-editor.org/rfc/rfc6002.txt This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP). [STANDARDS-TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Sun Oct 10 17:09:33 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144213A68E7; Sun, 10 Oct 2010 17:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.919 X-Spam-Level: X-Spam-Status: No, score=-101.919 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFfFGkcxDijG; Sun, 10 Oct 2010 17:09:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 336C53A68AF; Sun, 10 Oct 2010 17:09:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 18221E06FB; Sun, 10 Oct 2010 17:10:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101011001042.18221E06FB@rfc-editor.org> Date: Sun, 10 Oct 2010 17:10:42 -0700 (PDT) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 6003 on Ethernet Traffic Parameters X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 00:09:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6003 Title: Ethernet Traffic Parameters Author: D. Papadimitriou Status: Standards Track Stream: IETF Date: October 2010 Mailbox: dimitri.papadimitriou@alcatel-lucent.be Pages: 14 Characters: 28232 Updates: RFC3471, RFC3473 I-D Tag: draft-ietf-ccamp-ethernet-traffic-parameters-10.txt URL: http://www.rfc-editor.org/rfc/rfc6003.txt This document describes the support of Metro Ethernet Forum (MEF) Ethernet traffic parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. [STANDARDS-TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Sun Oct 10 17:09:45 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FF6B3A68D5; Sun, 10 Oct 2010 17:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.923 X-Spam-Level: X-Spam-Status: No, score=-101.923 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeepC0qgq48Q; Sun, 10 Oct 2010 17:09:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 8BB503A688A; Sun, 10 Oct 2010 17:09:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 73BDCE0706; Sun, 10 Oct 2010 17:10:55 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101011001055.73BDCE0706@rfc-editor.org> Date: Sun, 10 Oct 2010 17:10:55 -0700 (PDT) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 6004 on Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 00:09:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6004 Title: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching Author: L. Berger, D. Fedyk Status: Standards Track Stream: IETF Date: October 2010 Mailbox: lberger@labn.net, donald.fedyk@alcatel-lucent.com Pages: 15 Characters: 32319 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-ether-svcs-04.txt URL: http://www.rfc-editor.org/rfc/rfc6004.txt This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Sun Oct 10 17:10:07 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5393E3A68AF; Sun, 10 Oct 2010 17:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.927 X-Spam-Level: X-Spam-Status: No, score=-101.927 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFx6h3VT1IoQ; Sun, 10 Oct 2010 17:10:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id A17833A68BC; Sun, 10 Oct 2010 17:10:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 83BBEE0710; Sun, 10 Oct 2010 17:11:12 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101011001112.83BBEE0710@rfc-editor.org> Date: Sun, 10 Oct 2010 17:11:12 -0700 (PDT) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 6005 on Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 00:10:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6005 Title: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) Author: L. Berger, D. Fedyk Status: Standards Track Stream: IETF Date: October 2010 Mailbox: lberger@labn.net, donald.fedyk@alcatel-lucent.com Pages: 10 Characters: 20301 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-mef-uni-03.txt URL: http://www.rfc-editor.org/rfc/rfc6005.txt This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. [STANDARDS- TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From root@core3.amsl.com Mon Oct 11 00:15:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7D0573A6903; Mon, 11 Oct 2010 00:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101011071502.7D0573A6903@core3.amsl.com> Date: Mon, 11 Oct 2010 00:15:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lmp-behavior-negotiation-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 07:15:02 -0000 --NextPart 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 : Behavior Negotiation in The Link Management Protocol Author(s) : D. Li, D. Ceccarelli Filename : draft-ietf-ccamp-lmp-behavior-negotiation-01.txt Pages : 8 Date : 2010-10-11 The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS) networks. Various proposals have been advanced to provide extensions to the base LMP specification. This document defines an extension to negotiated capabilities and provides a generic procedure for LMP implementations that do not recognize or do not support any one of these extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-behavior-negotiation-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-behavior-negotiation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-11001153.I-D@ietf.org> --NextPart-- From danli@huawei.com Mon Oct 11 00:34:09 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF613A68E4 for ; Mon, 11 Oct 2010 00:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.923 X-Spam-Level: *** X-Spam-Status: No, score=3.923 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_NUMERIC_HELO=2.067, SARE_RECV_IP_061172=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr9OUyTqUsxY for ; Mon, 11 Oct 2010 00:34:07 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id C128B3A68C3 for ; Mon, 11 Oct 2010 00:34:07 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA400K817QUSR@usaga01-in.huawei.com> for ccamp@ietf.org; Mon, 11 Oct 2010 00:35:18 -0700 (PDT) Received: from 255.130.173.61.broad.xw.sh.dynamic.163data.com.cn (255.130.173.61.broad.xw.sh.dynamic.163data.com.cn [61.173.130.255]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0LA4007U37QM1G@usaga01-in.huawei.com> for ccamp@ietf.org; Mon, 11 Oct 2010 00:35:18 -0700 (PDT) Date: Mon, 11 Oct 2010 15:29:41 +0800 From: Dan Li In-reply-to: <20101011071502.7D0573A6903@core3.amsl.com> To: CCAMP Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable References: <20101011071502.7D0573A6903@core3.amsl.com> Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lmp-behavior-negotiation-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 07:34:09 -0000 Hi all, As we have discussed during IETF 78th meeting in Masstricht, the = architecture bits are removed in this updated 01 version.=20 Please check out the updated draft-ietf-ccamp-lmp-behavior-negotiation. = Comments are always welcome! Best regards, Dan =D4=DA 2010-10-11=A3=AC=CF=C2=CE=E73:15=A3=AC Internet-Drafts@ietf.org = =D0=B4=B5=C0=A3=BA > 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. >=20 >=20 > Title : Behavior Negotiation in The Link Management = Protocol > Author(s) : D. Li, D. Ceccarelli > Filename : = draft-ietf-ccamp-lmp-behavior-negotiation-01.txt > Pages : 8 > Date : 2010-10-11 >=20 > The Link Management Protocol (LMP) is used to coordinate the=20 > properties, use, and faults of data links in Generalized=20 > Multiprotocol Label Switching (GMPLS) networks. Various proposals=20 > have been advanced to provide extensions to the base LMP=20 > specification. This document defines an extension to negotiated=20 > capabilities and provides a generic procedure for LMP=20 > implementations that do not recognize or do not support any one of=20 > these extensions. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-behavior-negotiat= ion-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > <=D3=CA=BC=FE=B8=BD=BC=FE>______________________________________________= _ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From root@core3.amsl.com Mon Oct 11 06:15:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5A9363A6A28; Mon, 11 Oct 2010 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101011131502.5A9363A6A28@core3.amsl.com> Date: Mon, 11 Oct 2010 06:15:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-dpm-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 13:15:02 -0000 --NextPart 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 : Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ MPLS-TE Networks Author(s) : W. Sun, et al. Filename : draft-ietf-ccamp-dpm-01.txt Pages : 34 Date : 2010-10-11 When setting up a label switched path (LSP) in Generalized MPLS and MPLS/TE networks, the completion of the signaling process does not necessarily mean that the cross connection along the LSP have been programmed accordingly and in a timely manner. Meanwhile, the completion of signaling process may be used by applications as indication that data path has become usable. The existence of this delay and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the application model and to build more robust applications. This document defines a series of performance metrics to evaluate the availability of data path in the signaling process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-dpm-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-dpm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-11060241.I-D@ietf.org> --NextPart-- From sunwq@mit.edu Mon Oct 11 06:38:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B6E3A6A0A for ; Mon, 11 Oct 2010 06:38:21 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X75UXujRcFjQ for ; Mon, 11 Oct 2010 06:38:18 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id 546893A69F5 for ; Mon, 11 Oct 2010 06:38:18 -0700 (PDT) X-AuditID: 1209190d-b7cacae000000a14-6a-4cb313947f29 Received: from mailhub-1.mit.edu ( [18.9.21.34]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 59.52.02580.49313BC4; Mon, 11 Oct 2010 09:39:32 -0400 (EDT) Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by mailhub-1.mit.edu (8.13.8/8.9.2) with ESMTP id o9BDdThQ029395 for ; Mon, 11 Oct 2010 09:39:29 -0400 Received: from [192.168.1.2] (10.202.79.124.broad.xw.sh.dynamic.163data.com.cn [124.79.202.10] (may be forged)) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id o9BDdL1J025785 for ; Mon, 11 Oct 2010 09:39:26 -0400 (EDT) User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 11 Oct 2010 21:39:19 +0800 From: Weiqiang Sun To: Message-ID: Thread-Topic: [CCAMP] I-D Action:draft-ietf-ccamp-dpm-01.txt Thread-Index: ActpSbRhLblwFJJ9mUm8RujOz6e9Iw== In-Reply-To: <20101011131502.5A9363A6A28@core3.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-dpm-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 13:38:21 -0000 Hi all, We have uploaded a newer version of the draft-ietf-ccamp-dpm draft. We made a couple of editorial changes as well as technical changes. The technical changes are listed below: 1. An updated statistical metrics section taking into account the comments received for the DPPM doc during the IESG review stage. 2. Two new metrics were added - PSFD and PSRD. Comments and suggestions are welcome. Thanks, Weiqiang On 10/11/10 9:15 PM, "Internet-Drafts@ietf.org" wrote: > 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 : Label Switched Path (LSP) Data Path Delay Metrics in > Generalized MPLS/ MPLS-TE Networks > Author(s) : W. Sun, et al. > Filename : draft-ietf-ccamp-dpm-01.txt > Pages : 34 > Date : 2010-10-11 > > When setting up a label switched path (LSP) in Generalized MPLS and > MPLS/TE networks, the completion of the signaling process does not > necessarily mean that the cross connection along the LSP have been > programmed accordingly and in a timely manner. Meanwhile, the > completion of signaling process may be used by applications as > indication that data path has become usable. The existence of this > delay and the possible failure of cross connection programming, if > not properly treated, will result in data loss or even application > failure. Characterization of this performance can thus help > designers to improve the application model and to build more robust > applications. This document defines a series of performance metrics > to evaluate the availability of data path in the signaling process. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-dpm-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From rfgraveman@gmail.com Mon Oct 11 08:57:51 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16C03A69A5 for ; Mon, 11 Oct 2010 08:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=-1.395, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnMDVwo+rF9O for ; Mon, 11 Oct 2010 08:57:51 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E53A13A6910 for ; Mon, 11 Oct 2010 08:57:50 -0700 (PDT) Received: by iwn10 with SMTP id 10so4830978iwn.31 for ; Mon, 11 Oct 2010 08:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vQ6m3HnU2EHMN5F6cNH1PnwDf7Ekti9/aFT7Vlhi2gQ=; b=RIwFNAp/eJCjtvMkXjdlyWZ1SKKPxetpHIGOeuLocJoY32gylCYo55tCn2e6T8SM6Z 1z6lx3f/6I9omvxDMn5DGKBcXdkJ6zbfZzCs0WyctAxVsw8aEhZnOAxvkWdBxrAmaWCA QHy7Dw9/eX3XJcOgccuV/PhUu+idtWAsQKqro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SqWioZccGSgAWW+57pZfgaD4YRgoYbLXemEa+IlXXqnfD9pu1F/rtZsMU9h/y3a+mC 9GvygpbLJSCixHS5OBv5Q9KXIRe6Onn/u5HzLiF2PoKwOHCr9fQs2BupCBZwX6r+KQef 2jLnETeqcz5XPcInVskQi8ohnjyfgB86qMpws= MIME-Version: 1.0 Received: by 10.231.152.143 with SMTP id g15mr4728765ibw.76.1286812742848; Mon, 11 Oct 2010 08:59:02 -0700 (PDT) Received: by 10.231.15.2 with HTTP; Mon, 11 Oct 2010 08:59:00 -0700 (PDT) In-Reply-To: References: <20101011071502.7D0573A6903@core3.amsl.com> Date: Mon, 11 Oct 2010 11:59:00 -0400 Message-ID: From: Richard Graveman To: Dan Li Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: CCAMP Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lmp-behavior-negotiation-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 15:57:52 -0000 =C4=FA=BA=C3Dan=A3=AC The Security Considerations of this draft section says that the security in RFC 4204 is RECOMMENDED, so it may be worthwhile to go back and look at that. With one exception, IMO the recommendations in 4204 are sound, but they are out of date. In particular: 1. RFC 5996 makes a lot of the more complicated the text about Quick Mode, Aggressive Mode, and DOI unnecessary. 2. RFC 5840 may be a convenient improvement for some deployments. 3. There is no discussion about NAT or an IPv4-IPv6 transition environment. 4. Newer cryptographic algorithms may be more secure and more efficient. Nevertheless, there may be cases where the old-style RFC-2401-based IPsec is available but the new style RFC-4301-5996-based IPsec is not. The Security Considerations section of this draft says something about messages being intercepted. The confidentiality service of ESP can mitigate that of course, but RFC 4204 proscribes confidentiality. This seems rash to me. A statement that authentication, replay detection, and integrity may be the most important security services in most case suffices. Saying that confidentiality is not needed is making too many assumptions about the operational environment. The situation may vary from case to case. See also RFC 5920 for additional guidance. Rich Graveman 2010/10/11 Dan Li : > Hi all, > > As we have discussed during IETF 78th meeting in Masstricht, the architec= ture bits are removed in this updated 01 version. > > Please check out the updated draft-ietf-ccamp-lmp-behavior-negotiation. C= omments are always welcome! > > Best regards, > > Dan > > =D4=DA 2010-10-11=A3=AC=CF=C2=CE=E73:15=A3=AC Internet-Drafts@ietf.org = =D0=B4=B5=C0=A3=BA > >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Common Control and Measurement Plane Wo= rking Group of the IETF. >> >> >> Title : Behavior Negotiation in The Link Management Prot= ocol >> Author(s) : D. Li, D. Ceccarelli >> Filename : draft-ietf-ccamp-lmp-behavior-negotiation-01.txt >> Pages : 8 >> Date : 2010-10-11 >> >> The Link Management Protocol (LMP) is used to coordinate the >> properties, use, and faults of data links in Generalized >> Multiprotocol Label Switching (GMPLS) networks. Various proposals >> have been advanced to provide extensions to the base LMP >> specification. This document defines an extension to negotiated >> capabilities and provides a generic procedure for LMP >> implementations that do not recognize or do not support any one of >> these extensions. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-behavior-negoti= ation-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> <=D3=CA=BC=FE=B8=BD=BC=FE>______________________________________________= _ >> 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 daniel@olddog.co.uk Mon Oct 11 12:39:59 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D933A6B8C for ; Mon, 11 Oct 2010 12:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.421 X-Spam-Level: X-Spam-Status: No, score=-101.421 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXnzgf7EyUFR for ; Mon, 11 Oct 2010 12:39:58 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id B48013A6B65 for ; Mon, 11 Oct 2010 12:39:18 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o9BJeJNa016800; Mon, 11 Oct 2010 20:40:19 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o9BJeIZJ016794; Mon, 11 Oct 2010 20:40:19 +0100 From: "Daniel King" To: "'CCAMP'" Date: Mon, 11 Oct 2010 20:40:18 +0100 Message-ID: <001301cb697c$23235390$6969fab0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: ActpfCKkgVn2liaaQD28bS6zLeUjTg== Content-Language: en-gb Cc: "'DEBORAH A, ATTLABS BRUNGARD'" Subject: [CCAMP] Agenda Requests for IETF 79 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 19:39:59 -0000 Hello CCAMP'rs, Please let us know if you have an agenda request for our CCAMP session at IETF 79. Requests MUST be sent to the chairs (db3546@att.com and lberger@labn.net)and secretary (daniel@olddog.co.uk) with the desired duration, topic/draft title, and presenter for each slot that you request. Please let us have your requests by Sunday, 24 October. Housekeeping: a) Presentation slots require published drafts or specific approval from a WG chair. b) Presentations should focus on open issues and questions for the WG. c) Presentations should not include a tutorial of the draft, but rather a brief review of changes and draft status. Key dates are: 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (24:00 UTC). 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT (24:00 UTC). The preliminary agenda has also been posted: https://datatracker.ietf.org/meeting/79/agenda.html Br, Dan. From db3546@att.com Mon Oct 11 12:53:56 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCFD73A6B65; Mon, 11 Oct 2010 12:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLWQx05vt0JP; Mon, 11 Oct 2010 12:53:54 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 8167A3A6B2B; Mon, 11 Oct 2010 12:53:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-13.tower-161.messagelabs.com!1286826904!28677316!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 4760 invoked from network); 11 Oct 2010 19:55:05 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Oct 2010 19:55:05 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9BJsSDK006886; Mon, 11 Oct 2010 15:54:28 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9BJsOAb006800; Mon, 11 Oct 2010 15:54:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Oct 2010 15:54:59 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RSVP-related drafts as CCAMP wg docs Thread-Index: Actpfi+RSzeqeMgoSxSclsj5MA6H7A== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Cc: tsvwg@ietf.org Subject: [CCAMP] RSVP-related drafts as CCAMP wg docs X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Oct 2010 19:53:56 -0000 CCAMP, As discussed during the last IETF and follow-up discussion with our AD, CCAMP will take on the RSVP work in the following documents. Authors, please upload your documents without changes other than file name and version as: draft-ietf-ccamp-assoc-info-00.txt draft-ietf-ccamp-rsvp-resource-sharing-00.txt Thanks, Deborah (and Lou) From wwwrun@rfc-editor.org Tue Oct 12 10:21:59 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6563A67FA for ; Tue, 12 Oct 2010 10:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73cQ7fc07zSV for ; Tue, 12 Oct 2010 10:21:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 8E8E23A6941 for ; Tue, 12 Oct 2010 10:21:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7D0E6E06D7; Tue, 12 Oct 2010 10:23:09 -0700 (PDT) To: dimitri.papadimitriou@alcatel-lucent.be, stbryant@cisco.com, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System Message-Id: <20101012172309.7D0E6E06D7@rfc-editor.org> Date: Tue, 12 Oct 2010 10:23:09 -0700 (PDT) Cc: ah@TR-Sys.de, ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] [Editorial Errata Reported] RFC6003 (2551) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2010 17:21:59 -0000 The following errata report has been submitted for RFC6003, "Ethernet Traffic Parameters". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6003&eid=2551 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 4, pg. 5 Original Text ------------- Type: 16 bits Defined values are: Type Length Format Description ------------------------------------------------------ 0 - Reserved Reserved value 1 - Reserved Reserved value | 2 24 see Section 3.1 Ethernet Bandwidth Profile [MEF10.1] 3 8 [RFC6004] Layer 2 Control Protocol (L2CP) 255 - Reserved Reserved value Corrected Text -------------- Type: 16 bits Defined values are: Type Length Format Description ------------------------------------------------------ 0 - Reserved Reserved value 1 - Reserved Reserved value | 2 24 see Section 4.1 Ethernet Bandwidth Profile [MEF10.1] 3 8 [RFC6004] Layer 2 Control Protocol (L2CP) 255 - Reserved Reserved value Notes ----- Rationale: no such Section 3.1 in this RFC ! Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6003 (draft-ietf-ccamp-ethernet-traffic-parameters-10) -------------------------------------- Title : Ethernet Traffic Parameters Publication Date : October 2010 Author(s) : D. Papadimitriou Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Tue Oct 12 10:27:54 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3533A6822 for ; Tue, 12 Oct 2010 10:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.255 X-Spam-Level: X-Spam-Status: No, score=-102.255 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzPByYhJ8NRW for ; Tue, 12 Oct 2010 10:27:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id B4B243A6910 for ; Tue, 12 Oct 2010 10:27:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A408AE06D7; Tue, 12 Oct 2010 10:29:08 -0700 (PDT) To: dimitri.papadimitriou@alcatel-lucent.be, stbryant@cisco.com, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System Message-Id: <20101012172908.A408AE06D7@rfc-editor.org> Date: Tue, 12 Oct 2010 10:29:08 -0700 (PDT) Cc: ah@TR-Sys.de, ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] [Technical Errata Reported] RFC6003 (2552) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2010 17:27:54 -0000 The following errata report has been submitted for RFC6003, "Ethernet Traffic Parameters". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6003&eid=2552 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 4.1, pg.7 Original Text ------------- Index: 8 bits [...] A given index value j can be associated to at most N Class-Type values CTi (i =< N) of the EXTENDED_CLASSTYPE object. This | association applies when a set of one or more CTIs maps to a single (shared) BW profile. An example of value setting consists in assigning an arbitrary value comprised within the range [0x08,0xF8] associated to a set of CTi, the values in the range | [0xF8,0xFF] being selected for reserved sets. This allows mapping to one of 248 predefined CTi sets. Corrected Text -------------- Index: 8 bits [...] A given index value j can be associated to at most N Class-Type values CTi (i =< N) of the EXTENDED_CLASSTYPE object. This | association applies when a set of one or more CTis maps to a single (shared) BW profile. An example of value setting consists in assigning an arbitrary value comprised within the range [0x08,0xF8] associated to a set of CTi, the values in the range | [0xF9,0xFF] being selected for reserved sets. This allows mapping to one of 248 predefined CTi sets. Notes ----- Rationale: a) consistent use of "CTi" -- 'i' essentially is a subscript index; b) avoid ambiguity due to overlap in ranges given [The first item is Editorial, but the second one clearly Technical; to simplify Errata management, only a single, combined report is submitted covering both.] Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6003 (draft-ietf-ccamp-ethernet-traffic-parameters-10) -------------------------------------- Title : Ethernet Traffic Parameters Publication Date : October 2010 Author(s) : D. Papadimitriou Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From danli@huawei.com Tue Oct 12 18:30:13 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4AB3A6AFD for ; Tue, 12 Oct 2010 18:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.621 X-Spam-Level: **** X-Spam-Status: No, score=4.621 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, SARE_RECV_IP_061172=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoGCd8Wnk8aH for ; Tue, 12 Oct 2010 18:30:11 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id A2DD33A6AFA for ; Tue, 12 Oct 2010 18:30:11 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA700BRAG8E84@usaga01-in.huawei.com> for ccamp@ietf.org; Tue, 12 Oct 2010 18:31:26 -0700 (PDT) Received: from 179.130.173.61.broad.xw.sh.dynamic.163data.com.cn (179.130.173.61.broad.xw.sh.dynamic.163data.com.cn [61.173.130.179]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0LA7003HMG63RH@usaga01-in.huawei.com> for ccamp@ietf.org; Tue, 12 Oct 2010 18:31:26 -0700 (PDT) Date: Wed, 13 Oct 2010 09:29:14 +0800 From: Dan Li In-reply-to: To: Richard Graveman Message-id: <8EC0975D-27BF-45E5-9D63-059FB7623499@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.1081) Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable References: <20101011071502.7D0573A6903@core3.amsl.com> Cc: CCAMP Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lmp-behavior-negotiation-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2010 01:30:13 -0000 Hello Rich, Thanks your comments on this draft. With respect to "Security Consideration" section in this draft, our = intention is to describe the security implications and requirements of = this draft. As you know the basic security issues of LMP have been = addressed in RFC4204.=20 You have pointed out that some new mechanisms have been defined in the = newly published RFCs, I think "re-evaluation" of LMP security *could* = form the basis of a new draft. Honestly I don't know if I get your point, any specific modification = suggestions on this section? Thanks, Dan =D4=DA 2010-10-11=A3=AC=CF=C2=CE=E711:59=A3=AC Richard Graveman =D0=B4=B5=C0= =A3=BA > =C4=FA=BA=C3Dan=A3=AC >=20 > The Security Considerations of this draft section says that the > security in RFC 4204 is RECOMMENDED, so it may be worthwhile to go > back and look at that. >=20 > With one exception, IMO the recommendations in 4204 are sound, but > they are out of date. In particular: >=20 > 1. RFC 5996 makes a lot of the more complicated the text about Quick > Mode, Aggressive Mode, and DOI unnecessary. >=20 > 2. RFC 5840 may be a convenient improvement for some deployments. >=20 > 3. There is no discussion about NAT or an IPv4-IPv6 transition = environment. >=20 > 4. Newer cryptographic algorithms may be more secure and more = efficient. >=20 > Nevertheless, there may be cases where the old-style RFC-2401-based > IPsec is available but the new style RFC-4301-5996-based IPsec is not. >=20 > The Security Considerations section of this draft says something about > messages being intercepted. The confidentiality service of ESP can > mitigate that of course, but RFC 4204 proscribes confidentiality. This > seems rash to me. A statement that authentication, replay detection, > and integrity may be the most important security services in most case > suffices. Saying that confidentiality is not needed is making too many > assumptions about the operational environment. The situation may vary > from case to case. See also RFC 5920 for additional guidance. >=20 > Rich Graveman >=20 >=20 > 2010/10/11 Dan Li : >> Hi all, >>=20 >> As we have discussed during IETF 78th meeting in Masstricht, the = architecture bits are removed in this updated 01 version. >>=20 >> Please check out the updated = draft-ietf-ccamp-lmp-behavior-negotiation. Comments are always welcome! >>=20 >> Best regards, >>=20 >> Dan >>=20 >> =D4=DA 2010-10-11=A3=AC=CF=C2=CE=E73:15=A3=AC = Internet-Drafts@ietf.org =D0=B4=B5=C0=A3=BA >>=20 >>> 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. >>>=20 >>>=20 >>> Title : Behavior Negotiation in The Link Management = Protocol >>> Author(s) : D. Li, D. Ceccarelli >>> Filename : = draft-ietf-ccamp-lmp-behavior-negotiation-01.txt >>> Pages : 8 >>> Date : 2010-10-11 >>>=20 >>> The Link Management Protocol (LMP) is used to coordinate the >>> properties, use, and faults of data links in Generalized >>> Multiprotocol Label Switching (GMPLS) networks. Various proposals >>> have been advanced to provide extensions to the base LMP >>> specification. This document defines an extension to negotiated >>> capabilities and provides a generic procedure for LMP >>> implementations that do not recognize or do not support any one of >>> these extensions. >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-behavior-negotiat= ion-01.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> <=D3=CA=BC=FE=B8=BD=BC=FE>____________________________________________= ___ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >>=20 From root@core3.amsl.com Wed Oct 13 08:00:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 32B543A6981; Wed, 13 Oct 2010 08:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101013150002.32B543A6981@core3.amsl.com> Date: Wed, 13 Oct 2010 08:00:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-encode-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2010 15:00:02 -0000 --NextPart 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 Encoding for Wavelength Switched Optical Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-encode-06.txt Pages : 35 Date : 2010-10-13 A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are fairly specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-wson-encode-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-13075745.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Wed Oct 13 08:12:19 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8237F3A6B1D; Wed, 13 Oct 2010 08:12:19 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20101013151219.8237F3A6B1D@core3.amsl.com> Date: Wed, 13 Oct 2010 08:12:19 -0700 (PDT) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)' to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2010 15:12:19 -0000 The IESG has approved the following document: - 'Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt Technical Summary This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework [RFC5828] and describes the technology specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point to point (P2P) and point to multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. Working Group Summary Nothing of note. Document Quality There are no known implementations, but it is expected that several vendors plan to implement. Personnel Deborah Brungard (db3546@att.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. RFC Editor Note Section 4.1 OLD Note, PBB-TE is designed to be bidirectional and symmetrically routed just like Ethernet. That is, complete and proper functionality of Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In the following we discuss the establishment of bidirectional Eth-LSPs. Note however that it is also possible to use RSVP-TE to configure unidirectional ESPs, if the UPSTREAM_LABEL is not included in the PATH message. To initiate a bidirectional Eth-LSP, the initiator of the PATH message MUST use the procedures outlined in [RFC3473] with the following specifics: NEW PBB-TE is designed to be bidirectional and symmetrically routed just like Ethernet. That is, complete and proper functionality of Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In this section we discuss the establishment of bidirectional Eth-LSPs. Note, however, that it is also possible to use RSVP-TE to configure unidirectional ESPs, if the UPSTREAM_LABEL is not included in the PATH message. To initiate a bidirectional Eth-LSP, the initiator of the PATH message MUST use the procedures outlined in [RFC3473] with the following specifics: END --- Section 4.1.1 s/Eth LSP/Eth-LSP/ --- Section 5.1.2 OLD The destination bridge after receiving the PATH message has to allocate a VID, which together with its MAC address will constitute the PBB-TE Ethernet Label. Depending on the size of the allocated VLAN range and the number of Eth-LSPs terminated on a particular bridge, it is possible that the available VIDs are exhausted and hence no PBB-TE Ethernet Label can be allocated. In this case the destination bridge SHOULD generate a PathErr message with error code: Routing problem (24) and error value: MPLS Label allocation failure (9). NEW The destination bridge after receiving the PATH message has to assign a VID, which together with its MAC address will constitute the PBB-TE Ethernet Label. An existing VID may be reused when Shared forwarding is used or when there are no path conflicts otherwise the bridge has to allocate a VID. Depending on the size of the allocated VLAN range and the number of Eth-LSPs terminated on a particular bridge, it is possible that the available VIDs are exhausted and hence no PBB-TE Ethernet Label can be allocated. In this case the destination bridge SHOULD generate a PathErr message with error code: Routing problem (24) and error value: MPLS Label allocation failure (9). END --- Section 5.2 OLD IEEE defines a set of reserved MAC addresses Table 8-1 [IEEE 802.1Q] that have special meaning, processing and follow specific forwarding rules. NEW IEEE defines a set of reserved MAC addresses from 01-80-C2-00-00-00 to 01-80-C2-00-00-0F as explained in [IEEE 802.1Q] that have special meaning, processing, and follow specific forwarding rules. END --- Section 6 Acronym expansions UNI - User-to-Network Interface NNI - Network-to-Network Interface DOS - Denial of Service --- Section 6 OLD For a more comprehensive discussion on GMPLS security please see the Security Framework for MPLS and GMPLS Networks[RFC5920]. Cryptography can be used to protect against many attacks described in [RFC5920]. One option for protecting "transport" Ethernet is the use of 802.1AE Media Access Control Security, [MACSEC] which provides encryption and authentication." NEW Where control plane communications are point-to-point over links that employ 802.1AE Media Access Control Security [MACSEC], it may reasonably determined that no further security measures are used. In other cases, it is appropriate to use control plane security where it is deemed necessary to secure the signaling messages. GMPLS signaling security measures are described in [RFC3471] and [RFC3473], and inherit security techniques applicable to RSVP-TE as described in [RFC3209] and [RFC2205]. For a fuller overview of GMPLS security techniques see [RFC5920]. END --- Section 7 DELETE - Assign a new globally defined error value: "PBB-TE Ethernet Label VID allocation failure" (suggested value: 35?) under the "Routing problem" (24) error code in the RSVP Parameters / Error Codes and Globally-Defined Error Value Sub-Codes registry. END --- Section 7 OLD - Assign a new type from the Attributes TLV Space in the RSVP-TE Parameters registry (suggested value 2) for the Service ID TLV that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type = 1) [RFC5420]. NEW - Assign a new type from the Attributes TLV Space in the RSVP-TE Parameters registry (suggested value 2) for the Service ID TLV that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type = 1) [RFC5420]. Please reocrd this new type as follows: Name: I-SID Association TLV Allowed on LSP_ATTRIBUTES Yes Allowed on LSP_REQUIRED_ATTRIBUTES No END --- Section 8.1 ADD [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. --- Section 8.1 [RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery", RFC 4871, May 2007. s/4871/4872/ --- IANA Note IANA: Please note the two RFC Editor note changes to Section 7. From root@core3.amsl.com Wed Oct 13 08:15:03 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 025703A6B0D; Wed, 13 Oct 2010 08:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101013151503.025703A6B0D@core3.amsl.com> Date: Wed, 13 Oct 2010 08:15:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-general-constraint-encode-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2010 15:15:03 -0000 --NextPart 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 : General Network Element Constraint Encoding for GMPLS Controlled Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-general-constraint-encode-03.txt Pages : 29 Date : 2010-10-13 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-general-constraint-encode-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-general-constraint-encode-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-13081416.I-D@ietf.org> --NextPart-- From gregb@grotto-networking.com Wed Oct 13 08:51:00 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EBC3A6B5F for ; Wed, 13 Oct 2010 08:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mT+2AiHURAd for ; Wed, 13 Oct 2010 08:50:57 -0700 (PDT) Received: from mail32c40.carrierzone.com (mail32c40.carrierzone.com [209.235.156.172]) by core3.amsl.com (Postfix) with ESMTP id 5D2353A6A11 for ; Wed, 13 Oct 2010 08:50:57 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.124] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail32c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id o9DFqBDA005039 for ; Wed, 13 Oct 2010 11:52:12 -0400 Message-ID: <4CB5D5A9.4080707@grotto-networking.com> Date: Wed, 13 Oct 2010 08:52:09 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: CCAMP Content-Type: multipart/alternative; boundary="------------040009060004070809030806" X-CSC: 0 X-CHA: v=1.1 cv=+b7a8zcox5zRK4UWoLDmXkeAiBE42l067MPpBjoROmw= c=1 sm=1 a=zJgyWuvuOfAA:10 a=OkPnmgdRXU7//wtL+yd+jg==:17 a=48vgC7mUAAAA:8 a=AdxO-31kT74UCzf03bcA:9 a=D0YDw39sqbCZCoPjLhQHkT78PocA:4 a=wPNLvfGTeEIA:10 a=EgY3od2ZU2QA:10 a=h-I_03WOSDMA:10 a=MHodbUvn8hWqO7g-2IEA:9 a=k6F9XW5C6z7_5DMk-XkA:7 a=DVll7C_uqy2nSFMt4OMGRTKZmeIA:4 a=OkPnmgdRXU7//wtL+yd+jg==:117 Subject: [CCAMP] WSON documents ready for last call... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2010 15:51:00 -0000 This is a multi-part message in MIME format. --------------040009060004070809030806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPers, per the Maastricht meeting notes we've been preparing three CCAMP WG documents for last call: (a) WSON Info (draft-ietf-ccamp-rwa-info-09 ) (b) General Constraint Encoding (draft-ietf-ccamp-general-constraint-encode -03) (c) WSON RWA Encoding (draft-ietf-ccamp-rwa-wson-encode -06) We published the update to the WSON Info document over a month ago and queried this list for comments. We have now updated the General Constraint Encoding draft to align with the WSON Info model. In addition we have updated the WSON RWA Encoding draft per the Maastricht meeting notes to be more bit efficient with one of our encodings. From the document authors perspective we are ready for last call. Are there any outstanding comments? Best Regards Greg and co-authors -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------040009060004070809030806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi CCAMPers, per the Maastricht meeting notes we've been preparing three CCAMP WG documents for last call:
(a) WSON Info (draft-ietf-ccamp-rwa-info-09)
(b) General Constraint Encoding (draft-ietf-ccamp-general-constraint-encode-03)
(c) WSON RWA Encoding (draft-ietf-ccamp-rwa-wson-encode-06)

We published the update to the WSON Info document over a month ago and queried this list for comments. We have now updated the General Constraint Encoding draft to align with the WSON Info model. In addition we have updated the WSON RWA Encoding draft per the Maastricht meeting notes to be more bit efficient with one of our encodings.
From the document authors perspective we are ready for last call. Are there any outstanding comments?

Best Regards

Greg and co-authors
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------040009060004070809030806-- From rrao@infinera.com Wed Oct 13 14:39:19 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E4D3A66B4 for ; Wed, 13 Oct 2010 14:39: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipshwJ+1KM75 for ; Wed, 13 Oct 2010 14:39:17 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id 1F3E53A69DF for ; Wed, 13 Oct 2010 14:39:12 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Wed, 13 Oct 2010 14:39:53 -0700 From: Rajan Rao To: "ccamp@ietf.org" Date: Wed, 13 Oct 2010 14:39:33 -0700 Thread-Topic: OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: ActrHdiZI+Ac/40cQBur+suTIMHh2AAADSfw Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2010 21:39:19 -0000 SGksDQoNClRoZSBmb2xsb3dpbmcgZHJhZnQgaGFzIGJlZW4gc3VibWl0dGVkLiBQbGVhc2UgcmV2 aWV3LiBDb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWFzaG9rLWNjYW1wLWdtcGxzLW9zcGYtZzcwOS8NCg0KdGhhbmtzDQpB dXRob3JzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEktRCBTdWJt aXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDogV2VkbmVz ZGF5LCBPY3RvYmVyIDEzLCAyMDEwIDI6MzAgUE0NClRvOiBSYWphbiBSYW8NCkNjOiBTbmlnZGhv IEJhcmRhbGFpOyBBc2hvayBLdW5qaWRoYXBhdGhhbTsgS2h1emVtYSBQaXRoZXdhbg0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hc2hvay1jY2FtcC1nbXBscy1v c3BmLWc3MDktMDEgDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFzaG9rLWNjYW1w LWdtcGxzLW9zcGYtZzcwOS0wMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBSYWphbiBSYW8gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFt ZToJIGRyYWZ0LWFzaG9rLWNjYW1wLWdtcGxzLW9zcGYtZzcwOQ0KUmV2aXNpb246CSAwMQ0KVGl0 bGU6CQkgT1NQRiBURSBFeHRlbnNpb25zIGZvciBHZW5lcmFsaXplZCBNUExTIChHTVBMUykgQ29u dHJvbCBvZiBHLjcwOSBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3Jrcw0KQ3JlYXRpb25fZGF0ZToJ IDIwMTAtMTAtMTINCldHIElEOgkJIEluZGVwZW5kZW50IFN1Ym1pc3Npb24NCk51bWJlcl9vZl9w YWdlczogMjANCg0KQWJzdHJhY3Q6DQpBcyBPVE4gbmV0d29yayBjYXBhYmlsaXRpZXMgY29udGlu dWUgdG8gZXZvbHZlLCB0aGVyZSBpcyBhbiBpbmNyZWFzZWQNCm5lZWQgdG8gc3VwcG9ydCBHTVBM UyBjb250cm9sIGZvciB0aGUgc2FtZS4gW1JGQzQzMjhdIGludHJvZHVjZWQNCkdNUExTIHNpZ25h bGluZyBleHRlbnNpb25zIGZvciBzdXBwb3J0aW5nIHRoZSBlYXJseSB2ZXJzaW9uIG9mIEcuNzA5 DQpbRy43MDktdjFdLiBUaGUgYmFzaWMgcm91dGluZyBjb25zaWRlcmF0aW9ucyBmcm9tIHNpZ25h bGluZw0KcGVyc3BlY3RpdmUgaXMgYWxzbyBzcGVjaWZpZWQgaW4gW1JGQzQzMjhdLg0KDQpUaGUg cmVjZW50IHJldmlzaW9uIG9mIElUVS1UIFJlY29tbWVuZGF0aW9uIEcuNzA5IFtHLjcwOS12M10g YW5kDQpbR1NVUC40M10gaGF2ZSBpbnRyb2R1Y2VkIG5ldyBPRFUgY29udGFpbmVycyAoYm90aCBm aXhlZCBhbmQNCmZsZXhpYmxlKSBhbmQgYWRkaXRpb25hbCBPRFUgbXVsdGlwbGV4aW5nIGNhcGFi aWxpdGllcywgZW5hYmxpbmcNCnN1cHBvcnQgZm9yIG9wdGltYWwgc2VydmljZSBhZ2dyZWdhdGlv bi4gIA0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBPU1BGIHByb3RvY29sIGV4dGVuc2lvbnMg dG8gc3VwcG9ydA0KR2VuZXJhbGl6ZWQgTVBMUyAoR01QTFMpIGNvbnRyb2wgZm9yIHJvdXRpbmcg c2VydmljZXMgb3ZlciB0aGUNCnN0YW5kYXJkaXplZCBPVFUvT0RVIGNvbnRhaW5lcnMgaW4gc3Vw cG9ydCBvZiBPRFUgYmFzZWQgVERNDQpzd2l0Y2hpbmcuIFJvdXRpbmcgc3VwcG9ydCBmb3IgT3B0 aWNhbCBDaGFubmVsIExheWVyIHN3aXRjaGluZw0KKExhbWJkYSBzd2l0Y2hpbmcpIGlzIG5vdCBj b3ZlcmVkIGluIHRoaXMgZG9jdW1lbnQuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0K From Lyong@Ciena.com Thu Oct 14 07:44:01 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26423A68ED for ; Thu, 14 Oct 2010 07:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.862 X-Spam-Level: X-Spam-Status: No, score=-101.862 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UQTqopzSuik for ; Thu, 14 Oct 2010 07:44:00 -0700 (PDT) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id 97C163A68DB for ; Thu, 14 Oct 2010 07:44:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 10:44:30 -0400 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Importance: normal Thread-Index: ActrHdiZI+Ac/40cQBur+suTIMHh2AAADSfwACPdsWA= Priority: normal References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> From: "Ong, Lyndon" To: "Rajan Rao" , Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 14 Oct 2010 14:44:01 -0000 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would be helpful to understand if your draft is asking for similar extensions or different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreciated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01=20 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. =20 This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. =20 The IETF Secretariat. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Thu Oct 14 12:13:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1344C3A6AD6 for ; Thu, 14 Oct 2010 12:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.105 X-Spam-Level: X-Spam-Status: No, score=-101.105 tagged_above=-999 required=5 tests=[AWL=-1.254, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZF+agKjvkH6 for ; Thu, 14 Oct 2010 12:13:13 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 065363A69AF for ; Thu, 14 Oct 2010 12:13:12 -0700 (PDT) Received: (qmail 6488 invoked by uid 0); 14 Oct 2010 19:14:32 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 14 Oct 2010 19:14:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=vvLB9pJ4WSth7mCE3MIKxjnfZEFYqE1PKzSHX8SWvEjp3frzGi8RLiiKMMzbNDNz3ORI1HCYUX02qg7kyqJRXoXgwOL0+v4/7EhwD3Egqz7FDIHl33m6JlNVguBpdTXU; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1P6TG3-0007cu-Qd; Thu, 14 Oct 2010 13:14:31 -0600 Message-ID: <4CB75699.5050501@labn.net> Date: Thu, 14 Oct 2010 15:14:33 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP WG , CCAMP ADs Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] Request for input on draft-shiomoto-ccamp-switch-programming X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 14 Oct 2010 19:13:14 -0000 All, We have heard from the authors of http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 that they intend to publish this document as individuals rather than as a WG document. Given the lackluster interest in this document in the WG, we see no issue with the authors proceeding with an Independent submission. As this document is within the scope of the WG, the IESG is likely to only approve this document with CCAMPs agreement. Therefore, we ask that the all review this document and raise any comments you may have on this document by Monday, October 25. Note this is not a working last call, nor will there be one, as the document will be submitted as an Independent submission. Much thanks, Lou (and Deborah) From rrao@infinera.com Fri Oct 15 10:11:53 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150253A6B62 for ; Fri, 15 Oct 2010 10:11:53 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se4FnFHpQ8EB for ; Fri, 15 Oct 2010 10:11:48 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id CE3D43A6B85 for ; Fri, 15 Oct 2010 10:11:47 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.30]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Fri, 15 Oct 2010 10:12:48 -0700 From: Rajan Rao To: "Ong, Lyndon" , "ccamp@ietf.org" Date: Fri, 15 Oct 2010 10:12:51 -0700 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: ActrHdiZI+Ac/40cQBur+suTIMHh2AAADSfwACPdsWAANsiSMA== Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> In-Reply-To: <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2010 17:11:53 -0000 THluZG9uLA0KDQpZZXMsIHdlIGFyZSBhd2FyZSBvZiB0aGUgZXhpc3RpbmcgZHJhZnQuIFRoZXJl IGFyZSBzb21lIGZ1bmRhbWVudGFsIGRpZmZlcmVuY2VzIGluIHRoZSBtb2RlbCB3ZSBoYXZlIHBy b3Bvc2VkIGZyb20gdGhlIGV4aXN0aW5nIGRyYWZ0LiBUaGUga2V5IGRpZmZlcmVuY2VzIGFyZSB0 aGUgZm9sbG93aW5nOg0KIA0KMSkgVGhpcyBkcmFmdCBleHRlbmRzIGV4aXN0aW5nIElTQ0QgIFZz LiBkZWZpbmluZyBhIG5ldyBvbmUgDQogICAgLSBhZGRyZXNzZXMgYmFja3dhcmQgY29tcGF0aWJp bGl0eSBpc3N1ZXMgKFJGQyA0MjAyKQ0KDQoyKSBPRFUgY29udGFpbmVycyBhcmUgYWR2ZXJ0aXNl ZCBpbnN0ZWFkIG9mICNUU3MNCiAgICAgLSBzaW1wbGUgcGF0aCBjb21wdXRhdGlvbg0KDQozKSBQ YXRoIGNvbXB1dGluZyBub2RlIGRvZXNuJ3QgbmVlZCB0byBrbm93IHBlciBsaW5rIGFuZC9vciBw ZXIgT0RVIGxheWVyIFRTIGdyYW51bGFyaXR5DQogICAgIC0gYWdhaW4sIHNpbXBsZSAmIHN0cmFp Z2h0IGZvcndhcmQgcGF0aCBjb21wdXRhdGlvbiAgDQoNClRoYW5rcw0KUmFqYW4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9uZywgTHluZG9uIFttYWlsdG86THlvbmdAQ2ll bmEuY29tXSANClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE0LCAyMDEwIDc6NDUgQU0NClRvOiBS YWphbiBSYW87IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0NDQU1QXSBPU1BGLVRFIGV4 dGVuc2lvbnMgZm9yIEcuNzA5IE9UTiBkcmFmdCBzdWJtaXR0ZWQ6IGRyYWZ0LWFzaG9rLWNjYW1w LWdtcGxzLW9zcGYtZzcwOS0wMQ0KDQpIaSBSYWphbiwNCg0KSGF2ZSB5b3UgbG9va2VkIGF0IGRy YWZ0LWNlY2NhcmVsbGktY2NhbXAtZ21wbHMtb3NwZi1nNzA5LTAzLnR4dD8gIEl0DQp3b3VsZCBi ZSBoZWxwZnVsIHRvIHVuZGVyc3RhbmQgaWYgeW91ciBkcmFmdCBpcyBhc2tpbmcgZm9yIHNpbWls YXINCmV4dGVuc2lvbnMgb3IgZGlmZmVyZW50IGZ1bmN0aW9uYWxpdHkuDQoNClRoYW5rcywNCg0K THluZG9uDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0K T2YgUmFqYW4gUmFvDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTMsIDIwMTAgMjo0MCBQTQ0K VG86IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiBbQ0NBTVBdIE9TUEYtVEUgZXh0ZW5zaW9ucyBm b3IgRy43MDkgT1ROIGRyYWZ0IHN1Ym1pdHRlZDoNCmRyYWZ0LWFzaG9rLWNjYW1wLWdtcGxzLW9z cGYtZzcwOS0wMQ0KDQpIaSwNCg0KVGhlIGZvbGxvd2luZyBkcmFmdCBoYXMgYmVlbiBzdWJtaXR0 ZWQuIFBsZWFzZSByZXZpZXcuIENvbW1lbnRzIGFyZQ0KYXBwcmVjaWF0ZWQuDQoNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFzaG9rLWNjYW1wLWdtcGxzLW9zcGYtZzcw OS8NCg0KdGhhbmtzDQpBdXRob3JzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmdd IA0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEzLCAyMDEwIDI6MzAgUE0NClRvOiBSYWphbiBS YW8NCkNjOiBTbmlnZGhvIEJhcmRhbGFpOyBBc2hvayBLdW5qaWRoYXBhdGhhbTsgS2h1emVtYSBQ aXRoZXdhbg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KZHJhZnQtYXNo b2stY2NhbXAtZ21wbHMtb3NwZi1nNzA5LTAxIA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1hc2hvay1jY2FtcC1nbXBscy1vc3BmLWc3MDktMDEudHh0IGhhcyBiZWVuDQpzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IFJhamFuIFJhbyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z aXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtYXNob2stY2NhbXAtZ21wbHMtb3NwZi1nNzA5DQpS ZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBPU1BGIFRFIEV4dGVuc2lvbnMgZm9yIEdlbmVyYWxpemVk IE1QTFMgKEdNUExTKSBDb250cm9sDQpvZiBHLjcwOSBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3Jr cw0KQ3JlYXRpb25fZGF0ZToJIDIwMTAtMTAtMTINCldHIElEOgkJIEluZGVwZW5kZW50IFN1Ym1p c3Npb24NCk51bWJlcl9vZl9wYWdlczogMjANCg0KQWJzdHJhY3Q6DQpBcyBPVE4gbmV0d29yayBj YXBhYmlsaXRpZXMgY29udGludWUgdG8gZXZvbHZlLCB0aGVyZSBpcyBhbiBpbmNyZWFzZWQNCm5l ZWQgdG8gc3VwcG9ydCBHTVBMUyBjb250cm9sIGZvciB0aGUgc2FtZS4gW1JGQzQzMjhdIGludHJv ZHVjZWQNCkdNUExTIHNpZ25hbGluZyBleHRlbnNpb25zIGZvciBzdXBwb3J0aW5nIHRoZSBlYXJs eSB2ZXJzaW9uIG9mIEcuNzA5DQpbRy43MDktdjFdLiBUaGUgYmFzaWMgcm91dGluZyBjb25zaWRl cmF0aW9ucyBmcm9tIHNpZ25hbGluZw0KcGVyc3BlY3RpdmUgaXMgYWxzbyBzcGVjaWZpZWQgaW4g W1JGQzQzMjhdLg0KDQpUaGUgcmVjZW50IHJldmlzaW9uIG9mIElUVS1UIFJlY29tbWVuZGF0aW9u IEcuNzA5IFtHLjcwOS12M10gYW5kDQpbR1NVUC40M10gaGF2ZSBpbnRyb2R1Y2VkIG5ldyBPRFUg Y29udGFpbmVycyAoYm90aCBmaXhlZCBhbmQNCmZsZXhpYmxlKSBhbmQgYWRkaXRpb25hbCBPRFUg bXVsdGlwbGV4aW5nIGNhcGFiaWxpdGllcywgZW5hYmxpbmcNCnN1cHBvcnQgZm9yIG9wdGltYWwg c2VydmljZSBhZ2dyZWdhdGlvbi4gIA0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBPU1BGIHBy b3RvY29sIGV4dGVuc2lvbnMgdG8gc3VwcG9ydA0KR2VuZXJhbGl6ZWQgTVBMUyAoR01QTFMpIGNv bnRyb2wgZm9yIHJvdXRpbmcgc2VydmljZXMgb3ZlciB0aGUNCnN0YW5kYXJkaXplZCBPVFUvT0RV IGNvbnRhaW5lcnMgaW4gc3VwcG9ydCBvZiBPRFUgYmFzZWQgVERNDQpzd2l0Y2hpbmcuIFJvdXRp bmcgc3VwcG9ydCBmb3IgT3B0aWNhbCBDaGFubmVsIExheWVyIHN3aXRjaGluZw0KKExhbWJkYSBz d2l0Y2hpbmcpIGlzIG5vdCBjb3ZlcmVkIGluIHRoaXMgZG9jdW1lbnQuDQogDQoNCg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdC4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQo= From root@core3.amsl.com Fri Oct 15 12:00:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4013F3A6A2B; Fri, 15 Oct 2010 12:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101015190002.4013F3A6A2B@core3.amsl.com> Date: Fri, 15 Oct 2010 12:00:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-tp-cp-framework-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2010 19:00:02 -0000 --NextPart 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 : MPLS-TP Control Plane Framework Author(s) : L. Andersson, et al. Filename : draft-ietf-ccamp-mpls-tp-cp-framework-03.txt Pages : 54 Date : 2010-10-15 The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. MPLS-TP also uses the control plane for Pseudowires (PWs). Management plane functions such as manual configuration and the initiation of LSP setup are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-cp-framework-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-tp-cp-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-15115928.I-D@ietf.org> --NextPart-- From lberger@labn.net Fri Oct 15 12:13:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708603A694F for ; Fri, 15 Oct 2010 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ4tZt+IHKRv for ; Fri, 15 Oct 2010 12:13:31 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 384D43A693E for ; Fri, 15 Oct 2010 12:13:31 -0700 (PDT) Received: (qmail 10824 invoked by uid 0); 15 Oct 2010 19:14:53 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 15 Oct 2010 19:14:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=TuytqgIB9cENauLRC/Hdb5DZ0EOZSp6IToV2fuGcswRz7KetfB4YdBA355WywCL2McBcnD0ODouO11ZmgY1TeCFu3Vk0t+iqDutrveK7ssfedEx2aAa0z+zFGhE6diUh; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1P6pjw-0003pa-IU for ccamp@ietf.org; Fri, 15 Oct 2010 13:14:52 -0600 Message-ID: <4CB8A82F.7060707@labn.net> Date: Fri, 15 Oct 2010 15:14:55 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: ccamp@ietf.org References: <20101015190002.4013F3A6A2B@core3.amsl.com> In-Reply-To: <20101015190002.4013F3A6A2B@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Re: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-tp-cp-framework-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2010 19:13:34 -0000 On 10/15/2010 3:00 PM, Internet-Drafts@ietf.org wrote: > 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 : MPLS-TP Control Plane Framework > Author(s) : L. Andersson, et al. > Filename : draft-ietf-ccamp-mpls-tp-cp-framework-03.txt > Pages : 54 > Date : 2010-10-15 ... > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-cp-framework-03.txt ... All, We've updated draft-ietf-ccamp-mpls-tp-cp-framework to address last call comments. There a number of changes so we do expect a second last call on these changes. The major changes are as follows: -- Updated OAM Requirements section (2.3) to match current versions of [RFC5860] and [TP-OAM], and updated LSP/PW tables to match -- Added Section 2.5, Identifier Requirement based on [TP-IDENTIFIERS], and updated LSP/PW tables to match -- Addressed Liaison comments as listed below -- Addressed minor and editorial feedback -- Revised Editors list Lou (for document authors/editors) Responses to Liaison LS218, "Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02" are as follows. The authors expect this list to be used as the basis for a future Liaison response. ========================================================================= > [M1]Editorial: Add the boiler plate text on joint development This has been done. > [M2]Editorial: Add a note to the RFC editor that this Informational RFC > has been approved by the IETF consensus process. This has been done. > [M3]Path computation is normally out of scope for standards Although specific path computation algorithms are out of scope, the Path Computation function itself is in scope; see for example RFC 4655, "A Path Computation Element (PCE)-Based Architecture". > [M4]Data plane or control plane? The referenced text has been deleted. > [M5]RFC5654 says "The control plane for MPLS-TP MUST fit within the ASON > architecture", however, ASON CP and GMPLS don't include the control for > PW and the protocols identified for the PW control plane do not comply > with the ASON architecture. New explanatory text on this topic has been added to the document. > [M6]Current text implies that a control plane is always used for PWs. The scope of this document is the control plane for MPLS-TP, and the related mechanisms defined by IETF for this technology. As such, we believe the current phrasing is correct. > [M7]Add this text to the Abstract section as per comment M1. This text has been added. > [M8]This draft identifies the protocols for the control plane The existing text is correct because the MPLS-TP Framework and MPLS-TP Survivability Framework do limit the scope of protocols. > [M9]RFC5654 says "The control plane for MPLS-TP MUST fit within the ASON > architecture", however, ASON CP and GMPLS don't include the control for > PW and the protocols identified for the PW control plane do not comply > with the ASON architecture. This is a duplicate comment; see [M5] above. > [M10]RFC5654 says "The control plane for MPLS-TP MUST fit within the > ASON architecture", however, ASON CP and GMPLS don't include the control > for PW and the protocols identified for the PW control plane do not > comply with the ASON architecture. This is a duplicate comment; see [M5] above. > [M11]PW recovery is for further study The text in question has been removed. > [M12]TP-SURVIVE describes both protection and restoration Agreed. > [M13]Not exactly identical. See section 3.2 of [TP-FWK] We have aligned the text with Section 3.3 of RFC 5921. > [M14]A server layer must support traffic engineering. We have aligned the text with Section 3.3 of RFC 5921. > [M15]How is traffic engineering supported as per [RFC5654, requirement > 5] We have removed "as-is" from the sentence "MPLS PWs are used as-is by MPLS-TP...". > [M16]Draft-ietf-pwe3-ldp-aii-reachability extends LDP for the MS-PW > routing. So, LDP should also be added here. As LDP is already referred to in this narrative sentence, we believe the existing text is sufficient. > [M17]The currently defined control plane is for "general purpose" LSPs > the MPLS-TP control plane is for transport applications. GMPLS was defined to include, and has been applied to, transport applications, and thus we believe the existing text is correct. > [M18]ASTN is in old term that is no longer user Agreed; the reference to the term has been removed. > [M19]The requirements state: The MPLS-TP control plane design should as > far as reasonably possible reuse existing MPLS standards We agree. > [M20]Is the IETF precluded from adopting work already completed in other > standards bodies? This question is outside the scope of the specific text and this document. > [M21]The current GMPLS control plane does not include PWs. This is correct. We have added "LSP-related" in order to avoid misunderstanding. > [M22]A GMPLS control plane does not support merging The text in question has been removed. > [M23]The control plane requirements are provided in Section 2 of this > RFC. The text has been clarified. > [M24]MPLS-TP LSPs do not cross the UNI as defined in the MPLS-TP > Framework We do not see how this comment relates to the highlighted text. > [M25]Can the PW be between CEs, if so the T-LDP session should extend to > the CEs In the figure a CE PW would be carried over an LSP, so PW should not be listed as a client signal type; we have made the correction. > [M26]This figure is correct however it is inconsistent with the UNI and > NNI as defined in the recently published MPLS-TP framework. Is it > intended to publish a Bis for the overall framework to correct this > inconsistency? This figure shows the control plane representation of the UNI and NNI, not the internal node representation shown in the MPLS-TP Framework. > [M27]Where are the RSVP-TE sessions? We have clarified the figure. > [M28]T-LDP for PW label assignment Targeted LDP is a form of LDP. > [M29]Use of hierarchical LSP as SPME for OAM alters data plane > processing of particular LSP(s) to which the H-LSP been applied. Such > effect should be described. Discussions of data-plane processing are outside the scope of this document. This document covers the control plane of hierarchical LSPs, of which SPMEs are special cases. > [M30]TP-SURVIVE describes both protection and restoration. Restoration > has the most impact on the control plane. We have added "and restored" after "protected". > [M31]instantiation of the MIPs is optional. We have accepted the change. > [M32]Comments on Figure 1 also apply to figure 2. We have accepted the change. > [M33]Editorial We have accepted the change. > [M34]Address separation must added to LDP if this is used for PWs We have updated the text to clarify. > [M35]Reword to make the control plane implications clear e.g. The > control plane must make all nodes. We agree and have updated the text accordingly. > [M36]Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M37]Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M38]Independence of the management plane is outside the scope of this > draft. Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M39]Independence of the management plane is outside the scope of this > draft. Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M40]Independence of the management plane is outside the scope of this > draft. Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M41]Is this really a control plane requirement? Clarification is > needed. We have removed this item, as related requirements are already captured in 14 and 15. > [M42]To be consistent with RFC5654 Requirement, i.e., extra traffic is > not required in MPLS-TP. We believe the existing text is preferable as it aligns with the use of "MAY" in the referenced text of RFC 5654. > [M43]How does this support traffic engineering as per [RFC5654, > requirement 5] and the address separation requirements LDP is the foundation for the pseudowire control plane. Traffic engineering support for PWs is discussed in Section 5. > [M44]Better describe in 108, 109 and 124 The existing text parallels the text in RFC 5860. > [M45]This is not a control plane requirement This text has been rephrased to reflect the control plane requirement and for improved alignment with RFC 5860. > [M46]Not a control plane function This text has been rephrased to reflect the control plane requirement. > [M47]Not a control plane function This text has been rephrased to reflect the control plane requirement. > [M48]Should be reliable to support restoration the functions > identified should be independent of the control plane. The current text reuses the language of RFC 5860. > [M49]Repeat of 109 We are maintaining parallelism with the structure in RFC 5860. The text has been revised to better align with that document. > [M50]116-123 are all OAM functions that may be enabled by the control > plane as per requirement 109 This is correct. Also, we are maintaining parallelism with the structure in RFC 5860. The text has been revised to better align with that document. > [M51]Part of MEP/MIP configuration The current text is constructed to be aligned with [TP-OAM]. > [M52]How are SPMEs established for PWs (PW TCM). How is this > coordinated with LSP SPMEs. PW/LSP coordination is covered in Section 5.1. > [M53]Please clarify the use of the term "tunnel" in this context. The > MPLS-TP identifiers draft uses the term tunnel as a logical relationship > between node and is used to name LSPs. We have removed the text in question. > [M54]The relationship of management plane with respect to the transport > plane should be out of scope of this document. We agree. > [M55]Should define how the terms are used in the context of the MPLS-TP > control plane. We have revised the subsequent text accordingly. > [M56]Please clarify this: Is it on the same wavelength or in the same > fiber on a different wavelength. This depends on the technology / layer of switching being performed. At the optical layer it may be a different wavelength, at the TP layer it would be the same wavelength. > [M57]Most use an embedded communications channel but the selection of > the route for control/management traffic is independent for the > "associated data traffic" and hence is, in effect, out-of-band > independent topology. We have removed the sentence in question. > [M58]How is this different from Out-of-band in-fiber The difference is that the control plane uses the same node pairs but not the same links. > [M59]If it is in-fiber or aligned topology links are used, please > clarify what "alignment is not required" means in this context. It means simply that the independent topology case is a superset of the aligned topology case. > [M60]Addressing in the context of the MPLS-TP data plane is defined in > the MPLS-TP identifiers draft The text has been revised to better align with the TP identifier document. > [M61]Does "family" mean Format? Please clarify The term "address family", as in IPv4 or IPv6 address family, is commonly used in RFCs and is used here in the same sense. > [M62]See the identifiers draft. We agree with the reference. > [M63]Do you mean "The address space(s) of the control, management and > data planes used ..."? Yes, as well as the neighbor adjacencies in the respective planes. > [M64]RFC 4201 defines mechanism by which allocated label is valid across > all component links of given Link Bundle. Is this Link Bundle technique > as well applicable to MPLS-TP? The question relates to label allocation policy in the data plane and is therefore outside the scope of the control plane and this document. > [M65]Is this consistent with the Survivability framework? We have revised the text to better align with that document. > [M66]Not a control plane function This text now references the GMPLS definition of recovery, which includes this list. > [M67]Where is this defined? We have added references to [RFC4872] and [RFC4873]. > [M68]Should include MIP configuration We agree and have updated the text accordingly. > [M69]A routing sub section should be add here. It is essential for > MS-PW. Furthermore, the TE mechanism for MS-PW should be described This is covered in the last part of Section 5.1 and Section 5.3.4. > [M70]Specification for PW QoS, TE parameters, explicit route control and > OAM configuration (for MS-PW) should be provided These topics are covered in the following subsections. > [M71]Is this binding only for dynamic PW and dynamic LSP? What will it > be if a dynamic PW is bound to a static LSP and the reverse? We have updated the text to clarify. Note that the case of configured pseudowires is outside the scope of the control plane. > [M72]MS-PW recovery that is independent of LSP recovery should > considered. This would allow recovery in the event of a PE node > failure. As S-PEs and T-PEs are always co-located with LSP end points, we believe that the described case accurately reflects the MPLS-TP data plane. From lberger@labn.net Fri Oct 15 12:24:42 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5020E3A69F5 for ; Fri, 15 Oct 2010 12:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT4gTjLhXK6F for ; Fri, 15 Oct 2010 12:24:42 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 15C623A69F4 for ; Fri, 15 Oct 2010 12:24:42 -0700 (PDT) Received: (qmail 2581 invoked by uid 0); 15 Oct 2010 19:19:24 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 15 Oct 2010 19:19:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=qkYJxXyP2W3av7J8LSYHcFSAkv1skk3I6zvxFbgEp7Qi/To4hx6e9y6Qrb2DztWpFaQt8QOAsM+uiHsFia7TFDqACabbmElKwMqyxGc2VOss3GvlZkPbNMf0eV8TiGv+; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1P6poK-0005KX-3s; Fri, 15 Oct 2010 13:19:24 -0600 Message-ID: <4CB8A93E.5060600@labn.net> Date: Fri, 15 Oct 2010 15:19:26 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP , MPLS-TP , PWE3 References: <20101015190002.4013F3A6A2B@core3.amsl.com> In-Reply-To: <20101015190002.4013F3A6A2B@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Re: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-tp-cp-framework-03.txt (resend) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2010 19:24:42 -0000 [This is a resend to include the CCAMP, MPLS-TP, and PWE3 lists] On 10/15/2010 3:00 PM, Internet-Drafts@ietf.org wrote: > 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 : MPLS-TP Control Plane Framework > Author(s) : L. Andersson, et al. > Filename : draft-ietf-ccamp-mpls-tp-cp-framework-03.txt > Pages : 54 > Date : 2010-10-15 ... > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-cp-framework-03.txt ... All, We've updated draft-ietf-ccamp-mpls-tp-cp-framework to address last call comments. There a number of changes so we do expect a second last call on these changes. The major changes are as follows: -- Updated OAM Requirements section (2.3) to match current versions of [RFC5860] and [TP-OAM], and updated LSP/PW tables to match -- Added Section 2.5, Identifier Requirement based on [TP-IDENTIFIERS], and updated LSP/PW tables to match -- Addressed Liaison comments as listed below -- Addressed minor and editorial feedback -- Revised Editors list Lou (for document authors/editors) Responses to Liaison LS218, "Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02" are as follows. The authors expect this list to be used as the basis for a future Liaison response. ========================================================================= > [M1]Editorial: Add the boiler plate text on joint development This has been done. > [M2]Editorial: Add a note to the RFC editor that this Informational RFC > has been approved by the IETF consensus process. This has been done. > [M3]Path computation is normally out of scope for standards Although specific path computation algorithms are out of scope, the Path Computation function itself is in scope; see for example RFC 4655, "A Path Computation Element (PCE)-Based Architecture". > [M4]Data plane or control plane? The referenced text has been deleted. > [M5]RFC5654 says "The control plane for MPLS-TP MUST fit within the ASON > architecture", however, ASON CP and GMPLS don't include the control for > PW and the protocols identified for the PW control plane do not comply > with the ASON architecture. New explanatory text on this topic has been added to the document. > [M6]Current text implies that a control plane is always used for PWs. The scope of this document is the control plane for MPLS-TP, and the related mechanisms defined by IETF for this technology. As such, we believe the current phrasing is correct. > [M7]Add this text to the Abstract section as per comment M1. This text has been added. > [M8]This draft identifies the protocols for the control plane The existing text is correct because the MPLS-TP Framework and MPLS-TP Survivability Framework do limit the scope of protocols. > [M9]RFC5654 says "The control plane for MPLS-TP MUST fit within the ASON > architecture", however, ASON CP and GMPLS don't include the control for > PW and the protocols identified for the PW control plane do not comply > with the ASON architecture. This is a duplicate comment; see [M5] above. > [M10]RFC5654 says "The control plane for MPLS-TP MUST fit within the > ASON architecture", however, ASON CP and GMPLS don't include the control > for PW and the protocols identified for the PW control plane do not > comply with the ASON architecture. This is a duplicate comment; see [M5] above. > [M11]PW recovery is for further study The text in question has been removed. > [M12]TP-SURVIVE describes both protection and restoration Agreed. > [M13]Not exactly identical. See section 3.2 of [TP-FWK] We have aligned the text with Section 3.3 of RFC 5921. > [M14]A server layer must support traffic engineering. We have aligned the text with Section 3.3 of RFC 5921. > [M15]How is traffic engineering supported as per [RFC5654, requirement > 5] We have removed "as-is" from the sentence "MPLS PWs are used as-is by MPLS-TP...". > [M16]Draft-ietf-pwe3-ldp-aii-reachability extends LDP for the MS-PW > routing. So, LDP should also be added here. As LDP is already referred to in this narrative sentence, we believe the existing text is sufficient. > [M17]The currently defined control plane is for "general purpose" LSPs > the MPLS-TP control plane is for transport applications. GMPLS was defined to include, and has been applied to, transport applications, and thus we believe the existing text is correct. > [M18]ASTN is in old term that is no longer user Agreed; the reference to the term has been removed. > [M19]The requirements state: The MPLS-TP control plane design should as > far as reasonably possible reuse existing MPLS standards We agree. > [M20]Is the IETF precluded from adopting work already completed in other > standards bodies? This question is outside the scope of the specific text and this document. > [M21]The current GMPLS control plane does not include PWs. This is correct. We have added "LSP-related" in order to avoid misunderstanding. > [M22]A GMPLS control plane does not support merging The text in question has been removed. > [M23]The control plane requirements are provided in Section 2 of this > RFC. The text has been clarified. > [M24]MPLS-TP LSPs do not cross the UNI as defined in the MPLS-TP > Framework We do not see how this comment relates to the highlighted text. > [M25]Can the PW be between CEs, if so the T-LDP session should extend to > the CEs In the figure a CE PW would be carried over an LSP, so PW should not be listed as a client signal type; we have made the correction. > [M26]This figure is correct however it is inconsistent with the UNI and > NNI as defined in the recently published MPLS-TP framework. Is it > intended to publish a Bis for the overall framework to correct this > inconsistency? This figure shows the control plane representation of the UNI and NNI, not the internal node representation shown in the MPLS-TP Framework. > [M27]Where are the RSVP-TE sessions? We have clarified the figure. > [M28]T-LDP for PW label assignment Targeted LDP is a form of LDP. > [M29]Use of hierarchical LSP as SPME for OAM alters data plane > processing of particular LSP(s) to which the H-LSP been applied. Such > effect should be described. Discussions of data-plane processing are outside the scope of this document. This document covers the control plane of hierarchical LSPs, of which SPMEs are special cases. > [M30]TP-SURVIVE describes both protection and restoration. Restoration > has the most impact on the control plane. We have added "and restored" after "protected". > [M31]instantiation of the MIPs is optional. We have accepted the change. > [M32]Comments on Figure 1 also apply to figure 2. We have accepted the change. > [M33]Editorial We have accepted the change. > [M34]Address separation must added to LDP if this is used for PWs We have updated the text to clarify. > [M35]Reword to make the control plane implications clear e.g. The > control plane must make all nodes. We agree and have updated the text accordingly. > [M36]Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M37]Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M38]Independence of the management plane is outside the scope of this > draft. Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M39]Independence of the management plane is outside the scope of this > draft. Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M40]Independence of the management plane is outside the scope of this > draft. Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M41]Is this really a control plane requirement? Clarification is > needed. We have removed this item, as related requirements are already captured in 14 and 15. > [M42]To be consistent with RFC5654 Requirement, i.e., extra traffic is > not required in MPLS-TP. We believe the existing text is preferable as it aligns with the use of "MAY" in the referenced text of RFC 5654. > [M43]How does this support traffic engineering as per [RFC5654, > requirement 5] and the address separation requirements LDP is the foundation for the pseudowire control plane. Traffic engineering support for PWs is discussed in Section 5. > [M44]Better describe in 108, 109 and 124 The existing text parallels the text in RFC 5860. > [M45]This is not a control plane requirement This text has been rephrased to reflect the control plane requirement and for improved alignment with RFC 5860. > [M46]Not a control plane function This text has been rephrased to reflect the control plane requirement. > [M47]Not a control plane function This text has been rephrased to reflect the control plane requirement. > [M48]Should be reliable to support restoration the functions > identified should be independent of the control plane. The current text reuses the language of RFC 5860. > [M49]Repeat of 109 We are maintaining parallelism with the structure in RFC 5860. The text has been revised to better align with that document. > [M50]116-123 are all OAM functions that may be enabled by the control > plane as per requirement 109 This is correct. Also, we are maintaining parallelism with the structure in RFC 5860. The text has been revised to better align with that document. > [M51]Part of MEP/MIP configuration The current text is constructed to be aligned with [TP-OAM]. > [M52]How are SPMEs established for PWs (PW TCM). How is this > coordinated with LSP SPMEs. PW/LSP coordination is covered in Section 5.1. > [M53]Please clarify the use of the term "tunnel" in this context. The > MPLS-TP identifiers draft uses the term tunnel as a logical relationship > between node and is used to name LSPs. We have removed the text in question. > [M54]The relationship of management plane with respect to the transport > plane should be out of scope of this document. We agree. > [M55]Should define how the terms are used in the context of the MPLS-TP > control plane. We have revised the subsequent text accordingly. > [M56]Please clarify this: Is it on the same wavelength or in the same > fiber on a different wavelength. This depends on the technology / layer of switching being performed. At the optical layer it may be a different wavelength, at the TP layer it would be the same wavelength. > [M57]Most use an embedded communications channel but the selection of > the route for control/management traffic is independent for the > "associated data traffic" and hence is, in effect, out-of-band > independent topology. We have removed the sentence in question. > [M58]How is this different from Out-of-band in-fiber The difference is that the control plane uses the same node pairs but not the same links. > [M59]If it is in-fiber or aligned topology links are used, please > clarify what "alignment is not required" means in this context. It means simply that the independent topology case is a superset of the aligned topology case. > [M60]Addressing in the context of the MPLS-TP data plane is defined in > the MPLS-TP identifiers draft The text has been revised to better align with the TP identifier document. > [M61]Does "family" mean Format? Please clarify The term "address family", as in IPv4 or IPv6 address family, is commonly used in RFCs and is used here in the same sense. > [M62]See the identifiers draft. We agree with the reference. > [M63]Do you mean "The address space(s) of the control, management and > data planes used ..."? Yes, as well as the neighbor adjacencies in the respective planes. > [M64]RFC 4201 defines mechanism by which allocated label is valid across > all component links of given Link Bundle. Is this Link Bundle technique > as well applicable to MPLS-TP? The question relates to label allocation policy in the data plane and is therefore outside the scope of the control plane and this document. > [M65]Is this consistent with the Survivability framework? We have revised the text to better align with that document. > [M66]Not a control plane function This text now references the GMPLS definition of recovery, which includes this list. > [M67]Where is this defined? We have added references to [RFC4872] and [RFC4873]. > [M68]Should include MIP configuration We agree and have updated the text accordingly. > [M69]A routing sub section should be add here. It is essential for > MS-PW. Furthermore, the TE mechanism for MS-PW should be described This is covered in the last part of Section 5.1 and Section 5.3.4. > [M70]Specification for PW QoS, TE parameters, explicit route control and > OAM configuration (for MS-PW) should be provided These topics are covered in the following subsections. > [M71]Is this binding only for dynamic PW and dynamic LSP? What will it > be if a dynamic PW is bound to a static LSP and the reverse? We have updated the text to clarify. Note that the case of configured pseudowires is outside the scope of the control plane. > [M72]MS-PW recovery that is independent of LSP recovery should > considered. This would allow recovery in the event of a PE node > failure. As S-PEs and T-PEs are always co-located with LSP end points, we believe that the described case accurately reflects the MPLS-TP data plane. From lamberto.sterling@gmail.com Sun Oct 17 01:57:46 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1DD43A68BC; Sun, 17 Oct 2010 01:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTAlSKWtxmFr; Sun, 17 Oct 2010 01:57:45 -0700 (PDT) Received: from mail-bw0-f66.google.com (mail-bw0-f66.google.com [209.85.214.66]) by core3.amsl.com (Postfix) with ESMTP id 6D2B83A6778; Sun, 17 Oct 2010 01:57:44 -0700 (PDT) Received: by bwz6 with SMTP id 6so1048313bwz.1 for ; Sun, 17 Oct 2010 01:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5rYkcVKulDx52a9Dn2exeMyHSxSpvCv/p1KBaNaXh5Y=; b=QkjrRdkmVapaKo/TNxza0ul4V+FrYnliUKhJfVk8sftcMUEFq3M3mxiPeTIYmQ55Tt Uh1c3YYtuL/OQ/PtCOk2ktKA/t5pZ9iBbVuDCWBFKO997sCZS8ohatZWP+bNjtp6pG1R DaVOjdPuh42WCWknHRqlp3DsTZHDYwbigZv3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fZUG6pGgmP4DIknxa/OnONr5exP6q9mesRwwTfbFDC/PKWFS8BvQf4cAdOc3xv99gh gnTSbxQpnklbnDGMM/9BQHFBBWUo7EZW+R8/kGHT/xWm4sghU0A51rOyPu7aMiHwuX6M GYIkXRSM2SfQ66gQSufjzXoddo37SezdbhjUk= MIME-Version: 1.0 Received: by 10.204.68.67 with SMTP id u3mr2916214bki.199.1287305944680; Sun, 17 Oct 2010 01:59:04 -0700 (PDT) Received: by 10.204.72.15 with HTTP; Sun, 17 Oct 2010 01:59:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Oct 2010 16:59:04 +0800 Message-ID: From: Lamberto Sterling To: zhang.fei3@zte.com.cn Content-Type: multipart/alternative; boundary=00504502d81a8cc9060492cc45f5 Cc: mpls@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] Collecting comments on associated bidirectional LSP X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 17 Oct 2010 08:57:46 -0000 --00504502d81a8cc9060492cc45f5 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Fei, See in line, thanks. Cheers Lamberto 2010/9/25 > > Hi Sterling > > Sorry for the delayed response, I am on vacation. See in line > > Kind regards > > Fei > > > *Sterling Lamberto * > > 2010-09-12 09:25 > =CA=D5=BC=FE=C8=CB > zhang.fei3@zte.com.cn > =B3=AD=CB=CD > mpls-tp@ietf.org, ccamp@ietf.org, mpls@ietf.org > =D6=F7=CC=E2 > Re: [mpls] Collecting comments on associated bidirectional LSP > > > > > Hi Fei, > After a brief review of the draft, there are several points: > 1. section 4.1, point 3, why node B sends PATH message of LSP2 with > ASSOCIATION object with same value as that of LSP1? It seems a bit stran= ge, > what's your consideration about that? > > ZF:It is in accordance with RFC4872, based on the same value, the two LSP= s > can be bound together > Lamberto: OK, I see. > > 2. in section 4.2 peer mode, what if the backward LSP has been already > setup before setting up the forward LSP? In that case, if backward LSP > without ASSOCIATION object does not wish to be bound, how to handle that > case? > > ZF: Actually I do not consider the situation that the backward LSP does n= ot > wish to be bound in the 00 version of this draft. It can be handled in > accordance with the first operation mode. That is to say, if Association > object is carried, it can be bound; if not carried, can not be bound. Lamberto: I do not agree. It is very likely that the backward LSP is a normal LSP that does not support the association feature described in this draft, the the bind mechanism will break with one end binding successfully and one end binding failure. The backward LSP should also carry the association object to indicate its ability and tunnel id it wishes to bind. > > > 3. will asymmetric bandwidth allocation for associated LSP be described i= n > future draft? > > ZF: Yeah, this will be added > Lamberto: I don't mean to add it. I am interested with the scenario. Can yo= u list some? > > Lamberto. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Hi all, > > Associated bidirectional LSP, defined in RFC5654, is useful for protectio= n > switching, for OAM that requires a reply (from MIP or MEP), and for defec= t > correlation. > > There are potentially several solutions, such as GMPLS call, the > Association object, and the LSP_TUNNEL_INTERFACE_ID object. Furthermore, = the > scheme based on the extensions to > > the Association object has been presented in IETF77, and there are some > discussions on the mailinglist. > > We need to receive more comments on this topic to push this work forward, > then update the document, > * > ** > http://tools.ietf.org/html/draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-= 00 > *, > which is recently expired. > > Any comments are welome. > > B.R. > > Fei > > :) > --00504502d81a8cc9060492cc45f5 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Fei,
See in line, thanks.
 
Cheers
Lamberto

2010/9/25 <zhang.fei3@zte.com.cn>

Hi Sterling

So= rry for the delayed response, I am on vacation. See in line

Kind regards

Fei


Sterling Lamberto= <lambe= rto.sterling@gmail.com>

2010-09-12 09:25

=
=CA=D5=BC=FE=C8= =CB
zhang.fei3@zte.com.cn=20
=B3=AD=CB=CD
mpls-tp@ietf.org, ccamp@ietf.org, mpls@ietf.org=20
=D6=F7=CC=E2
Re: [mpls] Collecting comments on = associated bidirectional LSP




Hi Fei,
After a brief review of the draft, there are several points:=
1. section 4.1, point 3, why node B sends P= ATH message of LSP2 with ASSOCIATION object with same  value as t= hat of LSP1? It seems a bit strange, what's your consideration about th= at?

ZF:It is in accordance with RFC4872, based on th= e same value, the two LSPs can be bound together
Lamberto: OK, I see.

2. in section 4.2 peer mode, what if= the backward LSP has been already setup before setting up the forward LSP?= In that case, if backward LSP without ASSOCIATION object does not wis= h to be bound, how to handle that case?

ZF: Actually I do not consider the situation tha= t the backward LSP does not wish to be bound in the 00 version of this draf= t. It can be handled in accordance with the first operation mode. That is t= o say, if Association object is carried, it can be bound; if not carried, c= an not be bound.
Lamberto: I do not agree. It is very likely that the backward LSP is a= normal LSP that does not support the association feature described in this= draft, the the bind mechanism will break with one end binding successfully= and one end binding failure. The backward LSP should also carry the associ= ation object to indicate its ability and tunnel id it wishes to bind.


3. will asymmetric bandwidth allocat= ion for associated LSP be described in future draft?

<= font size=3D"3">ZF: Yeah, this will be added
Lamberto: I don't mean to add it. I am interested with the scenari= o. Can you list some?
 
Lambe= rto.
 
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Hi all,

Associated bidirectional LS= P, defined in RFC5654, is useful for protection= switching, for OAM that requires a reply (from MIP or MEP), and for defect= correlation.

There are potentially several solutions, su= ch as GMPLS call, the Association object, and the LSP_TUNNEL_INTERFACE_ID o= bject. Furthermore, the scheme based on the extensions to

the Association object has been presented i= n IETF77, and there are some discussions on the mailinglist.

We need to receive more = comments on this topic to push this work forward, then update the document,=

http://tools= .ietf.org/html/draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-00, which is recently expired.

Any comments are welome.

B.R.

Fei

:)
<= br> --00504502d81a8cc9060492cc45f5-- From zhang.fei3@zte.com.cn Sun Oct 17 19:53:26 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDE03A6973; Sun, 17 Oct 2010 19:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.634 X-Spam-Level: X-Spam-Status: No, score=-95.634 tagged_above=-999 required=5 tests=[AWL=2.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMhUatKY3sKJ; Sun, 17 Oct 2010 19:53:25 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 79BBB3A6C3C; Sun, 17 Oct 2010 19:53:24 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205952043691617; Mon, 18 Oct 2010 10:52:05 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 55813.2806151920; Mon, 18 Oct 2010 10:54:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9I2sXAf042135; Mon, 18 Oct 2010 10:54:34 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Lamberto Sterling MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 18 Oct 2010 10:54:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-18 10:54:26, Serialize complete at 2010-10-18 10:54:26 Content-Type: multipart/alternative; boundary="=_alternative 00101142482577C0_=" X-MAIL: mse2.zte.com.cn o9I2sXAf042135 Cc: mpls@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] Collecting comments on associated bidirectional LSP X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 18 Oct 2010 02:53:27 -0000 This is a multipart message in MIME format. --=_alternative 00101142482577C0_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgbGFtYmVydG8NCg0KU2VlIGluIGxpbmUuLi4NCg0KS2luZCByZWdhcmRzDQoNCkZlaSA6KQ0K DQoNCg0KTGFtYmVydG8gU3RlcmxpbmcgPGxhbWJlcnRvLnN0ZXJsaW5nQGdtYWlsLmNvbT4gDQoy MDEwLTEwLTE3IDE2OjU5DQoNCsrVvP7Iyw0KemhhbmcuZmVpM0B6dGUuY29tLmNuDQqzrcvNDQpt cGxzLXRwQGlldGYub3JnLCBjY2FtcEBpZXRmLm9yZywgbXBsc0BpZXRmLm9yZw0K1vfM4g0KUmU6 IFttcGxzXSBDb2xsZWN0aW5nIGNvbW1lbnRzIG9uIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBM U1ANCg0KDQoNCg0KDQoNCkhpIEZlaSwNClNlZSBpbiBsaW5lLCB0aGFua3MuDQogDQpDaGVlcnMN CkxhbWJlcnRvDQoNCjIwMTAvOS8yNSA8emhhbmcuZmVpM0B6dGUuY29tLmNuPg0KDQpIaSBTdGVy bGluZyANCg0KU29ycnkgZm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlLCBJIGFtIG9uIHZhY2F0aW9u LiBTZWUgaW4gbGluZSANCg0KS2luZCByZWdhcmRzIA0KDQpGZWkgDQoNCg0KU3RlcmxpbmcgTGFt YmVydG8gPGxhbWJlcnRvLnN0ZXJsaW5nQGdtYWlsLmNvbT4gDQoyMDEwLTA5LTEyIDA5OjI1IA0K DQoNCsrVvP7Iyw0KemhhbmcuZmVpM0B6dGUuY29tLmNuIA0Ks63LzQ0KbXBscy10cEBpZXRmLm9y ZywgY2NhbXBAaWV0Zi5vcmcsIG1wbHNAaWV0Zi5vcmcgDQrW98ziDQpSZTogW21wbHNdIENvbGxl Y3RpbmcgY29tbWVudHMgb24gYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUA0KDQoNCg0KDQoN Cg0KDQoNCg0KSGkgRmVpLCANCkFmdGVyIGEgYnJpZWYgcmV2aWV3IG9mIHRoZSBkcmFmdCwgdGhl cmUgYXJlIHNldmVyYWwgcG9pbnRzOiANCjEuIHNlY3Rpb24gNC4xLCBwb2ludCAzLCB3aHkgbm9k ZSBCIHNlbmRzIFBBVEggbWVzc2FnZSBvZiBMU1AyIHdpdGggDQpBU1NPQ0lBVElPTiBvYmplY3Qg d2l0aCBzYW1lICB2YWx1ZSBhcyB0aGF0IG9mIExTUDE/IEl0IHNlZW1zIGEgYml0IA0Kc3RyYW5n ZSwgd2hhdCdzIHlvdXIgY29uc2lkZXJhdGlvbiBhYm91dCB0aGF0PyANCg0KWkY6SXQgaXMgaW4g YWNjb3JkYW5jZSB3aXRoIFJGQzQ4NzIsIGJhc2VkIG9uIHRoZSBzYW1lIHZhbHVlLCB0aGUgdHdv IExTUHMgDQpjYW4gYmUgYm91bmQgdG9nZXRoZXIgDQpMYW1iZXJ0bzogT0ssIEkgc2VlLg0KDQoy LiBpbiBzZWN0aW9uIDQuMiBwZWVyIG1vZGUsIHdoYXQgaWYgdGhlIGJhY2t3YXJkIExTUCBoYXMg YmVlbiBhbHJlYWR5IA0Kc2V0dXAgYmVmb3JlIHNldHRpbmcgdXAgdGhlIGZvcndhcmQgTFNQPyBJ biB0aGF0IGNhc2UsIGlmIGJhY2t3YXJkIExTUCANCndpdGhvdXQgQVNTT0NJQVRJT04gb2JqZWN0 IGRvZXMgbm90IHdpc2ggdG8gYmUgYm91bmQsIGhvdyB0byBoYW5kbGUgdGhhdCANCmNhc2U/IA0K DQpaRjogQWN0dWFsbHkgSSBkbyBub3QgY29uc2lkZXIgdGhlIHNpdHVhdGlvbiB0aGF0IHRoZSBi YWNrd2FyZCBMU1AgZG9lcyANCm5vdCB3aXNoIHRvIGJlIGJvdW5kIGluIHRoZSAwMCB2ZXJzaW9u IG9mIHRoaXMgZHJhZnQuIEl0IGNhbiBiZSBoYW5kbGVkIGluIA0KYWNjb3JkYW5jZSB3aXRoIHRo ZSBmaXJzdCBvcGVyYXRpb24gbW9kZS4gVGhhdCBpcyB0byBzYXksIGlmIEFzc29jaWF0aW9uIA0K b2JqZWN0IGlzIGNhcnJpZWQsIGl0IGNhbiBiZSBib3VuZDsgaWYgbm90IGNhcnJpZWQsIGNhbiBu b3QgYmUgYm91bmQuIA0KDQpMYW1iZXJ0bzogSSBkbyBub3QgYWdyZWUuIEl0IGlzIHZlcnkgbGlr ZWx5IHRoYXQgdGhlIGJhY2t3YXJkIExTUCBpcyBhIA0Kbm9ybWFsIExTUCB0aGF0IGRvZXMgbm90 IHN1cHBvcnQgdGhlIGFzc29jaWF0aW9uIGZlYXR1cmUgZGVzY3JpYmVkIGluIHRoaXMgDQpkcmFm dCwgdGhlIHRoZSBiaW5kIG1lY2hhbmlzbSB3aWxsIGJyZWFrIHdpdGggb25lIGVuZCBiaW5kaW5n IHN1Y2Nlc3NmdWxseSANCmFuZCBvbmUgZW5kIGJpbmRpbmcgZmFpbHVyZS4gVGhlIGJhY2t3YXJk IExTUCBzaG91bGQgYWxzbyBjYXJyeSB0aGUgDQphc3NvY2lhdGlvbiBvYmplY3QgdG8gaW5kaWNh dGUgaXRzIGFiaWxpdHkgYW5kIHR1bm5lbCBpZCBpdCB3aXNoZXMgdG8gDQpiaW5kLg0KIA0KIFpG OiBJbiBvcmRlciB0byBiZSBpbiBhY2NvcmRhbmNlIHdpdGggZHJhZnQtaWV0Zi1jY2FtcC1hc3Nv Yy1pbmZvLTAwLnR4dCwgDQphbmQgZG8gbm90IG5lZWQgdG8gaW50cm9kdWNlIHRoZSBuZXcgYXNz b2NpYXRpb24gcnVsZXMsIEkgaGF2ZSBkZWxldGVkIA0KdGhpcyBvcGVyYXRpb24gbW9kZSBpbiAw MSB2ZXJzaW9uLiBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIGJhY2t3YXJkIExTUCANCnNob3Vs ZCBhbHNvIGNhcnJ5IHRoZSBhc3NvY2lhdGlvbiBvYmplY3QgdG8gaW5kaWNhdGUgaXRzIGFiaWxp dHkuIEJ1dCBpZiANCndlIGRvIHRoaXMsIHRoaXMgb3BlcmF0aW9uIGhhdmUgbm8gYWR2YW50YWdl cyBjb21wYXJlZCB0byB0aGUgZmlyc3QgDQpvcGVhcmF0aW9uIG1vZGUsIGZ1cnRoZXJtb3JlLCBp dCBpbmNyZWFzZXMgdGhlIGJsb2NraW5nIHByb2JhYmlsaXR5IHRvIA0Kc2V0dXAgYXNzb2NpYXRl ZCBiaWRpcmVjdGlvbmFsIExTUCBzdWNjZXNzZnVsbHkgKHRoZSBpbmdyZXNzIG5vZGVzIGRvIG5v dCANCmtub3cgd2hpY2ggdHVubmVsIGFuZC9vciBMU1AgSURzIG9mIHRoZSBlZ3Jlc3Mgbm9kZXMg YXJlIHVub2NjdXBpZWQpLiANCg0KDQozLiB3aWxsIGFzeW1tZXRyaWMgYmFuZHdpZHRoIGFsbG9j YXRpb24gZm9yIGFzc29jaWF0ZWQgTFNQIGJlIGRlc2NyaWJlZCBpbiANCmZ1dHVyZSBkcmFmdD8g DQoNClpGOiBZZWFoLCB0aGlzIHdpbGwgYmUgYWRkZWQgDQpMYW1iZXJ0bzogSSBkb24ndCBtZWFu IHRvIGFkZCBpdC4gSSBhbSBpbnRlcmVzdGVkIHdpdGggdGhlIHNjZW5hcmlvLiBDYW4gDQp5b3Ug bGlzdCBzb21lPw0KDQpaRjogQWNjb3JkaW5nIHRvIFJGQzU2NTQ6IDE0ICBNUExTLVRQIE1VU1Qg c3VwcG9ydCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCANCnBhdGhzIHdpdGggYXN5bW1ldHJpYyBi YW5kd2lkdGggcmVxdWlyZW1lbnRzLCBpLmUuLCB0aGUgYW1vdW50IG9mIHJlc2VydmVkIA0KYmFu ZHdpZHRoDQogICAgZGlmZmVycyBiZXR3ZWVuIHRoZSBmb3J3YXJkIGFuZCBiYWNrd2FyZCBkaXJl Y3Rpb25zLiBIZXJlIA0KYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aHMgaW5jbHVkZSBjb3Jv dXRlZCBhbmQgYXNzb2NpYXRlZCANCmJpZGlyZWN0aW9uYWwgTFNQcy4gDQpBcyB0byB0aGUgc2Nl bmFyaW9zLCBqdXN0IG15IHR3byBjZW50cy4NCigxKUludGVybmV0IHNlcnZpY2UsIHRoZSBiYW5k d2lkdGggcmVxdWlyZW1lbnRzIG9mIHVwc3RyZWFtIGFuZCBkb3duc3RyZWFtIA0KZGlyZWN0aW9u IGFyZSBkaWZmZXJlbnQuDQooMikgRm9yIHNvbWUgT0FNIG1lc3NhZ2UsIHN1Y2ggYXMgTFNQIHBp bmcgb3IgQkZELCB0aGV5IFNIT1VMRCBoYXZlIHRoZSANCnJldmVyc2UgcmV0dXJuIHBhdGggd2hp Y2gncyBiYW5kd2lkdGggTUFZIGJlIHNtYWxsZXIgdGhhbiB0aGUgZm9yd2FyZCANCmRpcmVjdGlv bi4NCiANCiANCkxhbWJlcnRvLiANCiANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0gDQpIaSBhbGwsIA0KDQpBc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwgTFNQLCBkZWZpbmVkIGluIFJGQzU2NTQsIGlzIHVzZWZ1bCBmb3IgcHJvdGVjdGlv biANCnN3aXRjaGluZywgZm9yIE9BTSB0aGF0IHJlcXVpcmVzIGEgcmVwbHkgKGZyb20gTUlQIG9y IE1FUCksIGFuZCBmb3IgZGVmZWN0IA0KY29ycmVsYXRpb24uIA0KDQpUaGVyZSBhcmUgcG90ZW50 aWFsbHkgc2V2ZXJhbCBzb2x1dGlvbnMsIHN1Y2ggYXMgR01QTFMgY2FsbCwgdGhlIA0KQXNzb2Np YXRpb24gb2JqZWN0LCBhbmQgdGhlIExTUF9UVU5ORUxfSU5URVJGQUNFX0lEIG9iamVjdC4gRnVy dGhlcm1vcmUsIA0KdGhlIHNjaGVtZSBiYXNlZCBvbiB0aGUgZXh0ZW5zaW9ucyB0byANCg0KdGhl IEFzc29jaWF0aW9uIG9iamVjdCBoYXMgYmVlbiBwcmVzZW50ZWQgaW4gSUVURjc3LCBhbmQgdGhl cmUgYXJlIHNvbWUgDQpkaXNjdXNzaW9ucyBvbiB0aGUgbWFpbGluZ2xpc3QuIA0KDQpXZSBuZWVk IHRvIHJlY2VpdmUgbW9yZSBjb21tZW50cyBvbiB0aGlzIHRvcGljIHRvIHB1c2ggdGhpcyB3b3Jr IGZvcndhcmQsIA0KdGhlbiB1cGRhdGUgdGhlIGRvY3VtZW50LCANCg0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNw LTAwDQosIHdoaWNoIGlzIHJlY2VudGx5IGV4cGlyZWQuIA0KDQpBbnkgY29tbWVudHMgYXJlIHdl bG9tZS4gDQoNCkIuUi4gDQoNCkZlaSANCg0KOikgDQoNCg0K --=_alternative 00101142482577C0_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGxhbWJlcnRvPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TZWUgaW4gbGluZS4uLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+S2luZCByZWdh cmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWkg Oik8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ TGFtYmVydG8gU3RlcmxpbmcgJmx0O2xhbWJlcnRvLnN0ZXJsaW5nQGdtYWlsLmNvbSZndDs8L2I+ DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0xMC0xNyAx Njo1OTwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj56aGFuZy5mZWkzQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm1wbHMtdHBAaWV0 Zi5vcmcsIGNjYW1wQGlldGYub3JnLCBtcGxzQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW21wbHNdIENvbGxlY3RpbmcgY29tbWVudHMgb24gYXNzb2NpYXRlZA0KYmlkaXJlY3Rpb25h bCBMU1A8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+SGkgRmVpLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+U2VlIGluIGxpbmUsIHRoYW5rcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+Q2hlZXJzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj5MYW1iZXJ0bzxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+MjAxMC85LzI1ICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhbmcuZmVpM0B6 dGUuY29tLmNuPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pnpo YW5nLmZlaTNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQpIaSBTdGVybGluZzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KU29ycnkgZm9y IHRoZSBkZWxheWVkIHJlc3BvbnNlLCBJIGFtIG9uIHZhY2F0aW9uLiBTZWUgaW4gbGluZTwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCktpbmQgcmVnYXJkczwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KRmVpPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4g PGJyPg0KPGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlN0ZXJsaW5nIExhbWJlcnRvICZsdDs8L2I+PC9m b250PjxhIGhyZWY9bWFpbHRvOmxhbWJlcnRvLnN0ZXJsaW5nQGdtYWlsLmNvbSB0YXJnZXQ9X2Js YW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PmxhbWJl cnRvLnN0ZXJsaW5nQGdtYWlsLmNvbTwvdT48L2I+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4yMDEwLTA5LTEyIDA5OjI1PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZD4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxhIGhyZWY9bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNv bS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1PnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rp dj4NCjx0ZD48YSBocmVmPSJtYWlsdG86bXBscy10cEBpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz48 Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5tcGxzLXRwQGlldGYu b3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiwNCjwvZm9u dD48YSBocmVmPW1haWx0bzpjY2FtcEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9 MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PmNjYW1wQGlldGYub3JnPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiwNCjwvZm9udD48YSBocmVmPW1h aWx0bzptcGxzQGlldGYub3JnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUg ZmFjZT0ic2Fucy1zZXJpZiI+PHU+bXBsc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxzXSBD b2xsZWN0aW5nIGNvbW1lbnRzIG9uIGFzc29jaWF0ZWQNCmJpZGlyZWN0aW9uYWwgTFNQPC9mb250 PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTQ5JT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj4NCjx0ZD48L3Rh YmxlPg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjxicj4N CkhpIEZlaSwgPGJyPg0KQWZ0ZXIgYSBicmllZiByZXZpZXcgb2YgdGhlIGRyYWZ0LCB0aGVyZSBh cmUgc2V2ZXJhbCBwb2ludHM6IDxicj4NCjEuIHNlY3Rpb24gNC4xLCBwb2ludCAzLCB3aHkgbm9k ZSBCIHNlbmRzIFBBVEggbWVzc2FnZSBvZiBMU1AyIHdpdGggQVNTT0NJQVRJT04NCm9iamVjdCB3 aXRoIHNhbWUgJm5ic3A7dmFsdWUgYXMgdGhhdCBvZiBMU1AxPyBJdCBzZWVtcyBhIGJpdCBzdHJh bmdlLCB3aGF0J3MNCnlvdXIgY29uc2lkZXJhdGlvbiBhYm91dCB0aGF0PyA8YnI+DQo8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlpGOkl0IGlzIGluIGFjY29yZGFu Y2Ugd2l0aCBSRkM0ODcyLA0KYmFzZWQgb24gdGhlIHNhbWUgdmFsdWUsIHRoZSB0d28gTFNQcyBj YW4gYmUgYm91bmQgdG9nZXRoZXIgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj5MYW1iZXJ0bzogT0ssIEkgc2VlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KMi4gaW4gc2VjdGlvbiA0LjIgcGVlciBtb2RlLCB3aGF0IGlm IHRoZSBiYWNrd2FyZCBMU1AgaGFzIGJlZW4gYWxyZWFkeQ0Kc2V0dXAgYmVmb3JlIHNldHRpbmcg dXAgdGhlIGZvcndhcmQgTFNQPyBJbiB0aGF0IGNhc2UsIGlmIGJhY2t3YXJkIExTUA0Kd2l0aG91 dCBBU1NPQ0lBVElPTiBvYmplY3QgZG9lcyBub3Qgd2lzaCB0byBiZSBib3VuZCwgaG93IHRvIGhh bmRsZSB0aGF0DQpjYXNlPyA8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPlpGOiBBY3R1YWxseSBJIGRvIG5vdCBjb25zaWRlciB0aGUgc2l0dWF0aW9uDQp0 aGF0IHRoZSBiYWNrd2FyZCBMU1AgZG9lcyBub3Qgd2lzaCB0byBiZSBib3VuZCBpbiB0aGUgMDAg dmVyc2lvbiBvZiB0aGlzDQpkcmFmdC4gSXQgY2FuIGJlIGhhbmRsZWQgaW4gYWNjb3JkYW5jZSB3 aXRoIHRoZSBmaXJzdCBvcGVyYXRpb24gbW9kZS4gVGhhdA0KaXMgdG8gc2F5LCBpZiBBc3NvY2lh dGlvbiBvYmplY3QgaXMgY2FycmllZCwgaXQgY2FuIGJlIGJvdW5kOyBpZiBub3QgY2FycmllZCwN CmNhbiBub3QgYmUgYm91bmQuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+TGFtYmVydG86IEkgZG8gbm90IGFncmVlLiBJdCBpcyB2ZXJ5DQpsaWtlbHkg dGhhdCB0aGUgYmFja3dhcmQgTFNQIGlzIGEgbm9ybWFsIExTUCB0aGF0IGRvZXMgbm90IHN1cHBv cnQgdGhlDQphc3NvY2lhdGlvbiBmZWF0dXJlIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0LCB0aGUg dGhlIGJpbmQgbWVjaGFuaXNtIHdpbGwNCmJyZWFrIHdpdGggb25lIGVuZCBiaW5kaW5nIHN1Y2Nl c3NmdWxseSBhbmQgb25lIGVuZCBiaW5kaW5nIGZhaWx1cmUuIFRoZQ0KYmFja3dhcmQgTFNQIHNo b3VsZCBhbHNvIGNhcnJ5IHRoZSBhc3NvY2lhdGlvbiBvYmplY3QgdG8gaW5kaWNhdGUgaXRzIGFi aWxpdHkNCmFuZCB0dW5uZWwgaWQgaXQgd2lzaGVzIHRvIGJpbmQuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO1pGOiBJbiBvcmRlciB0byBiZSBpbiBhY2NvcmRhbmNl DQp3aXRoIDwvZm9udD48Zm9udCBzaXplPTM+PHR0PmRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtaW5m by0wMC50eHQ8L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+LA0KYW5k IGRvIG5vdCBuZWVkIHRvIGludHJvZHVjZSB0aGUgbmV3IGFzc29jaWF0aW9uIHJ1bGVzLCBJIGhh dmUgZGVsZXRlZA0KdGhpcyBvcGVyYXRpb24gbW9kZSBpbiAwMSB2ZXJzaW9uLiBJIGFncmVlIHdp dGggeW91IHRoYXQgdGhlIGJhY2t3YXJkIExTUA0Kc2hvdWxkIGFsc28gY2FycnkgdGhlIGFzc29j aWF0aW9uIG9iamVjdCB0byBpbmRpY2F0ZSBpdHMgYWJpbGl0eS4gQnV0IGlmDQp3ZSBkbyB0aGlz LCB0aGlzIG9wZXJhdGlvbiBoYXZlIG5vIGFkdmFudGFnZXMgY29tcGFyZWQgdG8gdGhlIGZpcnN0 IG9wZWFyYXRpb24NCm1vZGUsIGZ1cnRoZXJtb3JlLCBpdCBpbmNyZWFzZXMgdGhlIGJsb2NraW5n IHByb2JhYmlsaXR5IHRvIHNldHVwIGFzc29jaWF0ZWQNCmJpZGlyZWN0aW9uYWwgTFNQIHN1Y2Nl c3NmdWxseSAodGhlIGluZ3Jlc3Mgbm9kZXMgZG8gbm90IGtub3cgd2hpY2ggdHVubmVsDQphbmQv b3IgTFNQIElEcyBvZiB0aGUgZWdyZXNzIG5vZGVzIGFyZSB1bm9jY3VwaWVkKS4gJm5ic3A7PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQozLiB3 aWxsIGFzeW1tZXRyaWMgYmFuZHdpZHRoIGFsbG9jYXRpb24gZm9yIGFzc29jaWF0ZWQgTFNQIGJl IGRlc2NyaWJlZA0KaW4gZnV0dXJlIGRyYWZ0PyA8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlpGOiBZZWFoLCB0aGlzIHdpbGwgYmUgYWRkZWQgPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5MYW1iZXJ0bzogSSBkb24ndCBt ZWFuIHRvIGFkZCBpdC4gSQ0KYW0gaW50ZXJlc3RlZCB3aXRoIHRoZSBzY2VuYXJpby4gQ2FuIHlv dSBsaXN0IHNvbWU/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj5aRjogQWNjb3JkaW5nIHRvIFJGQzU2NTQ6IDE0ICZuYnNwO01QTFMtVFANCk1VU1Qgc3Vw cG9ydCBiaWRpcmVjdGlvbmFsIHRyYW5zcG9ydCBwYXRocyB3aXRoIGFzeW1tZXRyaWMgYmFuZHdp ZHRoIHJlcXVpcmVtZW50cywNCmkuZS4sIHRoZSBhbW91bnQgb2YgcmVzZXJ2ZWQgYmFuZHdpZHRo PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 IGRpZmZlcnMgYmV0d2VlbiB0aGUgZm9yd2FyZA0KYW5kIGJhY2t3YXJkIGRpcmVjdGlvbnMuIEhl cmUgYmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQgcGF0aHMgaW5jbHVkZSBjb3JvdXRlZA0KYW5kIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPkFzIHRvIHRoZSBzY2VuYXJpb3MsIGp1c3QgbXkgdHdvIGNlbnRzLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+KDEpSW50ZXJuZXQgc2Vy dmljZSwgdGhlIGJhbmR3aWR0aCByZXF1aXJlbWVudHMNCm9mIHVwc3RyZWFtIGFuZCBkb3duc3Ry ZWFtIGRpcmVjdGlvbiBhcmUgZGlmZmVyZW50LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+KDIpIEZvciBzb21lIE9BTSBtZXNzYWdlLCBzdWNoIGFzIExTUA0KcGlu ZyBvciBCRkQsIHRoZXkgU0hPVUxEIGhhdmUgdGhlIHJldmVyc2UgcmV0dXJuIHBhdGggd2hpY2gn cyBiYW5kd2lkdGgNCk1BWSBiZSBzbWFsbGVyIHRoYW4gdGhlIGZvcndhcmQgZGlyZWN0aW9uLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgPGJyPg0KTGFtYmVydG8u IDxicj4NCiAmbmJzcDs8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09IDxicj4NCkhpIGFsbCwgPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQpBc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQ LCBkZWZpbmVkIGluIFJGQzU2NTQsIGlzIHVzZWZ1bCBmb3I8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0 dD4NCnByb3RlY3Rpb24gc3dpdGNoaW5nLCBmb3IgT0FNIHRoYXQgcmVxdWlyZXMgYSByZXBseSAo ZnJvbSBNSVAgb3IgTUVQKSwNCmFuZCBmb3IgZGVmZWN0IGNvcnJlbGF0aW9uLiA8YnI+DQo8YnI+ DQpUaGVyZSBhcmUgcG90ZW50aWFsbHkgc2V2ZXJhbCBzb2x1dGlvbnMsIHN1Y2ggYXMgR01QTFMg Y2FsbCwgdGhlIEFzc29jaWF0aW9uDQpvYmplY3QsIGFuZCB0aGUgTFNQX1RVTk5FTF9JTlRFUkZB Q0VfSUQgb2JqZWN0LiBGdXJ0aGVybW9yZSwgdGhlIHNjaGVtZQ0KYmFzZWQgb24gdGhlIGV4dGVu c2lvbnMgdG88L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9u dD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCjxicj4NCnRoZSBBc3NvY2lhdGlvbiBvYmplY3QgaGFz IGJlZW4gcHJlc2VudGVkIGluIElFVEY3NywgYW5kIHRoZXJlIGFyZSBzb21lDQpkaXNjdXNzaW9u cyBvbiB0aGUgbWFpbGluZ2xpc3QuIDxicj4NCjxicj4NCldlIG5lZWQgdG8gcmVjZWl2ZSBtb3Jl IGNvbW1lbnRzIG9uIHRoaXMgdG9waWMgdG8gcHVzaCB0aGlzIHdvcmsgZm9yd2FyZCwNCnRoZW4g dXBkYXRlIHRoZSBkb2N1bWVudCwgPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+ PHR0Pjx1Pjxicj4NCjwvdT48L3R0PjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxz cC0wMCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+PHU+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctbXBscy10cC1yc3ZwdGUtZXh0LWFzc29j aWF0ZWQtbHNwLTAwPC91PjwvdHQ+PC9mb250PjwvYT48Zm9udCBzaXplPTI+PHR0PiwNCndoaWNo IGlzIHJlY2VudGx5IGV4cGlyZWQuPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQo8YnI+DQpBbnkgY29tbWVudHMg YXJlIHdlbG9tZS48L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwv Zm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCjxicj4NCkIuUi48L3R0PjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCjxi cj4NCkZlaSA8YnI+DQo8YnI+DQo6KTwvdHQ+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4gPC9mb250Pg0KPGJyPg0KPGJyPg0K --=_alternative 00101142482577C0_=-- From giomarti@cisco.com Mon Oct 18 05:14:01 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A61F3A6DA1 for ; Mon, 18 Oct 2010 05:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.523 X-Spam-Level: X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[AWL=-2.925, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKg92vPyQ1Fc for ; Mon, 18 Oct 2010 05:13:59 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 798E73A6D71 for ; Mon, 18 Oct 2010 05:13:57 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOfWu0yQ/khMgWdsb2JhbACBRJ9nFQEBFiIioHmcC4MOgjsEiko X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208,217";a="11525272" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 18 Oct 2010 12:15:25 +0000 Received: from mnza1-dhcp-vl301-144-254-166-69.cisco.com (mnza1-dhcp-vl301-144-254-166-69.cisco.com [144.254.166.69]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o9ICFO17026120; Mon, 18 Oct 2010 12:15:24 GMT Message-ID: <4CBC3A5F.50907@cisco.com> Date: Mon, 18 Oct 2010 14:15:27 +0200 From: Giovanni Martinelli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Greg Bernstein References: <4CB5D5A9.4080707@grotto-networking.com> In-Reply-To: <4CB5D5A9.4080707@grotto-networking.com> Content-Type: multipart/alternative; boundary="------------070208050003060307020807" Cc: CCAMP Subject: Re: [CCAMP] WSON documents ready for last call... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 18 Oct 2010 12:14:01 -0000 This is a multi-part message in MIME format. --------------070208050003060307020807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Greg, from my side there are no outstanding comments and docs are in a very good state. My only concern is to progress more on protocol extension drafts before going through a last call. At least I see this need because protocol implementation might provide feedback to information model (different information) and encoding (different tlv/sub-tlv layout) so requiring updates on these documents. Here my thought, may be others on the list have different opinion. Cheers G On 10/13/10 5:52 PM, Greg Bernstein wrote: > Hi CCAMPers, per the Maastricht meeting notes we've been preparing > three CCAMP WG documents for last call: > (a) WSON Info (draft-ietf-ccamp-rwa-info-09 > ) > (b) General Constraint Encoding > (draft-ietf-ccamp-general-constraint-encode > -03) > (c) WSON RWA Encoding (draft-ietf-ccamp-rwa-wson-encode > -06) > > We published the update to the WSON Info document over a month ago and > queried this list for comments. We have now updated the General > Constraint Encoding draft to align with the WSON Info model. In > addition we have updated the WSON RWA Encoding draft per the > Maastricht meeting notes to be more bit efficient with one of our > encodings. > From the document authors perspective we are ready for last call. Are > there any outstanding comments? > > Best Regards > > Greg and co-authors > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp --------------070208050003060307020807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Greg,

from my side there are no outstanding comments and docs are in a very good state. My only concern is to progress more on protocol extension drafts before going  through a last call.

At least I see this need because protocol implementation might provide feedback to  information model (different information)  and  encoding (different tlv/sub-tlv layout) so requiring updates on these documents.

Here my thought, may be others on the list have different opinion.

Cheers
G

On 10/13/10 5:52 PM, Greg Bernstein wrote:
Hi CCAMPers, per the Maastricht meeting notes we've been preparing three CCAMP WG documents for last call:
(a) WSON Info (draft-ietf-ccamp-rwa-info-09)
(b) General Constraint Encoding (draft-ietf-ccamp-general-constraint-encode-03)
(c) WSON RWA Encoding (draft-ietf-ccamp-rwa-wson-encode-06)

We published the update to the WSON Info document over a month ago and queried this list for comments. We have now updated the General Constraint Encoding draft to align with the WSON Info model. In addition we have updated the WSON RWA Encoding draft per the Maastricht meeting notes to be more bit efficient with one of our encodings.
From the document authors perspective we are ready for last call. Are there any outstanding comments?

Best Regards

Greg and co-authors
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237



_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--------------070208050003060307020807-- From db3546@att.com Tue Oct 19 07:15:19 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822E63A6840; Tue, 19 Oct 2010 07:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.307 X-Spam-Level: X-Spam-Status: No, score=-106.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIAxP9npLLmq; Tue, 19 Oct 2010 07:15:14 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id D21D83A6832; Tue, 19 Oct 2010 07:15:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-11.tower-146.messagelabs.com!1287497667!32104362!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 13332 invoked from network); 19 Oct 2010 14:14:27 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Oct 2010 14:14:27 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9JEDnfH015987; Tue, 19 Oct 2010 10:13:50 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9JEDm9s015951; Tue, 19 Oct 2010 10:13:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Oct 2010 10:14:23 -0400 Message-ID: In-Reply-To: <4CB8A93E.5060600@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call on draft-ietf-ccamp-mpls-tp-cp-framework-03.txt Thread-Index: ActsnesEusnoCKnhSMOXa4hilpSylwC+Nspg References: <20101015190002.4013F3A6A2B@core3.amsl.com> <4CB8A93E.5060600@labn.net> From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" , "MPLS-TP" , "PWE3" , Subject: [CCAMP] Last Call on draft-ietf-ccamp-mpls-tp-cp-framework-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2010 14:15:20 -0000 Thanks authors. This begins a second Last Call. The Last Call ends on Nov. 9th. Please send comments (limited to updates) to the ccamp and pwe3 lists. Thanks, CCAMP Co-Chairs, PWE3 Co-Chairs, MPLS Co-Chairs -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, October 15, 2010 3:19 PM To: CCAMP; MPLS-TP; PWE3 Subject: Re: [mpls-tp] [CCAMP] I-D Action:draft-ietf-ccamp-mpls-tp-cp-framework-03.txt (resend) [This is a resend to include the CCAMP, MPLS-TP, and PWE3 lists] On 10/15/2010 3:00 PM, Internet-Drafts@ietf.org wrote: > 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 : MPLS-TP Control Plane Framework > Author(s) : L. Andersson, et al. > Filename : draft-ietf-ccamp-mpls-tp-cp-framework-03.txt > Pages : 54 > Date : 2010-10-15 ... > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-cp-framewor k-03.txt ... All, We've updated draft-ietf-ccamp-mpls-tp-cp-framework to address last=20 call comments. There a number of changes so we do expect a second last=20 call on these changes. The major changes are as follows: -- Updated OAM Requirements section (2.3) to match current versions of [RFC5860] and [TP-OAM], and updated LSP/PW tables to match -- Added Section 2.5, Identifier Requirement based on [TP-IDENTIFIERS], and updated LSP/PW tables to match -- Addressed Liaison comments as listed below -- Addressed minor and editorial feedback -- Revised Editors list Lou (for document authors/editors) Responses to Liaison LS218, "Comments on draft-ietf-ccamp-mpls-tp-cp-framework-02" are as follows. The authors=20 expect this list to be used as the basis for a future Liaison response. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D > [M1]Editorial: Add the boiler plate text on joint development This has been done. > [M2]Editorial: Add a note to the RFC editor that this Informational RFC > has been approved by the IETF consensus process. This has been done. > [M3]Path computation is normally out of scope for standards Although specific path computation algorithms are out of scope, the Path Computation function itself is in scope; see for example RFC 4655, "A Path Computation Element (PCE)-Based Architecture". > [M4]Data plane or control plane? The referenced text has been deleted. > [M5]RFC5654 says "The control plane for MPLS-TP MUST fit within the ASON > architecture", however, ASON CP and GMPLS don't include the control for > PW and the protocols identified for the PW control plane do not comply > with the ASON architecture. New explanatory text on this topic has been added to the document. > [M6]Current text implies that a control plane is always used for PWs. The scope of this document is the control plane for MPLS-TP, and the related mechanisms defined by IETF for this technology. As such, we believe the current phrasing is correct. > [M7]Add this text to the Abstract section as per comment M1. This text has been added. > [M8]This draft identifies the protocols for the control plane The existing text is correct because the MPLS-TP Framework and MPLS-TP Survivability Framework do limit the scope of protocols. > [M9]RFC5654 says "The control plane for MPLS-TP MUST fit within the ASON > architecture", however, ASON CP and GMPLS don't include the control for > PW and the protocols identified for the PW control plane do not comply > with the ASON architecture. This is a duplicate comment; see [M5] above. > [M10]RFC5654 says "The control plane for MPLS-TP MUST fit within the > ASON architecture", however, ASON CP and GMPLS don't include the control > for PW and the protocols identified for the PW control plane do not > comply with the ASON architecture. This is a duplicate comment; see [M5] above. > [M11]PW recovery is for further study The text in question has been removed. > [M12]TP-SURVIVE describes both protection and restoration Agreed. > [M13]Not exactly identical. See section 3.2 of [TP-FWK] We have aligned the text with Section 3.3 of RFC 5921. > [M14]A server layer must support traffic engineering. We have aligned the text with Section 3.3 of RFC 5921. > [M15]How is traffic engineering supported as per [RFC5654, requirement > 5] We have removed "as-is" from the sentence "MPLS PWs are used as-is by MPLS-TP...". > [M16]Draft-ietf-pwe3-ldp-aii-reachability extends LDP for the MS-PW > routing. So, LDP should also be added here. As LDP is already referred to in this narrative sentence, we believe the existing text is sufficient. > [M17]The currently defined control plane is for "general purpose" LSPs > the MPLS-TP control plane is for transport applications. GMPLS was defined to include, and has been applied to, transport applications, and thus we believe the existing text is correct. > [M18]ASTN is in old term that is no longer user Agreed; the reference to the term has been removed. > [M19]The requirements state: The MPLS-TP control plane design should as > far as reasonably possible reuse existing MPLS standards We agree. > [M20]Is the IETF precluded from adopting work already completed in other > standards bodies? This question is outside the scope of the specific text and this document. > [M21]The current GMPLS control plane does not include PWs. This is correct. We have added "LSP-related" in order to avoid misunderstanding. > [M22]A GMPLS control plane does not support merging The text in question has been removed. > [M23]The control plane requirements are provided in Section 2 of this > RFC. The text has been clarified. > [M24]MPLS-TP LSPs do not cross the UNI as defined in the MPLS-TP > Framework We do not see how this comment relates to the highlighted text. > [M25]Can the PW be between CEs, if so the T-LDP session should extend to > the CEs In the figure a CE PW would be carried over an LSP, so PW should not be listed as a client signal type; we have made the correction. > [M26]This figure is correct however it is inconsistent with the UNI and > NNI as defined in the recently published MPLS-TP framework. Is it > intended to publish a Bis for the overall framework to correct this > inconsistency? This figure shows the control plane representation of the UNI and NNI, not the internal node representation shown in the MPLS-TP Framework. > [M27]Where are the RSVP-TE sessions? We have clarified the figure. > [M28]T-LDP for PW label assignment Targeted LDP is a form of LDP. > [M29]Use of hierarchical LSP as SPME for OAM alters data plane > processing of particular LSP(s) to which the H-LSP been applied. Such > effect should be described. Discussions of data-plane processing are outside the scope of this document. This document covers the control plane of hierarchical LSPs, of which SPMEs are special cases. > [M30]TP-SURVIVE describes both protection and restoration. Restoration > has the most impact on the control plane. We have added "and restored" after "protected". > [M31]instantiation of the MIPs is optional. We have accepted the change. > [M32]Comments on Figure 1 also apply to figure 2. We have accepted the change. > [M33]Editorial We have accepted the change. > [M34]Address separation must added to LDP if this is used for PWs We have updated the text to clarify. > [M35]Reword to make the control plane implications clear e.g. The > control plane must make all nodes. We agree and have updated the text accordingly. > [M36]Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M37]Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M38]Independence of the management plane is outside the scope of this > draft. Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M39]Independence of the management plane is outside the scope of this > draft. Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M40]Independence of the management plane is outside the scope of this > draft. Reword to make the control plane implications clear We agree and have updated the text accordingly. > [M41]Is this really a control plane requirement? Clarification is > needed. We have removed this item, as related requirements are already captured in 14 and 15. > [M42]To be consistent with RFC5654 Requirement, i.e., extra traffic is > not required in MPLS-TP. We believe the existing text is preferable as it aligns with the use of "MAY" in the referenced text of RFC 5654. > [M43]How does this support traffic engineering as per [RFC5654, > requirement 5] and the address separation requirements LDP is the foundation for the pseudowire control plane. Traffic engineering support for PWs is discussed in Section 5. > [M44]Better describe in 108, 109 and 124 The existing text parallels the text in RFC 5860. > [M45]This is not a control plane requirement This text has been rephrased to reflect the control plane requirement and for improved alignment with RFC 5860. > [M46]Not a control plane function This text has been rephrased to reflect the control plane requirement. > [M47]Not a control plane function This text has been rephrased to reflect the control plane requirement. > [M48]Should be reliable to support restoration the functions > identified should be independent of the control plane. The current text reuses the language of RFC 5860. > [M49]Repeat of 109 We are maintaining parallelism with the structure in RFC 5860. The text has been revised to better align with that document. > [M50]116-123 are all OAM functions that may be enabled by the control > plane as per requirement 109 This is correct. Also, we are maintaining parallelism with the structure in RFC 5860. The text has been revised to better align with that document. > [M51]Part of MEP/MIP configuration The current text is constructed to be aligned with [TP-OAM]. > [M52]How are SPMEs established for PWs (PW TCM). How is this > coordinated with LSP SPMEs. PW/LSP coordination is covered in Section 5.1. > [M53]Please clarify the use of the term "tunnel" in this context. The > MPLS-TP identifiers draft uses the term tunnel as a logical relationship > between node and is used to name LSPs. We have removed the text in question. > [M54]The relationship of management plane with respect to the transport > plane should be out of scope of this document. We agree. > [M55]Should define how the terms are used in the context of the MPLS-TP > control plane. We have revised the subsequent text accordingly. > [M56]Please clarify this: Is it on the same wavelength or in the same > fiber on a different wavelength. This depends on the technology / layer of switching being performed. At the optical layer it may be a different wavelength, at the TP layer it would be the same wavelength. > [M57]Most use an embedded communications channel but the selection of > the route for control/management traffic is independent for the > "associated data traffic" and hence is, in effect, out-of-band > independent topology. We have removed the sentence in question. > [M58]How is this different from Out-of-band in-fiber The difference is that the control plane uses the same node pairs but not the same links. > [M59]If it is in-fiber or aligned topology links are used, please > clarify what "alignment is not required" means in this context. It means simply that the independent topology case is a superset of the aligned topology case. > [M60]Addressing in the context of the MPLS-TP data plane is defined in > the MPLS-TP identifiers draft The text has been revised to better align with the TP identifier document. > [M61]Does "family" mean Format? Please clarify The term "address family", as in IPv4 or IPv6 address family, is commonly used in RFCs and is used here in the same sense. > [M62]See the identifiers draft. We agree with the reference. > [M63]Do you mean "The address space(s) of the control, management and > data planes used ..."? Yes, as well as the neighbor adjacencies in the respective planes. > [M64]RFC 4201 defines mechanism by which allocated label is valid across > all component links of given Link Bundle. Is this Link Bundle technique > as well applicable to MPLS-TP? The question relates to label allocation policy in the data plane and is therefore outside the scope of the control plane and this document. > [M65]Is this consistent with the Survivability framework? We have revised the text to better align with that document. > [M66]Not a control plane function This text now references the GMPLS definition of recovery, which includes this list. > [M67]Where is this defined? We have added references to [RFC4872] and [RFC4873]. > [M68]Should include MIP configuration We agree and have updated the text accordingly. > [M69]A routing sub section should be add here. It is essential for > MS-PW. Furthermore, the TE mechanism for MS-PW should be described This is covered in the last part of Section 5.1 and Section 5.3.4. > [M70]Specification for PW QoS, TE parameters, explicit route control and > OAM configuration (for MS-PW) should be provided These topics are covered in the following subsections. > [M71]Is this binding only for dynamic PW and dynamic LSP? What will it > be if a dynamic PW is bound to a static LSP and the reverse? We have updated the text to clarify. Note that the case of configured pseudowires is outside the scope of the control plane. > [M72]MS-PW recovery that is independent of LSP recovery should > considered. This would allow recovery in the event of a PE node > failure. As S-PEs and T-PEs are always co-located with LSP end points, we believe that the described case accurately reflects the MPLS-TP data plane. _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From lamberto.sterling@gmail.com Tue Oct 19 07:27:05 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402C63A67FD; Tue, 19 Oct 2010 07:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYIDW3NIAd41; Tue, 19 Oct 2010 07:27:03 -0700 (PDT) Received: from mail-bw0-f66.google.com (mail-bw0-f66.google.com [209.85.214.66]) by core3.amsl.com (Postfix) with ESMTP id BE7F33A6809; Tue, 19 Oct 2010 07:27:02 -0700 (PDT) Received: by bwz6 with SMTP id 6so598742bwz.1 for ; Tue, 19 Oct 2010 07:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=CTSb+iGdyrwEcC6uCTBtXTfWbI7RGEmQl/hFlVp3muo=; b=Hj0Y+w4jslzk8qL0XwxPmMmnIlo1Ym8+79SQJ+oL5yFHkPKXgD8RCIKggsZHv2eWpO hbLjkSrTggtOm0WTizrm4oigW1mGnMVMJ3s21RyR7V0uHjWXvXZFKIYiCx/E3DGr2xir m3HZlLWgyo6SU8tR4Llk+pAcbOZuV1bMmtlD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pxA/JjBDEXkYEID/TxsNxaxni4AQ+BbmWa73k7mU11fDPvCPfjqY9EZQmOX4h7NZxJ H97dcIaM50AZkd1402VEhRUMswu4ihgP8Oi8vanWCL71TUu4Dwf2mkMnidBkI3AZmoA8 E27wIt1zYPIGrWvtg/wWFCtQwLGJh/+42AGfU= MIME-Version: 1.0 Received: by 10.204.131.132 with SMTP id x4mr5790198bks.50.1287498510935; Tue, 19 Oct 2010 07:28:30 -0700 (PDT) Received: by 10.204.72.15 with HTTP; Tue, 19 Oct 2010 07:28:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Oct 2010 22:28:30 +0800 Message-ID: From: Lamberto Sterling To: zhang.fei3@zte.com.cn Content-Type: multipart/alternative; boundary=001517478f8e64a95b0492f91b1c Cc: mpls@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] Collecting comments on associated bidirectional LSP X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2010 14:27:05 -0000 --001517478f8e64a95b0492f91b1c Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Thank you for the clarification. Cheers Lamberto 2010/10/18 > > Hi lamberto > > See in line... > > Kind regards > > Fei :) > > > *Lamberto Sterling * > > 2010-10-17 16:59 > =CA=D5=BC=FE=C8=CB > zhang.fei3@zte.com.cn > =B3=AD=CB=CD > mpls-tp@ietf.org, ccamp@ietf.org, mpls@ietf.org > =D6=F7=CC=E2 > Re: [mpls] Collecting comments on associated bidirectional LSP > > > > > Hi Fei, > See in line, thanks. > > Cheers > Lamberto > > 2010/9/25 <*zhang.fei3@zte.com.cn* > > > Hi Sterling > > Sorry for the delayed response, I am on vacation. See in line > > Kind regards > > Fei > > *Sterling Lamberto <**lamberto.sterling@gmail.com* > *>* > > 2010-09-12 09:25 > > =CA=D5=BC=FE=C8=CB > *zhang.fei3@zte.com.cn* > =B3=AD=CB=CD > *mpls-tp@ietf.org* , *ccamp@ietf.org* , > *mpls@ietf.org* > =D6=F7=CC=E2 > Re: [mpls] Collecting comments on associated bidirectional LSP > > > > > > Hi Fei, > After a brief review of the draft, there are several points: > 1. section 4.1, point 3, why node B sends PATH message of LSP2 with > ASSOCIATION object with same value as that of LSP1? It seems a bit stran= ge, > what's your consideration about that? > > ZF:It is in accordance with RFC4872, based on the same value, the two LSP= s > can be bound together > Lamberto: OK, I see. > > 2. in section 4.2 peer mode, what if the backward LSP has been already > setup before setting up the forward LSP? In that case, if backward LSP > without ASSOCIATION object does not wish to be bound, how to handle that > case? > > ZF: Actually I do not consider the situation that the backward LSP does n= ot > wish to be bound in the 00 version of this draft. It can be handled in > accordance with the first operation mode. That is to say, if Association > object is carried, it can be bound; if not carried, can not be bound. > > Lamberto: I do not agree. It is very likely that the backward LSP is a > normal LSP that does not support the association feature described in thi= s > draft, the the bind mechanism will break with one end binding successfull= y > and one end binding failure. The backward LSP should also carry the > association object to indicate its ability and tunnel id it wishes to bin= d. > > ZF: In order to be in accordance with draft-ietf-ccamp-assoc-info-00.txt= , > and do not need to introduce the new association rules, I have deleted th= is > operation mode in 01 version. I agree with you that the backward LSP shou= ld > also carry the association object to indicate its ability. But if we do > this, this operation have no advantages compared to the first opearation > mode, furthermore, it increases the blocking probability to setup associa= ted > bidirectional LSP successfully (the ingress nodes do not know which tunne= l > and/or LSP IDs of the egress nodes are unoccupied). > Lamberto: OK, I see. > > > 3. will asymmetric bandwidth allocation for associated LSP be described i= n > future draft? > > ZF: Yeah, this will be added > Lamberto: I don't mean to add it. I am interested with the scenario. Can > you list some? > > ZF: According to RFC5654: 14 MPLS-TP MUST support bidirectional transpor= t > paths with asymmetric bandwidth requirements, i.e., the amount of reserve= d > bandwidth > differs between the forward and backward directions. Here bidirection= al > transport paths include corouted and associated bidirectional LSPs. > As to the scenarios, just my two cents. > (1)Internet service, the bandwidth requirements of upstream and downstrea= m > direction are different. > (2) For some OAM message, such as LSP ping or BFD, they SHOULD have the > reverse return path which's bandwidth MAY be smaller than the forward > direction. > Lamberto: thanks. maybe internet service makes a little sense. > > > Lamberto. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Hi all, > > Associated bidirectional LSP, defined in RFC5654, is useful for protectio= n > switching, for OAM that requires a reply (from MIP or MEP), and for defec= t > correlation. > > There are potentially several solutions, such as GMPLS call, the > Association object, and the LSP_TUNNEL_INTERFACE_ID object. Furthermore, = the > scheme based on the extensions to > > the Association object has been presented in IETF77, and there are some > discussions on the mailinglist. > > We need to receive more comments on this topic to push this work forward, > then update the document, * > ** > ** > http://tools.ietf.org/html/draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-= 00 > *, > which is recently expired. > > Any comments are welome. > > B.R. > > Fei > > :) > > --001517478f8e64a95b0492f91b1c Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi
Thank you for the clarification.
 
Cheers
Lamberto

2010/10/18 <zhang.fei3@zte.com.cn>

Hi lamberto

See in line...

Kind regards
=
Fei :)


Lamberto Sterling= <lambe= rto.sterling@gmail.com>

2010-10-17 16:59

=
=CA=D5=BC=FE=C8= =CB
zhang.fei3@zte.com.cn=20
=B3=AD=CB=CD
mpls-tp@ietf.org, ccamp@ietf.org, mpls@ietf.org=20
=D6=F7=CC=E2
Re: [mpls] Collecting comments on = associated bidirectional LSP




Hi Fei,
See= in line, thanks.
 
Cheers
Lamberto

2010/9/25 <zhang.fei3@zte.com.cn>

Hi Sterling

S= orry for the delayed response, I am on vacation. See in line

Kind regards

Fei

Sterling Lamberto <lamberto.sterling@gmail.c= om>

2010-09-12 09:25


=
=CA=D5=BC=FE=C8= =CB
zhang.fei3@zte.com.cn
=B3=AD=CB=CD
mpls-tp@ietf.org, cca= mp@ietf.org, mpls@ietf.org
=D6=F7=CC=E2
Re: [mpls] Collecting comments on = associated bidirectional LSP




Hi Fei, =
After a brief review of the draft, there are several points:
1. sec= tion 4.1, point 3, why node B sends PATH message of LSP2 with ASSOCIATION o= bject with same  value as that of LSP1? It seems a bit strange, what&#= 39;s your consideration about that?

ZF:It is in accordance with= RFC4872, based on the same value, the two LSPs can be bound together
Lamberto: OK, I see.
=
2. in section 4.2 peer mode, what if the backward LSP has been already setu= p before setting up the forward LSP? In that case, if backward LSP without = ASSOCIATION object does not wish to be bound, how to handle that case?

ZF: Actually I do not consi= der the situation that the backward LSP does not wish to be bound in the 00= version of this draft. It can be handled in accordance with the first oper= ation mode. That is to say, if Association object is carried, it can be bou= nd; if not carried, can not be bound.

Lamberto: I do not agree. It is ve= ry likely that the backward LSP is a normal LSP that does not support the a= ssociation feature described in this draft, the the bind mechanism will bre= ak with one end binding successfully and one end binding failure. The backw= ard LSP should also carry the association object to indicate its ability an= d tunnel id it wishes to bind.
 
 ZF: In order to be in accordance with draft-ietf-ccamp-assoc-info-00.txt, and do not need to introduce the new as= sociation rules, I have deleted this operation mode in 01 version. I agree = with you that the backward LSP should also carry the association object to = indicate its ability. But if we do this, this operation have no advantages = compared to the first opearation mode, furthermore, it increases the blocki= ng probability to setup associated bidirectional LSP successfully (the ingr= ess nodes do not know which tunnel and/or LSP IDs of the egress nodes are u= noccupied).  

 
Lamberto: OK, I see.


3. will asym= metric bandwidth allocation for associated LSP be described in future draft= ?

ZF: Yeah, this will b= e added
Lamberto: I don't mean to add it. = I am interested with the scenario. Can you list some?

= ZF: According to RFC5654: 14  MPL= S-TP MUST support bidirectional transport paths with asymmetric bandwidth r= equirements, i.e., the amount of reserved bandwidth
    differs between the forw= ard and backward directions. Here bidirectional transport paths include cor= outed and associated bidirectional LSPs.
As to the scenarios, just my two cents.
(1)Internet service, the bandwidth req= uirements of upstream and downstream direction are different.
(2) For some OAM message, such as LSP pi= ng or BFD, they SHOULD have the reverse return path which's bandwidth M= AY be smaller than the forward direction.
 
Lamberto: thanks. maybe internet service makes a little sense.
 
 
Lamberto.
 
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Hi all,

Associated bidirectional LSP, defined in RFC5654, is useful for<= font size=3D"2"> protection switching, for OAM that requires a reply (f= rom MIP or MEP), and for defect correlation.

There are potentially = several solutions, such as GMPLS call, the Association object, and the LSP_= TUNNEL_INTERFACE_ID object. Furthermore, the scheme based on the extensions= to

the Association object has been presented in IETF77, and there are some= discussions on the mailinglist.

We need to receive more comments o= n this topic to push this work forward, then update the document,

= <= tt>http://tools.ietf.org/html/draft-zhang-mpls-tp-rsvpte-ext-associated-= lsp-00, which is recently expired.= <= tt>

Any comments are welome.

B.R.

Fei

:)


--001517478f8e64a95b0492f91b1c-- From root@core3.amsl.com Tue Oct 19 12:30:16 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AE1553A6940; Tue, 19 Oct 2010 12:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101019193016.AE1553A6940@core3.amsl.com> Date: Tue, 19 Oct 2010 12:30:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rsvp-resource-sharing-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2010 19:30:16 -0000 --NextPart 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 : RSVP Resource Sharing Remote Identification Association Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-ccamp-rsvp-resource-sharing-00.txt Pages : 11 Date : 2010-10-18 The RSVP ASSOCIATION object allows to create association across RSVP path states or across Resv states. Two association types are currently defined: recovery and resource sharing. This document defines a new association type called "Resource Sharing Remote Identification". It can be used by the sender to convey to the receiver the information that can then be used by the receiver to identify a downstream initiated resource sharing association. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-resource-sharing-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-resource-sharing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-19122257.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Oct 21 06:30:04 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 589823A68A9; Thu, 21 Oct 2010 06:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101021133003.589823A68A9@core3.amsl.com> Date: Thu, 21 Oct 2010 06:30:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g709-framework-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Oct 2010 13:30:04 -0000 --NextPart 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 : Framework for GMPLS and PCE Control of G.709 Optical Transport Networks Author(s) : F. Zhang, et al. Filename : draft-ietf-ccamp-gmpls-g709-framework-03.txt Pages : 27 Date : 2010-10-20 This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Zhang Expires April 2011 [page 1] draft-ietf-ccamp-gmpls-g709-framework-03.txt October 2010 Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as consented in October 2009. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-framework-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-g709-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-21062233.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Oct 21 08:45:07 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9E53B3A6983; Thu, 21 Oct 2010 08:45:06 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101021154507.9E53B3A6983@core3.amsl.com> Date: Thu, 21 Oct 2010 08:45:06 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-wson-impairments-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Oct 2010 15:45:07 -0000 --NextPart 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 : A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-wson-impairments-04.txt Pages : 36 Date : 2010-10-21 The operation of optical networks requires information on the physical characterization of optical network elements, subsystems, devices, and cabling. These physical characteristics may be important to consider when using a GMPLS control plane to support path setup and maintenance. This document discusses how the definition and characterization of optical fiber, devices, subsystems, and network elements contained in various ITU-T recommendations can be combined with GMPLS control plane protocols and mechanisms to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in optical networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-impairments-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-wson-impairments-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-21084015.I-D@ietf.org> --NextPart-- From daniele.ceccarelli@ericsson.com Fri Oct 22 06:47:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA283A691C for ; Fri, 22 Oct 2010 06:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.527 X-Spam-Level: X-Spam-Status: No, score=-5.527 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6-Ujecevain for ; Fri, 22 Oct 2010 06:47:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 98FD83A67E7 for ; Fri, 22 Oct 2010 06:47:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7b28ae00000135b-9c-4cc196360113 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3A.A8.04955.63691CC4; Fri, 22 Oct 2010 15:48:38 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.62]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 22 Oct 2010 15:48:37 +0200 From: Daniele Ceccarelli To: Rajan Rao Date: Fri, 22 Oct 2010 15:48:36 +0200 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: ActrHdiZI+Ac/40cQBur+suTIMHh2AAADSfwACPdsWAANsiSMAFSMElw Message-ID: References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Ong, Lyndon" , "ccamp@ietf.org" Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2010 13:47:03 -0000 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" Moreover it states: "If the interface does not support ODU-flex service,=20 this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: =20 1) This draft extends existing ISCD Vs. defining a new one=20 - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation =20 Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01=20 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. =20 This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. =20 The IETF Secretariat. _______________________________________________ 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 pierre.peloso@alcatel-lucent.com Fri Oct 22 08:40:07 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5AF3A6840 for ; Fri, 22 Oct 2010 08:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlVw+0S2BCO3 for ; Fri, 22 Oct 2010 08:40:04 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 90FE23A67F7 for ; Fri, 22 Oct 2010 08:40:03 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9MFfVX0022905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Oct 2010 17:41:31 +0200 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 22 Oct 2010 17:41:31 +0200 From: "PELOSO, PIERRE (PIERRE)" To: Giovanni Martinelli , Greg Bernstein Date: Fri, 22 Oct 2010 17:41:30 +0200 Thread-Topic: [CCAMP] WSON documents ready for last call... Thread-Index: Actuvj+VumoqOZVrR8CCpDfP3D4zmgDQO99Q Message-ID: References: <4CB5D5A9.4080707@grotto-networking.com> <4CBC3A5F.50907@cisco.com> In-Reply-To: <4CBC3A5F.50907@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_CCBFBB7025DF984494DEC3285C058152126125C3EFFRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: CCAMP Subject: Re: [CCAMP] WSON documents ready for last call... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2010 15:40:07 -0000 --_000_CCBFBB7025DF984494DEC3285C058152126125C3EFFRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Giovanni and Greg, My point of view is very similar to yours (Giovanni), and though the work i= s in a good shape, I also share your opinion that progress on protocols is = required before the last call. Cheers, - pierre ________________________________ De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de G= iovanni Martinelli Envoy=E9 : lundi 18 octobre 2010 14:15 =C0 : Greg Bernstein Cc : CCAMP Objet : Re: [CCAMP] WSON documents ready for last call... Hi Greg, from my side there are no outstanding comments and docs are in a very good = state. My only concern is to progress more on protocol extension drafts bef= ore going through a last call. At least I see this need because protocol implementation might provide feed= back to information model (different information) and encoding (differen= t tlv/sub-tlv layout) so requiring updates on these documents. Here my thought, may be others on the list have different opinion. Cheers G On 10/13/10 5:52 PM, Greg Bernstein wrote: Hi CCAMPers, per the Maastricht meeting notes we've been preparing three CC= AMP WG documents for last call: (a) WSON Info (draft-ietf-ccamp-rwa-info-09) (b) General Constraint Encoding (draft-ietf-ccamp-general-constraint-encode= -03) (c) WSON RWA Encoding (draft-ietf-ccamp-rwa-wson-encode-06) We published the update to the WSON Info document over a month ago and quer= ied this list for comments. We have now updated the General Constraint Enco= ding draft to align with the WSON Info model. In addition we have updated t= he WSON RWA Encoding draft per the Maastricht meeting notes to be more bit = efficient with one of our encodings. >From the document authors perspective we are ready for last call. Are there= any outstanding comments? Best Regards Greg and co-authors -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_CCBFBB7025DF984494DEC3285C058152126125C3EFFRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Giovanni and Greg,
 
My point of view is very similar to yours (Giovann= i), and=20 though the work is in a good shape, I also share your opinion that progress= on=20 protocols is required before the last call.
 
Cheers,
 
- pierre
 

De : ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] De la part de Giovanni=20 Martinelli
Envoy=E9 : lundi 18 octobre 2010=20 14:15
=C0 : Greg Bernstein
Cc :=20 CCAMP
Objet : Re: [CCAMP] WSON documents ready for last=20 call...

Hi Greg,

fr= om my=20 side there are no outstanding comments and docs are in a very good state.= My=20 only concern is to progress more on protocol extension drafts before=20 going  through a last call.

At least I see this need because= =20 protocol implementation might provide feedback to  information model= =20 (different information)  and  encoding (different tlv/sub-tlv=20 layout) so requiring updates on these documents.

Here my thought,= may=20 be others on the list have different=20 opinion.

Cheers
G

On 10/13/10 5:52 PM, Greg Berns= tein=20 wrote:=20
Hi CCAMPers, = per the=20 Maastricht meeting notes we've been preparing three CCAMP WG documents = for=20 last call:
(a) WSON Info (draft-ietf-ccamp-rwa-info-09)
(b= )=20 General Constraint Encoding (draft-ietf-ccamp-general-constraint-encode= -03)
(c)=20 WSON RWA Encoding (draft-ietf-ccamp-rwa-wson-encode-06)

We=20 published the update to the WSON Info document over a month ago and que= ried=20 this list for comments. We have now updated the General Constraint Enco= ding=20 draft to align with the WSON Info model. In addition we have updated th= e=20 WSON RWA Encoding draft per the Maastricht meeting notes to be more bit= =20 efficient with one of our encodings.
From the document authors=20 perspective we are ready for last call. Are there any outstanding comme= nts?=20

Best Regards

Greg and co-authors
--=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237



_______________________________________________
CCAMP mailing list
CCAMP@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ccamp
--_000_CCBFBB7025DF984494DEC3285C058152126125C3EFFRMRSSXCHMBSA_-- From root@core3.amsl.com Mon Oct 25 07:15:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 871F33A6A11; Mon, 25 Oct 2010 07:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025141502.871F33A6A11@core3.amsl.com> Date: Mon, 25 Oct 2010 07:15:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-oam-configuration-fwk-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Oct 2010 14:15:02 -0000 --NextPart 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 : GMPLS RSVP-TE extensions for OAM Configuration Author(s) : A. Takacs, et al. Filename : draft-ietf-ccamp-oam-configuration-fwk-04.txt Pages : 23 Date : 2010-10-25 OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-oam-configuration-fwk-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-oam-configuration-fwk-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25070112.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 07:30:05 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 056263A688C; Mon, 25 Oct 2010 07:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025143005.056263A688C@core3.amsl.com> Date: Mon, 25 Oct 2010 07:30:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Oct 2010 14:30:05 -0000 --NextPart 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 : GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration Author(s) : A. Kern, A. Takacs Filename : draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt Pages : 21 Date : 2010-10-25 GMPLS has been extended to support connection establishment in both SONET/SDH [RFC4606] and OTN [RFC4328] networks. However support for the configuration of the supervision functions is not specified. Both SONET/SDH and OTN implement supervision functions to qualify the transported signals. This document defines extensions to RSVP-TE for SONET/SDH and OTN OAM configuration based on the OAM Configuration Framework defined in [GMPLS-OAM-FWK].Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25071517.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 11:00:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 267D63A6922; Mon, 25 Oct 2010 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025180002.267D63A6922@core3.amsl.com> Date: Mon, 25 Oct 2010 11:00:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-assoc-info-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Oct 2010 18:00:02 -0000 --NextPart 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 : Usage of The RSVP Association Object Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-assoc-info-00.txt Pages : 21 Date : 2010-10-14 The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state, and this document defines how the ASSOCIATION object can be more generally applied. The document also reviews how the association is to be provided in the context of GMPLS recovery. No new new procedures or mechanisms are defined with respect to GMPLS recovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-assoc-info-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-assoc-info-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25105509.I-D@ietf.org> --NextPart-- From rrao@infinera.com Mon Oct 25 16:12:15 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4135E3A6BC6 for ; Mon, 25 Oct 2010 16:12:15 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vykh5UnQaz2L for ; Mon, 25 Oct 2010 16:12:04 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id E6DC13A6BCD for ; Mon, 25 Oct 2010 16:12:03 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Mon, 25 Oct 2010 16:13:13 -0700 From: Rajan Rao To: Daniele Ceccarelli Date: Mon, 25 Oct 2010 16:13:16 -0700 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: ActrHdiZI+Ac/40cQBur+suTIMHh2AAADSfwACPdsWAANsiSMAFSMElwAKc8mrAACYSToA== Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1SVEXDB1infine_" MIME-Version: 1.0 Cc: "Ong, Lyndon" , "ccamp@ietf.org" Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Oct 2010 23:12:15 -0000 --_004_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1SVEXDB1infine_ Content-Type: multipart/alternative; boundary="_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1SVEXDB1infine_" --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1SVEXDB1infine_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards = compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue - either support or don= 't support. Based on the WG agreement we could go either way without breaki= ng the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question= . - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where OD= Uflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-B= W. This can be easily accomplished with a sub-TLV for ODUflex signal type i= n our model. BW in bytes/sec, of course. Please refer to attached slides f= or details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This= is exactly the proposal we have in our draft. Good to see that you have mo= ved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ 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 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1SVEXDB1infine_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Daniele,

 

Please see response inline, within { }. =

 

Thanks

Rajan

 

-----Original Message-----

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Just a couple of comments on backward compatibility= and bandwidth advertisement.

 

- Backward compatibility: no ODU advertising is def= inded in RFC 4202/4203, so i believe there are no backward compatibility issues.<= o:p>

 

 

[Rajan] =A0{

Agree there is no ODU advertisement defined. The ne= ed to address backwards compatibility depends on the following:

 

=A01) are there RFC-4328 based deployments?

=A02) If so, what do they use for BW advertisement?=

=A0

Our fair guess is that ISCD is used for this as per= RFC 4202/4203.

 

There are 2 ways to address the compatibility issue= – either support or don’t support. Based on the WG agreement we could g= o either way without breaking the model we have proposed. Please refer to attached slides for details.

 

}

 

Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the M= AX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisemen= t, this is a backward compatibility issue in my opinion. It states that:=

 

=A0=A0=A0=A0=A0 "Encoding of Max LSP Bandwidth= is as follows:

=A0=A0=A0=A0=A0=A0 Max LSP Bandwidth =3D Unreserved= -TS-Count x TS-Nominal-Rate"

 

[Rajan] =A0{

 

The unit here is in Bytes/sec. The description abov= e (& in our draft)

-    shows that nominal rate is dependent on specific ODU layer in question.

-    shows how Max LSP bandwidth number is derived at the advertising node.=

}

 

Moreover it states:

 

=A0=A0=A0=A0=A0 "If the interface does not sup= port ODU-flex service,

=A0=A0=A0=A0=A0 this value should be coded as zero&= quot;.

 

But advertising max LSP bandwidth =3D 0 means disca= rding such link in the path computation process.

 

[Rajan] {

Good question & very valid. I think you are bri= nging up a scenario where ODUflex is not supported but backward compatibility is = required.

 

What we need here is to separate ODUflex advertisem= ent from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUfle= x signal type in our model. BW in bytes/sec, of course.=A0 Please refer to at= tached slides for details.

=A0

}

 

- Bandwidth advertisement: in the -04 version of ou= r draft the bandwidth is advertised as follows:

 

=A0=A0=A0 - Unreserved bandwidth for fixed containe= r in number of containers

=A0=A0=A0 - Unreserved bandwidth for oduflex in Byt= es/sec

=A0=A0=A0 - Max LSP bandwidth in Bytes/sec.

 

[Rajan] {

We believe advertising the number of containers is = the right approach. This is exactly the proposal we have in our draft. Good to = see that you have moved away from TS approach which had serious limitations.

 

}

 

Advertising the unreserved bandwidth in number of containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

 

[Rajan] {

 

=A0The ODUflex uses bytes/sec in our draft.=A0 Ther= e is no disagreement here.

 

}

BR

 

The authors

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: venerd=EC 15 ottobre 2010 19.13

To: Ong, Lyndon; ccamp@ietf.org

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Lyndon,

 

Yes, we are aware of the existing draft. There are = some fundamental differences in the model we have proposed from the existing dra= ft. The key differences are the following:

=A0

1) This draft extends existing ISCD=A0 Vs. defining= a new one

=A0=A0=A0 - addresses backward compatibility issues= (RFC 4202)

 

2) ODU containers are advertised instead of #TSs

=A0=A0=A0=A0 - simple path computation

 

3) Path computing node doesn't need to know per lin= k and/or per ODU layer TS granularity

=A0=A0=A0=A0 - again, simple & straight forward= path computation=A0

 

Thanks

Rajan

 

-----Original Message-----

From: Ong, Lyndon [mailto:Lyong@Ciena.com]

Sent: Thursday, October 14, 2010 7:45 AM=

To: Rajan Rao; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?=A0 It would be helpful to understand if your draft is asking for similar extensions or different functionality.

 

Thanks,

 

Lyndon

 

 

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: Wednesday, October 13, 2010 2:40 PM

To: ccamp@ietf.org

Subject: [CCAMP] OSPF-TE extensions for G.709 OTN d= raft submitted:

draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi,

 

The following draft has been submitted. Please revi= ew. Comments are appreciated.

 

https://datatracker.ietf.org/doc/draft-ashok-ccamp-= gmpls-ospf-g709/

 

thanks

Authors

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]

Sent: Wednesday, October 13, 2010 2:30 PM

To: Rajan Rao

Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan

Subject: New Version Notification for

draft-ashok-ccamp-gmpls-ospf-g709-01

 

 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been

successfully submitted by Rajan Rao and posted to t= he IETF repository.

 

Filename:=A0=A0 draft-ashok-ccamp-gmpls-ospf-g709<= o:p>

Revision:=A0=A0 01

Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 OSPF TE Ex= tensions for Generalized MPLS (GMPLS) Control

of G.709 Optical Transport Networks

Creation_date:=A0=A0=A0 2010-10-12

WG ID:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Independen= t Submission

Number_of_pages: 20

 

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased

need to support GMPLS control for the same. [RFC432= 8] introduced

GMPLS signaling extensions for supporting the early version of G.709

[G.709-v1]. The basic routing considerations from signaling

perspective is also specified in [RFC4328].

 

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and

[GSUP.43] have introduced new ODU containers (both = fixed and

flexible) and additional ODU multiplexing capabilit= ies, enabling

support for optimal service aggregation.=A0

 

This document describes OSPF protocol extensions to support

Generalized MPLS (GMPLS) control for routing servic= es over the

standardized OTU/ODU containers in support of ODU b= ased TDM

switching. Routing support for Optical Channel Laye= r switching

(Lambda switching) is not covered in this document.=

=A0

 

 

 

The IETF Secretariat.

 

 

_______________________________________________

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

--_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1SVEXDB1infine_-- --_004_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1SVEXDB1infine_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="OTN Routing extensions- backwards-compatibility.pptx" Content-Description: OTN Routing extensions- backwards-compatibility.pptx Content-Disposition: attachment; filename="OTN Routing extensions- backwards-compatibility.pptx"; size=94184; creation-date="Mon, 25 Oct 2010 16:05:18 GMT"; modification-date="Mon, 25 Oct 2010 16:04:28 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQD+toQZagIAAMsWAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM WNuO0zAQfUfiHyK/osZNgWVBbVeIyxOwK7F8gEmmrSGxLdst279nkrSRW2VJN05IXlK5iWeOxzPH czy/ecjSYAfacCkWJAqnJAARy4SL9YL8uP88uSaBsUwkLJUCFmQPhtwsnz+b3+8VmABnC7MgG2vV O0pNvIGMmVAqEPhmJXXGLA71mioW/2ZroLPp9IrGUlgQdmJzG2Q5v0UAmicQ3DFtv7EM/VClLDUp /vmVGYv43MEsROsk+FCayZEsCFMq5TGzuA66E8kZholcrXgMiYy3GXoOlQaDv8XnWRo6jl7kpmkD pi9sL7f2gKkcvOkFU2m7LabrEWKK3g4Nqiahol4wlY4u2rxDKr3sBcdTELwaBEFejndaKtO198rw RTGoKet+4uFX1q+7jlJBf36YrkaIKRojJ0dDkrLF8xlo8fQ/QwszTXXlePQnt4s8Fsl84NN+eL1p zS4C/zDXtSpNCJyo+4fg8qjX8Gc/6/fjKv9ErNsTP0zRGEk9+h+s/hFWbJva4NMDaoJShvxSsD5r 73mWq4fiBTbnNXM0pOZsToMkOEiSEGcWOsBsuDLHyqrx8G/N0SAb3Izp+qg8sZ0xLo6LeExXCWnB HNtgZ+DPFS4U1FWO7SZMTg9yoqs6x+Q4ao1plAwyxlZ1NhT/o9IvBAVFEvCuN8ipKYFkolCjgLYc Kp54rMQs+5nCd7tPoXNN45huncCjrKqhcqW6aqrrX6be2XPGiR3wz2zI7Ytlll+hvd/ajdSdJ/ep 9db5PeSu7Tj86eUyozLcNixDXb1VZBxLDU+vp2Ojls+uoWBaXEUv/wIAAP//AwBQSwMEFAAGAAgA AAAhAGj4dKEFAQAA4gIAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskttKAzEQhu8F3yHMfTfbKiLS bG9E6J3I+gBjMrsb3RxIptK+vaHgYWEtgr2c0z9f8s96s3ejeKeUbfAKllUNgrwOxvpewXP7sLgF kRm9wTF4UnCgDJvm8mL9RCNyGcqDjVkUFZ8VDMzxTsqsB3KYqxDJl0oXkkMuYeplRP2GPclVXd/I 9FMDmomm2BoFaWuuQLSHWDb/R1s6YjTIKHVItIipkCW25S2ixdQTKzBBP5Z0PnZUhRrkPNDqvEA8 7NyLRzvOoHzVqtdI/W9Ay78Dha6zmu6D3jnyPGOCnHZ8M8XIMibKZexo+6kfuj4nEO2ZvCFz2jSM 8ZNITi6z+QAAAP//AwBQSwMEFAAGAAgAAAAhABDGtglSAQAAtQQAACAAAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlMS54bWwucmVsc7yU3U4CMRCF7018h03vdwuoqIQFL9SERG8MPsDYzm7r9i/toPD2 VhMSSDBqQC6nnZ755uSk4+nSmuINY9Le1axf9ViBTnipXVuz5/l9ecWKROAkGO+wZitMbDo5PRk/ oQHKj5LSIRVZxaWaKaIw4jwJhRZS5QO6fNP4aIFyGVseQHTQIh/0ekMeNzXYZEuzmMmaxZk8Y8V8 FfLkn7V902iBt14sLDraMYKrrBSNdl0Whdgi1cyCNuRH6QVi3hH0jXaNdhihEt6u2x69zAR3S8Lo wDC+G3Xwz6ifDqRsrwQCitlIjJVGar6MlV5wGaGhEpLyXSkE2FC2NphU+hSasr3sXfO/LdQ/5ELJ aIkPsPILWlPUrKr4xnnaLPpVjs53Vg8PSfZ9KqBbuFctFQQgBXaPbFwcB7gLmhS+g9sD9fw4qDGC /yUl3/psJh8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTIueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/Xtz rCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8 a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO 5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAG6cA XMEAAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzhI9Bq8IwEITvgv8h 7N2kPkREmvYigvBOoj9gSbZtsE1CNj5e/705VhA8zg7zzU7d/k+j+KPELngNW1mBIG+Cdb7XcL+d NwcQnNFbHIMnDTMxtM16VV9pxFxCPLjIolA8axhyjkel2Aw0IcsQyRenC2nCXGTqVUTzwJ7UT1Xt VVoyoHljiovVkC52C+I2x9L8nR26zhk6BfOcyOcPFYpHZ+kX5/DMBYupp6xByuWdl2Iny/ugmlq9 zW1eAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGU0LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd 5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457 pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrF g7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAD/qLu9lAQAA HwcAAB8ACAFwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAvJXPTsMwDMbvSLxDlTvL2o3xR+smJIS0AxKC8QCh9dqKNolib7C3 J5SxptUULhGXVv7SOj99dpz58rOpox0YrJRMWTwaswhkpvJKFil7XT9cXLMISchc1EpCyvaAbLk4 P5s/Qy3I/oRlpTGyWSSmrCTSt5xjVkIjcKQ0SLuyUaYRZENTcC2yd1EAT8bjGTduDrbo5YxWecrM Krf7r/fa7vx3brXZVBncq2zbgKQTW/BMNd9Ld1sqlUGbWZgCKGV9fWSZGT+NMwmJg3WVQ0fRhsjb V+yDuAoJIRUBPgokMB2KIyJ3Ai9WnITkIvFWwwvta9txx0I5os+goCBtPYYGOeKhYj9fJD6sOKQ/ DkHnjyP2sLx1mwXHGgAdUKZeb4KaQ3YAOSerDXn79Dpx+U9OTLxO2BkcbuTtKvh4Mko7h+go+Sim ISHatjzdFN4DcxMSQhvAgRNH6dcJ3rvWFl8AAAD//wMAUEsDBBQABgAIAAAAIQBltBc/dwIAAGwN AAAUAAAAcHB0L3ByZXNlbnRhdGlvbi54bWzsl92O2jAQhe8r9R0i31ZsSMjfRoSV2gpppa2ECvsA 3mSAaB0nsg2FffqOjSEGqmofIHexZ3zm+NPYmOnToWHeHoSsW16Q4GFMPOBlW9V8U5DX1XyUEU8q yivKWg4FOYIkT7OvX6Zd3gmQwBVVuNRDGS5zWpCtUl3u+7LcQkPlQ9sBx9i6FQ1VOBQbvxL0D8o3 zA/H48RvaM2JXS8+s75dr+sSfrblrsHyJxEBzPiQ27qTZ7XuM2ruLq4tSbqH5e5Ngpq3XEmkQ2a4 bcmqX1QqEM/Vi1Q3M15dFSQMojTKJkmE7ESuZzA3IP7/chMEf8kNda7/r1K8VSBvyl/N9SKpFbkK 945d98/VyXecOCYmF8PncBo54eg+HDvh+D7siifWHMJ0jSw/vPJQkMcgisZjJFIeC5JkcWYG6thh A8pSAPDoYO2Z3dlll0y97KxhqFewpjumVnBQS3VkMJvSHOcWC2G/fi+Ex6jueeCj16Vx56awPQs6 zGmoeCkIOqNsg+eFEQ9lVvRt+XGuiAwUMylAX/h38a77BrVVze0QV2+xFB6BxY6X6tRXpph2IVEp wA0T7x2EPpJ4SLDvaC5bVlfzmjEz0McLfjDh7SlWUwfTXv5NlqnqaW5rWiK7bw0fMaU3R3OgNwGg p0ApbwKl7HGgQ+xMmlseWgg/wx5NFKfa8MDHQLF8Jj2fU1sOfPZMQ7F8op5PMEmDZGggfao0FQso dgBlYWauh+EG0lQsoKQHFIYZNtBwBWEHaSoWUOoASqPJcEebHy5NxQLKekCaDr4/hkt6zzQVC+jR AZTE6XBJmw7SVMxb/f6JiQ9498/F7C8AAAD//wMAUEsDBBQABgAIAAAAIQDihS+v1QcAAIkiAAAV AAAAcHB0L3NsaWRlcy9zbGlkZTMueG1s7Fpbb+M2Fn4vsP+B0EMxBdYTX+RrxykSZxwMkCaB7dk+ 0xJtE5FJlaJvW/S/70fSsi3Ft8AZ7G6nD4l1IQ/PnYff0adfltOIzJlKuBRtr/Sx6BEmAhlyMW57 XwfdQsMjiaYipJEUrO2tWOL9cv2PHz7FrSQKCWaLpEXb3kTruHV1lQQTNqXJRxkzgXcjqaZU41aN r0JFF6A6ja7KxWLtakq58Nbz1Tnz5WjEA3Yng9mUCe2IKBZRDc6TCY+TlFp8DrVYsQRk7OwMS9eQ LOhHoflN4oFizFyJ+b2K+/Gzsq8f58+K8BD68oigU6jFu1q/WA+ztwLDcHGVmz5OKdHWcqSm159o C7KRZduD8lfmPybRFltqEriHwfZpMHnaMzaYfN4z+ipdABxsFjVSOYlei1NPxRlwHTFS20jlhlJM fZDBS0KEhJxGfCde8DhPiRmZDfl4QvQqhma0IbUe515afaTjE6vTlNGNJvxqHV5i1VGu+7VKI6uT RrncrJn3RjNN36/WynaJlA6WcITjll7eynBlFDrEr2GOtgTc8mam5YhrI8DuqyjRfb2KmDUBFEVb doaCwSNqYoKJwtc+YuLfba9iWQi50tY+JJnqTsQo4mhtQn19S4OXBVVhQgI5jeFtQx5xvfpQ/sks q+3idgEmwmeqaO+MdRzL4A1SptJZgY3ex4rGEx50FdzSmfl+50nef6upwTtSaIQDeY5owCYyCpki vlEpguERvr8l6jS4u8whl8jPMmGwcQ6jvwmNRh7iCE6eetKOh7yenouWUrlZ9ddOUirWag1cW7Ol kVOrlZt2gPGSUr1ebpbtCCgrJbWWw9h5fXlHNSUzxc9JIrmUpukQrm5o6WG0/oE9R1wluicXNl0M kUrX13aEmWId7kt4/Ue1Uy5Xff+mUP/8uVbwK365cFv0G4VG9fau0+zelTqVmz+t4+xOsw+GkTMM Vr5XHNnLCMTDjoyIWdgvlRolG8+Z5+VqtVhtWENnn9dq9aJTp3HTLU2tyASOXy82/KKTNLBi5ILM muF1KCHWCY3GCJBAq7Wtjvh9KRtfW78HS5sFdQCiU6oe2p7vN+oVz9z00hs3RzsmL2T1cCLIMbov ETxw8UJuCrckE/dQrs0x7t9r7Vy05If7j/ViszAvZdc8ltHOEGTAIoiSkeI0xSFNzDRsB8jZRxNm ltdL9XP+ur1uduX3lKlD/HKxcoV/pbek/Zwx/v/d/7bQyfjNpdY96kip91featejVP+i3m/iJHyr os4PLimInCmC7XKkL4iAfF51/oP/b98NzCSbXN99Q7soZT/hSNXpP3czYYKjwHeySXbWNXLEvjcF mCIqkREPuzyypWOixsNOpMicRm2v20Ux5krXzDB4MQ4mtgC73uouG8cuSNI6471LDNJjI6IleZQ6 b7NTgXB++iBDFsnFBYnjsq3zfzRXPLLF37mC4/j0veUKeDN2r52A/28pYB0Y5secd/G7c4bevbdQ xfrdBpk4DEMBcnSo2j5Uor5BJRyE9EZQKoc7ONgoRSYADIgNknUAmarXAEw5ZKqCK4MvWIOkoAPQ qvoGmsIJvrnN3A50sFCNw0G2dctebIpEoh8HPRbOAgNy4hi/sw1sZ+w9ZxsfGc4egdmuk5/bJw4n ZSfV0eLXJPlWxtlg8u359SLagwnL7lvHDmCO16EFVGZtLxHjE6fK+6ebhwzjp6kf1cRbWT1KjCdm B53SF0YGnwvmdJ2QBdcTItgCMNzT4JEENKYWOeRsiyQCobXD3lOwDopPwsW7yheyOJKrt5wvzvBF wfRCqpckJ/yxSvkE1ffzZWKc+Uu/c0dc/4PESsbSnLCg2c1BCEgYqpoEpVPICjckq/IMMwY2i+ao Ay1Kesx1c5BB/sBkto2BBBeaKTRANJmJHtogas7Cwu1v/8zx8JaFmEIPB92QPRD4r3T50H/O2elw rjhDBPBKAKN+I3a5+BbsJiRGLPe6HQMFkR/pNP7Z3BlkqJTRzX7L233qqEGK1VPQWkdR8VIYoiOR 9bULycKzE9fWMMmJj8h0tkSfj0R8yl1/LSGELXmiM3KeONUeF2e/kt4jPH4ziVcqm1nlTKfROZZG JD1RcjaekESONLo6jMxiVDVhtgLN8HbYz09kIxOqT8BM4OpTJIgIW4DAOQiapAmPVlAo+jUhUgq2 DpLM4lgqTZ7uvo4itszoOcPOu2aSHvt9xtFGTZc1rAwZ+lwMDA0Lg4d/mXzX7/S/5P3tWJY+Ef/f TpybMIQwCeTRSN8BEDGymDCxkQ7btJA61TU0/8GMSwImqOKSrOSMTPh4EuFPu1SPR4qgHc6jC86u +ZSaV8CBQu+YinOutz0d7+knHq7S/bRK7wO2YORxNh0iw+02ECuXlequf4yvDEDaNVx/n1GFrSvt GZ4o3iHXVqC0x2tr9dcV8wjAm2no/3FX71Tq3WaxUKlW6gW/2uwWbsoNv+AXm427RrGEtvPdn966 t50YyQW4M0Z43SLOt4MRfXZ5fV3ZhihWNrMP2WtTOR6xkj1RuC8VcJl+vBBE6lcaP81tCsI3GVAc ACU8ipHKDDUM3Q6BppCvxdjqTDwkaE2jiU8xGcMGIv3aIZxhn+dIPCMuuGYeQchoGKXtCYavSOAS SFYD1/if9qTUxgWwkqWEX+1Im6v1criEia//AwAA//8DAFBLAwQUAAYACAAAACEAmb3JJ2MFAAC3 FQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbOxYy27jNhTdF+g/EOqmReHxS34izmBiJ4MAmSSI nWZNS3TMjkSqIu3YU/Rf+i39sh5SkhM5sRQnnq66kWWRvLyPcy95z9HHVRiQJYsVl2Lg1D/UHMKE J30u7gfO7eSs0nWI0lT4NJCCDZw1U87H4x9/OIr6KvAJVgvVpwNnrnXUr1aVN2chVR9kxATGZjIO qcbf+L7qx/QBUsOg2qjV2tWQcuGk6+PXrJezGffYSHqLkAmdCIlZQDU0V3MeqUxa9BppUcwUxNjV OZWOYZk3Dnzzq6JJzJh5E8vPcTSOrmM7fLm8jgn34S+HCBrCLU41HUin2b8C0/BS3Vp+n0mi/dUs Do+PaB+2kdXAgfPX5olFtM9WmnjJR+/xqze/emGuNz99YXY12wAabDY1ViUWPTennZkz4TpgpLWx KplKsfRCel8VERJ2GvMT87zLZSbM2GzER3Oi1xE8o42odF4yaP2RzVfWp5miG0+4rQ5QYt3R6Ljt Zjfvk26j0WubceOZTr3VazfsFpkcbJEIjvp6dSL9tXHoFL9GOdoXgOWnhZYzro0BT4cCpcd6HTAb AjiK9u2KGAEPqMkJJiq3Y+TEt4HTtCr6PNY2PkSFehgwijxKQ6iPryILT6Ilob4PzClyQr2vDzT2 FRnKMAIApzzgem3U0FYZuyET/jWN6c0r9k1MgK6wOrPWOsDEYXewO1mwh1JopAK5DqjH5jLwWUza xp1IhCywe4ae+wBuho43Rb3e7NRNhG0cslTIhb1Va/RMABLzk0w6ZNwBTBLS+GLgtOpuswWwBcvA 5igXPvw1cCrpgAXX4gxutJifwY0D59fw90qgE/2nC4O2y0WY5gQCO+XeNYu59FP90zTYDbaGa/Be CLbzGdlC0bvETTdA9Z4ClQjGAF4gesoyUDO/n9sZWLa5kzwMho3rLCCKEgrhLLPxVjFEhQtyPh6O CFUkAlpze79zg5uzIXEbtUYVj6Z51LekF2VmiQHfzy0jNuMC4UBwHohaTCuTi98O6hac5ORqdDsL 2OqgchHJ8XB8Tn4+uSN4n641U1XFvF9yXt/luCTzLnEzSYtgUt8PGaL/S4A9q/IlgKs9QGAL12Lg KHFfUsCE1LmwF6ZyeT0kVBCu1IL9Z8Xp9dqXVzoUukOKeyyaJpX3lDy1V91XxTAtEntuUHiu/fP3 vvoWikOloT5aHs0VM61EXviuUmMvIgXnaXlALw/pE5nXujBTylUzRzp5Ay4K/UyJYhGuOpptTqQn p8iWM75fyX75trbfmVFca55BJn9mbCtQhqTizUyXcMr1HNceaZuLPYBQLtlDycS1jlHFg/VBJVMP R0gofcDBNye9XMQEmfhF+izIYWGHN3t116qf3iQhIn8JL/NqeRIkvdpP9T3MLheKk1KAtjDX5ZyV 70zYOV2ynLwdXstal329VY6UO0YMWLKuliWQnFKF8Ep8vwdz8ry6FpptN32hiTa3/VNQUXeft31Y WDWKbcg5bA856UVz3267lXXb44D7jKAXnCKDn7bcrukE395yJ2wLODmITuiJPxY01ix2wFSZbjxh SAwXZS7J6JTFhrQxXIndPKMPMkbEJtVzSmQG5s/QX3+OOsNm56xXqzRbzU7FbfXOKp8aXbfi1nrd UbdWB0kz+stJu15lLBfQzrIqz4iNbfIk0cmUO/cR6djZrN4Vr815VBAlyxEkvB5eM6rPC+IvNLpa 2hMeDCYcN7SfInCWRhqmPk4B0cJDDJiAaXGhQNyA8qJYjGkT3DoTbtBfgNk0qYfmjGvmEBBAGkEZ OILhAgJIoPpNEposvJHS0gXYyUrCbyravKXb4RUhPv4XAAD//wMAUEsDBBQABgAIAAAAIQDHY0wR MgQAAAsOAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTEueG1szFfbcts2EH3vTP8Bw6f0gbpbt7GUOnad ySSxNZLyASsQFBGBAAuAipRO/z0LkJRjWprYjd2JHiSIXJzFHuweLM5f71JBtkwbruQkaDdaAWGS qojL9ST4tLwOhwExFmQEQkk2CfbMBK+nv/92no2NiAjOlmYMkyCxNhs3m4YmLAXTUBmT+C5WOgWL f/W6GWn4gqipaHZarX4zBS6Dcr5+zHwVx5yyK0XzlElbgGgmwOLKTcIzU6Flj0HLNDMI42ffW9IU I6MLEblfky01Y24kt291tshm2r++2c404RHyFRAJKdISNMsXpZn/K9EMB83a9HWFBONdrNPpOYwx NrKbBEj+3n3jJBiznSW0eEjvntLk9ogtTf46Yt2sHOAKDk5dVEVED8PpVOEsuRWMtA9RFaaAUz8o ujFEKozThV+ER2+2FZiL2cFnCbH7DJmhVnu00rR47ympphik1fNld29UtHexr/DX4cBYYgZd5FbF 3JJYSbugIBB11MKPh/zeWBi7sHvBPH8YJYw9hsbdEuASmsnw0yIgEdfWU0pMai8FA0z9knU7navc Yp4SZJRJVxYGHWvytjFojcg5cmpxSytk7+NJ8LfLmxrI6omLROfllKPezVfcGCyxH4T56nGx/AjN LSERXG4uBacboseuLPS7qFNuDnLvTOzUCYRBhYgAi04D3TDd4MzGhTYo6vQhtiGYRG1CSiHNwnWa CRMqk8XhGsmv0XactWdbb/NZ3PlMtFPyRw2NyWgGGub11DmyfFdiMMZsxqKpKgSHRRWfruVuVcuL fGV9OfstQXGrivU/lbPJV0U5o/6hOFUKcKKs3dbXNG7YHfrkxPrrDod9N/YkVXI36LbPvIETvfbg rNM/FHqB5GMvRKai43sNOCEYAy8YRMhFRucsyqk7NiYBejrA34nOs+jIQvJ1lCjyBjQensDJq1oO HE/g49p0qsy69TIzq9Ldn1zGXDINDarSn/BcZvD9BC4S0mdlpYT1TD4eR4k2h88gyRzUi5DSq5Oi Nahfmo/3Sf4V+yYy4zZhX5Cal8iVszotm6x090tzc+FOBPI+l595lEAGNoH0Rfjp1/mBzT2n/wNL T5P43kHiBY8YucnTFdNkJoCyRIkIx14eflryRYTQeA3AxuLvHLRlOijVvzjlXX/rBBlXLw+N4Mmu zkvAQ4WN8Tbheod/rgaX3cH1qBV2z7qDsHc2ug4vOsNe2GuNhlfDVnvUb139G5TdpXGRS1ydE8gH fd6D7q7oNF070r6TRPTsZp86kg9Chgs/dRD7M6m4K+Cwuj5QoT9Cdrv1Qo+3IiTu0j/KsL90aGh6 Z4KnO0/xheuerfxgsM3ENhpwMpotZXXfiHK8LXEZMVR3bllA8CJjcVMmgWR4j8OUUBFb+tbbpnOl rM/qEgk9ltBuVLrDIV7lpt8AAAD//wMAUEsDBBQABgAIAAAAIQDavJtjhQYAALoeAAAVAAAAcHB0 L3NsaWRlcy9zbGlkZTIueG1s7FnbbuM2EH0v0H8g9FBsUXitmy9y4ywSZ7NYYJsN4uQDGIm2hehW ifEmLfrvPUOK8j3rZJMUKJIHh7bI4VzODM9QBx/u0oTNRVnFeTa0nPe2xUQW5lGcTYfW1eVpq2+x SvIs4kmeiaF1Lyrrw+HPPx0UgyqJGFZn1YAPrZmUxaDdrsKZSHn1Pi9EhmeTvEy5xNdy2o5K/g1S 06Tt2na3nfI4s+r15T7r88kkDsVJHt6mIpNaSCkSLqF5NYuLykgr9pFWlKKCGLV6RaVDWBaOk4j+ V8VlKQSNsvmnshgX56V6fDY/L1kcwV8Wy3gKt1jt+kE9TX3NMA2D9tryqZHEB3eTMj084APYxu6G Fpx/T59YxAfiTrJQ/xgufg1nX7fMDWcft8xumw2gQbMpWaUt2jTHNeZcxjIRzGms0lM5ln7Jw5uK ZTnsJPO1eeHZ3Agjm0l8MWPyvoBnJImq5+mHyh9mfqV8ahRtPOF3ekCJcofb87tef9UnfdcNuvSc PNPpep2uq7YwcrCFFlwM5N1xHt2TQ6/xn5TjgwywPLqV+SSWbJJnchzyBKoGNv5qOYvJSSXH8j4R KihwHR8oGSUgkHDKEpG1rsYWi+JSqjixKpWjRHDkUx1KeXjMw5tvvIwqdoCoSIDCiFECHyVrlKcF cHsdJ7G8Z++cX9dEiiw65yW/2CmUgsYHMAVuMu5RHqPA7UaHZ9AxgsuQO+w84aGY5UkkSqb8j8wx SHgkVuIISDdwehJMgsDu2krCInVWYWK7AWFKW68zb3+c6FUPoaIG8vXtGQpl7WINt10Bqf4aWn6f YLwTOzpOKlj40OIescOPyn0C0r/E2Q07ah0PVpG+bghL5kkdcZMJ63gl97j+g+6hVPr0vmcHrblj TjEW1vmBCraWGdvN2XOfr5dXNywG8ssJYM/eAUtrqfdyNl5VomIXpyPme24fJatkVTzNeILzdM3E h7D2HWe+nPpKc9f2njUev/C0+F07xbUdds0rEbHP49HJs+6iAg6yoJnCirPX/aXOmM3s3w66nZlJ kFY5tLLXrhx5UMxxa/TaWei9dhY6btsO9nLVnmm+epqux/j5ypZKaQVX9hsbj8afnxW2II8iI05f Mb4n59jTPwUO+/y2fFZt0RpM5FoQdxWy7Yin3KvyJI5O4yRRX8rp9Sgp2ZzjmDk9XWJ2S9MQ3cU2 hhTVh+3iwZ40bx0qO8rB/0UuweVlyct/ssMTubFvuPEYGBTs7Da9Rp4sE2SPiOfTCbJuptByQzQ6 cjj/z1tegoxYaESJO+sGiFpNYokgtlnTk1ErpDY3ZN/0QviRDzb7mwkae+pu/z7pjbzeaWC3vI7X a/md4LR15Pb9lm8H/ZO+7aAHO/nHqhu9iizPoB0J3eiONnoirROddu4i87Ezrf5ujjwxSh0TpQsR 4k5jCobor4RFeYk8SBusu5A0W2vYXbvTUwwVjZ/jBh0aK6ea5j1wfPWc+lSv7yz6SyOoKCv5SeQp o8HQKqGYciCff6lkbWY9Ralk2tqKWlIVvuxCTDQGXLVSXcGIpvbxMESv5uhHMw5wqpLYWa6IdGlD K1QJTEggSZ6glDayawFmphZiZGs96/kqgJMJDGkW2w8pphcLs0LtjAazWZzGaNe3CUhgVb2znq8d pB2z6GwN2Fkpk1GO0wD9Fs/CWY5bp1CWOl6bSQB8Mp5M0cQ3k+CfLcjefiBBMcL2WR6J1tEC4ErE S8G7uwnvDpnXVB01fgS8fdvrq2uWN3g36fAG76VrLQXv41eCd28T3t0fgnfXc/03eJsaqqv9G7zX 4T16VniHd9m4vn8f0ZDImqrPOG6IcwUG5GNZ8ng6kwy3rRkOU9z5qEtwNblZiq5H4otaCnajqKBi mopEmSc4GFYuWHFL20jQjJHOURot/ayZxiblCXqOurOkM8Hvd3Bpro9QQ3kcu9tVE4jzOJ2+0hrN 0Q7GgzssoU73pzCePVjJdjqzByN5bToj7x6gMwhOaJDTDFbChZjWEHJAcPRbqS0YCpqK2YR6GUMG KZsYQvV9Ngz5QccjKkxvu7ZjyOs5zfudNwwRGd+LEu+JIaDJvNokYNVvO8Ok/IMXX+eKo+IlLppL 9AT4qcA1sy4QS1NAsGNQ8ymVL5mhWaFBwXU5u9QVCa9Ho1vQ7DiLxCTOYikshveuEo3r0MoEXjsD qWDIl/pNYXqR51IdR7UkKFeLplG9HSmPNvFfAAAA//8DAFBLAwQUAAYACAAAACEA/XiMqb4AAAA3 AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxOC54bWwucmVsc4SPwQrC MBBE74L/EPZuUj2ISNNeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdur2NY3iSYld8BrWsgJB3gTr fK/hdj2udiA4o7c4Bk8a3sTQNstFfaERcwnx4CKLQvGsYcg57pViM9CELEMkX5wupAlzkalXEc0d e1KbqtqqNGdA88UUJ6shnewaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kuNrK8 D6qp1dfc5gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlv dXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQD lmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL 5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUd S/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAG AAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 MS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9 axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJ WYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNy plSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwA AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc4SPwQrCMBBE74L/ EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2u tiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVR ac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu +wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0My54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtsk ZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLi wUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6 Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAh ANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwu cmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK7 4DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhd SBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrK GqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAP14jKm+AAAANwEAAC0AAABwcHQv c2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTkueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9 iEjTXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3bq9jWN4kmJXfAa1rICQd4E63yv4XY9rnYgOKO3 OAZPGt7E0DbLRX2hEXMJ8eAii0LxrGHIOe6VYjPQhCxDJF+cLqQJc5GpVxHNHXtSm6raqjRnQPPF FCerIZ3sGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LjayvA+qqdXX3OYDAAD/ /wMAUEsDBBQABgAIAAAAIQD9eIypvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDIwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhI015E8OBF9AOWZNsG2yRko+jf m2MFwePsMG926vY1jeJJiV3wGtayAkHeBOt8r+F2Pa52IDijtzgGTxrexNA2y0V9oRFzCfHgIotC 8axhyDnulWIz0IQsQyRfnC6kCXORqVcRzR17Upuq2qo0Z0DzxRQnqyGd7BrE9R1L83926Dpn6BDM YyKff1QoHp2lM3KmVLCYesoapJzfeS42srwPqqnV19zmAwAA//8DAFBLAwQUAAYACAAAACEA/XiM qb4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyMS54bWwucmVs c4SPwQrCMBBE74L/EPZuUj2ISNNeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdur2NY3iSYld8BrW sgJB3gTrfK/hdj2udiA4o7c4Bk8a3sTQNstFfaERcwnx4CKLQvGsYcg57pViM9CELEMkX5wupAlz kalXEc0de1KbqtqqNGdA88UUJ6shnewaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc 33kuNrK8D6qp1dfc5gMAAP//AwBQSwMEFAAGAAgAAAAhAP14jKm+AAAANwEAAC0AAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MjIueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEjT XkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3bq9jWN4kmJXfAa1rICQd4E63yv4XY9rnYgOKO3OAZP Gt7E0DbLRX2hEXMJ8eAii0LxrGHIOe6VYjPQhCxDJF+cLqQJc5GpVxHNHXtSm6raqjRnQPPFFCer IZ3sGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LjayvA+qqdXX3OYDAAD//wMA UEsDBBQABgAIAAAAIQD1PUbKawEAAJkIAAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlk ZU1hc3RlcjEueG1sLnJlbHPElt9qgzAUh+8HewfJvUb731Hbm21Q2G5G9wCH5KihmoQkHe3bLxPK WugyBMEbIQn5ne98UeJ6e2qb6AuNFUoWJEtSEqFkigtZFeRz/xqvSGQdSA6NkliQM1qy3Tw+rD+w Aec32VpoG/kUaQtSO6efKLWsxhZsojRKv1Iq04LzQ1NRDewAFdJJmi6ouc4gm5vMaMcLYnbc19+f ta/8f7YqS8HwWbFji9LdKUFtIzi+wVkdnY8FU6ErSJJcz9vrwSrx+ITeJ8umQ6LVvknTCHn4Bfvp 2HqdHBw448WhSQS6shPJFaPcQOlisLU6xIxBq+Oq1Y2NldVlXC3TnF7C3hX3Cl9ODo2EPzsatKG+ rqch18shVfclW4bIssmQaM5/OHg5tO7V7GZo98xCHINi9DU0CZFlQwrqSxZ0thiTbBF0Nq60oLX5 mNbmQWv+9hrvssjSENtsTLRZiCwfkyy/kNGbH4rNNwAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+ AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwucmVsc4SP wQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB 3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOv Ipo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33ku alneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDg RfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSw b5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtka xPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwME FAAGAAgAAAAhAP14jKm+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0MTYueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEjTXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+ww b3bq9jWN4kmJXfAa1rICQd4E63yv4XY9rnYgOKO3OAZPGt7E0DbLRX2hEXMJ8eAii0LxrGHIOe6V YjPQhCxDJF+cLqQJc5GpVxHNHXtSm6raqjRnQPPFFCerIZ3sGsT1HUvzf3boOmfoEMxjIp9/VCge naUzcqZUsJh6yhqknN95LjayvA+qqdXX3OYDAAD//wMAUEsDBBQABgAIAAAAIQD9eIypvgAAADcB AAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDE1LnhtbC5yZWxzhI/BCsIw EETvgv8Q9m5SPYhI015E8OBF9AOWZNsG2yRko+jfm2MFwePsMG926vY1jeJJiV3wGtayAkHeBOt8 r+F2Pa52IDijtzgGTxrexNA2y0V9oRFzCfHgIotC8axhyDnulWIz0IQsQyRfnC6kCXORqVcRzR17 Upuq2qo0Z0DzxRQnqyGd7BrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS42srwP qqnV19zmAwAA//8DAFBLAwQUAAYACAAAACEA/XiMqb4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQxNC54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISNNeRPDgRfQD lmTbBtskZKPo35tjBcHj7DBvdur2NY3iSYld8BrWsgJB3gTrfK/hdj2udiA4o7c4Bk8a3sTQNstF faERcwnx4CKLQvGsYcg57pViM9CELEMkX5wupAlzkalXEc0de1KbqtqqNGdA88UUJ6shnewaxPUd S/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kuNrK8D6qp1dfc5gMAAP//AwBQSwMEFAAG AAgAAAAhAP14jKm+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 MTMueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEjTXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3bq 9jWN4kmJXfAa1rICQd4E63yv4XY9rnYgOKO3OAZPGt7E0DbLRX2hEXMJ8eAii0LxrGHIOe6VYjPQ hCxDJF+cLqQJc5GpVxHNHXtSm6raqjRnQPPFFCerIZ3sGsT1HUvzf3boOmfoEMxjIp9/VCgenaUz cqZUsJh6yhqknN95LjayvA+qqdXX3OYDAAD//wMAUEsDBBQABgAIAAAAIQD9eIypvgAAADcBAAAt AAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEyLnhtbC5yZWxzhI/BCsIwEETv gv8Q9m5SPYhI015E8OBF9AOWZNsG2yRko+jfm2MFwePsMG926vY1jeJJiV3wGtayAkHeBOt8r+F2 Pa52IDijtzgGTxrexNA2y0V9oRFzCfHgIotC8axhyDnulWIz0IQsQyRfnC6kCXORqVcRzR17Upuq 2qo0Z0DzxRQnqyGd7BrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS42srwPqqnV 19zmAwAA//8DAFBLAwQUAAYACAAAACEAwrM8OiEBAADQBwAALAAAAHBwdC9zbGlkZU1hc3RlcnMv X3JlbHMvc2xpZGVNYXN0ZXIyLnhtbC5yZWxzxNXdasMgFAfw+8HeIZz7xWjb9IOa3oxBYVejewCJ Jx8s0aB2LG8/KQwSKI5CwJuAiuf8+CvmePrpu+QbjW214kDTDBJUpZatqjl8Xt5edpBYJ5QUnVbI YUQLp+L56fiBnXB+k23awSa+irIcGueGAyG2bLAXNtUDKr9SadML54emJoMov0SNhGVZTsy0BhSz mslZcjBn6ftfxsF3/r+2rqq2xFddXntU7k4LYrtW4rsY9dX5ssLU6Dik6XTeTgd0n3o/kPu0VVTa OkTbRqXtQjTKlrQ5f9Nwdpa3GXL7spBjUcbDF2sVotElE3qYFkwtj0rbBlOLGhsLxraJGlsejM0/ +fFeWEZDtnVMGt2EaPuYNJb90cjsP1z8AgAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAA LQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc4SPwQrCMBBE 74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/h dj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTW VbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U2 6mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk 2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZC I+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvz f3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAI AAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDku eG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/Wsa xZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmG SL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZU sJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA cHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDYueG1sLnJlbHOEj8EKwjAQRO+C/xD2 btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYg OKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnO gPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsB AAD//wMAUEsDBBQABgAIAAAAIQCsAGq6qgMAAPkLAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDIyLnhtbLRWwXLbNhC9d6b/gGHPDEmYpESOpYxsS70ktqdSekdIyOQEBFgAUqV2OpPf aj4nX5IFSMixrE7pWr1QFLH7sPve7gKXb3cNQ1sqVS34xIvehB6ivBBlzR8m3ofVwh97SGnCS8IE pxNvT5X3dvrjD5dtrlj5juzFRiPA4ConE6/Sus2DQBUVbYh6I1rKYW0tZEM0/JUPQSnJ74DdsACH YRo0pOZe7y+H+Iv1ui7ojSg2DeW6A5GUEQ3xq6pulUNrh6C1kiqAsd5PQ9L7FrIFYvSq1ozOeLna ecjayy2sRN4UKCiWrEScNPDhVzCtC8KQtUfAGFrRnbZmql1JSo0D3/4s22V7L6337fZeoro0aD2K F/QLvZn9y8EMXoIj9weHRPLdWjbTS5IDO2g38UDEvXmCE8khCFR0H4vHr0V1d8K2qOYnrAO3AURw 2BT0b7uMnqeDXTpHpESH9DofAhjvRPFJIS4gYcNDl2dxu3WoJnmzT1uhThNt9PCQkDUo10nUe3Wm libnrSzVLv4DQWmKszjsaMKjOL0YP+UKh8nIrhvGknESJTixmzgk2KSDbnO9uxLl3jD9EX5BUFM0 E48Sk3wHy5Re6j2jVg9gjeSQEjzAmBHTaJT7H5bQaI2+ZpRAI/ba6ek1q4tPSAtEy1qj90RpKpGl ANoSIC9BHA210UNSXt4TSX45Qjaskhx2hrhdvDYFw+w/63jxXEdTTfeMFLQSrIRQsMkQGsEJ9p8k NcQdKQptATXr6mG4snEygsFi6/+UsGkYZWOz/n8JC/WG2JYdFHyl0IZuq7N6InQnplUUHm5Ly9YL amtJCwFjitEtZQPgrdQvgF9VtRyOftG1ymC+FmIjdTU4+Pil8PX6JDrM07O2WOxa7IZo+qSzLCGv 7axSw1T5A45CwtZe31N2ttgpaSarffl+XNp+dkPCDTU7uZ6PsTUcf+b8+nMczePsIkn9+SKa+XGc Jf4sxNjPomg+T2bZzdXo+i+vn+AlpKrrhi7qh42kdxtzSA6bhlEY4AQO/Sh8rFeIwbifV5bEybIQ wkzc70eeLaXXCrPWslPmtw2RsIMT518m3kvEOS8jqWNkyeqSottN8/GIF3tCvpYXuFQC9Elq7Pw5 c93OwizFoxD7cXZlH6E/xjj08TjNcJJe4ewmPdStMplziG5ouX79/PdPXz9/OUOt2sO6u0TCq7l2 2lOXyfekvdvaoQkXbqija/uphSs2lIoxfTQxGO7KPv0GAAD//wMAUEsDBBQABgAIAAAAIQDNR7w1 JwgAALQwAAAhAAAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s7FtvbuO4Ff9eYO8g aL+0KDS2ZMmSjXEWmWS8HSA7DTbZAzASbamhJVWis8kWBeYOe4O9xW6/9Shzkv4eScmyY884TQIk QYCBI5GPj+T7vf/2vP3ueiGsK17VWZFPbPdN37Z4HhdJls8n9k/nUyeyrVqyPGGiyPnEvuG1/d3B N396W45rkfzAaskrCzzyeswmdiplOe716jjlC1a/KUqeY25WVAsm8VrNe0nFfgbvheh5/f6wt2BZ bpv11T7ri9ksi/lxES8XPJeaScUFkzh/nWZl3XAr9+FWVrwGG7V67UgHuF98JhL6ezHXnz/ymZUl 15BSv+/aB2/ZWN2TH4nKumJiYl/MXbt38LZHS0BsnmhxXZ5XnNNTfvV9VZ6VpxW9xB+vTivwBEvb ytkC8iUGasKQqdccZJrx2vJ5w4mNr2fVgk4E8Vg4IVC8oU8sYmN+La1YD8ar0Tj9+xbaOH2/hbrX bICrtZvSrfSNbl/Ha65znknBrVPBYp4WIoGuKBGpG+plkGJ5UsSXtZUXuDOJQl8VwmkY0/1pqzK1 5E0JKUlia+j0JE6Wt/S1km9z6FYqfhBC6ZRovNAfDqJ1+USeNxrSPEnJdf1BHy90lhWjsqrl97xY WPQwsSseS6UI7Oqklpq0IVHo64OUY3n9rkhuCIwL/AXmsDisT4vqF9sSH/J6Yo9c38feUr2ok9pW 1Z25WJuR4qiAymEFy2PwmdixrNRZcljb4VIWs8ycSG9Jm4tanskbwZVaADw2hljxgQMJRgbPc+en Mxj8Qh4JzuAQjArJgyORxZeWLCyeZNIydq9ggHsAS5KSVLJSLHmenLKK/bjB2YhIyaaRCZDTirRb nQatOpEud7XJI4Duq00kINuY9n2UyoX2kIIp8TZWt6ZVfuAFo+Hg6WsVqcWdFAkWZ4krpZHq+vdU LJKe0qt6TbGgZEpt9UezpfIYd9DlMx4XeWIJfsXFHuyVjt2B/XmaVftzV8pwB+7TYlnJdO/D+1ob 94Zjms22ckcYeVCT9huTPmZyPUAogdzXpBMJL/YLPCwTM2PaCkYVJiiY3DFeDAcB/m2YthsGXhsw BsPA9YKnb9lr8UKZahMVVIS4Ei6ZMhNzeH9h01jCZ+THSZwuuTcaqwuRJdNMCPVC6d4qDZLXOjuS WS51YhQGq1Da5kwqWHT4wLb1TmoCvoQOop9N2KK9lOXPRKKypn+F76eH7mHkOkHQnzr+YXTkjAbH vnM0jKJ30ftBhBj+bwRVlTQk0DSZLbg+3deDHrZX8pEHbr/nBcg13f7KXeAMdJ4dVmElWSWbZEt7 LWjcHUJe0NjHtCgoxe4GPWXT97WQGdIFhek/l6zCDsZKdGyiZGpfK/GGw5DgpYxzq5n4ETJ9IqC8 6iWaSZN5PT1Dgf1sS+8aS15p6baU78/WSts1o/+LGy1KRZZf6hSyGlO9U31I3CYNgiUSjTyg6rFG +QhDZbJi8SWv3mRcznThWMRUPM6kw+q0uHTimC1KZ74oRe0UdTlz5mF/1HuQExurt/6ywe2xbH3Y 2PoZnCq3Pi4XFxsWr+LKfS0e9TpYbzN65VDuFBqjftjWUluNfthf1VIv0eZ1rfX0LL4Njcfh0SCc jvrOIBiEjh+Mps6hF/mO3x9Fx1HfBTzHbWisSfFyKMd2C98sB1eR8fOn37/9/OmPlaE8QFiEIjb9 Ejw2XZhYVD+w0kKPBXmJRL8EacbETi7xdDH3aAxNB3mNp+QSTyyO0dgBhXloRjCvR1qaQTOCKlNP +c0IklQ9EjQjCMt6ZNiMwHiVd0OuSU7OtmaF+Bs9TezmiZJC3EkkJ+ymWMoPCZoFGyMqnfFcP/Sj wdAfofRv3eSt1Wu0yElXtKYa7uy0TgtZtXxNmr2TFvJpaU3CsZMWkmtpjavaSQuZtrTDr9wN0m5p w6/QAoeWVjV21iS+LoewQzv6Cl/0P1u+rioAvsB4DbimkdURhQE+nVlpUqnuDdIw9TdBO8hwl9eq SVOTiqgOi3olyzRJscnOKe2w4IHO2cUZIrpqIJE2SN0X4uwkf1dBDYE69Udz8wqSFM0eNGFPl3mM bU0vs4zfUc+S+nHxaWwyd3Uk5K8YM7MXy49oBKsQ2fF+6F2BLwI2NZH3LRLAhFh3Swl1UJWvz9Ay nNh/XfzDEZIgQqrNNiY40xNxvTER1zSxq6BYlyqatWj/3BLxglUnyFZ9b0QXy3K4R4jKaQaa+uix 5Q9RYn8jqA4G0wK1FZU1WkyHVcaEbZWZjNMpW2SCMm1YWpyyquaNaqH7uDzCiBqe2J8//abl18Fx QNg9Co75LhxzZweOufNFHJU5eFSsaqxCYEXesMXKiwIUnnDYppZ93lj9egsrD3XVk8eKADKua7DC qumud8DyIlUjvgywbhuW92gO8gENixAyYPkdsExb+6WCtcWyVD/jMaLZA4JFCBmwghVYXj8Ilaqt 3OALsqz//ue2F3wOWBFABqthB6vA9ZXTe5FYbUsvKJ158iGLEDJghR2wRqGrAu4rWF9q/O+V0z+g FySEDFjRCiydpq8lgy/ICz5byyKEDFijDlhRNFRlx6tlPSXLIoRQRK/Vx+W4kCmv2moZleOphtTU kN2fkbQluCFpuhe6XHuUwqxTyWpn/cRzOP0V52Yl2/xO6eFroecmn+3VY9PpepXPjoJtENJPkR6j 8/HcFGh7keRGXqRyuVcN2lGZqGzpVYMQsnZUA6GvW6WvGrQjA0dGp/oQrwLakfUOg/DVSavUp800 u8klEs/VF2H0lXDzvw0O/gcAAP//AwBQSwMEFAAGAAgAAAAhAMRrM/vaAgAAKwgAACEAAABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWy0VUtu2zAQ3RfoHQh1rUiy5Y8E20FqRd0kjlEn B2BEKhJCkSpJu3aLArlWe5ycpENKitM0AdLW3dgUOfM4780MZ3K8rRjaUKlKwadOcOQ7iPJMkJLf TJ2ry9QdO0hpzAlmgtOps6PKOZ69fTOpY8XIGd6JtUaAwVWMp06hdR17nsoKWmF1JGrK4SwXssIa PuWNRyT+DNgV83q+P/QqXHKn9Zev8Rd5XmY0Edm6olw3IJIyrCF+VZS16tDq16DVkiqAsd6/hqR3 NbDVpWb0grOdg6yp3MBm4MyAfbZiBHFcwcalsULWzJyo+lJSalZ880HWq3oprcNis5SoJAagdXS8 9qA1s58czGDhPXG/6ZBwvM1lNZvgGLRA26kDKduZX3DCMd1qlDWb2X43Ky6esc2K02esve4CiODh UsOqYfQ7nV5Hp9EheGDVmGJwPRPZrUJcAE9Dv6GXLTYdmOFs4OsCPRK+tWsOrR6dvQJNrVh6+16Q nSF+Df92E8dM6ZXeMWoFgbBxDODwA/IzbOqacvdqBXVd6TmjGOq+FU/P5qzMbpEWiJJSo3OsNJXI VgF0AUBOQB0NyWkhKSdLLPHHJ8iGH47hZgi6ixCWjYQvC9nvhEywpmjJcEYLwQhE0DuEpkQD5S/Q FpjlDhQiVElgiVtpTQL+SeMc+sFU99d+L42CKExdPzgdumGajtxxMobVPBqOxienSRIk35w20QSo 6rKipqlek6Im8SYJge/1BvAABP4+KRCDgXkhLYiUUndN8TcJCrsEpUKYwnicov4hUpRr2eTo0xpL uKFLU9cyB2iF/6XNoNNmxUpC0WJdXT9RKDyEQjB0APpZkWyTHLiWk9G8P0oj3+0P+iM3HESpe9Ib h27oR1DTfhAN/X0tK8OcQ3R/Wsr3d9/f3d/9OGgd2/emGUSwNNPKzhomz3F9sbEPIoxoqLG53aph KLfP8t7EYHRDfvYTAAD//wMAUEsDBBQABgAIAAAAIQDceRPApQIAANkGAAAhAAAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDcueG1stFXtbtMwFP2PxDtE5neWr3Zro7ZTm1D+jK2i2wPcJe4S zbGD7ZYWhLTXgsfZk3Dt1BuMIQ1R/rTOzb3H95xz7YxOtw3zNlSqWvAxiY5C4lFeiLLmN2NydTn3 B8RTGngJTHA6JjuqyOnk9atRmypWnsFOrLWHGFylMCaV1m0aBKqoaAPqSLSU47uVkA1ofJQ3QSnh E2I3LIjD8DhooOZkXy9fUi9Wq7qguSjWDeW6A5GUgcb+VVW3yqG1L0FrJVUIY6t/bUnvWmR7zYDf Es+myQ0GIjJB5sWSlR6HBgMzm2GCqr2UlJoV37yT7bJdSJt7vllIry5N7b6GBPsX+zT7yDENF8GT 8huHBOl2JZvJCFKUwNuOCTq1M79YBCndaq/ogsVjtKgunsktqrfPZAduA+zgYVPDqmP0O53Y0clB U2/BoKCVYCWVXvRAsKsCRDkTxa3yuEDKRomOaXG+cbiGvtmprbxO+lLj4H1GE4GtCOqH5CJL1ipk ku3C1SuU2+qotzNR7owm1/hvg5AypZd6x6jVChlBukIHjSlf8rjfj/Pp3M9nxwO/l017/qCfDP1p lGSzOIvj6TD7SlxTSFXXDTVjAKlEY9F+PCiU+1dL7LfRGaOAB2lvS9cUpHoShUHcx3GNwhEqrbF7 24P1jpcLkPDhKVpZS+28xGxsGxk7erjsrPmzQYkzaC6ERlt+tig+hEUrLTuPPq5B4g7OJmdv5+k/ 2UT/kzY9p82S1SX1ztfN9ROFkkMohFckQj8rknXAanPAWT7JkpP5MPSTfnLi9/rDuT+NBz2/Fw4H +SCMhsdh/jDLyjDn2N3fjvL93bc393ffDzrHdpy7+xOX5n61VyST76G92OBhhxQ/KDhjmQ21+AnZ XyGPKQbDfZImPwAAAP//AwBQSwMEFAAGAAgAAAAhAFQzgr/yBAAANBIAACEAAABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0OC54bWzMWNuS2jYYvu9M30HjXhMsH7BhFjIUSm+SzU4hDyBssbiR D7UFgXQ6k9dqHydP0k+yxQLLBtjdzvQGhPj06T//v33zdpMKsuZlleRZ36JvbIvwLMrjJLvvWx9n k1ZokUqyLGYiz3jf2vLKejv48YeboleJ+B3b5itJwJFVPda3llIWvXa7ipY8ZdWbvOAZ/lvkZcok fpb37bhkn8GdirZj2512ypLMas6Xl5zPF4sk4uM8WqU8kzVJyQWTkL9aJkVl2IpL2IqSV6DRpw9F ktsC2ubz32cbi2hYucYGtQbQPJqKmGQsxcYozyQYyOdELsmIFUoOjamKWcm5QmfrX8tiWtyV+ujt +q4kSayoGgqr3fzRwPTPDDAs2kfH7w0T620WZTq4YT1YhGz6Fhy3VZ84xHp8I0lUb0YPu9Hywwls tPzlBLptLoAEu0vh86LW6LE6jlFnlkjBCd1pVUMZjr7Lo08VyXLoqdSv1Ytu14ZM6azoiyWpzS8V VYOr/9T2MPhK29QIurOE5weILW0OJ3Bt/8gmrm2HLnUtoixDacdpEPsa18xFT25+zuOtsugc33Ac y6JljkCd13YWlZzKrYCbWU+sBYVAhIl7ZJJAELBezBe/Yav60rcgEmSaG8V3ePgY6z0eWJj1YAd8 4KhgKhF51vo4RSKmciQ4A32jkxyMRBJ9IjInPE4kec8qyUui7Ya0hWSKXeo7NCXP4jtWMiXUPrNy BevhZtjX6Ixl7e2nfQ4jHmbBnWARX+YihhDOyyIgiRG/Jkgud77rB75yqEqGU973KaVA1N73Q9+l CIVa/TqhtNp1HBpLGO/r1Np3VePyI0+7Kvpqyj0Alk4Tr/tREe5jDQBY9wTW28caALDeCayKtp0M BgCsfw5rAMB2zmENANjgHNYAgA3PYQ0A2O45bA04lUM4ScCwS5YX5pSqqTqlqoOcqvNGJw8+zJU6 cK9I4ymP8iwmgq+5uIBe59YV9LNlUl7OrhPiCvZJvirR/S4V3lOBeQ19sjjJjjb3qtXMM9Vsply9 X8q0QdD2Tat6VjNTHQQlHK1gycTCwgyAAqcdqZuaKjl6MdURr4qv2vped6Oe69M6zx9a/kF78zpd andeXOBIysp3esRIshjTjloq0earWwyF2pt7NY0e1CnVExUWmajKW0NlevRFfAf19KhGNnxd6qlb yUV8B7XxqI42fNQNaOdSwu53aq3hC51QlfqLBDzgO6rHDZ/jhBDvOXxHNdvwBZ5uW9fLd1TXGz5F drFDDvQ9qv2Gr+MHz/PH/6M/ILPNNKEHDDXmPj1X+aYSjZnkB5VI186XVqJYPqpDtJ4W1NPGyUKE HH/Q4OQ8pKuAnl0XeDhSDzh/Ou6I+kPfa03sidvyPHfUCu1h0EJoDMd24A2HHv3Lamb9GKrKJOXq CQvN4WhAfTz6opboK+WA2m3Hx5MgtR86J2RQNE80CBInpTTPRc8ZfDvGQZM8VwP3frPwVXt7qYsW sqx99MeKlbihaRf0zEB8jZv+K9sExjZTkcSc3K7S+ZGFOq9hIbx9APVJI51pqtcYaRfL42DkBpOu 3XJ9N2h5fnfSGjqh1/LsbjgObdrt2ONdLFdK8wzSXRvK377+/dO3r/+8ahzrelO/i8BSvbrQ4SnK 96z4sNa9Ge9qEGMjvVXg7QwspKAPEMVh3vYM/gUAAP//AwBQSwMEFAAGAAgAAAAhAFPVO/auBAAA rREAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OS54bWy0mOuS2jYUx793pu+gcT8T fL/NQiZA6JfNhinkAYQt1p74VlkQSKczea32cfIkPUe2AG/YhnXIFzDm6Cedi/5H9t3rfZ6RHeN1 WhYjzXila4QVURmnxeNI+7CaD3yN1IIWMc3Kgo20A6u11+Nff7mrwjqL7+mh3AoCjKIO6UhLhKjC 4bCOEpbT+lVZsQL+25Q8pwJ+8sdhzOknYOfZ0NR1d5jTtNDa8fya8eVmk0ZsVkbbnBWigXCWUQHr r5O0qhWtuoZWcVYDRo7uLkkcKvC2SqPVXiPSjO/ghqGNwfNomcWkoDncWKSR2HJGPqUiIVNa4Tqk TV2tOGNoXex+59WyWnA59GG34CSNEdUitGH7R2smfxZgBhfDJ8MfFYmG+w3Px3c0hIiQ/UiDxB3w EwbRkO0FiZqb0elulLy/YBslby9YD9UEsILjpJDzqvHoW3dM5c4qFRkjxtGrxpTC0Psy+liTogQ/ 0f3Gvehhp2DoM+KrhDThF4hq7Zo/ZTyUfS1jqhZ6jIThBabpQ92C57YPVaY/iYpj+64NNwnGxnFd z/LlJIoEkzToKhT7SRkfMKRr+IbM0SJKSqjUNY6gYVaLpThkkGe43mUGrIjQ7BG2UgZVQMOYbf6A W/XnkQb1DlOuledHe0hylwMhpiEEAj5gaEZxJ7Ji8GEJOzEX04xRwLcuifE0S6OPRJSExakg72gt GCcycLBvYWVIF3IOiWRFvKCc4qLOyZgLGsLM4LvyWYYB8/F80i2VdLUNFhmNWFJmMSzCxBDBZlEJ 7lUCsAM12C5Qy6pg+hWCa5ie5zRJU7ujUwe2YWCxXFsIz2Y/p/xe7sa0iEFa8BJTud4+gH7KUWc1 YUFRtDO21YO2cGliITUo2/HQilzDM08etJCWZ514gWHL4r+Kh5ZNbQAPIS3PPvEMyzNwi123QNwE RyBSWqBzBvRh9/YDIqUFuicgqAEssNcKkdICvTOgZ8vM9XAZKS3QPwGRdn1SOjFESgsMzoCu4/VM ClIua9Iz2kHilAvVZfqoiK1UZIU781xCLKyVH5UQVG6QTpDghGabVk2kOMluIr3FNruUjivtV83g YltxLGgaTdc4NduOnPg6NJlmEkX6n7YideFSL3mRmhid3Yq9qC2MnmpidNQJIS2vp5oYncK9gZoE NxaTDu8GWtLh3UBKOrwbKEmHdwMh6fCe1xEoJALt5HiIkWXV/6yDoiGPOnXnrNNHiRylRDMqWEeJ 7FsoUSy+0SGjaYeoPxeFSOqfOpGpU2hHLuQPeWbcwFMJPln8Zb513cCduQPPnVgD2wwmg8lEfzPw 53PTcOyZbsycv7X2kB2DqyLNGT7aXHPkhOzJKcXY0IemA49ghn4KPKwBMT+rVbgqQfOyxIPuebOQ p7sfbRYbwZsc/bmlHGZQh8/vnD5fkqafFRtPxWaZpTEjD9t8/SRC7i2KGB77AX0xSN9pqi8J0rGW Z97U8uaBPrAcyxvYTjAfvDF9e2DrgT/zdSNw9dmxlmv0vIDVvbSUv37557evX/69aR3Lft+8BIBL fGcgzzIZf0er9zspevCSBGpsKm9V8FoEIoSmJxNkqNcs4/8AAAD//wMAUEsDBBQABgAIAAAAIQCl ZYlFcgUAAKkbAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDUueG1s7FnbktpGEH1P Vf5BpTxjdEWIWnB5weRlvbsV8AcM0rAo1i3SwIJTqfJvJZ/jL0l3SwPiIluwmypXhRcQ4uioL9NH Pa2bt+soVFY8y4Mk7qv6G01VeOwlfhA/9dWP03Grqyq5YLHPwiTmfXXDc/Xt4OefbtJeHvp3bJMs hQIccd5jfXUhRNprt3NvwSOWv0lSHsN/8ySLmICf2VPbz9gzcEdh29C0TjtiQayW12dNrk/m88Dj o8RbRjwWBUnGQybA/nwRpLlkS5uwpRnPgYau3jdJbFLwVjwn0/X0OXmY/a4qBM5WcFpXB+C/Nwl9 JWYRnBgmUcqyIE9i+idPpxnniIlXv2bpJH3M6IL71WOmBD4SlBeq7fKPEkY/Y4DBQfvg8ifJxHrr eRYNblgPoqGs+yokbYOfcBHr8bVQvOKktzvrLR5OYL3F+xPotrwBWLC9KeQ7LTw6dseQ7kwDEXJF 33pVQBlcepd4n3IlTsBPdL9wz7tfSTL0GenThVKGHqlKXPEnxUPic4gpBUusbxN/g47P4JtOsl6Y i4nYhJACOF6FOiWA9Xw+/60IbeU0eFuFg5OsB6bAByQrZFgHPG59nEAdRGIYcgZ1UoZaDIZh4H1S RKJwPxDKB5YLnimCopCjATfALiCVJSWP/UeWMTBijxmjwXpwZ3BR+gOHRcDrw25uw445fwyZxxdJ 6IMFxmtkAOOpwnKFtSQTVpMIjNbBkrRsBwqc1qVum7aum2jSbnVamqXpXRAXXKMd03U6ZDOEoSAi 94slISMiM6yw2FskoBazgrKavTLZSsSyO6qLIPahwPEQ7z5b3oOKkSHFWlDyz33VsNDSmXSzsjbo 0IDVUxJKrxqxasesSIV2gJnmjtXVLbKgCavePWZFqpLV2rHqpqN3ENyIlpD7IUCuktau0HaNLtlw KS1ylbSdHa1hdMGEF1iLXCWtU6F1LJPW4aXWIldJ293RImfzlJ2ILXKVtG6FtmM7L0oZcpGWVGuC FA1vAqtuK11098sVDgWHBC7fU7hLVMySKjZMYgG1uidkpBrwqJUPijMfJVjdCxbOSxkrJAYfqxQm PKg+TzAh9TJm6I7VdexvyJjp2joUByKa6BjJUDVRR0+qnToVlBUAHEoxqSoZltAWKwGAlRJRwZKS bLESAFhZ91UsrsotVgIAK4u5FisBgJUVWouVAMDKsqvFSgBgZS3VYiUAsEWByE6A4ksiufXtx6gg agbgQxYtPX/PaEsm3EtiXwn5iocnCvSQnuriDPrpIsias5dP/saKM06WmVg0Nt4qKrI5fTA/yQ69 yat2Z7bUtelhd0YWXy5qRX9cdGcocH8sWQZtZ6lxFG1qlRtrXMeyNQPMhU6srlfTHVC+a6/WV6+9 GvTL116tr5r/x16tIzXtVK9GrdHlsnYsZaSTF0tZXb+2k7Jrv4Yx3+9/rv1azUznmzuew4bq2q/h CK3YDR7G5kft1xypbSMm+N4mtIMd5uXCVvRrvoAB4v52VC/2VLX7Ubrr4fQLTu4GlvSD9vdzmEXj ZPnP8djQTHc0ahnvulrLspxh63Y4tlvue/d2aLq6bo87f6nlkNUHV0UQcRxoNxl4woaEbikGutY2 bBi/69pufwE2IE1NG634QSbkQPqSQQEMC4tp+zhJcMxaHXg6r5GiuYAm+vgxpH9n+nlOmv6r2Lgy NpMw8Llyv4xmBxGiscRLFzG88gHqk0H6zmzlnCBt1/LIGZrO2NVapm06Lct2x613RtdqWZrbHXU1 3e1oo+1aztHzGKw7dyl//fL3L1+//POq65jG18VLIDjEN0WkIGH2gaUPK9qrwgsyWMVDOpXCKzGI EEJ3EOSQr9gG/wIAAP//AwBQSwMEFAAGAAgAAAAhAOv4TksWBAAA2hEAACEAAABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0NC54bWzsWN1y2jgUvt+ZvoPGvXb9g22MJ9AJEPamTTKFPoBiy8Gt bLmSINCdnelr7T5On6RHskUIIQs02bvcgC1/+qTznR8d++z9qqRoSbgoWNW3vHeuhUiVsqyobvvW 59nEji0kJK4yTFlF+taaCOv94M0fZ3UiaPYBr9lCIuCoRIL71lzKOnEckc5JicU7VpMKnuWMl1jC Lb91Mo7vgLukju+6kVPiorLa+fyY+SzPi5SMWbooSSUbEk4olrB/MS9qYdjqY9hqTgTQ6NkPtyTX NVgr79jVzRcLaRxfwohnDcD0dEozVOESBmZ3DI1YJYFGPxL1jBOiQNXyT15P62uuZ1wurzkqMsXQ zrSc9kEL07cVwODC2Zl+a5hwssp5OTjDCSiBVn0LHLZWvzAJJ2QlUdoMpvej6fxqDzadX+xBO2YB 2MFmUfB13Vj02BzfmDMrJCXI21jVQDFM/cDSrwJVDOxU5jfmpZdLQ6ZsVvT1HLWyK6oW1zzUehi8 AE21WHI1ZNlaGX4D/3oQJ1TIqVxTogWBbeMEyOEH5KdYRTWp7M9TiOpSjijBEPWteHIwokX6FUmG SFZI9BELSTiS2i6hKM9AHQnOaSlJlV1jjj/tMCv7cAIrw6bNDuGykfBpITtGyDaa0DXFKZkzmsEm /OfJKr5DNmCaWxCBEB7GB09oq+TaibIg7EK+6lDzItdV11pfE3CB24lh3EIq7ILQD3tRRzvQMGkB GjcbTfZ6Ta1Nl9TTaYOTjORKXrV/P24WBW23AHDp78EG21gDAGxnD9bdxhoAYIPHWO/BHgwAsOEh rAEANjqENQDAdg9hDQCw8SGsAQC2dwjbAJTWbTopx+hsgpkIGDZp88zsUhGkk0s8yK4mg3aX1IF7 QkJPScqqDFGyJPQIep1lJ9DP5gU/nl0nxAnsE7bgcn705oMmI492x6TI97LDKfKidS34r7qmNYHz 1BwGJx4XO3VN+08fFarS6IvtM2NfXYuC+LWwwYnwWtiS18K2aYReC9sRDVtoCtsYS/KgW9Ol+Per WtMEZxJ61J2+TTvo6QJ3SlOcwxuMeh35yzsPhx13dGEHF8PQDibnsd0benAbjF1vGExGYeT/bbWd eQamyqIk6jUIjrKdzvdxTw05pftEOfBcxw/hfc1z7w9i2IOieeK8QVnBpXmL+Z2OOjIOmjCmOvnt hjpUp+VzXZRL3vjo2wJzWMG01wf661Pc9H9p0zXaTGmREXS5KG92FIpeQiH4RgDUe0U6cFifItIm lsfdUac76bl2J+x07SDsTexzPw7swO3F49j1epE73sSyUJZXsLtTQ/nnj3/e/vzx74vGsa43zZcD uFTfF3R4Uv4R11dL3dTBFxWIsZEequEbCiikoPcQxWG+yQx+AQAA//8DAFBLAwQUAAYACAAAACEA wg5d/osEAADLEAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbMxY23LiRhB9 T1X+YUp5ZpEEuqAybDlgkgev1xW8HzCWBqPa0SWjMYGkUrW/lXzOfklOjzSAHW8twRuXX0DMpfv0 6dMzLc7ebgrJ1kI1eVWOHe+N6zBRplWWl3dj58PNvBc7rNG8zLisSjF2tqJx3k6+/+6sThqZXfJt da8ZbJRNwsfOSus66febdCUK3rypalFiblmpgmv8VHf9TPHfYLuQfd91w37B89Lp9qtj9lfLZZ6K WZXeF6LUrRElJNfA36zyurHW6mOs1Uo0MGN2P4SktzWibUT6s+CZw8xCtcaQ50wQe7qQGSt5gYGF SMk5o4VCmdmmvlFC0Lpy/ZOqF/W1Mpuu1teK5RkZ6TY7/W6iW2Z+lliGh/6j7XfWEk82S1VMzngC Nthm7CBpW/rEJp6IjWZpO5juR9PV+yfWpquLJ1b3rQMg2DlFvus2on+H49twbnItBfN2UbVLObZe VunHhpUV4qTw2/DSq7U1RjGT+XrFWuo1merWtZOGD7u+MZxaoDsmIt8feANDx3DohiP3ESlRFPlD DDKixhuEvhsFxom1BCet6TrRmx+rbEuU3uIbmeNluqqgUk07eCIbvdBbiTzjeS09IGJc3qGMJFTA k0wsf8FQ8/vYgUv4vDWJTzkY4FJ2brudSPdDiyCbJ6AEHzAiOdWjKHsfFqjHQk+l4HDURacnU5mn H5mumMhyzd7xRgvFDIWoXmAk69r4MCZFmV1zxQneoWXKCk/gGSzY6A0hlJkvpx98t6VwQ9q7ljwV q0qiGJhPQaJabJ5PUgKx76BsoGkrnJME4Y/cMII4TPJslTwUROC6Xhx1mWmL7BhB3LY2nxJEwdWl KdC8zHDS0CPl9Pb+CsepQXIgExyJ7XRTyTyb51LSWnOaiqlUbM0l1LehIwjpzEvdjkSAbZSA5O0W m1Qe2MFc68lM7FRnpOuTdFukwyACCtB9BFwvfkG4hJHCBvLBHu7IQ5kfCzd8QbiEsYM73MP1BpFH KI6jlyIzAngBNRDIDm9wgDf2Y0ry68NLIDu84R6v78eg9zXiJZAd3ugAbzQcHF9uL6kHAtnhjfd4 Cezx9faSeAlkh3d0gDcMotdZbwSyPYkPughz5xN6HHK7y92EdXoPQBedaQGaBz3AKff80N7zM67F g3veXKrPveczjdYGzdKKy6W979trjRphQxc9LAxzbZtmugvbqdg+zdyq9i42PwyvS3Ts1Hv/EcSz wfks8nsBuoHeMAi9XuyPwt7FhTs7n4bT4GI+/9Pp2tAMoeq8EO2d+/U0AJxxqSee2/cDvKB47p54 YCCRfqH9YlmutG3ZT0lQYBM0rypqAA9bsSH1KM9N0VKrNke/3nMFDzZNX+nLjOcj0/R/cRNabhZo rQS7ui9uHzFkXgSeyxBeimH6SZJMM4x28ltqeRZNB9F85PYGwSCClkfz3rkfD3tDdxTPYtcbhe5s p+WGIi+BjjT4X6T8+dNfP3z+9Pc31bHpq9vXZDzS+7SRp1TveP1+bQ49/IUAjaHxxVCNPw0gI1q6 X0I27J8Qk38AAAD//wMAUEsDBBQABgAIAAAAIQCHZz1sTgMAAAgLAAAhAAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDIueG1stFZbctowFP3vTPegcb8dmzd4gEyC4/7kwRSyAMUWsRtZciVB oZ3OZFvtcrKSXskWaQiZgUB//JCvju499/hI/dNlTtGCCJlxNnBqJ76DCIt5krH7gXM7jdyug6TC LMGUMzJwVkQ6p8OPH/pFIGlyiVd8rhBgMBnggZMqVQSeJ+OU5Fie8IIw+DbjIscKXsW9lwj8HbBz 6tV9v+3lOGNONV/sMp/PZllMQh7Pc8JUCSIIxQryl2lWSItW7IJWCCIBxsx+mZJaFVAtv/vqIBMk FvBac4ZQdzyhCWI4h4FppihBwA4acaYAyQTIYioI0aFs8VkUk2IszLzrxVigLNE41XzHqz5UYeaV QRg8eBvT7y0SDpYzkQ/7OAAy0HLgQM9W+gqTcECWCsXlYPw8Gqc3W2Lj9GJLtGcXgAzWi0K7i7Ki 1+XUbTklHbV1VWUohqmXPH6QiHGoU5dflhdfLyyYrlnDFykqmVea2Squ/Gj4sPESODVkqeU5T1a6 8Du4m0EcUKkmakWJIQTSxgGAwwXop1gLmzD3dgLCztWIEgzCr8hTwxHN4gekOCJJptAVlooIZJKB 3wAg+8COguZUkIQlYyzwlw1kXR8OYGVI2mYIjyWFbxPZsERWakJjimOScppAEvXDaM0SEIVl/giM QgMQXdA1dQcyrGVrCJYvGC5ZNFTCxS5pytijqRMSc/hHKVkQugO8YXoP+Gmaid3RG7qPe6BHfC5U unPyzX3hs9lWdHCSo2q7abUdYkVeCNsQArZq3eBdfpEo+J1/gOdjOnPAZLXYzU9tbEOby0H+MQPL 187987x+EdUi33dr7WbdbZ5ddNxep9t0o7NesxGFURiG0S+nMrEESlVZTvS+AR3fMInX9lOamjaY mu/VW7C71fxnvUIOGuaNtqAkE8oa/nvMp2UbFHGuTe9f7zGiOrRFMyXKHn2bYwEr2DYd0ZT+Fzdt y82EZglB1/P8boOh1mHuXG56cKIC6K0kGU86spbDzqjRiXq+22g1Om6z1Yvcszpouen3umHXr/Xa frjWstSVM8huXyk/Pf7+9PT456g6NntpeciCR30gM+coKq5wcbMwWxGcP0FjIzNUwIlTb8kQ+hyi MewJdvgXAAD//wMAUEsDBBQABgAIAAAAIQARq6hKPAQAAHcQAAAhAAAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDEueG1szFjbjts2EH0v0H8g1GfFuksW1hskvvRls1nUmw/gSvRaCHUpSbt2 igL5rfZz8iWdIUXLu3WQbeAWfvFS1HB0OGeGPLNXr3c1J1smZNU2E8d/5TmENUVbVs3jxPlwv3Az h0hFm5LytmETZ8+k8/r6xx+uulzy8obu240i4KOROZ04a6W6fDSSxZrVVL5qO9bAu1UraqrgUTyO SkF/A981HwWel4xqWjVOv168ZH27WlUFm7XFpmaNMk4E41QBfrmuOmm9dS/x1gkmwY1e/RSS2new W1UpzhyizcQWJnznGnZeLHlJGlrDxD1akCWvSqZfye5eMIZGzfZn0S27O6FX3G7vBKlK9NCvdEb9 i95MPzZgBoPRs+WP1hPNdytRX1/RHAJBdhMH+NrjLyyiOdspUpjJYpgt1u9P2Bbr+Qnrkf0AIDh8 FKjuzI7+uZ3AbscEwj/syphSWHrTFh8laVrYJ27fbK+43VpnuGd0362JiXqhhPbWm5r3OiR2idRh tVgPwUiyOPNMRAI/9KIgfhqXNE2DCA0wOn6Uep6xON61cd3lave2LfcY1Qf4q1mhOZdqqfac6WhD TGgOyOEHuOUUK4Y17oclVEytppxRqKieGXU95VXxkaiWsLJS5B2VigmidPZIdHkFIBQw37tkTXlH Bf3lmWcMHs3hyxAOixCGhp+vsxRalpabB/PN4BxEyc2DIQoyG9LOcvtywvww9ZOesTDLEjgTnjKW AF2aUs1YGgdobYJgCkFv3uSPjcdJxpAmvuU+JA6pqbjRlVM1JVS/HlL+CGxB5kEVg4PNLZx2muWS rYAEnJQtVPmi4lw/4BHHplyQLeVwUOzwZAAGq0aZmTT2DlD1eYjGmr0jP8Cl9Q/DHh/6gWEwQI3i FCNDLg8vguzxhgPesR/pMrs8vAiyxxsNeA9peHmAEWUPOD4CnAWZLovLA4woe8DJADgIMqjci0xh RNkDTo8Ap1F4oTWHKHvA2QAY0V5o0SHKHvD4CHASp/rsv7wcRpT6qLb3PaI/w3UP9+X/deNH9saf UcXIHacFW7e8BM0RnuPmLxWInE8gsSlfwb2kb39zMaNy1dHDwVIHEvWJFlCDZjl5Rw+qagX6GsXy 7/E8WcRRnLnTcTp1ozfz2M3m/sKdzcL5PB1747dT7w+n140lbFVVNTNX8bdFmQGFssv3RkEMzYTv DTIMMCDtXxFipKyEshr7eyRZbAlatC1KwWOKonNQtAItozn6dUMFfMHS9A2VBiS8mKb/KjaJjY3u q8jtpn54FiEt7KERs13Ed/UZ0MCC65NB0vJYtxzny+VZOg3TxdhzwzhM3SgeL9w3QRa5kTfOZpnn jxNvdshliR1lA+gwB/9NKn/5/OdPXz7/ddY81iLb9LUwxO5Xt65cvKPd+60+26HdhxwDiQtTHTT4 qNHBdDBBH/YfBtd/AwAA//8DAFBLAwQUAAYACAAAACEAOu9hr5EHAAAwLwAAIQAAAHBwdC9zbGlk ZU1hc3RlcnMvc2xpZGVNYXN0ZXIyLnhtbOxaa27bRhD+X6B3INifhSKR4kMUIgd+KQ3gJEbsHGBF rizWK5JdrlQ7RYHcoTfoLdr+61Fyks7MLinKllwZlgHbEGBI5O7s7O5887Zev7maCmvOZZnm2cB2 XnVsi2dxnqTZxcD+fD5s9WyrVCxLmMgzPrCveWm/2fv+u9dFvxTJe1YqLi3gkZV9NrAnShX9druM J3zKyld5wTOYG+dyyhS8yot2ItmvwHsq2m6nE7SnLM1ss15usj4fj9OYH+XxbMozpZlILpiC85eT tCgrbsUm3ArJS2BDq5ePRDNyDjd27D24bHwmEvweXejPT3xspckVTHc6SMH6dGl+KKQ1Z2Jgjy4c u733uo1LgNg84eKyOJec41M2fyuLs+JU4kv8YX4qgSfuaGVsClsjA5owZPSaAZlmvLT8ouLE+ldj OcUTgawsOCFAeo2fsIj1+ZWyYj0YL0bjyccVtPHkeAV1u9oArlZvirfSN7p9Hbe6znmqBLdOBYv5 JBcJKA6JiG6ol4EUi5M8viytLIc7oyj0VUE4FWO8P25VTCx1XYCUFLI1dHoSTpbV9CXJtzp0LRXP D0EDSTRu6AXd3rJ8eq4bBTiPUnIcr9uBFzzLglEhS/WW51MLHwa25LEiRWDzk1Jp0oqE0NcHKfrq 6iBPrhGMEXwD5mB+sH6Syy+2Jd5l5cCOHM+DvRW90EltSzZnRkszShzmoHKwgmUx8BnYsZJ0lgxM b3+m8nFqTqS3xM1Fqc7UteCkFgAe64NY4QMOJBhaP89an8/A+qfqUHAG3sGokNo7FGl8aanc4kmq LOMECAbwFcASpaRIVsSSZ8kpk+zTDc5GRCSbSiaAnFak9erUrdUJdbmpTS4C9FBtQgHZxrQfolQO aA8qGIm3srolrfJ814+C7tPXKlSLeykSWJwl5qSRdP0HKhZKj/SqXFIsUDJSW/1RbUke4x66fMbj PEsswedcbMCedOwe7M8nqdycOynDPbgP85lUk40P72lt3BiOYTpeyR3CyFZN2qtM+oip5QBBAnmo SScKvNgX8LBMjI1pE4wUJjCY3DNeBF0f/m6Ytut0u3XA6Aa+4/pP37KX4gWZahUVKELMhYOmzMQF eH9h41jCx+jHUZwOujccK3ORJsNUCHrB3G+RBqkrnR2pNFM6MQr9RSitcyYKFg0+YNt6J5oAX4IH 0c8mbOFeZPljkVDW9FvPOfYigKZ1PHT2W54X+a39juu2Isc5Pvb3o6OD8PB3CKqUNCSgaSqd8mF6 MZP840yH7k2Cn9Npuz4knk5n4S7gDHie7VqFX1nFMM8xy26GOrLkh9rFGJIEQvKXGZOwg7ENHZEw hdrUNrqO61XJ1Grj6EX+izaOKt96euaxXZ0MKp08A5Pn1ofZdHRDM8nrPVQzobQE1quUkxT/Xo47 8P3u3cr50j23LgWenmrWnnu/EwVu2HFbXnRAH50WZMqdltsLItcPDtzoKKg9d4mal4F2oMfdxGF/ +/rXD9++/r0Fb03ViS7e4bFqCcRCvmeFBQU/BEkFxTvEvIGdXMLT6MLFMaiA1RU8JZfwxOIYWg5A YR6qEZjXIzVNtxqBkkdPedUIZEx6xK9GIFrokaAaAVudiDS7hMQHv2xrnIuf9ED1hBkKNXJO2HU+ U+8SqFxvjFBsdR0v9HrdIIA7yT72KOS7xBTvYKvV6mVauEdNa0qztbRww5rW5HxraeHuNa2Jg2tp QSo1rfFMa2lBXjVtcEsyy3cLG7Th/9BCB63mS12GJYkv840atNHdfEMo92u+DmWj6xmHS8BVXZWG KAzw6op6AiUqARX09IqWZnIwkwxivLPAo5yz0RmkgtSvwPMo3Ybg7CQ7kKB5sC325jLzCiQT6C1A A/B0lsXQ9DCtsyI+wBYZtn/i09gkinQlSARhzMyOZh+gCUl5asObQasE+F5yiQ3MTXNSYIKsm5kr HZTSwzF0qAb2j9OfW0IhCJDZsRsTnOmJuLwxEZc4sS5/XZYq9Aah23BLxFMmTwZ213MjvFiagbsD UbWqgSodf2z5gyh1/+IGBsMcUnnMorWY9mXKhG0VqYonQzZNBTTMumCj8YTJksPBTaE0mh3CCA0P 7G9f/9Tya+Coo/Rj4JitwzFrrcExa92JI5mDi7WRxioErKAgXGDl9nyoc8Alm9LpeWP1xy2s3N5j 2dwWsUKAjOvqLrCqmrkNsCDPwOu8DLBuG5b7aA5yi2AhQgYsrwGW6aK+VLBWWBY63UeJZlsECxEy YPkLsNyOH5Kq1SHLfUGW9e8/t73gc8AKATJYBQ2sfMcjp/cisVqVXmA68+QNCxEyYIUNsKLQoYC7 A+uuPvNGOf0WvSAiZMDqLcDSaTqo2g6spwQWImTAihpg9XoBNQd3YD0lsBAhKKKX6uOin6sJl3W1 DJXjqYbU1JDNXy3UJbghqboXulx7lFy/UclqZ/0sK9nqZzHbr4Wem3xWV49Vp2snnzUFWzfEX748 RjH93BRodZHk9Nwe5XI7DVpTmVDNuNMgCFlrqoHQ063SnQatycAho6M+xE5Aa7LewA93Tpqa+HWm 2UwuIfFc/CMM/+lb/dJ97z8AAAD//wMAUEsDBBQABgAIAAAAIQD9eIypvgAAADcBAAAtAAAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDE3LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5S PYhI015E8OBF9AOWZNsG2yRko+jfm2MFwePsMG926vY1jeJJiV3wGtayAkHeBOt8r+F2Pa52IDij tzgGTxrexNA2y0V9oRFzCfHgIotC8axhyDnulWIz0IQsQyRfnC6kCXORqVcRzR17Upuq2qo0Z0Dz xRQnqyGd7BrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS42srwPqqnV19zmAwAA //8DAFBLAwQUAAYACAAAACEAMR7thWcDAAA/CwAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQxMC54bWy0Vs1y2jAQvnem76Bxz45t/vEAmQBxL03CFNK7YsuxJrLlSoJCO53Ja7WPkyfp SrZIk5IZSOjFGHn30+63u580OF3nDK2IkJQXQyc48R1EipgntLgdOteLyO05SCpcJJjxggydDZHO 6ej9u0EZSpZ8whu+VAgwChnioZMpVYaeJ+OM5Fie8JIU8C3lIscK/opbLxH4G2DnzGv4fsfLMS2c 2l/s48/TlMZkyuNlTgpVgQjCsIL4ZUZLadHKfdBKQSTAGO+nIalNCdkCMWqxdpCxEytYCZwRpB7P WYIKnMPCgipGEBCEvoAxjTFDC7JWxkyWC0GIdihWH0U5L2fCeF+uZgLRRKPVKI5Xf6jNzN8CzODF e+Z+a5FwuE5FPhrgEFhB66EDxdvoJzjhEIJAcbUYP67G2dUO2zg732Ht2Q0ggu2mUPeyyujfdBo2 nYqUYJtVZYrB9ROP7yQqOOSp06/Siy9XFkznrOHLDFUlUJrf2q76aPiw9hI4NWSp9ZgnG534Dfya RRwyqeZqw4ghBMLGIYDDA+hnWHc4KdzrOXR4riaMYJiAmjw1mjAa3yHFEUmoQhdYKiKQCQbmASAH wI6C4tSQpEhmWODPz5B1fjiEnSFoGyG8VhS+TGTTEvmkp9CM4ZhknCUQSuMY5GqqHMQFhSGout2B voSmsZU5hHEtI4BCsA5aR7eLfygXYiu2JfqN9dBNbsohn9Sj4twQDw+7pUnqgBaYk5jDXDOyImwP eFORA+AXGRX7ozcrRvfmK+JLobK9g28dCk/TneigO0edhJadhClW5MkAGEJAiq12vEpdEgXD/x2O CsxS2/pGAozIaCl6k9qkcExonf/RGPeD7jjquJ3AP3db42jq9hvdwG13ovZZpzdpnkfjn04teQmk qmhO9Fmzj1hVEqjlKPC9RhsOxcB/7FeIQcO8UBaUUKHs8fAaqWrbAkWca4n8W6NMU721RKkSVY2+ LrGAHWyZXiNRL4jS/+KmY7mZM5oQdLnMb54x1D6GisNFDKB3kmQ06ci9PO1Omt2o77vNdrPrttr9 yD1r9Fpuy+/3pj0/6Hf86baXpc68gOgObeWH+18fHu5/H7WPzclbXcngVV/izK2LiQtcXq2MtMK1 FXpsYpZKuKjqAxxMH000hr34jv4AAAD//wMAUEsDBBQABgAIAAAAIQBWFQz/MQQAAFEQAAAiAAAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEyLnhtbMxY227jNhB9L7D/QGifvZZo3RF7kYvd l2wS1NkPYCTaFpa6lKJdu0WB/a32c/ZLOkOKlpO6qLEwFn5xKGo4OjNnhjOTq4/bUpANl21RV2PH ++A6hFdZnRfVcux8fp4NYoe0ilU5E3XFx86Ot87Hybufrpq0Ffk929VrRUBH1aZs7KyUatLhsM1W vGTth7rhFbxb1LJkCh7lcphL9hvoLsWQum44LFlROd15ecr5erEoMn5XZ+uSV8ookVwwBfjbVdG0 VltzirZG8hbU6NOvIaldA9aqQgnuEC0mN7DhOROwPJuLnFSshI1nlCBzUeRcv2qbZ8k5ClWbn2Uz b56kPvGweZKkyFFDd9IZdi86Mf1YgRgshm+OL60mlm4XspxcsRQcQbZjB/ja4S8cYinfKpKZzazf zVaPR2Sz1fSI9NB+ABDsPwpUN8aif5tDrTnGEd7eKiPK4Oh9nX1pSVWDnWi+MS972FhlaDOqb1bE eD1TUmvrRM177RJ7pNVutVj3zgjjIHaNR6g3cn0avPZLFEXURwH0judHrmskDq02qptUbW/qfIde fYG/mhWWilbN1U5w7W3wCUsBOfwAt4JhxvBq8HkOGVOqW8EZZFTHjJrciiL7QlRNeF4o8om1ikui dPS0qPIKQChgvlPJq/yJSfbLG83oPJbCl8EdFiEsDT//zdLIsjRfv5hv0nMQ1a5fDFEQ2RB2ltvT CfNGkRd2jI3iOIQ74TVjIdClKdWMRQFFaeMEkwjaeBM/1h9HGUOaxEZ4EDikZPJeZ05R5ZD9esnE EtiCyIMsBgXrB7jtNMs5XwAJuNnWkOWzQgj9gFccvxWSbJiAi2KLNwMwWFTK7ESBu4eq70MU1uwd 6AEurX5YdvhQDyxpD9UPIvQMuTy8CLLDO+rxJp6v0+zy8CLIDq/f492H4eUBRpQd4OAAcExjnRaX BxhRdoDDHjClMWTuRYYwouwARweAI390oTmHKDvAcQ8Y0V5o0iHKDnByADgMIn33X14MI0p9Vdt6 j+jPUO6hXv6oiu/bin/HFCdPgmV8VYsceo7ROSp/rqDJ+R1abCYWUJd09TeFGTtX7T1czLUjsT/R DVTfsxyt0X1XtYD+GpvlP2Jv6iejIBxMZ971wPeTYHDtUjpIPG86Da6Tu5vo9k+n6xtzMFUVJZ8V y7Xkj2vlIG+nNGeeO6QBDBOe27dhgAGPn7cRCywts7rGBvCQGP8cxCygg9HM/LpmEr5gyfmf3gxc fzI55/VIaD2iZyjysC5f3vhFN/EwdNmJ4btmChhWQfVR1+hWWI8X54vbazcJaeTSgZ/c6B93EFPq DqAMJjQIb2hyF+7jtsXpsQJ0p4brt69/vf/29e8zxKpun83ECkuca/VQKuQn1jxu9K0NgzzEETSv sNXA6I7dN4j2IqjD/itg8g8AAAD//wMAUEsDBBQABgAIAAAAIQDrDJeVXAMAABkLAAAiAAAAcHB0 L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDIxLnhtbKxW23LaMBB970z/QeM+O74ECPYAGa59yYUp pO+KLWNPZMuVBIV2OpPfaj8nX9KVbJGSkhlIeDFG3j3aPbt7pM7lOqdoRbjIWNG1vDPXQqSIWJwV i651N5/YbQsJiYsYU1aQrrUhwrrsffzQKUNB4yu8YUuJAKMQIe5aqZRl6DgiSkmOxRkrSQHfEsZz LOEvXzgxx98BO6eO77otJ8dZYdX+/BB/liRZREYsWuakkBUIJxRLiF+kWSkMWnkIWsmJABjtvRuS 3JSQLRAj52sLaTu+ghXP6kHq0YzGqMA5LMwzSQkCgtBXMM4iTNGcrKU2E+WcE6IcitVnXs7KKdfe N6spR1ms0GoUy6k/1Gb6bwFm8OK8cF8YJByuE573OjgEVtC6a0HxNuoJTjiEIFBULUbPq1F6u8c2 Ssd7rB2zAUSw3RTqXlYZ/Z+Ob9KpSPG2WVWmGFyvWPQgUMEgT5V+lV50szJgKmcFX6aoKoFU/NZ2 1UfNh7EXwKkmS64HLN6oxO/hVy/ikAo5kxtKNCEQNg4BHB5AP8Wqw0lh382gw3M5pATDBNTkyd6Q ZtEDkgyROJPoGgtJONLBwDwAZAfYkVCcGpIU8RRz/OUFssoPh7AzBG0ihNeKwteJPDdE7vQUmlIc kZTRGELxT0GuospCjGcwBFW3W9CX0DSmMscwrmQEUAhWQavo9vEP5UJ0RbdEv7Meqsl1OcROPSrO NfHwMFvqpI5ogRmJGMw1JStCD4DXFTkCfp5m/HD084rRg/masCWX6cHBN46Fz5K96KA7J52EhpmE EZZkZwA0ISDFRjvepC6xhOH/AUcFpolpfS0BWmSUFL1LbRI4JpTO/2x740Zw3mzZ44nXtxuNoGn3 Xd+3A88bj5v9YDS4GP6yasmLIVWZ5WSSLZac3C7VYXKYaHmu4zfhUPTc536FGJT7acvSNGWZMKaE 8V9l0q303sIkkleV+bbEHHYwxXmLML0iRadlpGUYmdEsJuhmmd+/4KV5CsWGSxdA76VG68+J+7bv Bi3/wvXtRjDQD9du+75r++1W4DdbAz8YtbZ9K1TmBUR3aLs+Pf7+9PT45wS9qs/U6rIFr+p6pu9T lF/j8nalRRMupNBHQ71UwhVUHc1g+myiMMyVtvcXAAD//wMAUEsDBBQABgAIAAAAIQDKztNxpQQA AH0RAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDIwLnhtbKxY25LaRhB9T1X+YUp5 xmiE7rXg2mXZvKx3qYA/YJAGpLJukQYMTqXKv5V8jr8k3SMNoDUbs7JeQIieM9Pdp0+3dPN+nyZk x8sqzrOxRt/pGuFZkIdxthlrH5cPA1cjlWBZyJI842PtwCvt/eTXX24Kv0rCR3bIt4IARlb5bKxF QhT+cFgFEU9Z9S4veAb/rfMyZQJ+lpthWLLPgJ0mQ0PX7WHK4kxr1pfXrM/X6zjg93mwTXkmapCS J0zA+asoLiqFVlyDVpS8Ahi5un0kcSjA2yIOlnuNSLNyBzeoNgHPg0USkoylcGMeB2JbcvI5FhGZ sgLPIW2qYllyjtbZ7veyWBTzUi592s1LEocI1UBow+aPxkz+zMAMLoYvlm8UEvP36zKd3DAfIkL2 Yw0Sd8BPWMR8vhckqG8Gp7tB9HzBNohmF6yHagM4wXFTyHlRe/S9O4ZyZxmLhBN69Ko2ZbD0MQ8+ VSTLwU90v3YveNopMPQZ4YuI1OEXCNXY1X/KeCj7SsZUHfQYCep4huECb8Fz0wWW6S+iYpmubcJN grGxbNsZuXIThQSb1NCFL/Z3eXjAkK7gGzLHsiDKgakrXMH8pBILcUggz3C9SyiciLBkA6WUAAuY H/L1H3Cr+jLWgO+w5Up5frSHJLdxIMTMh0DAByxNGFYizwYfF1CJqZgmnAF845KYTJM4+ERETngY C/KBVYKXRAYO6hZOhuhC7iEheRbOWcnwUOfImAvmw87gu/JZhgHz8XrSRyrpqgzmCQt4lCchHMLA EEGxqAR3ogBUoAblAlxWhOlGBJsajmPVSVPV0eKBSSmS5VoivJr9lJWPshrjLARpwUtM5Wr7BPop V51xYgSkaHZs2IO2cGkgkWoo03LQilyDZ5w8aEAavNEJz6OmJP9VeGhZcwPwEKTBM094dORQLLHr DohFcARElAbQOgN0oXq7ASJKA2ifAEEN4ICdTogoDaBzBuiYMnMdXEaUBtA9ASLa9UlpxRBRGkDv DNC2nI5JQZTLmtSvdphKO5ZYj+fCMUKG/KxwoF6DYILwRixZNxoiJUn2EOkjNteFdFcpvmoBF5uJ NYJWUfeKU4ttiYirQ2upN1FI/9NMpBpc6iBv0hDaqlHsQA0dOmoIbWkSgjR4HTWEtujag4Z4PUtI C68HBWnh9SAgLbwe9KOF14N8tPBeVw8gEoEmchxdJK26TzgoGnLAqVoTTpcpxlJKdM8EbymR2YcS heI7HaJ1E0T9uShEUv/UHKZmz5ZcyB9yUlzDswg+T/zl0pnpjSx7MHugtwPT9KzBrW4YA4/S2cy6 9e7vnOnfWjNah+CqiFP+EG/g8eV5KzSs8mvSQfWhYcGDF9VPgYcz4PJ+G4St0vKQ5zjUnrcIOcn9 bItYi7LOzJ9bVsIOatD8waT5luT0GxFHRWSRxCEnT9t09SIudh+EhQd7gL4Ymh800LeE5sjbW92z DUc3BqZ3Jz/0gWsY+gCmNs+w7DvDu7ePvK3Q8wxOdy1dv33957dvX//tgauyk9cP9XCJ7wDklJKU H1jxvJNyBi89gEdTeauA1xwQDzQ9mSCGem0y+Q8AAP//AwBQSwMEFAAGAAgAAAAhAAEYFJzoBAAA DhIAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTkueG1szFjdcqM2FL7vTN9BQ6+9 RhiwYeLsJE7Sm2ySqb0PIIMc6IqfCtlrt9OZfa32cfZJeo5ANvZ61zjJRW8IkT99nN/vCC7erzNB VlxWaZGPLfrOtgjPoyJO8+ex9XF21xtZpFIsj5kocj62Nryy3l/+/NNFGVYivmebYqkIcORVyMZW olQZ9vtVlPCMVe+Kkufw26KQGVPwr3zux5J9Bu5M9B3b9vsZS3Or2S+77C8WizTiN0W0zHiuahLJ BVNgf5WkZWXYyi5speQV0Ojd+yapTQneFvPfZ2uLaJhcwQK1LsHzaCpikrMMFiZFroCBfE5VQias RDs0pipnknNE56tfZTktn6Te+rB6kiSNkaqhsPrNDw1M/5sDDG76B9ufDRML1wuZXV6wECJC1mML ErfBK2xiIV8rEtWL0W41Sh6PYKPk9gi6bx4AFmwfCjkva4++dccx7sxSJTihW69qKIOt90X0qSJ5 AX6i+7V70cPKkKHPSF8mpA6/QqoGV/+o42HwlY6pMXQbCdcbQm3pcDjDge0dxGRg26MBHVgEI0Op 7zSItsc1cxmq9XURbzCic/gLiWN5lBRQqPM6zqJSU7URkGYWipWgYBBh4hk6SUARsDDmi99gqfpz bIFJYNPcOL7FQ47hvsUDEWYhxAEusFUwbESe9z5OoREzNRGcAX3jk7qciDT6RFRBeJwq8oFVikui 4wZtC5Yhu9LP0JQ8j5+YZGhUmxlTwUJ4MsTX+Ay3dba/n3MI4n4XPAkW8aQQMRjhvK4C0hjq1xRJ 9+QPvKGHCcVmOJZ9j1IKiDr73sgbUCiF2v26obTbdR2aSJjs69Zqp6pJ+UGmB1h9NWULALdOU6/t qhi1sQYA2MERrNvGGgBg3SNYrLatDQYAWO8U1gAA65/CGgBgh6ewBgDY0SmsAQA2OIWtAcd6CHYS YNg2yyt7CjVVt1S111N13+jmgYt5pC7cM9p4yqMij4ngKy460OveOoN+lqSyO7tuiDPY74qlhOnX 1XgXC/Mc+nRxlB3G3JuqmWvUbIapbkuZDgiMfTOqXjTMcIKAhMMoSJhYWHAGAIHTidRDDSVH30x1 xaP44tKPpht1Bx6t+3w38vfGm+sH1PZfLXAkY/JeHzHSPIbTDt6iafPlAxwKdTZbmkb3dApnImKh E1HeGiozozvx7enpgUY2fAF18amkE9+eNh7oaMNHB0PqdyUMfqC1hm/kjFDqOxm4x3egxw2f44zA vJfwHWi24Ru6emydb9+Brjd8SNY5IXv+Hmi/4fO94cvy8f+YD9DZ5jShDxh4zP3+ucozSnTDFN9T Iq2dr1WiWH2jQ7Q+LeDbxlEhgh7feXD0PKRVQJ9dF/ByhC84f43orRsMPL93e0eveq4beL0r23F6 AaW3t95VcHM9nPxtNWf9GFxVacbv0uel5I9LpRWmyxGY2n3HgzdBau8mJ9iAovO2A8I3abkrCjxm t0eEh0PttYlZKFln5o8lk/CEZkjQE8fgc5LzthEZmohMRRpz8rDM5gdx8d8iLvClAaiPhubEAD0n NNu6vbID3xnaTs8NrvXF7o0cx+6B5gaO5187wY2/rdsKPc/BOqy3LuX69cs/v3z98u8b1KpWkvor A9ziRwldgkJ+YOXjSk9d+AoDdTTRSyV8d4F4IHQHQQ7zHefyPwAAAP//AwBQSwMEFAAGAAgAAAAh AENwoVGjAgAAswYAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTgueG1srFXtbtow FP0/ae9geb/TfBQoiYAKCuxP16LRPsBt4pCojp3ZhkGnSX2t7XH6JLt2SLuxTqo0/iTOzb3H95xz 4wzOtxUnG6Z0KcWQhicBJUykMivFakhvb+ZenxJtQGTApWBDumOano/evxvUiebZJezk2hDEEDqB IS2MqRPf12nBKtAnsmYC3+VSVWDwUa38TMFXxK64HwVBz6+gFHRfr95SL/O8TNlUpuuKCdOAKMbB YP+6KGvdotVvQasV0wjjqv9syexqZHvHQdxT4tLUBgMhHSHzdMkzIqDCwMRl2KCubxRjdiU2H1W9 rBfK5V5tFoqUma3d11B//2Kf5h4FpuHCPyhftUiQbHNVjQaQoARkO6To1M5esQgStjUkbYLpSzQt rl/JTYvZK9l+uwF28LypZdUw+ptO1NKZgmFkwSFlheQZUyR8JthUAaJcyvReEyGRslWiYZpebVpc S9/uVBekkT4zOHgPaCLwnKJ+SC50ZJ1CNtkt2nqNcjsdzXYis53V5A7vLggJ12Zpdpw5rZARJDk6 aE351g9nnfi02/Nm83DsdTpx1xsHUeTFYTibdcfxdHJ28Z22TSFVU1ZsXq7Wil2vDY4DJAoNxjHA D4YJ73aJfVfmgjPAD2pvjxmFgR91cVzDYIBKG+ze9eC8E9kCFHw+QLESQYLNIs+WFC4bQ/5ty2lr y1xKg2b8bkx0DGNyoxpnvqxB4Q6tOa2pjZP/ZQ47qiKdVpElLzNGrtbV3YEup8fQBY9DhH5VGqe7 U+R4czsO4l50FkReJ564S+D1oyjwon4vjrq9SRRPe89zqy1zgd29dVyfHn98eHr8eYRZdSPbnIy4 tCenO/y4+gT19QY/Y0jwV4FzdOFCNf4c9ofDS4rFaH82o18AAAD//wMAUEsDBBQABgAIAAAAIQCe x2px0AIAAAUIAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDE3LnhtbKxVS27bMBDd F+gdCHat6BPbsQTbgb/dNLFRJwdgJMoSQpEqSbtWiwK5VnucnKRDSkrSNAUMVBuKImce570ZckaX x4KhA5UqF3yM/TMPI8pjkeR8N8a3NytniJHShCeECU7HuKIKX07evxuVkWLJJ1KJvUaAwVVExjjT uoxcV8UZLYg6EyXlsJcKWRANv3LnJpJ8BeyCuYHnDdyC5Bw3/vIUf5GmeUwXIt4XlOsaRFJGNMSv srxULVp5ClopqQIY6/1nSLoqga3ONaNrziqMrKk8wKKPJ8A+3rIEcVLAwo2xQtbM7KjyRlJqZvzw UZbbciOtw/VhI1GeGIDGEbvNRmNmfzmYwcR95b5rkUh0TGUxGZEItEDHMYaUVWYEJxLRo0ZxvRg/ r8bZ+g3bOFu+Ye22B0AET4caVjWjv+kELZ1aB/+JVW1KwPWTiO8V4gJ4Gvo1vfj60IIZzga+zNAL 4Ru7etPq0dor0NSKpY8zkVSG+B187SKJmNJbXTFqBYGwSQTgMID8jJi6pty53UJdF3rOKIG6b8TT kznL43ukBaJJrtEVUZpKZKsAbgFAjkAdDclpIClPNkSSz6+QDT8SwckQdBshTGsJ/y3keSvkgmiK NozENBMsgQiCLjRNNFD+BteCsBRDIUKV+Ja4ldYk4L80TuE+mOr+PvSXvfC8P3CWK3/q9Hph35l6 QeCEvr9c9qfhYnYx/4GbRCdAVecFXeW7vaTrvcanpsr33KAPD4DvPScFYjDu3aal16ZlJYQph5eJ Oe8iMamWdWa+7ImEE9rktBelgwvQrSL9VpEtyxOKrvfF3Stdel3oAg0GoN+Uxl6Ijut26oWD4MIL nF44s4PnDIPAc4LhIAz6g1kQLgZPdasMcw7RnVqujw8/Pzw+/OqgVu1LUrcYmJo+ZLsIk1ekXB/s UwfNF+pobpdKaLfNg/tsYjDa9j35DQAA//8DAFBLAwQUAAYACAAAACEAV2qam2cFAACDGwAAIgAA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxNi54bWzsWcty2kgU3U/V/INKsyZIQg9EGads bM/GsV0D+YBGaowmeo3UYJipqcpvTT4nX5J7b6tBvBIZs0jVsAEhTh/d59FV6+L9Iom1OS/KKEv7 uvnO0DWeBlkYpc99/ePortXVtVKwNGRxlvK+vuSl/v7y118u8l4Zh/dsmc2EBhxp2WN9fSpE3mu3 y2DKE1a+y3Kewn+TrEiYgJ/Fczss2AtwJ3HbMgy3nbAo1av1RZP12WQSBfwmC2YJT4UkKXjMBNhf TqO8VGx5E7a84CXQ0OpNk8QyB2/FSzZajF6yx/GfukbgYg6nTf0S/A+GcailLIETgyzJWRGVWUr/ lPmo4Bwx6fz3Ih/mTwUteJg/FVoUIkG1UG9Xf1Qw+pkCDA7aW8ufFRPrLSZFcnnBehANbdHXIWlL /IRFrMcXQgvkyWB9Npg+7sEG09s96La6AFiwuijkO5ce7bpjKXdGkYi5Zq68klAGS++z4FOppRn4 ie5L94KHuSJDn5E+n2pV6JGqwsk/KR4KX0JMKVhicZ2FS3R8DN90kvXiUgzFMoYUwPE8NikBrBfy yR8ytLXT4G0dDk6yHpgCH5CsmGEf8LT1cQh9kIhBzBn0SRVqcTmIo+CTJjKNh5HQPrBS8EITFIUS DbgAdgGprCh5Gj6xgoERG8wYDdaDK4OLyh84lAE/HPbOKuyY86eYBXyaxSFYYJ0iAxhPHcoVakkl 7EAiMFpbJWk7HjQ41aXpdBzT7KBJ6+q0DdswuyAuWKNux/dcshnCIInIfVkSKiIqwxpLg2kGajGW lPXsVcnWElbcU19EaQgNjod49fHsAVSMDJG1oJV/93XLRkvHys1abdChBdVTESqvGrEau6xIhXaA mZ01q2/aZEETVrO7y4pUFau9ZjU7nukiuBEtITdDgFwVrVOj7VpdsuFYWuSqaN01rWV1wYQ3WItc Fa1Xo/XsDtXhsdYiV0XbXdMiZ/OU7YktclW0fo3Wdbw3pQy5SEvqPUGKhheBqltJF139eIVDwSGB KzcU7hgVs5WKDbJUQK9uCBmpBtxq1Y3ilbcS7O4piyeVjEmJwdsqhQkP6vcTTMhhGbNMz+56zndk rOM7JjQHIproGMlQPVE7d6q1OknKGgAOlZjUlQxbaIVVAMAqiahhSUlWWAUArOr7OharcoVVAMCq Zj6IVQDAqg49iFUAwKq2O4hVAMCqXjqIVQDAygZRkwDFl0Ry5dvP0UE0DMCHalq6/75iLBnyIEtD LeZzHu9p0G166otX0I+mUdGcvbrzN1acu2xWiGlj423Zkc3po8ledphNTjqdOUrXRtvTGVl8vKjJ +VhOZyhwf81YAWNnpXEUbRqVG2ucazuGBebCJHZoVjM9UL7zrNbXz7MazMvnWa2vd/6Ps5qrNG3f rEaj0fGytitlpJNHS9mheW0tZed5DWO+Of+c57UDezrffeLZHqjO8xpuocmnwe3Y/Kzzmqe07YYJ vvEQ6uKEebywyXktFLCBuPk4aspnqoPPo3TV7d0vOLnesKQf9Hw/gb1o3Fn+p2ve2n7HcVu3d+ZV y7Z9p3VlWFbLN83bW+fKv7n2Bv/q1SZrCK6KKOF30fOs4I8zoSN7k20B02hbDmy/m8b6+QJswOWn HaNhi1Dusd9lGW6u1rc5vVMkZiJgdN69+Zg/2PN8TXJOGxFfRWQYRyHXHmbJeCsutAXx1oKF1ztA vTc0P9hHeU1oVnV7Zfiu5RlWy/av6cNodS3LaMGs6VuOe235N+6qbkv0PAXrmpbr18///fb185cT 1CptTMvXO3CI74BIG+LiA8sf5/QUCq++oFIHdCqHl10QD4SuIcihXp5dfgMAAP//AwBQSwMEFAAG AAgAAAAhAJeESNdFAwAA4goAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTMueG1s rFbbctowEH3vTP9B4z47vgQI9gAZrn3JhSnkAxRbYDey5ErChXY6k99qPydf0pVsk4bSGSi8yLa8 e7R7dnWkzvU6o6ggQqacdS3vwrUQYRGPU7bsWg/zid22kFSYxZhyRrrWhkjruvf+XScPJY1v8Iav FAIMJkPctRKl8tBxZJSQDMsLnhMG/xZcZFjBp1g6scBfATujju+6LSfDKbMqf3GIP18s0oiMeLTK CFMliCAUK4hfJmkua7T8ELRcEAkwxvttSGqTQ7b88bOFjJEo4NOzepB3NKMxYjiDiXmqKEHADhpy pgDJGMh8LgjRpqz4KPJZPhXG766YCpTGGqfyt5zqR2VmPhmYwYuz476skXC4Xois18EhkIHWXQtq ttEjOOGQrBWKysnodTZK7vfYRsl4j7VTLwARbBeFcudlRn+n49fplHR426xKUwyuNzx6kohxyFOn X6YX3RU1mM5Zw+cJKplXmtnKrvxp+KjtJXBqyFLrAY83OvFHeJpJHFKpZmpDiSEEwsYhgMMA9FOs G5sw+2EGjZ2pISUYGr8iT/WGNI2ekOKIxKlCt1gqIpAJBrYBQHaAHQXFqSAJi6dY4E87yDo/HMLK EHQdIbyWFP6byMuayKqb0JTiiCScxhCEfxqtaQxNUTN/BkahAIgWdEvdiQzrtjUEyzcMlywaKmGo lzRpHFHUGYk47FFKCkIPgDdMHwE/T1JxOPqlruMR6BO+Eio5OPjGsfDpYi86KMlZe7tR9/YIK/Km sQ0hIKu1GvyXXsQKtvM30HxMFxaIrG52s6mNbGhxOUk/FiD5Wrm/t71xI7hstuzxxOvbjUbQtPuu 79uB543HzX4wGlwNf1iViMWQqkozMkmXK0HuV/p4gMrviMU+GfJcx2/C6ea5r/0KMWj385alWZdl wrmWuj8Vx7TSqYVZKFFW5ssKC1ihLs4Zpei8jLRqRmY0jQm6W2WPO7w0T1Pi8oCD2xNA76XG6M+Z +7bvBi3/yvXtRjAwg2u3fd+1/XYr8JutgR+MWtu+lTpzBtEd2q4vzz8/vDz/OkOvmlOyvD7Bq75q mRsSFbc4vy/MIQM3S+ijoZnK4S6pD1swfTXRGPXdtPcbAAD//wMAUEsDBBQABgAIAAAAIQDM5kY4 fQQAAKUQAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDE0LnhtbMxY227jNhB9L9B/ INRnryVZF0uIs8i1fcgmwTr7AYxEx8JSl1K0a7cosL/Vfs5+Sc9Qoi/ZFHWzQZAXWyaHwzNnzpAj H71flZIthWqLupo43jvXYaLK6ryoHibOp7vLwdhhreZVzmVdiYmzFq3z/vjHH46atJX5FV/XC83g o2pTPnHmWjfpcNhmc1Hy9l3diApzs1qVXOOnehjmiv8G36Uc+q4bDUteVE6/Xh2yvp7Nikyc19mi FJXunCghuQb+dl40rfXWHOKtUaKFG7N6H5JeN4i2FdkvgucOM4ZqiSHPOUbs2VTmrOIlBqYio80Z GQplZtvmTglBdtXyZ9VMm1tlFl0vbxUrcnLSL3aG/URvZn5WMMPD8NHyB+uJp6uZKo+PeAo22Gri IGlr+sQinoqVZlk3mG1Hs/nNE7bZ/OIJ66HdAAg2myLfTRfRt+H4Npy7QkvBvE1UnSnH0qs6+9yy qkacFH4XXna9tM4oZnLfzFlHvSZXvV03afiw9q3h1ALdMBH7/sgbGTqCwI0S9xEpcRz7AQYZUeON It+NQ7OJ9YRNOtdNqlendb4mSu/xjczxKpvXUKmmFTyVrZ7qtUSe8byUHhAxLh9QRhIq4GkuZh8x 1P4+cbAl9rw3ic84GOBS9tv2K5HufY8gm6egBB9wIjnVo6gGn6aox1KfScGxUR+dPj6TRfaZ6ZqJ vNDsA2+1UMxQiOoFRvKuzR7GpajyW644wdv1TFnhKXYGCzZ6Qwhl5t/TD767Urgj7d1Knol5LVEM zKcgUS02z89SArHvoGygaSucZwnCT9wohjhM8myV7AsidF1vHPeZ6YrsEEHcdz6fEkTJ1ZUp0KLK cdLQI+X0fnGN49Qg2ZEJjsRuuq1lkV8WUpKtOU3FmVRsySXUt6IjCOksKt2NxIBtlIDkbYxNKnf8 YK7byUxsVGek65N0O6RBGAMF6D4Arjd+RbiEkcIG8tEWbuKhzA+FG70iXMLYww22cL1R7BGKw+il yIwAXkENBLLHG+7gHftjSvLbw0sge7zRFq/vj0HvW8RLIHu88Q7eOBgdXm6vqQcC2eMdb/ES2MPr 7TXxEsgeb7KDNwrjt1lvBLI7iXe6CHPnE3occpvL3YT1/B6ALjrTArR7PcBz7vnA3vPnXIu9e95c qt97z+carQ2apTmXM3vfd9caNcKGLnqYGua6Ns10F7ZTsX2auVXtXWx+GF5n6Nip9/5j7F0EySiM BheX3skgCJJwcOL6/iDxvIuL8CQ5P43P/nT6NjRHqLooxWXxsFDiZqEdUtkh6fDcoR/iBcVzt8QD Ay1/2fYrtGm5rGtq+3YbsOAlGrCZVl1mfl1whR1scv6jG/s/yXlZRiLLyBRtlGDXi/L+ES+m6f9e weIFGK6fpMY0vmgdX1K3J24S+bHrD4Lk1Hy4g7HvuwPceYkfRqd+ch5tdNtS5BXQHSrXr1/++unr l79fQKumY+5egPFIb8rmHUCqD7y5WZrjDH8OQEdoaTHU4O8ASIVMtybkw/69cPwPAAAA//8DAFBL AwQUAAYACAAAACEAXqxWRgwEAAC0EQAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQx NS54bWzsWN1y2jgUvt+ZfQeN99r1D7bBnkAnIbA3bZIp9AEUWw7eypZXEgS6szN9rd3H6ZP0SLYI oc4CGy5zY4z86ZPOd3507Iv365KiFeGiYNXQ8t65FiJVyrKiehhan+dTe2AhIXGVYcoqMrQ2RFjv R7/+clEngmYf8IYtJQKOSiR4aC2krBPHEemClFi8YzWp4FnOeIkl/OUPTsbxI3CX1PFdN3JKXFRW O58fM5/leZGSa5YuS1LJhoQTiiXsXyyKWhi2+hi2mhMBNHr28y3JTQ3Wykd2e/+HhTSOr2DEs0Zg ejqjGapwCQPzR4bGrJJAox+Jes4JUaBq9TuvZ/Ud1zNuVnccFZliaGdaTvughem/FcDgxtmb/mCY cLLOeTm6wAkogdZDCxy2UVeYhBOylihtBtOn0XRx24FNF5MOtGMWgB1sFwVf141FP5vjG3PmhaQE eVurGiiGqR9Y+kWgioGdyvzGvPRmZciUzYq+XqBWdkXV4pqHWg+DF6CpFkuur1i2UYbfw68exAkV ciY3lGhBYNs4AXK4gPwUq6gmlf15BlFdyjElGKK+FU+OxrRIvyDJEMkKiT5iIQlHUtslFOUFqCPB OS0lqbI7zPGnPWZlH05gZdi02SHcNhK+LGTPCNlGE7qjOCULRjPYhP86WcVXyAZMcwsiEMLD+OAF bZVce1EWhH3IVx1qXuS66l7rawIucHsDGLeQCrsg9MM46mkHGiYtQONmo0mn19TadEU9nTY4yUiu 5FX79wfNoqDtDgBu/Q5ssIs1AMD2OrDuLtYAABv8jPWe7cEAABsewhoAYKNDWAMAbP8Q1gAAOziE NQDAxoewDUBp3aaTcozOJpiJgGGbNq/MLhVBOrnEs+xqMmh/SR24JyT0jKSsyhAlK0KPoNdZdgL9 fFHw49l1QpzAPmVLLhdHbz5oMvJod0yLvJMdTpGz1rXgv+qa1gTOU3MYnHhc7NU17T99VKhKo292 z4yuuhYFg7fCBifCW2FL3grbthF6K2xHNGyhKWzXWJJn3Zouxf+/qjVNcCahR93r27SDXi5wpzTF ObzBqNeRvwbeJIh7YWRPpt6lHQRxaF+6vm/HnjeZhJfx9VV//LfVduYZmCqLkkyLhyUnt0v1zgNH 2l4H3NVbe67jh/C+5rlPBzHsQU0/73kTGbdMGVP9+24bHb6ujW4ck0veeObPJeawgmmqD3TVpzjn vIr0jSIzWmQE3SzL+z1donPoAt8DgLpTmgMH8ynSbOP20o0jv+/6dhBf6YtrD3zftf1BFPthdOXH 19E2boWyvILdHRuu37/989v3b/+eIVZ1JWm+CcCt+nKgX/sp/4jr25Vu1+BbCcTRWA/V8HUE9FDQ J4jiMF9bRj8AAAD//wMAUEsDBBQABgAIAAAAIQAH5mbDsQMAAB8MAAAiAAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDExLnhtbLRW247TMBB9R+IfrPAccmmSptG2aGk3vMCyol3eTeJuIhw7 2G5pQUj8FnwOX8LYiffSLaJll5c0jWeOZ86ZGfvkxaahaE2ErDkbO8Fz30GEFbys2dXYuVzkbuog qTArMeWMjJ0tkc6LydMnJ20mafkab/lKIcBgMsNjp1KqzTxPFhVpsHzOW8JgbclFgxX8FVdeKfBn wG6oF/p+4jW4Zk7vLw7x58tlXZAZL1YNYaoDEYRiBfHLqm6lRWsPQWsFkQBjvO+GpLYtZAvEqEWt KDll5WLjIGMv1rASOBOgoJjTEjHcwIf3YFoXmCJjj4AxtCAbZcxkuxCEaAe2fiXaeXshjPf5+kKg utRoPYrj9Qu9mfnLwAxevB33K4uEs81SNJMTnAE7aDN2QMStfoITziAIVHQfi5uvRfV2j21Rne2x 9uwGEMH1pqB/22V0P53QprNDSnCdXueDAeM1Lz5KxDgkrHno8izO1xZVJ6/3aSvUaaK0Hg7iogbl Ool6r87U0GS9paHaxn9NUJKEo8jvaAqHUTJI73IV+vHQrGvG4jQO4jA2m1gk2KSDbjO1ecnLrWb6 A/yCoLpoxg7BOvkOlko1V1tKjB7AGs4gJXiAMcW60QhzL+fQaI2aUoKhEXvt1GRK6+IjUhyRslbo DZaKCGQogLYEyBMQR0Ft9JCElRdY4Hc7yJpVnMHOELeN16Sgmf2zjoP7OupquqC4IBWnJYQS6gyh Eaxg/ySpJm5HUWgLqFlbD4crG8VDGCym/vcJm/jBKNXr/0tYqDdE1/RawQcKrek2Oss7QndiGkXh Ybc0bB1RW3NScBhTlKwJPQDeSH0E/KKqxeHog65VDuYr5yuhqoODj46Fr5d70WGePmqLRbbFZliR O51lCHloZ5UKpsoXOAoxXTp9T5nZYqaknqzm5fa4NP1sh4QdamZy3R9jSzj+9Pn1dZqMorPcn7mD IHnpRqMwcNM8D9w4Tk9H+Vk+DMLZN6ef4CWkquqG6DP0kCkIBW72V5PA98IYDv3Av6lXiEHD/EEW VNZC2WPvX2ZgbAXKOdez9/bwM0X1UImWSnQafVphATtYmf4y+46R6X9xk1hu5rQuCTpfNR92GDKn 5kMZgosmQO8lycykR67l2XA6GOYj3x3Eg6EbxaPcPQ3TyI38UTpL4QBJ/JtaljpzBtEdW8q/vv94 9uv7z0etY3Okd1dNeNWXU3M2U/EGt2/XZrTCtRxqbGo+tXARhzLSpjcmGsNe7Ce/AQAA//8DAFBL AwQUAAYACAAAACEAk6p9mLsAAAAkAQAALAAAAHBwdC9ub3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNN YXN0ZXIxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SKohI015E6FXqB4RkmwbbJCRR7N8b6MWC4GVh Ztk3s1XznkbywhCNsxxKWgBBK50yVnO4d9fdCUhMwioxOoscZozQ1NtNdcNRpHwUB+MjyRQbOQwp +TNjUQ44iUidR5s3vQuTSFkGzbyQD6GR7YviyMI3A+oVk7SKQ2hVCaSbfU7+z3Z9byRenHxOaNOP CJZyL8xAETQmDpQuzjIPNHcFVlds9Vv9AQAA//8DAFBLAwQUAAYACAAAACEAvVo7jt0AAAB0AQAA FgAAAHBwdC9jb21tZW50QXV0aG9ycy54bWyMkM9KBDEMh++C71Bydzt6EBmmsyyIIHjUB4htZ6fQ piXp6vr2hlXBve0tf/h9JN+0PZZsPiJLquTgdjOAieRrSLR38Pb6dPMARjpSwFwpOviKAtv5+mpq oy+7Q18rv0g3SiEZ0cHaexutFb/GgrKpLZLulsoFu7a8t4HxU+kl27thuLcFE8Fvni/J12VJPj5W fyiR+g+EY8auH8iamvzR2iW0xlEUc0qfnTT/+9Ck4EDNEBZVIO/IqgMTmESpJ8yiQzAZpT+Ho1oE 4zOfygHsPNkzV/M3AAAA//8DAFBLAwQUAAYACAAAACEAmxtwqgoGAAByHQAAIQAAAHBwdC9ub3Rl c01hc3RlcnMvbm90ZXNNYXN0ZXIxLnhtbOxZ647aOBT+v9K+g5X9uaKQkEBAAxUwQ1tp2o7K9AFM YiDCcbKOoUyrlfpau4/TJ9lz7JgAM91Cd1rtblElxvHl2Ofzdy4+vXi6STlZM1kkmeg57pOGQ5iI sjgR857z9nZcCx1SKCpiyjPBes4dK5yn/Z9/usi7IlOseEkLxSQBKaLo0p6zUCrv1utFtGApLZ5k ORMwNstkShV8ynk9lvQdSE953Ws0WvWUJsIp18tj1mezWRKxyyxapUwoI0QyThVoUCySvLDS8mOk 5ZIVIEav3jtSHzSMJjzGv9O5+X3DZiSJN4BTo+E6/Qva1XqyEZdkTXnPmc5dp96/qOMSmFy2cHGR 30rGsCXWz2Q+yW8kfkSv1jcSZIJIhwiaAsIoQA+U0/SngGlG8N7yuZVEu5uZTPFEAA+BE8I93uEv LKJdtlEkMp1R1RstXj8wN1pcPTC7bjcA1babolZGo/vqeFad54zGQJAbTiO2yDi2NUZaRbMOYMyv s2hZEJGB0oiF0RXQsZIRANwrXxB1lwNMi1gCM9/3nN9WVAIFyyVmHpxSbJcWGmurwN8j5HXabtgA 8BAnP2gDRbXganUuC/WMZSnBRs+RLFKaCXR9XSg8Nu3aKfr6ze55V22GWXyHtzGFv3DpYHSwfpHJ 9w7hL0TRczqu78PWSn/ozR0id0emeyOKjzLgXHnHvFATdceBYrTL19wFpQnlczBqrs8Xs9kb6ELE 3EqrcqY+9q4EuFegjYhvqKS4jFP0B0zU3k4cEidSWRqhulpPqx9Ab1jxeW40LTcuqWJ7zPAQ7H/K jFg5pZWezIlmGPotF85n1ats5//IDPm1zJjxWDutD1f+oNEeh8Nawws6NT8Yt2uDcTusjVtB0Ble NcPLoPU7UFqbbAzXrZKUjZP5SrLXK2M48pBeRapGnFFgbkltoLJ2Y6rvNupeAC7fbaCdKU1bOMu3 JKtvyTrhSczIi5TO9znb/DJnwa+9ycDY0cdnowXYEhsUOXiO41xdweMX6bwktTYR7d/QIR7j6FzX bzbQpwGpW2GA7k3DaaOCcXOlz2v6XgcnG09mg4r1aEc5PQqZwTjhXG/CBXmHHqcNMvGaigxgxFH8 QLFV7IQIsSz33ZkF98yFVvQ7eFJCRQQeuedESgcU2Lt0q1qZb+oVA0u0V5hX7blF/8sUw/vacZwY /w4CJoad/YhpvKTm70mEKkmEfPKb8O+QUIEftrDTBFGgX0k5uMqvIhQc7jvcPRJSQJ46WKlslpSh 3MRqHLpPBIywED+3bgrMkXa/7M1Uf8STaElURlicKFJm0ArNscAIXlS+DS1cB1j7Y7fUGRLsduyW ExZlIiacrRk/Qrx2MieIv10k8njpmnEnSB9nK6kWRx9eW8sp4pPZg9I/mwAZ33hy2tOyBj7OwML3 U+LgMSx8Bk5rLyU2Bq7xOMnATawIwc49SIa067PB4j+ZBm3d+tQoY21Z2/W/O1duW9KY9OPVKp0e UKf1GNSBFANEP8QezcyT2LObRP+IHHqErLoTDq68wVWt7fmQVYfjy1rYHA5rTc8fhMP2aDgKr7ZZ dYF5qYDLOy4WVMn0p49//PLp459VOHiETFqHalPpgKatn0RcvqQ5geoIvEYVZMFqA614Ca3p3MM+ KBeoDbTiJbRoFEFJBmaUDdsD46ZnO6dpe+DJZoZ82wN5u+kJbA8kWKanZXvAIy94IpbwDMc/Dpll /LnpsC1jXLrUde95nVJ5jdF/+84m8Mi+pdMJvLH1Wx6GpNIJAmH0Wgwl7AQ6Y61KlJ8wBd8DUBC7 WQnzIMB7PHytkyWTWJ/DlzuO7yTI94pQAC6eGhKHvVl6V/0Sm0Eppuf8mooaV8YhMnowwKgZiIqD gagoZZsT6m22RQRdefAwLzLQlAWUMz4cQSmjTbPCx5LE1ml+XP4gKCU+foWP22y7LXxInAFCVEqA gh2AQi/U5cozQIhKCVCrAsjzQiDQmUHgohGVEqD2DkBtv4lB5WxiHFEpAQorgBAdXcw4mxiiUgLU 2QGoFbTPTlqnPoiKrsPt5ov4dqr+p7T/FwAAAP//AwBQSwMEFAAGAAgAAAAhAPnPCTmDBgAAXBsA ABQAAABwcHQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixm61NG8Ruhx5p iZZYU6JA0kl9G9rjgAHDumGXAbvtMGwr0AK7dJ8mW4etA/oV9khKshjLSNIG27DFh0Qif3z/3+Mj df3Go5ihQyIk5Unbq1+teYgkPg9oEra9e8P+lQ0PSYWTADOekLY3I9K7sfX+e9fxpopITBCsT+Qm bnuRUunmyor0YRjLqzwlCcyNuYixglcRrgQCHwHdmK2s1mrrKzGmiYcSHAPZu+Mx9QkaapLeVk68 x+A1UVIP+EwMNGnirDDYYFLXCDmTXSbQIWZtD/gE/GhIHikPMSwVTLS9mvl5K1vXV/BmtoipJWtL 6/rml63LFgSTVcNThKOCab3faF3bKegbAFOLuF6v1+3VC3oGgH0fNLWylGk2+hv1Tk6zBLKPi7S7 tWat4eJL9NcWZG51Op1mK5PFEjUg+9hYwG/U1hvbqw7egCy+uYBvdLa73XUHb0AWv76A719rrTdc vAFFjCaTBbR2aL+fUS8gY852K+EbAN+oZfA5CqKhiC7NYswTtSzWYvyQiz4ANJBhRROkZikZYx+i uIsZHQmqGeBNgkszdsiXC0OaF5K+oKlqex+mGDJiTu/Ny+/fvHyO3rx8dvz4xfHjn46fPDl+/KOl 5SzcxUlYXvj628/+/Ppj9Mfzb14//aIaL8v4X3/45JefP68GQgbNJXr15bPfXjx79dWnv3/3tAK+ LfCoDB/SmEh0hxyhAx6DbsYwruRkJM63YhhhWl6xnYQSJ1hzqaDfU5GDvjPDDFfgOsS14H0BFaQK eHP60BF4EImpylzuaHYrih3gHuesw0WlFW5pXiUzD6dJWM1cTMu4A4wPq3h3ceL4tzdNoXTSKpLd iDhi7jOcKByShCik5/iEkAp7PaDUsese9QWXfKzQA4o6mFaaZEhHTjTNF+3SGPwyqxIQ/O3YZu8+ 6nBWpfUOOXSRkBWYVQg/JMwx4008VTiuIjnEMSsb/DZWUZWQg5nwy7ieVODpkDCOegGRsmrNXQH6 lpx+C6pHtdv32Cx2kULRSRXN25jzMnKHT7oRjtMq7IAmURn7gZxAiGK0z1UVfI+7GaLfwQ84Weru +5Q47j69GtyjoSPSPED0zFRoX0K1dopwTJPLinzmirwtaGVK7J6ow8twJ6tvl4uA/vuL7w6eJvsE 4n1xB7qsvZe11/vP195l+XzWijsvslB/dZ9jG2TTLsdLu+UxZWygZozclqZhlrBhBH0Y1OvMSZEU p6c0gseswDu4UGCzBgmuPqIqGkQ4hWa77mkiocxIhxKlXMIhzwxX0tZ4aNiVPSI29eHB1gOJ1R4P 7PCaHs7PCAUZs+2E5iCaM1rTBM7KbO1aRhTUfhtmdS3UmbnVjWim1DncCpXBh4uqwWBhTehEEPQv YOV1OKtr1nBIwYwE2u52E87dYrxwkS6SEQ5I5iOt96KP6sZJeayYWwGInQof6QPfKVYrcWtpsu/A 7SxOKrNrLGGXe+9dvJRH8NxLOm9PpCNLysnJEnTU9lrN1aaHfJy2vTGcb+ExTsHrUjd/mIVwSeQr YcP+1GQ2WT73ZitXzE2COlxZWLsvKOzUgVRItYNlZEPDTGUhwBLNycq/2gSzXpQCNtLfQoq1DQiG f0wKsKPrWjIeE1+VnV0a0bazr1kp5VNFxCAKjtCITcUBBvfrUAV9AirhmsJUBP0Cd2ra2mbKLc5Z 0pVvsgzOjmOWRjgrtzpF80y2cJPHhQzmrSQe6FYpu1Hu/KqYlL8gVcph/D9TRe8ncGWwFmgP+HCl KzDS+dr2uFARhyqURtTvC2gcTO2AaIF7WZiGoIKLZfNfkEP93+acpWHSGk5+6oCGSFDYj1QkCNmH smSi7xRi9WzvsiRZRshEVElcmVqxR+SQsKGuget6b/dQBKFuqklWBgzuZPy571kGjULd5JTzzakh xd5rc+Dv7nxsMoNSbh02DU1u/0LEil3VrjfL8723rIiemLdZjTwrgFlpK2hlaf+WIpxzq7UVa0Hj 1WYuHHhxUWMYLBqiFC5+kP4D+x8VPrNfKfSGOuQHUFsRfHTQxCBsIKqv2MYD6QJpB0fQONlBG0ya lDVt1jppq+Wb9QV3ugXfE8bWkp3F3+c0dtGcueycXLxIY2cWdmxtx5aaGjx7MkVhaJwfZIxjzOet 8hcoPnoIjt6Bu/4pU9IEE3xfEhhaz4HJA0h+y9Es3foLAAD//wMAUEsDBBQABgAIAAAAIQDcsXCC iAYAAF0bAAAUAAAAcHB0L3RoZW1lL3RoZW1lMi54bWzsWU9vHDUUvyPxHay5t9lNdtNs1E2V/ddA mzbKbot69M54Z9x4xiPbm3RvqD0iISEK4oLEjQMCKrUSl/JpAkVQpH4Fnu2Z2XF2VknaCBBkD8mM /fP7/56fPddvPIoZOiRCUp60vfrVmodI4vOAJmHbuzcaXNnwkFQ4CTDjCWl7MyK9G1vvv3cdb6qI xATB+kRu4rYXKZVurqxIH4axvMpTksDchIsYK3gV4Uog8BHQjdnKaq22vhJjmngowTGQ7U6l4jHq EUnDxNvKqfcZsEiU1AM+E0NNm2RL7k4m1CcGGxzUNULOZJcJdIhZ2wNGAT8akUfKQwxLBRNtr2Z+ 3srW9RW8mS1iasna0rqB+WXrsgXBwarhKcJxwbQ+aLSu9Qr6BsDUIq7f73f79YKeAWDfB02tLGWa jcFGvZPTLIHs4yLtbq1Za7j4Ev21BZlbnU6n2cpksUQNyD42FvAbtfXG9qqDNyCLby7gG53tbnfd wRuQxa8v4AfXWusNF29AEaPJwQJaO3QwyKgXkAlnO5XwDYBv1DL4HAXRUESXZjHhiVoWazF+yMUA ABrIsKIJUrOUTLCvwxgzOhZUM8CbBJdm7JAvF4Y0LyR9QVPV9j5MMaTEnN6bl9+/efkcvXn57Pjx i+PHPx0/eXL8+EdLy1m4g5OwvPD1t5/9+fXH6I/n37x++kU1Xpbxv/7wyS8/f14NhAyaS/Tqy2e/ vXj26qtPf//uaQV8W+BxGT6iMZHoDjlC+zwG3YxhXMnJWJxvxSjCtLxiOwklTrDmUkG/ryIHfWeG Ga7AdYhrwfsCKkgV8Ob0oSPwMBJTlbnc0exWFDvAXc5Zh4tKK9zSvEpmHk2TsJq5mJZx+xgfVvHu 4sTxb3+aQumkVSS7EXHE3GM4UTgkCVFIz/EDQirs9YBSx6671Bdc8olCDyjqYFppkhEdO9E0X7RD Y/DLrEpA8Ldjm937qMNZldY9cugiISswqxB+RJhjxpt4qnBcRXKEY1Y2+G2soiohhzPhl3F9qcDT IWEc9QMiZdWauwL0LTn9FlSParfvslnsIoWiB1U0b2POy8geP+hGOE6rsEOaRGXsB/IAQhSjPa6q 4LvczRD9Dn7AyVJ336fEcffp1eAeDR2R5gGiZ6ZC+xKqtVOEY5pcVuQzV+RtQStTYudEHV6GO1l9 u1wE9N9ffHt4muwRiPfFHeiy9l7WXu8/X3uX5fNZK+68yEL91X2ObZBNuxwv7ZYnlLGhmjFyW5qG WcKGEQxgUK8zR0VSnJ7SCB6zAu/gQoHNGiS4+oiqaBjhFJrtuqeJhDIjHUqUcgmHPDNcSVvjoWFX 9ojY1IcHWw8kVrs8sMNrejg/IxRkzLYTmoNozmhNEzgrs7VrGVFQ+22Y1bVQZ+ZWN6KZUudwK1QG Hy6qBoOFNaETQdC/gJXX4bCuWcMhBTMSaLvbTTh3i/HCRbpIRjggmY+03os+qhsn5bFibgUgdip8 pA98p1itxK2lyb4Dt7M4qcyusYRd7r138VIewXMv6bw9kY4sKScnS9BR22s1V5se8nHa9iZwvoXH OAWvS938YRbCLZGvhA37U5PZZPncm61cMTcJ6nBlYe2+oLBTB1IhVQ/LyIaGmcpCgCWak5V/tQlm vSgFbKS/hRRrGxAM/5gUYEfXtWQyIb4qO7s0om1nX7NSyqeKiGEUHKExm4p9DO7XoQr6BFTCNYWp CPoF7tS0tc2UW5yzpCvfZBmcHccsjXBWbnWK5pls4SaPCxnMW0k80K1SdqPc+VUxKX9BqpTD+H+m it5P4MpgLdAe8OFOV2Ck87XtcaEiDlUojag/ENA4mNoB0QL3sjANQQU3y+a/IIf6v805S8OkNZz8 1D4NkaCwH6lIELIHZclE3ynE6tneZUmyjJCJqJK4MrVij8khYSNdA9f13u6hCELdVJOsDBjcyfhz 37MMGoe6ySnnm1NDir3X5sDf3fnYZAal3DpsGprc/oWIFbuqXW+W53tvWRE9MW+zGnlWALPSVtDK 0v4tRTjnVmsr1oLGq81cOPDiosYwWDREKVz8IP0H9j8qfGa/POgNdcT3obYi+OigiUHYQFRfsY0H 0gXSDo6hcbKDNpg0KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s7Njaji01NXj2 ZIrC0CQ/yBjHmO9b5S9QfPwQHN2Du/4pU9IEE3xfEhhaz6HJA0h+y9Es3foLAAD//wMAUEsDBBQA BgAIAAAAIQD5zwk5gwYAAFwbAAAUAAAAcHB0L3RoZW1lL3RoZW1lMy54bWzsWU9v2zYUvw/YdyB0 b2MndhoHdYrYsZutTRvEboceaYmWWFOiQNJJfRva44ABw7phlwG77TBsK9ACu3SfJluHrQP6FfZI SrIYy0jSBtuwxYdEIn98/9/jI3X9xqOYoUMiJOVJ26tfrXmIJD4PaBK2vXvD/pUND0mFkwAznpC2 NyPSu7H1/nvX8aaKSEwQrE/kJm57kVLp5sqK9GEYy6s8JQnMjbmIsYJXEa4EAh8B3ZitrNZq6ysx pomHEhwD2bvjMfUJGmqS3lZOvMfgNVFSD/hMDDRp4qww2GBS1wg5k10m0CFmbQ/4BPxoSB4pDzEs FUy0vZr5eStb11fwZraIqSVrS+v65petyxYEk1XDU4Sjgmm932hd2ynoGwBTi7her9ft1Qt6BoB9 HzS1spRpNvob9U5OswSyj4u0u7VmreHiS/TXFmRudTqdZiuTxRI1IPvYWMBv1NYb26sO3oAsvrmA b3S2u911B29AFr++gO9fa603XLwBRYwmkwW0dmi/n1EvIGPOdivhGwDfqGXwOQqioYguzWLME7Us 1mL8kIs+ADSQYUUTpGYpGWMforiLGR0JqhngTYJLM3bIlwtDmheSvqCpansfphgyYk7vzcvv37x8 jt68fHb8+MXx45+Onzw5fvyjpeUs3MVJWF74+tvP/vz6Y/TH829eP/2iGi/L+F9/+OSXnz+vBkIG zSV69eWz3148e/XVp79/97QCvi3wqAwf0phIdIccoQMeg27GMK7kZCTOt2IYYVpesZ2EEidYc6mg 31ORg74zwwxX4DrEteB9ARWkCnhz+tAReBCJqcpc7mh2K4od4B7nrMNFpRVuaV4lMw+nSVjNXEzL uAOMD6t4d3Hi+Lc3TaF00iqS3Yg4Yu4znCgckoQopOf4hJAKez2g1LHrHvUFl3ys0AOKOphWmmRI R040zRft0hj8MqsSEPzt2GbvPupwVqX1Djl0kZAVmFUIPyTMMeNNPFU4riI5xDErG/w2VlGVkIOZ 8Mu4nlTg6ZAwjnoBkbJqzV0B+pacfguqR7Xb99gsdpFC0UkVzduY8zJyh0+6EY7TKuyAJlEZ+4Gc QIhitM9VFXyPuxmi38EPOFnq7vuUOO4+vRrco6Ej0jxA9MxUaF9CtXaKcEyTy4p85oq8LWhlSuye qMPLcCerb5eLgP77i+8Onib7BOJ9cQe6rL2Xtdf7z9feZfl81oo7L7JQf3WfYxtk0y7HS7vlMWVs oGaM3JamYZawYQR9GNTrzEmRFKenNILHrMA7uFBgswYJrj6iKhpEOIVmu+5pIqHMSIcSpVzCIc8M V9LWeGjYlT0iNvXhwdYDidUeD+zwmh7OzwgFGbPthOYgmjNa0wTOymztWkYU1H4bZnUt1Jm51Y1o ptQ53AqVwYeLqsFgYU3oRBD0L2DldTira9ZwSMGMBNrudhPO3WK8cJEukhEOSOYjrfeij+rGSXms mFsBiJ0KH+kD3ylWK3FrabLvwO0sTiqzayxhl3vvXbyUR/DcSzpvT6QjS8rJyRJ01PZazdWmh3yc tr0xnG/hMU7B61I3f5iFcEnkK2HD/tRkNlk+92YrV8xNgjpcWVi7Lyjs1IFUSLWDZWRDw0xlIcAS zcnKv9oEs16UAjbS30KKtQ0Ihn9MCrCj61oyHhNflZ1dGtG2s69ZKeVTRcQgCo7QiE3FAQb361AF fQIq4ZrCVAT9Andq2tpmyi3OWdKVb7IMzo5jlkY4K7c6RfNMtnCTx4UM5q0kHuhWKbtR7vyqmJS/ IFXKYfw/U0XvJ3BlsBZoD/hwpSsw0vna9rhQEYcqlEbU7wtoHEztgGiBe1mYhqCCi2XzX5BD/d/m nKVh0hpOfuqAhkhQ2I9UJAjZh7Jkou8UYvVs77IkWUbIRFRJXJlasUfkkLChroHrem/3UAShbqpJ VgYM7mT8ue9ZBo1C3eSU882pIcXea3Pg7+58bDKDUm4dNg1Nbv9CxIpd1a43y/O9t6yInpi3WY08 K4BZaStoZWn/liKcc6u1FWtB49VmLhx4cVFjGCwaohQufpD+A/sfFT6zXyn0hjrkB1BbEXx00MQg bCCqr9jGA+kCaQdH0DjZQRtMmpQ1bdY6aavlm/UFd7oF3xPG1pKdxd/nNHbRnLnsnFy8SGNnFnZs bceWmho8ezJFYWicH2SMY8znrfIXKD56CI7egbv+KVPSBBN8XxIYWs+ByQNIfsvRLN36CwAA//8D AFBLAwQKAAAAAAAAACEAFi9H4gCAAAAAgAAAFwAAAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVn/9j/ 4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCADAAQADASIAAhEB AxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9 AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6 Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEB AQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJB UQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RV VldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6 wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiv56vhP+1r+0P4u/bZsfh9on7S3x98V+IL z9u79o34VeJP2b/iN+zV8NfBX7KVr+yp8Jv+E9tdU174Q/tGXH7Ofwp8RfEX4wfD9LXwBqNz4a8F /tT/ABx8aQ3V9rL+MPhA3hTT/FOv+Bft/Qv2+/iJrPi7w74uk/Z00W2/ZB8aftJeIv2U/Cvxsg+N NzffGdPiZoPj/wAUfBq18V+Lv2dl+EVv4Z8O/B3xP8afB+peBfD3ifTP2hfE/wAQUste8FeKvEvw n8N6fqnie28Gc+GxNLFZflmYxVSnRzXCZfi8LTq0qkajhmmDyfGYKnzKMsPVrYh53hMFRhha+IVf MqOY5fh5VsTlmOp0HiuXCYjNaFarRX9j1Mwp42qq9L2cFleJzWhjpqEpxxEY4enk+Kx9aNWhSq0c srYDMK1OnhsfhKlX9NqK/Hrx5/wUb+J3ij9k34I/FD4M/CDw1pHxQ/ai/Yk+Ov7Tngyz8X/Fi4sN A+Fmr/DD4e+AvFy6Tea5b/BbxsfGE0EHj2e80+7uPAun6ff6l4atNL1PR4dO8QXV/onMaz+3p8ff g78I/gH8Tvjv4E0u48dTf8E8f2yP2u/F/wAPfhT8ZtB1/wCGfxGm/Z08Gfs/+KPDqeJPE3iz9k7w R460bxZ40s/iHdXUC+BU8I+DfhrqWpeItK1bQ/jbYjwtq3hvRVE8dnOXSjOGJyKNKWPjJc0U54fi fE1YUJU3P29TDUuEs1dWFNOVZuh9S+tr608L208txlbGZXgKNJVMXnGIzLC4OjGpST9vlbypVoVp TnGFKNWWcYWFGs5OgpxqRr1KDlhvrH7WUV+SE/8AwUf+M/hGL4h+H/i5+yf4R8CfFM+EP2YfGHwA 8F6T+01b+LvD/wARIv2tvjVqHwC+Gnhv4w+PJPgt4btfgn4q8KeP10Q/Fa38F6H+0D4e0rQdVurz 4Y+Jfi5qun2+h6r9Z/sc/H74vftBeEfihq3xm+EXw0+Dvin4bfG/4hfBhtD+Fnx0179oDw3rMnw5 u7TSdV8Qx+Mte+BnwGktRd6y99b2+iw+GtRudPt7RIdfu9I8TJrXhbQeiNKUpVYQcJ+wp4+pUlTq 0qlL/hKx+XZXmdOFaE5UquIy7MM1y/B47DUpzxGEr4lQr0qfs6rp+aqkHQoYi7VLE1sJh6LlGcJy qY/LKuc4Fyoziq1OljMsoVsZha9SnChiKVOXsqk5rlPryivxe/ZN+NnxS+L37T/x9svEH7Tf7aGu a58Nf2hf2oPB3hf9ny7/AGTvCvhP9hy+8GfDzxFr3hXwHoF9+13ZfsDXV5PrVhbyaTqt3baV+15q vjRvE1hJaaj4f1a2tNY8IXPnHxY/4Ke/tHfFD9lz9oDx7+yz8ALP4ffEH9nnWfhh8NPjFrnxo+I0 /hLS/AH7RVx8XYfBnxm+Bngu3k+AXxRPxOb4d6XHoN3dfEe98J+F/B/ibwp8VPCviPwXcXeq2mpa bpfDDF0qmX4DMYKo6eY5Jl/EFKioSdall+Y4WOKoyrNXwydFVKOHxtSliKuFwWMxGFweKxNLEYvD U6u1eP1fE47DVHG+AzPG5PVqcyVOpj8DiquGq0KKm4VpVKsaFXGYWlOlCticuo4nH0aUsLgcfUwv 70UV+J/7WP8AwWD0r9jrxvbfC/4v6F+yL4Q+JPgL4CeFv2gPj94T+In7enh74S3s+j+J9V8ZWEHg D9jKz+IvwO0LxD+1t8TI7f4c+LriLS/Fnh39mfwrLfX/AMPdEu/GWnan4w1GLwp6B4v/AOClfxN0 n4kfFtfCH7LugeKf2cPgP8a/2Y/hN8TPjZqv7QB8LeN73Tf2ovCPwA8T+HPFfwz+CafBvxB/wlNz 4CPx4sH+IPhzxn8Sfhkq6Dp+mal4H13xt4g1fW/B/g7toQeIbVGVOShVlRqydWlCnhnHMaeUxq4u pOcaeDwtbH1FRw2MxUqOExUI1sRhq1XDUK9amThKEXKSd1hPrqhH36s6ChgZy9lRhzVqtenHMsCq uEpQniqMsRGFWjCcakYfrhRX5C67/wAFE/FXiX4cf8FJtY03w98LPBY/Yt+Fv7QmqL4e8F/tKW1/ +2hoWufDLS/G7eEvEXxM/Z1+I37KureCPgNovxO0zwhd/EH4I+N/Eet/H/wj4z8KXvhXxOfBHirw /quoaZD03in/AIKC/Erww3xM8X+F/wBnvT/iD+zf+zDrfw48DftNfF3XvjXH4X+M+m+IfEvgn4b+ P/GXiP4UfAzRPgnqvhH4peE/hn4M+KvhLxF441bxD8WfgVrGp3Fh49sPh38PvEX9g+F4vGaoQnif ZOlTnJV8JgMfSbi4p4HMa7w2Hxla6TweFVZ4anVxGOWGo03jsC3NrERaMVH6lTlUxU6dCMMdm+Wz 9rUhTax+SUcvxGYYOmqko/WcRToZjTrwo4T6xUnRwuY1lFUsvxU6f6qUV+T3gb/gov8AF7xN8UfD 9nr37KOjeG/2fPE/7YH7Qf7FWjfFax/aBTxN8UNQ+JvwP1f42adpvi60+Btt8H9P0n/hWXjl/g3N oo1C9+Mlj488OeM9XutNb4d634L0rT/iJ4j94/YO/a+1v9s34feKviNqHh/4EeFbDRvEcHhyHwl8 Kf2idc+NvxJ8Ba7HYi/8RfDf9pvwVrvwI+C13+zz8ePBP2vSrDxn8H57vx7f6Bqs9/aXmvLHZWdz qqoxdenOrRtUhSo0a9ZxaboQxFLA16MMRG/Nh8TPD5ll+I+qVlTxUcPjMPiJUY0asZsxMJ4PE1cJ iYSpV6OLxGBnBxcl9YwuJzLB11CpBSp1KUMXk+Z4ZYmnOeGnXwValTrSmkpfdNFfg74q/aI/aG+G /wC3V+2D8TfH/wAO4fGPg/4Sf8Mx/s2fsy+APBn7bPxw0Hw1rfxD/aT1vT9D+Go8ffs+P8IPDPwB hk8eeJfiDDrHxZ+N/i3UPib4/wDgj4W8J2OhfCrQfiiyR2Woe5eLf+Cif7QngXxBoHwP8QfsfeCb v9q/Xv2gfh98EYPh94b/AGoL29+Bk+g/F34F/G34zfD34w6X8ePEP7PHhTxffeC7S5+BnjHwb8St EvPgBpXjrwrd6F4n1Xwb4Z+JyWngzTviBnhZ/XKFOvQjOcamIeEuoTUY4x4zC4WGDblGMo41QzDL cRicFVhSxeDoY2GIr0Y4JLGTJR5alam5U1KjhsZjXCVfDqs8Fl2AxePx2NVKNWblg4wy3NY4TFU5 VKOYPLsTRw0pY6jicDhv1wor4s/bG+P3xR+AX7NuieL/AAvoXgOx+OPxE+Iv7O/wI8MW+uarqPir 4W+Bvif+0X8WvAXwbg8TaveSr8NPEHj/AMF/DrV/G1x4kTSbWHwD4i+I9roVr4ftv+EM1HxCtzpP k37M/jq+8K/tQeNf2dPF37a37Vf7Q/jvTvh1rfifUfAf7T/7HmgfBrRVXwn4l8IaNqXjz9n346fC /wDZK/Zc+FHxF8GWV34zs9D8Y6TYa78e5przWPB13ovirwkujeJIvF+9GlKtVqUoON4V8xwsXGSr e2xOU5bhs3zKjQhh/bVaqweX4/L8TXxMabwdOljqNSWJVOli54bKpUhSw9PETkoxqQwVXkqJ0alO jmOOnluBq1liFSjR+t42jisNh6VSccTWr4SvQp0ZV/Y0qv6WUV+WH/BS60/aB8H+AZfiD+z/APtm ftFfB34q+OdT+H/wG+AnwQ+HvhX9i3XPhn4s+OnxK8Ut4b8K+JvFMvx4/ZO+MHxQutE0FNXn8cfF Oy8O/EjS7e2+F/w78QX/AIc0rSdWhvdQvfnv4pfHX9rjw9of7U/7THh79ovxO3hf9ij4/wDw0+BV n+zjbfDr4FN4C/aA8MeHND+BUvxp8WfFDXtS+Gdz8XoPix47vviv40l+Gtv8G/il8KvBPhy80D4c 2N38P/FTt4qsPFWWGaxLrKLUI4WVV4uc7yhhaGGxGS4fGYqq6KquUMH/AKx5BXxGHoqrmH1bNsLW o4OrGOJ9gYqrRwcaMq9WEXiVbDwSnz1q0sPj8Vh6EYuCcHjKOT599WxNX2eXyq5FmWHqYyniFg6W L/dOivwJ8Aftf/tN+G/2tPhL4e+NXjn9qDQ/Enxe/a++MvwB8W/sv+Lv2KNc0X9kDwV8IrDT/jPe /A/x98Df2ydP/Z38N6Z4r8fa94e+G3w08daxeeIP2tPi3pfii08efEfQLD4O+BdbsNJ0r4Y/fP7S /j34seMP2kvgP+x38I/jBqn7PknxL+FPxv8Aj38RfjB4M8N/DbxZ8WtN8HfBfxN8GfBukeDPhXpf xj8KfEb4XaXqXi/xb8Y9Ou/F3i7xj8LPiVbaT4M8M6t4b0bw/ovinxpoHj3wdWHX1unhJ4WUcS8Z PFUoQpST9nWwGTQ4hx9J1pcuGrPB5JNZjVq4OvisNUpc1DC1sRjIywy1qxVCvi6FWcKbwlF4iVWo /Z06tKeaY3JcI4e0UatOWYZpgZ4PA0sVTw1WrUxGDnUhSpYmnUf37RX4AftHePf2y/h/8Af+Cimk 6f8At1/GbR/iX/wT3+G/iT4vfDb4seEfhF+x/Fq3xx8J+N/gpJ8TPAPhv9pbQ/Gn7NfxB+Hl94s+ Hni3wn4u0S5v/gB4X/Z1i1/wPrHh2+1zwpDqlzY6/edj+1Z8Sf21v2SPFH7HFp8Nf2kvib+0doOl 2n7Q/wC0L+014f8Ai58Mv2eL74j/ABz+Bnwo0T4TSeKvhl4If4D/AAG+D2neHfFngvw34z8VeP8A 4XDwj4TtPEXjTxpoel+BfFura1o2vxPpWcqtCnSp162IpYfDTxNDDTxOIcqNDDuq4+3rYmc4r2GG wEPbVsbXmlCnRwtepSdZex9rXsa8oYSVCjUxVXHf2zHC4bDKNXEVa+Sww0qmEhBSUZ4nHVMdl+Hy +nCclUxGOo08TLCqni5Yb9zqK+Gv2Kv2gtV/aH1b9rTxAnjnT/H3w58LftJaZ4e+CGs6TZaLb6Wn wk1/9mf9nT4oaEunX2k6dYXGuWWpax8Q9f8AEFrq2uS6jq8kOtJZtfDTrPT7Kz+5a6atCrQWF9tT nSnisuyvMlRqRlTrUKWbZbhczoUMRTmk6WKoUcXTpYql70aWIhVpwqVIRjUlyUMTRxSxEqE41adD H5ll/tqcozpVqmV5histrV8PUhKUamGrVsJOrhavuyqYedOcoU5SdOJRRRWJuFFFFABRRRQB8aXf 7D3wsn0XRdLtfFPxK0m/8N/tg3/7a/h3xRpeseGYfEuifFLXPGet+KPFPhuwu5/CFzYL8OfF+heK vGPwv8S6JPps+vX/AMM/GHiHRovFFtrN1b+ILXktA/4J7/DrQfiVZ+Kj8XfjvrHwj0H4y+If2ivB f7KOra18NT+z94H+OnijW9b8War8RNFuNM+FmmfHjVVj8c+KvF3j7RPh541+OPiz4QeGPGXiEa54 Z+HekTeFvAKeEfviioo06eHo4ahRhGFHBxw8cLS5VKFFYTCZPgsI4qSd5YPD8P5KsHOV54WrlmEx GHlTxNJVR1pPESxMq79rLGRxEMTKerrU8Xis2xmLpye/ssXXz7O/rVJWp4ijm2YYatGeGxdajP8A NT4cf8Eu/g58P9Z0Ka9+L/7RnxD8D+BPhl8ZPgh8I/hB438ZeBoPhl8Hvgp8cLfTLLxX8MfBlh4D +GfgbxNrGmaVp2i6NpXhHxf8SvFXj/4o+H9G0u00WPx9PpIlspdbW/8Agm18OPGfwx8J/DP4kfGz 4/8AxHXwd+y7+0t+yFpnjXxBdfBPRPGFx8I/2ndN+H+h+JBfx/D/AOCHgrwZL4n8BeH/AIZ+FtE+ HOtW/g+1jitIb278eWHj7Wbx9UX9FaKdOEaU69SnFRqYmjChiJ/FOtTp0M0w69pKV3OpKnnecurW bdatWzXMcRWqTxGNxFWpvRxeJoYqhjaNadPF4XFV8ZhsQn+9oV8T9XVd0ZtN06U44PBQ+rwth408 DgKcKUaeBwkaP49/8FKP2FP+FwfCrXte8CeAvFXxn17V9D/Zh+Enj/4ZW1z+z3qOo6n8Cvgp8dG+ Keqa58OvCn7TemWP7OPi74tWE+q3eoDQP2jNVvPgfr+jabLa6x4R1LUILTS9a9t/4Jj/AA5+Lvwn /Z/1nwF8QvDl/wCBvh54d+Iuu6d+zt8PvFvhX9kXwb8VfAvwmttM0OHU9A+Kmg/sE6bpH7IOm68v xZT4l33h2x+DNh5Fr4CvPCg8cXcnxFk8V2Wn/oDr2jWfiPQ9a8PagZhYa7pOo6NfG3cRTiz1Szms bkwSMkixzCGd/LdkcI+1ijAYP41/HL/gh58DPj/8TfHHxT8YftK/tR6PrfjzxnfeNdT03wdof7F2 h6Vb3lx4pg8W2Gmfapf2Or/xP4i03Rb2x0nT7G58deJPF3iC/wBE0TSdN8R67rsdqXk/QPDbIuBs 0xWeYHjnj+rwFlWKnVzGhjlwnmfGLq5jmGYYbFZisFleV4vLo4bEzq0cRjJ4/F4n2n/CjmGDpylQ xijg/Lx/tIwwlbCYGOJxeFw9HB01GtDDXwmCwkMHhKFfEVXOUaEMOqFGFKjRqxmsBhqlWNOphqcs T9VeCf2U4vgt8VvHPiHwv+3V+0V4W8J+P/iJ8S/i/rX7OOoR/sYzfDW28UfGBPGviXWb/TNU1v8A ZVuP2gLfTLTVdM8UeNfDlvcfGi7gjuPBuoR30mq+FtI17RZeV0L/AIJZfs5+F/APxI+HvgvxR8Yf C+hfGL4O+Cvhr8SbzTvF/h/VtV8beOfAHifUvGvhf9qHxDe+KfB3iKHWv2lz4n1rU9X8U+OtRtrv wx8SWnsrP4meBvGOm6D4bs9H4Hxx/wAEoR8R/hl4m+DvjH9v79uPVfh14y0250nxNoEOlfsGaRLq 1je3Wg3t6k2uaJ+wxp3iKKe+u/DWlz3t7batDe3jnVPtNxKNf14an88W3/Bvn+z7ayTyj9rv9tq6 e50rXNHuP7Tuv2N9XWa08S3U95rk0keq/sbXkbarqE9w/ma6V/tuOFLa1g1CK1s7SGD7rK/DnwIq ZVHC5r9ICGVVsNShlWHwmWeGHGeeYSrkuDy2WAy9VMbiv9XsVhpU6eKxWGhlrwuOo4Kjh8BiaGZV 8Rh8LDBctTG5vUrzxE8ojOpXqVMdib4/DqFTMq2aYLMKs50VTdGsp1YYrF1sVUgqlesng54ZYbMc bVX394r/AGLtR13xxo/xB8E/toftR/CD4223wo8D/DD4tfEv4c2f7I2o+Jfjz4W8F6r4n1PwFr3x a8C/FD9lb4lfCPR/Eek614h+Ic+meI/g/wDDH4SNfJ4k13Q7pL3QdF8N6R4b1vG37IvwO16y+PsX ibx94s02H9q347/BL4meLrk+J/BmntH8SvglpXwb8KeDfC/gZ7vww8EMGsj4AeGU1/Qb+PxBrd9q V34qj0i90dZ9OtdF+FrD/ghX8JNM03wvo9r+2Z+2udN8HXNvdaFa3cP7EmoKktlcWF1YJqr6h+xT dS+I7bTZ9K06TS7PxHJqtnphs4BYQWyoBXY3X/BGrwrd+MfEnxBm/bp/bgHjXxboGreFdb8SwWn7 DVpqknh3XPD154V1XSNOntf2IYf7Cs7zQdR1CxePQl00ob++u4mjvry5uZd6nAPgcp1oUvpA0quH nRzGyl4WcX4OpUqV8yweYUsLanDFQwuBxeJw0MxrxpOrTyzFYeGHwuDx0cTVxlPTDY3NOan9Yyud Dnp4ahiK9DMMPiqkadJOkpzpVFhHmVXDUcPgPYzxGKw1atCnUwjxGGp0qNaf0B45/YQ8DeNLn446 j+0B+0/8evirdfHr4F/Gr9mLw/dfEC7/AGbvBf8Awpn4S/Guyn174meFfg4nwp/Z++Ftvq1/Jpfh XRtVttb+M0fxl8QaLpvw7tL2K/S1m8bS+I6/jz/gn98HNX8W+INW1X47fGvwb8Ifi7rngbxF8aP2 a9N8V/CjTfgh+0F40+F3g/QbLS/EXjK+134W6l8adGub7wV8KvCB+IHhb4OfGT4Z+BPiB4d+H0v/ AAnvhDXtI1r4iJ4q+Y9M/wCCG/wk0P4UeMvgpoP7Xf7XHh/4efEXw7oXhT4gWPh7wn+wHoPiPxxo Xhix8O6X4etfF3xA0j9hWz+IPiOfRdK8K6NpWnalrHim81S10tNR02K8Wy1zXINRp6J/wQu+Fvhz 4Y/Ej4OaR+23+3ZbfDv4uR3cXxD0OXUP2N7668RRX2vL4nu4m8RX/wCxpdeJ9MjuNc8++kTRtZ05 Sb/VrfAtNZ1aC81pcAeA9GnRjD6Q1SLweZYTCYanDwr4vhTr8PvGU8yxePrt1Z8mZUMzxeZZkshr QzHBZzmOGwuYYziDA4zGyrZZh9ezuvGKxWSUU608XiMUqeZ0Kjo4qvhcuwCng6rwtGUZzy/KMtwL xMI4WphcHh6eFw9OVCnKniPuOy/Y5+C+n23hbwDpPxG8cWGveE/2m/i3+3D4eS38Q+A7jxXB49+M Pij4s6xr9y2l3/gy9tbv4c6L4g+NHiK28OW82iS3ED6f4csta8Ra5JBqY1jrf2f/ANnHR/gT4o+K XxE8U/H/AOK37RHxX+JR+Hvg7xn8Ufjc/wADNG8RWmg+CF1d/hx8O7Tw/wDs+/B34DfDbTbTTtR+ JHiHVrCe48CTeN9cvfG6war4j1bSoPCum6T+b9x/wQV+B13o/ibQrj9rX9sGTTfF2ra3rusIdG/Y WW7j1bxJNoM2uXuhamv7EK6p4Vl1EeGtLtph4WvNGjXTzqmlxJHpuv69a6lo67/wQr+EPiTUvC2s ax+2J+2Xcat4M059J8P6lBpf7DOnX0GmL4c1XwlYWOoXWm/sRWk2u22geH9c1nT/AAlHrz6mvg7+ 1L+68K/2Pe3U1y9UfDzwBoupCn9IivCjiVOeKj/xCbi2pzYjD5fleDwdajCeK5KMsTQyvBZbip0+ SthcFgsPWVTM05YBGJx2d4urVxOIyejXxPtK1WnUnmNGEqkq+bZpj6rxFSNGTaqVsxxGcKDhVhQz DMcXg6anHCUs1xv398Tf2JPhV8U5fj3fa14h+I2ja78e9c+CfjG58SeGNd0TTNc+F/xB/Z2OlXvw g+IHwrubjwzf2+neI/CviLQtF8UPa+MrXxx4X13UdPOk+IvDmreD9R1nwxqXH+Ev+Cfnw90XxZ4I +JvjX4ufHL4yfGfwl8ctC+PWr/GT4kan8LbXxf8AEDxF4R+DfxO+BPgnwl4o0D4Z/Cf4cfC7QPhz 4N8BfFnxSdF8LfCv4efDg3HimWTxlr2oa14l17xpqXin44vv+CGnwov7xbyX9sj9s23EfiS08WRa fpel/sL6LoMGs2HiO78V2gtvDej/ALENj4fttIg1u785fDcGmR+HDZWOi6O2kto3h/Q9P06Dwv8A 8EJfgP4L1K41Twx+0j+0LpU0tjoWm2VnH8H/APgmvcaJ4ds/DY8UtoyeC/Dl5/wT9uPD/gSS1uPG fiDUZbnwZpmg3N9rE+n61fzXWraFoN7pnNQ8OvArC0MRUw30iVTxbqRxVCh/xCTjJYWpjHicHWqV 6ld4ycsLWl9Uw8p4qjgq9bELA4PDVv3FOl7Dapjs29vUpU8p5sE8PjsJHESx+Go4uthcdhsbg6+F r4enCpH6tWw+KnCVGWOrUqEsZjKtGDrRU8T+s3xx+DXw0/aI+Gfij4J/FjTJtZ8H+NrK0kvbDTte 1fwx4is7vw5rWkeINB8VeFfEnhzUNK8TeGPFHgvxXYeHvEvhjxZ4d1Gw1nwx4m0/RdX02+tNQt7S UfJ2ifsU2XgS/wDGnxN+MX7bn7VHxX8VXnwK8Y/s/eGfiv8AFbXP2Yvhr4g+CXgj4k6j4fu/FGsf D7xF+z/+zf8AAOxh8b6rr/hnwTqVh4v+IsPjvUdG1nwzpMnh46a+oa9Frfyj4Q/4IY/BvwBqsmq+ Cf2r/wBqrwsstpomnnQNE8C/8E97DwOmmeHrbxlZafpUHw8g/YPXwHbaRLZfEHxrZ6zpNv4ci07x HZ+JNTtfENrqkEwjXL8Mf8EG/gt4Ph8MWmi/tf8A7Zraf4Q8beJfiJomk63Y/sP+KdFHjDxhpepa J4m1XV9E8UfsTaxpPiWPWdI1a90280vxJZ6to7WZtoE09E0/Txa2/DjwCVXFv/iYerVoSoeypr/i FHGOGq4tYzKczwGZ05tYvEwyqdSji1lEMbh45jXr5bjsbiKtOk8JQyzGS8fnEoYSDyaCVKrDEzUs xw1SNLFYfMMLjsLOnB0IfWIQrZdluMdOtKnCOMwkHGMvZwqv7v8AFOh/sxx/F74F3fxF/aV0+++I P7Gugaw2j+AvHPxi+Hq6hF4p+Ifw0l8JWPxi+LWi30Fr4uvfiMfhdbfEG38La7d3+i6FPovjv4j6 4+g6ncy6dqegcf4v/YM+DvxY+MXjXx4Pjj8Yk+Hnj74kfDv4u/G79lXwr4n+FM/wB+Kvxb+DtxpH hvwp418ew3fww1n426PPb6v8IfB2neMPBXgb4z+B/hr481X4Ux6X8QvA/iQXfxDsfFHzl4y/4Iu+ C/HfhLw54A1r9uL9t6w8BeFNPutL0PwN4Ltf2HPhv4Ngsbu6m1KaG88LfDv9iPwtoWrldcuLjxTb zaxYX89n4yubjxpaSweK55tYf9Pfg78JJvhN4Y0TQtT+Jfj/AOLus6N4ctfC7+O/iVa/Dax8Vavp lhr/AIk1vTm1Sz+E3w6+FvghLyyt/EMWgC60nwbpb3+k6Bot1q41HxI+u6/rfyvHOQ+G2UZfk+ac FeIkuLeIHmGKpZxg55DneVxo0JTjmGGzbC4jMsjy2hiKWJzPC0MVWyvEVqlbI8TTyeGAr5zHLKeY 4WsHPHSp1MLicDDD4b6nh6FGKrwqOKjzYethvaRnOrGNPCYjF+yxVONOpiXWxOHrU8PDF16s/HdL /Y/tbn4+aD8f/ip+0B8f/jxqfw713xt4k+Bnw4+I938HPD/wo+A2sePtI1XwtrepeCfDXwT+DPwi 1bxrq9p4G1vVvAfhrxF8e/Efxk8T+FfDGra8nh7WtO1jxR4p1jW+l/aF/Zc0H4+av8OPG+nfE74t fAf4x/CGbxQvw1+NvwR1XwXbeOPDWjePLTSrDx/4SvvDvxU8CfFX4QeOvB3jW00LQW1jw38Svhf4 z02y1nw/4a8X+HIdC8a+GPDviPS/p2ivyi37vD0lKajhVag4znGpC9SpVm3VjJVZyqzq1fbzqTnK vCpUp1nOnOUX63PL2lWrf3q0KtKomk6fsa0KlOpQp0reyo0JRq1bUKUIUoyq1ZxhGdScn8OxfsD/ AAquP2ev2lPgH4n8b/FfxvqX7X2jeMdP/aM+PXifWPBZ+OHxI1Xxl4DtPhjJ4mnu9B8B6F8LPDV9 4Z8A6XoXhbwX4b8GfCrw58OvDOmaDp8dh4IEk2qyal77r/wO8JeI/iz8H/jHf3/iGPxN8FPCvxL8 IeFtPtrrTF0DUdM+Klt4MtfEM3iK0m0ifULu9tI/A2knR5NO1TSre3a51E31tqKzWy2nstFOoo1a cKU4U3RpKlClQjThChRp0KCwtCjRoQjGlRoUMMo4ahh6UIUaNCMKNKnCnCMVKclCjTc5yjQli503 UnOpUVTHvCyxtWdWpKVSrVxcsFhp4irVnOpVqUo1Jyc3KUvkX9jz9ij4L/sNeEvid4D+BR8W2vgz 4m/GTxV8aJPDnifW7XW9O8Eaj4o0jw1oEfgbwB5OladdaL8NfCui+FNH0jwV4Y1C41mbw1o9vFot nqh0ey0ywsPrqiim5ScKEHKUo4bC4TBUFKTk6eFwGFo4LCUVKTcnGhhaFGjBybk4U480pO7c2XPX qW9/E4rF42vLrVxePxVbG4yvL+/iMVXrV6lrLnqSskrJFFFFIYUUUUAFFFFABRRRQAUUVzf/AAmX hA+Kj4FHivw2fG40ka+fB39u6X/wlQ0Iz/ZhrR8Pfav7XGkm4/0caibP7H5/7rzvM+Wjql1d7Lq+ WMpyst3ywjKTttGMpPRNhsm3ola76LmkoRu+l5SjFd5SSWrSOkoqnDfQ3F3e2aJeLNYG3E7zaff2 1pJ9qiM0f2K/uLaKx1IKgxcHTri6FpL+4uzDORHUD61o8eqJoj6tpia1JBFcx6Q9/arqj204vTDc Jp5lF20Ew03UTFKsJjkFhelGItZ/LANOis3Wda0fw5pWoa94h1bTNC0PSLSa/wBV1nWb+10vStMs bZDJcXuoajfSwWdlaW8atJNc3M0UMSAtI6qCai0HX9B8U6PYeIfDGt6R4j0DVYBdaXrmg6lZ6vo+ pWxZkFxYanp81xZXkBdHQS288kZZGXdlSAb3try8vN5c3Ny37c3JPlvvyStfldja19Obmt58vLzW 78vPDmttzRvbmV9eiqzXtml5Bpz3dsmoXNtdXttYtPEt5cWdjLZwXt3BalxPLbWc+oWEN1PGjRW8 t9Zxyuj3MIeH+1LBoNQuILlL1NKe5hv004Pqdzb3NpCs89k1np63N29+kTxsNPige9kMsSRwO8sa sm0k22klCVRttJKEJqE5t7KEJtQlLaM2otpuw0m2kk25SUIpK7c5JyjFLrKSjJqK1aTaVky/RWPH r2lyajpukieZNS1bSLvXbKymsr63uDplhNplvdz3ST20Z0+SKfWNPhNnqH2W9eSWVI7d2tLwW9nT dU0zWbNNQ0fUbDVbCSW6gjvtNvLe+s3nsbqexvYUubWSWFpbO+trizuo1cvb3VvPbyhJopEXT2dT kdTkn7OM/Zynyy5I1OarDkcrcqnz0K8eVvm5qNWNr05pSpRdrSTulJWad4tRkmrbpxnGSezUovZq 9+iqGparpejW8d5rGpWGlWk1/pWlQ3WpXlvY28uqa9qlnoeh6bHPdSRRPf6zrWo6fo+lWasbjUdU vrPT7OOa7uoIXDqmmLqceiNqNguszWE2qRaQby3Gpy6Zb3EFpcajHYGT7U9hBdXVtbTXixG3iuLi CF5FkmjVnGjVlHnjSqSg/aWnGEnF+xjCdb3krfuoVITqa+5GcJSspJsbSTbaSjyczbSS9pONOF29 uepKNOF/inKMFeTSd+ivI/iJ8fPgr8HfCupeO/jP8UvBHwV8D6V4kTwld+M/jR4g0/4R+E28QTIX tLCx8R/Eabwzo+qjUVWX+yrzS7y8sNWNvdrpl1dtaXQh7Hwp438K+ObKDVvB2sQ+JdAvtI0HxBo/ inR4bu98H+JdC8T6curaFrPhHxhDbt4X8YaXf6c8V2t/4X1bV7WCKe2NzLA1zbrJ31MlzmjgI5rW ynM6WVzrVMNDMqmAxUMBPEUVh3WoRxkqSw8q1JYrCupSVRzgsTh3KKVanzQ6tJVVRdSmq0o1JRpO cVVlGlVlRqyVO/M40q0ZUqjStCrGVOTU00urorg/BPxQ+H3xJuPFdv4A8WaP4yTwP4k1Dwb4q1Dw 5cHVtE0jxho1xPZ6/wCE5PEFmkuh3Hifwxf282m+LNAstQudW8Kamo0zxFaaZfulu3eVy4vB4vAY ieEx2FxOCxVJQdTDYuhVw2IpqrThWpudGtGFSCqUqkKsHKK56c4TjeMk3alGXNyyUuWdSnKzT5al KcqVWnK206dSE6dSLtKE4yhJKUWkUUUVzDCiqMOpWU9/e6ZFNuv9Ohsri7t2jlRorfUPtIsp1aRF jmhuGs7uNJYHkQS2txCzLLDIi3qACiiigAooooAKKKKACiiigAooooAKKKKACvAPG3wY1jxt4t8R 6pc+L9M07wj4k8HP4W1Lwla+G9dnbW5JJLQteeLWvvHtx4L16GGGGe3tJLT4eaH4qjtXtdKuPGN3 4fgvNE1L3+ik0m02k7Kokmrq1WlUo1E09GpUqtSDTTVpXWqTTu0mk2k3Buzs706kK0GmtU41KcJJ pr4bO6bT/PH4n/sry2+o/DKLw34E0j4k+HvDfxCHiTTvDlzpNnpvhrwJa2HiK61Lw3bG1Hxl+G7w 6Noek6xcaHZy2Wm/ETTdO07Slif4S+IIryytNL7G2/Yv0OWXxI+t6p4F1A6lPLf6Je2Hwpt9M1y0 8SQWfjKDRPiJ4p1efxfqj+K/irp154tXULnx7Z2/he9vZdItVtrPTGkM0X27Xn3xW8GS/ET4c+Mf A0M9tbP4q0S60Uz3kFndW0UV7tinea11HS9b066UQmTFtqOj6np9w2Ib6wurV5oXHKVONWUE51JV KmI1laU6044HXmekZOeW4SSqtOpGVP4+S0UuWM3TjK0YRhTo6K8Y0oSxdlyrVxUcdiYukn7OUZv3 OZuT8Ns/2d4PC/gf4y6RP4y8JaG/xJs2tX8U6V4LuPBjWzpe6zdW3irx7daT47sb/wAY+P7y51ww 6/410vXPAV5qkNlpiabbaFc2sVzXAaF+xKmn+KLrxVrHjjRNa1HV/AWueBPEFy/hDxlLqGsaZruv T69c6ZeXfiT4weKrfWPDn2uY3s8fjGw8W+PdT1d7i91j4kahYPbaRZ48HwQ+MHwn1garoPi3XJfA un+D28BaR4S8E+JvFQ0qS91XxhG+ja1bfBfw58PE8L+FddmluY9U8S+M/DHijwz4Q8MaVcahoGn+ CtD8JaW+rTdP4f8AgB8dbfSfGOn658V/E0017418T+MvCV3/AMLs+ImqT6ff3WhXEHh22+02/hXw re6V4ItfEKaden4VandePvD+mafHeW93rXi57mUTOMYc0eWzhGlUoqbj8NPDTqZZGlyy/wCXlXLM dXrqE7TnRrck3KMlXipSlJS5k1OVWnUlGLterVp08dKpzQavSp47C0aTlFSgq1KNSEeaKpvJ+JP7 DGieP7nxhEmp/DbTdD8RR+TZWEvwl1Qax9kGqeG9S0/SPFvirwn8UvBWs+I/D/gxfDsFj8N9I0N/ BK+E9NWz0m6uNf0SHUNL1fr9a/ZITWfiD4F+IU/jSxm1fwW2umO+vfDOvS66U8QaFBoeqppep6b8 Q9I02EazBG668PFegeNo7i18uHQ4/Dl4+p6lqjvjF+zh4p8bePfEnxK8I69p+jeJtR8GxeDNIvbf UE8G+JtIszpOvw3epaF8S9A8F6v458M6xJd6jDYWULX3ibwRbW97ceJr7wDq/iLRNJSfV+GXwo+N PhvxN8P9Q8Z+MJtesfDXhPT9I1nU5vi/8Q9eu79rLQtU0l9B1TwXceF/DvgXxtf3ep3Wn+Jr34xa tZ6F40urux/skeG4LN/tNZ0oR5VTs4KMfZ2lKUvcm8Y5e/J+8508LhvbycnOpTxMMPUdSVOFGtdS TbcnaTtOUeWKitZYaTXLFe65VcTiI048vLF4d1H7OhKVWj8vf8FA/gl49+KnwR0DwR8L/hnqPx3L y+BvDl23hvwb8CvicPB2ufCPxnY+K9P8W3fw5+P/AO1T+y38L/EMmneJfDccSaR4n8YfEnQdP8X6 XoMfjL4PeO/D1pq1nb/lv47/AGHvi/448U6f4oP/AAT6+NXh+50H9qDwx+0xoD+FvhL+wV4I1RfF /hzxN438XQ/EbxVrnw3/AOC1fgbUPHn7SsWpeN7vTLH4xeKGvfhzP4Z03R9M8Zfs9eNtS0XQNc0b 9AfiN468N+G/HXirwr44uP27tNv9Pv8A4deHNVtPgv8AAL/gqhrPgiXw5pfj3U/HXxI1Dwv4s/Zk +Dms/CS91/x5aXWhPB4y8C+J73xHHby6x4I1nxNodp/bmizfAmheLvjro+ifEvRdT8b/APBQjxtb +L/2nPFvxV8L/wDCSeAf+C4ulaj4E0DxNo0+m6T4k8IeKPAf/BNzwh4n0rwF8Pr+Oz1nwv8AsD+L dS+Jfwa1V57qz8WftBaw9uuo33+i/gRjPFjhrgTB4LhmhSw2EjiXxNhsVm/h7xnUxWZy46hleY5h WyfOMt4qyXL8xoUFSoUbOjgcHDDUZTpYmdPHYipV+JzXC5ZXx9d4iCarZXhcrnOGNp2jg8vwfEOG p4HG0Hh61elHDr21N+xWKxNeGd0asKE8bKGDPWfi18APiP4l1bwJ4r0v/gnN8bPB9t4M8W+JfiP4 18UeMvhR/wAEtvGXjGy1zUfiZZfE3VfiD8I/G1z/AMFT/C+mfBv4k+INJ0jT/h/8VviL4k8N/FYf EH4eeHvDWh6lo+lafoEcM/za/wCwn42u/wBg+z/ZQm/YW+PM/wAKbGx1zW9Mt/7P/ZGuPgLa+Htc +Jeh/GMTWuk3v/BeG9+N9poNpqml3XiuK+0z9q6wW58V6gdau72b4evq3wz1ut4KHhzXv+Cjvjn9 qDxh8D/26/CPiPSrPxfFYftC65/wSh/4KI+J9X8b6NN4ji1TwP4Q+E/xZ0bx1qvi74Z6db2Elnoe u6V4g/YJ8NyWvwzvvil8E4PiB4i8MXHw58R2X0j8TD4C+M8dnp/xVvf+Cg/jbw3q1/4E1jxz4N1f 9k3/AILWt4J1PWvhNrfwV8R/DTVdF8HW37MFt4c0e60vXPDPxY1fxF/ZGn6JB411TW/Beo+NoPE9 9oul3HhL9bp8ReJfCeK4KyXLateeXYCfCXiDi8dk/hR4o4mpwxxrhK+dY6GHwMn4lVKWd5nw1Rzv PKuSZrXzvBSpYrOKOUV8qyGNbEzy3GtDBYuvVlVXtISeKwic8bgKNSvShl2Erv60o4F0qHt6tGOD qVcPLNKOMxTjiI4mrVhVVTg/2svg9+1l8ffh94H0zwV/wTl/ae+MVlc3uo6lq2peOvjD/wAEoPBT R2Hibwz8MLD/AITbwnrnxH+L/wC3z4E8Tandt8O7fVltdV+E2nap/amoeGvGHhH4n+ENf8D29x4k +h/GHwX8e+NPCkfhLXv+Cd37bvim3stGW60rWvHzf8ErPEniCy+LUHh/4irYfHFG8P8A/BQTwP4W 0n4hab8R/iDL8VdKn8BeEPAWmeGvEmmR2vgew8IaedMTRPDP2hfEnxH+IngPxTY/Dj4y/wDBTrwf 4w8a6HoOj+MD4P8AgL/wWQ+EtxqVv4RvPg3ceG4fh148vv8Agn18edL+AOrTS6J8X7vxp42+H3wV v9e+IVhrui+FvF9rqtvrD674F2fjH438c+KNN+EOp/Dr4lf8FNdF8b+FPjv8K/iD42vB8E/+Cxfg zTtd8F/DrwZoOjRaH4k06x/4JyeN/h38SfDep69F4r1P4l/B7SPg/wDAzQ/jle6tomua78R/AY0E +G9Q+fw0/EHF5FwPluF4W4UyWngcy4nWErUuAfG/D5nlWKqU8nx/tc7lW8RYYTDYGvinj8Pk2YZR l+FjiKdOjWxEKmPx2NwWR8bpYKk3iXHE1p1cPjKVeksVlns5wpwzGvU/dPDVa0pZhiKdOn9WqVJ4 eVPMaNSk6taeMg+5v/2btXuPCWteCrD/AIJdftOaP4fvdV8UeMNB0vTfC3/BLWy0zwp8UNWi+KN3 4a+KmjadY/8ABSOzt7Xx54J8UfEPTfF2i+JrH+z/ABBHrnhKzvbPWNMvbyK90vjPgr+yp4t+Dl98 W9T1T/gnD+1R4ki+Ivxx8b/tAXOtag/7C+ueI28c+IvDHi7RNJ+InjO4+Nn/AAWF+NvgG8+Lnhe8 8TR+IG8f/DT4d/Bvw3qN3o1nGfh3p0MGntpfUftDftAePPib8R/FXizw54B/bLvfDureG/D2l6Z4 c0vwt/wX1/Zis7fSdC8WQzX/AMPoNI+AP/BPm40Pw/feK7a0tfiNqP7R2m2t78XdLu2v/wBnmDRt T+F+oXHjVun8Ca/Lr3xO+Euq3XxI/wCCjN94yj8R/DDT9QTXfgL/AMFnPAfwn1jV/Dnif4C6Tpt1 4n8PeJfgH4f+Cml+HdT8JWn7RNl49ufH0GneBPEF9418H+K/ijNfXHhqw8VeAPCqZ/4vYLhLGyzf J1lmE4hy2rjc+y9cJ+KmPwbxmFw+DzWVLNsTgfFOpjsPhsLioyWPzTG4DBxlisNhK+V0s4jTxVXK fXqUsBRxGElhaixtanjsJisNzV8ApRxU8NmUVUqSqZfiI8sIZhjaNem1iKc451yOjWxdTMsHgvIv hl+zf8fvhr+xP4a/Y28N/wDBPr4r6x8OvDvjHVfH+k+DvGHwr/Yl+KP7O+q3Oq+MY/Ftt4a8TfBz 4pf8FyPHnivxj8ORNf8AiHxNP4Z1z433k83xSvfD3j/Sdc0TSPDMfgbVJtO/ZP8AiFe6D8SNC8df 8E1fjVrUfjPWtb8Q6VP4P+DX/BMDwMV8YHw/8Q7HwV8ZviNDcf8ABVbxZF8Q/wBpDwn4k8fQ+JLn 406aPAV5qieDvCWm6P4c8J3GlrrDf0P/AAwstS034b+AdP1iG4ttVsvB3hu21C1uwwu7S8h0ezjn tLncS32i1kVrebcSxkjYkk813Nfz1iPpceIcsVntefDvBSxef8R5lxRnWO9nxjDMsw4izTHUMfmO b4nMKPGyxf17GY3CUMTiKlLExjKtDmjo3f0KfD+DWHw1GNfEujh4WoQjOj7KEJzr1ZRpxdBpUqk8 XiZOm24S9vNSTTVvjL9jX4Xy/DfwZJBY/BXWP2dfCMttrcHhL4La5p3wc0O++HemX/xn+NHjS28J waD8BPiT8WPhVpmhaLo/jLRI/DS+FPGl3aTaTcxNd6V4b1RdQ8O6X9m0UV/NGe5viuIM7zjPsbGE cZnWaZjm2KjTniqtOOJzLGVsdiI06uOxOMxtWCrV58tTGYvFYqcbSxGJr1XOrL2qNGnQhGnTioxj GnFKMYQjanShRgo06cYUqUY06cIxp0adOlCMVGEIxSQUUUV5RqFFFFABRRRQAUUUUAFFFFABRXhP xP8AjG3w/wDG3w+8MxaVqOo6fr12J/F+o2PhTxf4hg8O6Lf6lY+G9FutR1fw9p11oXg23uNX1K51 qfXvGt7YaM+geD/E9lZ+dqsto9t4zpf7WPiDV7y61LTfA/hDWfCeg+I9f8M+LF8MfEK+8TeItOnt fFnh3wx4butDl0zwW3hXxZqWqN4k06413w1o2uyweHRc/Y4fFeteIbHVPDdnMZxlKlFO7rSxMYb2 /wBjjTdeT0vGEJ1aVJ1GuT2tSMXJJTcXKMoqV07xeFi4/a58bNww1NJ2vUqpOrCn8U6SU4KXNBS9 z+MOsfEPST4Q/wCEGh1Q6ddavex+OL/RdDi8Q6xo3hWHT3mu9W0TSp9Ov4tS160KltJ01tz3UzPL aaP4wv7S08FeIvGn+LXx48GWus/8JV4SvfFsN3Z67deDtQ8M/B/4h3eoW+rX914xh8G+FfFemeGr 3XnmW2fw3YnWvGFvY+GtFWx8QaIdTtvDjXFvqWqaPw5/aa1Tx54q8JaOdA8Cf2L4kfV7SXxT4P8A iLJ418GpeWFppF7aQaL4xHhjQBrerXcmpzaDLoLeGtOtLTxDoviDTpvFK39jpmna7q6j+0UPCvjL xZY+PD4Y8I+CvDfiWDw/Br+v376HHqFjemwjm8V/21eXk2g2mh+F9SvNM8N65FdvBqEut+K9ElvY PDOlnw9d+O6Vo+zcnaNWGIrpyd26VDG4HA1aUVHmcak686CoNQnKmsTVrTtRdaKiUlao1d+x9lGS im/frYPEYyjUtZSlGNGnW9pSUl7WVKnTpQ9u6U6nm9v8bf2lrnxp4b0+x8H+HbrwZe+KfHFlq+p6 38Dv2kfCWuy6PpF0tt4e03TIF0zxToek6qLZY9Zm8W+LtW0fwN4ut9UtNK8N3thqmk6+ljU8a/Ff 9sHwt4c1G/07wx4B17VRHGmn+V8DvjfPptpKLbwHrT3Oqaf4O8ZeO/Ft9DdWvi/VvCNraaD4fvZb TxR4R1DWNSurfQTrkPhTtLT9pDXvEcGlyHwkPDekeI9M0/VPD2uaD41sNW1ad0tPCE+vWOqaXrfw 7l0zToLOTxxpA0m7s7nWX1qK2vZrhdAaOK2u+cX9qPx3q3imDwh4L8NfDTVdVt7KwQ6B4n+Jd9a+ OLm7l1fwNpwvfGemaD4Dkh+HWla3ZeIdU1Pwfq0GleLYPGFpHZapFpfhu0WexaKMZKnGDnKVRSw+ HjVnFN800qrrunaampwSp2qRm+VxnGlUc51amlaUYVnOSiqSp4+o6cZL2SdGU6TSrJq/sKlKpKLh P2MqinCVSFGMKFP07x9J8cfEHiX4f3Hgu5vfDfhUeCr3xD8QNIllgs0ur2V9MZfDahvhzrnia/1l 7Z9R0+0tfD/j/wCFOq6TcSLrhv8AWHsl0huAh8ZftKW9lqMmnG3ubzw9rt9qbeHNW+C/xA8m98HW vw9t/EFj4RtvFF14rWbxF4g1PVWOk2Hi7TLzUZ9J1+OfTvEug65fzDTLfC079t3+0JPHS3HgvwJ4 XtfDNv8ADq70bWfGnxy8P6Ho1xbeOzbRTTfEH7H4Y1jX/hVHpd1e2sOly654e1G38YW8g1Xw9NPp ElrfXLNJ/bN8Q+I9Y1vS7LwH8P8Aw1b6DrHwrE+r+L/jLp0Vs/h7x9PBZapNr2maZ4Zn8Q+ANVsd TvtMsfCyeK9Ij0/xtb3g1nRbqXTXsXv96Eb1pU6UFN4ytGhRjKXOqdWrmqxdOKqSf7z6rTrwwfs6 kpyo4KGKi48s8TBYV704N1qkofUYJ17RcZT5cvWElGUUm4zxFTDVcTP2ai54uVGcmpUqUzU0D4z/ ALUtxaeKrrWfhf4XmubfxvqegeHtE0XwX8ZrG/0nSYUn1Ozk8T6l4s0XQtC8SJFpmi6tps/i74cX +v8AhPUtd1fw+NMl+aDT9c0ZPjD+0hJ43l0q2+H2kQeF9U+FaeJ9Fa7+Gfxbl13RfGOotbX2n2mv atDJH4Dv7DTbC6/sTWfCK+JPDnxDfxJZX90NJ07w8LS+usbXv2vPGHgu88O6d4n+GXhK5bX/ABzp WjxalYfFiw8PwHwRrviXxR4fsdftLHxh4c0tNU8c28vhe9L/AAt0XV9W1bWY8X3h7V9RtoNYTRfW PCfxx8Za/wCPdN8Man8O/Dmk+HdW1Ga0svEVl8RNR1fWDaXVt8Q5dBupvDM3w60i0invJ/hh4lg1 m0Hid00dLjRJ7C78Qfbb6LS8aUeaME258sVS5m3ScnDKqMKim7q05yxmHxsJO1VYl1KEZzrUZLD6 zlyym1aN+avblVRRpvMKs4OCSa9nCnha+GmknB0HGvJRoVaaq8L8ZfGvx90z4Q2up+EdLiuvjVp1 j8XP+Ef0PR7TWvDWheOvHHg6y8SaP4PsTpt7p/xC1TS/DPjC3hbxVAt1pfjsaTaR2upW9r4klsbK S4+b/Ff7Tn7SWrfEjRvhRp3hS+1t3+DHh/xh4+8M6L+y7+1R4Q1bT/EmraT47v5dTi+P3hr4mP8A D34fLo3jDwRpnhKD4M3l/rnxF8fad4oTxb4Z8Uz+D7SSbVfGv2if20NI8X/EP4j/ALIPxf8A2Tfg 9+0h4Og/Zz8UftHaTZfELxt8EPHeseLfGfhfxjfar4Y+F9x+x58QYPDXiG88PaXo1lBZaJ+0Bda8 fhjF8R9OtvBOp+KdP8Y23iCXRPOfEmg/8EqvD1x4f8GD/gnD/wAE0b/42eKfC1n4z8P/AAkX4cfA Gx1nV/C83wo+I3jrUfFenwX/AOz9B4yu/CHhrxx8PpvhN4q1+HwAw8OeJb64TVrK11nTU8Maj/YX hr4azyvhrBY7ivgvMMzx+f4HG8U8O4rh7L+A+IqtDIMyyrJq2X5zm2KxfHeWYnKMNgo0sxrwy6WC yfMMsqzxGMrZpha8KMMF85mGKUq1bDUMbCgsN7HCYmWIq4mlGNapUwNWjao6E4yly47CKjUjWjQr YjGfVMbRxkadfBn1TpPxa/4KCafb+HPEFqnh74of8In4t+Kvhv4nfD/Uv2S/iz8IL7x3E3x68MfD 34e2nw98YeIPiVPZ+GpvCXhDWr7xpefFUaR8SPhb8TPAum3mpaXpvh6LTr/xxFwvwc/bE/4KI3Hw W8HeOvjD+zr4K8X+M9Rv/Gep+K9J+CfwJ/bK8AwaX4V8B6rajUtHj8D/ALSngXwB8VrXx54h0vxN oNp4Hih8L+IfDni/VPCni7UvDmpazol9K/gz5v1v4VfsE+GtB1vxx4s/4Jf/ALDPh3XfBVr4t0jx l8Px8KP2YZfgzovi/wAD3Xxb8K+J9R1n4rah+yPZeN7D4TaF4i+Gl34i134n3Gj6VeaL4BSbxpqH w7hOjal4J1PxKG7/AGRdK+GPiH4y3v8AwSS/4JB/Ev4dQ+E/iFc+GfEvwpT4IWvg7U/iL4X1X9o/ U/Dei2vxQ8Y/sxWnw71H4EeI/AfwJS7uf2odc1nwBo3h6+1B/FHib4YaB4Al1HW/Cn6xg/D7hfNs txsKvh9gs0cuJcHhqeOjwt4X8NzjUxP+sGJlwxSxeW+L2Q5ZiPZ4jHzxuHzTBVaNKpgcDgMs+uZt gcHleGyvjnjK9bEUJUMVPDvH4iToUJVsZONWlhKWTYSdOpTq5f7bDXq4ihVxk6SwLvmGPrKlhFRj iMv/AE08P/H7/gonr/xr/aT+ENx4H+D/AIe0nwvf/BbRvgb8TJ/2Z/2sL/QNLufEMtlpvxP174kX Wt+KPA3wo+MPh+a4vH8T+Ck/Z++O9xdeCPCljLp/xlm8OeMpZ9B075L+If7Wv7cvjj9tD9nr4Y+A vihF8J9S1Lwt4M1fxh+yNpelfsX6b4h8S3PiD4X6P401XxT8SbL9pz4zeEv2sm+Gvg7xlc6pa+Lr z9mP4S+K9R1L4aaL400PR9T8O/GX4calbeIvn7WPiZ/wTfsvAPhLxZp3/BJv/glJe+LPEf7L0Hx+ uvhLe+Kv2SLLxvaa1ceFvHWslNL1fT/2dtc+Gur/ALNem+IPh7q3hTxD+2HeePdD+GXh06t4Z8U6 po0HhO/1TVtE7TwB4V/ZW+L/AId0nV/hx/wSY/4I9r4r8Y/DT9lz4geBvhZ4hHwR1TXb65+MnjPV PBfxGg1Pxf8ADX9mHx54dvPhd4f1nQte0r4dfHnwDZeOvDfjO+07TZn8KwWniBzoPt5bwFk3Cs8x z7M/CjJ44afD8eEML/rHwn4MYzK8HxFj8pyrg3F8S1cFi/GLGRrUK2OwtTPMPi1HA0smxUsZnGW8 TYPFzzHNcdx4nFzx+Hxbo5pWpUMRgqmZJ0a+Y0K2Gy3CSw+bVlTrrL8NVw+IqUcfltCE5To1mr4e VN4SWY4WP6EfFTxx+3z/AMIp4g8NfBS30n4e22peH/G3g3QPEuufAj4s/GD4keDfGuqW/wAZNe8M /Fix1nxl8WJ/D/iXQvD9v4C8O6BH4I8V+E9S0++8SfEfwfqA8SQ+H7Ox+H/iXI8YfF//AIKDfCX4 ZzS/D3wD4Z+KN54T8A+KfDi2vj74RftA6t4r8RfEuDRPjDr2j/GDW/EPhPxp4v8AEGofD6yuPh5o CeJPhB4I+GWveNfE9z8RNA0D4WeJNMv5/B/gzXPgf4V6h+wv8afHPxn+HXgP/gjH/wAE2l8TeDNI /Z51L4UweIm/ZZin8cT/ABz0/SJ72z+L/hLwb+zp45+Kf7NaeF9Q13Trfwzf+Lvh14ns/i7oguvG nw/e98JJZatqHA/HTQPg43wW07Vv2fP+CO3/AATK0r42ateQ+KbTRNX/AGOfEf7XmgJ8J73wN8Hf iL4fvpPAH7NP7LnhX4v3XjPXtB+MujaHr/8AZej33w9+GPjq20nSNe8b634U8XQ+O9B8rLPDTCTz nKOFMz4Ry2nzZhlWPxtPM+E/CjE1qq4hyXB5zhsXnuPybxnzLifE4d5RmMITf+2V8lzWrj8sVDB8 TU80wcexY50cROVSvVlPLo1KuIw8HmMOSFGvQpSoVYLJ3SpOviMqp4XDxrwUKtWdaFNOGZ4v6z+g njr9qD/gptpP7JR+L3hbwF8CLj4zWvgD4TPP4Zl/ZI/4KA+JPBWoePPFfjLV7fxn4gtfAumaZof7 XNl4S0vwlo1vp1v8P/8Ahm/VvG/hTxh4t0TXPG/iGz+HGk634kX3v4+ftR/tFeGb3wMPhn4E1/QL fUvhpruueI7PVv2Lf2p/2ip7/wCIcXhmy1m78M2mr/CnX/h1p3w/0/4YWGpWviy5fxTb69N+0Tdw 6l8Evg9daL8VtLvxb/A0/wAFP2QPCPgi28Uar/wSd/YT8X+KR4Q8P+OPF/h3xR+zX8JvgBYab4E0 fwf8RPGvi3xj4Q+Hvif9mHxf8UvCHi/xH4K8B/8ACW6R8DvjNro17QvEGu2Xw78X+OfBF9oet6tc cX4Y+DX7Pnhbw18RvEvxO/4JSf8ABL/xp4i07xx4412z8I+CvhF8JvCXhHwh+z/4Gf4r6vNcaXrW tfssa94k8ZfGOHwR8Mby81LS9bbw54J8Y+L7uysdJ1f4XaH9pnPk/wCovh/i5rHx4XhTp5bxBntT A4fDcO+F+Br5rheIcFlOCwuVPC5t4i1KNbAcO1cFjcZLNM+wOCpQhmmJ/sGtleZU8Lj454bMMRDD 4GcsTUnOWXYbD4lyqYqrUqVKbrYuWPlCOBr0aeLnRwMMtq0MK69SUcVGboVMXj6GOo/d8/x0/wCC iuteENA8UeDNC+Fwtz4d1mW8Hiv9iz9pbQNd8ZXul6L8YPHOheLdN+HmvftFeGvGfwosvHXh/wCF /hjwLH8KfHlvrvjjwH47+M/hS617X9X1DQl+HXi/9K/hpqt9q/hq6ub+SaaS28X+P9Jt5biWaac2 OieOfEOkWEUs07PNLJZ2llFYvJKxkkNsXfDMRX8+XwR079iD426n8V7Cx/4Ivf8ABObwuPhp8dPG vw1SC7H7Ifj7xPfeAvAvhnxb4p1nxR4v+H/wW+B/xP8AHnwi+MC2PhOaAfs7/E7w74e8RLe6lZWx 8WNLDqK2X2X8K/8AgqJpfiv9iPw3+0lf+AP2bvg/401fxtrnhO98AeKv21fhXqX7Ofgu00/xx/YN 34/8Uftc/CTwZ8RfBsHw+mXU9Bs7/wAU6B8O9et9O+LPi/QvhVq6Wus30usxfmfiv4PcSZjiMswn CPBuDw8sBn2CyLHYbDLwqynGPM+OqNfM+GKNSpwl4hcSzzmjLDZDnNLGZhUo5fkvCtelSwGMll2J zbD4NengcXTotRxeJmqssRmOFVRvMZ4edTIY16WOwkHi8PGlS+qyUqlKt7WtjM3hLC1ni8wU8NVr fsFRX5E6d/wUy8ceJNB+JGs+Bfg38B/iDJ8Ota1ufVbLwf8Ataavq50Pwf4Q8P8AxD8WeNdC+I0t v+zW0vw5/aQ8N+G/h7Nqdz8ANStdRs4U8UeEv7Y+KeiW+rNdW/3N+z/8WvHHxPi1n/hYHhXw94K8 T6PFqGneIPC3hLxle/EPwxofifwv8T/ip8Mtfg8P+ONV8A/DHWvEmhajN8PbbWNLv9Z8C+G9QC31 zby6XbrAm78F4t8LOOeBcHHHcU5ThMroyx1HLVTXEHDmPxyxeIwM8ypRnluW5vjMxp0JYSnKbxk8 LHBwq8uGqV44qcKMvTo5hhMRKcaNSc/ZycJyVCuqcKirLD+ylVlSVKNWVSXuUnNVJ01KtCMqMJ1I /SFFFFfnp2hRRRQAUUUUAFFFFABRRRQAUUUUAYes+HNJ1+fQ7nVYbqd/DmsRa9paQ6nqljbLqkFr d2lvPf2dhe21prMNvHeTTW9lrMF/YwX6Wupw2yajY2N1b7lFFC0TS0Tm6jS0TnKMISm1s5uFKnBy 3cacIt2hFIerTerUFTTerUIynOME91BTq1JqOylUnJK85N5up6Pp2sLZLqNv9pXTtTstYsx508Pk 6jp0vnWdxmCWIyeTJ83kyl4JOksTrxWlRRQtE4rSLnKq4rROpKFOnKo0tHOVOjSpym/ecKVOLfLC KQ9WpPWSgqab1ahGU5xgnuoRnVqTUdlKpOSV5ybKKKKAPkTxn+xD8EvHXinW/F+p+Jv2qdA1HxBe vqN9pXw1/bw/bk+EHgm3u5UQXEmh/Dj4UftE+C/h74YS7lVr2+g8N+GNJt77U7i91W8in1O/vbu4 5j/h3r8Bf+h+/bi/8Wdf8FJ//osq+4qK+4wnib4k5fhcLgMB4g8cYLA4LD0cJg8HhOLM+w2FwmEw 1OFHD4bC4ejj4UcPh8PRp06VGjShCnSpwhCnGMYpLmlg8HOUpzwuGnOcnKU5UKUpSlJ3lKUnBtyb 1bbbb1bufB0H/BOH9nK21C+1a28W/tp2+qapFZQanqUH/BS7/go/FqGowaaLgadDfXkf7Vy3F3FY C7uxZR3EkiWourgQCMTSbr//AA71+Av/AEP37cX/AIs6/wCCk/8A9FlX3FRXVLxb8VptSn4m+IU2 owgnLjTiSTUKcI06cU3mTajThCEIR2jCMYxSUUlKwGBW2Cwi1b0w1Fat3b+DdvV+ep8HQf8ABOH9 nK21C+1a28W/tp2+qapFZQanqUH/AAUu/wCCj8WoajBpouBp0N9eR/tXLcXcVgLu7FlHcSSJai6u BAIxNJuv/wDDvX4C/wDQ/ftxf+LOv+Ck/wD9FlX3FRRLxb8VptSn4m+IU2owgnLjTiSTUKcI06cU 3mTajThCEIR2jCMYxSUUkLAYFbYLCLVvTDUVq3dv4N29X56nw7/w71+Av/Q/ftxf+LOv+Ck//wBF lXk/xa/4I9/sJfHzTNE0X46+Fv2ivjTo3hrWU8R+HNJ+LX7en7fHxH0zQPEMVvNaR67olh4x/aZ1 m10rWY7W4ntk1Sxigvkt55oVnEcjq36dUV1Zf40+MeU4yhmOVeLPiZlmYYWUp4bHZfx5xTgsZh5y hKnKVDFYbNaVejKVOUqcpU5xbhKUW+VtOZ5bl1SE6dTAYKdOpGUJwnhaEoThNcsoTjKm4yjKPuyi 001o00fDi/8ABPP4Bqqqvj39uFVUBVVf+CnP/BScKqgYCqB+1iAAAAAAMAcCl/4d6/AX/ofv24v/ ABZ1/wAFJ/8A6LKvuKiuP/iLHin/ANHL8QP/ABMuI/8A55eS+4pYDApJLBYRJJJJYaikkrWSXJol ZW7WXY+Hf+HevwF/6H79uL/xZ1/wUn/+iyo/4d6/AX/ofv24v/FnX/BSf/6LKvuKij/iLHin/wBH L8QP/Ey4i/8Anl5L7g+oYH/oDwn/AIT0f/kPJfcfDv8Aw71+Av8A0P37cX/izr/gpP8A/RZV9L/C /wCEvg/4Q6Bb+HfCU/jjUre3tRYnWviV8VPij8aPG97Zx6xruu21trHxF+MfjHx54/1yCw1DxLrI 0uPWfEt+ulafcw6PpotdHsNOsbT0uivHzvjfjTiXC08DxHxfxRn+Bo4iGLpYPO8/zbNcLSxVOlVo wxNPD47F16MMRCjXr0oVowVSNKtVpqSjUmnpTw2GoycqOHoUpNcrlTpU6cnFtNxbjFOzcYu17XS7 IKKKK+XNwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKgubiO0tri6mEzRW0EtxKLe3uLucxwxtI4gtLSKe6upiqkR29tDNcT PtjhikkZUM9Q3Ntb3lvPaXcEN1aXUMttc21zEk9vc286NFNBPDKrRzQzRs0csUiskiMyOpUkGZ8/ JP2fKqnLL2bmm4Kdny86i1Jx5rcyTTavZplR5eaPPzcnMubltzct/e5b6c1r2vpffQZZXlvqNnaa haO0tpfWtveWsjRSwtJb3USTwO0M6RTxM8bqximjjljJKyIjgqLNVbGxsdLsbPTNMs7XTtN061t7 HT9PsbeG0sbGxtIUt7Szs7S3SOC1tbWCOOC3t4I0hhhRI40VFVRarSfJzz9nzKnzS9mptOahd8vO 4pRcuW3M0km72SRnHm5Y8/Lz8q5uW/LzW97lvry3va+tt9T/2QAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwMEFAAGAAgA AAAhAFibkMKqAAAAHwEAABEAAABwcHQvcHJlc1Byb3BzLnhtbIyPOw7CMAxAdyTuEGWnKQwIVf0s iJkBDhClbhspcSI7/G5PxEeCraNlvefnurt7J65AbAM2cl2UUgCa0FscG3k+HVY7KThp7LULCI18 AMuuXS7qWEUCBkw6ZfRIIouQK93IKaVYKcVmAq+5CBEw74ZAXqc80qh60rd8wDu1Kcut8tqi/PA0 hw/DYA3sg7n4HPCWELhXCU828tcW59h+//hLUu0TAAD//wMAUEsDBBQABgAIAAAAIQDjem7GnQEA AOQDAAARAAAAcHB0L3ZpZXdQcm9wcy54bWyUk01PwzAMhu9I/Icod9ZsEmVU6yYkxGkHJAb3KPG6 oDaJ4uyLX4/bbrT7OIxTY9d+/bxOO5ntqpJtIKBxNufDgeAMrHLa2CLnn4u3hzFnGKXVsnQWcr4H 5LPp/d3EZxsD2/fASMBiJnO+itFnSYJqBZXEgfNg6d3ShUpGCkOR6CC3JFyVyUiINKmksfzQH27p d8ulUfDq1LoCG1uRAKWMBI8r4/Go5m9R8wGQZJruE6QpmbM1dvnVWKxjqo0ugJ7DMjL8oVUNH8WI M7mO7kV/rzHmXPCkX7pwvql8ToWgLV5UJpdTsDQauqHqo9S9qDuikiVMJzLDHaNrG9OtaUISDQFl 95dZmnbo8pkLpjCW7aiFLOxzntKT2KlGdUOKNcHMMdaemjOjPloY7daFH868w5yPhunBdlvSJsdE 1Op1IrV4z0/Nc+rWugi4gF3sEHo0Z5Zrr1c8n6XrIe2q+qapkzwfCf9mUPEVBHQhQrgFKU2vEZ1m /wt0Pr0IRn94qegvYoru72ksRrRscqTI0l/U7n7Tfr2/AAAA//8DAFBLAwQUAAYACAAAACEAP4W4 cUMCAAAoCwAAEwAAAHBwdC90YWJsZVN0eWxlcy54bWzkVlFv2jAQfp+0/2D5PQ0JoWWIUAEt2qRt Dx3ruxM7YNWxUeIVqmn/fZdLSFLUVmUjWqU94Yjzfd/dfXfn8eUuVeReZLk0OqTeWY8SoWPDpV6F 9Pty4QwpyS3TnCmjRUgfRE4vJ+/fjdnIRuqbfVDic24JeNH5iIV0be1m5Lp5vBYpy8/MRmj4LzFZ yix8ZiuXZ2wL3lPl+r3euZsyqSnhIgnpz8Hc9wdBMHUurq/PnaAf+M6sFwyd4WB2Nf+wuPLm/ekv OmlhAzdg8Im/+nJ54StLIZYvgssfKcEgiE8cMo1joS3xEGK7NkosI4Vw8XKHZsVHYrS9EQmRfBfS VGqTof0my+1cZeSeqZBGisV31J2M3dq+uIppEbUVv/MqG9sGsHGNZeMZz4qbSiQWfzXZQp38ix5U Kk43EHmuV0ggN0ryhVTI+ABJ2T1Sywq4KY0U994zuVp3CFO7t2bTXTCV88hYa9LuYBr/UueSi4/d QbUAyuNt11gAAOqo1ZfsVfWCxBg2T9k7VkIbYSNAj4NSy0aoNYnOHwuxREDMSvxwbrdgBDPIwxwf tgc4hyb7Y4bB3zBsWBUn/zl+B3E1tngfq/nmokJWyPQ5fk9FhbaKwSg0jycniUJqNA6q0w3QZqy9 OECPVkil10btEOqTCm1FmshiAfwXUbdDLTJwY7ZFD9Y1+Je1RiLt9dIfeifdlbheUPrVaj5m9Bwl rCqtmO23luJm+yl8kZw6y3v/nSe6yW4BVT1py+3XvG8nvwEAAP//AwBQSwMEFAAGAAgAAAAhANSh Wq1qAQAAnAIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAISSy07DMBRE90j8Q+R94jwoFCtxJUBdUUAQBGJn7NvWIrEj2339PU7ShlYgscyd 8fHMdfLJtq6CNRgrtSpQEsUoAMW1kGpRoNdyGo5RYB1TglVaQYF2YNGEnp/lvCFcG3gyugHjJNjA k5QlvCnQ0rmGYGz5EmpmI+9QXpxrUzPnP80CN4x/sQXgNI4vcQ2OCeYYboFhMxDRHin4gGxWpuoA gmOooAblLE6iBP94HZja/nmgU46ctXS7xnfaxz1mC96Lg3tr5WDcbDbRJuti+PwJfp/dv3RVQ6na XXFANBecOOkqoI/lQ/CsV85vNMfDtNW5Aea0ofaTGb9fJjv9MG03XDHrZv4x5hLEzY4aw3SOf89b q4G1bB+RZmnceYaBv6pr3t8HIvBdSN/8oLxlt3flFNE0TuIwvgqT6zJNyeiKJNlHG+rkfNutH9T7 aP8RPTQdlWlG4guSjo+IBwDtEp/+T/QbAAD//wMAUEsDBBQABgAIAAAAIQAtMZFFfQIAAGgFAAAQ AAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxU S3PTMBC+M8N/0PgUDo6TNBTIKO5ASumBNhnilrMqrW1NbUmjVdOWX8/ablKHBhjwaR+fd1ffPvjJ Q12xDXjU1syj8XAUMTDSKm2KeXSVncXvI4ZBGCUqa2AePQJGJ+nrV3zlrQMfNCCjEAbnURmCmyUJ yhJqgUNyG/Lk1tcikOqLxOa5lnBq5V0NJiST0eg4gYcARoGK3S5g1EWcbcL/BlVWNvXhdfboqOCU ZzaIKtM1pEfT6YQnzzr/br3CdPKWrJ3IPzpXaSkCUZJeaOkt2jywZVs8W9l78CurTeBJH0iEANKr 2t/O2kenSxOj9ACGrUt7zwbT2dEbnhwA8pXwovDClZgejwnyrPJ1pRVgOuXJk8QvbSDDiCedwM+1 UmCevGTe0/nFxaLSrsVvRb6WooIFMZTmokKg0DsDPwfRdH8ltMeUb8JsAzJYz1D/oP5PI3YjEBpe 59FGeC1MIH4bWKe0cuUw+DSjQaDY5Ov0VuzD+rKeptQBwpLwR2AXq30ty3SoAP8hBbF4KEVj7J5J ufcJ6FIsc2pJOMDHcZ+PtrSOja7Kp5l5QcSOksUdBluzU0BdmP47dohv9i5QO9jnZk+aLUVGK8W+ DN+NPrBldskGrFk8pM1TgqbPC3kLfqgh5O3O0Sokyos8xAJLextLKWoXF7WrMLbo8rigQAmjudyl bLrZ1f+Jgt0L2g+2sLWj0b7RlQ6PbDD+G1728YPJYfjSNTuGLFgmlKL9QfabjP3q9pr1S3u+anOL Vy6zpyLAdrj3jXxdCg+KrtDW/2zg5zTXvmqCLEphClBbzEtHcyauu8OZjifDEX3tRdjamkXfnsj0 JwAAAP//AwBQSwECLQAUAAYACAAAACEA/raEGWoCAADLFgAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBo+HShBQEAAOICAAALAAAAAAAAAAAAAAAA AKMEAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAQxrYJUgEAALUEAAAgAAAAAAAAAAAAAAAA ANkHAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3s vwAAADcBAAAgAAAAAAAAAAAAAAAAAGkJAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVs c1BLAQItABQABgAIAAAAIQAbpwBcwQAAADcBAAAgAAAAAAAAAAAAAAAAAGYKAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlMy54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAA AAAAAAAAAGULAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc1BLAQItABQABgAIAAAA IQA/6i7vZQEAAB8HAAAfAAAAAAAAAAAAAAAAAGIMAABwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnht bC5yZWxzUEsBAi0AFAAGAAgAAAAhAGW0Fz93AgAAbA0AABQAAAAAAAAAAAAAAAAADA8AAHBwdC9w cmVzZW50YXRpb24ueG1sUEsBAi0AFAAGAAgAAAAhAOKFL6/VBwAAiSIAABUAAAAAAAAAAAAAAAAA tREAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbFBLAQItABQABgAIAAAAIQCZvcknYwUAALcVAAAVAAAA AAAAAAAAAAAAAL0ZAABwcHQvc2xpZGVzL3NsaWRlNC54bWxQSwECLQAUAAYACAAAACEAx2NMETIE AAALDgAAFQAAAAAAAAAAAAAAAABTHwAAcHB0L3NsaWRlcy9zbGlkZTEueG1sUEsBAi0AFAAGAAgA AAAhANq8m2OFBgAAuh4AABUAAAAAAAAAAAAAAAAAuCMAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbFBL AQItABQABgAIAAAAIQD9eIypvgAAADcBAAAtAAAAAAAAAAAAAAAAAHAqAABwcHQvc2xpZGVMYXlv dXRzL19yZWxzL3NsaWRlTGF5b3V0MTgueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3 AQAALAAAAAAAAAAAAAAAAAB5KwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIu eG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAACBLAAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA 1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAACJLQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlk ZUxheW91dDQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAA AACRLgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHNQSwECLQAU AAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAACZLwAAcHB0L3NsaWRlTGF5b3V0cy9f cmVscy9zbGlkZUxheW91dDUueG1sLnJlbHNQSwECLQAUAAYACAAAACEA/XiMqb4AAAA3AQAALQAA AAAAAAAAAAAAAAChMAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDE5LnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAP14jKm+AAAANwEAAC0AAAAAAAAAAAAAAAAAqjEAAHBwdC9zbGlk ZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyMC54bWwucmVsc1BLAQItABQABgAIAAAAIQD9eIyp vgAAADcBAAAtAAAAAAAAAAAAAAAAALMyAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0MjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA/XiMqb4AAAA3AQAALQAAAAAAAAAAAAAAAAC8 MwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIyLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPU9RsprAQAAmQgAACwAAAAAAAAAAAAAAAAAxTQAAHBwdC9zbGlkZU1hc3RlcnMvX3Jl bHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAA AAAAAAAAAAAAejYAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAgjcAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAP14jKm+AAAA NwEAAC0AAAAAAAAAAAAAAAAAijgAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQx Ni54bWwucmVsc1BLAQItABQABgAIAAAAIQD9eIypvgAAADcBAAAtAAAAAAAAAAAAAAAAAJM5AABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTUueG1sLnJlbHNQSwECLQAUAAYACAAA ACEA/XiMqb4AAAA3AQAALQAAAAAAAAAAAAAAAACcOgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDE0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAP14jKm+AAAANwEAAC0AAAAAAAAA AAAAAAAApTsAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMy54bWwucmVsc1BL AQItABQABgAIAAAAIQD9eIypvgAAADcBAAAtAAAAAAAAAAAAAAAAAK48AABwcHQvc2xpZGVMYXlv dXRzL19yZWxzL3NsaWRlTGF5b3V0MTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEAwrM8OiEBAADQ BwAALAAAAAAAAAAAAAAAAAC3PQAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjIu eG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAAAiPwAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh ANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAAK0AAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAA AAAAADRBAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc1BLAQIt ABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAADxCAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc1BLAQItABQABgAIAAAAIQCsAGq6qgMAAPkLAAAi AAAAAAAAAAAAAAAAAERDAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MjIueG1sUEsBAi0A FAAGAAgAAAAhAM1HvDUnCAAAtDAAACEAAAAAAAAAAAAAAAAALkcAAHBwdC9zbGlkZU1hc3RlcnMv c2xpZGVNYXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQDEazP72gIAACsIAAAhAAAAAAAAAAAAAAAA AJRPAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWxQSwECLQAUAAYACAAAACEA3HkT wKUCAADZBgAAIQAAAAAAAAAAAAAAAACtUgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcu eG1sUEsBAi0AFAAGAAgAAAAhAFQzgr/yBAAANBIAACEAAAAAAAAAAAAAAAAAkVUAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQ4LnhtbFBLAQItABQABgAIAAAAIQBT1Tv2rgQAAK0RAAAhAAAA AAAAAAAAAAAAAMJaAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OS54bWxQSwECLQAUAAYA CAAAACEApWWJRXIFAACpGwAAIQAAAAAAAAAAAAAAAACvXwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDUueG1sUEsBAi0AFAAGAAgAAAAhAOv4TksWBAAA2hEAACEAAAAAAAAAAAAAAAAAYGUA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ0LnhtbFBLAQItABQABgAIAAAAIQDCDl3+iwQA AMsQAAAhAAAAAAAAAAAAAAAAALVpAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWxQ SwECLQAUAAYACAAAACEAh2c9bE4DAAAICwAAIQAAAAAAAAAAAAAAAAB/bgAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDIueG1sUEsBAi0AFAAGAAgAAAAhABGrqEo8BAAAdxAAACEAAAAAAAAA AAAAAAAADHIAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLAQItABQABgAIAAAA IQA672GvkQcAADAvAAAhAAAAAAAAAAAAAAAAAId2AABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFz dGVyMi54bWxQSwECLQAUAAYACAAAACEA/XiMqb4AAAA3AQAALQAAAAAAAAAAAAAAAABXfgAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDE3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh ADEe7YVnAwAAPwsAACIAAAAAAAAAAAAAAAAAYH8AAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQxMC54bWxQSwECLQAUAAYACAAAACEAVhUM/zEEAABREAAAIgAAAAAAAAAAAAAAAAAHgwAAcHB0 L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEyLnhtbFBLAQItABQABgAIAAAAIQDrDJeVXAMAABkL AAAiAAAAAAAAAAAAAAAAAHiHAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MjEueG1sUEsB Ai0AFAAGAAgAAAAhAMrO03GlBAAAfREAACIAAAAAAAAAAAAAAAAAFIsAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQyMC54bWxQSwECLQAUAAYACAAAACEAARgUnOgEAAAOEgAAIgAAAAAAAAAA AAAAAAD5jwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDE5LnhtbFBLAQItABQABgAIAAAA IQBDcKFRowIAALMGAAAiAAAAAAAAAAAAAAAAACGVAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5 b3V0MTgueG1sUEsBAi0AFAAGAAgAAAAhAJ7HanHQAgAABQgAACIAAAAAAAAAAAAAAAAABJgAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxNy54bWxQSwECLQAUAAYACAAAACEAV2qam2cFAACD GwAAIgAAAAAAAAAAAAAAAAAUmwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDE2LnhtbFBL AQItABQABgAIAAAAIQCXhEjXRQMAAOIKAAAiAAAAAAAAAAAAAAAAALugAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0MTMueG1sUEsBAi0AFAAGAAgAAAAhAMzmRjh9BAAApRAAACIAAAAAAAAA AAAAAAAAQKQAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxNC54bWxQSwECLQAUAAYACAAA ACEAXqxWRgwEAAC0EQAAIgAAAAAAAAAAAAAAAAD9qAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDE1LnhtbFBLAQItABQABgAIAAAAIQAH5mbDsQMAAB8MAAAiAAAAAAAAAAAAAAAAAEmtAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1sUEsBAi0AFAAGAAgAAAAhAJOqfZi7AAAA JAEAACwAAAAAAAAAAAAAAAAAOrEAAHBwdC9ub3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNNYXN0ZXIx LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAL1aO47dAAAAdAEAABYAAAAAAAAAAAAAAAAAP7IAAHBw dC9jb21tZW50QXV0aG9ycy54bWxQSwECLQAUAAYACAAAACEAmxtwqgoGAAByHQAAIQAAAAAAAAAA AAAAAABQswAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAh APnPCTmDBgAAXBsAABQAAAAAAAAAAAAAAAAAmbkAAHBwdC90aGVtZS90aGVtZTEueG1sUEsBAi0A FAAGAAgAAAAhANyxcIKIBgAAXRsAABQAAAAAAAAAAAAAAAAATsAAAHBwdC90aGVtZS90aGVtZTIu eG1sUEsBAi0AFAAGAAgAAAAhAPnPCTmDBgAAXBsAABQAAAAAAAAAAAAAAAAACMcAAHBwdC90aGVt ZS90aGVtZTMueG1sUEsBAi0ACgAAAAAAAAAhABYvR+IAgAAAAIAAABcAAAAAAAAAAAAAAAAAvc0A AGRvY1Byb3BzL3RodW1ibmFpbC5qcGVnUEsBAi0AFAAGAAgAAAAhAFibkMKqAAAAHwEAABEAAAAA AAAAAAAAAAAA8k0BAHBwdC9wcmVzUHJvcHMueG1sUEsBAi0AFAAGAAgAAAAhAON6bsadAQAA5AMA ABEAAAAAAAAAAAAAAAAAy04BAHBwdC92aWV3UHJvcHMueG1sUEsBAi0AFAAGAAgAAAAhAD+FuHFD AgAAKAsAABMAAAAAAAAAAAAAAAAAl1ABAHBwdC90YWJsZVN0eWxlcy54bWxQSwECLQAUAAYACAAA ACEA1KFarWoBAACcAgAAEQAAAAAAAAAAAAAAAAALUwEAZG9jUHJvcHMvY29yZS54bWxQSwECLQAU AAYACAAAACEALTGRRX0CAABoBQAAEAAAAAAAAAAAAAAAAACsVQEAZG9jUHJvcHMvYXBwLnhtbFBL BQYAAAAASABIAHMWAABfWQEAAAA= --_004_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1SVEXDB1infine_-- From zhangfatai@huawei.com Tue Oct 26 05:09:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621D33A682E for ; Tue, 26 Oct 2010 05:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.142 X-Spam-Level: * X-Spam-Status: No, score=1.142 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aA6ytCCnJnri for ; Tue, 26 Oct 2010 05:09:01 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6FD8D3A67D7 for ; Tue, 26 Oct 2010 05:08:57 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAW003ZHCHL7F@szxga05-in.huawei.com> for ccamp@ietf.org; Tue, 26 Oct 2010 20:10:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAW00KUTCHKMN@szxga05-in.huawei.com> for ccamp@ietf.org; Tue, 26 Oct 2010 20:10:33 +0800 (CST) Received: from Z41162C ([10.70.76.101]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAW0036ICHK2X@szxml06-in.huawei.com> for ccamp@ietf.org; Tue, 26 Oct 2010 20:10:32 +0800 (CST) Date: Tue, 26 Oct 2010 20:10:32 +0800 From: Fatai Zhang To: Rajan Rao , Daniele Ceccarelli Message-id: <01e401cb7506$c996ade0$654c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_bpDC8pqaPl649Cc7jzS5IA)" X-Priority: 3 X-MSMail-priority: Normal References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> Cc: "Ong, Lyndon" , ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2010 12:09:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bpDC8pqaPl649Cc7jzS5IA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgUmFqYW4sDQoNCllvdSBzYWlkIHRoZXJlIGFyZSB0aHJlZSBkaWZmZXJlbmNlcyBiZXR3ZWVu IHR3byBkcmFmdHMuIE5vdywgd2UgYXJlIGNvbWluZyBtdWNoIGNsb3NlciB0aGF0IHRoZXJlICJt YXkiIGJlIG9ubHkgb25lIGRpZmZlcmVuY2UgKGkuZS4sIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkp IGFmdGVyIERhbmllbGUgZ2F2ZSBzb21lIGNsYXJpZmljYXRpb25zLg0KDQpZb3VyIGRyYWZ0IGlu dHJvZHVjZXMgYSBuZXcgc3ViLVRMViBTQ1NJIGFuZCBbZHJhZnQtY2VjY2FyZWxsaV0gaW50cm9k dWNlcyBHZW5lcmFsaXplZC1JU0NEIHN1Yi1UTFYsIHNvIEkgdGhpbmsgdGhleSBoYXZlIHRoZSBz YW1lIGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGFsdGhvdWdoIGl0IHNlZW1zIGxpa2UgdGhhdCB5 b3VyIGRyYWZ0ICJjb3VsZCIgc3VwcG9ydCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LiANCg0KTW9y ZW92ZXIsIHRoZXJlIGFyZSBzb21lIGRpc2FkdmFudGFnZXMgdG8gdXNlIHRoZSBleGlzdGluZyBJ U0NEICtTQ1NJLiBGaXJzdGx5LCAgYXMgRGFuaWVsZSBhbHJlYWR5IHBvaW50ZWQgaXQgb3V0LCBp dCBpcyBhIGJpZyBpc3N1ZSB0byBhZHZlcnRpc2UgdGhhdCBNYXggTFNQIGJhbmR3aWR0aCBpcyAw IGluIHRoZSBjYXNlIG9mIG5vbi1PRFVmbGV4IHN1cHBvcnRlZCBmb3IgTm9kZSBCL0MsIGhvd2V2 ZXIsIGZvciBOb2RlIEEoRy43MDkgVjEpLCBpdCBtdXN0IGFsd2F5cyBhZHZlcnRpc2UgYSBtZWFu aW5nZnVsIHZhbHVlIGZvciB0aGUgTWF4IExTUCBiYW5kd2lkdGguIFNlY29uZGx5LCBZb3UgaGF2 ZSBjaGFuZ2VkIHRoZSBtZWFuaW5nIG9mICJNaW5pbXVtIExTUCBCYW5kd2lkdGgiLCB3aGljaCB3 aWxsIG1ha2UgdGhlIHBhdGggY29tcHV0YXRpb24gbWVzc2VkLiBBc3N1bWUgT1RVMiBpbnRlcmZh Y2UgdGhhdCBzdXBwb3J0cyBPRFUyIHN3aXRjaGluZyBvbmx5IChhbiBleGFtcGxlIGluIHlvdXIg ZHJhZnQpLCBpbiB0aGlzIGNhc2UsIGFjY29yZGluZyB0byB0aGUgcmVndWxhciByb3V0aW5nIHBy b2Nlc3MsIGl0IHdpbGwgbWFrZSB0aGUgcm91dGluZyBwYXRoIGNvbXB1dGF0aW9uIGZ1bmN0aW9u IHRvIHVuZGVyc3RhbmQgdGhhdCBpdCBjYW4gc3VwcG9ydCBPRFUwIExTUC4gVGhpcmRseSwgaXQg Y2FuIG5vdCBzdXBwb3J0IHByaW9yaXR5IGZsZXhpYmlsaXR5LCBzbyBpdCBpcyBub3QgZWZmaWNp ZW50IGZyb20gdGhlIHJvdXRpbmcgc2NhbGFiaWxpdHkgcGVyc3BlY3RpdmUuIEZvdXJ0aCwgaXQg Y2FuIG5vdCBkaWZmZXJlbnRpYXRlIHRlcm1pbmF0aW9uIGFuZCBzd2ljaGluZyBjYXBhYmlsaXR5 IGZvciB5b3VyIGRhcmZ0Lg0KDQpJIGFtIHRyeWluZyB0byByZWNhbGwgbW9yZSByZWFzb25zIHdo eSB3ZSBuZWVkIHRvIHVzZSBhIG5ldyBzdWItVExWIHJhdGhlciB0aGFuIHRoZSBleGlzdGluZyBU TFYsIGJlY2F1c2Ugd2UgaGFkIGxvdHMgb2YgZGlzY3Vzc2lvbiBiZWZvcmUgSUVURjc4dGggbWVl dGluZyB0aHJvdWdoIG1haWxpbmcgbGlzdCBhbmQgRjJGLCBidXQgaXQgaXMgYSBsaXR0bGUgZGlm ZmljdWx0IGZvciBtZSB0byBkaWcgbW9yZSB0aGluZ3MgZnJvbSBteSBtZW1vcnkgYXQgdGhpcyBt b21lbnQsIDotKX5+fn4NCg0KDQpCZXN0IFJlZ2FyZHMNCiANCkZhdGFpDQogDQogIC0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IFJhamFuIFJhbyANCiAgVG86IERhbmllbGUg Q2VjY2FyZWxsaSANCiAgQ2M6IE9uZywgTHluZG9uIDsgY2NhbXBAaWV0Zi5vcmcgDQogIFNlbnQ6 IFR1ZXNkYXksIE9jdG9iZXIgMjYsIDIwMTAgNzoxMyBBTQ0KICBTdWJqZWN0OiBSZTogW0NDQU1Q XSBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIEcuNzA5IE9UTiBkcmFmdCBzdWJtaXR0ZWQ6IGRyYWZ0 LWFzaG9rLWNjYW1wLWdtcGxzLW9zcGYtZzcwOS0wMQ0KDQoNCiAgRGFuaWVsZSwNCg0KICAgDQoN CiAgUGxlYXNlIHNlZSByZXNwb25zZSBpbmxpbmUsIHdpdGhpbiB7IH0uIA0KDQogICANCg0KICBU aGFua3MNCg0KICBSYWphbg0KDQogICANCg0KICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K DQogIEZyb206IERhbmllbGUgQ2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBl cmljc3Nvbi5jb21dIA0KDQogIFNlbnQ6IEZyaWRheSwgT2N0b2JlciAyMiwgMjAxMCA2OjQ5IEFN DQoNCiAgVG86IFJhamFuIFJhbw0KDQogIENjOiBPbmcsIEx5bmRvbjsgY2NhbXBAaWV0Zi5vcmcN Cg0KICBTdWJqZWN0OiBSRTogW0NDQU1QXSBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIEcuNzA5IE9U TiBkcmFmdCBzdWJtaXR0ZWQ6IGRyYWZ0LWFzaG9rLWNjYW1wLWdtcGxzLW9zcGYtZzcwOS0wMQ0K DQogICANCg0KICBIaSBSYWphbiwNCg0KICAgDQoNCiAgSnVzdCBhIGNvdXBsZSBvZiBjb21tZW50 cyBvbiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGFuZCBiYW5kd2lkdGggYWR2ZXJ0aXNlbWVudC4N Cg0KICAgDQoNCiAgLSBCYWNrd2FyZCBjb21wYXRpYmlsaXR5OiBubyBPRFUgYWR2ZXJ0aXNpbmcg aXMgZGVmaW5kZWQgaW4gUkZDIDQyMDIvNDIwMywgc28gaSBiZWxpZXZlIHRoZXJlIGFyZSBubyBi YWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzc3Vlcy4NCg0KICAgDQoNCiAgIA0KDQogIFtSYWphbl0g IHsgDQoNCiAgQWdyZWUgdGhlcmUgaXMgbm8gT0RVIGFkdmVydGlzZW1lbnQgZGVmaW5lZC4gVGhl IG5lZWQgdG8gYWRkcmVzcyBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBkZXBlbmRzIG9uIHRoZSBm b2xsb3dpbmc6IA0KDQogICANCg0KICAgMSkgYXJlIHRoZXJlIFJGQy00MzI4IGJhc2VkIGRlcGxv eW1lbnRzPw0KDQogICAyKSBJZiBzbywgd2hhdCBkbyB0aGV5IHVzZSBmb3IgQlcgYWR2ZXJ0aXNl bWVudD8NCg0KICAgDQoNCiAgT3VyIGZhaXIgZ3Vlc3MgaXMgdGhhdCBJU0NEIGlzIHVzZWQgZm9y IHRoaXMgYXMgcGVyIFJGQyA0MjAyLzQyMDMuIA0KDQogICANCg0KICBUaGVyZSBhcmUgMiB3YXlz IHRvIGFkZHJlc3MgdGhlIGNvbXBhdGliaWxpdHkgaXNzdWUgLSBlaXRoZXIgc3VwcG9ydCBvciBk b24ndCBzdXBwb3J0LiBCYXNlZCBvbiB0aGUgV0cgYWdyZWVtZW50IHdlIGNvdWxkIGdvIGVpdGhl ciB3YXkgd2l0aG91dCBicmVha2luZyB0aGUgbW9kZWwgd2UgaGF2ZSBwcm9wb3NlZC4gUGxlYXNl IHJlZmVyIHRvIGF0dGFjaGVkIHNsaWRlcyBmb3IgZGV0YWlscy4NCg0KICAgDQoNCiAgfQ0KDQog ICANCg0KICBNb3Jlb3ZlciBpbiBkcmFmdC1hc2hvay1jY2FtcC1nbXBscy1vc3BmLWc3MDkgdGhl IE1BWCBMU1AgYmFuZHdpZHRoIGZpZWxkcyBvZiB0aGUgSVNDRCBhcmUgdXNlZCBmb3IgdW5yZXNl cnZlZCBiYW5kd2lkdGggYWR2ZXJ0aXNlbWVudCwgdGhpcyBpcyBhIGJhY2t3YXJkIGNvbXBhdGli aWxpdHkgaXNzdWUgaW4gbXkgb3Bpbmlvbi4gSXQgc3RhdGVzIHRoYXQ6DQoNCiAgIA0KDQogICAg ICAgICJFbmNvZGluZyBvZiBNYXggTFNQIEJhbmR3aWR0aCBpcyBhcyBmb2xsb3dzOg0KDQogICAg ICAgICBNYXggTFNQIEJhbmR3aWR0aCA9IFVucmVzZXJ2ZWQtVFMtQ291bnQgeCBUUy1Ob21pbmFs LVJhdGUiDQoNCiAgIA0KDQogIFtSYWphbl0gIHsgDQoNCiAgIA0KDQogIFRoZSB1bml0IGhlcmUg aXMgaW4gQnl0ZXMvc2VjLiBUaGUgZGVzY3JpcHRpb24gYWJvdmUgKCYgaW4gb3VyIGRyYWZ0KSAN Cg0KICAtICAgIHNob3dzIHRoYXQgbm9taW5hbCByYXRlIGlzIGRlcGVuZGVudCBvbiBzcGVjaWZp YyBPRFUgbGF5ZXIgaW4gcXVlc3Rpb24uIA0KDQogIC0gICAgc2hvd3MgaG93IE1heCBMU1AgYmFu ZHdpZHRoIG51bWJlciBpcyBkZXJpdmVkIGF0IHRoZSBhZHZlcnRpc2luZyBub2RlLg0KDQogIH0N Cg0KICAgDQoNCiAgTW9yZW92ZXIgaXQgc3RhdGVzOg0KDQogICANCg0KICAgICAgICAiSWYgdGhl IGludGVyZmFjZSBkb2VzIG5vdCBzdXBwb3J0IE9EVS1mbGV4IHNlcnZpY2UsIA0KDQogICAgICAg IHRoaXMgdmFsdWUgc2hvdWxkIGJlIGNvZGVkIGFzIHplcm8iLg0KDQogICANCg0KICBCdXQgYWR2 ZXJ0aXNpbmcgbWF4IExTUCBiYW5kd2lkdGggPSAwIG1lYW5zIGRpc2NhcmRpbmcgc3VjaCBsaW5r IGluIHRoZSBwYXRoIGNvbXB1dGF0aW9uIHByb2Nlc3MuDQoNCiAgIA0KDQogIFtSYWphbl0gew0K DQogIEdvb2QgcXVlc3Rpb24gJiB2ZXJ5IHZhbGlkLiBJIHRoaW5rIHlvdSBhcmUgYnJpbmdpbmcg dXAgYSBzY2VuYXJpbyB3aGVyZSBPRFVmbGV4IGlzIG5vdCBzdXBwb3J0ZWQgYnV0IGJhY2t3YXJk IGNvbXBhdGliaWxpdHkgaXMgcmVxdWlyZWQuDQoNCiAgIA0KDQogIFdoYXQgd2UgbmVlZCBoZXJl IGlzIHRvIHNlcGFyYXRlIE9EVWZsZXggYWR2ZXJ0aXNlbWVudCBmcm9tIElTQ0Q6Ok1heC1MU1At QlcuIFRoaXMgY2FuIGJlIGVhc2lseSBhY2NvbXBsaXNoZWQgd2l0aCBhIHN1Yi1UTFYgZm9yIE9E VWZsZXggc2lnbmFsIHR5cGUgaW4gb3VyIG1vZGVsLiBCVyBpbiBieXRlcy9zZWMsIG9mIGNvdXJz ZS4gIFBsZWFzZSByZWZlciB0byBhdHRhY2hlZCBzbGlkZXMgZm9yIGRldGFpbHMuDQoNCiAgICAN Cg0KICB9DQoNCiAgIA0KDQogIC0gQmFuZHdpZHRoIGFkdmVydGlzZW1lbnQ6IGluIHRoZSAtMDQg dmVyc2lvbiBvZiBvdXIgZHJhZnQgdGhlIGJhbmR3aWR0aCBpcyBhZHZlcnRpc2VkIGFzIGZvbGxv d3M6DQoNCiAgIA0KDQogICAgICAtIFVucmVzZXJ2ZWQgYmFuZHdpZHRoIGZvciBmaXhlZCBjb250 YWluZXIgaW4gbnVtYmVyIG9mIGNvbnRhaW5lcnMNCg0KICAgICAgLSBVbnJlc2VydmVkIGJhbmR3 aWR0aCBmb3Igb2R1ZmxleCBpbiBCeXRlcy9zZWMNCg0KICAgICAgLSBNYXggTFNQIGJhbmR3aWR0 aCBpbiBCeXRlcy9zZWMuDQoNCiAgIA0KDQogIFtSYWphbl0gew0KDQogIFdlIGJlbGlldmUgYWR2 ZXJ0aXNpbmcgdGhlIG51bWJlciBvZiBjb250YWluZXJzIGlzIHRoZSByaWdodCBhcHByb2FjaC4g VGhpcyBpcyBleGFjdGx5IHRoZSBwcm9wb3NhbCB3ZSBoYXZlIGluIG91ciBkcmFmdC4gR29vZCB0 byBzZWUgdGhhdCB5b3UgaGF2ZSBtb3ZlZCBhd2F5IGZyb20gVFMgYXBwcm9hY2ggd2hpY2ggaGFk IHNlcmlvdXMgbGltaXRhdGlvbnMuDQoNCiAgIA0KDQogIH0NCg0KICAgDQoNCiAgQWR2ZXJ0aXNp bmcgdGhlIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGluIG51bWJlciBvZiBjb250YWluZXJzIGlzIHRo ZSBtb3N0IHN1aXRhYmxlIHdheSBmb3IgZml4ZWQgY29udGFpbmVycyAoT0RVaykgYnV0IGRvZXNu J3Qgd29yayB3aXRoIE9EVWZsZXguDQoNCiAgIA0KDQogIFtSYWphbl0gew0KDQogICANCg0KICAg VGhlIE9EVWZsZXggdXNlcyBieXRlcy9zZWMgaW4gb3VyIGRyYWZ0LiAgVGhlcmUgaXMgbm8gZGlz YWdyZWVtZW50IGhlcmUuDQoNCiAgIA0KDQogIH0gDQoNCiAgQlINCg0KICAgDQoNCiAgVGhlIGF1 dGhvcnMNCg0KICAgDQoNCiAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KICBGcm9tOiBj Y2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFJhamFuIFJhbw0KDQogIFNlbnQ6IHZlbmVyZOwgMTUgb3R0b2JyZSAyMDEwIDE5 LjEzDQoNCiAgVG86IE9uZywgTHluZG9uOyBjY2FtcEBpZXRmLm9yZw0KDQogIFN1YmplY3Q6IFJl OiBbQ0NBTVBdIE9TUEYtVEUgZXh0ZW5zaW9ucyBmb3IgRy43MDkgT1ROIGRyYWZ0IHN1Ym1pdHRl ZDogZHJhZnQtYXNob2stY2NhbXAtZ21wbHMtb3NwZi1nNzA5LTAxDQoNCiAgIA0KDQogIEx5bmRv biwNCg0KICAgDQoNCiAgWWVzLCB3ZSBhcmUgYXdhcmUgb2YgdGhlIGV4aXN0aW5nIGRyYWZ0LiBU aGVyZSBhcmUgc29tZSBmdW5kYW1lbnRhbCBkaWZmZXJlbmNlcyBpbiB0aGUgbW9kZWwgd2UgaGF2 ZSBwcm9wb3NlZCBmcm9tIHRoZSBleGlzdGluZyBkcmFmdC4gVGhlIGtleSBkaWZmZXJlbmNlcyBh cmUgdGhlIGZvbGxvd2luZzoNCg0KICAgDQoNCiAgMSkgVGhpcyBkcmFmdCBleHRlbmRzIGV4aXN0 aW5nIElTQ0QgIFZzLiBkZWZpbmluZyBhIG5ldyBvbmUgDQoNCiAgICAgIC0gYWRkcmVzc2VzIGJh Y2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzIChSRkMgNDIwMikNCg0KICAgDQoNCiAgMikgT0RV IGNvbnRhaW5lcnMgYXJlIGFkdmVydGlzZWQgaW5zdGVhZCBvZiAjVFNzDQoNCiAgICAgICAtIHNp bXBsZSBwYXRoIGNvbXB1dGF0aW9uDQoNCiAgIA0KDQogIDMpIFBhdGggY29tcHV0aW5nIG5vZGUg ZG9lc24ndCBuZWVkIHRvIGtub3cgcGVyIGxpbmsgYW5kL29yIHBlciBPRFUgbGF5ZXIgVFMgZ3Jh bnVsYXJpdHkNCg0KICAgICAgIC0gYWdhaW4sIHNpbXBsZSAmIHN0cmFpZ2h0IGZvcndhcmQgcGF0 aCBjb21wdXRhdGlvbiAgDQoNCiAgIA0KDQogIFRoYW5rcw0KDQogIFJhamFuDQoNCiAgIA0KDQog IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCiAgRnJvbTogT25nLCBMeW5kb24gW21haWx0 bzpMeW9uZ0BDaWVuYS5jb21dDQoNCiAgU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTQsIDIwMTAg Nzo0NSBBTQ0KDQogIFRvOiBSYWphbiBSYW87IGNjYW1wQGlldGYub3JnDQoNCiAgU3ViamVjdDog UkU6IFtDQ0FNUF0gT1NQRi1URSBleHRlbnNpb25zIGZvciBHLjcwOSBPVE4gZHJhZnQgc3VibWl0 dGVkOiBkcmFmdC1hc2hvay1jY2FtcC1nbXBscy1vc3BmLWc3MDktMDENCg0KICAgDQoNCiAgSGkg UmFqYW4sDQoNCiAgIA0KDQogIEhhdmUgeW91IGxvb2tlZCBhdCBkcmFmdC1jZWNjYXJlbGxpLWNj YW1wLWdtcGxzLW9zcGYtZzcwOS0wMy50eHQ/ICBJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIHVuZGVy c3RhbmQgaWYgeW91ciBkcmFmdCBpcyBhc2tpbmcgZm9yIHNpbWlsYXIgZXh0ZW5zaW9ucyBvciBk aWZmZXJlbnQgZnVuY3Rpb25hbGl0eS4NCg0KICAgDQoNCiAgVGhhbmtzLA0KDQogICANCg0KICBM eW5kb24NCg0KICAgDQoNCiAgIA0KDQogICANCg0KICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KDQogIEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFqYW4gUmFvDQoNCiAgU2VudDogV2VkbmVzZGF5LCBP Y3RvYmVyIDEzLCAyMDEwIDI6NDAgUE0NCg0KICBUbzogY2NhbXBAaWV0Zi5vcmcNCg0KICBTdWJq ZWN0OiBbQ0NBTVBdIE9TUEYtVEUgZXh0ZW5zaW9ucyBmb3IgRy43MDkgT1ROIGRyYWZ0IHN1Ym1p dHRlZDoNCg0KICBkcmFmdC1hc2hvay1jY2FtcC1nbXBscy1vc3BmLWc3MDktMDENCg0KICAgDQoN CiAgSGksDQoNCiAgIA0KDQogIFRoZSBmb2xsb3dpbmcgZHJhZnQgaGFzIGJlZW4gc3VibWl0dGVk LiBQbGVhc2UgcmV2aWV3LiBDb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQoNCiAgIA0KDQogIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFzaG9rLWNjYW1wLWdtcGxzLW9z cGYtZzcwOS8NCg0KICAgDQoNCiAgdGhhbmtzDQoNCiAgQXV0aG9ycw0KDQogICANCg0KICAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQogIEZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9v bCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10NCg0KICBTZW50OiBXZWRuZXNkYXksIE9j dG9iZXIgMTMsIDIwMTAgMjozMCBQTQ0KDQogIFRvOiBSYWphbiBSYW8NCg0KICBDYzogU25pZ2Ro byBCYXJkYWxhaTsgQXNob2sgS3VuamlkaGFwYXRoYW07IEtodXplbWEgUGl0aGV3YW4NCg0KICBT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQoNCiAgZHJhZnQtYXNob2stY2Nh bXAtZ21wbHMtb3NwZi1nNzA5LTAxIA0KDQogICANCg0KICAgDQoNCiAgQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWFzaG9rLWNjYW1wLWdtcGxzLW9zcGYtZzcwOS0wMS50eHQgaGFzIGJlZW4N Cg0KICBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJhamFuIFJhbyBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCiAgIA0KDQogIEZpbGVuYW1lOiAgIGRyYWZ0LWFzaG9rLWNj YW1wLWdtcGxzLW9zcGYtZzcwOQ0KDQogIFJldmlzaW9uOiAgIDAxDQoNCiAgVGl0bGU6ICAgICAg ICAgICAgT1NQRiBURSBFeHRlbnNpb25zIGZvciBHZW5lcmFsaXplZCBNUExTIChHTVBMUykgQ29u dHJvbA0KDQogIG9mIEcuNzA5IE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmtzDQoNCiAgQ3JlYXRp b25fZGF0ZTogICAgMjAxMC0xMC0xMg0KDQogIFdHIElEOiAgICAgICAgICAgIEluZGVwZW5kZW50 IFN1Ym1pc3Npb24NCg0KICBOdW1iZXJfb2ZfcGFnZXM6IDIwDQoNCiAgIA0KDQogIEFic3RyYWN0 Og0KDQogIEFzIE9UTiBuZXR3b3JrIGNhcGFiaWxpdGllcyBjb250aW51ZSB0byBldm9sdmUsIHRo ZXJlIGlzIGFuIGluY3JlYXNlZA0KDQogIG5lZWQgdG8gc3VwcG9ydCBHTVBMUyBjb250cm9sIGZv ciB0aGUgc2FtZS4gW1JGQzQzMjhdIGludHJvZHVjZWQNCg0KICBHTVBMUyBzaWduYWxpbmcgZXh0 ZW5zaW9ucyBmb3Igc3VwcG9ydGluZyB0aGUgZWFybHkgdmVyc2lvbiBvZiBHLjcwOQ0KDQogIFtH LjcwOS12MV0uIFRoZSBiYXNpYyByb3V0aW5nIGNvbnNpZGVyYXRpb25zIGZyb20gc2lnbmFsaW5n DQoNCiAgcGVyc3BlY3RpdmUgaXMgYWxzbyBzcGVjaWZpZWQgaW4gW1JGQzQzMjhdLg0KDQogICAN Cg0KICBUaGUgcmVjZW50IHJldmlzaW9uIG9mIElUVS1UIFJlY29tbWVuZGF0aW9uIEcuNzA5IFtH LjcwOS12M10gYW5kDQoNCiAgW0dTVVAuNDNdIGhhdmUgaW50cm9kdWNlZCBuZXcgT0RVIGNvbnRh aW5lcnMgKGJvdGggZml4ZWQgYW5kDQoNCiAgZmxleGlibGUpIGFuZCBhZGRpdGlvbmFsIE9EVSBt dWx0aXBsZXhpbmcgY2FwYWJpbGl0aWVzLCBlbmFibGluZw0KDQogIHN1cHBvcnQgZm9yIG9wdGlt YWwgc2VydmljZSBhZ2dyZWdhdGlvbi4gIA0KDQogICANCg0KICBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBPU1BGIHByb3RvY29sIGV4dGVuc2lvbnMgdG8gc3VwcG9ydA0KDQogIEdlbmVyYWxpemVk IE1QTFMgKEdNUExTKSBjb250cm9sIGZvciByb3V0aW5nIHNlcnZpY2VzIG92ZXIgdGhlDQoNCiAg c3RhbmRhcmRpemVkIE9UVS9PRFUgY29udGFpbmVycyBpbiBzdXBwb3J0IG9mIE9EVSBiYXNlZCBU RE0NCg0KICBzd2l0Y2hpbmcuIFJvdXRpbmcgc3VwcG9ydCBmb3IgT3B0aWNhbCBDaGFubmVsIExh eWVyIHN3aXRjaGluZw0KDQogIChMYW1iZGEgc3dpdGNoaW5nKSBpcyBub3QgY292ZXJlZCBpbiB0 aGlzIGRvY3VtZW50Lg0KDQogICANCg0KICAgDQoNCiAgIA0KDQogICANCg0KICBUaGUgSUVURiBT ZWNyZXRhcmlhdC4NCg0KICAgDQoNCiAgIA0KDQogIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCiAgQ0NBTVAgbWFpbGluZyBsaXN0DQoNCiAgQ0NBTVBA aWV0Zi5vcmcNCg0KICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w DQoNCiAgIA0KDQogIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCiAgQ0NBTVAgbWFpbGluZyBsaXN0DQoNCiAgQ0NBTVBAaWV0Zi5vcmcNCg0KICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQogIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogIENDQU1QIG1haWxpbmcgbGlzdA0KICBDQ0FNUEBpZXRmLm9yZw0KICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo= --Boundary_(ID_bpDC8pqaPl649Cc7jzS5IA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4ID0gDQoidXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnAgPSANCiJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpwb3dlcnBvaW50IiB4bWxuczphID0gDQoidXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6YWNjZXNzIiB4bWxuczpkdCA9IA0KInV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzID0gDQoidXVpZDpCREM2RTNGMC02REEz LTExZDEtQTJBMy0wMEFBMDBDMTQ4ODIiIHhtbG5zOnJzID0gDQoidXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpyb3dzZXQiIHhtbG5zOnogPSAiI1Jvd3NldFNjaGVtYSIgeG1sbnM6YiA9IA0KInVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnB1Ymxpc2hlciIgeG1sbnM6c3MgPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6YyA9IA0K InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmNvbXBvbmVudDpzcHJlYWRzaGVldCIg eG1sbnM6b2RjID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2RjIiB4bWxu czpvYSA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24iIHht bG5zOmh0bWwgPSANCiJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxuczpxID0g DQoiaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnJ0YyA9 IA0KImh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIFhNTE5TOkQg PSAiREFWOiIgWE1MTlM6UmVwbCA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVw bC8iIHhtbG5zOm10ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50 L3NvYXAvbWVldGluZ3MvIiB4bWxuczp4MiA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlL2V4Y2VsLzIwMDMveG1sIiB4bWxuczpwcGRhID0gDQoiaHR0cDovL3d3dy5wYXNz cG9ydC5jb20vTmFtZVNwYWNlLnhzZCIgeG1sbnM6b2lzID0gDQoiaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvZGlyZWN0b3J5LyIgeG1sbnM6ZHMg PSANCiJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3AgPSANCiJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGMgPSAN CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjIiB4bWxuczp4c2QgPSANCiJo dHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8xL2FsZXJ0cy8iIHhtbG5z OmVjID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIiB4bWxuczpzcCA9IA0K Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcyA9IA0K Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1sbnM6eHNp ID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnVk Y3MgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5z OnVkY3hmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxmaWxl IiB4bWxuczp1ZGNwMnAgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRj L3BhcnR0b3BhcnQiIHhtbG5zOndmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9z aGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4bWxuczpkc3NzID0gDQoiaHR0cDovL3NjaGVtYXMu bWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2kgPSANCiJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2RpZ3NpZyIgeG1sbnM6bWRz c2kgPSANCiJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L2Rp Z2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyID0gDQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZv cm1hdHMub3JnL21hcmt1cC1jb21wYXRpYmlsaXR5LzIwMDYiIHhtbG5zOm0gPSANCiJodHRwOi8v c2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzID0g DQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9yZWxhdGlv bnNoaXBzIiB4bWxuczpzcHdwID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vc2hhcmVwb2ludC93 ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9leGNoYW5nZS9zZXJ2aWNlcy8yMDA2L3R5cGVzIiB4bWxuczpleDEybSA9IA0KImh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1s bnM6cHB0c2wgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vd2Vi c2VydmljZXMvU2hhcmVQb2ludFBvcnRhbFNlcnZlci9QdWJsaXNoZWRMaW5rc1NlcnZpY2UiIA0K WE1MTlM6WiA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3QgPSAiASI+PEhF QUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNo YXJzZXQ9aXNvLTg4NTktMSI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjI5MTIi IG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBXaW5n ZGluZ3M7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogV2luZ2RpbmdzOw0KfQ0KQGZv bnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IENhbGlicmk7DQp9DQpAZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogVGFob21hOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IENvbnNvbGFz Ow0KfQ0KQHBhZ2UgV29yZFNlY3Rpb24xIHtzaXplOiA4LjVpbiAxMS4waW47IG1hcmdpbjogMS4w aW4gMS4waW4gMS4waW4gMS4waW47IH0NClAuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDExcHQ7 IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYi DQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTFwdDsgTUFSR0lOOiAwaW4gMGluIDBw dDsgRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiINCn0NCkRJVi5Nc29Ob3JtYWwg ew0KCUZPTlQtU0laRTogMTFwdDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJD YWxpYnJpIiwic2Fucy1zZXJpZiINCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVD T1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1zb0h5 cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28t c3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQt REVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1z b0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVu ZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KUC5Nc29QbGFpblRleHQgew0KCUZP TlQtU0laRTogMTAuNXB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogQ29uc29s YXM7IG1zby1zdHlsZS1wcmlvcml0eTogOTk7IG1zby1zdHlsZS1saW5rOiAiUGxhaW4gVGV4dCBD aGFyIg0KfQ0KTEkuTXNvUGxhaW5UZXh0IHsNCglGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAw aW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6IENvbnNvbGFzOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5 OyBtc28tc3R5bGUtbGluazogIlBsYWluIFRleHQgQ2hhciINCn0NCkRJVi5Nc29QbGFpblRleHQg ew0KCUZPTlQtU0laRTogMTAuNXB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTog Q29uc29sYXM7IG1zby1zdHlsZS1wcmlvcml0eTogOTk7IG1zby1zdHlsZS1saW5rOiAiUGxhaW4g VGV4dCBDaGFyIg0KfQ0KUC5Nc29BY2V0YXRlIHsNCglGT05ULVNJWkU6IDhwdDsgTUFSR0lOOiAw aW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUYWhvbWEiLCJzYW5zLXNlcmlmIjsgbXNvLXN0eWxl LXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLWxpbms6ICJCYWxsb29uIFRleHQgQ2hhciINCn0NCkxJ Lk1zb0FjZXRhdGUgew0KCUZPTlQtU0laRTogOHB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05U LUZBTUlMWTogIlRhaG9tYSIsInNhbnMtc2VyaWYiOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5OyBt c28tc3R5bGUtbGluazogIkJhbGxvb24gVGV4dCBDaGFyIg0KfQ0KRElWLk1zb0FjZXRhdGUgew0K CUZPTlQtU0laRTogOHB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRhaG9t YSIsInNhbnMtc2VyaWYiOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5OyBtc28tc3R5bGUtbGluazog IkJhbGxvb24gVGV4dCBDaGFyIg0KfQ0KU1BBTi5QbGFpblRleHRDaGFyIHsNCglGT05ULUZBTUlM WTogQ29uc29sYXM7IG1zby1zdHlsZS1wcmlvcml0eTogOTk7IG1zby1zdHlsZS1saW5rOiAiUGxh aW4gVGV4dCI7IG1zby1zdHlsZS1uYW1lOiAiUGxhaW4gVGV4dCBDaGFyIg0KfQ0KU1BBTi5CYWxs b29uVGV4dENoYXIgew0KCUZPTlQtRkFNSUxZOiAiVGFob21hIiwic2Fucy1zZXJpZiI7IG1zby1z dHlsZS1wcmlvcml0eTogOTk7IG1zby1zdHlsZS1saW5rOiAiQmFsbG9vbiBUZXh0IjsgbXNvLXN0 eWxlLW5hbWU6ICJCYWxsb29uIFRleHQgQ2hhciINCn0NClNQQU4uRW1haWxTdHlsZTIxIHsNCglt c28tc3R5bGUtdHlwZTogcGVyc29uYWwNCn0NClNQQU4uRW1haWxTdHlsZTIyIHsNCgltc28tc3R5 bGUtdHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KLk1zb0NocERlZmF1bHQgew0KCUZPTlQtU0la RTogMTBwdDsgbXNvLXN0eWxlLXR5cGU6IGV4cG9ydC1vbmx5DQp9DQpESVYuV29yZFNlY3Rpb24x IHsNCglwYWdlOiBXb3JkU2VjdGlvbjENCn0NCk9MIHsNCglNQVJHSU4tQk9UVE9NOiAwaW4NCn0N ClVMIHsNCglNQVJHSU4tQk9UVE9NOiAwaW4NCn0NCjwvU1RZTEU+DQo8IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1F Ti1VUyB2TGluaz1wdXJwbGUgbGluaz1ibHVlIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbD5IaSBSYWphbiw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPllvdSBzYWlkIHRoZXJl IGFyZSB0aHJlZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHR3byBkcmFmdHMuIA0KPC9GT05UPjxGT05U IGZhY2U9QXJpYWw+Tm93LCZuYnNwO3dlIGFyZSBjb21pbmcmbmJzcDttdWNoIGNsb3NlciZuYnNw O3RoYXQgdGhlcmUgDQoibWF5IiBiZSBvbmx5IG9uZSBkaWZmZXJlbmNlIChpLmUuLCBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5KSBhZnRlciBEYW5pZWxlIGdhdmUgDQpzb21lIGNsYXJpZmljYXRpb25z LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+WW91ciBkcmFmdCBpbnRyb2R1Y2VzIGEgbmV3IHN1Yi1U TFYgU0NTSSANCmFuZCZuYnNwO1tkcmFmdC1jZWNjYXJlbGxpXSBpbnRyb2R1Y2VzIEdlbmVyYWxp emVkLUlTQ0Qgc3ViLVRMViwgc28gSSB0aGluayB0aGV5IA0KaGF2ZSB0aGUgc2FtZSBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5LCBhbHRob3VnaCZuYnNwO2l0IHNlZW1zIGxpa2UgdGhhdCB5b3VyIA0K ZHJhZnQgImNvdWxkIiBzdXBwb3J0IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuIDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWw+TW9yZW92ZXIsIHRoZXJlIGFyZSBzb21lIGRpc2FkdmFudGFnZXMgdG8gdXNl IHRoZSBleGlzdGluZyANCklTQ0QgK1NDU0kuIEZpcnN0bHksJm5ic3A7IGFzIERhbmllbGUgYWxy ZWFkeSBwb2ludGVkIGl0IG91dCwgaXQgaXMgYSBiaWcgaXNzdWUgDQp0byBhZHZlcnRpc2UgdGhh dCBNYXggTFNQIGJhbmR3aWR0aCBpcyAwIGluIHRoZSBjYXNlIG9mIG5vbi1PRFVmbGV4IHN1cHBv cnRlZCANCmZvciBOb2RlIEIvQywgaG93ZXZlciwgZm9yIE5vZGUgQShHLjcwOSBWMSksIGl0IG11 c3QgYWx3YXlzIGFkdmVydGlzZSANCmEmbmJzcDttZWFuaW5nZnVsIHZhbHVlIGZvciB0aGUmbmJz cDtNYXggTFNQIGJhbmR3aWR0aC4gU2Vjb25kbHksIFlvdSBoYXZlIA0KY2hhbmdlZCB0aGUgbWVh bmluZyBvZiAiTWluaW11bSBMU1AgQmFuZHdpZHRoIiwgd2hpY2ggd2lsbCBtYWtlIHRoZSBwYXRo IA0KY29tcHV0YXRpb24gbWVzc2VkLiBBc3N1bWUgT1RVMiBpbnRlcmZhY2UgdGhhdCBzdXBwb3J0 cyBPRFUyIHN3aXRjaGluZyBvbmx5IChhbiANCmV4YW1wbGUgaW4geW91ciBkcmFmdCksIGluIHRo aXMgY2FzZSwgYWNjb3JkaW5nIHRvIHRoZSByZWd1bGFyIHJvdXRpbmcgcHJvY2VzcywgDQppdCB3 aWxsIG1ha2UgdGhlIHJvdXRpbmcgcGF0aCBjb21wdXRhdGlvbiBmdW5jdGlvbiB0byB1bmRlcnN0 YW5kIHRoYXQgaXQgY2FuIA0Kc3VwcG9ydCBPRFUwIExTUC4gVGhpcmRseSwgaXQgY2FuIG5vdCBz dXBwb3J0IHByaW9yaXR5IGZsZXhpYmlsaXR5LCBzbyBpdCBpcyBub3QgDQplZmZpY2llbnQgZnJv bSB0aGUgcm91dGluZyBzY2FsYWJpbGl0eSBwZXJzcGVjdGl2ZS4gRm91cnRoLCBpdCBjYW4gbm90 IA0KZGlmZmVyZW50aWF0ZSB0ZXJtaW5hdGlvbiBhbmQgc3dpY2hpbmcgY2FwYWJpbGl0eSBmb3Ig eW91ciBkYXJmdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkkgYW0gdHJ5aW5nIHRvIHJlY2FsbCBt b3JlIHJlYXNvbnMgd2h5IHdlIG5lZWQgdG8gdXNlIGEgDQpuZXcgc3ViLVRMViByYXRoZXIgdGhh biB0aGUgZXhpc3RpbmcgVExWLCBiZWNhdXNlIHdlIGhhZCBsb3RzIG9mIGRpc2N1c3Npb24gDQpi ZWZvcmUgSUVURjc4dGggbWVldGluZyB0aHJvdWdoIG1haWxpbmcgbGlzdCBhbmQgRjJGLCBidXQg aXQgaXMgYSBsaXR0bGUgDQpkaWZmaWN1bHQgZm9yIG1lIHRvIGRpZyBtb3JlIHRoaW5ncyBmcm9t IG15IG1lbW9yeSBhdCB0aGlzIG1vbWVudCwgDQo6LSl+fn5+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPkJlc3QgUmVnYXJkczxCUj4mbmJzcDs8QlI+RmF0 YWk8QlI+Jm5ic3A7PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAw cHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAw MDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDog OXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+ DQogIDxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1ycmFv QGluZmluZXJhLmNvbSBocmVmPSJtYWlsdG86cnJhb0BpbmZpbmVyYS5jb20iPlJhamFuIFJhbzwv QT4gDQo8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxC PlRvOjwvQj4gPEEgdGl0bGU9ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbSANCiAgaHJl Zj0ibWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPkRhbmllbGUgQ2VjY2Fy ZWxsaTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7 Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPUx5b25nQENpZW5hLmNvbSANCiAgaHJlZj0ibWFpbHRvOkx5 b25nQENpZW5hLmNvbSI+T25nLCBMeW5kb248L0E+IDsgPEEgdGl0bGU9Y2NhbXBAaWV0Zi5vcmcg DQogIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L0E+IDwvRElW Pg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+ IFR1ZXNkYXksIE9jdG9iZXIgMjYsIDIwMTAgNzoxMyBBTTwvRElWPg0KICA8RElWIHN0eWxlPSJG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFJlOiBbQ0NBTVBdIE9T UEYtVEUgZXh0ZW5zaW9ucyBmb3IgDQogIEcuNzA5IE9UTiBkcmFmdCBzdWJtaXR0ZWQ6IGRyYWZ0 LWFzaG9rLWNjYW1wLWdtcGxzLW9zcGYtZzcwOS0wMTwvRElWPg0KICA8RElWPjxCUj48L0RJVj4N CiAgPERJViBjbGFzcz1Xb3JkU2VjdGlvbjE+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5EYW5p ZWxlLDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8 L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5QbGVhc2Ugc2VlIHJlc3BvbnNlIGlu bGluZSwgd2l0aGluIHsgfS4gPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4 dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PlRoYW5rczxv OnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+UmFqYW48bzpwPjwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PkZyb206IERhbmllbGUgQ2VjY2FyZWxsaSANCiAg W21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tXSA8bzpwPjwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PlNlbnQ6IEZyaWRheSwgT2N0b2JlciAyMiwgMjAxMCA2 OjQ5IEFNPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5UbzogUmFqYW4g UmFvPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5DYzogT25nLCBMeW5k b247IDxBIA0KICBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9B PjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+U3ViamVjdDogUkU6IFtD Q0FNUF0gT1NQRi1URSBleHRlbnNpb25zIGZvciBHLjcwOSBPVE4gDQogIGRyYWZ0IHN1Ym1pdHRl ZDogZHJhZnQtYXNob2stY2NhbXAtZ21wbHMtb3NwZi1nNzA5LTAxPG86cD48L286cD48L1A+DQog IDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9 TXNvUGxhaW5UZXh0PkhpIFJhamFuLDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFp blRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5KdXN0 IGEgY291cGxlIG9mIGNvbW1lbnRzIG9uIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgYW5kIA0KICBi YW5kd2lkdGggYWR2ZXJ0aXNlbWVudC48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxh aW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+LSBC YWNrd2FyZCBjb21wYXRpYmlsaXR5OiBubyBPRFUgYWR2ZXJ0aXNpbmcgaXMgZGVmaW5kZWQgDQog IGluIFJGQyA0MjAyLzQyMDMsIHNvIGkgYmVsaWV2ZSB0aGVyZSBhcmUgbm8gYmFja3dhcmQgY29t cGF0aWJpbGl0eSANCiAgaXNzdWVzLjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFp blRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpw PiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PltSYWphbl0gJm5ic3A7 eyA8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PkFncmVlIHRoZXJlIGlz IG5vIE9EVSBhZHZlcnRpc2VtZW50IGRlZmluZWQuIFRoZSBuZWVkIHRvIA0KICBhZGRyZXNzIGJh Y2t3YXJkcyBjb21wYXRpYmlsaXR5IGRlcGVuZHMgb24gdGhlIGZvbGxvd2luZzogPG86cD48L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAg PFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZuYnNwOzEpIGFyZSB0aGVyZSBSRkMtNDMyOCBiYXNlZCAN CiAgZGVwbG95bWVudHM/PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4m bmJzcDsyKSBJZiBzbywgd2hhdCBkbyB0aGV5IHVzZSBmb3IgQlcgDQogIGFkdmVydGlzZW1lbnQ/ PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mbmJzcDs8bzpwPjwvbzpw PjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0Pk91ciBmYWlyIGd1ZXNzIGlzIHRoYXQgSVND RCBpcyB1c2VkIGZvciB0aGlzIGFzIHBlciBSRkMgDQogIDQyMDIvNDIwMy4gPG86cD48L286cD48 L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9TXNvUGxhaW5UZXh0PlRoZXJlIGFyZSAyIHdheXMgdG8gYWRkcmVzcyB0aGUgY29tcGF0 aWJpbGl0eSBpc3N1ZSCWIA0KICBlaXRoZXIgc3VwcG9ydCBvciBkb26SdCBzdXBwb3J0LiBCYXNl ZCBvbiB0aGUgV0cgYWdyZWVtZW50IHdlIGNvdWxkIGdvIGVpdGhlciANCiAgd2F5IHdpdGhvdXQg YnJlYWtpbmcgdGhlIG1vZGVsIHdlIGhhdmUgcHJvcG9zZWQuIFBsZWFzZSByZWZlciB0byBhdHRh Y2hlZCANCiAgc2xpZGVzIGZvciBkZXRhaWxzLjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1N c29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4 dD59PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwv bzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0Pk1vcmVvdmVyIGluIGRyYWZ0LWFzaG9r LWNjYW1wLWdtcGxzLW9zcGYtZzcwOSB0aGUgTUFYIA0KICBMU1AgYmFuZHdpZHRoIGZpZWxkcyBv ZiB0aGUgSVNDRCBhcmUgdXNlZCBmb3IgdW5yZXNlcnZlZCBiYW5kd2lkdGggDQogIGFkdmVydGlz ZW1lbnQsIHRoaXMgaXMgYSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzc3VlIGluIG15IG9waW5p b24uIEl0IHN0YXRlcyANCiAgdGhhdDo8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxh aW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJFbmNvZGluZyBvZiBNYXggTFNQIA0KICBCYW5k d2lkdGggaXMgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNYXggTFNQIEJhbmR3aWR0 aCA9IA0KICBVbnJlc2VydmVkLVRTLUNvdW50IHggVFMtTm9taW5hbC1SYXRlIjxvOnA+PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQ IGNsYXNzPU1zb1BsYWluVGV4dD5bUmFqYW5dICZuYnNwO3sgPG86cD48L286cD48L1A+DQogIDxQ IGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0PlRoZSB1bml0IGhlcmUgaXMgaW4gQnl0ZXMvc2VjLiBUaGUgZGVzY3JpcHRpb24g YWJvdmUgDQogICgmYW1wOyBpbiBvdXIgZHJhZnQpIDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQgDQogIHN0eWxlPSJNQVJHSU4tTEVGVDogMjRwdDsgVEVYVC1JTkRFTlQ6 IC0wLjI1aW47IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PFNQQU4gDQogIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj4tPFNQQU4gDQogIHN0eWxlPSJGT05U OiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9TUEFO PjwhW2VuZGlmXT5zaG93cyB0aGF0IG5vbWluYWwgcmF0ZSBpcyBkZXBlbmRlbnQgb24gc3BlY2lm aWMgT0RVIA0KICBsYXllciBpbiBxdWVzdGlvbi4gPG86cD48L286cD48L1A+DQogIDxQIGNsYXNz PU1zb1BsYWluVGV4dCANCiAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAyNHB0OyBURVhULUlOREVOVDog LTAuMjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 U1BBTiANCiAgc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPi08U1BBTiANCiAgc3R5bGU9IkZPTlQ6 IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48L1NQQU4+ PCFbZW5kaWZdPnNob3dzIGhvdyBNYXggTFNQIGJhbmR3aWR0aCBudW1iZXIgaXMgZGVyaXZlZCBh dCB0aGUgDQogIGFkdmVydGlzaW5nIG5vZGUuPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b1BsYWluVGV4dD59PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpw PiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0Pk1vcmVvdmVyIGl0IHN0 YXRlczo8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7 PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICJJZiB0aGUgaW50ZXJmYWNlIGRvZXMgDQogIG5vdCBzdXBwb3J0IE9EVS1mbGV4 IHNlcnZpY2UsIDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMgdmFsdWUgc2hvdWxkIGJlIA0KICBjb2RlZCBh cyB6ZXJvIi48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5i c3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+QnV0IGFkdmVydGlzaW5nIG1h eCBMU1AgYmFuZHdpZHRoID0gMCBtZWFucyBkaXNjYXJkaW5nIA0KICBzdWNoIGxpbmsgaW4gdGhl IHBhdGggY29tcHV0YXRpb24gcHJvY2Vzcy48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+ W1JhamFuXSB7PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5Hb29kIHF1 ZXN0aW9uICZhbXA7IHZlcnkgdmFsaWQuIEkgdGhpbmsgeW91IGFyZSBicmluZ2luZyANCiAgdXAg YSBzY2VuYXJpbyB3aGVyZSBPRFVmbGV4IGlzIG5vdCBzdXBwb3J0ZWQgYnV0IGJhY2t3YXJkIGNv bXBhdGliaWxpdHkgaXMgDQogIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1N c29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4 dD5XaGF0IHdlIG5lZWQgaGVyZSBpcyB0byBzZXBhcmF0ZSBPRFVmbGV4IGFkdmVydGlzZW1lbnQg DQogIGZyb20gSVNDRDo6TWF4LUxTUC1CVy4gVGhpcyBjYW4gYmUgZWFzaWx5IGFjY29tcGxpc2hl ZCB3aXRoIGEgc3ViLVRMViBmb3IgDQogIE9EVWZsZXggc2lnbmFsIHR5cGUgaW4gb3VyIG1vZGVs LiBCVyBpbiBieXRlcy9zZWMsIG9mIGNvdXJzZS4mbmJzcDsgUGxlYXNlIA0KICByZWZlciB0byBh dHRhY2hlZCBzbGlkZXMgZm9yIGRldGFpbHMuPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b1BsYWluVGV4dD4mbmJzcDsgPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4 dD59PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwv bzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0Pi0gQmFuZHdpZHRoIGFkdmVydGlzZW1l bnQ6IGluIHRoZSAtMDQgdmVyc2lvbiBvZiBvdXIgDQogIGRyYWZ0IHRoZSBiYW5kd2lkdGggaXMg YWR2ZXJ0aXNlZCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFp blRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mbmJz cDsmbmJzcDsmbmJzcDsgLSBVbnJlc2VydmVkIGJhbmR3aWR0aCBmb3IgZml4ZWQgDQogIGNvbnRh aW5lciBpbiBudW1iZXIgb2YgY29udGFpbmVyczxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1N c29QbGFpblRleHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gVW5yZXNlcnZlZCBiYW5kd2lkdGggZm9y IG9kdWZsZXggaW4gDQogIEJ5dGVzL3NlYzxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Q bGFpblRleHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gTWF4IExTUCBiYW5kd2lkdGggaW4gDQogIEJ5 dGVzL3NlYy48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5i c3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+W1JhamFuXSB7PG86cD48L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5XZSBiZWxpZXZlIGFkdmVydGlzaW5nIHRo ZSBudW1iZXIgb2YgY29udGFpbmVycyBpcyB0aGUgDQogIHJpZ2h0IGFwcHJvYWNoLiBUaGlzIGlz IGV4YWN0bHkgdGhlIHByb3Bvc2FsIHdlIGhhdmUgaW4gb3VyIGRyYWZ0LiBHb29kIHRvIHNlZSAN CiAgdGhhdCB5b3UgaGF2ZSBtb3ZlZCBhd2F5IGZyb20gVFMgYXBwcm9hY2ggd2hpY2ggaGFkIHNl cmlvdXMgDQogIGxpbWl0YXRpb25zLjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFp blRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD59PG86 cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PkFkdmVydGlzaW5nIHRoZSB1bnJlc2VydmVkIGJh bmR3aWR0aCBpbiBudW1iZXIgb2YgDQogIGNvbnRhaW5lcnMgaXMgdGhlIG1vc3Qgc3VpdGFibGUg d2F5IGZvciBmaXhlZCBjb250YWluZXJzIChPRFVrKSBidXQgZG9lc24ndCANCiAgd29yayB3aXRo IE9EVWZsZXguPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZu YnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PltSYWphbl0gezxvOnA+PC9v OnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQog IDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mbmJzcDtUaGUgT0RVZmxleCB1c2VzIGJ5dGVzL3NlYyBp biBvdXIgZHJhZnQuJm5ic3A7IA0KICBUaGVyZSBpcyBubyBkaXNhZ3JlZW1lbnQgaGVyZS48bzpw PjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+fSA8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9 TXNvUGxhaW5UZXh0PkJSPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48 bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PlRoZSBhdXRob3Jz PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpw PjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5Gcm9tOiBjY2FtcC1ib3Vu Y2VzQGlldGYub3JnIA0KICBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBSYWphbiBSYW88bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PlNl bnQ6IHZlbmVyZOwgMTUgb3R0b2JyZSAyMDEwIDE5LjEzPG86cD48L286cD48L1A+DQogIDxQIGNs YXNzPU1zb1BsYWluVGV4dD5UbzogT25nLCBMeW5kb247IGNjYW1wQGlldGYub3JnPG86cD48L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5TdWJqZWN0OiBSZTogW0NDQU1QXSBPU1BG LVRFIGV4dGVuc2lvbnMgZm9yIEcuNzA5IE9UTiANCiAgZHJhZnQgc3VibWl0dGVkOiBkcmFmdC1h c2hvay1jY2FtcC1nbXBscy1vc3BmLWc3MDktMDE8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRl eHQ+THluZG9uLDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4m bmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5ZZXMsIHdlIGFyZSBhd2Fy ZSBvZiB0aGUgZXhpc3RpbmcgZHJhZnQuIFRoZXJlIGFyZSBzb21lIA0KICBmdW5kYW1lbnRhbCBk aWZmZXJlbmNlcyBpbiB0aGUgbW9kZWwgd2UgaGF2ZSBwcm9wb3NlZCBmcm9tIHRoZSBleGlzdGlu ZyBkcmFmdC4gDQogIFRoZSBrZXkgZGlmZmVyZW5jZXMgYXJlIHRoZSBmb2xsb3dpbmc6PG86cD48 L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mbmJzcDs8bzpwPjwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjEpIFRoaXMgZHJhZnQgZXh0ZW5kcyBleGlzdGluZyBJ U0NEJm5ic3A7IFZzLiBkZWZpbmluZyBhIA0KICBuZXcgb25lIDxvOnA+PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gYWRkcmVzc2VzIGJhY2t3 YXJkIGNvbXBhdGliaWxpdHkgDQogIGlzc3VlcyAoUkZDIDQyMDIpPG86cD48L286cD48L1A+DQog IDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9 TXNvUGxhaW5UZXh0PjIpIE9EVSBjb250YWluZXJzIGFyZSBhZHZlcnRpc2VkIGluc3RlYWQgb2Yg DQogICNUU3M8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtIHNpbXBsZSBwYXRoIA0KICBjb21wdXRhdGlvbjxvOnA+PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQ IGNsYXNzPU1zb1BsYWluVGV4dD4zKSBQYXRoIGNvbXB1dGluZyBub2RlIGRvZXNuJ3QgbmVlZCB0 byBrbm93IHBlciBsaW5rIA0KICBhbmQvb3IgcGVyIE9EVSBsYXllciBUUyBncmFudWxhcml0eTxv OnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0gYWdhaW4sIHNpbXBsZSAmYW1wOyBzdHJhaWdodCANCiAgZm9yd2FyZCBwYXRoIGNv bXB1dGF0aW9uJm5ic3A7IDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+ PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5UaGFua3M8bzpw PjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PlJhamFuPG86cD48L286cD48L1A+ DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L1A+ DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5Gcm9tOiBPbmcsIEx5bmRvbiANClttYWlsdG86THlv bmdAQ2llbmEuY29tXTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+U2Vu dDogVGh1cnNkYXksIE9jdG9iZXIgMTQsIDIwMTAgNzo0NSBBTTxvOnA+PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQ+VG86IFJhamFuIFJhbzsgY2NhbXBAaWV0Zi5vcmc8bzpwPjwv bzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PlN1YmplY3Q6IFJFOiBbQ0NBTVBdIE9T UEYtVEUgZXh0ZW5zaW9ucyBmb3IgRy43MDkgT1ROIA0KICBkcmFmdCBzdWJtaXR0ZWQ6IGRyYWZ0 LWFzaG9rLWNjYW1wLWdtcGxzLW9zcGYtZzcwOS0wMTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWlu VGV4dD5IaSBSYWphbiw8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxv OnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+SGF2ZSB5b3UgbG9v a2VkIGF0IA0KICBkcmFmdC1jZWNjYXJlbGxpLWNjYW1wLWdtcGxzLW9zcGYtZzcwOS0wMy50eHQ/ Jm5ic3A7IEl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gDQogIHVuZGVyc3RhbmQgaWYgeW91ciBkcmFm dCBpcyBhc2tpbmcgZm9yIHNpbWlsYXIgZXh0ZW5zaW9ucyBvciBkaWZmZXJlbnQgDQogIGZ1bmN0 aW9uYWxpdHkuPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZu YnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PlRoYW5rcyw8bzpwPjwvbzpw PjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQ+THluZG9uPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJz cDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+RnJvbTogY2Nh bXAtYm91bmNlc0BpZXRmLm9yZyANCiAgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgUmFqYW4gUmFvPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWlu VGV4dD5TZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTMsIDIwMTAgMjo0MCBQTTxvOnA+PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+VG86IGNjYW1wQGlldGYub3JnPG86cD48L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5TdWJqZWN0OiBbQ0NBTVBdIE9TUEYtVEUg ZXh0ZW5zaW9ucyBmb3IgRy43MDkgT1ROIGRyYWZ0IA0KICBzdWJtaXR0ZWQ6PG86cD48L286cD48 L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5kcmFmdC1hc2hvay1jY2FtcC1nbXBscy1vc3Bm LWc3MDktMDE8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5i c3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+SGksPG86cD48L286cD48L1A+ DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0PlRoZSBmb2xsb3dpbmcgZHJhZnQgaGFzIGJlZW4gc3VibWl0dGVkLiBQ bGVhc2UgcmV2aWV3LiANCiAgQ29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLjxvOnA+PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIA0K ICBjbGFzcz1Nc29QbGFpblRleHQ+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtYXNob2stY2NhbXAtZ21wbHMtb3NwZi1nNzA5LzxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWlu VGV4dD50aGFua3M8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PkF1dGhv cnM8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9v OnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PkZyb206IElFVEYgSS1E IFN1Ym1pc3Npb24gVG9vbCANCiAgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddPG86cD48 L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5TZW50OiBXZWRuZXNkYXksIE9jdG9i ZXIgMTMsIDIwMTAgMjozMCBQTTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRl eHQ+VG86IFJhamFuIFJhbzxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+ Q2M6IFNuaWdkaG8gQmFyZGFsYWk7IEFzaG9rIEt1bmppZGhhcGF0aGFtOyBLaHV6ZW1hIA0KICBQ aXRoZXdhbjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+U3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1N c29QbGFpblRleHQ+ZHJhZnQtYXNob2stY2NhbXAtZ21wbHMtb3NwZi1nNzA5LTAxIDxvOnA+PC9v OnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQog IDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9 TXNvUGxhaW5UZXh0PkEgbmV3IHZlcnNpb24gb2YgSS1ELCANCiAgZHJhZnQtYXNob2stY2NhbXAt Z21wbHMtb3NwZi1nNzA5LTAxLnR4dCBoYXMgYmVlbjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQ+c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSYWphbiBSYW8gYW5kIHBv c3RlZCB0byB0aGUgDQogIElFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFp blRleHQ+RmlsZW5hbWU6Jm5ic3A7Jm5ic3A7IA0KICBkcmFmdC1hc2hvay1jY2FtcC1nbXBscy1v c3BmLWc3MDk8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PlJldmlzaW9u OiZuYnNwOyZuYnNwOyAwMTxvOnA+PC9vOnA+PC9QPg0KICA8UCANCiAgY2xhc3M9TXNvUGxhaW5U ZXh0PlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgT1NQRiBURSBFeHRlbnNpb25zIGZvciBHZW5lcmFsaXpl ZCBNUExTIChHTVBMUykgQ29udHJvbDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFp blRleHQ+b2YgRy43MDkgT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29ya3M8bzpwPjwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PkNyZWF0aW9uX2RhdGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICAyMDEwLTEwLTEyPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5X RyANCiAgSUQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBJbmRlcGVuZGVudCBTdWJtaXNzaW9uPG86cD48L286cD48 L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5OdW1iZXJfb2ZfcGFnZXM6IDIwPG86cD48L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAg PFAgY2xhc3M9TXNvUGxhaW5UZXh0PkFic3RyYWN0OjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQ+QXMgT1ROIG5ldHdvcmsgY2FwYWJpbGl0aWVzIGNvbnRpbnVlIHRvIGV2 b2x2ZSwgdGhlcmUgaXMgDQogIGFuIGluY3JlYXNlZDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQ+bmVlZCB0byBzdXBwb3J0IEdNUExTIGNvbnRyb2wgZm9yIHRoZSBzYW1l LiBbUkZDNDMyOF0gDQogIGludHJvZHVjZWQ8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0PkdNUExTIHNpZ25hbGluZyBleHRlbnNpb25zIGZvciBzdXBwb3J0aW5nIHRoZSBl YXJseSANCiAgdmVyc2lvbiBvZiBHLjcwOTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Q bGFpblRleHQ+W0cuNzA5LXYxXS4gVGhlIGJhc2ljIHJvdXRpbmcgY29uc2lkZXJhdGlvbnMgZnJv bSANCiAgc2lnbmFsaW5nPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5w ZXJzcGVjdGl2ZSBpcyBhbHNvIHNwZWNpZmllZCBpbiANCiAgW1JGQzQzMjhdLjxvOnA+PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQ IGNsYXNzPU1zb1BsYWluVGV4dD5UaGUgcmVjZW50IHJldmlzaW9uIG9mIElUVS1UIFJlY29tbWVu ZGF0aW9uIEcuNzA5IA0KICBbRy43MDktdjNdIGFuZDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQ+W0dTVVAuNDNdIGhhdmUgaW50cm9kdWNlZCBuZXcgT0RVIGNvbnRhaW5l cnMgKGJvdGggZml4ZWQgDQogIGFuZDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFp blRleHQ+ZmxleGlibGUpIGFuZCBhZGRpdGlvbmFsIE9EVSBtdWx0aXBsZXhpbmcgY2FwYWJpbGl0 aWVzLCANCiAgZW5hYmxpbmc8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PnN1cHBvcnQgZm9yIG9wdGltYWwgc2VydmljZSBhZ2dyZWdhdGlvbi4mbmJzcDsgDQogIDxvOnA+ PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+ DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5UaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBPU1BGIHBy b3RvY29sIGV4dGVuc2lvbnMgdG8gDQogIHN1cHBvcnQ8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0PkdlbmVyYWxpemVkIE1QTFMgKEdNUExTKSBjb250cm9sIGZvciByb3V0 aW5nIHNlcnZpY2VzIA0KICBvdmVyIHRoZTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Q bGFpblRleHQ+c3RhbmRhcmRpemVkIE9UVS9PRFUgY29udGFpbmVycyBpbiBzdXBwb3J0IG9mIE9E VSBiYXNlZCANCiAgVERNPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5z d2l0Y2hpbmcuIFJvdXRpbmcgc3VwcG9ydCBmb3IgT3B0aWNhbCBDaGFubmVsIExheWVyIA0KICBz d2l0Y2hpbmc8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PihMYW1iZGEg c3dpdGNoaW5nKSBpcyBub3QgY292ZXJlZCBpbiB0aGlzIA0KICBkb2N1bWVudC48bzpwPjwvbzpw PjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZuYnNwOzxvOnA+PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1z b1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+VGhlIElFVEYg U2VjcmV0YXJpYXQuPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpw PiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9v OnA+PC9QPg0KICA8UCANCiAgY2xhc3M9TXNvUGxhaW5UZXh0Pl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b1BsYWluVGV4dD5DQ0FNUCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9 TXNvUGxhaW5UZXh0PkNDQU1QQGlldGYub3JnPG86cD48L286cD48L1A+DQogIDxQIA0KICBjbGFz cz1Nc29QbGFpblRleHQ+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286 cD48L1A+DQogIDxQIA0KICBjbGFzcz1Nc29QbGFpblRleHQ+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0PkNDQU1QIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1N c29QbGFpblRleHQ+Q0NBTVBAaWV0Zi5vcmc8bzpwPjwvbzpwPjwvUD4NCiAgPFAgDQogIGNsYXNz PU1zb1BsYWluVGV4dD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w PG86cD48L286cD48L1A+PC9ESVY+DQogIDxQPg0KICA8SFI+DQoNCiAgPFA+PC9QPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPkNDQU1QIG1haWxpbmcg DQogIGxpc3Q8QlI+Q0NBTVBAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jY2FtcDxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_bpDC8pqaPl649Cc7jzS5IA)-- From sergio.belotti@alcatel-lucent.com Tue Oct 26 05:27:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D75D3A6951 for ; Tue, 26 Oct 2010 05:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.676 X-Spam-Level: X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[AWL=1.572, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImBUcsLgT1UJ for ; Tue, 26 Oct 2010 05:27:00 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 8C2AC3A67B2 for ; Tue, 26 Oct 2010 05:26:57 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9QCRRaR003743 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Oct 2010 14:28:23 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 26 Oct 2010 14:28:13 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Fatai Zhang , Rajan Rao Date: Tue, 26 Oct 2010 14:28:12 +0200 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: Act1Bt7KT3oUIIy1TYajB4X112DZMgAAXm/Q Message-ID: References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> In-Reply-To: <01e401cb7506$c996ade0$654c460a@china.huawei.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F050945A8D8E9A44A71039532BA344D80E02FF14FRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "Ong, Lyndon" , "ccamp@ietf.org" Subject: [CCAMP] R: OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2010 12:27:12 -0000 --_000_F050945A8D8E9A44A71039532BA344D80E02FF14FRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, we concur with all Fatai pointed out with one more addon : the change in th= e semantic of Minimum LSP BW open also the door to the question of which "N= ominal " OPU Tributary Slot should be chose in case of bundling . Best Regards Sergio and Pietro Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 ________________________________ Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Fat= ai Zhang Inviato: marted=EC 26 ottobre 2010 14.11 A: Rajan Rao; Daniele Ceccarelli Cc: Ong, Lyndon; ccamp@ietf.org Oggetto: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, You said there are three differences between two drafts. Now, we are coming= much closer that there "may" be only one difference (i.e., backward compat= ibility) after Daniele gave some clarifications. Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces = Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backward compat= ibility. Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firs= tly, as Daniele already pointed it out, it is a big issue to advertise tha= t Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C,= however, for Node A(G.709 V1), it must always advertise a meaningful value= for the Max LSP bandwidth. Secondly, You have changed the meaning of "Mini= mum LSP Bandwidth", which will make the path computation messed. Assume OTU= 2 interface that supports ODU2 switching only (an example in your draft), i= n this case, according to the regular routing process, it will make the rou= ting path computation function to understand that it can support ODU0 LSP. = Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. Fourth, it can not differentiate te= rmination and swiching capability for your darft. I am trying to recall more reasons why we need to use a new sub-TLV rather = than the existing TLV, because we had lots of discussion before IETF78th me= eting through mailing list and F2F, but it is a little difficult for me to = dig more things from my memory at this moment, :-)~~~~ Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: Daniele Ceccarelli Cc: Ong, Lyndon ; ccamp@ietf.org Sent: Tuesday, October 26, 2010 7:13 AM Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards = compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue - either support or don= 't support. Based on the WG agreement we could go either way without breaki= ng the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question= . - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where OD= Uflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-B= W. This can be easily accomplished with a sub-TLV for ODUflex signal type i= n our model. BW in bytes/sec, of course. Please refer to attached slides f= or details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This= is exactly the proposal we have in our draft. Good to see that you have mo= ved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ 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 --_000_F050945A8D8E9A44A71039532BA344D80E02FF14FRMRSSXCHMBSB1d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

we concur with all = Fatai pointed out with one more addon : the change in the semantic of Minimum LSP= BW open also the door to the question of which “Nominal “ OPU Trib= utary Slot should be chose in case of bundling .

 

Best Regards

 

Sergio and Pietro

 

Sergio Belotti

System Architecture=
Optics Division-Terrestrial Optics Unit=
ALCATEL-LUCENT

+39 039 6863033
+39 039 6863590

Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Fatai Zhang
Inviato: marted=EC 26 ottobr= e 2010 14.11
A: Rajan Rao; Daniele Ceccar= elli
Cc: Ong, Lyndon; ccamp@ietf.= org
Oggetto: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Hi Rajan,

 <= /span>

You said there are three differences between two drafts. Now, we are coming much closer that there "may" be only one difference (i.e., backward compatibility) after Daniele gave some clarifications.

 <= /span>

Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibility, although it seems like that your draft "could" support backward compatibility. =

 <= /span>

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly,  as Daniele already pointed it out, it i= s a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUfl= ex supported for Node B/C, however, for Node A(G.709 V1), it must always adver= tise a meaningful value for the Max LSP bandwidth. Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which will make t= he path computation messed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular rou= ting process, it will make the routing path computation function to understand t= hat it can support ODU0 LSP. Thirdly, it can not support priority flexibility, = so it is not efficient from the routing scalability perspective. Fourth, it ca= n not differentiate termination and swiching capability for your darft.

 <= /span>

I am trying to recall more reasons why we need to= use a new sub-TLV rather than the existing TLV, because we had lots of discussi= on before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig more things from my memory at this moment, :-)~~~~<= /span>

 <= /span>

 <= /span>

Best Regards
 
Fatai
 

----- Original Message -----

Sent:<= /font> Tuesday, October 26, 2010 7:13 AM

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-c= camp-gmpls-ospf-g709-01

 <= /span>

Daniele,

 

Please see response inline, within { }.

 

Thanks

Rajan

 

-----Original Message-----

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Just a couple of comments on backward compatibil= ity and bandwidth advertisement.

 

- Backward compatibility: no ODU advertising is definded in RFC 4202/4203, so i believe there are no backward compatibility issues.

 

 

[Rajan]  {

Agree there is no ODU advertisement defined. The= need to address backwards compatibility depends on the following:

 

 1) are there RFC-4328 based deployments?

 2) If so, what do they use for BW advertis= ement?

 

Our fair guess is that ISCD is used for this as = per RFC 4202/4203.

 

There are 2 ways to address the compatibility is= sue – either support or don’t support. Based on the WG agreement we could g= o either way without breaking the model we have proposed. Please refer to attached slides for details.

 

}

 

Moreover in draft-ashok-ccamp-gmpls-ospf-g709 th= e MAX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisement, this is a backward compatibility issue in my opinion. It sta= tes that:

 

      "Encoding of= Max LSP Bandwidth is as follows:

       Max LSP Ban= dwidth =3D Unreserved-TS-Count x TS-Nominal-Rate"

 

[Rajan]  {

 

The unit here is in Bytes/sec. The description a= bove (& in our draft)

-    shows that nominal rate is dependent on specific ODU layer in question.

-    shows how Max LSP bandwidth number is derived at the advertisi= ng node.

}

 

Moreover it states:

 

      "If the inte= rface does not support ODU-flex service,

      this value should= be coded as zero".

 

But advertising max LSP bandwidth =3D 0 means di= scarding such link in the path computation process.

 

[Rajan] {

Good question & very valid. I think you are = bringing up a scenario where ODUflex is not supported but backward compatibility is required.

 

What we need here is to separate ODUflex adverti= sement from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course.  Please refer to attached slides for details.

 

}

 

- Bandwidth advertisement: in the -04 version of= our draft the bandwidth is advertised as follows:

 

    - Unreserved bandwidth for fi= xed container in number of containers

    - Unreserved bandwidth for od= uflex in Bytes/sec

    - Max LSP bandwidth in Bytes/= sec.

 

[Rajan] {

We believe advertising the number of containers = is the right approach. This is exactly the proposal we have in our draft. Good to = see that you have moved away from TS approach which had serious limitations.

 

}

 

Advertising the unreserved bandwidth in number o= f containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

 

[Rajan] {

 

 The ODUflex uses bytes/sec in our draft.&n= bsp; There is no disagreement here.

 

}

BR

 

The authors

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: venerd=EC 15 ottobre 2010 19.13=

To: Ong, Lyndon; ccamp@ietf.org

Subject: Re: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Lyndon,

 

Yes, we are aware of the existing draft. There a= re some fundamental differences in the model we have proposed from the existin= g draft. The key differences are the following:

 

1) This draft extends existing ISCD  Vs. de= fining a new one

    - addresses backward compatib= ility issues (RFC 4202)

 

2) ODU containers are advertised instead of #TSs=

     - simple path computati= on

 

3) Path computing node doesn't need to know per = link and/or per ODU layer TS granularity

     - again, simple & straight forward path computation 

 

Thanks

Rajan

 

-----Original Message-----

From: Ong, Lyndon [mailto:Lyong@Ciena.com]<= /o:p>

Sent: Thursday, October 14, 2010 7:45 AM

To: Rajan Rao; ccamp@ietf.org<= /font>

Subject: RE: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It would be helpful to understand if your draft is asking for similar extensions or different functionality.

 

Thanks,

 

Lyndon

 

 

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: Wednesday, October 13, 2010 2:40 PM

To: ccamp@ietf.org

Subject: [CCAMP] OSPF-TE extensions for G.709 OT= N draft submitted:

draft-ashok-ccamp-gmpls-ospf-g709-01<= /span>

 

Hi,

 

The following draft has been submitted. Please r= eview. Comments are appreciated.

 

https://datatracker.ietf.org/doc/draft-ashok-cca= mp-gmpls-ospf-g709/

 

thanks

Authors

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]

Sent: Wednesday, October 13, 2010 2:30 PM

To: Rajan Rao

Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuz= ema Pithewan

Subject: New Version Notification for=

draft-ashok-ccamp-gmpls-ospf-g709-01 =

 

 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been<= /p>

successfully submitted by Rajan Rao and posted t= o the IETF repository.

 

Filename:   draft-ashok-ccamp-gmpls-ospf-g709

Revision:   01

Title:       =      OSPF TE Extensions for Generalized MPLS (GMPLS) Control

of G.709 Optical Transport Networks

Creation_date:    2010-10-12=

WG ID:            Independent Submission

Number_of_pages: 20

 

Abstract:

As OTN network capabilities continue to evolve, = there is an increased

need to support GMPLS control for the same. [RFC= 4328] introduced

GMPLS signaling extensions for supporting the ea= rly version of G.709

[G.709-v1]. The basic routing considerations fro= m signaling

perspective is also specified in [RFC4328].=

 

The recent revision of ITU-T Recommendation G.70= 9 [G.709-v3] and

[GSUP.43] have introduced new ODU containers (bo= th fixed and

flexible) and additional ODU multiplexing capabilities, enabling

support for optimal service aggregation.  <= o:p>

 

This document describes OSPF protocol extensions= to support

Generalized MPLS (GMPLS) control for routing ser= vices over the

standardized OTU/ODU containers in support of OD= U based TDM

switching. Routing support for Optical Channel L= ayer switching

(Lambda switching) is not covered in this docume= nt.

 

 

 

 

The IETF Secretariat.

 

 

_______________________________________________<= o:p>

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp=

 

_______________________________________________<= o:p>

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

--_000_F050945A8D8E9A44A71039532BA344D80E02FF14FRMRSSXCHMBSB1d_-- From adrian@olddog.co.uk Tue Oct 26 07:29:00 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E823A67A1 for ; Tue, 26 Oct 2010 07:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsWXE-EtXCbI for ; Tue, 26 Oct 2010 07:28:59 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 8A1053A685C for ; Tue, 26 Oct 2010 07:28:50 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o9QEUYdK003703; Tue, 26 Oct 2010 15:30:34 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o9QEUXMh003689; Tue, 26 Oct 2010 15:30:33 +0100 From: "Adrian Farrel" To: "'Olufemi Komolafe'" References: <1288101490.7081.4.camel@dhcp-144-254-153-58.cisco.com> In-Reply-To: <1288101490.7081.4.camel@dhcp-144-254-153-58.cisco.com> Date: Tue, 26 Oct 2010 15:30:34 +0100 Message-ID: <077301cb751a$59fb44f0$0df1ced0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG+TmVDDaxxcIHmewVCb+a2qwK2fpNtk6DQ Content-Language: en-gb Cc: shiomoto.kohei@lab.ntt.co.jp, ccamp@ietf.org Subject: Re: [CCAMP] Feedback on draft-shiomoto-ccamp-switch-programming-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 14:29:00 -0000 Hi Femi, Good questions. > I recently read this draft and thought it was pretty interesting. > I like the motivation behind it and the way you try to correlate > what may be inferred from the different pertinent RFCs as to > guidelines as to how LSRs should behave during the LSP set > up phase. > > However, one of the things that struck me while reading it > was that it'd be really useful for the draft to try to identify > definitively when it is safe for any LSR to forward the Path > or Resv message before programming its cross-connect, > exploiting pipelining to try to minimise the total time to set > up the LSP. You allude to this several times in the draft but > wonder if it'd be worthy of more consideration in the > draft? You're right. It would be really nice to be able to be definitive about this. But I am not sure that a node can "know" much without first probing the network (for example, with protocol extensions) and that would (of course) defeat the point of pipelining. There are so many variables introduced by path length and by other nodes. It even seems unlikely that a vendor would give a pessimistic view of how long it takes them to programme and stabilise their cross-connects. > Admittedly, an LSR cannot make any assumptions about how > long any other LSR in the path takes to program the cross- > connect or whether or not they support pipelining. However, > I think it is always safe for an LSR to forward the message > provided it knows that the time it takes to program the cross- > connect is less than the minimum possible time it > takes for the message to reach the end-point. I guess > estimating this latter time is the difficult part ;-) The only > thing I thought may help is trying to use the relative location > of a given LSR in the path (based on info in an ERO, if used) > to guide? I think the best we can do is set out some of these considerations so that a smart implementation has a chance to make some assumptions and choices. The points you raise certainly give some bullets we can add to a list, and I'll think about any others we can think of. In fact, it is relatively easy to come up with a formula from which is it possible to deduce worst-case scenarios. Cheers, Adrian From sshew@ciena.com Tue Oct 26 11:07:06 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052A53A6965 for ; Tue, 26 Oct 2010 11:07:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJTPg0fbxbYs for ; Tue, 26 Oct 2010 11:07:04 -0700 (PDT) Received: from hicks.ciena.com (hicks.ciena.com [63.118.34.22]) by core3.amsl.com (Postfix) with ESMTP id 4D8F23A68EC for ; Tue, 26 Oct 2010 11:07:03 -0700 (PDT) From: "Shew, Stephen" To: "ccamp@ietf.org" Date: Tue, 26 Oct 2010 14:08:39 -0400 Thread-Topic: [CCAMP] New Version Notification for draft-malis-ccamp-rfc5787bis-01 Thread-Index: ActbJhs4jq9Qoh6XSE2rcAxleXwbPQaEM6ag Message-ID: References: <20100922094423.0F58F3A6967@core3.amsl.com> <585B7F67-3035-44D6-9BD5-E3D60C64F3D5@ericsson.com> In-Reply-To: <585B7F67-3035-44D6-9BD5-E3D60C64F3D5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] New Version Notification for draft-malis-ccamp-rfc5787bis-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2010 18:07:06 -0000 I have read draft-malis-ccamp-rfc5787bis-01.txt and was involved in the dis= cussion of it at the recent ITU-T Q12/15 interim meeting. I have the follo= wing comments on it: The main comment I have on the draft is that it is requires more clarity on= address/name spaces that various identifiers are part of, especially disti= nguishing between the IP network address space and other address/namespaces= . In transport networks, there are different name spaces associated with s= ervices, resources (data plane), management functions, and the communicatio= ns between those functions. ASON (G.8080) can be viewed as another transpo= rt management function and thus has the following name spaces: Services - UNI and ENNI Transport Resource identifiers (known in OIF IAs as= Transport Network Addresses) Resources - Subnetwork Point Pool (SNPP) names Functions - Component (RC, NCC, CC, LRM, TAP, DS) names and Protocol Contro= ller names Communications - The Signalling Communications Network (SCN) has identifier= s that are used for the purpose of sending information between ASON compone= nts. These have similar meaning as L3 IP reachable addresses. Reading the draft then with this view of name spaces we make the following = comments: 1. General. The term "reachability" can be confusing as the semantics diffe= r with the name space to which it is applied. If applied to the resource o= r data plane, it means that the resource is visible in some topology. If a= pplied in the SCN context, it means that information can be sent to that ad= dress using an IP network. If applied to the component name space, it usua= lly means that the information can be sent to that component via the SCN. 2. Section 3. In an ASON context, "TE router ID" is in the resource name s= pace and identifies a node/matrix in the transport network. The "OSPF rout= er ID" is in a component name space and represents the routing function. 3. Section 4. The term "reachability" should be clarified in this section t= o mean identifiers in the resource plane that are advertised by the routing= function. They are not reachable in the same sense as functions are pinge= d in IP. What can be confusing is that these addresses may use the IPv4 or= IPv6 address format, but are in a different name space from IP routable ad= dresses. 4. Section 6.1. I would like to suggest that consideration be given to alw= ays advertising the Local and Remote TE Router ID sub-TLV. This would prov= ide a consistent advertising behaviour for the ASON case and make it possib= le to increase the scope of an OSPF router from one to two TE Router IDs wi= thout changing the advertising format. 5. Section 6.2. The term "reachability" should be clarified as noted above= (point 3). Also, I suggest that consideration be given to always advertisi= ng the Local TE Router ID sub-TLV for the same reason given above (point 4)= . Stephen Shew=A0| Director, Standards sshew@ciena.com | 3500 Carling Ave. |=A0Ottawa CANADA K2H 8E9 Direct +1.613.763.2462 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of A= cee Lindem Sent: 23 September, 2010 09:49 To: ccamp@ietf.org Subject: Re: [CCAMP] New Version Notification for draft-malis-ccamp-rfc5787= bis-01 Most of the changes in the this revision are an attempt to make the documen= t easier to understand for people unfamiliar with ITU ASON terminology. Thi= s is in response to comments from Julien Meuric and others at the IETF 78 C= CAMP meeting.=20 =20 - Section 2 now contains text better explaining the hierarchical re= lationship between RAs. Much of this is taken from RFC 4258.=20 - Section 3 has been rewritten with the description of an OSPF rout= er advertising on behalf multiple ASON transport nodes simplified. The subs= cripted variables (Ri, Pi, and Li) have been removed in favor of this simpl= ified terminology. - Section 5 includes solely editorial changes. Some of the longer s= entences have been split and some ambiguous language has been clarified.=20 - Section 6 has been rewritten to reflect the simplified terminolog= y introduced in section 3. Additionally, we have clarified when the rules f= or inclusion of the new section 6 Sub-TLVs. We also removed the restriction= on when these new Sub-TLVs may be specified.=20 - Section 7 includes some changes to reflect the new section 3 term= inology, as well as, a couple editorial changes.=20 Lyndon Ong will coordinate review of this revision with the ITU Q.12/15 SG = at their Shanghai meeting.=20 Thanks, Acee On Sep 22, 2010, at 5:44 AM, IETF I-D Submission Tool wrote: >=20 > A new version of I-D, draft-malis-ccamp-rfc5787bis-01.txt has been succes= sfully submitted by Andrew Malis and posted to the IETF repository. >=20 > Filename: draft-malis-ccamp-rfc5787bis > Revision: 01 > Title: Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) > Creation_date: 2010-09-22 > WG ID: Independent Submission > Number_of_pages: 20 >=20 > Abstract: > The ITU-T has defined an architecture and requirements for operating > an Automatically Switched Optical Network (ASON). >=20 > The Generalized Multiprotocol Label Switching (GMPLS) protocol suite > is designed to provide a control plane for a range of network > technologies including optical networks such as time division > multiplexing (TDM) networks including SONET/SDH and Optical Transport > Networks (OTNs), and lambda switching optical networks. >=20 > The requirements for GMPLS routing to satisfy the requirements of > ASON routing, and an evaluation of existing GMPLS routing protocols > are provided in other documents. This document defines extensions to > the OSPFv2 Link State Routing Protocol to meet the requirements for > routing in an ASON. >=20 > Note that this work is scoped to the requirements and evaluation > expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations > current when those documents were written. Future extensions of > revisions of this work may be necessary if the ITU-T Recommendations > are revised or if new requirements are introduced into a revision of > RFC 4258. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From rrao@infinera.com Tue Oct 26 12:14:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D473A68F5 for ; Tue, 26 Oct 2010 12:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Da-ivg9+JQ1 for ; Tue, 26 Oct 2010 12:14:00 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id BA55B3A6827 for ; Tue, 26 Oct 2010 12:14:00 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Tue, 26 Oct 2010 12:15:11 -0700 From: Rajan Rao To: Fatai Zhang , Daniele Ceccarelli Date: Tue, 26 Oct 2010 12:14:55 -0700 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: Act1Brf5KGIS065lRrORP3/7GvHAwgAOk0bw Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> In-Reply-To: <01e401cb7506$c996ade0$654c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30SVEXDB1infine_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" , Khuzema Pithewan , Ashok Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2010 19:14:14 -0000 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30SVEXDB1infine_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fatai, Please see response inline, within { } Thanks Rajan From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Tuesday, October 26, 2010 5:11 AM To: Rajan Rao; Daniele Ceccarelli Cc: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, You said there are three differences between two drafts. Now, we are coming= much closer that there "may" be only one difference (i.e., backward compat= ibility) after Daniele gave some clarifications. Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces = Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backward compat= ibility. Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firs= tly, as Daniele already pointed it out, it is a big issue to advertise tha= t Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C,= however, for Node A(G.709 V1), it must always advertise a meaningful value= for the Max LSP bandwidth. {Rajan] { Not clear what the issue is. We have listed 2 approaches in the slides sen= t out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero. Please clarify if you have a different case in mind. } Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports OD= U2 switching only (an example in your draft), in this case, according to th= e regular routing process, it will make the routing path computation functi= on to understand that it can support ODU0 LSP. [Rajan] { No, we have not changed the meaning of "Minimum LSP BW". Please elaborate= on what is messed. Following RFC 4202/4201 meaning, the example you have listed works as follo= ws: MinLSP-BW =3D ODU1 ( G.709-v1 supports 2.5G) MaxLSP-BW =3D ODU2 ( Min(unreserved-BW, configured Max LSP size) as per R= FC 4202) If you are computing path for an ODU0 connection, the rule would be Odu0-LSP-BW >=3D MinLSP-BW && <=3D MaxLSP-BW The computation fails for the above. Where is it messed? Please provide a= concrete example. } Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } Fourth, it can not differentiate termination and swiching capability for yo= ur darft. [Rajan] { We do not see a need to advertise this info. We need to understand the use= cases requiring this. Are T/S bits addressing HW limitations? } I am trying to recall more reasons why we need to use a new sub-TLV rather = than the existing TLV, because we had lots of discussion before IETF78th me= eting through mailing list and F2F, but it is a little difficult for me to = dig more things from my memory at this moment, :-)~~~~ [Rajan] { Please list the justifications for changing original GMPLS model. } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: Daniele Ceccarelli Cc: Ong, Lyndon ; ccamp@ietf.org Sent: Tuesday, October 26, 2010 7:13 AM Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards = compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue - either support or don= 't support. Based on the WG agreement we could go either way without breaki= ng the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question= . - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where OD= Uflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-B= W. This can be easily accomplished with a sub-TLV for ODUflex signal type i= n our model. BW in bytes/sec, of course. Please refer to attached slides f= or details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This= is exactly the proposal we have in our draft. Good to see that you have mo= ved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ 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 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30SVEXDB1infine_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fatai,=

 =

Please see response inli= ne, within { }

 =

Thanks=

Rajan<= /p>

 =

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Tuesday, October 26, 2010 5:11 AM
To: Rajan Rao; Daniele Ceccarelli
Cc: Ong, Lyndon; ccamp@ietf.org
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

You said there are three differences between two drafts. Now, we are coming much closer that there "may" be only one differe= nce (i.e., backward compatibility) after Daniele gave some clarifications.

 

Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backw= ard compatibility.

 

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly, = as Daniele already pointed it out, it is a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C, however, = for Node A(G.709 V1), it must always advertise a meaningful value for the Max LSP bandwidth.

{Rajan] {

Not clear what the issue is.  We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:

 With  backwar= d compatibility option, the ODUflex goes in to a separate sub–TLV withi= n SCCI. If ODUflex is not supported on a link, this sub-TLV will not be inclu= ded; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become ze= ro.

 =

Please clarify if you ha= ve a different case in mind.

}

 =

Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular routing process, it will make the routing path computation function= to understand that it can support ODU0 LSP.

[Rajan] {

No, we have not changed = the meaning of “Minimum LSP BW”.   Please elaborate on wh= at is messed.   

Following RFC 4202/4201 = meaning, the example you have listed works as follows:

 =

MinLSP-BW =3D ODU1 = ( G.709-v1 supports 2.5G)

MaxLSP-BW =3D ODU2 = ( Min(unreserved-BW, configured Max LSP size)  as per RFC 4202)

 =

If you are computing pat= h for an ODU0 connection, the rule would be

 =

Odu0-LSP-BW >=3D MinL= SP-BW && <=3D MaxLSP-BW

 =

The computation fails fo= r the above.   Where is it messed? Please provide a concrete example.

}

 =

Thirdly, it can not support priority flexibility, so it is not efficient from the routing scalability perspective. <= /span>

[Rajan] {

The whole idea is to sta= y with the GMPLS architecture already in place.  The technology specific extensions should go into SCSI. This has been done successfully for SONET/S= DH case (Ref to examples in RFC 4202). Do not see a reason to deviation from t= he original GMPLS model.

}

 =

Fourth, it can not differentiate termination and swiching capability for your darft= .

 [Rajan] {

We do not see a need to advertise this info.  We need to understand the use cases requiring th= is.  Are T/S bits addressing HW limitations?

}

 =

I am trying to recall more reasons why we need to use a new sub-TLV rather th= an the existing TLV, because we had lots of discussion before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig mo= re things from my memory at this moment, :-)~~~~

 [Rajan] {

Please list the justific= ations for changing original GMPLS model.

}

Best Regards
 
Fatai
 

----- Original Message -----

From: Rajan Rao

Sent: Tuesday, October 26= , 2010 7:13 AM

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Daniele,

 

Please see response inline, within { }. =

 

Thanks

Rajan

 

-----Original Message-----

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; = ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Just a couple of comments on backward compatibility= and bandwidth advertisement.

 

- Backward compatibility: no ODU advertising is def= inded in RFC 4202/4203, so i believe there are no backward compatibility issues.<= o:p>

 

 

[Rajan]  {

Agree there is no ODU advertisement defined. The ne= ed to address backwards compatibility depends on the following:

 

 1) are there RFC-4328 based deployments?=

 2) If so, what do they use for BW advertiseme= nt?

 

Our fair guess is that ISCD is used for this as per= RFC 4202/4203.

 

There are 2 ways to address the compatibility issue – either support or don’t support. Based on the WG agreement we could go either way without breaking the model we have proposed. Please ref= er to attached slides for details.

 

}

 

Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the M= AX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisemen= t, this is a backward compatibility issue in my opinion. It states that:<= /o:p>

 

      "Encoding of Ma= x LSP Bandwidth is as follows:

       Max LSP Bandwi= dth =3D Unreserved-TS-Count x TS-Nominal-Rate"

 

[Rajan]  {

 

The unit here is in Bytes/sec. The description abov= e (& in our draft)

-  = ;  shows that nominal rate is dependent on specific ODU layer in questi= on.

-  = ;  shows how Max LSP bandwidth number is derived at the advertising nod= e.

}

 

Moreover it states:

 

      "If the interfa= ce does not support ODU-flex service,

      this value should be= coded as zero".

 

But advertising max LSP bandwidth =3D 0 means disca= rding such link in the path computation process.

 

[Rajan] {

Good question & very valid. I think you are bri= nging up a scenario where ODUflex is not supported but backward compatibility is required.

 

What we need here is to separate ODUflex advertisem= ent from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course.  Please refer to attached slides for details.

 

}

 

- Bandwidth advertisement: in the -04 version of ou= r draft the bandwidth is advertised as follows:

 

    - Unreserved bandwidth for fixed container in number of containers

    - Unreserved bandwidth for odufl= ex in Bytes/sec

    - Max LSP bandwidth in Bytes/sec= .

 

[Rajan] {

We believe advertising the number of containers is = the right approach. This is exactly the proposal we have in our draft. Good to = see that you have moved away from TS approach which had serious limitations.

 

}

 

Advertising the unreserved bandwidth in number of containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

 

[Rajan] {

 

 The ODUflex uses bytes/sec in our draft. = ; There is no disagreement here.

 

}

BR

 

The authors

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: venerd=EC 15 ottobre 2010 19.13

To: Ong, Lyndon; ccamp@ietf.org

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Lyndon,

 

Yes, we are aware of the existing draft. There are = some fundamental differences in the model we have proposed from the existing dra= ft. The key differences are the following:

 

1) This draft extends existing ISCD  Vs. defin= ing a new one

    - addresses backward compatibili= ty issues (RFC 4202)

 

2) ODU containers are advertised instead of #TSs

     - simple path computation<= o:p>

 

3) Path computing node doesn't need to know per lin= k and/or per ODU layer TS granularity

     - again, simple & stra= ight forward path computation 

 

Thanks

Rajan

 

-----Original Message-----

From: Ong, Lyndon [mailto:Lyong@Ciena.com]

Sent: Thursday, October 14, 2010 7:45 AM=

To: Rajan Rao; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It would be helpful to understand if your draft is asking for similar extensions or different functionality.

 

Thanks,

 

Lyndon

 

 

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: Wednesday, October 13, 2010 2:40 PM

To: ccamp@ietf.org

Subject: [CCAMP] OSPF-TE extensions for G.709 OTN d= raft submitted:

draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi,

 

The following draft has been submitted. Please revi= ew. Comments are appreciated.

 

https://datatracker.ietf.org/doc/draft-ashok-ccamp-= gmpls-ospf-g709/

 

thanks

Authors

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission= @ietf.org]

Sent: Wednesday, October 13, 2010 2:30 PM

To: Rajan Rao

Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan

Subject: New Version Notification for

draft-ashok-ccamp-gmpls-ospf-g709-01

 

 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-= g709-01.txt has been

successfully submitted by Rajan Rao and posted to t= he IETF repository.

 

Filename:   draft-ashok-ccamp-gmpls-ospf-= g709

Revision:   01

Title:       &nb= sp;    OSPF TE Extensions for Generalized MPLS (GMPLS) Control

of G.709 Optical Transport Networks

Creation_date:    2010-10-12

WG ID:            Independent Submission

Number_of_pages: 20

 

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased

need to support GMPLS control for the same. [RFC432= 8] introduced

GMPLS signaling extensions for supporting the early version of G.709

[G.709-v1]. The basic routing considerations from signaling

perspective is also specified in [RFC4328].

 

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and

[GSUP.43] have introduced new ODU containers (both = fixed and

flexible) and additional ODU multiplexing capabilit= ies, enabling

support for optimal service aggregation. 

 

This document describes OSPF protocol extensions to support

Generalized MPLS (GMPLS) control for routing servic= es over the

standardized OTU/ODU containers in support of ODU b= ased TDM

switching. Routing support for Optical Channel Laye= r switching

(Lambda switching) is not covered in this document.=

 

 

 

 

The IETF Secretariat.

 

 

_______________________________________________

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

--_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30SVEXDB1infine_-- From rrao@infinera.com Tue Oct 26 14:24:56 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54323A682C for ; Tue, 26 Oct 2010 14:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qllHtaFdLy5T for ; Tue, 26 Oct 2010 14:24:53 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id 8C2F13A6879 for ; Tue, 26 Oct 2010 14:24:53 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Tue, 26 Oct 2010 14:26:04 -0700 From: Rajan Rao To: "ccamp@ietf.org" Date: Tue, 26 Oct 2010 14:26:03 -0700 Thread-Topic: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Thread-Index: Act1VGRI5wkewppjRwqJwYZTSF8Cjg== Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D99@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D99SVEXDB1infine_" MIME-Version: 1.0 Cc: Khuzema Pithewan , Mohit Misra Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2010 21:24:56 -0000 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D99SVEXDB1infine_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have a draft on "GMPLS Signaling extensions for OTN" available for revie= w. It can be accessed from the following link: http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt The above draft is not on IETF repository as we missed the submission deadl= ine. We will submit to IETF as soon as possible. Please review and comment. Abstract: As OTN network capabilities continue to evolve, there is an increased need= to support GMPLS control for the same. [RFC4328] introduced GMPLS signalin= g extensions for supporting early version of G.709 [G.709-v1].The basic rou= ting considerations from signaling perspective is also specified in [RFC432= 8]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] h= ave introduced new ODU containers (both fixed and flexible) and additional = ODU multiplexing capabilities, enabling support for optimal service aggrega= tion. This document extends [RFC4328] to provide GMPLS signaling support for the = new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling ext= ensions described in this document caters to ODU layer switching only. Opti= cal Channel Layer switching considerations in [RFC4328] are not modified in= this document. Thanks Authors --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D99SVEXDB1infine_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have a draft on “GMPLS Signaling extensions for OTN” available = for review.  It can be accessed from the following link:=

http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g= 709-00.txt

The above draft is not on IETF repository as we missed the submission deadline.=   We will submit to IETF as soon as possible.

 

Please review and comment.=

Abstract:

As OTN network capabilities continue to evolve, there is an increased  need to suppor= t GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions= for supporting early version of G.709 [G.709-v1].The basic routing consideratio= ns from signaling perspective is also specified in [RFC4328].

The recent revi= sion of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] have introduced new O= DU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation.<= /span>

This document e= xtends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in = this document caters to ODU layer switching only. Optical Channel Layer switchin= g considerations in [RFC4328] are not modified in this document.

 

Thanks

Authors

--_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D99SVEXDB1infine_-- From zhangfatai@huawei.com Wed Oct 27 02:51:24 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A442E3A69A7 for ; Wed, 27 Oct 2010 02:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxa1YC3uRO31 for ; Wed, 27 Oct 2010 02:51:23 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9A9B23A6824 for ; Wed, 27 Oct 2010 02:51:22 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAY001L201FS9@szxga05-in.huawei.com> for ccamp@ietf.org; Wed, 27 Oct 2010 17:36:51 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAY0033G01DWR@szxga05-in.huawei.com> for ccamp@ietf.org; Wed, 27 Oct 2010 17:36:50 +0800 (CST) Received: from Z41162C ([10.70.76.101]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAY00IJY01CUI@szxml06-in.huawei.com> for ccamp@ietf.org; Wed, 27 Oct 2010 17:36:49 +0800 (CST) Date: Wed, 27 Oct 2010 17:36:47 +0800 From: Fatai Zhang To: Rajan Rao , ccamp@ietf.org Message-id: <02f001cb75ba$79fcd250$654c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_+9DH5c+RKd3Y63G2HMWMSg)" X-Priority: 3 X-MSMail-priority: Normal References: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D99@SV-EXDB1.infinera.com> Cc: Khuzema Pithewan , Mohit Misra Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2010 09:51:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+9DH5c+RKd3Y63G2HMWMSg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Rajan, Happy to see your draft, but except multi-stage muxing supported in your draft, I don't see any substantial difference between your draft and [draft-zhang-ccamp-gmpls-evolving-g709-06.txt]. You may say that TPN info is incorporated into label Object, but you know it is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and we already stated that in the slides for IETF78th meeting (just make the door open at this moment). In addtion, for multi-stage muxing, I really suspect that it can be resolved so easily, be because it is MLN stuff and it needs to indicate how to create the infrastructure FA. If it can be done in this way as your draft describes, I will be much happy. Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: ccamp@ietf.org Cc: Khuzema Pithewan ; Mohit Misra Sent: Wednesday, October 27, 2010 5:26 AM Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Hi, We have a draft on "GMPLS Signaling extensions for OTN" available for review. It can be accessed from the following link: http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt The above draft is not on IETF repository as we missed the submission deadline. We will submit to IETF as soon as possible. Please review and comment. Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in this document caters to ODU layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document. Thanks Authors ------------------------------------------------------------------------------ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --Boundary_(ID_+9DH5c+RKd3Y63G2HMWMSg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4ID0gDQoidXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnAgPSANCiJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpwb3dlcnBvaW50IiB4bWxuczphID0gDQoidXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6YWNjZXNzIiB4bWxuczpkdCA9IA0KInV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzID0gDQoidXVpZDpCREM2RTNGMC02REEz LTExZDEtQTJBMy0wMEFBMDBDMTQ4ODIiIHhtbG5zOnJzID0gDQoidXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpyb3dzZXQiIHhtbG5zOnogPSAiI1Jvd3NldFNjaGVtYSIgeG1sbnM6YiA9IA0KInVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnB1Ymxpc2hlciIgeG1sbnM6c3MgPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6YyA9IA0K InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmNvbXBvbmVudDpzcHJlYWRzaGVldCIg eG1sbnM6b2RjID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2RjIiB4bWxu czpvYSA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24iIHht bG5zOmh0bWwgPSANCiJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxuczpxID0g DQoiaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnJ0YyA9 IA0KImh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIFhNTE5TOkQg PSAiREFWOiIgWE1MTlM6UmVwbCA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVw bC8iIHhtbG5zOm10ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50 L3NvYXAvbWVldGluZ3MvIiB4bWxuczp4MiA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlL2V4Y2VsLzIwMDMveG1sIiB4bWxuczpwcGRhID0gDQoiaHR0cDovL3d3dy5wYXNz cG9ydC5jb20vTmFtZVNwYWNlLnhzZCIgeG1sbnM6b2lzID0gDQoiaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvZGlyZWN0b3J5LyIgeG1sbnM6ZHMg PSANCiJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3AgPSANCiJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGMgPSAN CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjIiB4bWxuczp4c2QgPSANCiJo dHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8xL2FsZXJ0cy8iIHhtbG5z OmVjID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIiB4bWxuczpzcCA9IA0K Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcyA9IA0K Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1sbnM6eHNp ID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnVk Y3MgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5z OnVkY3hmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxmaWxl IiB4bWxuczp1ZGNwMnAgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRj L3BhcnR0b3BhcnQiIHhtbG5zOndmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9z aGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4bWxuczpkc3NzID0gDQoiaHR0cDovL3NjaGVtYXMu bWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2kgPSANCiJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2RpZ3NpZyIgeG1sbnM6bWRz c2kgPSANCiJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L2Rp Z2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyID0gDQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZv cm1hdHMub3JnL21hcmt1cC1jb21wYXRpYmlsaXR5LzIwMDYiIHhtbG5zOm0gPSANCiJodHRwOi8v c2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzID0g DQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9yZWxhdGlv bnNoaXBzIiB4bWxuczpzcHdwID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vc2hhcmVwb2ludC93 ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9leGNoYW5nZS9zZXJ2aWNlcy8yMDA2L3R5cGVzIiB4bWxuczpleDEybSA9IA0KImh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1s bnM6cHB0c2wgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vd2Vi c2VydmljZXMvU2hhcmVQb2ludFBvcnRhbFNlcnZlci9QdWJsaXNoZWRMaW5rc1NlcnZpY2UiIA0K WE1MTlM6WiA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3QgPSAiASI+PEhF QUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNo YXJzZXQ9aXNvLTg4NTktMSI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjI5MTIi IG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBDYWxp YnJpOw0KfQ0KQHBhZ2UgV29yZFNlY3Rpb24xIHtzaXplOiA4LjVpbiAxMS4waW47IG1hcmdpbjog MS4waW4gMS4waW4gMS4waW4gMS4waW47IH0NClAuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEy cHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiDQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwaW4g MGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiINCn0NCkRJVi5N c29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1G QU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiINCn0NCkE6bGluayB7DQoJQ09MT1I6IGJs dWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBw dXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5 DQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURF Q09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KU1BBTi5FbWFp bFN0eWxlMTcgew0KCUNPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJz YW5zLXNlcmlmIjsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NClNQQU4uYXBw bGUtc3R5bGUtc3BhbiB7DQoJbXNvLXN0eWxlLW5hbWU6IGFwcGxlLXN0eWxlLXNwYW4NCn0NCi5N c29DaHBEZWZhdWx0IHsNCgltc28tc3R5bGUtdHlwZTogZXhwb3J0LW9ubHkNCn0NCkRJVi5Xb3Jk U2VjdGlvbjEgew0KCXBhZ2U6IFdvcmRTZWN0aW9uMQ0KfQ0KPC9TVFlMRT4NCjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9EWSBs YW5nPUVOLVVTIHZMaW5rPXB1cnBsZSBsaW5rPWJsdWUgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPkhpIFJhamFuLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SGFwcHkgdG8g c2VlIHlvdXIgZHJhZnQsIGJ1dCBleGNlcHQgbXVsdGktc3RhZ2UgbXV4aW5nIA0Kc3VwcG9ydGVk IGluIHlvdXIgZHJhZnQsJm5ic3A7IEkgZG9uJ3Qgc2VlJm5ic3A7YW55IHN1YnN0YW50aWFsIGRp ZmZlcmVuY2UgDQpiZXR3ZWVuIHlvdXIgZHJhZnQgYW5kIA0KW2RyYWZ0LXpoYW5nLWNjYW1wLWdt cGxzLWV2b2x2aW5nLWc3MDktMDYudHh0XS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPllvdSBtYXkgc2F5IHRoYXQgVFBOIGluZm8gaXMgaW5j b3Jwb3JhdGVkIGludG8gbGFiZWwgDQpPYmplY3QsIGJ1dCB5b3Uga25vdyBpdCBpcyBlYXN5IGZv ciANCltkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1ldm9sdmluZy1nNzA5LTA2LnR4dF0gdG8gZG8g dGhhdCBhbmQgd2UgYWxyZWFkeSBzdGF0ZWQgDQp0aGF0IGluIHRoZSBzbGlkZXMgZm9yIElFVEY3 OHRoIG1lZXRpbmcgKGp1c3QgbWFrZSB0aGUgZG9vciBvcGVuIGF0IHRoaXMgDQptb21lbnQpLjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWw+SW4gYWRkdGlvbiwgZm9yIG11bHRpLXN0YWdlIG11eGluZywg SSByZWFsbHkgc3VzcGVjdCB0aGF0IA0KaXQgY2FuIGJlIHJlc29sdmVkJm5ic3A7c28gZWFzaWx5 LCBiZSBiZWNhdXNlIGl0IGlzJm5ic3A7TUxOIHN0dWZmIGFuZCBpdCBuZWVkcyANCnRvIGluZGlj YXRlIGhvdyB0byBjcmVhdGUgdGhlIGluZnJhc3RydWN0dXJlIEZBLiBJZiBpdCBjYW4gYmUgZG9u ZSBpbiB0aGlzIHdheSANCmFzIHlvdXIgZHJhZnQgZGVzY3JpYmVzLCBJIHdpbGwgYmUgbXVjaCBo YXBweS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbD48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+PEZPTlQgDQpmYWNl PUFyaWFsPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsPjwv Rk9OVD48Rk9OVCANCmZhY2U9QXJpYWw+PC9GT05UPjxCUj5CZXN0IFJlZ2FyZHM8QlI+Jm5ic3A7 PEJSPkZhdGFpPEJSPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iUEFERElORy1S SUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxF RlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9 IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMy MzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0 bGU9cnJhb0BpbmZpbmVyYS5jb20gaHJlZj0ibWFpbHRvOnJyYW9AaW5maW5lcmEuY29tIj5SYWph biBSYW88L0E+IA0KPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAz MDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWNjYW1wQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86 Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0i Rk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9a3BpdGhld2Fu QGluZmluZXJhLmNvbSANCiAgaHJlZj0ibWFpbHRvOmtwaXRoZXdhbkBpbmZpbmVyYS5jb20iPkto dXplbWEgUGl0aGV3YW48L0E+IDsgPEEgDQogIHRpdGxlPW1taXNyYUBpbmZpbmVyYS5jb20gaHJl Zj0ibWFpbHRvOm1taXNyYUBpbmZpbmVyYS5jb20iPk1vaGl0IE1pc3JhPC9BPiANCiAgPC9ESVY+ DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4g V2VkbmVzZGF5LCBPY3RvYmVyIDI3LCAyMDEwIDU6MjYgDQogIEFNPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gW0NDQU1QXSBT aWduYWxpbmcgZXh0ZW5zaW9ucyBmb3IgDQogIEcuNzA5IC0gZHJhZnQta2h1emVtYS1jY2FtcC1n bXBscy1zaWduYWxpbmctZzcwOS0wMC50eHQ8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxE SVYgY2xhc3M9V29yZFNlY3Rpb24xPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+ SGksPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQog IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlm JyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQ QU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5z LXNlcmlmJyI+V2UgaGF2ZSBhIGRyYWZ0IG9uIA0KICCTR01QTFMgU2lnbmFsaW5nIGV4dGVuc2lv bnMgZm9yIE9UTpQgYXZhaWxhYmxlIGZvciByZXZpZXcuICZuYnNwO0l0IGNhbiBiZSANCiAgYWNj ZXNzZWQgZnJvbSB0aGUgZm9sbG93aW5nIGxpbms6PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1z by1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+PFNQQU4gDQogIGNsYXNzPWFwcGxlLXN0eWxlLXNw YW4+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwn LCdzYW5zLXNlcmlmJyI+PEEgDQogIGhyZWY9Imh0dHA6Ly93d3cuaW5maW5lcmEuY29tL3JmYy9k cmFmdC1raHV6ZW1hLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5LTAwLnR4dCI+aHR0cDovL3d3 dy5pbmZpbmVyYS5jb20vcmZjL2RyYWZ0LWtodXplbWEtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3 MDktMDAudHh0PC9BPjxvOnA+PC9vOnA+PC9TUEFOPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdB cmlhbCcsJ3NhbnMtc2VyaWYnIj5UaGUgYWJvdmUgZHJhZnQgaXMgDQogIG5vdCBvbiBJRVRGIHJl cG9zaXRvcnkgYXMgd2UgbWlzc2VkIHRoZSBzdWJtaXNzaW9uIGRlYWRsaW5lLiZuYnNwOyBXZSB3 aWxsIA0KICBzdWJtaXQgdG8gSUVURiBhcyBzb29uIGFzIHBvc3NpYmxlLiA8bzpwPjwvbzpwPjwv U1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj48bzpwPiZuYnNwOzwv bzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5QbGVhc2Ug cmV2aWV3IGFuZCANCiAgY29tbWVudC48U1BBTiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxvOnA+ PC9vOnA+PC9TUEFOPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48 U1BBTiANCiAgY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5BYnN0cmFjdDo8bzpw PjwvbzpwPjwvU1BBTj48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0byI+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdz YW5zLXNlcmlmJyI+QXMgT1ROIG5ldHdvcmsgDQogIGNhcGFiaWxpdGllcyBjb250aW51ZSB0byBl dm9sdmUsIHRoZXJlIGlzIGFuIGluY3JlYXNlZCAmbmJzcDtuZWVkIHRvIHN1cHBvcnQgDQogIEdN UExTIGNvbnRyb2wgZm9yIHRoZSBzYW1lLiBbUkZDNDMyOF0gaW50cm9kdWNlZCBHTVBMUyBzaWdu YWxpbmcgZXh0ZW5zaW9ucyANCiAgZm9yIHN1cHBvcnRpbmcgZWFybHkgdmVyc2lvbiBvZiBHLjcw OSBbRy43MDktdjFdLlRoZSBiYXNpYyByb3V0aW5nIA0KICBjb25zaWRlcmF0aW9ucyBmcm9tIHNp Z25hbGluZyBwZXJzcGVjdGl2ZSBpcyBhbHNvIHNwZWNpZmllZCBpbiANCiAgW1JGQzQzMjhdLjxv OnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1z ZXJpZiciPlRoZSByZWNlbnQgcmV2aXNpb24gDQogIG9mIElUVS1UIFJlY29tbWVuZGF0aW9uIEcu NzA5IFtHLjcwOS12M10gYW5kW0dTVVAuNDNdIGhhdmUgaW50cm9kdWNlZCBuZXcgT0RVIA0KICBj b250YWluZXJzIChib3RoIGZpeGVkIGFuZCBmbGV4aWJsZSkgYW5kIGFkZGl0aW9uYWwgT0RVIG11 bHRpcGxleGluZyANCiAgY2FwYWJpbGl0aWVzLCBlbmFibGluZyBzdXBwb3J0IGZvciBvcHRpbWFs IHNlcnZpY2UgDQogIGFnZ3JlZ2F0aW9uLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsIA0KICBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFy Z2luLWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPlRoaXMgZG9jdW1lbnQgDQogIGV4dGVu ZHMgW1JGQzQzMjhdIHRvIHByb3ZpZGUgR01QTFMgc2lnbmFsaW5nIHN1cHBvcnQgZm9yIHRoZSBu ZXcgT1ROIA0KICBjYXBhYmlsaXRpZXMgZGVmaW5lZCBpbiBbRy43MDktdjNdIGFuZCBbR1NVUC40 M10uIFRoZSBzaWduYWxpbmcgZXh0ZW5zaW9ucyANCiAgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1l bnQgY2F0ZXJzIHRvIE9EVSBsYXllciBzd2l0Y2hpbmcgb25seS4gT3B0aWNhbCBDaGFubmVsIA0K ICBMYXllciBzd2l0Y2hpbmcgY29uc2lkZXJhdGlvbnMgaW4gW1JGQzQzMjhdIGFyZSBub3QgbW9k aWZpZWQgaW4gdGhpcyANCiAgZG9jdW1lbnQuPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+VGhhbmtzPG86cD48L286cD48L1NQQU4+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+QXV0aG9yczxvOnA+PC9vOnA+ PC9TUEFOPjwvUD48L0RJVj4NCiAgPFA+DQogIDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Q0NBTVAgbWFpbGluZyANCiAg bGlzdDxCUj5DQ0FNUEBpZXRmLm9yZzxCUj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NjYW1wPEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_+9DH5c+RKd3Y63G2HMWMSg)-- From akunjidhapatham@infinera.com Wed Oct 27 03:56:19 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26CC3A69B8 for ; Wed, 27 Oct 2010 03:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKNRFiSFo-Uc for ; Wed, 27 Oct 2010 03:56:07 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 186143A6820 for ; Wed, 27 Oct 2010 03:56:06 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Wed, 27 Oct 2010 03:57:18 -0700 From: Ashok Kunjidhapatham To: "BELOTTI, SERGIO (SERGIO)" , Fatai Zhang , Rajan Rao Date: Wed, 27 Oct 2010 03:57:14 -0700 Thread-Topic: [CCAMP] R: OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: Act1Bt7KT3oUIIy1TYajB4X112DZMgAAXm/QAC8cx5A= Message-ID: <4434CEA67C942648814B234B57088C2D016CE5EA609B@SV-EXDB1.infinera.com> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4434CEA67C942648814B234B57088C2D016CE5EA609BSVEXDB1infi_" MIME-Version: 1.0 Cc: "Ong, Lyndon" , "ccamp@ietf.org" Subject: Re: [CCAMP] R: OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2010 10:56:19 -0000 --_000_4434CEA67C942648814B234B57088C2D016CE5EA609BSVEXDB1infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sergio, For bundle case, the OPU TS rate of the component link/odu container used f= or encoding Max-Lsp-Bw should be coded in Min-Lsp-Bw. Basically Min-Lsp-Bw= and Max-Lsp-Bw pertain to the same component link. Thanks, Ashok From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= ELOTTI, SERGIO (SERGIO) Sent: Tuesday, October 26, 2010 5:58 PM To: Fatai Zhang; Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: [CCAMP] R: OSPF-TE extensions for G.709 OTN draft submitted: draft= -ashok-ccamp-gmpls-ospf-g709-01 Hi all, we concur with all Fatai pointed out with one more addon : the change in th= e semantic of Minimum LSP BW open also the door to the question of which "N= ominal " OPU Tributary Slot should be chose in case of bundling . Best Regards Sergio and Pietro Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 ________________________________ Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Fat= ai Zhang Inviato: marted=EC 26 ottobre 2010 14.11 A: Rajan Rao; Daniele Ceccarelli Cc: Ong, Lyndon; ccamp@ietf.org Oggetto: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, You said there are three differences between two drafts. Now, we are coming= much closer that there "may" be only one difference (i.e., backward compat= ibility) after Daniele gave some clarifications. Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces = Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backward compat= ibility. Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firs= tly, as Daniele already pointed it out, it is a big issue to advertise tha= t Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C,= however, for Node A(G.709 V1), it must always advertise a meaningful value= for the Max LSP bandwidth. Secondly, You have changed the meaning of "Mini= mum LSP Bandwidth", which will make the path computation messed. Assume OTU= 2 interface that supports ODU2 switching only (an example in your draft), i= n this case, according to the regular routing process, it will make the rou= ting path computation function to understand that it can support ODU0 LSP. = Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. Fourth, it can not differentiate te= rmination and swiching capability for your darft. I am trying to recall more reasons why we need to use a new sub-TLV rather = than the existing TLV, because we had lots of discussion before IETF78th me= eting through mailing list and F2F, but it is a little difficult for me to = dig more things from my memory at this moment, :-)~~~~ Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: Daniele Ceccarelli Cc: Ong, Lyndon ; ccamp@ietf.org Sent: Tuesday, October 26, 2010 7:13 AM Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards = compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue - either support or don= 't support. Based on the WG agreement we could go either way without breaki= ng the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question= . - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where OD= Uflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-B= W. This can be easily accomplished with a sub-TLV for ODUflex signal type i= n our model. BW in bytes/sec, of course. Please refer to attached slides f= or details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This= is exactly the proposal we have in our draft. Good to see that you have mo= ved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ 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 --_000_4434CEA67C942648814B234B57088C2D016CE5EA609BSVEXDB1infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Sergio,

 =

For bundle case, the OPU= TS rate of the component link/odu container used for encoding Max-Lsp-Bw should be = coded in Min-Lsp-Bw. =A0Basically Min-Lsp-Bw and Max-Lsp-Bw pertain to the same component link.

 =

Thanks,

Ashok =

 =

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = BELOTTI, SERGIO (SERGIO)
Sent: Tuesday, October 26, 2010 5:58 PM
To: Fatai Zhang; Rajan Rao
Cc: Ong, Lyndon; ccamp@ietf.org
Subject: [CCAMP] R: OSPF-TE extensions for G.709 OTN draft submitted= : draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi all,

 

we concur with all Fatai pointed out with one more addon : the change in the semantic of Minimum LSP BW open also the door to the question= of which “Nominal “ OPU Tributary Slot should be chose in case of bundling .

 

Best Regards

 

Sergio and Pietro

 

Sergio Belotti

System Architecture
Optics Division-Terrestrial Optics Unit
ALCATEL-LUCENT

+39 039 6863033
+39 039 6863590

Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di = Fatai Zhang
Inviato: marted=EC 26 ottobre 2010 14.11
A: Rajan Rao; Daniele Ceccarelli
Cc: Ong, Lyndon; ccamp@ietf.org
Oggetto: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

You said there are three differences between two drafts. Now, we are coming much closer that there "may" be only one differe= nce (i.e., backward compatibility) after Daniele gave some clarifications.

 

Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backw= ard compatibility.

 

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly, = as Daniele already pointed it out, it is a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C, however, = for Node A(G.709 V1), it must always advertise a meaningful value for the Max LSP bandwidth. Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which will make the path computation mes= sed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular routing process, it will mak= e the routing path computation function to understand that it can support ODU= 0 LSP. Thirdly, it can not support priority flexibility, so it is not efficie= nt from the routing scalability perspective. Fourth, it can not differentiate termination and swiching capability for your darft.

 

I am trying to recall more reasons why we need to use a new sub-TLV rather th= an the existing TLV, because we had lots of discussion before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig mo= re things from my memory at this moment, :-)~~~~

 

 

Best Regards
 
Fatai
 

----- Original Message -----

From: Rajan Rao

Sent: Tuesday, October 26= , 2010 7:13 AM

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Daniele,

 

Please see response inline, within { }. =

 

Thanks

Rajan

 

-----Original Message-----

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; = ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Just a couple of comments on backward compatibility= and bandwidth advertisement.

 

- Backward compatibility: no ODU advertising is def= inded in RFC 4202/4203, so i believe there are no backward compatibility issues.<= o:p>

 

 

[Rajan]  {

Agree there is no ODU advertisement defined. The ne= ed to address backwards compatibility depends on the following:

 

 1) are there RFC-4328 based deployments?=

 2) If so, what do they use for BW advertiseme= nt?

 

Our fair guess is that ISCD is used for this as per= RFC 4202/4203.

 

There are 2 ways to address the compatibility issue – either support or don’t support. Based on the WG agreement we could go either way without breaking the model we have proposed. Please ref= er to attached slides for details.

 

}

 

Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the M= AX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisemen= t, this is a backward compatibility issue in my opinion. It states that:<= /o:p>

 

      "Encoding of Ma= x LSP Bandwidth is as follows:

       Max LSP Bandwi= dth =3D Unreserved-TS-Count x TS-Nominal-Rate"

 

[Rajan]  {

 

The unit here is in Bytes/sec. The description abov= e (& in our draft)

-  = ;  shows that nominal rate is dependent on specific ODU layer in questi= on.

-  = ;  shows how Max LSP bandwidth number is derived at the advertising nod= e.

}

 

Moreover it states:

 

      "If the interfa= ce does not support ODU-flex service,

      this value should be= coded as zero".

 

But advertising max LSP bandwidth =3D 0 means disca= rding such link in the path computation process.

 

[Rajan] {

Good question & very valid. I think you are bri= nging up a scenario where ODUflex is not supported but backward compatibility is required.

 

What we need here is to separate ODUflex advertisem= ent from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course.  Please refer to attached slides for details.

 

}

 

- Bandwidth advertisement: in the -04 version of ou= r draft the bandwidth is advertised as follows:

 

    - Unreserved bandwidth for fixed container in number of containers

    - Unreserved bandwidth for odufl= ex in Bytes/sec

    - Max LSP bandwidth in Bytes/sec= .

 

[Rajan] {

We believe advertising the number of containers is = the right approach. This is exactly the proposal we have in our draft. Good to = see that you have moved away from TS approach which had serious limitations.

 

}

 

Advertising the unreserved bandwidth in number of containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

 

[Rajan] {

 

 The ODUflex uses bytes/sec in our draft. = ; There is no disagreement here.

 

}

BR

 

The authors

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: venerd=EC 15 ottobre 2010 19.13

To: Ong, Lyndon; ccamp@ietf.org

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Lyndon,

 

Yes, we are aware of the existing draft. There are = some fundamental differences in the model we have proposed from the existing dra= ft. The key differences are the following:

 

1) This draft extends existing ISCD  Vs. defin= ing a new one

    - addresses backward compatibili= ty issues (RFC 4202)

 

2) ODU containers are advertised instead of #TSs

     - simple path computation<= o:p>

 

3) Path computing node doesn't need to know per lin= k and/or per ODU layer TS granularity

     - again, simple & stra= ight forward path computation 

 

Thanks

Rajan

 

-----Original Message-----

From: Ong, Lyndon [mailto:Lyong@Ciena.com]

Sent: Thursday, October 14, 2010 7:45 AM=

To: Rajan Rao; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It would be helpful to understand if your draft is asking for similar extensions or different functionality.

 

Thanks,

 

Lyndon

 

 

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: Wednesday, October 13, 2010 2:40 PM

To: ccamp@ietf.org

Subject: [CCAMP] OSPF-TE extensions for G.709 OTN d= raft submitted:

draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi,

 

The following draft has been submitted. Please revi= ew. Comments are appreciated.

 

https://datatracker.ietf.org/doc/draft-ashok-ccamp-= gmpls-ospf-g709/

 

thanks

Authors

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]

Sent: Wednesday, October 13, 2010 2:30 PM

To: Rajan Rao

Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan

Subject: New Version Notification for

draft-ashok-ccamp-gmpls-ospf-g709-01

 

 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been

successfully submitted by Rajan Rao and posted to t= he IETF repository.

 

Filename:   draft-ashok-ccamp-gmpls-ospf-= g709

Revision:   01

Title:       &nb= sp;    OSPF TE Extensions for Generalized MPLS (GMPLS) Control

of G.709 Optical Transport Networks

Creation_date:    2010-10-12

WG ID:            Independent Submission

Number_of_pages: 20

 

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased

need to support GMPLS control for the same. [RFC432= 8] introduced

GMPLS signaling extensions for supporting the early version of G.709

[G.709-v1]. The basic routing considerations from signaling

perspective is also specified in [RFC4328].

 

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and

[GSUP.43] have introduced new ODU containers (both = fixed and

flexible) and additional ODU multiplexing capabilit= ies, enabling

support for optimal service aggregation. 

 

This document describes OSPF protocol extensions to support

Generalized MPLS (GMPLS) control for routing servic= es over the

standardized OTU/ODU containers in support of ODU b= ased TDM

switching. Routing support for Optical Channel Laye= r switching

(Lambda switching) is not covered in this document.=

 

 

 

 

The IETF Secretariat.

 

 

_______________________________________________

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

--_000_4434CEA67C942648814B234B57088C2D016CE5EA609BSVEXDB1infi_-- From lberger@labn.net Wed Oct 27 14:17:07 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD28E3A67B8 for ; Wed, 27 Oct 2010 14:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_81=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcRnbaN92au0 for ; Wed, 27 Oct 2010 14:17:05 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 7755B3A67B6 for ; Wed, 27 Oct 2010 14:16:56 -0700 (PDT) Received: (qmail 25595 invoked by uid 0); 27 Oct 2010 21:18:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 27 Oct 2010 21:18:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=JgCSNSVVrLfZYO/yki7EEKwNSjxkaadbhFkE+WxMGFuFwsecy877x4O1J/56ZuRmZJfyicXuAts3XIj+ctXwBiRicm/b2h6y0IYvHtOdks+JiH32SKGi8ZREog6Q1cYS; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PBDOP-0004jk-Oj; Wed, 27 Oct 2010 15:18:45 -0600 Message-ID: <4CC8973B.4050105@labn.net> Date: Wed, 27 Oct 2010 17:18:51 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] Draft Beijing (IETF 79) agenda posted X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2010 21:17:08 -0000 We have posted the first revision of the CCAMP WG agenda at http://www.ietf.org/proceedings/79/agenda/ccamp.htm Some of you may note that we're doing things a little different in this meeting. OTN/G.709 has been moved into the first and longer session as this topic now requirements more time than WSON. Presenters: 1. Please verify that you are scheduled (At this point, all requests have been honored). 2. Slides are should be submitted to both the chairs *and* the secretary by the end of Sunday, November 7. (Earlier would be appreciated.) 3. As a reminder, the goal of the presentation is to resolve issues/discussions in order to move the document forward. Presentations should focus on unresolved issues and questions for the WG and *not* provide a tutorial on the draft. (for > -00 versions,a 1 or 2 page intro should be the maximum. -00 versions of a document may contain more background as the draft may still be new to some, but WG attendees are expected to have read the document *before* the presentation.) See you in 13 days! Lou (and Deborah) From zhangfatai@huawei.com Wed Oct 27 18:07:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE31E3A67A6 for ; Wed, 27 Oct 2010 18:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.161 X-Spam-Level: ** X-Spam-Status: No, score=2.161 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, FAKE_REPLY_C=2.012, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y51aFRwH6KX8 for ; Wed, 27 Oct 2010 18:07:20 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 874A83A672F for ; Wed, 27 Oct 2010 18:07:19 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAZ00KAB76ZSA@szxga05-in.huawei.com> for ccamp@ietf.org; Thu, 28 Oct 2010 09:09:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAZ0016076ZIV@szxga05-in.huawei.com> for ccamp@ietf.org; Thu, 28 Oct 2010 09:08:59 +0800 (CST) Received: from Z41162C ([10.70.76.101]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAZ006XX76YPC@szxml06-in.huawei.com> for ccamp@ietf.org; Thu, 28 Oct 2010 09:08:59 +0800 (CST) Date: Thu, 28 Oct 2010 09:08:58 +0800 From: Fatai Zhang To: Rajan Rao , Khuzema Pithewan , Mohit Misra Message-id: <033801cb763c$b354b720$654c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_ZWQjBD/2Qz3stS7hZiK1qQ)" X-Priority: 3 X-MSMail-priority: Normal Cc: ccamp@ietf.org Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 01:07:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ZWQjBD/2Qz3stS7hZiK1qQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Rajan, Happy to see your draft, but except multi-stage muxing supported in your draft, I don't see any substantial difference between your draft and [draft-zhang-ccamp-gmpls-evolving-g709-06.txt]. You may say that TPN info is incorporated into label Object, but you know it is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and we already stated it in the slides for IETF78th meeting ( we just make the door open at this moment and there are some advantages to decouple TPN and Label). In addtion, for multi-stage muxing, I really suspect that it can be resolved so easily, because it is MLN stuff and it needs to indicate how to create the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can be done in this way as your draft describes, we all will be much happy. Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: ccamp@ietf.org Cc: Khuzema Pithewan ; Mohit Misra Sent: Wednesday, October 27, 2010 5:26 AM Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Hi, We have a draft on "GMPLS Signaling extensions for OTN" available for review. It can be accessed from the following link: http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt The above draft is not on IETF repository as we missed the submission deadline. We will submit to IETF as soon as possible. Please review and comment. Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in this document caters to ODU layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document. Thanks Authors ---------------------------------------------------------------------------- _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --Boundary_(ID_ZWQjBD/2Qz3stS7hZiK1qQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4ID0gDQoidXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnAgPSANCiJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpwb3dlcnBvaW50IiB4bWxuczphID0gDQoidXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6YWNjZXNzIiB4bWxuczpkdCA9IA0KInV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzID0gDQoidXVpZDpCREM2RTNGMC02REEz LTExZDEtQTJBMy0wMEFBMDBDMTQ4ODIiIHhtbG5zOnJzID0gDQoidXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpyb3dzZXQiIHhtbG5zOnogPSAiI1Jvd3NldFNjaGVtYSIgeG1sbnM6YiA9IA0KInVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnB1Ymxpc2hlciIgeG1sbnM6c3MgPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6YyA9IA0K InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmNvbXBvbmVudDpzcHJlYWRzaGVldCIg eG1sbnM6b2RjID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2RjIiB4bWxu czpvYSA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24iIHht bG5zOmh0bWwgPSANCiJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxuczpxID0g DQoiaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnJ0YyA9 IA0KImh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIFhNTE5TOkQg PSAiREFWOiIgWE1MTlM6UmVwbCA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVw bC8iIHhtbG5zOm10ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50 L3NvYXAvbWVldGluZ3MvIiB4bWxuczp4MiA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlL2V4Y2VsLzIwMDMveG1sIiB4bWxuczpwcGRhID0gDQoiaHR0cDovL3d3dy5wYXNz cG9ydC5jb20vTmFtZVNwYWNlLnhzZCIgeG1sbnM6b2lzID0gDQoiaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvZGlyZWN0b3J5LyIgeG1sbnM6ZHMg PSANCiJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3AgPSANCiJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGMgPSAN CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjIiB4bWxuczp4c2QgPSANCiJo dHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8xL2FsZXJ0cy8iIHhtbG5z OmVjID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIiB4bWxuczpzcCA9IA0K Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcyA9IA0K Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1sbnM6eHNp ID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnVk Y3MgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5z OnVkY3hmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxmaWxl IiB4bWxuczp1ZGNwMnAgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRj L3BhcnR0b3BhcnQiIHhtbG5zOndmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9z aGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4bWxuczpkc3NzID0gDQoiaHR0cDovL3NjaGVtYXMu bWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2kgPSANCiJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2RpZ3NpZyIgeG1sbnM6bWRz c2kgPSANCiJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L2Rp Z2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyID0gDQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZv cm1hdHMub3JnL21hcmt1cC1jb21wYXRpYmlsaXR5LzIwMDYiIHhtbG5zOm0gPSANCiJodHRwOi8v c2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzID0g DQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9yZWxhdGlv bnNoaXBzIiB4bWxuczpzcHdwID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vc2hhcmVwb2ludC93 ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9leGNoYW5nZS9zZXJ2aWNlcy8yMDA2L3R5cGVzIiB4bWxuczpleDEybSA9IA0KImh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1s bnM6cHB0c2wgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vd2Vi c2VydmljZXMvU2hhcmVQb2ludFBvcnRhbFNlcnZlci9QdWJsaXNoZWRMaW5rc1NlcnZpY2UiIA0K WE1MTlM6WiA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3QgPSAiASI+PEhF QUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNo YXJzZXQ9aXNvLTg4NTktMSI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjI5MTIi IG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBDYWxp YnJpOw0KfQ0KQHBhZ2UgV29yZFNlY3Rpb24xIHtzaXplOiA4LjVpbiAxMS4waW47IG1hcmdpbjog MS4waW4gMS4waW4gMS4waW4gMS4waW47IH0NClAuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEy cHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiDQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwaW4g MGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiINCn0NCkRJVi5N c29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1G QU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiINCn0NCkE6bGluayB7DQoJQ09MT1I6IGJs dWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBw dXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5 DQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURF Q09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KU1BBTi5FbWFp bFN0eWxlMTcgew0KCUNPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJz YW5zLXNlcmlmIjsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NClNQQU4uYXBw bGUtc3R5bGUtc3BhbiB7DQoJbXNvLXN0eWxlLW5hbWU6IGFwcGxlLXN0eWxlLXNwYW4NCn0NCi5N c29DaHBEZWZhdWx0IHsNCgltc28tc3R5bGUtdHlwZTogZXhwb3J0LW9ubHkNCn0NCkRJVi5Xb3Jk U2VjdGlvbjEgew0KCXBhZ2U6IFdvcmRTZWN0aW9uMQ0KfQ0KPC9TVFlMRT4NCjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9EWSBs YW5nPUVOLVVTIHZMaW5rPXB1cnBsZSBsaW5rPWJsdWUgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkhpIFJhamFuLDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWw+SGFwcHkgdG8gc2VlIHlvdXIgZHJhZnQsIGJ1dCBleGNlcHQgbXVsdGkt c3RhZ2UgbXV4aW5nIA0Kc3VwcG9ydGVkIGluIHlvdXIgZHJhZnQsJm5ic3A7IEkgZG9uJ3Qgc2Vl Jm5ic3A7YW55IHN1YnN0YW50aWFsIGRpZmZlcmVuY2UgDQpiZXR3ZWVuIHlvdXIgZHJhZnQgYW5k IA0KW2RyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDktMDYudHh0XS48L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPllvdSBtYXkg c2F5IHRoYXQgVFBOIGluZm8gaXMgaW5jb3Jwb3JhdGVkIGludG8gbGFiZWwgDQpPYmplY3QsIGJ1 dCB5b3Uga25vdyBpdCBpcyBlYXN5IGZvciANCltkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1ldm9s dmluZy1nNzA5LTA2LnR4dF0gdG8gZG8gdGhhdCBhbmQgd2UgYWxyZWFkeSBzdGF0ZWQgDQppdCBp biB0aGUgc2xpZGVzIGZvciBJRVRGNzh0aCBtZWV0aW5nICggd2UganVzdCBtYWtlIHRoZSBkb29y IG9wZW4gYXQgdGhpcyANCm1vbWVudCBhbmQgdGhlcmUgYXJlIHNvbWUgYWR2YW50YWdlcyB0byBk ZWNvdXBsZSBUUE4gYW5kIExhYmVsKS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkluIGFkZHRpb24s IGZvciBtdWx0aS1zdGFnZSBtdXhpbmcsIEkgcmVhbGx5IHN1c3BlY3QgdGhhdCANCml0IGNhbiBi ZSByZXNvbHZlZCZuYnNwO3NvIGVhc2lseSwgYmVjYXVzZSBpdCBpcyZuYnNwO01MTiBzdHVmZiBh bmQgaXQgbmVlZHMgdG8gDQppbmRpY2F0ZSBob3cgdG8gY3JlYXRlIHRoZSBpbmZyYXN0cnVjdHVy ZSBGQS1MU1AgKFNlZSBSRkM0MjA2IGFuZCA0MjA2YmlzKS4gSWYgDQppdCBjYW4gYmUgZG9uZSBp biB0aGlzIHdheSBhcyB5b3VyIGRyYWZ0IGRlc2NyaWJlcywmbmJzcDt3ZSBhbGwgd2lsbCBiZSBt dWNoIA0KaGFwcHkuPC9GT05UPjwvRElWPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFs PjwvRk9OVD48Rk9OVCANCmZhY2U9QXJpYWw+PC9GT05UPjxCUj5CZXN0IFJlZ2FyZHM8QlI+Jm5i c3A7PEJSPkZhdGFpPEJSPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxl PSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4 OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAg PEJMT0NLUVVPVEUgDQogIHN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDog NXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1B UkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIw MzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgICA8RElWIA0KICAg IHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3Ozsg Zm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiA8QSANCiAgICB0aXRsZT1ycmFvQGluZmlu ZXJhLmNvbSBocmVmPSJtYWlsdG86cnJhb0BpbmZpbmVyYS5jb20iPlJhamFuIFJhbzwvQT4gPC9E SVY+DQogICAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwv Qj4gPEEgdGl0bGU9Y2NhbXBAaWV0Zi5vcmcgDQogICAgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYu b3JnIj5jY2FtcEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogICAgPERJViBzdHlsZT0iRk9OVDogOXB0 ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9a3BpdGhld2FuQGluZmluZXJh LmNvbSANCiAgICBocmVmPSJtYWlsdG86a3BpdGhld2FuQGluZmluZXJhLmNvbSI+S2h1emVtYSBQ aXRoZXdhbjwvQT4gOyA8QSANCiAgICB0aXRsZT1tbWlzcmFAaW5maW5lcmEuY29tIGhyZWY9Im1h aWx0bzptbWlzcmFAaW5maW5lcmEuY29tIj5Nb2hpdCBNaXNyYTwvQT4gDQogICAgPC9ESVY+DQog ICAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBX ZWRuZXNkYXksIE9jdG9iZXIgMjcsIDIwMTAgNToyNiANCiAgICBBTTwvRElWPg0KICAgIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gW0NDQU1Q XSBTaWduYWxpbmcgZXh0ZW5zaW9ucyBmb3IgDQogICAgRy43MDkgLSBkcmFmdC1raHV6ZW1hLWNj YW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5LTAwLnR4dDwvRElWPg0KICAgIDxESVY+PEJSPjwvRElW Pg0KICAgIDxESVYgY2xhc3M9V29yZFNlY3Rpb24xPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0FyaWFsJywn c2Fucy1zZXJpZiciPkhpLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdB cmlhbCcsJ3NhbnMtc2VyaWYnIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+V2UgaGF2ZSBhIGRyYWZ0IA0KICAgIG9uIJNH TVBMUyBTaWduYWxpbmcgZXh0ZW5zaW9ucyBmb3IgT1ROlCBhdmFpbGFibGUgZm9yIHJldmlldy4g Jm5ic3A7SXQgY2FuIA0KICAgIGJlIGFjY2Vzc2VkIGZyb20gdGhlIGZvbGxvd2luZyBsaW5rOjxv OnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogICAgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48 U1BBTiANCiAgICBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxTUEFOIA0KICAgIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+PEEgDQogICAg aHJlZj0iaHR0cDovL3d3dy5pbmZpbmVyYS5jb20vcmZjL2RyYWZ0LWtodXplbWEtY2NhbXAtZ21w bHMtc2lnbmFsaW5nLWc3MDktMDAudHh0Ij5odHRwOi8vd3d3LmluZmluZXJhLmNvbS9yZmMvZHJh ZnQta2h1emVtYS1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOS0wMC50eHQ8L0E+PG86cD48L286 cD48L1NQQU4+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYn Ij5UaGUgYWJvdmUgZHJhZnQgDQogICAgaXMgbm90IG9uIElFVEYgcmVwb3NpdG9yeSBhcyB3ZSBt aXNzZWQgdGhlIHN1Ym1pc3Npb24gZGVhZGxpbmUuJm5ic3A7IFdlIA0KICAgIHdpbGwgc3VibWl0 IHRvIElFVEYgYXMgc29vbiBhcyBwb3NzaWJsZS4gPG86cD48L286cD48L1NQQU4+PC9QPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFO PjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5QbGVhc2UgcmV2aWV3 IGFuZCANCiAgICBjb21tZW50LjxTUEFOIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PG86cD48L286 cD48L1NQQU4+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogICAgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48 U1BBTiANCiAgICBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxTUEFOIA0KICAgIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+QWJzdHJhY3Q6 PG86cD48L286cD48L1NQQU4+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQog ICAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0 OiBhdXRvIj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog J0FyaWFsJywnc2Fucy1zZXJpZiciPkFzIE9UTiBuZXR3b3JrIA0KICAgIGNhcGFiaWxpdGllcyBj b250aW51ZSB0byBldm9sdmUsIHRoZXJlIGlzIGFuIGluY3JlYXNlZCAmbmJzcDtuZWVkIHRvIHN1 cHBvcnQgDQogICAgR01QTFMgY29udHJvbCBmb3IgdGhlIHNhbWUuIFtSRkM0MzI4XSBpbnRyb2R1 Y2VkIEdNUExTIHNpZ25hbGluZyBleHRlbnNpb25zIA0KICAgIGZvciBzdXBwb3J0aW5nIGVhcmx5 IHZlcnNpb24gb2YgRy43MDkgW0cuNzA5LXYxXS5UaGUgYmFzaWMgcm91dGluZyANCiAgICBjb25z aWRlcmF0aW9ucyBmcm9tIHNpZ25hbGluZyBwZXJzcGVjdGl2ZSBpcyBhbHNvIHNwZWNpZmllZCBp biANCiAgICBbUkZDNDMyOF0uPG86cD48L286cD48L1NQQU4+PC9QPg0KICAgIDxQIGNsYXNzPU1z b05vcm1hbCANCiAgICBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBtc28tbWFyZ2lu LWJvdHRvbS1hbHQ6IGF1dG8iPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+VGhlIHJlY2VudCANCiAgICByZXZpc2lv biBvZiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjcwOSBbRy43MDktdjNdIGFuZFtHU1VQLjQzXSBo YXZlIA0KICAgIGludHJvZHVjZWQgbmV3IE9EVSBjb250YWluZXJzIChib3RoIGZpeGVkIGFuZCBm bGV4aWJsZSkgYW5kIGFkZGl0aW9uYWwgT0RVIA0KICAgIG11bHRpcGxleGluZyBjYXBhYmlsaXRp ZXMsIGVuYWJsaW5nIHN1cHBvcnQgZm9yIG9wdGltYWwgc2VydmljZSANCiAgICBhZ2dyZWdhdGlv bi48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICAgIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0 byI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdBcmlh bCcsJ3NhbnMtc2VyaWYnIj5UaGlzIGRvY3VtZW50IA0KICAgIGV4dGVuZHMgW1JGQzQzMjhdIHRv IHByb3ZpZGUgR01QTFMgc2lnbmFsaW5nIHN1cHBvcnQgZm9yIHRoZSBuZXcgT1ROIA0KICAgIGNh cGFiaWxpdGllcyBkZWZpbmVkIGluIFtHLjcwOS12M10gYW5kIFtHU1VQLjQzXS4gVGhlIHNpZ25h bGluZyBleHRlbnNpb25zIA0KICAgIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGNhdGVycyB0 byBPRFUgbGF5ZXIgc3dpdGNoaW5nIG9ubHkuIE9wdGljYWwgDQogICAgQ2hhbm5lbCBMYXllciBz d2l0Y2hpbmcgY29uc2lkZXJhdGlvbnMgaW4gW1JGQzQzMjhdIGFyZSBub3QgbW9kaWZpZWQgaW4g dGhpcyANCiAgICBkb2N1bWVudC48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPlRoYW5rczxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5BdXRob3JzPG86cD48 L286cD48L1NQQU4+PC9QPjwvRElWPg0KICAgIDxQPg0KICAgIDxIUj4NCg0KICAgIDxQPjwvUD5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5DQ0FNUCBt YWlsaW5nIA0KICAgIGxpc3Q8QlI+Q0NBTVBAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxCUj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwv Qk9EWT48L0hUTUw+DQo= --Boundary_(ID_ZWQjBD/2Qz3stS7hZiK1qQ)-- From rrao@infinera.com Wed Oct 27 23:16:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC063A682C for ; Wed, 27 Oct 2010 23:16:27 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weLO1QrEklHr for ; Wed, 27 Oct 2010 23:16:06 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id A291C3A67E3 for ; Wed, 27 Oct 2010 23:16:05 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Wed, 27 Oct 2010 23:17:17 -0700 From: Rajan Rao To: Fatai Zhang , Khuzema Pithewan , Mohit Misra , Ashok Kunjidhapatham Date: Wed, 27 Oct 2010 23:17:17 -0700 Thread-Topic: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Thread-Index: Act2PJ7qUZQAI1fyRkGdimt3bI5G6gAKOYBY Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E1DE49@SV-EXDB1.infinera.com> References: <033801cb763c$b354b720$654c460a@china.huawei.com> In-Reply-To: <033801cb763c$b354b720$654c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Biao Lu Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 06:16:27 -0000 Fatai, Please see response inline. thanks Rajan ________________________________________ From: Fatai Zhang [zhangfatai@huawei.com] Sent: Wednesday, October 27, 2010 6:08 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra Cc: ccamp@ietf.org; Zhang, Fatai Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, Happy to see your draft, but except multi-stage muxing supported in your dr= aft, I don't see any substantial difference between your draft and [draft-= zhang-ccamp-gmpls-evolving-g709-06.txt]. [Rajan]{ Multi stage muxing is one of the key drivers for signaling extensions. Any= solution is incomplete without this. The label format proposed is intended= to support G.709-v3 & future OTN extensions. Section 5.2 in draft-ietf-cc= amp-gmpls-g709-framework-03 touches on this aspect!! =20 We see following key differences between the drafts: Our draft addresses - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) } You may say that TPN info is incorporated into label Object, but you know i= t is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and= we already stated it in the slides for IETF78th meeting ( we just make the= door open at this moment and there are some advantages to decouple TPN and= Label). [Rajan]{ The key thing here is the mux layers. The TPN in label object is intended = to address per mux layer case=85. more efficient.=20 I think this should be captured in framework doc (section 3.1.2.1in framewo= rk doc doesn't cover hierarchy aspect clearly).=20 } In addtion, for multi-stage muxing, I really suspect that it can be resolve= d so easily, because it is MLN stuff and it needs to indicate how to create= the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can be done in = this way as your draft describes, we all will be much happy. [Rajan]{ The label structure we have defined is to address muxing levels of G.709. = This is not solving MLN using FA. i.e. it doesn=92t result in creation of F= A automatically. There is no FA involved or intended here (out of scope). P= lease refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-= ccamp-gmpls-ospf-g709/. For example, we need 3 labels to create an ODU0 LSP with following muxing= structure on a given TeLink =20 Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-ODU0 =20 Num-of-mux-stages =3D 3 Stage-1 - Label#1: for ODU2 layer with 8 out of 32 bits set Stage-2 - Label#2: for ODU1 layer with 2 out of 8 bits set Stage-3 - Label#3: for ODU0 layer with 1 out of 2 bits set =20 } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: ccamp@ietf.org Cc: Khuzema Pithewan ; Mohit Misra Sent: Wednesday, October 27, 2010 5:26 AM Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls= -signaling-g709-00.txt Hi, We have a draft on =93GMPLS Signaling extensions for OTN=94 available for r= eview. It can be accessed from the following link: http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt The above draft is not on IETF repository as we missed the submission deadl= ine. We will submit to IETF as soon as possible. Please review and comment. Abstract: As OTN network capabilities continue to evolve, there is an increased need= to support GMPLS control for the same. [RFC4328] introduced GMPLS signalin= g extensions for supporting early version of G.709 [G.709-v1].The basic rou= ting considerations from signaling perspective is also specified in [RFC432= 8]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] h= ave introduced new ODU containers (both fixed and flexible) and additional = ODU multiplexing capabilities, enabling support for optimal service aggrega= tion. This document extends [RFC4328] to provide GMPLS signaling support for the = new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling ext= ensions described in this document caters to ODU layer switching only. Opti= cal Channel Layer switching considerations in [RFC4328] are not modified in= this document. Thanks Authors ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From pietro_vittorio.grandi@alcatel-lucent.com Thu Oct 28 01:29:58 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E063A67F1 for ; Thu, 28 Oct 2010 01:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkmudTZCNNQ5 for ; Thu, 28 Oct 2010 01:29:41 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id B63C33A67AC for ; Thu, 28 Oct 2010 01:29:40 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9S8QQRi029508 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Oct 2010 10:31:13 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 28 Oct 2010 10:30:32 +0200 From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" To: Rajan Rao Date: Thu, 28 Oct 2010 10:30:30 +0200 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: Act1Brf5KGIS065lRrORP3/7GvHAwgAOk0bwABm8JIA= Message-ID: References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D89B562FE4A5B341B18808FB8441CC7C0FEB050EFRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" , Khuzema Pithewan , "Ashok@core3.amsl.com" Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 08:29:58 -0000 --_000_D89B562FE4A5B341B18808FB8441CC7C0FEB050EFRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, some considerations. 1) Draft Ashok states that Max LSP Bandwidth Number of OPU TSs =3D ------------------------- Min LSP Bandwidth This means that the MIN LSP Bandwidth is always set to the nominal size of = 1 TS. So it can have only two values 1.25 and 2.5 Gbit/s. The min LSP bandwidth for IETF should instead provide the minimum switching= capability. (see RFC4202) With the above relationship it seems that a NE that supporting ODU1 and hig= her rate containers and exporting interfaces with TS size =3D 1.25 Gbit/s should always declare= a Min LSP Bandwidth =3D to 1.25Gbit/s that is not corresponding to a supported switching capability. This behavior is absolutely independent from the fact that ODU-flex is supp= orted or not. 2) Snip: "Not clear what the issue is. We have listed 2 approaches in the slides se= nt out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero." We would like first to observe that the ashok draft does not report this sp= ecific behavior. Secondary we would make note that with this approach the MAX-LSP bandwidth in any cas= e should be interpreted differently when the ODU-flex capacity is exhausted. If you think to a bundle link with ODU-flex capacity, then when UDU-flex capacity is available the MAX-LSP bandwidth is used in a certain w= ay whereas when the ODU-flex capacity is exhausted the ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is differ= ent. we do not see a reason that motivates the introduction of this kind of comp= lication in routing. 3) Snip: Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } The original idea for GMPLS has been already discussed in the frame work do= cument draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only reference for requirements that have to be supported. Moreover, as required= by CCAMP chair an example of the difference in efficiency between the orig= inal IETF format and the new format is shown in the draft draft-bccdg-ccamp-gmpls-ospf-agno= stic. 4) Differentiation between termination and switching capabilities is a= requirement contained in the framework document. The differentiation allow= s an operator to engineer freely its network keeping into account capabilities offered by= current technology. Current technology allows switching only a stage at on= ce in the matrix. Of course this can be overcome with very costly muxponder boards that by th= e way could have limitations related to which containers can be terminated = and which can be only adapted and sent to matrix for switching. In general a routing specifi= cation must not force an operator to use costly solutions (multi-stage mult= iplexing) in order to operate the network. As a consequence the routing specification= must provide the means to allow manage the current technology indicating c= learly which are the capabilities of each interface in terms of termination= s and switching. Pietro & Sergio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pietro Vittorio Grandi Terrestrial Optics Unit - System Architecture Alcatel-Lucent Vimercate (Italy) Tel: +39 039 686 4930 Mail: pietro_vittorio.grandi@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's rel= ativity. (A. Einstein) ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: marted=EC 26 ottobre 2010 21.15 To: Fatai Zhang; Daniele Ceccarelli Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Fatai, Please see response inline, within { } Thanks Rajan From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Tuesday, October 26, 2010 5:11 AM To: Rajan Rao; Daniele Ceccarelli Cc: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, You said there are three differences between two drafts. Now, we are coming= much closer that there "may" be only one difference (i.e., backward compat= ibility) after Daniele gave some clarifications. Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces = Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backward compat= ibility. Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firs= tly, as Daniele already pointed it out, it is a big issue to advertise tha= t Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C,= however, for Node A(G.709 V1), it must always advertise a meaningful value= for the Max LSP bandwidth. {Rajan] { Not clear what the issue is. We have listed 2 approaches in the slides sen= t out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero. Please clarify if you have a different case in mind. } Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports OD= U2 switching only (an example in your draft), in this case, according to th= e regular routing process, it will make the routing path computation functi= on to understand that it can support ODU0 LSP. [Rajan] { No, we have not changed the meaning of "Minimum LSP BW". Please elaborate= on what is messed. Following RFC 4202/4201 meaning, the example you have listed works as follo= ws: MinLSP-BW =3D ODU1 ( G.709-v1 supports 2.5G) MaxLSP-BW =3D ODU2 ( Min(unreserved-BW, configured Max LSP size) as per R= FC 4202) If you are computing path for an ODU0 connection, the rule would be Odu0-LSP-BW >=3D MinLSP-BW && <=3D MaxLSP-BW The computation fails for the above. Where is it messed? Please provide a= concrete example. } Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } Fourth, it can not differentiate termination and swiching capability for yo= ur darft. [Rajan] { We do not see a need to advertise this info. We need to understand the use= cases requiring this. Are T/S bits addressing HW limitations? } I am trying to recall more reasons why we need to use a new sub-TLV rather = than the existing TLV, because we had lots of discussion before IETF78th me= eting through mailing list and F2F, but it is a little difficult for me to = dig more things from my memory at this moment, :-)~~~~ [Rajan] { Please list the justifications for changing original GMPLS model. } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: Daniele Ceccarelli Cc: Ong, Lyndon ; ccamp@ietf.org Sent: Tuesday, October 26, 2010 7:13 AM Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards = compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue - either support or don= 't support. Based on the WG agreement we could go either way without breaki= ng the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question= . - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where OD= Uflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-B= W. This can be easily accomplished with a sub-TLV for ODUflex signal type i= n our model. BW in bytes/sec, of course. Please refer to attached slides f= or details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This= is exactly the proposal we have in our draft. Good to see that you have mo= ved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ 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 --_000_D89B562FE4A5B341B18808FB8441CC7C0FEB050EFRMRSSXCHMBSB1d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello all,

 

some considerations.

 

1) Draft Ashok states that

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 =A0Max LSP Bandwidth

 

=A0=A0=A0=A0=A0 Number of OPU TSs =3D =A0=A0=A0= =A0=A0-------------------------

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 =A0=A0Min LSP Bandwidth

 

This means that the MIN LSP Bandwidth is always s= et to the nominal size of 1 TS.

So it can have only two values 1.25 and 2.5 Gbit/= s.

The min LSP bandwidth for IETF should instead pro= vide the minimum switching capability. (see RFC4202)

 

With the above relationship it seems that a NE th= at supporting ODU1 and higher rate containers

and exporting interfaces with TS size =3D 1.25 Gb= it/s should always declare a Min LSP Bandwidth =3D to 1.25Gbit/s

that is not corresponding to a supported switchin= g capability.

 

This behavior is absolutely independent from the = fact that ODU-flex is supported or not.

 

2)      Snip:

 

“Not clear what the issue is.  We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:=

 With  backward compatib= ility option, the ODUflex goes in to a separate sub–TLV within SCCI. If ODU= flex is not supported on a link, this sub-TLV will not be included; i.e, ISCD::M= ax-LSP-BW is not used for ODUflex & doesn’t become zero.”<= /span>

 

We would like first to observe that the ashok dra= ft does not report this specific behavior. Secondary<= /p>

we would make note that with this approach the MAX-LSP bandwidth in any case should be interpreted differently<= /span>

when the ODU-flex capacity is exhausted.

If you think to a bundle link with ODU-flex capac= ity, then when

UDU-flex capacity is available the MAX-LSP bandwi= dth is used in a certain way whereas when the ODU-flex capacity is exhausted th= e

ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is different.

we do not see a reason that motivates the introduction of this kind of complication in routing.

 

3)      Snip:

Thirdly, it can not support priori= ty flexibility, so it is not efficient from the routing scalability perspectiv= e.

[Rajan] {=

The whole idea is to stay with the= GMPLS architecture already in place.  The technology specific extensions sho= uld go into SCSI. This has been done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a reason to deviation from the original G= MPLS model.

}

 

The original idea for GMPLS has been already discussed in the frame work document draft-ietf-ccamp-gmpls-g709-framework-= 03. The framework is the only

reference for requirements that have to be suppor= ted. Moreover, as required by CCAMP chair an example of the difference in effici= ency between the original IETF format

and the new format is shown in the =A0draft draft= -bccdg-ccamp-gmpls-ospf-agnostic. =A0

 

4)      Differentiation= between termination and switching capabilities is a requirement contained in the framework docu= ment. The differentiation allows an operator

to engineer freely its network keeping into accou= nt capabilities offered by current technology. Current technology allows switching only a s= tage at once in the matrix.

Of course this can be overcome with very costly m= uxponder boards that by the way could have limitations related to which containers c= an be terminated and which can be

only adapted and sent to matrix for switching. In general a routing specification must not force an operator to use costly solutions (multi-stage multiplexing)

in order to operate the network. As a consequence= the routing specification must provide the means to allow manage the current te= chnology indicating clearly which are the capabilities of each interface in terms of terminations and switching.

 

Pietro & Sergio

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pietro Vittorio Grandi =
Terrestrial Optics Unit -  System Architecture
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930 <= br> Mail: pietro_vittorio.grandi@alcatel-lucent.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Put your hand on a hot stove for a minute, and it seems = like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

From:= ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao
Sent: marted=EC 26 ottobre 2= 010 21.15
To: Fatai Zhang; Daniele Ceccarelli
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Fatai,

 

Please see response inline, within= { }

 

Thanks

Rajan

 

From:= Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Tuesday, October 26, 2= 010 5:11 AM
To: Rajan Rao; Daniele Cecca= relli
Cc: Ong, Lyndon; ccamp@ietf.= org
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Hi Rajan,

 <= /span>

You said there are three differences between two drafts. Now, we are coming much closer that there "may" be only one difference (i.e., backward compatibility) after Daniele gave some clarifications.

 <= /span>

Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibility, although it seems like that your draft "could" support backward compatibility. =

 <= /span>

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly,  as Daniele already pointed it out, it i= s a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUfl= ex supported for Node B/C, however, for Node A(G.709 V1), it must always adver= tise a meaningful value for the Max LSP bandwidth.

{Rajan] {=

Not clear what the issue is. = We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:

 With  backward compatib= ility option, the ODUflex goes in to a separate sub–TLV within SCCI. If ODU= flex is not supported on a link, this sub-TLV will not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become zero.

 

Please clarify if you have a diffe= rent case in mind.

}

 

Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which will make the path computation mes= sed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular routing process, it will mak= e the routing path computation function to understand that it can support ODU= 0 LSP.

[Rajan] {=

No, we have not changed the meanin= g of “Minimum LSP BW”.   Please elaborate on what is messe= d.   

Following RFC 4202/4201 meaning, t= he example you have listed works as follows:

 

MinLSP-BW =3D ODU1  ( G.709-v= 1 supports 2.5G)

MaxLSP-BW =3D ODU2  ( Min(unreserved-BW, configured Max LSP size)  as per RFC 4202)

 

If you are computing path for an O= DU0 connection, the rule would be

 

Odu0-LSP-BW >=3D MinLSP-BW &= ;& <=3D MaxLSP-BW

 

The computation fails for the abov= e.   Where is it messed? Please provide a concrete example.

}

 

Thirdly, it can not support priority flexibility,= so it is not efficient from the routing scalability perspective.

[Rajan] {=

The whole idea is to stay with the= GMPLS architecture already in place.  The technology specific extensions sho= uld go into SCSI. This has been done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a reason to deviation from the original G= MPLS model.

}

 

Fourth, it can not differentiate termination and swiching capability for your darft.

 [Rajan] {=

We do not see a need to advertise = this info.  We need to understand the use cases requiring this.  Are T= /S bits addressing HW limitations?

}

 

I am trying to recall more reasons why we need to= use a new sub-TLV rather than the existing TLV, because we had lots of discussi= on before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig more things from my memory at this moment, :-)~~~~<= /span>

 [Rajan] {

Please list the justifications for changing original GMPLS model.

}

Best Regards
 
Fatai
 

----- Original Message -----

Sent:<= /font> Tuesday, October 26, 2010 7:13 AM

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 <= /span>

Daniele,

 

Please see response inline, within { }.

 

Thanks

Rajan

 

-----Original Message-----

From: Daniele Ceccarelli [mailto:daniele.ceccare= lli@ericsson.com]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Just a couple of comments on backward compatibil= ity and bandwidth advertisement.

 

- Backward compatibility: no ODU advertising is definded in RFC 4202/4203, so i believe there are no backward compatibility issues.

 

 

[Rajan]  {

Agree there is no ODU advertisement defined. The= need to address backwards compatibility depends on the following:

 

 1) are there RFC-4328 based deployments?

 2) If so, what do they use for BW advertis= ement?

 

Our fair guess is that ISCD is used for this as = per RFC 4202/4203.

 

There are 2 ways to address the compatibility is= sue – either support or don’t support. Based on the WG agreement we could go either way without breaking the model we have proposed. Please ref= er to attached slides for details.

 

}

 

Moreover in draft-ashok-ccamp-gmpls-ospf-g709 th= e MAX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisement, this is a backward compatibility issue in my opinion. It sta= tes that:

 

      "Encoding of= Max LSP Bandwidth is as follows:

       Max LSP Ban= dwidth =3D Unreserved-TS-Count x TS-Nominal-Rate"

 

[Rajan]  {

 

The unit here is in Bytes/sec. The description a= bove (& in our draft)

-    shows that nominal rate is dependent on specific ODU layer in question.

-    shows how Max LSP bandwidth number is derived at the advertisi= ng node.

}

 

Moreover it states:

 

      "If the inte= rface does not support ODU-flex service,

      this value should= be coded as zero".

 

But advertising max LSP bandwidth =3D 0 means di= scarding such link in the path computation process.

 

[Rajan] {

Good question & very valid. I think you are bringing up a scenario where ODUflex is not supported but backward compatibility is required.

 

What we need here is to separate ODUflex adverti= sement from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course.  Please refer to attached slides for details.

 

}

 

- Bandwidth advertisement: in the -04 version of= our draft the bandwidth is advertised as follows:

 

    - Unreserved bandwidth for fi= xed container in number of containers

    - Unreserved bandwidth for od= uflex in Bytes/sec

    - Max LSP bandwidth in Bytes/= sec.

 

[Rajan] {

We believe advertising the number of containers = is the right approach. This is exactly the proposal we have in our draft. Good to = see that you have moved away from TS approach which had serious limitations.

 

}

 

Advertising the unreserved bandwidth in number o= f containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

 

[Rajan] {

 

 The ODUflex uses bytes/sec in our draft.&n= bsp; There is no disagreement here.

 

}

BR

 

The authors

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounc= es@ietf.org] On Behalf Of Rajan Rao

Sent: venerd=EC 15 ottobre 2010 19.13=

To: Ong, Lyndon; ccamp@ietf.org

Subject: Re: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Lyndon,

 

Yes, we are aware of the existing draft. There a= re some fundamental differences in the model we have proposed from the existin= g draft. The key differences are the following:

 

1) This draft extends existing ISCD  Vs. de= fining a new one

    - addresses backward compatib= ility issues (RFC 4202)

 

2) ODU containers are advertised instead of #TSs=

     - simple path computati= on

 

3) Path computing node doesn't need to know per = link and/or per ODU layer TS granularity

     - again, simple & straight forward path computation 

 

Thanks

Rajan

 

-----Original Message-----

From: Ong, Lyndon [mailto:Lyong@Ciena.com]<= /o:p>

Sent: Thursday, October 14, 2010 7:45 AM

To: Rajan Rao; ccamp@ietf.org<= /font>

Subject: RE: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It would be helpful to understand if your draft is asking for similar extensions or different func= tionality.

 

Thanks,

 

Lyndon

 

 

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: Wednesday, October 13, 2010 2:40 PM

To: ccamp@ietf.org

Subject: [CCAMP] OSPF-TE extensions for G.709 OT= N draft submitted:

draft-ashok-ccamp-gmpls-ospf-g709-01<= /span>

 

Hi,

 

The following draft has been submitted. Please r= eview. Comments are appreciated.

 

https://datatracker.ietf.org/doc/draft-ashok-cca= mp-gmpls-ospf-g709/

 

thanks

Authors

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]

Sent: Wednesday, October 13, 2010 2:30 PM

To: Rajan Rao

Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuz= ema Pithewan

Subject: New Version Notification for=

draft-ashok-ccamp-gmpls-ospf-g709-01 =

 

 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been<= /p>

successfully submitted by Rajan Rao and posted t= o the IETF repository.

 

Filename:   draft-ashok-ccamp-gmpls-ospf-g709

Revision:   01

Title:       =      OSPF TE Extensions for Generalized MPLS (GMPLS) Control

of G.709 Optical Transport Networks

Creation_date:    2010-10-12=

WG ID:            Independent Submission

Number_of_pages: 20

 

Abstract:

As OTN network capabilities continue to evolve, = there is an increased

need to support GMPLS control for the same. [RFC= 4328] introduced

GMPLS signaling extensions for supporting the ea= rly version of G.709

[G.709-v1]. The basic routing considerations fro= m signaling

perspective is also specified in [RFC4328].=

 

The recent revision of ITU-T Recommendation G.70= 9 [G.709-v3] and

[GSUP.43] have introduced new ODU containers (bo= th fixed and

flexible) and additional ODU multiplexing capabilities, enabling

support for optimal service aggregation.  <= o:p>

 

This document describes OSPF protocol extensions= to support

Generalized MPLS (GMPLS) control for routing ser= vices over the

standardized OTU/ODU containers in support of OD= U based TDM

switching. Routing support for Optical Channel L= ayer switching

(Lambda switching) is not covered in this docume= nt.

 

 

 

 

The IETF Secretariat.

 

 

_______________________________________________<= o:p>

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp=

 

_______________________________________________<= o:p>

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

--_000_D89B562FE4A5B341B18808FB8441CC7C0FEB050EFRMRSSXCHMBSB1d_-- From lberger@labn.net Thu Oct 28 05:24:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB223A6879 for ; Thu, 28 Oct 2010 05:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm63jvSZEuKw for ; Thu, 28 Oct 2010 05:24:20 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 6F02D3A683C for ; Thu, 28 Oct 2010 05:24:20 -0700 (PDT) Received: (qmail 3839 invoked by uid 0); 28 Oct 2010 12:26:12 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 28 Oct 2010 12:26:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=K/9bEf1zuGeiKD7S3WH+17yj9NCo+OFL0NcMBMzHWXtLqRadrTzRFPPOKF/3HbOClQrEjOQ44l6QtZ1wevVl47/uw/AovVqSJpXp6lmH3ODiYgNpu9bsbxW9MbFFk+8F; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PBRYZ-0001y5-QW; Thu, 28 Oct 2010 06:26:12 -0600 Message-ID: <4CC96BEA.1000608@labn.net> Date: Thu, 28 Oct 2010 08:26:18 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Rajan Rao , "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" , Khuzema Pithewan , "Ashok@core3.amsl.com" Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 12:24:22 -0000 Pietro, I have a general comment, not on the specific drafts being discussed: I read your main and am left with the impression that you think that we need not make any attempt to leverage, to the maximum extent possible, what is already present in GMPLS. I don't believe this is the case, nor what the WG has agreed to. As has been said before, by the WG charter, the chairs and others, it is the mandate of CCAMP to developed "common" solutions wherever possible, not technology specific ones. As we covered in Maastrict, see http://www.ietf.org/proceedings/78/slides/ccamp-28/ccamp-28.htm , the WG is still in the earlier stages of defining a GMPLS-based solution for OTN. It seems to me, that this thread is really part of the "how information is to be communicated" discussion identified in slide 3 (of ccamp-28.htm). Such discussions are an important step in the standardization cycle, and it's good that discussions on reuse are underway and continue. But, please keep in mind that once there is agreement on requirements and information to be communicated, we can then decided how to communicate the information and agree on how we "Maximizing reuse of existing mechanisms". Maximizing reuse is an important optimization and generalization step in the CCAMP standardization cycle. (as has been done before for each of technologies supported by GMPLS.) The WG has not yet decided on how existing mechanisms are to be reused and what technology-specific objects are to be introduced. So please don't cut short any discussion on re-use. Much thanks, Lou PS Again, this is not an endorsement of any specific draft or proposal. On 10/28/2010 4:30 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote: > 3) Snip: > > Thirdly, it can not support priority flexibility, so it is not efficient > from the routing scalability perspective. > > [Rajan] { > > The whole idea is to stay with the GMPLS architecture already in place. > The technology specific extensions should go into SCSI. This has been > done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do > not see a reason to deviation from the original GMPLS model. > > } > > The original idea for GMPLS has been already discussed in the frame work > document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only > > reference for requirements that have to be supported. Moreover, as > required by CCAMP chair an example of the difference in efficiency > between the original IETF format > > and the new format is shown in the draft > draft-bccdg-ccamp-gmpls-ospf-agnostic. > From sergio.belotti@alcatel-lucent.com Thu Oct 28 06:01:16 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25203A69C6 for ; Thu, 28 Oct 2010 06:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[AWL=1.480, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVr0wqZPEfUw for ; Thu, 28 Oct 2010 06:01:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 1D4513A6875 for ; Thu, 28 Oct 2010 06:01:14 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9SCw4oh008914 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Oct 2010 15:02:52 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 28 Oct 2010 15:02:24 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Lou Berger Date: Thu, 28 Oct 2010 15:02:23 +0200 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: Act2m1PHEOgX5sMZRMiuuySuIMvmfwAAk3Dw Message-ID: References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> <4CC96BEA.1000608@labn.net> In-Reply-To: <4CC96BEA.1000608@labn.net> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: Rajan Rao , Snigdho, "ccamp@ietf.org" , Bardalai , Khuzema, "Ong, Lyndon" , Pithewan , "Ashok@core3.amsl.com" Subject: [CCAMP] R: OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 13:01:16 -0000 Hi Lou, I can take the action to answer your e-mail since I shared with him the con= tent of Pietro's mail. It seems to me our intention was exactly in the opposite direction of what = you interpreted.=20 We do not touch "how to communicate" but we just referenced requirements an= d information needed to accomplish them.=20 We did not discuss about the format to communicate priority flexibility but= just remind requirement for that and why the need to have it was already d= iscussed and contained in two regular document one dealing with requirement= and the other one related to information to be communicated (not how) .=20 This seems completely in line with the path indicated in the slides your re= ferenced.=20 It was not absolutely in our intention jump directly to " decide on how exi= sting mechanisms are to be reused=20 and what technology-specific objects are to be introduced"=20 On the other hand I think it is correct to highlight when some drafts tryin= g to propose format without taking into account requirement already discuss= ed. Thanks Sergio -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou= Berger Inviato: gioved=EC 28 ottobre 2010 14.26 A: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) Cc: Rajan Rao; ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithe= wan; Ashok@core3.amsl.com Oggetto: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Pietro, I have a general comment, not on the specific drafts being discussed: I=20 read your main and am left with the impression that you think that we=20 need not make any attempt to leverage, to the maximum extent possible,=20 what is already present in GMPLS. I don't believe this is the case, nor=20 what the WG has agreed to. As has been said before, by the WG charter, the chairs and others, it is=20 the mandate of CCAMP to developed "common" solutions wherever possible,=20 not technology specific ones. As we covered in Maastrict, see=20 http://www.ietf.org/proceedings/78/slides/ccamp-28/ccamp-28.htm , the WG=20 is still in the earlier stages of defining a GMPLS-based solution for OTN. It seems to me, that this thread is really part of the "how information=20 is to be communicated" discussion identified in slide 3 (of=20 ccamp-28.htm). Such discussions are an important step in the=20 standardization cycle, and it's good that discussions on reuse are=20 underway and continue. But, please keep in mind that once there is agreement on requirements=20 and information to be communicated, we can then decided how to=20 communicate the information and agree on how we "Maximizing reuse of=20 existing mechanisms". Maximizing reuse is an important optimization and=20 generalization step in the CCAMP standardization cycle. (as has been=20 done before for each of technologies supported by GMPLS.) The WG has not yet decided on how existing mechanisms are to be reused=20 and what technology-specific objects are to be introduced. So please=20 don't cut short any discussion on re-use. Much thanks, Lou PS Again, this is not an endorsement of any specific draft or proposal. On 10/28/2010 4:30 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote: > 3) Snip: > > Thirdly, it can not support priority flexibility, so it is not efficient > from the routing scalability perspective. > > [Rajan] { > > The whole idea is to stay with the GMPLS architecture already in place. > The technology specific extensions should go into SCSI. This has been > done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do > not see a reason to deviation from the original GMPLS model. > > } > > The original idea for GMPLS has been already discussed in the frame work > document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the o= nly > > reference for requirements that have to be supported. Moreover, as > required by CCAMP chair an example of the difference in efficiency > between the original IETF format > > and the new format is shown in the draft > draft-bccdg-ccamp-gmpls-ospf-agnostic. > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From pietro_vittorio.grandi@alcatel-lucent.com Thu Oct 28 06:52:38 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6880E3A6866 for ; Thu, 28 Oct 2010 06:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.805 X-Spam-Level: X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8sFc73X2INk for ; Thu, 28 Oct 2010 06:52:36 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 3BFE83A6868 for ; Thu, 28 Oct 2010 06:52:35 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9SDi4B8024483 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Oct 2010 15:54:16 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 28 Oct 2010 15:53:14 +0200 From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" To: Lou Berger Date: Thu, 28 Oct 2010 15:53:13 +0200 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: Act2m1FWkv4QpEgKS0KUs2bHDo1YJQADBsyA Message-ID: References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> <4CC96BEA.1000608@labn.net> In-Reply-To: <4CC96BEA.1000608@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Rajan Rao , Snigdho, "ccamp@ietf.org" , Bardalai , Khuzema, "Ong, Lyndon" , Pithewan , "Ashok@core3.amsl.com" Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 13:52:38 -0000 Hello Lou, I concur with Sergio's answer. Pietro =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pietro Vittorio Grandi Terrestrial Optics Unit - System Architecture Alcatel-Lucent Vimercate (Italy) Tel: +39 039 686 4930 Mail: pietro_vittorio.grandi@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's rel= ativity. (A. Einstein) -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: gioved=EC 28 ottobre 2010 14.26 To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) Cc: Rajan Rao; ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithe= wan; Ashok@core3.amsl.com Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Pietro, I have a general comment, not on the specific drafts being discussed: I=20 read your main and am left with the impression that you think that we=20 need not make any attempt to leverage, to the maximum extent possible,=20 what is already present in GMPLS. I don't believe this is the case, nor=20 what the WG has agreed to. As has been said before, by the WG charter, the chairs and others, it is=20 the mandate of CCAMP to developed "common" solutions wherever possible,=20 not technology specific ones. As we covered in Maastrict, see=20 http://www.ietf.org/proceedings/78/slides/ccamp-28/ccamp-28.htm , the WG=20 is still in the earlier stages of defining a GMPLS-based solution for OTN. It seems to me, that this thread is really part of the "how information=20 is to be communicated" discussion identified in slide 3 (of=20 ccamp-28.htm). Such discussions are an important step in the=20 standardization cycle, and it's good that discussions on reuse are=20 underway and continue. But, please keep in mind that once there is agreement on requirements=20 and information to be communicated, we can then decided how to=20 communicate the information and agree on how we "Maximizing reuse of=20 existing mechanisms". Maximizing reuse is an important optimization and=20 generalization step in the CCAMP standardization cycle. (as has been=20 done before for each of technologies supported by GMPLS.) The WG has not yet decided on how existing mechanisms are to be reused=20 and what technology-specific objects are to be introduced. So please=20 don't cut short any discussion on re-use. Much thanks, Lou PS Again, this is not an endorsement of any specific draft or proposal. On 10/28/2010 4:30 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote: > 3) Snip: > > Thirdly, it can not support priority flexibility, so it is not efficient > from the routing scalability perspective. > > [Rajan] { > > The whole idea is to stay with the GMPLS architecture already in place. > The technology specific extensions should go into SCSI. This has been > done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do > not see a reason to deviation from the original GMPLS model. > > } > > The original idea for GMPLS has been already discussed in the frame work > document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the o= nly > > reference for requirements that have to be supported. Moreover, as > required by CCAMP chair an example of the difference in efficiency > between the original IETF format > > and the new format is shown in the draft > draft-bccdg-ccamp-gmpls-ospf-agnostic. > From ylee@huawei.com Thu Oct 28 09:48:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70D43A694F for ; Thu, 28 Oct 2010 09:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NRn8fzR7yKo for ; Thu, 28 Oct 2010 09:48:24 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 4DE3A3A6955 for ; Thu, 28 Oct 2010 09:48:24 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB000FZ9ERSIT@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 28 Oct 2010 11:50:16 -0500 (CDT) Received: from L73682 ([10.124.12.96]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB0007MYEROAE@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 28 Oct 2010 11:50:15 -0500 (CDT) Date: Thu, 28 Oct 2010 11:50:12 -0500 From: Young Lee To: 'CCAMP' Message-id: <004901cb76c0$30999100$600c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_FaHv5vXD4YIZlcbZuBRWFw)" Thread-index: Act2wC/yfPfOLbTcTj6N8ONxrL/jVQ== Subject: [CCAMP] Merging of the WSON specific OSPF extensions X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 16:48:29 -0000 This is a multi-part message in MIME format. --Boundary_(ID_FaHv5vXD4YIZlcbZuBRWFw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Pierre, This email is to discuss the pending issues in regard to merging two drafts that discusses WSON specific OSPF extensions: Currently we have one WG draft: http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/. And your individual draft: http://datatracker.ietf.org/doc/draft-peloso-ccamp-wson-ospf-oeo/ We are more than happy to incorporate any new addition from your draft into the aforementioned existing WG draft. Let me summarized the key issues we need to discuss in the following: * I think we agreed on the encoding of the TLV's that are necessary for WSON specific information according to: http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/ * Let me try to understand your rationale to create a new Top Level RBA TLV. Your original rationale for O-E-O TLV (old name for RBA TLV) was to differentiate dynamic information from static. But I don't see your original rationale in your revision. If that is still an implicit rationale, you need to clearly state that. * If so, Fatai's draft clearly state the way to differentiate dynamic info from static info using an Opaque LSA mechanism discussed in Section 4 of http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/. In such as, we don't need to create a new TOP Level TLV. * If not, I am still not sure why we need a new TOP TLV. * Why not just use the Top Level OSPF TE LSA node attribute TLV which is existing TOP level TLV? Please let me know why this TLV would not be proper? * Our approach is to RE-use the OSPF TE LSA node attribute TLV under which we define all the necessary sub-TLVs. * I still have some problem as to why you still have these sub-TLV: Sub-TLV Type Length Name TBD 4 Bytes TE-metric [alike RFC3630] TBD 4 Bytes Administrative Group [alike RFC3630] TBD 8 Bytes Link Local/Remote Identifiers [alike RFC4203] TBD variable Shared Risk Link Group [alike RFC4203] * Section 2.4 is not clear to me. You didn't include sub-TLV in Section 2. Are you saying that connectivity matrix is a part of your RBA TLV? How is this connectivity matrix different from the one defined in section 3.5 in http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/ ? Regards, Greg & Young --Boundary_(ID_FaHv5vXD4YIZlcbZuBRWFw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Pierre, =

 

This email is to discuss the = pending issues in regard to merging two drafts that discusses WSON specific OSPF extensions:

 

Currently we have one WG = draft:

http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-con= straint-encode/.

 

And your individual = draft:

http://datatracker.ietf.org/doc/draft-peloso-ccamp-wson-ospf-oeo/

 

We are more than happy to incorporate any new =
addition from your draft into the aforementioned existing WG draft. Let =
me summarized the key issues we need to discuss in the following: =

 

 

  • Let me try to understand your rationale to create a new Top Level RBA = TLV. Your original rationale for O-E-O TLV (old name for RBA TLV) was to differentiate dynamic information from static. But I don’t = see your original rationale in your revision. If that is still an implicit = rationale, you need to clearly state that.

 

 =

    • If not, I am still not sure why we need a new TOP TLV. =

 

      • Why not just use the Top Level OSPF TE LSA node attribute TLV which = is existing TOP level TLV?  Please let me know why this TLV = would not be proper?

 

·         =
Our approach is to RE-use =
the OSPF TE LSA node =
attribute TLV under which we define all the necessary sub-TLVs. =

 
·         =
I still have some problem =
as to why you still have these =
sub-TLV:
 

Sub-TLV = Type       Length     Name

     TBD        4 Bytes    TE-metric [alike RFC3630]

     TBD        4 Bytes    Administrative Group [alike RFC3630]

     TBD        8 Bytes    = Link Local/Remote Identifiers [alike RFC4203]

     TBD        variable   = Shared Risk Link Group [alike RFC4203]

·         =
Section 2.4 =
is not clear to me.  You didn’t include sub-TLV in Section 2. =
 Are you saying that connectivity matrix is a part of your RBA TLV? =
How is this connectivity matrix different from the one defined in =
section 3.5 in http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-con=
straint-encode/ ? 
 
Regards,
Greg & =
Young

 

--Boundary_(ID_FaHv5vXD4YIZlcbZuBRWFw)-- From lberger@labn.net Thu Oct 28 11:41:31 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6653A6888 for ; Thu, 28 Oct 2010 11:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z18ORjrlBeEF for ; Thu, 28 Oct 2010 11:41:30 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 1B6723A6833 for ; Thu, 28 Oct 2010 11:41:30 -0700 (PDT) Received: (qmail 19722 invoked by uid 0); 28 Oct 2010 18:43:22 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 28 Oct 2010 18:43:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=AJeNB/8WV/QrZNf/blsAYR1i9YoFynG1/dxTMR1sWbX5oeEoAqDWS/eLGL3TQCJsT2BAyYwuIvc2PE5llpE8ZH8Np8yDlqFoh5zx2aefCFM2d9AfKOaT2wdJ00pZvMVK; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PBXRa-0003bY-Dd; Thu, 28 Oct 2010 12:43:22 -0600 Message-ID: <4CC9C44D.3060608@labn.net> Date: Thu, 28 Oct 2010 14:43:25 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "BELOTTI, SERGIO (SERGIO)" References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> <4CC96BEA.1000608@labn.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" , Khuzema Pithewan , "Ashok@core3.amsl.com" Subject: Re: [CCAMP] R: OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 18:41:31 -0000 Sergio, I think talking solutions is just fine. I was really reacting to "The framework is the only reference for requirements that have to be supported". It's not clear to me that the framework is (a) fully agreed upon, or (b) that it captures, or should even capture, all CCAMP requirements. It certainly should capture all technology-specific requirements. (Also, if the requirements end-up reading "don't use common mechanisms" then I personally think something is probably broken from a CCAMP perspective.) If you feel a point has been previously covered on the list, you certainly can take advantage of the list archive and point to where the point was discussed. Lou On 10/28/2010 9:02 AM, BELOTTI, SERGIO (SERGIO) wrote: > Hi Lou, > > I can take the action to answer your e-mail since I shared with him the content of Pietro's mail. > It seems to me our intention was exactly in the opposite direction of what you interpreted. > We do not touch "how to communicate" but we just referenced requirements and information needed to accomplish them. > We did not discuss about the format to communicate priority flexibility but just remind requirement for that and why the need to have it was already discussed and contained in two regular document one dealing with requirement and the other one related to information to be communicated (not how) . > This seems completely in line with the path indicated in the slides your referenced. > It was not absolutely in our intention jump directly to " decide on how existing mechanisms are to be reused > and what technology-specific objects are to be introduced" > > On the other hand I think it is correct to highlight when some drafts trying to propose format without taking into account requirement already discussed. > > Thanks > > Sergio > > > > -----Messaggio originale----- > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou Berger > Inviato: giovedì 28 ottobre 2010 14.26 > A: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) > Cc: Rajan Rao; ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com > Oggetto: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 > > Pietro, > > I have a general comment, not on the specific drafts being discussed: I > read your main and am left with the impression that you think that we > need not make any attempt to leverage, to the maximum extent possible, > what is already present in GMPLS. I don't believe this is the case, nor > what the WG has agreed to. > > As has been said before, by the WG charter, the chairs and others, it is > the mandate of CCAMP to developed "common" solutions wherever possible, > not technology specific ones. As we covered in Maastrict, see > http://www.ietf.org/proceedings/78/slides/ccamp-28/ccamp-28.htm , the WG > is still in the earlier stages of defining a GMPLS-based solution for OTN. > > It seems to me, that this thread is really part of the "how information > is to be communicated" discussion identified in slide 3 (of > ccamp-28.htm). Such discussions are an important step in the > standardization cycle, and it's good that discussions on reuse are > underway and continue. > > But, please keep in mind that once there is agreement on requirements > and information to be communicated, we can then decided how to > communicate the information and agree on how we "Maximizing reuse of > existing mechanisms". Maximizing reuse is an important optimization and > generalization step in the CCAMP standardization cycle. (as has been > done before for each of technologies supported by GMPLS.) > > The WG has not yet decided on how existing mechanisms are to be reused > and what technology-specific objects are to be introduced. So please > don't cut short any discussion on re-use. > > Much thanks, > Lou > > PS Again, this is not an endorsement of any specific draft or proposal. > > On 10/28/2010 4:30 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote: >> 3) Snip: >> >> Thirdly, it can not support priority flexibility, so it is not efficient >> from the routing scalability perspective. >> >> [Rajan] { >> >> The whole idea is to stay with the GMPLS architecture already in place. >> The technology specific extensions should go into SCSI. This has been >> done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do >> not see a reason to deviation from the original GMPLS model. >> >> } >> >> The original idea for GMPLS has been already discussed in the frame work >> document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only >> >> reference for requirements that have to be supported. Moreover, as >> required by CCAMP chair an example of the difference in efficiency >> between the original IETF format >> >> and the new format is shown in the draft >> draft-bccdg-ccamp-gmpls-ospf-agnostic. >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From nurit.sprecher@nsn.com Thu Oct 28 12:34:44 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE0E3A685B for ; Thu, 28 Oct 2010 12:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6vrADJ3PnYj for ; Thu, 28 Oct 2010 12:34:41 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id B6FCB3A67F8 for ; Thu, 28 Oct 2010 12:34:40 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9SJaWoK001096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Oct 2010 21:36:32 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9SJaUeo025477 for ; Thu, 28 Oct 2010 21:36:32 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Oct 2010 21:36:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB76D7.6B9C4866" Date: Thu, 28 Oct 2010 21:36:28 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326402D2E254@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-zhang-ccamp-gmpls-evolving-g709-06.txt Thread-Index: Actwu5E85x3kG7/aQhi4bA7AyoQkIwC0PJzQANKJbFA= From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "CCAMP" X-OriginalArrivalTime: 28 Oct 2010 19:36:30.0927 (UTC) FILETIME=[6BD3A5F0:01CB76D7] Cc: "Ouyang, Yong \(NSN - CN/Shanghai\)" , "Clemens, Rainer \(NSN - DE/Munich\)" Subject: [CCAMP] FW: I-D Action:draft-zhang-ccamp-gmpls-evolving-g709-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 19:34:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB76D7.6B9C4866 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB76D7.6B9C4866" ------_=_NextPart_002_01CB76D7.6B9C4866 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Two comments from our side: 1. ODUflex(CBR) is described clause 4 in a way that it could lead to misunderstanding.=20 As an example a client signal rate of 2.5G (+/-20ppm) is used. This could be misunderstood that 2.5G signals will be mapped into an ODUflex(CBR). In common language, 2.5G signals - especially with 20ppm - are STM-16 or STS-48 signals, which really are 2.488 Gbit/s signals and will be mapped into ODU2. To avoid misunderstanding, it might be helpful to clearly state that only signals with a bit rate >2.488Gbit/s will be mapped into ODUflex(CBR). =20 2. Clause 4.1 states at the end that ODUflex(GFP) is for further study because G.709 would need to define the TS allocation. But the definition is already there. ODUflex(GFP) can assume 1 TS up to 80 TS. G.709 Table 7-8 defines the bandwidths. In addition, clause 12.2.5 of G.709 states: The value of Cm should be selected such that the ODUflex signal can be transported over "n" OPUk tributary slots under worst-case conditions (i.e., maximum ODUflex bit rate and minimum HO OPUk bit rates). This is shown more explicit in the tables that follow. But what it essentially means is that the number of occupied tributary slots of an ODUflex(GFP) are and have to be constant over the entire path (even in the case of restoration/protection). The number of necessary TS is calculated out of the tributary slot bandwidth of the smallest HO ODU in the path (i.e. with ODU2 as smallest HO container in the path ODU2 TS bandwidth will determine the number of TS, with ODU3 as smallest HO container in the path it will be ODU3, and with only HO ODU4 it will be ODU4). Said all this, it might be helpful to already take this into account, either by defining 2 different labels for the 2 types of ODUflexes, GFP and CBR, or to reserve a field for the number of TS in the case the ODUflex is an ODUflex(GFP). This new field would not be used in the case of ODUflex(CBR)and/or would indicate that it is an ODUflex(CBR), e.g. by using an invalid value "0" for the number of TS. Best regards, Nurit =20 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org Sent: Thursday, October 21, 2010 3:00 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-zhang-ccamp-gmpls-evolving-g709-06.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 Title : Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control Author(s) : F. Zhang, et al. Filename : draft-zhang-ccamp-gmpls-evolving-g709-06.txt Pages : 21 Date : 2010-10-20 =20 Recent progress in ITU-T Recommendation G.709 standardization has=20 introduced new ODU containers (ODU0, ODU4, ODU2e and ODUflex) and=20 enhanced Optical Transport Networking (OTN) flexibility. Several=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Expires April 2011 =20 =20 =20 =20 =20 [page 1]=20 =20 draft-zhang-ccamp-gmpls-evolving-g709-06.txt =20 =20 =20 =20 October 2010=20 =20 =20 recent documents have proposed ways to modify GMPLS signaling=20 protocols to support these new OTN features. =20 =20 It is important that a single solution is developed for use in GMPLS=20 signaling and routing protocols. This solution must support ODUk=20 multiplexing capabilities, address all of the new features, be=20 acceptable to all equipment vendors, and be extensible considering=20 continued OTN evolution. =20 =20 This document describes the extensions to the Generalized Multi- Protocol Label Switching (GMPLS) signaling to control the evolving=20 Optical Transport Networks (OTN) addressing ODUk multiplexing and new=20 features including ODU0, ODU4, ODU2e and ODUflex. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-evolving-g70 9-06.txt =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_002_01CB76D7.6B9C4866 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Two comments from = our side:

1.  ODUflex(CBR) is described = clause 4 in a way that it could lead to misunderstanding.

As an example a client signal rate of 2.5G (+/-20ppm) is used. This could = be misunderstood that 2.5G signals will be mapped into an ODUflex(CBR). In = common language, 2.5G signals - especially with 20ppm - are STM-16 or STS-48 = signals, which really are 2.488 Gbit/s signals and will be mapped into = ODU2.

To avoid misunderstanding, it might be helpful to clearly state that only = signals with a bit rate >2.488Gbit/s will be mapped into = ODUflex(CBR).

 

2.  Clause 4.1 states at the = end that ODUflex(GFP) is for further study because G.709 would need to define the = TS allocation. But the definition is already there. ODUflex(GFP) can assume = 1 TS up to 80 TS.

G.709 Table 7-8 defines the bandwidths.

In addition, clause 12.2.5 of G.709 states: The value of Cm should be selected such = that the ODUflex signal can be transported over "n" OPUk tributary = slots under worst-case conditions (i.e., maximum ODUflex bit rate and minimum HO = OPUk bit rates). This is shown more explicit in the tables that = follow.

But what it essentially means is that the number of occupied tributary slots = of an ODUflex(GFP) are and have to be constant over the entire path (even in = the case of restoration/protection). The number of necessary TS is calculated out = of the tributary slot bandwidth of the smallest HO ODU in the path (i.e. with = ODU2 as smallest HO container in the path ODU2 TS bandwidth will determine the = number of TS, with ODU3 as smallest HO container in the path it will be ODU3, = and with only HO ODU4 it will be ODU4).

Said all this, it might be helpful to already take this into account, either = by defining 2 different labels for the 2 types of ODUflexes, GFP and CBR, = or to reserve a field for the number of TS in the case the ODUflex is an ODUflex(GFP). This new field would not be used in the case of ODUflex(CBR)and/or would indicate that it is an ODUflex(CBR), e.g. by = using an invalid value "0" for the number of TS.

Best = regards,

Nurit

 

-----Original Message-----

From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext Internet-Drafts@ietf.org

Sent: Thursday, October 21, 2010 3:00 = AM

To: i-d-announce@ietf.org

Subject: I-D = Action:draft-zhang-ccamp-gmpls-evolving-g709-06.txt

 

A New Internet-Draft is available from the = on-line Internet-Drafts directories.

 

      = Title           : Generalized Multi-Protocol Label Switching (GMPLS) Signaling = Extensions for the evolving G.709 Optical Transport Networks Control

      = Author(s)       : F. Zhang, et al.

      = Filename        : draft-zhang-ccamp-gmpls-evolving-g709-06.txt

      Pages =           : 21

      = Date            : 2010-10-20

 

Recent progress in ITU-T Recommendation G.709 standardization has

introduced new ODU containers (ODU0, ODU4, ODU2e = and ODUflex) and

enhanced Optical Transport Networking (OTN) = flexibility. Several

 

 

 

 

<Zhang>

 

 

 

 

 

Expires April 2011

 

 

 

 

 

  [page 1]

 

draft-zhang-ccamp-gmpls-evolving-g709-06.txt

 

 

 

 

October 2010

 

 

recent documents have proposed ways to modify = GMPLS signaling

protocols to support these new OTN = features. 

 

It is important that a single solution is = developed for use in GMPLS

signaling and routing protocols. This solution = must support ODUk

multiplexing capabilities, address all of the = new features, be

acceptable to all equipment vendors, and be = extensible considering

continued OTN evolution. 

 

This document describes the extensions to the = Generalized Multi-

Protocol Label Switching (GMPLS) signaling to = control the evolving

Optical Transport Networks (OTN) addressing ODUk multiplexing and new

features including ODU0, ODU4, ODU2e and = ODUflex.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-zhang-ccam= p-gmpls-evolving-g709-06.txt

 

Internet-Drafts are also available by anonymous = FTP at:

ftp://ftp.ietf.org/internet-drafts/

 

Below is the data which will enable a MIME = compliant mail reader

implementation to automatically retrieve the = ASCII version of the

Internet-Draft.

------_=_NextPart_002_01CB76D7.6B9C4866-- ------_=_NextPart_001_01CB76D7.6B9C4866 Content-Type: application/octet-stream; name="draft-zhang-ccamp-gmpls-evolving-g709-06.URL" Content-Transfer-Encoding: base64 Content-Description: draft-zhang-ccamp-gmpls-evolving-g709-06.URL Content-Disposition: attachment; filename="draft-zhang-ccamp-gmpls-evolving-g709-06.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC16aGFuZy1jY2FtcC1nbXBscy1ldm9sdmluZy1nNzA5LTA2LnR4dA0K ------_=_NextPart_001_01CB76D7.6B9C4866 Content-Type: text/plain; name="ATT2970380.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2970380.txt Content-Disposition: attachment; filename="ATT2970380.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01CB76D7.6B9C4866-- From rrao@infinera.com Thu Oct 28 12:35:24 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0651E3A685B for ; Thu, 28 Oct 2010 12:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdBlAf4Ml6t9 for ; Thu, 28 Oct 2010 12:34:37 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id 544953A67F6 for ; Thu, 28 Oct 2010 12:34:37 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Thu, 28 Oct 2010 12:35:49 -0700 From: Rajan Rao To: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" Date: Thu, 28 Oct 2010 12:35:53 -0700 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switching flags Thread-Index: Act1Brf5KGIS065lRrORP3/7GvHAwgAOk0bwABm8JIAAStCgAA== Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05121@SV-EXDB1.infinera.com> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05121SVEXDB1infine_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" , Khuzema Pithewan , "Ashok@core3.amsl.com" Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switching flags X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 19:35:25 -0000 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05121SVEXDB1infine_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pietro, Starting a separate chain for Termination and Switching flags. These flags= are very confusing and seems H/W centric. We will address your other ques= tions in a separate email. The framework doc has this requirement in section 5.3 & I think this has le= d to T/S flags. "Support for differentiating between link multiplexing capacity and link rate capacity" Our interpretation of the above requirement is as follows. Please correct/e= xpand if this is not the case: 1. A given ODU service can consume full ODUk or an ODUj based on line= rate "k". 2. In case of ODUj, it can be anywhere in the muxing hierarchy depend= ing on the mux layers supported on the link. 3. The routing extensions should allow path computation on Te-links w= ith varying muxing hierarchy. Since we are all agreeing on advertising #ODUs, the above requirement is a= utomatically taken care. This is because, when we advertise ODU0, ODU1, OD= U2 bandwidth for an OTU3 link it does mean that interface is capable of ter= minating ODU3, ODU2 and ODU1. We do not see a need to explicitly convey th= is ("Termination") information in LSAs. Questions: 1. Where is the need to advertise Termination for the above? 2. By advertising #ODUs, we are saying it is switchable & any HO-ODUs= are definitely terminate-able. If so, where is the need to advertise "Swi= tching" flag? Thanks Rajan From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) [mailto:pietro_vittorio.gra= ndi@alcatel-lucent.com] Sent: Thursday, October 28, 2010 1:31 AM To: Rajan Rao Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTORIO (P= IETRO VITTORIO); BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hello all, some considerations. 1) Draft Ashok states that Max LSP Bandwidth Number of OPU TSs =3D ------------------------- Min LSP Bandwidth This means that the MIN LSP Bandwidth is always set to the nominal size of = 1 TS. So it can have only two values 1.25 and 2.5 Gbit/s. The min LSP bandwidth for IETF should instead provide the minimum switching= capability. (see RFC4202) With the above relationship it seems that a NE that supporting ODU1 and hig= her rate containers and exporting interfaces with TS size =3D 1.25 Gbit/s should always declare= a Min LSP Bandwidth =3D to 1.25Gbit/s that is not corresponding to a supported switching capability. This behavior is absolutely independent from the fact that ODU-flex is supp= orted or not. 2) Snip: "Not clear what the issue is. We have listed 2 approaches in the slides se= nt out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero." We would like first to observe that the ashok draft does not report this sp= ecific behavior. Secondary we would make note that with this approach the MAX-LSP bandwidth in any cas= e should be interpreted differently when the ODU-flex capacity is exhausted. If you think to a bundle link with ODU-flex capacity, then when UDU-flex capacity is available the MAX-LSP bandwidth is used in a certain w= ay whereas when the ODU-flex capacity is exhausted the ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is differ= ent. we do not see a reason that motivates the introduction of this kind of comp= lication in routing. 3) Snip: Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } The original idea for GMPLS has been already discussed in the frame work do= cument draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only reference for requirements that have to be supported. Moreover, as required= by CCAMP chair an example of the difference in efficiency between the orig= inal IETF format and the new format is shown in the draft draft-bccdg-ccamp-gmpls-ospf-agno= stic. 4) Differentiation between termination and switching capabilities is a r= equirement contained in the framework document. The differentiation allows = an operator to engineer freely its network keeping into account capabilities offered by= current technology. Current technology allows switching only a stage at on= ce in the matrix. Of course this can be overcome with very costly muxponder boards that by th= e way could have limitations related to which containers can be terminated = and which can be only adapted and sent to matrix for switching. In general a routing specifi= cation must not force an operator to use costly solutions (multi-stage mult= iplexing) in order to operate the network. As a consequence the routing specification= must provide the means to allow manage the current technology indicating c= learly which are the capabilities of each interface in terms of termination= s and switching. Pietro & Sergio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pietro Vittorio Grandi Terrestrial Optics Unit - System Architecture Alcatel-Lucent Vimercate (Italy) Tel: +39 039 686 4930 Mail: pietro_vittorio.grandi@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's rel= ativity. (A. Einstein) ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: marted=EC 26 ottobre 2010 21.15 To: Fatai Zhang; Daniele Ceccarelli Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Fatai, Please see response inline, within { } Thanks Rajan From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Tuesday, October 26, 2010 5:11 AM To: Rajan Rao; Daniele Ceccarelli Cc: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, You said there are three differences between two drafts. Now, we are coming= much closer that there "may" be only one difference (i.e., backward compat= ibility) after Daniele gave some clarifications. Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces = Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backward compat= ibility. Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firs= tly, as Daniele already pointed it out, it is a big issue to advertise tha= t Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C,= however, for Node A(G.709 V1), it must always advertise a meaningful value= for the Max LSP bandwidth. {Rajan] { Not clear what the issue is. We have listed 2 approaches in the slides sen= t out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero. Please clarify if you have a different case in mind. } Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports OD= U2 switching only (an example in your draft), in this case, according to th= e regular routing process, it will make the routing path computation functi= on to understand that it can support ODU0 LSP. [Rajan] { No, we have not changed the meaning of "Minimum LSP BW". Please elaborate= on what is messed. Following RFC 4202/4201 meaning, the example you have listed works as follo= ws: MinLSP-BW =3D ODU1 ( G.709-v1 supports 2.5G) MaxLSP-BW =3D ODU2 ( Min(unreserved-BW, configured Max LSP size) as per R= FC 4202) If you are computing path for an ODU0 connection, the rule would be Odu0-LSP-BW >=3D MinLSP-BW && <=3D MaxLSP-BW The computation fails for the above. Where is it messed? Please provide a= concrete example. } Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } Fourth, it can not differentiate termination and swiching capability for yo= ur darft. [Rajan] { We do not see a need to advertise this info. We need to understand the use= cases requiring this. Are T/S bits addressing HW limitations? } I am trying to recall more reasons why we need to use a new sub-TLV rather = than the existing TLV, because we had lots of discussion before IETF78th me= eting through mailing list and F2F, but it is a little difficult for me to = dig more things from my memory at this moment, :-)~~~~ [Rajan] { Please list the justifications for changing original GMPLS model. } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: Daniele Ceccarelli Cc: Ong, Lyndon ; ccamp@ietf.org Sent: Tuesday, October 26, 2010 7:13 AM Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards = compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue - either support or don= 't support. Based on the WG agreement we could go either way without breaki= ng the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question= . - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where OD= Uflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-B= W. This can be easily accomplished with a sub-TLV for ODUflex signal type i= n our model. BW in bytes/sec, of course. Please refer to attached slides f= or details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This= is exactly the proposal we have in our draft. Good to see that you have mo= ved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ 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 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05121SVEXDB1infine_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Pietro,

 =

Starting a separate chai= n for Termination and Switching flags.=A0 These flags are very confusing and seems H/W ce= ntric. =A0We will address your other questions in a separate email.

 =

The framework doc has th= is requirement in section 5.3 & I think this has led to T/S flags.

“Support for differentiating between link multiplexing capacity and

=A0=A0=A0=A0=A0 link rate capacity”

 

Our interpretation of th= e above requirement is as follows. Please correct/expand if this is not the case:

1.&n= bsp;      A given ODU se= rvice can consume full ODUk or an ODUj based on line rate “k”.

2.&n= bsp;      In case of ODU= j, it can be anywhere in the muxing hierarchy depending on the mux layers support= ed on the link.

3.&n= bsp;      The routing extensions should allow path computation on Te-links with varying muxing hierarchy.

 =

Since we are all agreein= g on advertising #ODUs,=A0 the above requirement is automatically taken care. Th= is is because,=A0 when we advertise ODU0, ODU1, ODU2 bandwidth for an OTU3 link i= t does mean that interface is capable of terminating ODU3, ODU2 and ODU1.=A0 We do= not see a need to explicitly convey this (“Termination”) informatio= n in LSAs.

 =

Questions:

1.       Where is the n= eed to advertise Termination for the above?

2.       By advertising #ODUs, we are saying it is switchable & any HO-ODUs are definitely terminate-able. =A0If so, where is the need to advertise “Switching&#= 8221; flag?

 =

Thanks=

Rajan<= /p>

 =

=A0

 

 =

 =

From: GRANDI, PIETR= O VITTORIO (PIETRO VITTORIO) [mailto:pietro_vittorio.grandi@alcatel-lucent.co= m]
Sent: Thursday, October 28, 2010 1:31 AM
To: Rajan Rao
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTO= RIO (PIETRO VITTORIO); BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hello= all,

=  

some considerations.

=  

1) Dr= aft Ashok states that

=  

 = ;            &n= bsp;            = ;            &n= bsp;          Max LSP Bandwidth

=  

 = ;     Number of OPU TSs =3D      -----------------------= --

=  

 = ;            &n= bsp;            = ;               &nb= sp;        Min LSP Bandwidth

=  

This = means that the MIN LSP Bandwidth is always set to the nominal size of 1 TS.<= /o:p>

So it= can have only two values 1.25 and 2.5 Gbit/s.

The m= in LSP bandwidth for IETF should instead provide the minimum switching capability. (see RFC4202)

=  

With = the above relationship it seems that a NE that supporting ODU1 and higher rate containers

and e= xporting interfaces with TS size =3D 1.25 Gbit/s should always declare a Min LSP Ban= dwidth =3D to 1.25Gbit/s

that = is not corresponding to a supported switching capability.

=  

This = behavior is absolutely independent from the fact that ODU-flex is supported or not. =

=  

= 2)    Snip:

=  

“Not clear what th= e issue is.  We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:

 With  backwar= d compatibility option, the ODUflex goes in to a separate sub–TLV withi= n SCCI. If ODUflex is not supported on a link, this sub-TLV will not be inclu= ded; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become zero.”

 =

We wo= uld like first to observe that the ashok draft does not report this specific behavio= r. Secondary

we wo= uld make note that with this approach the MAX-LSP bandwidth in any case should be interpreted differently

when = the ODU-flex capacity is exhausted.

If yo= u think to a bundle link with ODU-flex capacity, then when

UDU-f= lex capacity is available the MAX-LSP bandwidth is used in a certain way wherea= s when the ODU-flex capacity is exhausted the

ODU-f= lex TLV is no more advertised and MAX-LSP bandwidth behavior is different.

we do= not see a reason that motivates the introduction of this kind of complication in routing.

=  

3)    Snip:

Thirdly, it can not supp= ort priority flexibility, so it is not efficient from the routing scalability perspective.

[Rajan] {

The whole idea is to sta= y with the GMPLS architecture already in place.  The technology specific extensions should go into SCSI. This has been done successfully for SONET/S= DH case (Ref to examples in RFC 4202). Do not see a reason to deviation from t= he original GMPLS model.

}

 

The o= riginal idea for GMPLS has been already discussed in the frame work document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only

refer= ence for requirements that have to be supported. Moreover, as required by CCAMP chai= r an example of the difference in efficiency between the original IETF format

and t= he new format is shown in the  draft draft-bccdg-ccamp-gmpls-ospf-agnostic.  

=  

= 4)    Differentiation between terminat= ion and switching capabilities is a requirement contained in the framework document. The differentiation allows an operator

to en= gineer freely its network keeping into account capabilities offered by current technology. Current technology allows switching only a stage at once in the matrix.

Of co= urse this can be overcome with very costly muxponder boards that by the way coul= d have limitations related to which containers can be terminated and which can be<= o:p>

only = adapted and sent to matrix for switching. In general a routing specification must n= ot force an operator to use costly solutions (multi-stage multiplexing) <= /o:p>

in or= der to operate the network. As a consequence the routing specification must provid= e the means to allow manage the current technology indicating clearly which a= re the capabilities of each interface in terms of terminations and switching. =

=  

Pietr= o & Sergio

 

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pietro Vi= ttorio Grandi
Terrestri= al Optics Unit -  System Architecture
Alcatel-L= ucent Vimercate (Italy)
Tel: +39 = 039 686 4930
Mail: pietro_vittorio.grandi@alcatel-lucent.com
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Put your = hand on a hot stove for a minute, and it seems like an hour.
Sit with = a pretty girl for an hour, and it seems like a  minute. That's relativit= y.
(A= . Einstein)

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Rajan Rao
Sent: marted=EC 26 ottobre 2010 21.15
To: Fatai Zhang; Daniele Ceccarelli
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Fatai,=

 =

Please see response inli= ne, within { }

 =

Thanks=

Rajan<= /p>

 =

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Tuesday, October 26, 2010 5:11 AM
To: Rajan Rao; Daniele Ceccarelli
Cc: Ong, Lyndon; ccamp@ietf.org
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

You said there are three differences between two drafts. Now, we are coming much closer that there "may" be only one differe= nce (i.e., backward compatibility) after Daniele gave some clarifications.

 

Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backw= ard compatibility.

 

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly, = as Daniele already pointed it out, it is a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C, however, = for Node A(G.709 V1), it must always advertise a meaningful value for the = Max LSP bandwidth.

{Rajan] {

Not clear what the issue is.  We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:

 With  backwar= d compatibility option, the ODUflex goes in to a separate sub–TLV withi= n SCCI. If ODUflex is not supported on a link, this sub-TLV will not be inclu= ded; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become ze= ro.

 =

Please clarify if you ha= ve a different case in mind.

}

 =

Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the r= egular routing process, it will make the routing path computation function to understand that it can support ODU0 LSP.

[Rajan] {

No, we have not changed = the meaning of “Minimum LSP BW”.   Please elaborate on wh= at is messed.   

Following RFC 4202/4201 = meaning, the example you have listed works as follows:

 =

MinLSP-BW =3D = ODU1  ( G.709-v1 supports 2.5G)

MaxLSP-BW =3D = ODU2  ( Min(unreserved-BW, configured Max LSP size)  as per RFC 4202)

 

If you are computing pat= h for an ODU0 connection, the rule would be

 =

Odu0-LSP-BW >=3D MinL= SP-BW && <=3D MaxLSP-BW

 =

The computation fails fo= r the above.   Where is it messed? Please provide a concrete example.

}

 =

Thirdly, it can not support priority flexibility, so it is not efficient from the routing scalability perspective. <= /span>

[Rajan] {

The whole idea is to sta= y with the GMPLS architecture already in place.  The technology specific extensions should go into SCSI. This has been done successfully for SONET/S= DH case (Ref to examples in RFC 4202). Do not see a reason to deviation from t= he original GMPLS model.

}

 =

Fourth, it can not differentiate termination and swiching capability for your darft= .

 [Rajan] {

We do not see a need to advertise this info.  We need to understand the use cases requiring th= is.  Are T/S bits addressing HW limitations?

}

 =

I am trying to recall more reasons why we need to use a new sub-TLV rather th= an the existing TLV, because we had lots of discussion before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig mo= re things from my memory at this moment, :-)~~~~

 [Rajan] {

Please list the justific= ations for changing original GMPLS model.

}

Best Regards
 
Fatai
 

---= -- Original Message -----

From: R= ajan Rao

Cc: Ong, Lyndon ; ccamp@ietf.org <= span lang=3DIT style=3D'font-size:9.0pt;font-family:SimSun'>

= Sent: Tuesday, October 26, 2010 7:1= 3 AM

= Subject: Re: [CCAMP] OSPF-TE extension= s for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01<= /span>

 

Daniele,

 

Please see response inline, within { }. =

 

Thanks

Rajan

 

-----Original Message-----

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; = ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Just a couple of comments on backward compatibility= and bandwidth advertisement.

 

- Backward compatibility: no ODU advertising is def= inded in RFC 4202/4203, so i believe there are no backward compatibility issues.<= o:p>

 

 

[Rajan]  {

Agree there is no ODU advertisement defined. The ne= ed to address backwards compatibility depends on the following:

 

 1) are there RFC-4328 based deployments?=

 2) If so, what do they use for BW advertiseme= nt?

 

Our fair guess is that ISCD is used for this as per= RFC 4202/4203.

 

There are 2 ways to address the compatibility issue – either support or don’t support. Based on the WG agreement we could go either way without breaking the model we have proposed. Please ref= er to attached slides for details.

 

}

 

Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the M= AX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisemen= t, this is a backward compatibility issue in my opinion. It states that:<= /o:p>

 

      "Encoding of Ma= x LSP Bandwidth is as follows:

       Max LSP Bandwi= dth =3D Unreserved-TS-Count x TS-Nominal-Rate"

 

[Rajan]  {

 

The unit here is in Bytes/sec. The description abov= e (& in our draft)

-  = ;  shows that nominal rate is dependent on specific ODU layer in questi= on.

-  = ;  shows how Max LSP bandwidth number is derived at the advertising nod= e.

}

 

Moreover it states:

 

      "If the interfa= ce does not support ODU-flex service,

      this value should be= coded as zero".

 

But advertising max LSP bandwidth =3D 0 means disca= rding such link in the path computation process.

 

[Rajan] {

Good question & very valid. I think you are bri= nging up a scenario where ODUflex is not supported but backward compatibility is required.

 

What we need here is to separate ODUflex advertisem= ent from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course.  Please refer to attached slides for details.

 

}

 

- Bandwidth advertisement: in the -04 version of ou= r draft the bandwidth is advertised as follows:

 

    - Unreserved bandwidth for fixed container in number of containers

    - Unreserved bandwidth for odufl= ex in Bytes/sec

    - Max LSP bandwidth in Bytes/sec= .

 

[Rajan] {

We believe advertising the number of containers is = the right approach. This is exactly the proposal we have in our draft. Good to = see that you have moved away from TS approach which had serious limitations.

 

}

 

Advertising the unreserved bandwidth in number of containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

 

[Rajan] {

 

 The ODUflex uses bytes/sec in our draft. = ; There is no disagreement here.

 

}

BR

 

The authors

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: venerd=EC 15 ottobre 2010 19.13

To: Ong, Lyndon; ccamp@ietf.org

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Lyndon,

 

Yes, we are aware of the existing draft. There are = some fundamental differences in the model we have proposed from the existing dra= ft. The key differences are the following:

 

1) This draft extends existing ISCD  Vs. defin= ing a new one

    - addresses backward compatibili= ty issues (RFC 4202)

 

2) ODU containers are advertised instead of #TSs

     - simple path computation<= o:p>

 

3) Path computing node doesn't need to know per lin= k and/or per ODU layer TS granularity

     - again, simple & stra= ight forward path computation 

 

Thanks

Rajan

 

-----Original Message-----

From: Ong, Lyndon [mailto:Lyong@Ciena.com]

Sent: Thursday, October 14, 2010 7:45 AM=

To: Rajan Rao; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It would be helpful to understand if your draft is asking for similar extensions or different functionality.

 

Thanks,

 

Lyndon

 

 

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: Wednesday, October 13, 2010 2:40 PM

To: ccamp@ietf.org

Subject: [CCAMP] OSPF-TE extensions for G.709 OTN d= raft submitted:

draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi,

 

The following draft has been submitted. Please revi= ew. Comments are appreciated.

 

https://datatracker.ietf.org/doc/draft-ashok-ccamp-= gmpls-ospf-g709/

 

thanks

Authors

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]

Sent: Wednesday, October 13, 2010 2:30 PM

To: Rajan Rao

Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan

Subject: New Version Notification for

draft-ashok-ccamp-gmpls-ospf-g709-01

 

 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been

successfully submitted by Rajan Rao and posted to t= he IETF repository.

 

Filename:   draft-ashok-ccamp-gmpls-ospf-= g709

Revision:   01

Title:       &nb= sp;    OSPF TE Extensions for Generalized MPLS (GMPLS) Control

of G.709 Optical Transport Networks

Creation_date:    2010-10-12

WG ID:            Independent Submission

Number_of_pages: 20

 

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased

need to support GMPLS control for the same. [RFC432= 8] introduced

GMPLS signaling extensions for supporting the early version of G.709

[G.709-v1]. The basic routing considerations from signaling

perspective is also specified in [RFC4328].

 

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and

[GSUP.43] have introduced new ODU containers (both = fixed and

flexible) and additional ODU multiplexing capabilit= ies, enabling

support for optimal service aggregation. 

 

This document describes OSPF protocol extensions to support

Generalized MPLS (GMPLS) control for routing servic= es over the

standardized OTU/ODU containers in support of ODU b= ased TDM

switching. Routing support for Optical Channel Laye= r switching

(Lambda switching) is not covered in this document.=

 

 

 

 

The IETF Secretariat.

 

 

_______________________________________________

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

--_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05121SVEXDB1infine_-- From jdrake@juniper.net Thu Oct 28 14:52:45 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29853A68BB for ; Thu, 28 Oct 2010 14:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.771 X-Spam-Level: X-Spam-Status: No, score=-5.771 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLdNW0vuPx-n for ; Thu, 28 Oct 2010 14:52:25 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id DF10B3A67B3 for ; Thu, 28 Oct 2010 14:52:23 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTMnxBy6/Ur7ESqBWwfsEoupuO7pEuv5X@postini.com; Thu, 28 Oct 2010 14:54:18 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 28 Oct 2010 14:52:11 -0700 From: John E Drake To: Rajan Rao , "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" Date: Thu, 28 Oct 2010 14:53:02 -0700 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switching flags Thread-Index: Act1Brf5KGIS065lRrORP3/7GvHAwgAOk0bwABm8JIAAStCgAAAFhohg Message-ID: <5E893DB832F57341992548CDBB33316398B5110582@EMBX01-HQ.jnpr.net> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05121@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05121@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB33316398B5110582EMBX01HQjnprn_" MIME-Version: 1.0 Cc: Khuzema Pithewan , "Ong, Lyndon" , "ccamp@ietf.org" , Snigdho Bardalai , "Ashok@core3.amsl.com" Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switching flags X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2010 21:52:46 -0000 --_000_5E893DB832F57341992548CDBB33316398B5110582EMBX01HQjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pietro, These fields were not in the predecessor to this I-D, so I am a bit curious= why they were added? With the new bandwidth allocation TLV, I thought we are only advertising t= he client service types available on a given TE link, and not on any of the= underlying hardware details. So in that context, what is the purpose of t= hese fields? E.g., switching is more or less by definition. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Thursday, October 28, 2010 12:36 PM To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switc= hing flags Pietro, Starting a separate chain for Termination and Switching flags. These flags= are very confusing and seems H/W centric. We will address your other ques= tions in a separate email. The framework doc has this requirement in section 5.3 & I think this has le= d to T/S flags. "Support for differentiating between link multiplexing capacity and link rate capacity" Our interpretation of the above requirement is as follows. Please correct/e= xpand if this is not the case: 1. A given ODU service can consume full ODUk or an ODUj based on line= rate "k". 2. In case of ODUj, it can be anywhere in the muxing hierarchy depend= ing on the mux layers supported on the link. 3. The routing extensions should allow path computation on Te-links w= ith varying muxing hierarchy. Since we are all agreeing on advertising #ODUs, the above requirement is a= utomatically taken care. This is because, when we advertise ODU0, ODU1, OD= U2 bandwidth for an OTU3 link it does mean that interface is capable of ter= minating ODU3, ODU2 and ODU1. We do not see a need to explicitly convey th= is ("Termination") information in LSAs. Questions: 1. Where is the need to advertise Termination for the above? 2. By advertising #ODUs, we are saying it is switchable & any HO-ODUs= are definitely terminate-able. If so, where is the need to advertise "Swi= tching" flag? Thanks Rajan From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) [mailto:pietro_vittorio.gra= ndi@alcatel-lucent.com] Sent: Thursday, October 28, 2010 1:31 AM To: Rajan Rao Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTORIO (P= IETRO VITTORIO); BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hello all, some considerations. 1) Draft Ashok states that Max LSP Bandwidth Number of OPU TSs =3D ------------------------- Min LSP Bandwidth This means that the MIN LSP Bandwidth is always set to the nominal size of = 1 TS. So it can have only two values 1.25 and 2.5 Gbit/s. The min LSP bandwidth for IETF should instead provide the minimum switching= capability. (see RFC4202) With the above relationship it seems that a NE that supporting ODU1 and hig= her rate containers and exporting interfaces with TS size =3D 1.25 Gbit/s should always declare= a Min LSP Bandwidth =3D to 1.25Gbit/s that is not corresponding to a supported switching capability. This behavior is absolutely independent from the fact that ODU-flex is supp= orted or not. 2) Snip: "Not clear what the issue is. We have listed 2 approaches in the slides se= nt out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero." We would like first to observe that the ashok draft does not report this sp= ecific behavior. Secondary we would make note that with this approach the MAX-LSP bandwidth in any cas= e should be interpreted differently when the ODU-flex capacity is exhausted. If you think to a bundle link with ODU-flex capacity, then when UDU-flex capacity is available the MAX-LSP bandwidth is used in a certain w= ay whereas when the ODU-flex capacity is exhausted the ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is differ= ent. we do not see a reason that motivates the introduction of this kind of comp= lication in routing. 3) Snip: Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } The original idea for GMPLS has been already discussed in the frame work do= cument draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only reference for requirements that have to be supported. Moreover, as required= by CCAMP chair an example of the difference in efficiency between the orig= inal IETF format and the new format is shown in the draft draft-bccdg-ccamp-gmpls-ospf-agno= stic. 4) Differentiation between termination and switching capabilities is a req= uirement contained in the framework document. The differentiation allows an= operator to engineer freely its network keeping into account capabilities offered by= current technology. Current technology allows switching only a stage at on= ce in the matrix. Of course this can be overcome with very costly muxponder boards that by th= e way could have limitations related to which containers can be terminated = and which can be only adapted and sent to matrix for switching. In general a routing specifi= cation must not force an operator to use costly solutions (multi-stage mult= iplexing) in order to operate the network. As a consequence the routing specification= must provide the means to allow manage the current technology indicating c= learly which are the capabilities of each interface in terms of termination= s and switching. Pietro & Sergio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pietro Vittorio Grandi Terrestrial Optics Unit - System Architecture Alcatel-Lucent Vimercate (Italy) Tel: +39 039 686 4930 Mail: pietro_vittorio.grandi@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's rel= ativity. (A. Einstein) ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: marted=EC 26 ottobre 2010 21.15 To: Fatai Zhang; Daniele Ceccarelli Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Fatai, Please see response inline, within { } Thanks Rajan From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Tuesday, October 26, 2010 5:11 AM To: Rajan Rao; Daniele Ceccarelli Cc: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, You said there are three differences between two drafts. Now, we are coming= much closer that there "may" be only one difference (i.e., backward compat= ibility) after Daniele gave some clarifications. Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces = Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backward compat= ibility. Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firs= tly, as Daniele already pointed it out, it is a big issue to advertise tha= t Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C,= however, for Node A(G.709 V1), it must always advertise a meaningful value= for the Max LSP bandwidth. {Rajan] { Not clear what the issue is. We have listed 2 approaches in the slides sen= t out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero. Please clarify if you have a different case in mind. } Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports OD= U2 switching only (an example in your draft), in this case, according to th= e regular routing process, it will make the routing path computation functi= on to understand that it can support ODU0 LSP. [Rajan] { No, we have not changed the meaning of "Minimum LSP BW". Please elaborate= on what is messed. Following RFC 4202/4201 meaning, the example you have listed works as follo= ws: MinLSP-BW =3D ODU1 ( G.709-v1 supports 2.5G) MaxLSP-BW =3D ODU2 ( Min(unreserved-BW, configured Max LSP size) as per R= FC 4202) If you are computing path for an ODU0 connection, the rule would be Odu0-LSP-BW >=3D MinLSP-BW && <=3D MaxLSP-BW The computation fails for the above. Where is it messed? Please provide a= concrete example. } Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } Fourth, it can not differentiate termination and swiching capability for yo= ur darft. [Rajan] { We do not see a need to advertise this info. We need to understand the use= cases requiring this. Are T/S bits addressing HW limitations? } I am trying to recall more reasons why we need to use a new sub-TLV rather = than the existing TLV, because we had lots of discussion before IETF78th me= eting through mailing list and F2F, but it is a little difficult for me to = dig more things from my memory at this moment, :-)~~~~ [Rajan] { Please list the justifications for changing original GMPLS model. } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: Daniele Ceccarelli Cc: Ong, Lyndon ; ccamp@ietf.org Sent: Tuesday, October 26, 2010 7:13 AM Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards = compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue - either support or don= 't support. Based on the WG agreement we could go either way without breaki= ng the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question= . - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where OD= Uflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-B= W. This can be easily accomplished with a sub-TLV for ODUflex signal type i= n our model. BW in bytes/sec, of course. Please refer to attached slides f= or details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This= is exactly the proposal we have in our draft. Good to see that you have mo= ved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ 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 --_000_5E893DB832F57341992548CDBB33316398B5110582EMBX01HQjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Pietro,

 =

These fields were not in= the predecessor to this I-D, so I am a bit curious why they were added?=A0

 =

With the new bandwidth allocation TLV, I thought we are only advertising =A0the client service typ= es available on a given TE link, and not on any of the underlying hardware det= ails.=A0 So in that context, what is the purpose of these fields? =A0=A0E.g., switch= ing is more or less by definition.

 =

Thanks,

 =

John

 =

Sent from my iPhone=

 =

From: ccamp-bounces= @ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao
Sent: Thursday, October 28, 2010 12:36 PM
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switching flags

 

Pietro,

 =

Starting a separate chai= n for Termination and Switching flags.  These flags are very confusing and seems H/W centric.  We will address your other questions in a separate email.

 =

The framework doc has th= is requirement in section 5.3 & I think this has led to T/S flags.

“Support for differentiating between link multiplexing capacity and

      link rate capacity”

 

Our interpretation of th= e above requirement is as follows. Please correct/expand if this is not the case:

1.&n= bsp;      A given ODU se= rvice can consume full ODUk or an ODUj based on line rate “k”.=

2.&n= bsp;      In case of ODU= j, it can be anywhere in the muxing hierarchy depending on the mux layers support= ed on the link.

3.&n= bsp;      The routing extensions should allow path computation on Te-links with varying muxing hi= erarchy.

 =

Since we are all agreein= g on advertising #ODUs,  the above requirement is automatically taken care. This is because,  when we advertise ODU0, ODU1, ODU2 bandwidth for an = OTU3 link it does mean that interface is capable of terminating ODU3, ODU2 and ODU1.  We do not see a need to explicitly convey this (“Termination”) information in LSAs.

 =

Questions:

1.       Where is the n= eed to advertise Termination for the above?

2.       By advertising #ODUs, we are saying it is switchable & any HO-ODUs are definitely terminate-able.  If so, where is the need to advertise “Switching” flag?

 =

Thanks=

Rajan<= /p>

 =

 

 

 =

 =

From: GRANDI, PIETR= O VITTORIO (PIETRO VITTORIO) [mailto:pietro_vittorio.grandi@alcatel-lucent.co= m]
Sent: Thursday, October 28, 2010 1:31 AM
To: Rajan Rao
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTO= RIO (PIETRO VITTORIO); BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hello= all,

=  

some considerations.

=  

1) Dr= aft Ashok states that

=  

 = ;            &n= bsp;            = ;            &n= bsp;          Max LSP Bandwidth

=  

 = ;     Number of OPU TSs =3D      -----------------------= --

=  

 = ;            &n= bsp;            = ;               &nb= sp;        Min LSP Bandwidth

=  

This = means that the MIN LSP Bandwidth is always set to the nominal size of 1 TS.<= /o:p>

So it= can have only two values 1.25 and 2.5 Gbit/s.

The m= in LSP bandwidth for IETF should instead provide the minimum switching capability. (see RFC4202)

=  

With = the above relationship it seems that a NE that supporting ODU1 and higher rate containers

and e= xporting interfaces with TS size =3D 1.25 Gbit/s should always declare a Min LSP Ban= dwidth =3D to 1.25Gbit/s

that = is not corresponding to a supported switching capability.

=  

This = behavior is absolutely independent from the fact that ODU-flex is supported or not. =

=  

= 2)  Snip:

=  

“Not clear what th= e issue is.  We have listed 2 approaches in the slides sent out yesterday. To = reiterate the case where ODUflex is not supported:

 With  backwar= d compatibility option, the ODUflex goes in to a separate sub–TLV withi= n SCCI. If ODUflex is not supported on a link, this sub-TLV will not be inclu= ded; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become zero.”

 =

We wo= uld like first to observe that the ashok draft does not report this specific behavio= r. Secondary

we wo= uld make note that with this approach the MAX-LSP bandwidth in any case should be interpreted differently

when = the ODU-flex capacity is exhausted.

If yo= u think to a bundle link with ODU-flex capacity, then when

UDU-f= lex capacity is available the MAX-LSP bandwidth is used in a certain way wherea= s when the ODU-flex capacity is exhausted the

ODU-f= lex TLV is no more advertised and MAX-LSP bandwidth behavior is different.

we do= not see a reason that motivates the introduction of this kind of complication in routing.

=  

3)  Snip:

Thirdly, it can not supp= ort priority flexibility, so it is not efficient from the routing scalability p= erspective.

[Rajan] {

The whole idea is to sta= y with the GMPLS architecture already in place.  The technology specific extensions should go into SCSI. This has been done successfully for SONET/S= DH case (Ref to examples in RFC 4202). Do not see a reason to deviation from t= he original GMPLS model.

}

 

The o= riginal idea for GMPLS has been already discussed in the frame work document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only

refer= ence for requirements that have to be supported. Moreover, as required by CCAMP chai= r an example of the difference in efficiency between the original IETF format

and t= he new format is shown in the  draft draft-bccdg-ccamp-gmpls-ospf-agnostic.  

=  

= 4)  Differentiation between terminat= ion and switching capabilities is a requirement contained in the framework document. The differentiation allows an operator

to en= gineer freely its network keeping into account capabilities offered by current technology. Current technology allows switching only a stage at once in the matrix.

Of co= urse this can be overcome with very costly muxponder boards that by the way coul= d have limitations related to which containers can be terminated and which ca= n be

only = adapted and sent to matrix for switching. In general a routing specification must n= ot force an operator to use costly solutions (multi-stage multiplexing) <= /o:p>

in or= der to operate the network. As a consequence the routing specification must provid= e the means to allow manage the current technology indicating clearly which a= re the capabilities of each interface in terms of terminations and switching.

=  

Pietr= o & Sergio

 

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pietro Vi= ttorio Grandi
Terrestri= al Optics Unit -  System Architecture
Alcatel-L= ucent Vimercate (Italy)
Tel: +39 = 039 686 4930
Mail: pietro_vittorio.grandi@alcatel-lucent.com
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Put your = hand on a hot stove for a minute, and it seems like an hour.
Sit with = a pretty girl for an hour, and it seems like a  minute. That's relativit= y.
(A= . Einstein)

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Rajan Rao
Sent: marted=EC 26 ottobre 2010 21.15
To: Fatai Zhang; Daniele Ceccarelli
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Fatai,=

 =

Please see response inli= ne, within { }

 =

Thanks=

Rajan<= /p>

 =

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Tuesday, October 26, 2010 5:11 AM
To: Rajan Rao; Daniele Ceccarelli
Cc: Ong, Lyndon; ccamp@ietf.org
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

You said there are three differences between two drafts. Now, we are coming much closer that there "may" be only one differe= nce (i.e., backward compatibility) after Daniele gave some clarifications.

 

Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backw= ard compatibility.

 

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly, = as Daniele already pointed it out, it is a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C, however, = for Node A(G.709 V1), it must always advertise a meaningful value for the&= nbsp;Max LSP bandwidth.

{Rajan] {

Not clear what the issue is.  We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:

 With  backwar= d compatibility option, the ODUflex goes in to a separate sub–TLV withi= n SCCI. If ODUflex is not supported on a link, this sub-TLV will not be inclu= ded; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become ze= ro.

 =

Please clarify if you ha= ve a different case in mind.

}

 =

Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular routing process, it will make the routing path computation function= to understand that it can support ODU0 LSP.

[Rajan] {

No, we have not changed = the meaning of “Minimum LSP BW”.   Please elaborate on wh= at is messed.   

Following RFC 4202/4201 = meaning, the example you have listed works as follows:

 =

MinLSP-BW =3D = ODU1  ( G.709-v1 supports 2.5G)

MaxLSP-BW =3D = ODU2  ( Min(unreserved-BW, configured Max LSP size)  as per RFC 4202)

 

If you are computing pat= h for an ODU0 connection, the rule would be

 =

Odu0-LSP-BW >=3D MinL= SP-BW && <=3D MaxLSP-BW

 =

The computation fails fo= r the above.   Where is it messed? Please provide a concrete example.

}

 =

Thirdly, it can not support priority flexibility, so it is not efficient from the routing scalability perspective. <= /span>

[Rajan] {

The whole idea is to sta= y with the GMPLS architecture already in place.  The technology specific extensions should go into SCSI. This has been done successfully for SONET/S= DH case (Ref to examples in RFC 4202). Do not see a reason to deviation from t= he original GMPLS model.

}

 =

Fourth, it can not differentiate termination and swiching capability for your darft= .

 [Rajan] {

We do not see a need to advertise this info.  We need to understand the use cases requiring th= is.  Are T/S bits addressing HW limitations?

}

 =

I am trying to recall more reasons why we need to use a new sub-TLV rather th= an the existing TLV, because we had lots of discussion before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig mo= re things from my memory at this moment, :-)~~~~

 [Rajan] {

Please list the justific= ations for changing original GMPLS model.

}

Best Regards
 
Fatai
 

---= -- Original Message -----

From: R= ajan Rao

Cc: Ong, Lyndon ; ccamp@ietf.org <= span lang=3DIT style=3D'font-size:9.0pt;font-family:SimSun'>

= Sent: Tuesday, October 26, 2010 7:1= 3 AM

= Subject: Re: [CCAMP] OSPF-TE extension= s for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01<= /span>

 

Daniele,

 

Please see response inline, within { }. =

 

Thanks

Rajan

 

-----Original Message-----

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; = ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Just a couple of comments on backward compatibility= and bandwidth advertisement.

 

- Backward compatibility: no ODU advertising is def= inded in RFC 4202/4203, so i believe there are no backward compatibility issues.

 

 

[Rajan]  {

Agree there is no ODU advertisement defined. The ne= ed to address backwards compatibility depends on the following:

 

 1) are there RFC-4328 based deployments?=

 2) If so, what do they use for BW advertiseme= nt?

 

Our fair guess is that ISCD is used for this as per= RFC 4202/4203.

 

There are 2 ways to address the compatibility issue – either support or don’t support. Based on the WG agreement we could go either way without breaking the model we have proposed. Please ref= er to attached slides for details.

 

}

 

Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the M= AX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisemen= t, this is a backward compatibility issue in my opinion. It states that:<= /o:p>

 

      "Encoding of Ma= x LSP Bandwidth is as follows:

       Max LSP Bandwi= dth =3D Unreserved-TS-Count x TS-Nominal-Rate"

 

[Rajan]  {

 

The unit here is in Bytes/sec. The description abov= e (& in our draft)

-  = ;  shows that nominal rate is dependent on specific ODU layer in questi= on.

-  = ;  shows how Max LSP bandwidth number is derived at the advertising nod= e.

}

 

Moreover it states:

 

      "If the interfa= ce does not support ODU-flex service,

      this value should be= coded as zero".

 

But advertising max LSP bandwidth =3D 0 means disca= rding such link in the path computation process.

 

[Rajan] {

Good question & very valid. I think you are bri= nging up a scenario where ODUflex is not supported but backward compatibility is required.

 

What we need here is to separate ODUflex advertisem= ent from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course.  Please refer to attached slides for details.

 

}

 

- Bandwidth advertisement: in the -04 version of ou= r draft the bandwidth is advertised as follows:

 

    - Unreserved bandwidth for fixed container in number of containers

    - Unreserved bandwidth for odufl= ex in Bytes/sec

    - Max LSP bandwidth in Bytes/sec= .

 

[Rajan] {

We believe advertising the number of containers is = the right approach. This is exactly the proposal we have in our draft. Good to = see that you have moved away from TS approach which had serious limitations.

 

}

 

Advertising the unreserved bandwidth in number of containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

 

[Rajan] {

 

 The ODUflex uses bytes/sec in our draft. = ; There is no disagreement here.

 

}

BR

 

The authors

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: venerd=EC 15 ottobre 2010 19.13

To: Ong, Lyndon; ccamp@ietf.org

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Lyndon,

 

Yes, we are aware of the existing draft. There are = some fundamental differences in the model we have proposed from the existing dra= ft. The key differences are the following:

 

1) This draft extends existing ISCD  Vs. defin= ing a new one

    - addresses backward compatibili= ty issues (RFC 4202)

 

2) ODU containers are advertised instead of #TSs

     - simple path computation<= o:p>

 

3) Path computing node doesn't need to know per lin= k and/or per ODU layer TS granularity

     - again, simple & stra= ight forward path computation 

 

Thanks

Rajan

 

-----Original Message-----

From: Ong, Lyndon [mailto:Lyong@Ciena.com]

Sent: Thursday, October 14, 2010 7:45 AM=

To: Rajan Rao; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It would be helpful to understand if your draft is asking for similar extensions or different functionality.

 

Thanks,

 

Lyndon

 

 

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: Wednesday, October 13, 2010 2:40 PM

To: ccamp@ietf.org

Subject: [CCAMP] OSPF-TE extensions for G.709 OTN d= raft submitted:

draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi,

 

The following draft has been submitted. Please revi= ew. Comments are appreciated.

 

https://datatracker.ietf.org/doc/draft-ashok-ccamp-= gmpls-ospf-g709/

 

thanks

Authors

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]

Sent: Wednesday, October 13, 2010 2:30 PM

To: Rajan Rao

Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan

Subject: New Version Notification for

draft-ashok-ccamp-gmpls-ospf-g709-01

 

 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been

successfully submitted by Rajan Rao and posted to t= he IETF repository.

 

Filename:   draft-ashok-ccamp-gmpls-ospf-= g709

Revision:   01

Title:       &nb= sp;    OSPF TE Extensions for Generalized MPLS (GMPLS) Control

of G.709 Optical Transport Networks

Creation_date:    2010-10-12

WG ID:            Independent Submission

Number_of_pages: 20

 

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased

need to support GMPLS control for the same. [RFC432= 8] introduced

GMPLS signaling extensions for supporting the early version of G.709

[G.709-v1]. The basic routing considerations from signaling

perspective is also specified in [RFC4328].

 

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and

[GSUP.43] have introduced new ODU containers (both = fixed and

flexible) and additional ODU multiplexing capabilit= ies, enabling

support for optimal service aggregation. 

 

This document describes OSPF protocol extensions to support

Generalized MPLS (GMPLS) control for routing servic= es over the

standardized OTU/ODU containers in support of ODU b= ased TDM

switching. Routing support for Optical Channel Laye= r switching

(Lambda switching) is not covered in this document.=

 

 

 

 

The IETF Secretariat.

 

 

_______________________________________________

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

--_000_5E893DB832F57341992548CDBB33316398B5110582EMBX01HQjnprn_-- From rrao@infinera.com Thu Oct 28 17:44:40 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF75D3A67B1 for ; Thu, 28 Oct 2010 17:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQJ99WBp6GH1 for ; Thu, 28 Oct 2010 17:44:21 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 361343A67A3 for ; Thu, 28 Oct 2010 17:44:20 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Thu, 28 Oct 2010 17:45:33 -0700 From: Rajan Rao To: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" Date: Thu, 28 Oct 2010 17:45:11 -0700 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: Act1Brf5KGIS065lRrORP3/7GvHAwgAOk0bwABm8JIAAT13ZYA== Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E051F8@SV-EXDB1.infinera.com> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E051F8SVEXDB1infine_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" , Khuzema Pithewan , Ashok, Daniele Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 00:44:40 -0000 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E051F8SVEXDB1infine_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pietro, et al Please see response inline Thanks Rajan From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) [mailto:pietro_vittorio.gra= ndi@alcatel-lucent.com] Sent: Thursday, October 28, 2010 1:31 AM To: Rajan Rao Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTORIO (P= IETRO VITTORIO); BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hello all, some considerations. 1) Draft Ashok states that Max LSP Bandwidth Number of OPU TSs =3D ------------------------- Min LSP Bandwidth This means that the MIN LSP Bandwidth is always set to the nominal size of = 1 TS. So it can have only two values 1.25 and 2.5 Gbit/s. [Rajan] { Yes. This is correct. But the exact value is nominal rate depending on the= ODU layer involved. } The min LSP bandwidth for IETF should instead provide the minimum switching= capability. (see RFC4202) [Rajan] { We have only 2 TS variants defined for (Switching-Capability=3DTDM && Enc= oding=3DODUk ). Not sure what the comment is about. } With the above relationship it seems that a NE that supporting ODU1 and hig= her rate containers and exporting interfaces with TS size =3D 1.25 Gbit/s should always declare= a Min LSP Bandwidth =3D to 1.25Gbit/s that is not corresponding to a supported switching capability. [Rajan] { This is not true. A link which is G.709-v1 based will advertise Min-LSP-BW= =3D2.5G (ODU1 rate) not 1.25G (ODU0 rate). Please ref to ODU0 example in th= e previous chain. } This behavior is absolutely independent from the fact that ODU-flex is supp= orted or not. 2) Snip: "Not clear what the issue is. We have listed 2 approaches in the slides se= nt out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero." We would like first to observe that the ashok draft does not report this sp= ecific behavior. Secondary we would make note that with this approach the MAX-LSP bandwidth in any cas= e should be interpreted differently when the ODU-flex capacity is exhausted. If you think to a bundle link with ODU-flex capacity, then when UDU-flex capacity is available the MAX-LSP bandwidth is used in a certain w= ay whereas when the ODU-flex capacity is exhausted the ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is differ= ent. we do not see a reason that motivates the introduction of this kind of comp= lication in routing. [Rajan] { The ODUflex confusion may be due to lack of details from us. In the ppt se= nt earlier we mentioned about how to handle backward compatibility & ODUfle= x. The minor modifications are captured in our draft-02 version (section 5= .4.2). Please review and let us know if there are still any issues. http://www.infinera.com/rfc/draft-ashok-ccamp-gmpls-ospf-g709-02.txt } 3) Snip: Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } The original idea for GMPLS has been already discussed in the frame work do= cument draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only reference for requirements that have to be supported. Moreover, as required= by CCAMP chair an example of the difference in efficiency between the orig= inal IETF format and the new format is shown in the draft draft-bccdg-ccamp-gmpls-ospf-agno= stic. [Rajan] { We have shown in our draft that we can take care of OTN extensions in SCSI.= It doesn't make sense to have two ISCDs (ISCD+BA) for the same switching = type (=3DTDM). Unnecessary. } 4) Differentiation between termination and switching capabilities is a r= equirement contained in the framework document. The differentiation allows = an operator to engineer freely its network keeping into account capabilities offered by= current technology. Current technology allows switching only a stage at on= ce in the matrix. Of course this can be overcome with very costly muxponder boards that by th= e way could have limitations related to which containers can be terminated = and which can be only adapted and sent to matrix for switching. In general a routing specifi= cation must not force an operator to use costly solutions (multi-stage mult= iplexing) in order to operate the network. As a consequence the routing specification= must provide the means to allow manage the current technology indicating c= learly which are the capabilities of each interface in terms of termination= s and switching. [Rajan] { Responded in a separate chain on why we do not need T/S flags. } Pietro & Sergio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pietro Vittorio Grandi Terrestrial Optics Unit - System Architecture Alcatel-Lucent Vimercate (Italy) Tel: +39 039 686 4930 Mail: pietro_vittorio.grandi@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's rel= ativity. (A. Einstein) ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: marted=EC 26 ottobre 2010 21.15 To: Fatai Zhang; Daniele Ceccarelli Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Fatai, Please see response inline, within { } Thanks Rajan From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Tuesday, October 26, 2010 5:11 AM To: Rajan Rao; Daniele Ceccarelli Cc: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, You said there are three differences between two drafts. Now, we are coming= much closer that there "may" be only one difference (i.e., backward compat= ibility) after Daniele gave some clarifications. Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces = Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backward compat= ibility. Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firs= tly, as Daniele already pointed it out, it is a big issue to advertise tha= t Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C,= however, for Node A(G.709 V1), it must always advertise a meaningful value= for the Max LSP bandwidth. {Rajan] { Not clear what the issue is. We have listed 2 approaches in the slides sen= t out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero. Please clarify if you have a different case in mind. } Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports OD= U2 switching only (an example in your draft), in this case, according to th= e regular routing process, it will make the routing path computation functi= on to understand that it can support ODU0 LSP. [Rajan] { No, we have not changed the meaning of "Minimum LSP BW". Please elaborate= on what is messed. Following RFC 4202/4201 meaning, the example you have listed works as follo= ws: MinLSP-BW =3D ODU1 ( G.709-v1 supports 2.5G) MaxLSP-BW =3D ODU2 ( Min(unreserved-BW, configured Max LSP size) as per R= FC 4202) If you are computing path for an ODU0 connection, the rule would be Odu0-LSP-BW >=3D MinLSP-BW && <=3D MaxLSP-BW The computation fails for the above. Where is it messed? Please provide a= concrete example. } Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } Fourth, it can not differentiate termination and swiching capability for yo= ur darft. [Rajan] { We do not see a need to advertise this info. We need to understand the use= cases requiring this. Are T/S bits addressing HW limitations? } I am trying to recall more reasons why we need to use a new sub-TLV rather = than the existing TLV, because we had lots of discussion before IETF78th me= eting through mailing list and F2F, but it is a little difficult for me to = dig more things from my memory at this moment, :-)~~~~ [Rajan] { Please list the justifications for changing original GMPLS model. } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: Daniele Ceccarelli Cc: Ong, Lyndon ; ccamp@ietf.org Sent: Tuesday, October 26, 2010 7:13 AM Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards = compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue - either support or don= 't support. Based on the WG agreement we could go either way without breaki= ng the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question= . - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where OD= Uflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-B= W. This can be easily accomplished with a sub-TLV for ODUflex signal type i= n our model. BW in bytes/sec, of course. Please refer to attached slides f= or details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This= is exactly the proposal we have in our draft. Good to see that you have mo= ved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ 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 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E051F8SVEXDB1infine_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Pietro, et al=

 =

Please see response inli= ne

 =

Thanks=

Rajan<= /p>

 =

From: GRANDI, PIETR= O VITTORIO (PIETRO VITTORIO) [mailto:pietro_vittorio.grandi@alcatel-lucent.co= m]
Sent: Thursday, October 28, 2010 1:31 AM
To: Rajan Rao
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTO= RIO (PIETRO VITTORIO); BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hello= all,

=  

some considerations.

=  

1) Dr= aft Ashok states that

=  

 = ;            &n= bsp;            = ;            &n= bsp;          Max LSP Bandwidth

=  

 = ;     Number of OPU TSs =3D      -----------------------= --

=  

 = ;            &n= bsp;            = ;               &nb= sp;        Min LSP Bandwidth

=  

This = means that the MIN LSP Bandwidth is always set to the nominal size of 1 TS.<= /o:p>

So it= can have only two values 1.25 and 2.5 Gbit/s.

[Rajan] {

Yes. This is correct.=A0= But the exact value is nominal rate depending on the ODU layer involved.=

}

The m= in LSP bandwidth for IETF should instead provide the minimum switching capability. (see RFC4202)

[Rajan] {

=A0We have only 2 TS var= iants defined for (Switching-Capability=3DTDM &&=A0 Encoding=3DODUk ). Not sure w= hat the comment is about.

}

 =

=  

With = the above relationship it seems that a NE that supporting ODU1 and higher rate containers

and e= xporting interfaces with TS size =3D 1.25 Gbit/s should always declare a Min LSP Ban= dwidth =3D to 1.25Gbit/s

that = is not corresponding to a supported switching capability.

[Rajan] {

This is not true.= =A0 A link which is G.709-v1 based will advertise Min-LSP-BW=3D2.5G (ODU1 rate) not 1.= 25G (ODU0 rate). Please ref to ODU0 example in the previous chain.

}

=  

This = behavior is absolutely independent from the fact that ODU-flex is supported or not. =

=  

= 2)    Snip:

=  

“Not clear what th= e issue is.  We have listed 2 approaches in the slides sent out yesterday. To = reiterate the case where ODUflex is not supported:

 With  backwar= d compatibility option, the ODUflex goes in to a separate sub–TLV withi= n SCCI. If ODUflex is not supported on a link, this sub-TLV will not be inclu= ded; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become zero.”

 =

We wo= uld like first to observe that the ashok draft does not report this specific behavio= r. Secondary

we wo= uld make note that with this approach the MAX-LSP bandwidth in any case should be interpreted differently

when = the ODU-flex capacity is exhausted.

If yo= u think to a bundle link with ODU-flex capacity, then when

UDU-f= lex capacity is available the MAX-LSP bandwidth is used in a certain way wherea= s when the ODU-flex capacity is exhausted the

ODU-f= lex TLV is no more advertised and MAX-LSP bandwidth behavior is different.

we do= not see a reason that motivates the introduction of this kind of complication in routing.

 =

[Rajan] {

The ODUflex confusion ma= y be due to lack of details from us.=A0 In the ppt sent earlier we mentioned about h= ow to handle backward compatibility & ODUflex. =A0The minor modifications are captured in our draft-02 version (section 5.4.2).=A0 Please review and let = us know if there are still any issues.

http://www.infinera.com/rfc/draft-ashok-ccamp-gmpls-ospf-g709-02.txt=

 =

}

 =

=  

3)    Snip:

Thirdly, it can not supp= ort priority flexibility, so it is not efficient from the routing scalability perspective.

[Rajan] {

The whole idea is to sta= y with the GMPLS architecture already in place.  The technology specific extensions should go into SCSI. This has been done successfully for SONET/S= DH case (Ref to examples in RFC 4202). Do not see a reason to deviation from t= he original GMPLS model.

}

 

The o= riginal idea for GMPLS has been already discussed in the frame work document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only

refer= ence for requirements that have to be supported. Moreover, as required by CCAMP chai= r an example of the difference in efficiency between the original IETF format

and t= he new format is shown in the  draft draft-bccdg-ccamp-gmpls-ospf-agnostic.  

[Rajan] {

We have shown in our dra= ft that we can take care of OTN extensions in SCSI.=A0 It doesn’t make sense = to have two ISCDs (ISCD+BA) for the same switching type (=3DTDM). Unnecessary.=

}

=  

= 4)    Differentiation between terminat= ion and switching capabilities is a requirement contained in the framework document. The differentiation allows an operator

to en= gineer freely its network keeping into account capabilities offered by current technology. Current technology allows switching only a stage at once in the matrix.

Of co= urse this can be overcome with very costly muxponder boards that by the way coul= d have limitations related to which containers can be terminated and which ca= n be

only = adapted and sent to matrix for switching. In general a routing specification must n= ot force an operator to use costly solutions (multi-stage multiplexing) <= /o:p>

in or= der to operate the network. As a consequence the routing specification must provid= e the means to allow manage the current technology indicating clearly which a= re the capabilities of each interface in terms of terminations and switching. =

[Rajan] {

=A0Responded in a separa= te chain on why we do not need T/S flags.

}

=  

Pietr= o & Sergio

 

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pietro Vi= ttorio Grandi
Terrestri= al Optics Unit -  System Architecture
Alcatel-L= ucent Vimercate (Italy)
Tel: +39 = 039 686 4930
Mail: pietro_vittorio.grandi@alcatel-lucent.com
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Put your = hand on a hot stove for a minute, and it seems like an hour.
Sit with = a pretty girl for an hour, and it seems like a  minute. That's relativit= y.
(A= . Einstein)

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Rajan Rao
Sent: marted=EC 26 ottobre 2010 21.15
To: Fatai Zhang; Daniele Ceccarelli
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Fatai,=

 =

Please see response inli= ne, within { }

 =

Thanks=

Rajan<= /p>

 =

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Tuesday, October 26, 2010 5:11 AM
To: Rajan Rao; Daniele Ceccarelli
Cc: Ong, Lyndon; ccamp@ietf.org
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitte= d: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

You said there are three differences between two drafts. Now, we are comin= g much closer that there "may" be only one difference (i.e., backwa= rd compatibility) after Daniele gave some clarifications.

 

Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backw= ard compatibility.

 

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly, = as Daniele already pointed it out, it is a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C, however, = for Node A(G.709 V1), it must always advertise a meaningful value for the Max LSP bandwidth.

{Rajan] {

Not clear what the issue is.  We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:

 With  backwar= d compatibility option, the ODUflex goes in to a separate sub–TLV withi= n SCCI. If ODUflex is not supported on a link, this sub-TLV will not be inclu= ded; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become ze= ro.

 =

Please clarify if you ha= ve a different case in mind.

}

 =

Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular routing process, it will make the routing path computation function= to understand that it can support ODU0 LSP.

[Rajan] {

No, we have not changed = the meaning of “Minimum LSP BW”.   Please elaborate on wh= at is messed.   

Following RFC 4202/4201 = meaning, the example you have listed works as follows:

 =

MinLSP-BW =3D = ODU1  ( G.709-v1 supports 2.5G)

MaxLSP-BW =3D = ODU2  ( Min(unreserved-BW, configured Max LSP size)  as per RFC 4202)

 

If you are computing pat= h for an ODU0 connection, the rule would be

 =

Odu0-LSP-BW >=3D MinL= SP-BW && <=3D MaxLSP-BW

 =

The computation fails fo= r the above.   Where is it messed? Please provide a concrete example.

}

 =

Thirdly, it can not support priority flexibility, so it is not efficient from the routing scalability perspective. <= /span>

[Rajan] {

The whole idea is to sta= y with the GMPLS architecture already in place.  The technology specific extensions should go into SCSI. This has been done successfully for SONET/S= DH case (Ref to examples in RFC 4202). Do not see a reason to deviation from t= he original GMPLS model.

}

 =

Fourth, it can not differentiate termination and swiching capability for your darft= .

 [Rajan] {

We do not see a need to advertise this info.  We need to understand the use cases requiring th= is.  Are T/S bits addressing HW limitations?

}

 =

I am trying to recall more reasons why we need to use a new sub-TLV rather th= an the existing TLV, because we had lots of discussion before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig mo= re things from my memory at this moment, :-)~~~~

 [Rajan] {

Please list the justific= ations for changing original GMPLS model.

}

Best Regards
 
Fatai
 

---= -- Original Message -----

From: R= ajan Rao

Cc: Ong, Lyndon ; ccamp@ietf.org <= span lang=3DIT style=3D'font-size:9.0pt;font-family:SimSun'>

= Sent: Tuesday, October 26, 2010 7:1= 3 AM

= Subject: Re: [CCAMP] OSPF-TE extension= s for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01<= /span>

 

Daniele,

 

Please see response inline, within { }. =

 

Thanks

Rajan

 

-----Original Message-----

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; = ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Just a couple of comments on backward compatibility= and bandwidth advertisement.

 

- Backward compatibility: no ODU advertising is def= inded in RFC 4202/4203, so i believe there are no backward compatibility issues.<= o:p>

 

 

[Rajan]  {

Agree there is no ODU advertisement defined. The ne= ed to address backwards compatibility depends on the following:

 

 1) are there RFC-4328 based deployments?=

 2) If so, what do they use for BW advertiseme= nt?

 

Our fair guess is that ISCD is used for this as per= RFC 4202/4203.

 

There are 2 ways to address the compatibility issue= – either support or don’t support. Based on the WG agreement we could g= o either way without breaking the model we have proposed. Please refer to attached slides for details.

 

}

 

Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the M= AX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisemen= t, this is a backward compatibility issue in my opinion. It states that:<= /o:p>

 

      "Encoding of Ma= x LSP Bandwidth is as follows:

       Max LSP Bandwi= dth =3D Unreserved-TS-Count x TS-Nominal-Rate"

 

[Rajan]  {

 

The unit here is in Bytes/sec. The description abov= e (& in our draft)

-  = ;  shows that nominal rate is dependent on specific ODU layer in questi= on.

-  = ;  shows how Max LSP bandwidth number is derived at the advertising nod= e.

}

 

Moreover it states:

 

      "If the interfa= ce does not support ODU-flex service,

      this value should be= coded as zero".

 

But advertising max LSP bandwidth =3D 0 means disca= rding such link in the path computation process.

 

[Rajan] {

Good question & very valid. I think you are bri= nging up a scenario where ODUflex is not supported but backward compatibility is required.

 

What we need here is to separate ODUflex advertisem= ent from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course.  Please refer to attached slides for details.

 

}

 

- Bandwidth advertisement: in the -04 version of ou= r draft the bandwidth is advertised as follows:

 

    - Unreserved bandwidth for fixed container in number of containers

    - Unreserved bandwidth for odufl= ex in Bytes/sec

    - Max LSP bandwidth in Bytes/sec= .

 

[Rajan] {

We believe advertising the number of containers is = the right approach. This is exactly the proposal we have in our draft. Good to = see that you have moved away from TS approach which had serious limitations.

 

}

 

Advertising the unreserved bandwidth in number of containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

 

[Rajan] {

 

 The ODUflex uses bytes/sec in our draft. = ; There is no disagreement here.

 

}

BR

 

The authors

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: venerd=EC 15 ottobre 2010 19.13

To: Ong, Lyndon; ccamp@ietf.org

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Lyndon,

 

Yes, we are aware of the existing draft. There are = some fundamental differences in the model we have proposed from the existing dra= ft. The key differences are the following:

 

1) This draft extends existing ISCD  Vs. defin= ing a new one

    - addresses backward compatibili= ty issues (RFC 4202)

 

2) ODU containers are advertised instead of #TSs

     - simple path computation<= o:p>

 

3) Path computing node doesn't need to know per lin= k and/or per ODU layer TS granularity

     - again, simple & stra= ight forward path computation 

 

Thanks

Rajan

 

-----Original Message-----

From: Ong, Lyndon [mailto:Lyong@Ciena.com]

Sent: Thursday, October 14, 2010 7:45 AM=

To: Rajan Rao; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.709 O= TN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It would be helpful to= understand if your draft is asking for similar extensions or different functionality.<= o:p>

 

Thanks,

 

Lyndon

 

 

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: Wednesday, October 13, 2010 2:40 PM

To: ccamp@ietf.org

Subject: [CCAMP] OSPF-TE extensions for G.709 OTN d= raft submitted:

draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi,

 

The following draft has been submitted. Please revi= ew. Comments are appreciated.

 

https://datatracker.ietf.org/doc/draft-ashok-ccamp-= gmpls-ospf-g709/

 

thanks

Authors

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]

Sent: Wednesday, October 13, 2010 2:30 PM

To: Rajan Rao

Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan

Subject: New Version Notification for

draft-ashok-ccamp-gmpls-ospf-g709-01

 

 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been

successfully submitted by Rajan Rao and posted to t= he IETF repository.

 

Filename:   draft-ashok-ccamp-gmpls-ospf-= g709

Revision:   01

Title:       &nb= sp;    OSPF TE Extensions for Generalized MPLS (GMPLS) Control

of G.709 Optical Transport Networks

Creation_date:    2010-10-12

WG ID:            Independent Submission

Number_of_pages: 20

 

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased

need to support GMPLS control for the same. [RFC432= 8] introduced

GMPLS signaling extensions for supporting the early version of G.709

[G.709-v1]. The basic routing considerations from signaling

perspective is also specified in [RFC4328].

 

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and

[GSUP.43] have introduced new ODU containers (both = fixed and

flexible) and additional ODU multiplexing capabilit= ies, enabling

support for optimal service aggregation. 

 

This document describes OSPF protocol extensions to support

Generalized MPLS (GMPLS) control for routing servic= es over the

standardized OTU/ODU containers in support of ODU b= ased TDM

switching. Routing support for Optical Channel Laye= r switching

(Lambda switching) is not covered in this document.=

 

 

 

 

The IETF Secretariat.

 

 

_______________________________________________

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

--_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E051F8SVEXDB1infine_-- From dinghui.ei@gmail.com Thu Oct 28 18:16:31 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789683A6767 for ; Thu, 28 Oct 2010 18:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RshHPi-oRqMl for ; Thu, 28 Oct 2010 18:16:30 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C7C913A679F for ; Thu, 28 Oct 2010 18:16:29 -0700 (PDT) Received: by qwb7 with SMTP id 7so2689652qwb.31 for ; Thu, 28 Oct 2010 18:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=Y39vdxaLQCUJJnrz8yYltLwTCFsF9waaHF+z3lKpMeU=; b=fTi5U1nd0v4jwUu88+gsd7bwJHf/RCW7d5RMwSdfamGK7t9i3f78IYDT2sEPLZhwOn ye1Ltmc0pWJl+55CcMIyqrbNQvnW+OCOy5Ks41BLSQtJSjC39NoBPNvKhwMwPXf3QN/g cK+12605GVAkXeDkgf6AnNiKAxFL/E/7LYBCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=U8k+tNK1Pu1n9Ds1TMhEl5QtYzCExd2169CdtrYV9nXehU2I9mBKeI0OuahULKLjnq 8IR5ec79sOaJdQNzQYR0BlHiFHcYq8XfXe6VQI9OG0N+XosrW5JIaBZUX3mA88k1Wlep Y1T2oPKeFdSDRONgDjMuqnHXSeUGR1F4aLeQU= Received: by 10.229.101.207 with SMTP id d15mr10657905qco.222.1288315101785; Thu, 28 Oct 2010 18:18:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.183.200 with HTTP; Thu, 28 Oct 2010 18:18:01 -0700 (PDT) From: hui ding Date: Fri, 29 Oct 2010 09:18:01 +0800 Message-ID: To: "ccamp@ietf.org" Content-Type: multipart/alternative; boundary=0016364ecece002d960493b73c7b Subject: [CCAMP] convergence time for flooding information draft submitted: draft-zhangm-ccamp-metric-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 01:16:31 -0000 --0016364ecece002d960493b73c7b Content-Type: text/plain; charset=ISO-8859-1 Hi, The following draft has been submitted. Please review. Comments are appreciated. We will give a presentation on IETF 79. Please review. Comments are appreciated. http://datatracker.ietf.org/doc/draft-zhangm-ccamp-metric/ thanks Authors ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Oct 18, 2010 at 11:25 PM Subject: New Version Notification for draft-zhangm-ccamp-metric-00 To: dinghui.ei@gmail.com Cc: mzhang@bupt.edu.cn, yufengx386@gmail.com, zhanghaiyi@mail.ritt.com.cn, xuyunbin@mail.ritt.com.cn A new version of I-D, draft-zhangm-ccamp-metric-00.txt has been successfully submitted by Hui Ding and posted to the IETF repository. Filename: draft-zhangm-ccamp-metric Revision: 00 Title: Performance Metric of Convergence Time of Information Flooding in Multi- Domain GMPLS Networks Creation_date: 2010-10-18 WG ID: Independent Submission Number_of_pages: 17 Abstract: To keep the information of topology and links resource synchronized at each control node, massive messages are necessary to be flooded in the control plane of General Multi-Protocol Label Switching (GMPLS) based multi-domain networks. The convergence time of information flooding will have a significant impact on the performance of the networks. So measuring and analyzing the convergence time of information flooding in multi-domains becomes very important. A performance metric of convergence time of information flooding is proposed to characterize the ability of information synchronization in multi-domain networks. The IETF Secretariat. --0016364ecece002d960493b73c7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

The following draft has been submitted. Please review. Comments are appreci= ated. We will give a presentation on IETF 79.
Please review. Comments ar= e appreciated.

http://datatracker.ietf.org/doc/draft-zhangm-ccamp-m= etric/

thanks
Authors

---------- Forwarded message ----= ------
From: IETF I-D Submission Tool = <idsubmission= @ietf.org>
Date: Mon, Oct 18, 2010 at 11:25 PM
Subject: New Version Notification fo= r draft-zhangm-ccamp-metric-00
To: dinghui.ei@gmail.com
Cc: mz= hang@bupt.edu.cn, yufengx386@gm= ail.com, zhanghaiyi@mail= .ritt.com.cn, xuyunbin@mai= l.ritt.com.cn



A new version of I-D, draft-zhangm-ccamp-metric-00.txt has been successfull= y submitted by Hui Ding and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-zhangm-ccamp-metric
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Performance Metric of Convergence Time of Inform= ation Flooding in Multi- Domain GMPLS Networks
Creation_date: =A0 2010-10-18
WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
Number_of_pages: 17

Abstract:
To keep the information of topology and links resource synchronized
at each control node, massive messages are necessary to be flooded in
the control plane of General Multi-Protocol Label Switching (GMPLS)
based multi-domain networks. =A0The convergence time of information
flooding will have a significant impact on the performance of the
networks. =A0So measuring and analyzing the convergence time of
information flooding in multi-domains becomes very important. =A0A
performance metric of convergence time of information flooding is
proposed to characterize the ability of information synchronization
in multi-domain networks.



The IETF Secretariat.

--0016364ecece002d960493b73c7b-- From zhangfatai@huawei.com Thu Oct 28 20:06:47 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91BF43A69E8 for ; Thu, 28 Oct 2010 20:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.337 X-Spam-Level: X-Spam-Status: No, score=0.337 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTi-ejbEkwGD for ; Thu, 28 Oct 2010 20:06:46 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 89CC33A69E9 for ; Thu, 28 Oct 2010 20:06:45 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB1000BQ7E4ZN@szxga01-in.huawei.com> for ccamp@ietf.org; Fri, 29 Oct 2010 11:08:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB100F587E4KK@szxga01-in.huawei.com> for ccamp@ietf.org; Fri, 29 Oct 2010 11:08:28 +0800 (CST) Received: from Z41162C ([10.70.76.101]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB100CHV7E16F@szxml06-in.huawei.com> for ccamp@ietf.org; Fri, 29 Oct 2010 11:08:28 +0800 (CST) Date: Fri, 29 Oct 2010 11:08:25 +0800 From: Fatai Zhang To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , CCAMP Message-id: <020701cb7716$8d575d90$654c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_72ofORmMN6aFred3aRr1iA)" X-Priority: 3 X-MSMail-priority: Normal References: <077E41CFFD002C4CAB7DFA4386A5326402D2E254@DEMUEXC014.nsn-intra.net> Cc: "Ouyang, Yong \(NSN - CN/Shanghai\)" , "Clemens, Rainer \(NSN - DE/Munich\)" Subject: Re: [CCAMP] FW: I-D Action:draft-zhang-ccamp-gmpls-evolving-g709-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 03:06:47 -0000 This is a multi-part message in MIME format. --Boundary_(ID_72ofORmMN6aFred3aRr1iA) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 SGkgTnVyaXQsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSByZXNwb25z ZSBpbi1saW5lIGJlbG93Lg0KDQoNCg0KDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRzDQogDQpGYXRh aQ0KIA0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBTcHJlY2hlciwg TnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbikgDQogIFRvOiBDQ0FNUCANCiAgQ2M6IE91eWFu ZywgWW9uZyAoTlNOIC0gQ04vU2hhbmdoYWkpIDsgQ2xlbWVucywgUmFpbmVyIChOU04gLSBERS9N dW5pY2gpIA0KICBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjksIDIwMTAgMzozNiBBTQ0KICBTdWJq ZWN0OiBbQ0NBTVBdIEZXOiBJLUQgQWN0aW9uOmRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWV2b2x2 aW5nLWc3MDktMDYudHh0DQoNCg0KICBIaSwNCg0KICBUd28gY29tbWVudHMgZnJvbSBvdXIgc2lk ZToNCg0KICAxLiAgT0RVZmxleChDQlIpIGlzIGRlc2NyaWJlZCBjbGF1c2UgNCBpbiBhIHdheSB0 aGF0IGl0IGNvdWxkIGxlYWQgdG8gbWlzdW5kZXJzdGFuZGluZy4gDQoNCiAgQXMgYW4gZXhhbXBs ZSBhIGNsaWVudCBzaWduYWwgcmF0ZSBvZiAyLjVHICgrLy0yMHBwbSkgaXMgdXNlZC4gVGhpcyBj b3VsZCBiZSBtaXN1bmRlcnN0b29kIHRoYXQgMi41RyBzaWduYWxzIHdpbGwgYmUgbWFwcGVkIGlu dG8gYW4gT0RVZmxleChDQlIpLiBJbiBjb21tb24gbGFuZ3VhZ2UsIDIuNUcgc2lnbmFscyAtIGVz cGVjaWFsbHkgd2l0aCAyMHBwbSAtIGFyZSBTVE0tMTYgb3IgU1RTLTQ4IHNpZ25hbHMsIHdoaWNo IHJlYWxseSBhcmUgMi40ODggR2JpdC9zIHNpZ25hbHMgYW5kIHdpbGwgYmUgbWFwcGVkIGludG8g T0RVMi4NCg0KICBUbyBhdm9pZCBtaXN1bmRlcnN0YW5kaW5nLCBpdCBtaWdodCBiZSBoZWxwZnVs IHRvIGNsZWFybHkgc3RhdGUgdGhhdCBvbmx5IHNpZ25hbHMgd2l0aCBhIGJpdCByYXRlID4yLjQ4 OEdiaXQvcyB3aWxsIGJlIG1hcHBlZCBpbnRvIE9EVWZsZXgoQ0JSKS4NCg0KDQoNCiAgW0ZhdGFp XSwgQWdyZWUsIGdvb2QgY2F0Y2guIEhlcmUgaXMganVzdCBhbiBleGFtcGxlLiBXZSB3aWxsIG1v ZGlmeSB0aGUgZGVzY3JpcHRpb24gYWNjb3JkaW5nIHRvIHlvdXIgc3VnZ2VzdGlvbi4NCg0KICAg DQoNCiAgMi4gIENsYXVzZSA0LjEgc3RhdGVzIGF0IHRoZSBlbmQgdGhhdCBPRFVmbGV4KEdGUCkg aXMgZm9yIGZ1cnRoZXIgc3R1ZHkgYmVjYXVzZSBHLjcwOSB3b3VsZCBuZWVkIHRvIGRlZmluZSB0 aGUgVFMgYWxsb2NhdGlvbi4gQnV0IHRoZSBkZWZpbml0aW9uIGlzIGFscmVhZHkgdGhlcmUuIE9E VWZsZXgoR0ZQKSBjYW4gYXNzdW1lIDEgVFMgdXAgdG8gODAgVFMuDQoNCiAgRy43MDkgVGFibGUg Ny04IGRlZmluZXMgdGhlIGJhbmR3aWR0aHMuDQoNCiAgSW4gYWRkaXRpb24sIGNsYXVzZSAxMi4y LjUgb2YgRy43MDkgc3RhdGVzOiBUaGUgdmFsdWUgb2YgQ20gc2hvdWxkIGJlIHNlbGVjdGVkIHN1 Y2ggdGhhdCB0aGUgT0RVZmxleCBzaWduYWwgY2FuIGJlIHRyYW5zcG9ydGVkIG92ZXIgIm4iIE9Q VWsgdHJpYnV0YXJ5IHNsb3RzIHVuZGVyIHdvcnN0LWNhc2UgY29uZGl0aW9ucyAoaS5lLiwgbWF4 aW11bSBPRFVmbGV4IGJpdCByYXRlIGFuZCBtaW5pbXVtIEhPIE9QVWsgYml0IHJhdGVzKS4gVGhp cyBpcyBzaG93biBtb3JlIGV4cGxpY2l0IGluIHRoZSB0YWJsZXMgdGhhdCBmb2xsb3cuDQoNCiAg QnV0IHdoYXQgaXQgZXNzZW50aWFsbHkgbWVhbnMgaXMgdGhhdCB0aGUgbnVtYmVyIG9mIG9jY3Vw aWVkIHRyaWJ1dGFyeSBzbG90cyBvZiBhbiBPRFVmbGV4KEdGUCkgYXJlIGFuZCBoYXZlIHRvIGJl IGNvbnN0YW50IG92ZXIgdGhlIGVudGlyZSBwYXRoIChldmVuIGluIHRoZSBjYXNlIG9mIHJlc3Rv cmF0aW9uL3Byb3RlY3Rpb24pLiBUaGUgbnVtYmVyIG9mIG5lY2Vzc2FyeSBUUyBpcyBjYWxjdWxh dGVkIG91dCBvZiB0aGUgdHJpYnV0YXJ5IHNsb3QgYmFuZHdpZHRoIG9mIHRoZSBzbWFsbGVzdCBI TyBPRFUgaW4gdGhlIHBhdGggKGkuZS4gd2l0aCBPRFUyIGFzIHNtYWxsZXN0IEhPIGNvbnRhaW5l ciBpbiB0aGUgcGF0aCBPRFUyIFRTIGJhbmR3aWR0aCB3aWxsIGRldGVybWluZSB0aGUgbnVtYmVy IG9mIFRTLCB3aXRoIE9EVTMgYXMgc21hbGxlc3QgSE8gY29udGFpbmVyIGluIHRoZSBwYXRoIGl0 IHdpbGwgYmUgT0RVMywgYW5kIHdpdGggb25seSBITyBPRFU0IGl0IHdpbGwgYmUgT0RVNCkuDQoN CiAgU2FpZCBhbGwgdGhpcywgaXQgbWlnaHQgYmUgaGVscGZ1bCB0byBhbHJlYWR5IHRha2UgdGhp cyBpbnRvIGFjY291bnQsIGVpdGhlciBieSBkZWZpbmluZyAyIGRpZmZlcmVudCBsYWJlbHMgZm9y IHRoZSAyIHR5cGVzIG9mIE9EVWZsZXhlcywgR0ZQIGFuZCBDQlIsIG9yIHRvIHJlc2VydmUgYSBm aWVsZCBmb3IgdGhlIG51bWJlciBvZiBUUyBpbiB0aGUgY2FzZSB0aGUgT0RVZmxleCBpcyBhbiBP RFVmbGV4KEdGUCkuIFRoaXMgbmV3IGZpZWxkIHdvdWxkIG5vdCBiZSB1c2VkIGluIHRoZSBjYXNl IG9mIE9EVWZsZXgoQ0JSKWFuZC9vciB3b3VsZCBpbmRpY2F0ZSB0aGF0IGl0IGlzIGFuIE9EVWZs ZXgoQ0JSKSwgZS5nLiBieSB1c2luZyBhbiBpbnZhbGlkIHZhbHVlICIwIiBmb3IgdGhlIG51bWJl ciBvZiBUUy4NCg0KDQoNCiAgW0ZhdGFpXSBHb29kIHBvaW50LiBZb3Ugc2FpZCAiVGhlIG51bWJl ciBvZiBuZWNlc3NhcnkgVFMgaXMgY2FsY3VsYXRlZCBvdXQgb2YgdGhlIHRyaWJ1dGFyeSBzbG90 IGJhbmR3aWR0aCBvZiB0aGUgc21hbGxlc3QgSE8gT0RVIGluIHRoZSBwYXRoIiAsIGJ1dCBJIGRv bid0IHRoaW5rIHNvLCBiZWNhdXNlIGhvdyB0byBkZXRlcm1pbmUgdGhlIG51bWJlciBvZiBUUyBm b3IgYW4gT0RVZmxleChHRlApIGlzIHVuZGVyIGRpc2N1c3Npb24gaW4gSVRVLVQvU0cxNS4gVGhl IHRhYmxlcyBpbiBjbGF1c2UgMTIuMi41IGRvbid0IHRlbGwgdXMgaG93IHRvIGRldGVybWluZSBp dC4gDQoNCg0KDQogIEFjdHVhbGx5LCAgdGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQgaW4g dGhlIHJlY2VudCBJVFUgU0cxNS9xMTEgbWVldGluZyBoZWxkIGluIFZpbWVyY2F0ZSBpbiBTZXB0 ZW1iZXIgMjAxMC4gRnJvbSB0aGUgbWVldGluZyByZXBvcnQsIHdlIGNhbiBzZWUgdGhhdCBpdCB3 YXMgZGVjaWRlZCB0aGF0IGEgcmVzaXphYmxlIE9EVWZsZXgoR0ZQKSBvY2N1cGllcyB0aGUgc2Ft ZSBudW1iZXIgb2YgVFMgb24gZXZlcnkgbGluayBvZiB0aGUgcGF0aCwgaW5kZXBlbmRlbnRseSBv ZiB0aGUgSGlnaCBPcmRlciAoSE8pIE9QVWsgVFMgcmF0ZS4gVGhhdCBpczoNCg0KICDvgp8gRm9y ICAgbiA9IDEg4oCmIDggICAgICBPRFVmbGV4ID0gbiAqIFRTKE9QVTIpDQogIO+CnyBGb3IgICBu ID0gOSDigKYgMzIgICAgT0RVZmxleCA9IG4gKiBUUyhPUFUzKQ0KICDvgp8gRm9yICAgbiA9IDMz IOKApiA4MCAgT0RVZmxleCA9IG4gKiBUUyhPUFU0KQ0KDQogIFBsZWFzZSBzZWUgV0QwNyBhbmQg dGhlIG1lZXRpbmcgcmVwb3J0IG9mIHRoaXMgbWVldGluZyBmb3IgbW9yZSBpbmZvcm1hdGlvbi4g VGhpcyBpcyB3aHkgd2UgYWRkZWQgYW4gZWRpdG9ycyBub3RlIHRvIHNheSAiZm9yIGZ1cnRoZXIg c3R1ZHkiIGFuZCBhZGRlZCBhbiBlZGl0b3JzJyBub3RlIGluIHNlY3Rpb24gMy4xLjEgb2YgW09U TiBGV0tdLiANCg0KDQoNCiAgV2Ugd2lsbCB1cGRhdGVkIGl0IGFzIHNvb24gYXMgRy43MDkgaXMg dXBkYXRlZC4NCg0KDQoNCg0KDQoNCg0KICBCZXN0IHJlZ2FyZHMsDQoNCiAgTnVyaXQNCg0KICAg DQoNCiAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KICBGcm9tOiBpLWQtYW5ub3VuY2Ut Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgZXh0IEludGVybmV0LURyYWZ0c0BpZXRmLm9yZw0KDQogIFNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDIxLCAyMDEwIDM6MDAgQU0NCg0KICBUbzogaS1kLWFubm91bmNlQGlldGYu b3JnDQoNCiAgU3ViamVjdDogSS1EIEFjdGlvbjpkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1ldm9s dmluZy1nNzA5LTA2LnR4dCANCg0KICAgDQoNCiAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQog ICANCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2Nv bCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSBTaWduYWxpbmcgRXh0ZW5zaW9ucyBmb3IgdGhlIGV2 b2x2aW5nIEcuNzA5IE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmtzIENvbnRyb2wNCg0KICAgICAg ICBBdXRob3IocykgICAgICAgOiBGLiBaaGFuZywgZXQgYWwuDQoNCiAgICAgICAgRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wNi50eHQNCg0K ICAgICAgICBQYWdlcyAgICAgICAgICAgOiAyMQ0KDQogICAgICAgIERhdGUgICAgICAgICAgICA6 IDIwMTAtMTAtMjANCg0KICAgDQoNCiAgUmVjZW50IHByb2dyZXNzIGluIElUVS1UIFJlY29tbWVu ZGF0aW9uIEcuNzA5IHN0YW5kYXJkaXphdGlvbiBoYXMgDQoNCiAgaW50cm9kdWNlZCBuZXcgT0RV IGNvbnRhaW5lcnMgKE9EVTAsIE9EVTQsIE9EVTJlIGFuZCBPRFVmbGV4KSBhbmQgDQoNCiAgZW5o YW5jZWQgT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29ya2luZyAoT1ROKSBmbGV4aWJpbGl0eS4gU2V2 ZXJhbCANCg0KICAgDQoNCiAgIA0KDQogICANCg0KICAgDQoNCiAgPFpoYW5nPg0KDQogICANCg0K ICAgDQoNCiAgIA0KDQogICANCg0KICAgDQoNCiAgRXhwaXJlcyBBcHJpbCAyMDExDQoNCiAgIA0K DQogICANCg0KICAgDQoNCiAgIA0KDQogICANCg0KICAgIFtwYWdlIDFdIA0KDQogICANCg0KICBk cmFmdC16aGFuZy1jY2FtcC1nbXBscy1ldm9sdmluZy1nNzA5LTA2LnR4dA0KDQogICANCg0KICAg DQoNCiAgIA0KDQogICANCg0KICBPY3RvYmVyIDIwMTAgDQoNCiAgIA0KDQogICANCg0KICByZWNl bnQgZG9jdW1lbnRzIGhhdmUgcHJvcG9zZWQgd2F5cyB0byBtb2RpZnkgR01QTFMgc2lnbmFsaW5n IA0KDQogIHByb3RvY29scyB0byBzdXBwb3J0IHRoZXNlIG5ldyBPVE4gZmVhdHVyZXMuICANCg0K ICAgDQoNCiAgSXQgaXMgaW1wb3J0YW50IHRoYXQgYSBzaW5nbGUgc29sdXRpb24gaXMgZGV2ZWxv cGVkIGZvciB1c2UgaW4gR01QTFMgDQoNCiAgc2lnbmFsaW5nIGFuZCByb3V0aW5nIHByb3RvY29s cy4gVGhpcyBzb2x1dGlvbiBtdXN0IHN1cHBvcnQgT0RVayANCg0KICBtdWx0aXBsZXhpbmcgY2Fw YWJpbGl0aWVzLCBhZGRyZXNzIGFsbCBvZiB0aGUgbmV3IGZlYXR1cmVzLCBiZSANCg0KICBhY2Nl cHRhYmxlIHRvIGFsbCBlcXVpcG1lbnQgdmVuZG9ycywgYW5kIGJlIGV4dGVuc2libGUgY29uc2lk ZXJpbmcgDQoNCiAgY29udGludWVkIE9UTiBldm9sdXRpb24uICANCg0KICAgDQoNCiAgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgdGhlIGV4dGVuc2lvbnMgdG8gdGhlIEdlbmVyYWxpemVkIE11bHRp LQ0KDQogIFByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpIHNpZ25hbGluZyB0byBjb250 cm9sIHRoZSBldm9sdmluZyANCg0KICBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3JrcyAoT1ROKSBh ZGRyZXNzaW5nIE9EVWsgbXVsdGlwbGV4aW5nIGFuZCBuZXcgDQoNCiAgZmVhdHVyZXMgaW5jbHVk aW5nIE9EVTAsIE9EVTQsIE9EVTJlIGFuZCBPRFVmbGV4Lg0KDQogICANCg0KICBBIFVSTCBmb3Ig dGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCg0KICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC16aGFuZy1jY2FtcC1nbXBscy1ldm9sdmluZy1nNzA5LTA2LnR4dA0KDQog ICANCg0KICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQoNCiAgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KICAgDQoN CiAgQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBt YWlsIHJlYWRlcg0KDQogIGltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUg dGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhlDQoNCiAgSW50ZXJuZXQtRHJhZnQuDQoNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KDQogIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQogIENDQU1QIG1haWxpbmcgbGlzdA0KICBDQ0FNUEBpZXRmLm9yZw0K ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo= --Boundary_(ID_72ofORmMN6aFred3aRr1iA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIj48SEVBRD4NCjxNRVRBIGh0 dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjI5MTIiIG5hbWU9R0VORVJBVE9SPg0K PFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBXaW5nZGluZ3M7DQp9DQpAZm9udC1m YWNlIHsNCglmb250LWZhbWlseTogV2luZ2RpbmdzOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1m YW1pbHk6IENhbGlicmk7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQ29uc29sYXM7 DQp9DQpAcGFnZSBTZWN0aW9uMSB7c2l6ZTogNjEyLjBwdCA3OTIuMHB0OyBtYXJnaW46IDcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTFw dDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJp ZiINCn0NCkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMXB0OyBNQVJHSU46IDBjbSAwY20g MHB0OyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIg0KfQ0KRElWLk1zb05vcm1h bCB7DQoJRk9OVC1TSVpFOiAxMXB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTog IkNhbGlicmkiLCJzYW5zLXNlcmlmIg0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1E RUNPUkFUSU9OOiB1bmRlcmxpbmU7IG1zby1zdHlsZS1wcmlvcml0eTogOTkNCn0NClNQQU4uTXNv SHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IG1z by1zdHlsZS1wcmlvcml0eTogOTkNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVY VC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IG1zby1zdHlsZS1wcmlvcml0eTogOTkNCn0NClNQQU4u TXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpQLk1zb1BsYWluVGV4dCB7DQoJ Rk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiBDb25z b2xhczsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLWxpbms6ICJQbGFpbiBUZXh0 IENoYXIiDQp9DQpMSS5Nc29QbGFpblRleHQgew0KCUZPTlQtU0laRTogMTAuNXB0OyBNQVJHSU46 IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogQ29uc29sYXM7IG1zby1zdHlsZS1wcmlvcml0eTog OTk7IG1zby1zdHlsZS1saW5rOiAiUGxhaW4gVGV4dCBDaGFyIg0KfQ0KRElWLk1zb1BsYWluVGV4 dCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZ OiBDb25zb2xhczsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLWxpbms6ICJQbGFp biBUZXh0IENoYXIiDQp9DQpTUEFOLlBsYWluVGV4dENoYXIgew0KCUZPTlQtRkFNSUxZOiBDb25z b2xhczsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLWxpbms6ICJQbGFpbiBUZXh0 IjsgbXNvLXN0eWxlLW5hbWU6ICJQbGFpbiBUZXh0IENoYXIiDQp9DQouTXNvQ2hwRGVmYXVsdCB7 DQoJbXNvLXN0eWxlLXR5cGU6IGV4cG9ydC1vbmx5DQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6 IFNlY3Rpb24xDQp9DQpPTCB7DQoJTUFSR0lOLUJPVFRPTTogMGNtDQp9DQpVTCB7DQoJTUFSR0lO LUJPVFRPTTogMGNtDQp9DQo8L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvSEVBRD4NCjxCT0RZIGxhbmc9RU4tVVMgdkxpbms9cHVy cGxlIGxpbms9Ymx1ZSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SGkg TnVyaXQsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBs ZWFzZSBzZWUgcmVzcG9uc2UgaW4tbGluZSANCmJlbG93LjwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48QlI+QmVzdCBSZWdhcmRzPEJSPiZu YnNwOzxCUj5GYXRhaTxCUj4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJ TkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRF Ui1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQg5a6L5L2TIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElW Pg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQg5a6L5L2TOyBm b250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1udXJpdC5zcHJlY2hl ckBuc24uY29tIGhyZWY9Im1haWx0bzpudXJpdC5zcHJlY2hlckBuc24uY29tIj5TcHJlY2hlciwg DQogIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pPC9BPiA8L0RJVj4NCiAgPERJViBzdHls ZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+VG86PC9CPiA8QSB0aXRsZT1jY2FtcEBpZXRmLm9yZyAN CiAgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5DQ0FNUDwvQT4gPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPkNjOjwvQj4gPEEgdGl0bGU9eW9uZy5vdXlhbmdA bnNuLmNvbSANCiAgaHJlZj0ibWFpbHRvOnlvbmcub3V5YW5nQG5zbi5jb20iPk91eWFuZywgWW9u ZyAoTlNOIC0gQ04vU2hhbmdoYWkpPC9BPiA7IDxBIA0KICB0aXRsZT1yYWluZXIuY2xlbWVuc0Bu c24uY29tIGhyZWY9Im1haWx0bzpyYWluZXIuY2xlbWVuc0Buc24uY29tIj5DbGVtZW5zLCANCiAg UmFpbmVyIChOU04gLSBERS9NdW5pY2gpPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDog OXB0IOWui+S9kyI+PEI+U2VudDo8L0I+IEZyaWRheSwgT2N0b2JlciAyOSwgMjAxMCAzOjM2IEFN PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlN1YmplY3Q6PC9CPiBb Q0NBTVBdIEZXOiBJLUQgDQogIEFjdGlvbjpkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1ldm9sdmlu Zy1nNzA5LTA2LnR4dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBjbGFzcz1TZWN0 aW9uMT4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PkhpLDxvOnA+PC9vOnA+PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjayI+VHdvIGNvbW1lbnRz IGZyb20gb3VyIA0KICBzaWRlOjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0IA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDcycHQ7IFRFWFQtSU5ERU5UOiAtMThw dDsgbXNvLWxpc3Q6IGwxIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExpc3RzXT48U1BBTiAN CiAgc3R5bGU9IkNPTE9SOiBibGFjayI+PFNQQU4gc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPjEu PFNQQU4gDQogIHN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyANCiAg PC9TUEFOPjwvU1BBTj48L1NQQU4+PCFbZW5kaWZdPjxTUEFOIGRpcj1sdHI+PC9TUEFOPjxTUEFO IA0KICBzdHlsZT0iQ09MT1I6IGJsYWNrIj5PRFVmbGV4KENCUikgaXMgZGVzY3JpYmVkIGNsYXVz ZSA0IGluIGEgd2F5IHRoYXQgaXQgY291bGQgDQogIGxlYWQgdG8gbWlzdW5kZXJzdGFuZGluZy4g PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1B UkdJTi1MRUZUOiA3MnB0Ij48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrIj5BcyANCiAgYW4gZXhh bXBsZSBhIGNsaWVudCBzaWduYWwgcmF0ZSBvZiAyLjVHICgrLy0yMHBwbSkgaXMgdXNlZC4gVGhp cyBjb3VsZCBiZSANCiAgbWlzdW5kZXJzdG9vZCB0aGF0IDIuNUcgc2lnbmFscyB3aWxsIGJlIG1h cHBlZCBpbnRvIGFuIE9EVWZsZXgoQ0JSKS4gSW4gY29tbW9uIA0KICBsYW5ndWFnZSwgMi41RyBz aWduYWxzIC0gZXNwZWNpYWxseSB3aXRoIDIwcHBtIC0gYXJlIFNUTS0xNiBvciBTVFMtNDggc2ln bmFscywgDQogIHdoaWNoIHJlYWxseSBhcmUgMi40ODggR2JpdC9zIHNpZ25hbHMgYW5kIHdpbGwg YmUgbWFwcGVkIGludG8gDQogIE9EVTIuPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTi1MRUZUOiA3MnB0Ij48U1BBTiBzdHlsZT0iQ09M T1I6IGJsYWNrIj5UbyANCiAgYXZvaWQgbWlzdW5kZXJzdGFuZGluZywgaXQgbWlnaHQgYmUgaGVs cGZ1bCB0byBjbGVhcmx5IHN0YXRlIHRoYXQgb25seSBzaWduYWxzIA0KICB3aXRoIGEgYml0IHJh dGUgJmd0OzIuNDg4R2JpdC9zIHdpbGwgYmUgbWFwcGVkIGludG8gT0RVZmxleChDQlIpLjwvU1BB Tj48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDcycHQi PjxTUEFOIA0KICBzdHlsZT0iQ09MT1I6IGJsYWNrIj48L1NQQU4+Jm5ic3A7PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTi1MRUZUOiA3MnB0Ij48U1BBTiANCiAgc3R5 bGU9IkNPTE9SOiBibGFjayI+PG86cD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0zPltGYXRhaV0sIA0KICBBZ3JlZSwgZ29vZCBjYXRjaC4gSGVyZSBpcyBqdXN0IGFuIGV4YW1w bGUuIFdlIHdpbGwgbW9kaWZ5IHRoZSBkZXNjcmlwdGlvbiANCiAgYWNjb3JkaW5nIHRvIHlvdXIg c3VnZ2VzdGlvbi48L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0IA0KICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDcycHQ7 IFRFWFQtSU5ERU5UOiAtMThwdDsgbXNvLWxpc3Q6IGwxIGxldmVsMSBsZm8zIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48U1BBTiANCiAgc3R5bGU9IkNPTE9SOiBibGFjayI+PFNQQU4gc3R5bGU9Im1z by1saXN0OiBJZ25vcmUiPjIuPFNQQU4gDQogIHN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBS b21hbiciPiZuYnNwOyANCiAgPC9TUEFOPjwvU1BBTj48L1NQQU4+PCFbZW5kaWZdPjxTUEFOIGRp cj1sdHI+PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iQ09MT1I6IGJsYWNrIj5DbGF1c2UgNC4xIHN0 YXRlcyBhdCB0aGUgZW5kIHRoYXQgT0RVZmxleChHRlApIGlzIGZvciANCiAgZnVydGhlciBzdHVk eSBiZWNhdXNlIEcuNzA5IHdvdWxkIG5lZWQgdG8gZGVmaW5lIHRoZSBUUyBhbGxvY2F0aW9uLiBC dXQgdGhlIA0KICBkZWZpbml0aW9uIGlzIGFscmVhZHkgdGhlcmUuIE9EVWZsZXgoR0ZQKSBjYW4g YXNzdW1lIDEgVFMgdXAgdG8gODAgDQogIFRTLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAg Y2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU4tTEVGVDogNzJwdCI+PFNQQU4gDQogIHN0 eWxlPSJDT0xPUjogYmxhY2siPkcuNzA5IFRhYmxlIDctOCBkZWZpbmVzIHRoZSANCiAgYmFuZHdp ZHRocy48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHls ZT0iTUFSR0lOLUxFRlQ6IDcycHQiPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2siPkluIA0KICBh ZGRpdGlvbiwgY2xhdXNlIDEyLjIuNSBvZiBHLjcwOSBzdGF0ZXM6IFRoZSB2YWx1ZSBvZiBDbSBz aG91bGQgYmUgc2VsZWN0ZWQgDQogIHN1Y2ggdGhhdCB0aGUgT0RVZmxleCBzaWduYWwgY2FuIGJl IHRyYW5zcG9ydGVkIG92ZXIgIm4iIE9QVWsgdHJpYnV0YXJ5IHNsb3RzIA0KICB1bmRlciB3b3Jz dC1jYXNlIGNvbmRpdGlvbnMgKGkuZS4sIG1heGltdW0gT0RVZmxleCBiaXQgcmF0ZSBhbmQgbWlu aW11bSBITyANCiAgT1BVayBiaXQgcmF0ZXMpLiBUaGlzIGlzIHNob3duIG1vcmUgZXhwbGljaXQg aW4gdGhlIHRhYmxlcyB0aGF0IA0KICBmb2xsb3cuPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTi1MRUZUOiA3MnB0Ij48U1BBTiBzdHls ZT0iQ09MT1I6IGJsYWNrIj5CdXQgDQogIHdoYXQgaXQgZXNzZW50aWFsbHkgbWVhbnMgaXMgdGhh dCB0aGUgbnVtYmVyIG9mIG9jY3VwaWVkIHRyaWJ1dGFyeSBzbG90cyBvZiBhbiANCiAgT0RVZmxl eChHRlApIGFyZSBhbmQgaGF2ZSB0byBiZSBjb25zdGFudCBvdmVyIHRoZSBlbnRpcmUgcGF0aCAo ZXZlbiBpbiB0aGUgDQogIGNhc2Ugb2YgcmVzdG9yYXRpb24vcHJvdGVjdGlvbikuIFRoZSBudW1i ZXIgb2YgbmVjZXNzYXJ5IFRTIGlzIGNhbGN1bGF0ZWQgb3V0IA0KICBvZiB0aGUgdHJpYnV0YXJ5 IHNsb3QgYmFuZHdpZHRoIG9mIHRoZSBzbWFsbGVzdCBITyBPRFUgaW4gdGhlIHBhdGggKGkuZS4g d2l0aCANCiAgT0RVMiBhcyBzbWFsbGVzdCBITyBjb250YWluZXIgaW4gdGhlIHBhdGggT0RVMiBU UyBiYW5kd2lkdGggd2lsbCBkZXRlcm1pbmUgdGhlIA0KICBudW1iZXIgb2YgVFMsIHdpdGggT0RV MyBhcyBzbWFsbGVzdCBITyBjb250YWluZXIgaW4gdGhlIHBhdGggaXQgd2lsbCBiZSBPRFUzLCAN CiAgYW5kIHdpdGggb25seSBITyBPRFU0IGl0IHdpbGwgYmUgT0RVNCkuPG86cD48L286cD48L1NQ QU4+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTi1MRUZUOiA3MnB0 Ij48U1BBTiANCiAgc3R5bGU9IkNPTE9SOiBibGFjayI+U2FpZCBhbGwgdGhpcywgaXQgbWlnaHQg YmUgaGVscGZ1bCB0byBhbHJlYWR5IHRha2UgdGhpcyANCiAgaW50byBhY2NvdW50LCBlaXRoZXIg YnkgZGVmaW5pbmcgMiBkaWZmZXJlbnQgbGFiZWxzIGZvciB0aGUgMiB0eXBlcyBvZiANCiAgT0RV ZmxleGVzLCBHRlAgYW5kIENCUiwgb3IgdG8gcmVzZXJ2ZSBhIGZpZWxkIGZvciB0aGUgbnVtYmVy IG9mIFRTIGluIHRoZSBjYXNlIA0KICB0aGUgT0RVZmxleCBpcyBhbiBPRFVmbGV4KEdGUCkuIFRo aXMgbmV3IGZpZWxkIHdvdWxkIG5vdCBiZSB1c2VkIGluIHRoZSBjYXNlIA0KICBvZiBPRFVmbGV4 KENCUilhbmQvb3Igd291bGQgaW5kaWNhdGUgdGhhdCBpdCBpcyBhbiBPRFVmbGV4KENCUiksIGUu Zy4gYnkgdXNpbmcgDQogIGFuIGludmFsaWQgdmFsdWUgIjAiIGZvciB0aGUgbnVtYmVyIG9mIFRT LjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOLUxFRlQ6 IDcycHQiPjxTUEFOIA0KICBzdHlsZT0iQ09MT1I6IGJsYWNrIj48L1NQQU4+Jm5ic3A7PC9QPjxT UEFOIHN0eWxlPSJDT0xPUjogYmxhY2siPjxGT05UIHNpemU9Mz4NCiAgPFAgY2xhc3M9TXNvUGxh aW5UZXh0IHN0eWxlPSJNQVJHSU4tTEVGVDogNzJwdCI+PEZPTlQgc2l6ZT0zPjxTUEFOIA0KICBz dHlsZT0iQ09MT1I6IGJsYWNrIj48U1BBTiBjbGFzcz00NzQ0MzUyMDAtMjkxMDIwMTA+PEZPTlQg ZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZj5bRmF0YWldIEdvb2QgcG9pbnQuIFlvdSBzYWlk ICI8Rk9OVCBjb2xvcj0jMDAwMDAwPlRoZSBudW1iZXIgb2YgDQogIG5lY2Vzc2FyeSBUUyBpcyBj YWxjdWxhdGVkIG91dCBvZiB0aGUgdHJpYnV0YXJ5IHNsb3QgYmFuZHdpZHRoIG9mIHRoZSBzbWFs bGVzdCANCiAgSE8gT0RVIGluIHRoZSBwYXRoPC9GT05UPiIgLCBidXQgSSBkb24ndCB0aGluayBz bywgYmVjYXVzZSBob3cgdG8gZGV0ZXJtaW5lIA0KICB0aGUgbnVtYmVyIG9mIFRTIGZvciBhbiBP RFVmbGV4KEdGUCkgaXMgdW5kZXIgZGlzY3Vzc2lvbiBpbiBJVFUtVC9TRzE1LiBUaGUgDQogIHRh YmxlcyZuYnNwO2luIGNsYXVzZSAxMi4yLjUgZG9uJ3QgdGVsbCB1cyBob3cgdG8gZGV0ZXJtaW5l IGl0LiANCiAgPC9GT05UPjwvU1BBTj48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0IHN0eWxlPSJNQVJHSU4tTEVGVDogNzJwdCI+PEZPTlQgc2l6ZT0zPjxTUEFOIA0K ICBzdHlsZT0iQ09MT1I6IGJsYWNrIj48U1BBTiBjbGFzcz00NzQ0MzUyMDAtMjkxMDIwMTA+PEZP TlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZj48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0ZP TlQ+Jm5ic3A7PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTi1MRUZU OiA3MnB0Ij48Rk9OVCBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJDT0xPUjogYmxhY2siPjxTUEFO IGNsYXNzPTQ3NDQzNTIwMC0yOTEwMjAxMD48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAw MGZmPkFjdHVhbGx5LCZuYnNwOyB0aGlzIA0KICBpc3N1ZSZuYnNwOzwvRk9OVD48L1NQQU4+PC9T UEFOPjwvRk9OVD48Rk9OVCBzaXplPTM+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiANCiAgc3R5bGU9 IkNPTE9SOiBibGFjayI+PFNQQU4gY2xhc3M9NDc0NDM1MjAwLTI5MTAyMDEwPjxGT05UIGNvbG9y PSMwMDAwZmY+aGFzIA0KICBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgcmVjZW50Jm5ic3A7SVRVIFNH MTUvcTExIG1lZXRpbmcgaGVsZCBpbiZuYnNwO1ZpbWVyY2F0ZSANCiAgaW4gU2VwdGVtYmVyIDIw MTAuIEZyb20gdGhlIDwvRk9OVD48L1NQQU4+PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iQ09MT1I6 IGJsYWNrIj48U1BBTiBjbGFzcz00NzQ0MzUyMDAtMjkxMDIwMTA+PEZPTlQgDQogIGNvbG9yPSMw MDAwZmY+bWVldGluZyByZXBvcnQsIHdlIGNhbiBzZWUgdGhhdCBpdCB3YXMmbmJzcDtkZWNpZGVk IHRoYXQgYSANCiAgcmVzaXphYmxlIE9EVWZsZXgoR0ZQKSBvY2N1cGllcyB0aGUgc2FtZSBudW1i ZXIgb2YgVFMgb24gZXZlcnkgbGluayBvZiB0aGUgDQogIHBhdGgsJm5ic3A7PEZPTlQgY29sb3I9 I2ZmMDAwMD5pbmRlcGVuZGVudGx5PC9GT05UPiBvZiB0aGUgSGlnaCBPcmRlciAoSE8pIA0KICBP UFVrIFRTIHJhdGUuIFRoYXQgaXM6PC9GT05UPjwvU1BBTj48L1NQQU4+PC9GT05UPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDcycHQiPjxG T05UIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkNPTE9SOiBibGFjayI+PFNQQU4gY2xhc3M9NDc0 NDM1MjAwLTI5MTAyMDEwPjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmY+74KfJm5i c3A7Rm9yJm5ic3A7Jm5ic3A7IG4gPSAxIOKApiA4Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KICBPRFVmbGV4ID0gbiAqIFRTKE9QVTIpPEJSPu+CnyZuYnNwO0ZvciZuYnNwOyZuYnNw OyBuID0gOSDigKYgMzImbmJzcDsmbmJzcDsmbmJzcDsgDQogIE9EVWZsZXggPSBuICogVFMoT1BV Myk8QlI+74KfJm5ic3A7Rm9yJm5ic3A7Jm5ic3A7IG4gPSAzMyDigKYgODAmbmJzcDsgT0RVZmxl eCA9IG4gDQogICogVFMoT1BVNCk8L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTi1MRUZUOiA3MnB0Ij48Rk9OVCBzaXpl PTM+PFNQQU4gDQogIHN0eWxlPSJDT0xPUjogYmxhY2siPjxTUEFOIGNsYXNzPTQ3NDQzNTIwMC0y OTEwMjAxMD48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmPlBsZWFzZSBzZWUgV0Qw NyZuYnNwO2FuZCB0aGUgbWVldGluZyByZXBvcnQgb2YgdGhpcyBtZWV0aW5nIGZvciANCiAgbW9y ZSBpbmZvcm1hdGlvbi4gVGhpcyBpcyB3aHkgd2UgYWRkZWQgYW4gZWRpdG9ycyBub3RlIHRvIHNh eSAiZm9yIGZ1cnRoZXIgDQogIHN0dWR5IiBhbmQgYWRkZWQgYW4gZWRpdG9ycycgbm90ZSBpbiBz ZWN0aW9uIDMuMS4xIG9mIFtPVE4gRldLXS4gDQogIDwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9O VD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDcycHQi PjxGT05UIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkNPTE9SOiBibGFjayI+PFNQQU4gY2xhc3M9 NDc0NDM1MjAwLTI5MTAyMDEwPjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmY+PC9G T05UPjwvU1BBTj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5U ZXh0IHN0eWxlPSJNQVJHSU4tTEVGVDogNzJwdCI+PEZPTlQgc2l6ZT0zPjxTUEFOIA0KICBzdHls ZT0iQ09MT1I6IGJsYWNrIj48U1BBTiBjbGFzcz00NzQ0MzUyMDAtMjkxMDIwMTA+PEZPTlQgZmFj ZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZj5XZSB3aWxsIHVwZGF0ZWQgaXQgYXMgc29vbiBhcyBH LjcwOSBpcyANCiAgdXBkYXRlZC48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTi1MRUZUOiA3MnB0Ij48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mz48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNr Ij48U1BBTiANCiAgY2xhc3M9NDc0NDM1MjAwLTI5MTAyMDEwPjwvU1BBTj48L1NQQU4+PC9GT05U PiZuYnNwOzwvUD48L0ZPTlQ+PC9TUEFOPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9 Ik1BUkdJTi1MRUZUOiA3MnB0Ij48U1BBTiANCiAgc3R5bGU9IkNPTE9SOiBibGFjayI+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTM+PC9GT05UPjwvU1BBTj4mbmJzcDs8L1A+DQogIDxQIGNsYXNzPU1z b1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDcycHQiPjxTUEFOIA0KICBzdHlsZT0iQ09M T1I6IGJsYWNrIj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mz48L0ZPTlQ+PG86cD48Rk9OVCBmYWNl PUFyaWFsIA0KICBzaXplPTM+PC9GT05UPjwvbzpwPjwvU1BBTj4mbmJzcDs8L1A+DQogIDxQIGNs YXNzPU1zb1BsYWluVGV4dD48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrIj5CZXN0IA0KICByZWdh cmRzLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxTUEFO IHN0eWxlPSJDT0xPUjogYmxhY2siPk51cml0PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjayI+PG86cD4mbmJzcDs8 L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PkZyb206 IGktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIA0KICBbbWFpbHRvOmktZC1hbm5vdW5jZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IA0KICBJbnRlcm5ldC1EcmFmdHNAaWV0 Zi5vcmc8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PlNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDIxLCAyMDEwIDM6MDAgQU08bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9 TXNvUGxhaW5UZXh0PlRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bzpwPjwvbzpwPjwvUD4NCiAg PFAgY2xhc3M9TXNvUGxhaW5UZXh0PlN1YmplY3Q6IEktRCANCiAgQWN0aW9uOmRyYWZ0LXpoYW5n LWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDktMDYudHh0IDxvOnA+PC9vOnA+PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1Bs YWluVGV4dD5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSANCiAgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxvOnA+PC9vOnA+PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1Bs YWluVGV4dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIFRpdGxlJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogDQog IEdlbmVyYWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpIFNpZ25h bGluZyBFeHRlbnNpb25zIGZvciANCiAgdGhlIGV2b2x2aW5nIEcuNzA5IE9wdGljYWwgVHJhbnNw b3J0IE5ldHdvcmtzIENvbnRyb2w8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgQXV0aG9yKHMpJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogRi4gWmhhbmcsIGV0IA0KYWwuPG86cD48L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQogIEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDogDQogIGRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDktMDYudHh0PG86 cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUGFnZXMgDQogICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogDQoyMTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBEYXRlJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDogDQogIDIwMTAtMTAtMjA8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxh aW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+UmVj ZW50IHByb2dyZXNzIGluIElUVS1UIFJlY29tbWVuZGF0aW9uIEcuNzA5IA0KICBzdGFuZGFyZGl6 YXRpb24gaGFzIDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+aW50cm9k dWNlZCBuZXcgT0RVIGNvbnRhaW5lcnMgKE9EVTAsIE9EVTQsIE9EVTJlIGFuZCANCiAgT0RVZmxl eCkgYW5kIDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+ZW5oYW5jZWQg T3B0aWNhbCBUcmFuc3BvcnQgTmV0d29ya2luZyAoT1ROKSBmbGV4aWJpbGl0eS4gDQogIFNldmVy YWwgPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwv bzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZuYnNwOzxvOnA+PC9vOnA+PC9QPg0K ICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jm5ic3A7PG86cD48L286cD48L1A+DQogIDxQIGNsYXNz PU1zb1BsYWluVGV4dD4mbmJzcDs8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZsdDtaaGFuZyZndDs8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJz cDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1Bs YWluVGV4dD5FeHBpcmVzIEFwcmlsIDIwMTE8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+ PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNw OzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNs YXNzPU1zb1BsYWluVGV4dD4mbmJzcDsgW3BhZ2UgMV0gPG86cD48L286cD48L1A+DQogIDxQIGNs YXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgDQogIGNsYXNzPU1z b1BsYWluVGV4dD5kcmFmdC16aGFuZy1jY2FtcC1nbXBscy1ldm9sdmluZy1nNzA5LTA2LnR4dDxv OnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48 L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Q bGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5P Y3RvYmVyIDIwMTAgPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpw PiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9v OnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+cmVjZW50IGRvY3VtZW50cyBoYXZlIHBy b3Bvc2VkIHdheXMgdG8gbW9kaWZ5IEdNUExTIA0KICBzaWduYWxpbmcgPG86cD48L286cD48L1A+ DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5wcm90b2NvbHMgdG8gc3VwcG9ydCB0aGVzZSBuZXcg T1ROIGZlYXR1cmVzLiZuYnNwOyANCiAgPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1Bs YWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0Pkl0 IGlzIGltcG9ydGFudCB0aGF0IGEgc2luZ2xlIHNvbHV0aW9uIGlzIGRldmVsb3BlZCBmb3IgDQog IHVzZSBpbiBHTVBMUyA8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PnNp Z25hbGluZyBhbmQgcm91dGluZyBwcm90b2NvbHMuIFRoaXMgc29sdXRpb24gbXVzdCANCiAgc3Vw cG9ydCBPRFVrIDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+bXVsdGlw bGV4aW5nIGNhcGFiaWxpdGllcywgYWRkcmVzcyBhbGwgb2YgdGhlIG5ldyANCiAgZmVhdHVyZXMs IGJlIDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+YWNjZXB0YWJsZSB0 byBhbGwgZXF1aXBtZW50IHZlbmRvcnMsIGFuZCBiZSBleHRlbnNpYmxlIA0KICBjb25zaWRlcmlu ZyA8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PmNvbnRpbnVlZCBPVE4g ZXZvbHV0aW9uLiZuYnNwOyA8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+VGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgdGhlIGV4dGVuc2lvbnMgdG8gdGhlIA0KICBHZW5lcmFsaXplZCBNdWx0 aS08bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PlByb3RvY29sIExhYmVs IFN3aXRjaGluZyAoR01QTFMpIHNpZ25hbGluZyB0byBjb250cm9sIA0KICB0aGUgZXZvbHZpbmcg PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5PcHRpY2FsIFRyYW5zcG9y dCBOZXR3b3JrcyAoT1ROKSBhZGRyZXNzaW5nIE9EVWsgDQogIG11bHRpcGxleGluZyBhbmQgbmV3 IDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+ZmVhdHVyZXMgaW5jbHVk aW5nIE9EVTAsIE9EVTQsIE9EVTJlIGFuZCANCiAgT0RVZmxleC48bzpwPjwvbzpwPjwvUD4NCiAg PFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1N c29QbGFpblRleHQ+QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6PG86cD48L286cD48 L1A+DQogIDxQIA0KICBjbGFzcz1Nc29QbGFpblRleHQ+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wNi50eHQ8 bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIA0KICBhdDo8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0PmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPG86cD48 L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PkJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5h YmxlIGEgTUlNRSBjb21wbGlhbnQgDQogIG1haWwgcmVhZGVyPG86cD48L286cD48L1A+DQogIDxQ IGNsYXNzPU1zb1BsYWluVGV4dD5pbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJp ZXZlIHRoZSBBU0NJSSANCiAgdmVyc2lvbiBvZiB0aGU8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0PkludGVybmV0LURyYWZ0LjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8 UD4NCiAgPEhSPg0KDQogIDxQPjwvUD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxCUj5DQ0FNUCBtYWlsaW5nIA0KICBsaXN0PEJSPkNDQU1QQGlldGYub3Jn PEJSPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8QlI+PC9CTE9D S1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_72ofORmMN6aFred3aRr1iA)-- From zhangfatai@huawei.com Fri Oct 29 00:54:31 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3863A6A1E for ; Fri, 29 Oct 2010 00:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.192 X-Spam-Level: * X-Spam-Status: No, score=1.192 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bYKnrqORs3M for ; Fri, 29 Oct 2010 00:54:30 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 917503A683B for ; Fri, 29 Oct 2010 00:54:29 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB1005F7KPOZZ@szxga02-in.huawei.com> for ccamp@ietf.org; Fri, 29 Oct 2010 15:56:13 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB100CTVKPO1S@szxga02-in.huawei.com> for ccamp@ietf.org; Fri, 29 Oct 2010 15:56:12 +0800 (CST) Received: from Z41162C ([10.70.76.101]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB1007IJKPOYD@szxml06-in.huawei.com> for ccamp@ietf.org; Fri, 29 Oct 2010 15:56:12 +0800 (CST) Date: Fri, 29 Oct 2010 15:56:12 +0800 From: Fatai Zhang To: Rajan Rao , Khuzema Pithewan , Mohit Misra , Ashok Kunjidhapatham Message-id: <02a501cb773e$c147ffb0$654c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <033801cb763c$b354b720$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E1DE49@SV-EXDB1.infinera.com> Cc: ccamp@ietf.org Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 07:54:31 -0000 SGkgUmFqYW4sDQoNCllvdSBzYWlkIHRoZXJlIGFyZSB0aGUgZm9sbG93aW5nIGRpZmZlcmVuY2Vz IGJldHdlZW4gdHdvIGRyYWZ0czoNCi0gIEcuNzA5IG11bHRpLXN0YWdlIG11bHRpcGxleGluZyAo djMgJiBiZXlvbmQpDQotICBOTUMgdHJlYXRtZW50IChyZWYgdG8gc2VjdGlvbi00IGluIHRoZSBk cmFmdCkNCi0gIFN1cHBvcnQgZm9yIFZDQVQgKE5WQyA+MSApDQotIFRQTiBmb3JtYXQNCg0KV2Ug aGF2ZSB0byByZXBlYXQgdGhhdCB0aGVyZSBpcyBub3QgbXVjaCBzdWJzdGFudGlhbCBkaWZmZXJl bmNlIGJldHdlZW4gdHdvIGRyYWZ0cyBleGNlcHQgbXVsdGktc3RhZ2UgbXV4aW5nLiANCg0KV2Ug ZG9uJ3Qgd2FudCB0byB0YWxrIG1vcmUgb24gIk5NQyIsICJOVkMiLCAiVFBOIiwgYmVjYXVzZSB0 aGV5IGhhdmUgYmVlbiBkaXNjdXNzZWQgYmVmb3JlIGFuZCBpdCBpcyBxdWl0ZSBlYXN5IGZvciBb ZHJhZnQtemhhbmddIHRvIGRvIHRoYXQuIEZvciBleGFtcGxlLCBmb3IgTk1DLCB0aGVyZSBpcyBh biBlZGl0b3JzIG5vdGUgaW4gdGhlIHByZXZpb3VzIHZlcnNpb25zICBzdWNoIGFzIDA0IHZlcnNp b24gdG8gZGlzY3VzcyBOTUMgc3R1ZmYgKGFuZCBzb21lIHBlb3BsZSBvcHBvc2VkIHRvIGRlcHJl Y2F0ZSBOTUMpLiBGb3IgTlZDLCBpdCBpcyBvYnZpb3VzbHkgdGhhdCBbZHJhZnQtemhhbmddIGNh biBzdXBwb3J0IGl0Lg0KDQpOb3cgd2UgY2FuIGZvY3VzIHlvdXIga2V5IGRyaXZlci1tdWx0aS1z dGFnZSBtdXhpbmcuDQoNCjEpIEF0IHBhZ2UgMywgaW4gdGhlIGxpc3Qgb2YgYWRkZWQgT1ROIGZl YXR1cmVzIGlzIHByZXNlbnQgZXhwbGljaXRseSB0aGUgIk11bHRpLXN0YWdlIE9EVSBNdWx0aXBs ZXhpbmciLiBBY3R1YWxseSwgbXVsdGktc3RhZ2UgaXMgbm90IHByZXNlbnQgYXQgYWxsIGFzIHJl cXVpcmVtZW50L2ZlYXR1cmUgaW4gRy43MDkuIE91ciBpbnRlbnRpb24gdG8gcG9zdHBvbmUgdGVj aG5pY2FsIHNvbHV0aW9uIHJlZ2FyZGluZyBtdWx0aS1zdGFnZSBtdWx0aXBsZXhpbmcgaXMganVz dGlmaWVkIGJ5IG9uIGdvaW5nIElUVS1UIFNHMTUgcHJvZ3Jlc3MuIEJlZm9yZSB0aGlua2luZyBh Ym91dCBzcGVjaWZpYyBzaWduYWxpbmcgYW5kIHJvdXRpbmcgc29sdXRpb25zIHdlIG5lZWQgdG8g aGF2ZSBzdGFibGUgSVRVLVQgcmVxdWlyZW1lbnRzLiBUaGlzIHdoeSBpbiBhbGwgb3VyIGNvbW1v biBkcmFmdHMgKEZXSywgSW5mby1Nb2RlbCwgUm91dGluZyBhbmQgU2lnbmFsaW5nIGRyYWZ0cykg d2UganVzdCBwbGFjZWQgc29tZSBwbGFjZWhvbGRlciBvbiB0aGUgc3ViamVjdC4NCg0KMikgV2Ug YXJlIGNvbmZ1c2VkIGJ5IHlvdXIgc2ltcGxpZmllZCBtdWx0aS1zdGFnZSBtdXhpbmcgbGFiZWwg ZGlzdHJpYnV0aW9uIHJ1bGUNCg0KVGhlcmUgaXMgbm8gZGV0YWlsZWQgdGV4dCB0byBkZXNjcmli ZSBtdWx0aS1zdGFnZSBtdXhpbmcgbGFiZWwgZGlzdHJpYnV0aW9uIHByb2NlZHVyZXMgaW4geW91 ciBkcmFmdCBhbmQgeW91ciBleHBsYWluYXRpb24gaW4geW91ciBiZWxvdyBtYWlsIGp1c3QgZm9j dXNlcyBvbiBvbmUgc2luZ2xlIG5vZGUgcmF0aGVyIHRoYW4gaG93IHRvIGNyZWF0ZSB0aGUgZW5k LXRvLWVuZCBMU1AuDQoNCkl0IGlzIGtub3duIHRoYXQgR01QTFMgc3RhbmRhcmQgcHJvY2VkdXJl IGltcG9zZSB0aGF0IGV2ZXJ5IG5vZGUgaGFzIHRvIGFsbG9jYXRlIGEgbGFiZWwvbGFiZWxzIGNv bnNpc3RlbnQgd2l0aCB0aGUgR2VuZXJhbGl6ZWQgTGFiZWwgUmVxdWVzdC4gVmVyeSBpbXBvcnRh bnQ6IEdlbmVyYWxpemVkIExhYmVsIFJlcXVlc3QgY2Fubm90IGJlIGNoYW5nZWQgZHVyaW5nIHNp Z25hbGluZyBwYXRoLg0KDQpGb3IgZXhhbXBsZSwgdGFraW5nIE9EVTEtT0RVMi1PRFUzIHR3by1z dGFnZSBtdXhpbmcsIHdoaWNoIG1lYW5zIHRoYXQgd2UgbmVlZCBhIHNlcnZpY2UgT0RVMSB0aGF0 IHdpbGwgYmUgbXV4ZWQgaW50byBPRFUyIGFuZCB0aGVuIE9EVTMuIEFzc3VtZSB0aGUgcGF0aCBp cyBBLUItQy1ELUUsIGluIG5vZGUgQiBhbmQgbm9kZSBEIHdpbGwgZmluaXNoIHRoZSB0d28tc3Rh Z2UgbXV4aW5nL2RlbXV4aW5nLiBIb3cgeW91IHRvIGNyZWF0ZSB0aGUgTFNQPyBob3cgeW91IHRv IGRpc3RyaWJ1dGUgdGhlIGxhYmVscyBpbiBOb2RlIEIsIEMsIEQ/IFdoYXQgaXMgdGhlIHRyYWZm aWMgcGFyYW1ldGVycyB3aWxsIGJlIHRyYW5zbWl0dGVkIGluIHRoZSBub2RlcyBCLCBDLCBEIGFu ZCBub2RlcyBBLCBFPw0KDQoNClRoYW5rcywNCg0KQXV0aG9ycyBvZiBbZHJhZnQtemhhbmctY2Nh bXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wNi50eHRdDQoNCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0gDQpGcm9tOiAiUmFqYW4gUmFvIiA8cnJhb0BpbmZpbmVyYS5jb20+DQpUbzog IkZhdGFpIFpoYW5nIiA8emhhbmdmYXRhaUBodWF3ZWkuY29tPjsgIktodXplbWEgUGl0aGV3YW4i IDxrcGl0aGV3YW5AaW5maW5lcmEuY29tPjsgIk1vaGl0IE1pc3JhIiA8bW1pc3JhQGluZmluZXJh LmNvbT47ICJBc2hvayBLdW5qaWRoYXBhdGhhbSIgPGFrdW5qaWRoYXBhdGhhbUBpbmZpbmVyYS5j b20+DQpDYzogPGNjYW1wQGlldGYub3JnPjsgIkJpYW8gTHUiIDxibHVAaW5maW5lcmEuY29tPg0K U2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjgsIDIwMTAgMjoxNyBQTQ0KU3ViamVjdDogUkU6IFtD Q0FNUF0gU2lnbmFsaW5nIGV4dGVuc2lvbnMgZm9yIEcuNzA5IC0gZHJhZnQta2h1emVtYS1jY2Ft cC1nbXBscy1zaWduYWxpbmctZzcwOS0wMC50eHQNCg0KDQpGYXRhaSwNCg0KUGxlYXNlIHNlZSBy ZXNwb25zZSBpbmxpbmUuDQoNCnRoYW5rcw0KUmFqYW4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IEZhdGFpIFpoYW5nIFt6aGFuZ2ZhdGFpQGh1YXdlaS5j b21dDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjcsIDIwMTAgNjowOCBQTQ0KVG86IFJhamFu IFJhbzsgS2h1emVtYSBQaXRoZXdhbjsgTW9oaXQgTWlzcmENCkNjOiBjY2FtcEBpZXRmLm9yZzsg WmhhbmcsIEZhdGFpDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBTaWduYWxpbmcgZXh0ZW5zaW9ucyBm b3IgRy43MDkgLSBkcmFmdC1raHV6ZW1hLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5LTAwLnR4 dA0KDQpIaSBSYWphbiwNCg0KSGFwcHkgdG8gc2VlIHlvdXIgZHJhZnQsIGJ1dCBleGNlcHQgbXVs dGktc3RhZ2UgbXV4aW5nIHN1cHBvcnRlZCBpbiB5b3VyIGRyYWZ0LCAgSSBkb24ndCBzZWUgYW55 IHN1YnN0YW50aWFsIGRpZmZlcmVuY2UgYmV0d2VlbiB5b3VyIGRyYWZ0IGFuZCBbZHJhZnQtemhh bmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wNi50eHRdLg0KDQpbUmFqYW5dew0KTXVsdGkg c3RhZ2UgbXV4aW5nIGlzIG9uZSBvZiB0aGUga2V5IGRyaXZlcnMgZm9yICBzaWduYWxpbmcgZXh0 ZW5zaW9ucy4gQW55IHNvbHV0aW9uIGlzIGluY29tcGxldGUgd2l0aG91dCB0aGlzLiBUaGUgbGFi ZWwgZm9ybWF0IHByb3Bvc2VkIGlzIGludGVuZGVkIHRvIHN1cHBvcnQgRy43MDktdjMgJiBmdXR1 cmUgT1ROIGV4dGVuc2lvbnMuIFNlY3Rpb24gNS4yIGluICBkcmFmdC1pZXRmLWNjYW1wLWdtcGxz LWc3MDktZnJhbWV3b3JrLTAzICB0b3VjaGVzIG9uIHRoaXMgYXNwZWN0ISENCiANCldlIHNlZSBm b2xsb3dpbmcga2V5IGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIGRyYWZ0czoNCiBPdXIgZHJhZnQg YWRkcmVzc2VzDQotICAgICAgICAgIEcuNzA5IG11bHRpLXN0YWdlIG11bHRpcGxleGluZyAodjMg JiBiZXlvbmQpDQotICAgICAgICAgIE5NQyB0cmVhdG1lbnQgKHJlZiB0byBzZWN0aW9uLTQgaW4g dGhlIGRyYWZ0KQ0KLSAgICAgICAgICBTdXBwb3J0IGZvciBWQ0FUIChOVkMgPjEgKQ0KfQ0KDQpZ b3UgbWF5IHNheSB0aGF0IFRQTiBpbmZvIGlzIGluY29ycG9yYXRlZCBpbnRvIGxhYmVsIE9iamVj dCwgYnV0IHlvdSBrbm93IGl0IGlzIGVhc3kgZm9yIFtkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1l dm9sdmluZy1nNzA5LTA2LnR4dF0gdG8gZG8gdGhhdCBhbmQgd2UgYWxyZWFkeSBzdGF0ZWQgaXQg aW4gdGhlIHNsaWRlcyBmb3IgSUVURjc4dGggbWVldGluZyAoIHdlIGp1c3QgbWFrZSB0aGUgZG9v ciBvcGVuIGF0IHRoaXMgbW9tZW50IGFuZCB0aGVyZSBhcmUgc29tZSBhZHZhbnRhZ2VzIHRvIGRl Y291cGxlIFRQTiBhbmQgTGFiZWwpLg0KDQpbUmFqYW5dew0KVGhlIGtleSB0aGluZyBoZXJlIGlz IHRoZSBtdXggbGF5ZXJzLiAgVGhlIFRQTiBpbiBsYWJlbCBvYmplY3QgaXMgaW50ZW5kZWQgdG8g YWRkcmVzcyBwZXIgbXV4IGxheWVyIGNhc2WFLiBtb3JlIGVmZmljaWVudC4gDQpJIHRoaW5rIHRo aXMgc2hvdWxkIGJlIGNhcHR1cmVkIGluIGZyYW1ld29yayBkb2MgKHNlY3Rpb24gMy4xLjIuMWlu IGZyYW1ld29yayBkb2MgZG9lc24ndCBjb3ZlciBoaWVyYXJjaHkgYXNwZWN0IGNsZWFybHkpLiAN Cn0NCg0KSW4gYWRkdGlvbiwgZm9yIG11bHRpLXN0YWdlIG11eGluZywgSSByZWFsbHkgc3VzcGVj dCB0aGF0IGl0IGNhbiBiZSByZXNvbHZlZCBzbyBlYXNpbHksIGJlY2F1c2UgaXQgaXMgTUxOIHN0 dWZmIGFuZCBpdCBuZWVkcyB0byBpbmRpY2F0ZSBob3cgdG8gY3JlYXRlIHRoZSBpbmZyYXN0cnVj dHVyZSBGQS1MU1AgKFNlZSBSRkM0MjA2IGFuZCA0MjA2YmlzKS4gSWYgaXQgY2FuIGJlIGRvbmUg aW4gdGhpcyB3YXkgYXMgeW91ciBkcmFmdCBkZXNjcmliZXMsIHdlIGFsbCB3aWxsIGJlIG11Y2gg aGFwcHkuDQoNCltSYWphbl17DQpUaGUgbGFiZWwgc3RydWN0dXJlIHdlIGhhdmUgZGVmaW5lZCBp cyB0byBhZGRyZXNzIG11eGluZyBsZXZlbHMgb2YgRy43MDkuICBUaGlzIGlzIG5vdCBzb2x2aW5n IE1MTiB1c2luZyBGQS4gaS5lLiBpdCBkb2VzbpJ0IHJlc3VsdCBpbiBjcmVhdGlvbiBvZiBGQSBh dXRvbWF0aWNhbGx5LiBUaGVyZSBpcyBubyBGQSBpbnZvbHZlZCBvciBpbnRlbmRlZCBoZXJlIChv dXQgb2Ygc2NvcGUpLiBQbGVhc2UgcmVmZXIgdG8gc2VjdGlvbi0zLjAgaW4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXNob2stY2NhbXAtZ21wbHMtb3NwZi1nNzA5Ly4N Cg0KIEZvciBleGFtcGxlLCAgd2UgbmVlZCAzIGxhYmVscyB0byBjcmVhdGUgYW4gT0RVMCBMU1Ag d2l0aCBmb2xsb3dpbmcgbXV4aW5nIHN0cnVjdHVyZSBvbiBhIGdpdmVuIFRlTGluaw0KIA0KTXV4 aW5nIGhpZXJhcmNoeSBvbiBhIFRlTGluazogT1RVMy1PRFUzLU9EVTItT0RVMS1PRFUwDQogDQpO dW0tb2YtbXV4LXN0YWdlcyA9IDMNClN0YWdlLTEgLSBMYWJlbCMxOiBmb3IgT0RVMiBsYXllciB3 aXRoIDggb3V0IG9mIDMyIGJpdHMgc2V0DQpTdGFnZS0yIC0gTGFiZWwjMjogZm9yIE9EVTEgbGF5 ZXIgd2l0aCAyIG91dCBvZiA4IGJpdHMgc2V0DQpTdGFnZS0zIC0gTGFiZWwjMzogZm9yIE9EVTAg bGF5ZXIgd2l0aCAxIG91dCBvZiAyIGJpdHMgc2V0DQogDQp9DQoNCg0KQmVzdCBSZWdhcmRzDQoN CkZhdGFpDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IFJhamFuIFJhbzxt YWlsdG86cnJhb0BpbmZpbmVyYS5jb20+DQpUbzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1w QGlldGYub3JnPg0KQ2M6IEtodXplbWEgUGl0aGV3YW48bWFpbHRvOmtwaXRoZXdhbkBpbmZpbmVy YS5jb20+IDsgTW9oaXQgTWlzcmE8bWFpbHRvOm1taXNyYUBpbmZpbmVyYS5jb20+DQpTZW50OiBX ZWRuZXNkYXksIE9jdG9iZXIgMjcsIDIwMTAgNToyNiBBTQ0KU3ViamVjdDogW0NDQU1QXSBTaWdu YWxpbmcgZXh0ZW5zaW9ucyBmb3IgRy43MDkgLSBkcmFmdC1raHV6ZW1hLWNjYW1wLWdtcGxzLXNp Z25hbGluZy1nNzA5LTAwLnR4dA0KDQpIaSwNCg0KV2UgaGF2ZSBhIGRyYWZ0IG9uIJNHTVBMUyBT aWduYWxpbmcgZXh0ZW5zaW9ucyBmb3IgT1ROlCBhdmFpbGFibGUgZm9yIHJldmlldy4gIEl0IGNh biBiZSBhY2Nlc3NlZCBmcm9tIHRoZSBmb2xsb3dpbmcgbGluazoNCmh0dHA6Ly93d3cuaW5maW5l cmEuY29tL3JmYy9kcmFmdC1raHV6ZW1hLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5LTAwLnR4 dA0KVGhlIGFib3ZlIGRyYWZ0IGlzIG5vdCBvbiBJRVRGIHJlcG9zaXRvcnkgYXMgd2UgbWlzc2Vk IHRoZSBzdWJtaXNzaW9uIGRlYWRsaW5lLiAgV2Ugd2lsbCBzdWJtaXQgdG8gSUVURiBhcyBzb29u IGFzIHBvc3NpYmxlLg0KDQpQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50Lg0KQWJzdHJhY3Q6DQpB cyBPVE4gbmV0d29yayBjYXBhYmlsaXRpZXMgY29udGludWUgdG8gZXZvbHZlLCB0aGVyZSBpcyBh biBpbmNyZWFzZWQgIG5lZWQgdG8gc3VwcG9ydCBHTVBMUyBjb250cm9sIGZvciB0aGUgc2FtZS4g W1JGQzQzMjhdIGludHJvZHVjZWQgR01QTFMgc2lnbmFsaW5nIGV4dGVuc2lvbnMgZm9yIHN1cHBv cnRpbmcgZWFybHkgdmVyc2lvbiBvZiBHLjcwOSBbRy43MDktdjFdLlRoZSBiYXNpYyByb3V0aW5n IGNvbnNpZGVyYXRpb25zIGZyb20gc2lnbmFsaW5nIHBlcnNwZWN0aXZlIGlzIGFsc28gc3BlY2lm aWVkIGluIFtSRkM0MzI4XS4NClRoZSByZWNlbnQgcmV2aXNpb24gb2YgSVRVLVQgUmVjb21tZW5k YXRpb24gRy43MDkgW0cuNzA5LXYzXSBhbmRbR1NVUC40M10gaGF2ZSBpbnRyb2R1Y2VkIG5ldyBP RFUgY29udGFpbmVycyAoYm90aCBmaXhlZCBhbmQgZmxleGlibGUpIGFuZCBhZGRpdGlvbmFsIE9E VSBtdWx0aXBsZXhpbmcgY2FwYWJpbGl0aWVzLCBlbmFibGluZyBzdXBwb3J0IGZvciBvcHRpbWFs IHNlcnZpY2UgYWdncmVnYXRpb24uDQpUaGlzIGRvY3VtZW50IGV4dGVuZHMgW1JGQzQzMjhdIHRv IHByb3ZpZGUgR01QTFMgc2lnbmFsaW5nIHN1cHBvcnQgZm9yIHRoZSBuZXcgT1ROIGNhcGFiaWxp dGllcyBkZWZpbmVkIGluIFtHLjcwOS12M10gYW5kIFtHU1VQLjQzXS4gVGhlIHNpZ25hbGluZyBl eHRlbnNpb25zIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGNhdGVycyB0byBPRFUgbGF5ZXIg c3dpdGNoaW5nIG9ubHkuIE9wdGljYWwgQ2hhbm5lbCBMYXllciBzd2l0Y2hpbmcgY29uc2lkZXJh dGlvbnMgaW4gW1JGQzQzMjhdIGFyZSBub3QgbW9kaWZpZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0K VGhhbmtzDQpBdXRob3JzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWls aW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NjYW1wDQo= From pietro_vittorio.grandi@alcatel-lucent.com Fri Oct 29 01:13:02 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD9F3A686E for ; Fri, 29 Oct 2010 01:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.366 X-Spam-Level: X-Spam-Status: No, score=-5.366 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXPGGVDbdFo9 for ; Fri, 29 Oct 2010 01:12:40 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id D565F3A6A15 for ; Fri, 29 Oct 2010 01:12:38 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9T8DVaA012834 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Oct 2010 10:13:37 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 29 Oct 2010 10:13:25 +0200 From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" To: Rajan Rao Date: Fri, 29 Oct 2010 10:13:22 +0200 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switching flags Thread-Index: Act1Brf5KGIS065lRrORP3/7GvHAwgAOk0bwABm8JIAAStCgAAAYubag Message-ID: References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05121@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05121@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D89B562FE4A5B341B18808FB8441CC7C0FEB08FDFRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" , Khuzema Pithewan , "Ashok@core3.amsl.com" Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switching flags X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 08:13:02 -0000 --_000_D89B562FE4A5B341B18808FB8441CC7C0FEB08FDFRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Rao, see in line. Pietro =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pietro Vittorio Grandi Terrestrial Optics Unit - System Architecture Alcatel-Lucent Vimercate (Italy) Tel: +39 039 686 4930 Mail: pietro_vittorio.grandi@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's rel= ativity. (A. Einstein) ________________________________ From: Rajan Rao [mailto:rrao@infinera.com] Sent: gioved=EC 28 ottobre 2010 21.36 To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); = Varma, Eve L (Eve) Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switc= hing flags Pietro, Starting a separate chain for Termination and Switching flags. These flags= are very confusing and seems H/W centric. We will address your other ques= tions in a separate email. The framework doc has this requirement in section 5.3 & I think this has le= d to T/S flags. "Support for differentiating between link multiplexing capacity and link rate capacity" Our interpretation of the above requirement is as follows. Please correct/e= xpand if this is not the case: 1. A given ODU service can consume full ODUk or an ODUj based on line= rate "k". 2. In case of ODUj, it can be anywhere in the muxing hierarchy depend= ing on the mux layers supported on the link. 3. The routing extensions should allow path computation on Te-links w= ith varying muxing hierarchy. Since we are all agreeing on advertising #ODUs, the above requirement is a= utomatically taken care. This is because, when we advertise ODU0, ODU1, OD= U2 bandwidth for an OTU3 link it does mean that interface is capable of ter= minating ODU3, ODU2 and ODU1. We do not see a need to explicitly convey th= is ("Termination") information in LSAs. [[PG]] It is no so. A line card can terminate e.g. an OTU-3 and not termi= nate ODU-2, ODU-1 and ODU-0 [[PG]] Moreover the assumption you make are not even valid for muxponder bo= ards. Just make an example of a muxponder board that demuxes ODU3-ODU2-ODU1= . These kind of boards would cost less if engineered in such a way that ODU-3= (and may be also ODU2) cannot be passed to the matrix. Questions: 1. Where is the need to advertise Termination for the above? 2. By advertising #ODUs, we are saying it is switchable & any HO-ODUs= are definitely terminate-able. [[PG]] I'll answer with an example: suppose that in a bundle link there are= both OTU-3 and OTU-4. In this case part of the ODU-3 resources are only switchable (the one carri= ed by ODU-4) and part are terminated or switchable (the ODU-3 resources car= ried by the OTU-3). If advertising does not distinguish between terminated and switchable resou= rces a misuse is possible due to the fact that on end points the matrix is = able to switch one layer and not two. Suppose that on an endpoint there is the need to switch an ODU-2 path carr= ied by an ODU-3 path. This is possible if the ODU-3 path is terminated on a= line card, the ODU 2 is extracted on the line card and sent to matrix for = switching. When setting up the ODU-3 path that will carry the ODU-2 path, care must b= e taken to ensure that on the end node of the ODU-3 path an ODU-3 that is = terminated is used. If a non terminated ODU-3 is used, like ODU3- carried by an OTU-4= , what happens is that the line card terminates the ODU-4 and is not able t= o extract the ODU-2 that is not directly visible because transported in an = ODU-3. If so, where is the need to advertise "Switching" flag? [[PG]] Please see before. Thanks Rajan From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) [mailto:pietro_vittorio.gra= ndi@alcatel-lucent.com] Sent: Thursday, October 28, 2010 1:31 AM To: Rajan Rao Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTORIO (P= IETRO VITTORIO); BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hello all, some considerations. 1) Draft Ashok states that Max LSP Bandwidth Number of OPU TSs =3D ------------------------- Min LSP Bandwidth This means that the MIN LSP Bandwidth is always set to the nominal size of = 1 TS. So it can have only two values 1.25 and 2.5 Gbit/s. The min LSP bandwidth for IETF should instead provide the minimum switching= capability. (see RFC4202) With the above relationship it seems that a NE that supporting ODU1 and hig= her rate containers and exporting interfaces with TS size =3D 1.25 Gbit/s should always declare= a Min LSP Bandwidth =3D to 1.25Gbit/s that is not corresponding to a supported switching capability. This behavior is absolutely independent from the fact that ODU-flex is supp= orted or not. 2) Snip: "Not clear what the issue is. We have listed 2 approaches in the slides se= nt out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero." We would like first to observe that the ashok draft does not report this sp= ecific behavior. Secondary we would make note that with this approach the MAX-LSP bandwidth in any cas= e should be interpreted differently when the ODU-flex capacity is exhausted. If you think to a bundle link with ODU-flex capacity, then when UDU-flex capacity is available the MAX-LSP bandwidth is used in a certain w= ay whereas when the ODU-flex capacity is exhausted the ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is differ= ent. we do not see a reason that motivates the introduction of this kind of comp= lication in routing. 3) Snip: Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } The original idea for GMPLS has been already discussed in the frame work do= cument draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only reference for requirements that have to be supported. Moreover, as required= by CCAMP chair an example of the difference in efficiency between the orig= inal IETF format and the new format is shown in the draft draft-bccdg-ccamp-gmpls-ospf-agno= stic. 4) Differentiation between termination and switching capabilities is a= requirement contained in the framework document. The differentiation allow= s an operator to engineer freely its network keeping into account capabilities offered by= current technology. Current technology allows switching only a stage at on= ce in the matrix. Of course this can be overcome with very costly muxponder boards that by th= e way could have limitations related to which containers can be terminated = and which can be only adapted and sent to matrix for switching. In general a routing specifi= cation must not force an operator to use costly solutions (multi-stage mult= iplexing) in order to operate the network. As a consequence the routing specification= must provide the means to allow manage the current technology indicating c= learly which are the capabilities of each interface in terms of termination= s and switching. Pietro & Sergio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pietro Vittorio Grandi Terrestrial Optics Unit - System Architecture Alcatel-Lucent Vimercate (Italy) Tel: +39 039 686 4930 Mail: pietro_vittorio.grandi@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's rel= ativity. (A. Einstein) ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: marted=EC 26 ottobre 2010 21.15 To: Fatai Zhang; Daniele Ceccarelli Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Fatai, Please see response inline, within { } Thanks Rajan From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Tuesday, October 26, 2010 5:11 AM To: Rajan Rao; Daniele Ceccarelli Cc: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, You said there are three differences between two drafts. Now, we are coming= much closer that there "may" be only one difference (i.e., backward compat= ibility) after Daniele gave some clarifications. Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces = Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backward compat= ibility. Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firs= tly, as Daniele already pointed it out, it is a big issue to advertise tha= t Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C,= however, for Node A(G.709 V1), it must always advertise a meaningful value= for the Max LSP bandwidth. {Rajan] { Not clear what the issue is. We have listed 2 approaches in the slides sen= t out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero. Please clarify if you have a different case in mind. } Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports OD= U2 switching only (an example in your draft), in this case, according to th= e regular routing process, it will make the routing path computation functi= on to understand that it can support ODU0 LSP. [Rajan] { No, we have not changed the meaning of "Minimum LSP BW". Please elaborate= on what is messed. Following RFC 4202/4201 meaning, the example you have listed works as follo= ws: MinLSP-BW =3D ODU1 ( G.709-v1 supports 2.5G) MaxLSP-BW =3D ODU2 ( Min(unreserved-BW, configured Max LSP size) as per R= FC 4202) If you are computing path for an ODU0 connection, the rule would be Odu0-LSP-BW >=3D MinLSP-BW && <=3D MaxLSP-BW The computation fails for the above. Where is it messed? Please provide a= concrete example. } Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } Fourth, it can not differentiate termination and swiching capability for yo= ur darft. [Rajan] { We do not see a need to advertise this info. We need to understand the use= cases requiring this. Are T/S bits addressing HW limitations? } I am trying to recall more reasons why we need to use a new sub-TLV rather = than the existing TLV, because we had lots of discussion before IETF78th me= eting through mailing list and F2F, but it is a little difficult for me to = dig more things from my memory at this moment, :-)~~~~ [Rajan] { Please list the justifications for changing original GMPLS model. } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: Daniele Ceccarelli Cc: Ong, Lyndon ; ccamp@ietf.org Sent: Tuesday, October 26, 2010 7:13 AM Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards = compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue - either support or don= 't support. Based on the WG agreement we could go either way without breaki= ng the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question= . - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where OD= Uflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-B= W. This can be easily accomplished with a sub-TLV for ODUflex signal type i= n our model. BW in bytes/sec, of course. Please refer to attached slides f= or details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This= is exactly the proposal we have in our draft. Good to see that you have mo= ved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ 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 --_000_D89B562FE4A5B341B18808FB8441CC7C0FEB08FDFRMRSSXCHMBSB1d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Rao,

 

see in line.

 

Pietro

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pietro Vittorio Grandi =
Terrestrial Optics Unit -  System Architecture
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930 <= br> Mail: pietro_vittorio.grandi@alcatel-lucent.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Put your hand on a hot stove for a minute, and it seems = like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

From:= Rajan Rao [mailto:rrao@infinera.com]
Sent: gioved=EC 28 ottobre 2= 010 21.36
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve)
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN - termination & switching flags<= font size=3D3 face=3D"Times New Roman">

 

Pietro,

 

Starting a separate chain for <= span style=3D'font-weight:bold'>Termination and Switching flags. = ; These flags are very confusing and seems H/W centric.  We will address your other questions in a separate email.

 

The framework doc has this require= ment in section 5.3 & I think this has led to T/S flags.

“Support for differentiating between link multiplexing capaci= ty and

 &nbs= p;    link rate capacity”

 = ;

Our interpretation of the above requirement is as follows. Please correct/expand if this is not the case:

1.<= font size=3D1 face=3D"Times New Roman">       A given ODU service can consume full O= DUk or an ODUj based on line rate “k”.

= 2.      = In case of ODU= j, it can be anywhere in the muxing hierarchy depending on the mux layers supported o= n the link.

= 3.      = The routing ex= tensions should allow path computation on Te-links with varying muxing hierarchy.

 

Since we are all agreeing on adver= tising #ODUs,  the above requirement is automatically taken care. This is because,  when we advertise ODU0, ODU1, ODU2 bandwidth for an OTU3 lin= k it does mean that interface is capable of terminating ODU3, ODU2 and ODU1.&nbs= p; We do not see a need to explicitly convey this (“Termination”) information in LSAs.

 

[[PG]] =A0It is no so. A =A0line card can termina= te e.g. an OTU-3 and not terminate ODU-2, ODU-1 and ODU-0

 

[[PG]] Moreover t= he assumption you make are not even valid for muxponder boards. Just make an example of a muxponder board that demuxes ODU3-ODU2-ODU1.

These kind of boa= rds would cost less if engineered in such a way that ODU-3 (and may be also ODU2) can= not be passed to the matrix.

 

Questions:

1. = ;      Where is the need to advertise Termina= tion for the above?

2. = ;      By advertising #ODUs, we are saying it= is switchable & any HO-ODUs are definitely terminate-able.

 =

[[PG]] I’ll= answer with an example: suppose that in a bundle link there are both OTU-3 and OTU= -4.
In this case part of the ODU-3 resources are only switchable (the one carri= ed by ODU-4) and part are terminated or switchable (the ODU-3 resources carrie= d by the OTU-3).

If advertising do= es not distinguish between terminated and switchable resources a misuse is possibl= e due to the fact that on end points the matrix is able to switch one layer

and not two.

Suppose that on a= n endpoint there is =A0the need to switch an ODU-2 path carried by an ODU-3 p= ath. This is possible if the ODU-3 path is terminated on a line card, the ODU 2 is extracted on the line card and sent to matrix for switching.

When setting up t= he ODU-3 path that will =A0carry the ODU-2 path, care must be taken to ensure that o= n the end node of the ODU-3 path =A0an ODU-3 that is terminated=

is used. =A0If a = non terminated ODU-3 is used, like ODU3- carried by an OTU-4, what happens is t= hat the line card terminates the ODU-4 and is not able to extract the ODU-2 tha= t is not directly visible because transported in an ODU-3.

=A0

=A0=A0=A0

 If so, where is the need to advertise “Switching” flag?

 =

[[PG]] Please see= before.

 =

 

Thanks

Rajan

 

=  

 

 

 

From:= GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) [mailto:pietro_vittorio.grandi@alcatel-lucent.com]
Sent: Thursday, October 28, = 2010 1:31 AM
To: Rajan Rao
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); BELOTTI, SER= GIO (SERGIO); Varma, Eve L (Eve)
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Hello all,

 

some considerations.

 

1) Draft Ashok states that

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   Max LSP Bandwidth

 

      Number of OPU TSs = =3D      -------------------------

 

        &= nbsp;           &nbs= p;                    &nb= sp;        Min LSP Bandwidth

 

This means that the MIN LSP Bandwidth is always s= et to the nominal size of 1 TS.

So it can have only two values 1.25 and 2.5 Gbit/= s.

The min LSP bandwidth for IETF should instead pro= vide the minimum switching capability. (see RFC4202)

 

With the above relationship it seems that a NE th= at supporting ODU1 and higher rate containers

and exporting interfaces with TS size =3D 1.25 Gb= it/s should always declare a Min LSP Bandwidth =3D to 1.25Gbit/s

that is not corresponding to a supported switchin= g capability.

 

This behavior is absolutely independent from the = fact that ODU-flex is supported or not.

 

2)      Snip:

 

“Not clear what the issue is.  We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:=

 With  backward compatib= ility option, the ODUflex goes in to a separate sub–TLV within SCCI. If ODU= flex is not supported on a link, this sub-TLV will not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become zero.”

 

We would like first to observe that the ashok dra= ft does not report this specific behavior. Secondary<= /p>

we would make note that with this approach the MAX-LSP bandwidth in any case should be interpreted differently<= /span>

when the ODU-flex capacity is exhausted.

If you think to a bundle link with ODU-flex capac= ity, then when

UDU-flex capacity is available the MAX-LSP bandwi= dth is used in a certain way whereas when the ODU-flex capacity is exhausted th= e

ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is different.

we do not see a reason that motivates the introduction of this kind of complication in routing.

 

3)      Snip:

Thirdly, it can not support priori= ty flexibility, so it is not efficient from the routing scalability perspectiv= e.

[Rajan] {=

The whole idea is to stay with the= GMPLS architecture already in place.  The technology specific extensions sho= uld go into SCSI. This has been done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a reason to deviation from the original G= MPLS model.

}

 

The original idea for GMPLS has been already discussed in the frame work document draft-ietf-ccamp-gmpls-g709-framework-= 03. The framework is the only

reference for requirements that have to be suppor= ted. Moreover, as required by CCAMP chair an example of the difference in effici= ency between the original IETF format

and the new format is shown in the  draft draft-bccdg-ccamp-gmpls-ospf-agnostic.  

 

4)      Differentiation= between termination and switching capabilities is a requirement contained in the framework document. The differentiation allows an operator

to engineer freely its network keeping into accou= nt capabilities offered by current technology. Current technology allows switc= hing only a stage at once in the matrix.

Of course this can be overcome with very costly muxponder boards that by the way could have limitations related to which containers can be terminated and which can be

only adapted and sent to matrix for switching. In general a routing specification must not force an operator to use costly solutions (multi-stage multiplexing)

in order to operate the network. As a consequence= the routing specification must provide the means to allow manage the current technology indicating clearly which are the capabilities of each interface = in terms of terminations and switching.

 

Pietro & Sergio

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pietro Vittorio Grandi =
Terrestrial Optics Unit -  System Architecture
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930 <= br> Mail: pietro_vittorio.grandi@alcatel-lucent.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Put your hand on a hot stove for a minute, and it seems = like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

From:= ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao
Sent: marted=EC 26 ottobre 2= 010 21.15
To: Fatai Zhang; Daniele Ceccarelli
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Fatai,

 

Please see response inline, within= { }

 

Thanks

Rajan

 

From:= Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Tuesday, October 26, 2= 010 5:11 AM
To: Rajan Rao; Daniele Cecca= relli
Cc: Ong, Lyndon; ccamp@ietf.= org
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Hi Rajan,

 <= /span>

You said there are three differences between two drafts. Now, we are coming much closer that there "may" be only one difference (i.e., backward compatibility) after Daniele gave some clarifications.

 <= /span>

Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibility, although it seems like that your draft "could" support backward compatibility. =

 <= /span>

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly,  as Daniele already pointed it out, it i= s a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUfl= ex supported for Node B/C, however, for Node A(G.709 V1), it must always adver= tise a meaningful value for the Max LSP bandwidth.

{Rajan] {=

Not clear what the issue is. = We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:

 With  backward compatib= ility option, the ODUflex goes in to a separate sub–TLV within SCCI. If ODU= flex is not supported on a link, this sub-TLV will not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become zero.

 

Please clarify if you have a diffe= rent case in mind.

}

 

Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which will make the path computation mes= sed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular routing process, it will mak= e the routing path computation function to understand that it can support ODU= 0 LSP.

[Rajan] {=

No, we have not changed the meanin= g of “Minimum LSP BW”.   Please elaborate on what is messe= d.   

Following RFC 4202/4201 meaning, t= he example you have listed works as follows:

 

MinLSP-BW =3D ODU1  ( G.709-v= 1 supports 2.5G)

MaxLSP-BW =3D ODU2  ( Min(unr= eserved-BW, configured Max LSP size)  as per RFC 4202)

 

If you are computing path for an O= DU0 connection, the rule would be

 

Odu0-LSP-BW >=3D MinLSP-BW &= ;& <=3D MaxLSP-BW

 

The computation fails for the abov= e.   Where is it messed? Please provide a concrete example.

}

 

Thirdly, it can not support priority flexibility,= so it is not efficient from the routing scalability perspective.

[Rajan] {=

The whole idea is to stay with the= GMPLS architecture already in place.  The technology specific extensions sho= uld go into SCSI. This has been done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a reason to deviation from the original G= MPLS model.

}

 

Fourth, it can not differentiate termination and swiching capability for your darft.

 [Rajan] {=

We do not see a need to advertise = this info.  We need to understand the use cases requiring this.  Are T= /S bits addressing HW limitations?

}

 

I am trying to recall more reasons why we need to= use a new sub-TLV rather than the existing TLV, because we had lots of discussi= on before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig more things from my memory at this moment, :-)~~~~<= /span>

 [Rajan] {

Please list the justifications for changing original GMPLS model.

}

Best Regards
 
Fatai
 

----- Original Message -----

Sent:<= /font> Tuesday, October 26, 2010 7:13 AM

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 <= /span>

Daniele,

 

Please see response inline, within { }.

 

Thanks

Rajan

 

-----Original Message-----

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Just a couple of comments on backward compatibil= ity and bandwidth advertisement.

 

- Backward compatibility: no ODU advertising is definded in RFC 4202/4203, so i believe there are no backward compatibility issues.

 

 

[Rajan]  {

Agree there is no ODU advertisement defined. The= need to address backwards compatibility depends on the following:

 

 1) are there RFC-4328 based deployments?

 2) If so, what do they use for BW advertis= ement?

 

Our fair guess is that ISCD is used for this as = per RFC 4202/4203.

 

There are 2 ways to address the compatibility is= sue – either support or don’t support. Based on the WG agreement we could go either way without breaking the model we have proposed. Please ref= er to attached slides for details.

 

}

 

Moreover in draft-ashok-ccamp-gmpls-ospf-g709 th= e MAX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisement, this is a backward compatibility issue in my opinion. It sta= tes that:

 

      "Encoding of= Max LSP Bandwidth is as follows:

       Max LSP Ban= dwidth =3D Unreserved-TS-Count x TS-Nominal-Rate"

 

[Rajan]  {

 

The unit here is in Bytes/sec. The description a= bove (& in our draft)

-    shows that nominal rate is dependent on specific ODU layer in question.

-    shows how Max LSP bandwidth number is derived at the advertisi= ng node.

}

 

Moreover it states:

 

      "If the inte= rface does not support ODU-flex service,

      this value should= be coded as zero".

 

But advertising max LSP bandwidth =3D 0 means di= scarding such link in the path computation process.

 

[Rajan] {

Good question & very valid. I think you are bringing up a scenario where ODUflex is not supported but backward compatibility is required.

 

What we need here is to separate ODUflex adverti= sement from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course.  Please refer to attached slides for details.

 

}

 

- Bandwidth advertisement: in the -04 version of= our draft the bandwidth is advertised as follows:

 

    - Unreserved bandwidth for fi= xed container in number of containers

    - Unreserved bandwidth for od= uflex in Bytes/sec

    - Max LSP bandwidth in Bytes/= sec.

 

[Rajan] {

We believe advertising the number of containers = is the right approach. This is exactly the proposal we have in our draft. Good to = see that you have moved away from TS approach which had serious limitations.

 

}

 

Advertising the unreserved bandwidth in number o= f containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

 

[Rajan] {

 

 The ODUflex uses bytes/sec in our draft.&n= bsp; There is no disagreement here.

 

}

BR

 

The authors

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounc= es@ietf.org] On Behalf Of Rajan Rao

Sent: venerd=EC 15 ottobre 2010 19.13=

To: Ong, Lyndon; ccamp@ietf.org

Subject: Re: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Lyndon,

 

Yes, we are aware of the existing draft. There a= re some fundamental differences in the model we have proposed from the existin= g draft. The key differences are the following:

 

1) This draft extends existing ISCD  Vs. de= fining a new one

    - addresses backward compatib= ility issues (RFC 4202)

 

2) ODU containers are advertised instead of #TSs=

     - simple path computati= on

 

3) Path computing node doesn't need to know per = link and/or per ODU layer TS granularity

     - again, simple & straight forward path computation 

 

Thanks

Rajan

 

-----Original Message-----

From: Ong, Lyndon [mailto:Lyong@Ciena.com]<= /o:p>

Sent: Thursday, October 14, 2010 7:45 AM

To: Rajan Rao; ccamp@ietf.org<= /font>

Subject: RE: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It would be helpful to understand if your draft is asking for similar extensions or different functionality.

 

Thanks,

 

Lyndon

 

 

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: Wednesday, October 13, 2010 2:40 PM

To: ccamp@ietf.org

Subject: [CCAMP] OSPF-TE extensions for G.709 OT= N draft submitted:

draft-ashok-ccamp-gmpls-ospf-g709-01<= /span>

 

Hi,

 

The following draft has been submitted. Please r= eview. Comments are appreciated.

 

https://datatracker.ietf.org/doc/draft-ashok-cca= mp-gmpls-ospf-g709/

 

thanks

Authors

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]

Sent: Wednesday, October 13, 2010 2:30 PM

To: Rajan Rao

Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuz= ema Pithewan

Subject: New Version Notification for=

draft-ashok-ccamp-gmpls-ospf-g709-01 =

 

 

A new version of I-D, draft-ashok-ccamp-gmpls-os= pf-g709-01.txt has been

successfully submitted by Rajan Rao and posted t= o the IETF repository.

 

Filename:   draft-ashok-ccamp-gmpls-ospf-g709

Revision:   01

Title:       =      OSPF TE Extensions for Generalized MPLS (GMPLS) Control

of G.709 Optical Transport Networks

Creation_date:    2010-10-12=

WG ID:            Independent Submission

Number_of_pages: 20

 

Abstract:

As OTN network capabilities continue to evolve, = there is an increased

need to support GMPLS control for the same. [RFC= 4328] introduced

GMPLS signaling extensions for supporting the ea= rly version of G.709

[G.709-v1]. The basic routing considerations fro= m signaling

perspective is also specified in [RFC4328].=

 

The recent revision of ITU-T Recommendation G.70= 9 [G.709-v3] and

[GSUP.43] have introduced new ODU containers (bo= th fixed and

flexible) and additional ODU multiplexing capabilities, enabling

support for optimal service aggregation.  <= o:p>

 

This document describes OSPF protocol extensions= to support

Generalized MPLS (GMPLS) control for routing ser= vices over the

standardized OTU/ODU containers in support of OD= U based TDM

switching. Routing support for Optical Channel L= ayer switching

(Lambda switching) is not covered in this docume= nt.

 

 

 

 

The IETF Secretariat.

 

 

_______________________________________________<= o:p>

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp=

 

_______________________________________________<= o:p>

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

--_000_D89B562FE4A5B341B18808FB8441CC7C0FEB08FDFRMRSSXCHMBSB1d_-- From pietro_vittorio.grandi@alcatel-lucent.com Fri Oct 29 02:19:38 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA383A6962 for ; Fri, 29 Oct 2010 02:19:38 -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=[AWL=-0.519, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loxFfr0KJBSq for ; Fri, 29 Oct 2010 02:19:17 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 4C8843A683A for ; Fri, 29 Oct 2010 02:19:15 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9T9InvN010218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Oct 2010 11:20:22 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 29 Oct 2010 11:20:08 +0200 From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" To: Rajan Rao Date: Fri, 29 Oct 2010 11:20:07 +0200 Thread-Topic: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: Act1Brf5KGIS065lRrORP3/7GvHAwgAOk0bwABm8JIAAT13ZYAAX4WkQ Message-ID: References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E051F8@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E051F8@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D89B562FE4A5B341B18808FB8441CC7C0FEB094EFRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "ccamp@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" , Khuzema Pithewan , Ashok, Daniele Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 09:19:38 -0000 --_000_D89B562FE4A5B341B18808FB8441CC7C0FEB094EFRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello in line and in RED to differentiate from previous statements.. Pietro =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pietro Vittorio Grandi Terrestrial Optics Unit - System Architecture Alcatel-Lucent Vimercate (Italy) Tel: +39 039 686 4930 Mail: pietro_vittorio.grandi@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's rel= ativity. (A. Einstein) ________________________________ From: Rajan Rao [mailto:rrao@infinera.com] Sent: venerd=EC 29 ottobre 2010 2.45 To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Fatai = Zhang; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve); Bi= ao Lu; Ashok Kunjidhapatham Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Pietro, et al Please see response inline Thanks Rajan From: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) [mailto:pietro_vittorio.gra= ndi@alcatel-lucent.com] Sent: Thursday, October 28, 2010 1:31 AM To: Rajan Rao Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTORIO (P= IETRO VITTORIO); BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve) Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hello all, some considerations. 1) Draft Ashok states that Max LSP Bandwidth Number of OPU TSs =3D ------------------------- Min LSP Bandwidth This means that the MIN LSP Bandwidth is always set to the nominal size of = 1 TS. So it can have only two values 1.25 and 2.5 Gbit/s. [Rajan] { Yes. This is correct. But the exact value is nominal rate depending on the= ODU layer involved. } The min LSP bandwidth for IETF should instead provide the minimum switching= capability. (see RFC4202) [Rajan] { We have only 2 TS variants defined for (Switching-Capability=3DTDM && Enc= oding=3DODUk ). Not sure what the comment is about. } [[PG]] The comment is about the fact that Min LSP bandwidth by RFC4202 has = to report the bandwidth associated to a switchable container. By G.709 Tributary Slots are not switchable containers, they are just a wa= y to partition bandwidth available on a link in such a way to have max flexibility. Their scope is limited to the link and are never = sent to the matrix. While nominal speed of the Tributary slots is dependent= from the server (e.g. ODU-3 TS has different size from ODU-2 TS), the ODU = speed is always the same independently from the server. This has to be the= reference for min LSP. } With the above relationship it seems that a NE that supporting ODU1 and hig= her rate containers and exporting interfaces with TS size =3D 1.25 Gbit/s should always declare= a Min LSP Bandwidth =3D to 1.25Gbit/s that is not corresponding to a supported switching capability. [Rajan] { This is not true. A link which is G.709-v1 based will advertise Min-LSP-BW= =3D2.5G (ODU1 rate) not 1.25G (ODU0 rate). Please ref to ODU0 example in th= e previous chain. [[PG]] I do not understand why you say so. The draft does not report that t= he relation is limited to G.709v1 interfaces. What I say happens always when a matrix does not support ODU0 switching. Again, the tributary= slot size by G.709 definition is not switched in matrix, and it has not t= o be considered as the equivalent of the ODU-1/ODU0. } This behavior is absolutely independent from the fact that ODU-flex is supp= orted or not. 2) Snip: "Not clear what the issue is. We have listed 2 approaches in the slides se= nt out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero." We would like first to observe that the ashok draft does not report this sp= ecific behavior. Secondary we would make note that with this approach the MAX-LSP bandwidth in any cas= e should be interpreted differently when the ODU-flex capacity is exhausted. If you think to a bundle link with ODU-flex capacity, then when UDU-flex capacity is available the MAX-LSP bandwidth is used in a certain w= ay whereas when the ODU-flex capacity is exhausted the ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is differ= ent. we do not see a reason that motivates the introduction of this kind of comp= lication in routing. [Rajan] { The ODUflex confusion may be due to lack of details from us. In the ppt se= nt earlier we mentioned about how to handle backward compatibility & ODUfle= x. The minor modifications are captured in our draft-02 version (section 5= .4.2). Please review and let us know if there are still any issues. http://www.infinera.com/rfc/draft-ashok-ccamp-gmpls-ospf-g709-02.txt } 3) Snip: Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } The original idea for GMPLS has been already discussed in the frame work do= cument draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only reference for requirements that have to be supported. Moreover, as required= by CCAMP chair an example of the difference in efficiency between the orig= inal IETF format and the new format is shown in the draft draft-bccdg-ccamp-gmpls-ospf-agno= stic. [Rajan] { We have shown in our draft that we can take care of OTN extensions in SCSI.= It doesn't make sense to have two ISCDs (ISCD+BA) for the same switching = type (=3DTDM). Unnecessary. } [[PG]] This is the reason why we have created an "agnostic" format . 4) Differentiation between termination and switching capabilities is a= requirement contained in the framework document. The differentiation allow= s an operator to engineer freely its network keeping into account capabilities offered by= current technology. Current technology allows switching only a stage at on= ce in the matrix. Of course this can be overcome with very costly muxponder boards that by th= e way could have limitations related to which containers can be terminated = and which can be only adapted and sent to matrix for switching. In general a routing specifi= cation must not force an operator to use costly solutions (multi-stage mult= iplexing) in order to operate the network. As a consequence the routing specification= must provide the means to allow manage the current technology indicating c= learly which are the capabilities of each interface in terms of termination= s and switching. [Rajan] { Responded in a separate chain on why we do not need T/S flags. } [[PG]] Responded in a separate chain on why this is needed. Pietro & Sergio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pietro Vittorio Grandi Terrestrial Optics Unit - System Architecture Alcatel-Lucent Vimercate (Italy) Tel: +39 039 686 4930 Mail: pietro_vittorio.grandi@alcatel-lucent.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's rel= ativity. (A. Einstein) ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: marted=EC 26 ottobre 2010 21.15 To: Fatai Zhang; Daniele Ceccarelli Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@= core3.amsl.com Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Fatai, Please see response inline, within { } Thanks Rajan From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Tuesday, October 26, 2010 5:11 AM To: Rajan Rao; Daniele Ceccarelli Cc: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, You said there are three differences between two drafts. Now, we are coming= much closer that there "may" be only one difference (i.e., backward compat= ibility) after Daniele gave some clarifications. Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces = Generalized-ISCD sub-TLV, so I think they have the same backward compatibil= ity, although it seems like that your draft "could" support backward compat= ibility. Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firs= tly, as Daniele already pointed it out, it is a big issue to advertise tha= t Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C,= however, for Node A(G.709 V1), it must always advertise a meaningful value= for the Max LSP bandwidth. {Rajan] { Not clear what the issue is. We have listed 2 approaches in the slides sen= t out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub= -TLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will = not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn't be= come zero. Please clarify if you have a different case in mind. } Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which wi= ll make the path computation messed. Assume OTU2 interface that supports OD= U2 switching only (an example in your draft), in this case, according to th= e regular routing process, it will make the routing path computation functi= on to understand that it can support ODU0 LSP. [Rajan] { No, we have not changed the meaning of "Minimum LSP BW". Please elaborate= on what is messed. Following RFC 4202/4201 meaning, the example you have listed works as follo= ws: MinLSP-BW =3D ODU1 ( G.709-v1 supports 2.5G) MaxLSP-BW =3D ODU2 ( Min(unreserved-BW, configured Max LSP size) as per R= FC 4202) If you are computing path for an ODU0 connection, the rule would be Odu0-LSP-BW >=3D MinLSP-BW && <=3D MaxLSP-BW The computation fails for the above. Where is it messed? Please provide a= concrete example. } Thirdly, it can not support priority flexibility, so it is not efficient fr= om the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. Th= e technology specific extensions should go into SCSI. This has been done su= ccessfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a r= eason to deviation from the original GMPLS model. } Fourth, it can not differentiate termination and swiching capability for yo= ur darft. [Rajan] { We do not see a need to advertise this info. We need to understand the use= cases requiring this. Are T/S bits addressing HW limitations? } I am trying to recall more reasons why we need to use a new sub-TLV rather = than the existing TLV, because we had lots of discussion before IETF78th me= eting through mailing list and F2F, but it is a little difficult for me to = dig more things from my memory at this moment, :-)~~~~ [Rajan] { Please list the justifications for changing original GMPLS model. } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: Daniele Ceccarelli Cc: Ong, Lyndon ; ccamp@ietf.org Sent: Tuesday, October 26, 2010 7:13 AM Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertise= ment. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, = so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards = compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue - either support or don= 't support. Based on the WG agreement we could go either way without breaki= ng the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields = of the ISCD are used for unreserved bandwidth advertisement, this is a back= ward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth =3D Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question= . - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth =3D 0 means discarding such link in the p= ath computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where OD= Uflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-B= W. This can be easily accomplished with a sub-TLV for ODUflex signal type i= n our model. BW in bytes/sec, of course. Please refer to attached slides f= or details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is= advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This= is exactly the proposal we have in our draft. Good to see that you have mo= ved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most su= itable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: venerd=EC 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differe= nces in the model we have proposed from the existing draft. The key differe= nces are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer T= S granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draf= t-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would= be helpful to understand if your draft is asking for similar extensions or= different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreci= ated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ 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 --_000_D89B562FE4A5B341B18808FB8441CC7C0FEB094EFRMRSSXCHMBSB1d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello

in line and in RED to differentiate from previous statements..

 

Pietro

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pietro Vittorio Grandi =
Terrestrial Optics Unit -  System Architecture
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930 <= br> Mail: pietro_vittorio.grandi@alcatel-lucent.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Put your hand on a hot stove for a minute, and it seems = like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

From:= Rajan Rao [mailto:rrao@infinera.com]
Sent: venerd=EC 29 ottobre 2= 010 2.45
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Fatai Zhang; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Varma, Eve L (Eve); Biao Lu; Ashok Kunjidhapatham=
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Pietro, et al

 

Please see response inline

 

Thanks

Rajan

 

From:= GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) [mailto:pietro_vittorio.grandi@alcatel-lucent.com]
Sent: Thursday, October 28, = 2010 1:31 AM
To: Rajan Rao
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com; Fatai Zhang; Daniele Ceccarelli; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); BELOTTI, SER= GIO (SERGIO); Varma, Eve L (Eve)
Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Hello all,

 

some considerations.

 

1) Draft Ashok states that

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   Max LSP Bandwidth

 

      Number of OPU TSs = =3D      -------------------------

 

        &= nbsp;           &nbs= p;                    &nb= sp;        Min LSP Bandwidth

 

This means that the MIN LSP Bandwidth is always s= et to the nominal size of 1 TS.

So it can have only two values 1.25 and 2.5 Gbit/= s.

[Rajan] {=

Yes. This is correct.  But th= e exact value is nominal rate depending on the ODU layer involved.=

}

The min LSP bandwidth for IETF should instead pro= vide the minimum switching capability. (see RFC4202)

[Rajan] {=

 We have only 2 TS variants d= efined for (Switching-Capability=3DTDM &&  Encoding=3DODUk ). Not sur= e what the comment is about.

}

[[PG]] The comment i= s about the fact that Min LSP bandwidth by RFC4202 has to report the bandwidt= h associated to a switchable container.

By G.709 Tributary S= lots =A0are not switchable containers, they are just a way to partition bandwidth avail= able on a link in such a way

to have max flexibil= ity. =A0Their scope is limited to the link and are never sent to the matrix. While nomina= l speed of the Tributary slots is dependent from the server (e.g. ODU-3 TS has different size from ODU-2 TS), the ODU speed is always the same independent= ly from the server. =A0This has to be the reference for min LSP.<= /font>

}

 

With the above relationship it seems that a NE th= at supporting ODU1 and higher rate containers

and exporting interfaces with TS size =3D 1.25 Gb= it/s should always declare a Min LSP Bandwidth =3D to 1.25Gbit/s

that is not corresponding to a supported switchin= g capability.

[Rajan] {=

This is not true.  A link which is G.709-v1 based will advert= ise Min-LSP-BW=3D2.5G (ODU1 rate) not 1.25G (ODU0 rate). Please ref to ODU0 exa= mple in the previous chain.

[[PG]] I do not unde= rstand why you say so. The draft does not report that the relation is limited to G.709v1 interfaces. What I say happens

always when a matrix= does not support ODU0 switching. =A0Again, the tributary slot size =A0by G.709 definition is not switched i= n matrix, and it has not to be considered as the equivalent of the ODU-1/ODU0= . =A0

}

 

This behavior is absolutely independent from the = fact that ODU-flex is supported or not.

 

2)      Snip:

 

“Not clear what the issue is.  We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:=

 With  backward compatib= ility option, the ODUflex goes in to a separate sub–TLV within SCCI. If ODU= flex is not supported on a link, this sub-TLV will not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become zero.”

 

We would like first to observe that the ashok dra= ft does not report this specific behavior. Secondary<= /p>

we would make note that with this approach the MAX-LSP bandwidth in any case should be interpreted differently<= /span>

when the ODU-flex capacity is exhausted.

If you think to a bundle link with ODU-flex capac= ity, then when

UDU-flex capacity is available the MAX-LSP bandwi= dth is used in a certain way whereas when the ODU-flex capacity is exhausted th= e

ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is different.

we do not see a reason that motivates the introduction of this kind of complication in routing.

 

[Rajan] {=

The ODUflex confusion may be due t= o lack of details from us.  In the ppt sent earlier we mentioned about how to handle backward compatibility & ODUflex.  The minor modifications = are captured in our draft-02 version (section 5.4.2).  Please review and l= et us know if there are still any issues.

http://www.infinera.com/rfc/draft-ashok-ccamp-gmpls-ospf-g709-02.txt=

 

}

 

 

3)      Snip:

Thirdly, it can not support priori= ty flexibility, so it is not efficient from the routing scalability perspectiv= e.

[Rajan] {=

The whole idea is to stay with the= GMPLS architecture already in place.  The technology specific extensions sho= uld go into SCSI. This has been done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a reason to deviation from the original G= MPLS model.

}

 

The original idea for GMPLS has been already discussed in the frame work document draft-ietf-ccamp-gmpls-g709-framework-= 03. The framework is the only

reference for requirements that have to be suppor= ted. Moreover, as required by CCAMP chair an example of the difference in effici= ency between the original IETF format

and the new format is shown in the  draft draft-bccdg-ccamp-gmpls-ospf-agnostic.  

[Rajan] {=

We have shown in our draft that we= can take care of OTN extensions in SCSI.  It doesn’t make sense to h= ave two ISCDs (ISCD+BA) for the same switching type (=3DTDM). Unnecessary.=

}

[[PG]] This is the reason why we have created an “agnostic” format . <= /span>

 

4)      Differentiation= between termination and switching capabilities is a requirement contained in the framework document. The differentiation allows an operator

to engineer freely its network keeping into accou= nt capabilities offered by current technology. Current technology allows switc= hing only a stage at once in the matrix.

Of course this can be overcome with very costly muxponder boards that by the way could have limitations related to which containers can be terminated and which can be

only adapted and sent to matrix for switching. In general a routing specification must not force an operator to use costly solutions (multi-stage multiplexing)

in order to operate the network. As a consequence= the routing specification must provide the means to allow manage the current technology indicating clearly which are the capabilities of each interface = in terms of terminations and switching.

[Rajan] {=

 Responded in a separate chai= n on why we do not need T/S flags.

}

 

[[PG]] Responded in a separate chain on why this is needed. =

 

Pietro & Sergio

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pietro Vittorio Grandi =
Terrestrial Optics Unit -  System Architecture
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930 <= br> Mail: pietro_vittorio.grandi@alcatel-lucent.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Put your hand on a hot stove for a minute, and it seems = like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

From:= ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao
Sent: marted=EC 26 ottobre 2= 010 21.15
To: Fatai Zhang; Daniele Ceccarelli
Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Fatai,

 

Please see response inline, within= { }

 

Thanks

Rajan

 

From:= Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Tuesday, October 26, 2= 010 5:11 AM
To: Rajan Rao; Daniele Cecca= relli
Cc: Ong, Lyndon; ccamp@ietf.= org
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709= -01

 

Hi Rajan,

 <= /span>

You said there are three differences between two drafts. Now, we are coming much closer that there "may" be only one difference (i.e., backward compatibility) after Daniele gave some clarifications.

 <= /span>

Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibility, although it seems like that your draft "could" support backward compatibility. =

 <= /span>

Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly,  as Daniele already pointed it out, it i= s a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUfl= ex supported for Node B/C, however, for Node A(G.709 V1), it must always adver= tise a meaningful value for the Max LSP bandwidth.

{Rajan] {=

Not clear what the issue is. = We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported:

 With  backward compatib= ility option, the ODUflex goes in to a separate sub–TLV within SCCI. If ODU= flex is not supported on a link, this sub-TLV will not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn’t become zero.

 

Please clarify if you have a diffe= rent case in mind.

}

 

Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which will make the path computation mes= sed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular routing process, it will mak= e the routing path computation function to understand that it can support ODU= 0 LSP.

[Rajan] {=

No, we have not changed the meanin= g of “Minimum LSP BW”.   Please elaborate on what is messe= d.   

Following RFC 4202/4201 meaning, t= he example you have listed works as follows:

 

MinLSP-BW =3D ODU1  ( G.709-v= 1 supports 2.5G)

MaxLSP-BW =3D ODU2  ( Min(unreserved-BW, configured Max LSP size)  as per RFC 4202)

 

If you are computing path for an O= DU0 connection, the rule would be

 

Odu0-LSP-BW >=3D MinLSP-BW &= ;& <=3D MaxLSP-BW

 

The computation fails for the abov= e.   Where is it messed? Please provide a concrete example.

}

 

Thirdly, it can not support priority flexibility,= so it is not efficient from the routing scalability perspective.

[Rajan] {=

The whole idea is to stay with the= GMPLS architecture already in place.  The technology specific extensions sho= uld go into SCSI. This has been done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a reason to deviation from the original G= MPLS model.

}

 

Fourth, it can not differentiate termination and swiching capability for your darft.

 [Rajan] {=

We do not see a need to advertise = this info.  We need to understand the use cases requiring this.  Are T= /S bits addressing HW limitations?

}

 

I am trying to recall more reasons why we need to= use a new sub-TLV rather than the existing TLV, because we had lots of discussi= on before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig more things from my memory at this moment, :-)~~~~<= /span>

 [Rajan] {

Please list the justifications for changing original GMPLS model.

}

Best Regards
 
Fatai
 

----- Original Message -----

Sent:<= /font> Tuesday, October 26, 2010 7:13 AM

Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 <= /span>

Daniele,

 

Please see response inline, within { }.

 

Thanks

Rajan

 

-----Original Message-----

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]

Sent: Friday, October 22, 2010 6:49 AM

To: Rajan Rao

Cc: Ong, Lyndon; ccamp@ietf.org

Subject: RE: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Just a couple of comments on backward compatibil= ity and bandwidth advertisement.

 

- Backward compatibility: no ODU advertising is definded in RFC 4202/4203, so i believe there are no backward compatibility issues.

 

 

[Rajan]  {

Agree there is no ODU advertisement defined. The= need to address backwards compatibility depends on the following:

 

 1) are there RFC-4328 based deployments?

 2) If so, what do they use for BW advertis= ement?

 

Our fair guess is that ISCD is used for this as = per RFC 4202/4203.

 

There are 2 ways to address the compatibility is= sue – either support or don’t support. Based on the WG agreement we could go either way without breaking the model we have proposed. Please ref= er to attached slides for details.

 

}

 

Moreover in draft-ashok-ccamp-gmpls-ospf-g709 th= e MAX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisement, this is a backward compatibility issue in my opinion. It sta= tes that:

 

      "Encoding of= Max LSP Bandwidth is as follows:

       Max LSP Ban= dwidth =3D Unreserved-TS-Count x TS-Nominal-Rate"

 

[Rajan]  {

 

The unit here is in Bytes/sec. The description a= bove (& in our draft)

-    shows that nominal rate is dependent on specific ODU layer in question.

-    shows how Max LSP bandwidth number is derived at the advertisi= ng node.

}

 

Moreover it states:

 

      "If the inte= rface does not support ODU-flex service,

      this value should= be coded as zero".

 

But advertising max LSP bandwidth =3D 0 means di= scarding such link in the path computation process.

 

[Rajan] {

Good question & very valid. I think you are = bringing up a scenario where ODUflex is not supported but backward compatibility is required.

 

What we need here is to separate ODUflex adverti= sement from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course.  Please refer to attached slides for details.

 

}

 

- Bandwidth advertisement: in the -04 version of= our draft the bandwidth is advertised as follows:

 

    - Unreserved bandwidth for fi= xed container in number of containers

    - Unreserved bandwidth for od= uflex in Bytes/sec

    - Max LSP bandwidth in Bytes/= sec.

 

[Rajan] {

We believe advertising the number of containers = is the right approach. This is exactly the proposal we have in our draft. Good to = see that you have moved away from TS approach which had serious limitations.

 

}

 

Advertising the unreserved bandwidth in number o= f containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex.

 

[Rajan] {

 

 The ODUflex uses bytes/sec in our draft.&n= bsp; There is no disagreement here.

 

}

BR

 

The authors

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: venerd=EC 15 ottobre 2010 19.13=

To: Ong, Lyndon; ccamp@ietf.org

Subject: Re: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Lyndon,

 

Yes, we are aware of the existing draft. There a= re some fundamental differences in the model we have proposed from the existin= g draft. The key differences are the following:

 

1) This draft extends existing ISCD  Vs. de= fining a new one

    - addresses backward compatib= ility issues (RFC 4202)

 

2) ODU containers are advertised instead of #TSs=

     - simple path computati= on

 

3) Path computing node doesn't need to know per = link and/or per ODU layer TS granularity

     - again, simple & straight forward path computation 

 

Thanks

Rajan

 

-----Original Message-----

From: Ong, Lyndon [mailto:Lyong@Ciena.com]<= /o:p>

Sent: Thursday, October 14, 2010 7:45 AM

To: Rajan Rao; ccamp@ietf.org<= /font>

Subject: RE: [CCAMP] OSPF-TE extensions for G.70= 9 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01

 

Hi Rajan,

 

Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt?  It would be helpful to understand if your draft is asking for similar extensions or different functionality.

 

Thanks,

 

Lyndon

 

 

 

-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao

Sent: Wednesday, October 13, 2010 2:40 PM

To: ccamp@ietf.org

Subject: [CCAMP] OSPF-TE extensions for G.709 OT= N draft submitted:

draft-ashok-ccamp-gmpls-ospf-g709-01<= /span>

 

Hi,

 

The following draft has been submitted. Please r= eview. Comments are appreciated.

 

https://datatracker.ietf.org/doc/draft-ashok-cca= mp-gmpls-ospf-g709/

 

thanks

Authors

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]

Sent: Wednesday, October 13, 2010 2:30 PM

To: Rajan Rao

Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuz= ema Pithewan

Subject: New Version Notification for=

draft-ashok-ccamp-gmpls-ospf-g709-01 =

 

 

A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been<= /p>

successfully submitted by Rajan Rao and posted t= o the IETF repository.

 

Filename:   draft-ashok-ccamp-gmpls-ospf-g709

Revision:   01

Title:       =      OSPF TE Extensions for Generalized MPLS (GMPLS) Control

of G.709 Optical Transport Networks

Creation_date:    2010-10-12=

WG ID:            Independent Submission

Number_of_pages: 20

 

Abstract:

As OTN network capabilities continue to evolve, = there is an increased

need to support GMPLS control for the same. [RFC= 4328] introduced

GMPLS signaling extensions for supporting the ea= rly version of G.709

[G.709-v1]. The basic routing considerations fro= m signaling

perspective is also specified in [RFC4328].=

 

The recent revision of ITU-T Recommendation G.70= 9 [G.709-v3] and

[GSUP.43] have introduced new ODU containers (bo= th fixed and

flexible) and additional ODU multiplexing capabi= lities, enabling

support for optimal service aggregation.  <= o:p>

 

This document describes OSPF protocol extensions= to support

Generalized MPLS (GMPLS) control for routing ser= vices over the

standardized OTU/ODU containers in support of OD= U based TDM

switching. Routing support for Optical Channel L= ayer switching

(Lambda switching) is not covered in this docume= nt.

 

 

 

 

The IETF Secretariat.

 

 

_______________________________________________<= o:p>

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp=

 

_______________________________________________<= o:p>

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

--_000_D89B562FE4A5B341B18808FB8441CC7C0FEB094EFRMRSSXCHMBSB1d_-- From zhangfatai@huawei.com Fri Oct 29 02:52:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D105A3A6845 for ; Fri, 29 Oct 2010 02:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.477 X-Spam-Level: * X-Spam-Status: No, score=1.477 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Feuzg+XKiab8 for ; Fri, 29 Oct 2010 02:52:02 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id EA9643A6821 for ; Fri, 29 Oct 2010 02:52:01 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB10016CQ5LAZ@szxga02-in.huawei.com> for ccamp@ietf.org; Fri, 29 Oct 2010 17:53:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB100FXUQ5LE1@szxga02-in.huawei.com> for ccamp@ietf.org; Fri, 29 Oct 2010 17:53:45 +0800 (CST) Received: from Z41162C ([10.70.76.101]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB1006L7Q5K3N@szxml06-in.huawei.com> for ccamp@ietf.org; Fri, 29 Oct 2010 17:53:45 +0800 (CST) Date: Fri, 29 Oct 2010 17:53:44 +0800 From: Fatai Zhang To: Young Lee , "PELOSO, PIERRE (PIERRE)" Message-id: <03d801cb774f$2c831160$654c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_jKY/KbkmrQyCPjIBfOVb2g)" X-Priority: 3 X-MSMail-priority: Normal References: <004901cb76c0$30999100$600c7c0a@china.huawei.com> Cc: 'CCAMP' Subject: Re: [CCAMP] Merging of the WSON specific OSPF extensions X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 09:52:04 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jKY/KbkmrQyCPjIBfOVb2g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgUGllcnJlIGFuZCBZb3VuZywNCg0KQSBmZXcgcG9pbnRzIGZvciBjbGFyaWZjaWF0aW9uLg0K DQpUaGVyZSBhcmUgdGhyZWUgT1NQRiBkcmFmdHMgcmVsYXRlZCB0byBXU09OOg0KDQooMSkgZHJh ZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYNCigyKSBkcmFmdC1w ZWxvc28tY2NhbXAtd3Nvbi1vc3BmLW9lby8NCigzKSBkcmFmdC16aGFuZy1jY2FtcC1nZW5lcmFs LWNvbnN0cmFpbnRzLW9zcGYtZXh0IA0KDQpGb3IgKDEpIGFuZCAoMiksIHRoZXkgYXJlIHRhbGtp bmcgYWJvdXQgV1NPTiBzcGVjaWZpYyByb3V0aW5nIHN0dWZmLCB3aGljaCAoc2hvdWxkKSBmb2xs b3cgW1dTT04tRW5jb2RlXS4gRm9yICgzKSwgaXQgaXMgZ2VuZXJpYyBzdHVmZiwgd2hpY2ggZm9s bG93cyBbR2VuZXJhbC1FbmNvZGVdLg0KDQpTbywgdG8gbWFrZSB0aGluZ3MgY2xlYXIsIEkgdGhp bmsgd2UgY2FuIGRpdmlkZSB0aGUgaXNzdWVzIGludG8gdHdvIHBpZWNlcy4gDQoNCigxKSBJcyB0 aGVyZSBhbnl0aGluZyBtaXNzZWQgaW4gW1dTT04tRW5jb2RlXSBhbmQgW0dlbmVyYWwtRW5jb2Rl XT8gDQoNCiAgICAgSWYgeWVzLCB0aGVuIGxpc3Qgd2hhdCBpcyBtaXNzZWQgYW5kIGdvIHRvIHRo ZXNlIGVuY29kaW5nIGRyYWZ0cyB0byByZWZpbmUgdGhlbS4gDQogICAgIA0KICAgICBJZiBubywg dGhlbiB3ZSBnbyB0byAoMikuDQoNCigyKSBGb2xsb3cgdGhlIFtXU09OLUVuY29kZV0gYW5kIFtH ZW5lcmFsLUVuY29kZV0gZHJhZnRzIHRvIGRlZmluZSBwcm90b2NvbCANCg0KRG9lcyBbZHJhZnQt aWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGZdIGZvbGxvdyBbV1NPTi1F bmNvZGVdPyBXaGF0IGlzIG1pc3NlZD8gDQpEb2VzIFtkcmFmdC1wZWxvc28tY2NhbXAtd3Nvbi1v c3BmLW9lb10gZm9sbG93IFtXU09OLUVuY29kZV0/IFdoYXQgc2hvdWxkIGJlIGFkZGVkIHRvICBb ZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGZdPw0KDQpEb2Vz IFtkcmFmdC16aGFuZy1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtZXh0XSBmb2xsb3cg W0dlbmVyYWwtRW5jb2RlXT8gDQoNClllcy4gV2hhdCBlbHNlIHNob3VsZCBiZSByZWZpbmVkPw0K DQoNCg0KDQoNCkJlc3QgUmVnYXJkcw0KIA0KRmF0YWkNCiANCiAgLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLSANCiAgRnJvbTogWW91bmcgTGVlIA0KICBUbzogJ0NDQU1QJyANCiAgU2VudDog RnJpZGF5LCBPY3RvYmVyIDI5LCAyMDEwIDEyOjUwIEFNDQogIFN1YmplY3Q6IFtDQ0FNUF0gTWVy Z2luZyBvZiB0aGUgV1NPTiBzcGVjaWZpYyBPU1BGIGV4dGVuc2lvbnMNCg0KDQogIEhpIFBpZXJy ZSwgDQoNCiAgIA0KDQogIFRoaXMgZW1haWwgaXMgdG8gZGlzY3VzcyB0aGUgcGVuZGluZyBpc3N1 ZXMgaW4gcmVnYXJkIHRvIG1lcmdpbmcgdHdvIGRyYWZ0cyB0aGF0IGRpc2N1c3NlcyBXU09OIHNw ZWNpZmljIE9TUEYgZXh0ZW5zaW9uczogDQoNCiAgIA0KDQogIEN1cnJlbnRseSB3ZSBoYXZlIG9u ZSBXRyBkcmFmdDoNCg0KICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS8uDQoNCiAgIA0KDQogIEFuZCB5b3Vy IGluZGl2aWR1YWwgZHJhZnQ6DQoNCiAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1wZWxvc28tY2NhbXAtd3Nvbi1vc3BmLW9lby8NCg0KICAgDQoNCldlIGFyZSBtb3JlIHRo YW4gaGFwcHkgdG8gaW5jb3Jwb3JhdGUgYW55IG5ldyBhZGRpdGlvbiBmcm9tIHlvdXIgZHJhZnQg aW50byB0aGUgYWZvcmVtZW50aW9uZWQgZXhpc3RpbmcgV0cgZHJhZnQuIExldCBtZSBzdW1tYXJp emVkIHRoZSBrZXkgaXNzdWVzIHdlIG5lZWQgdG8gZGlzY3VzcyBpbiB0aGUgZm9sbG93aW5nOiAg DQoNCiAgICBhLi4gSSB0aGluayB3ZSBhZ3JlZWQgb24gdGhlIGVuY29kaW5nIG9mIHRoZSBUTFYn cyB0aGF0IGFyZSBuZWNlc3NhcnkgZm9yIFdTT04gc3BlY2lmaWMgaW5mb3JtYXRpb24gYWNjb3Jk aW5nIHRvOiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAt cndhLXdzb24tZW5jb2RlLyANCiAgIA0KDQogICAgYS4uIExldCBtZSB0cnkgdG8gdW5kZXJzdGFu ZCB5b3VyIHJhdGlvbmFsZSB0byBjcmVhdGUgYSBuZXcgVG9wIExldmVsIFJCQSBUTFYuIFlvdXIg b3JpZ2luYWwgcmF0aW9uYWxlIGZvciBPLUUtTyBUTFYgKG9sZCBuYW1lIGZvciBSQkEgVExWKSB3 YXMgdG8gZGlmZmVyZW50aWF0ZSBkeW5hbWljIGluZm9ybWF0aW9uIGZyb20gc3RhdGljLiBCdXQg SSBkb24ndCBzZWUgeW91ciBvcmlnaW5hbCByYXRpb25hbGUgaW4geW91ciByZXZpc2lvbi4gSWYg dGhhdCBpcyBzdGlsbCBhbiBpbXBsaWNpdCByYXRpb25hbGUsIHlvdSBuZWVkIHRvIGNsZWFybHkg c3RhdGUgdGhhdC4gDQogICANCg0KICAgICAgYS4uIElmIHNvLCBGYXRhaSdzIGRyYWZ0IGNsZWFy bHkgc3RhdGUgdGhlIHdheSB0byBkaWZmZXJlbnRpYXRlIGR5bmFtaWMgaW5mbyBmcm9tIHN0YXRp YyBpbmZvIHVzaW5nIGFuIE9wYXF1ZSBMU0EgbWVjaGFuaXNtIGRpc2N1c3NlZCBpbiBTZWN0aW9u IDQgb2YgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLWdl bmVyYWwtY29uc3RyYWludC1lbmNvZGUvLiBJbiBzdWNoIGFzLCB3ZSBkb24ndCBuZWVkIHRvIGNy ZWF0ZSBhIG5ldyBUT1AgTGV2ZWwgVExWLiANCiAgIA0KDQogICAgICBhLi4gSWYgbm90LCBJIGFt IHN0aWxsIG5vdCBzdXJlIHdoeSB3ZSBuZWVkIGEgbmV3IFRPUCBUTFYuIA0KICAgDQoNCiAgICAg ICAgYS4uIFdoeSBub3QganVzdCB1c2UgdGhlIFRvcCBMZXZlbCBPU1BGIFRFIExTQSBub2RlIGF0 dHJpYnV0ZSBUTFYgd2hpY2ggaXMgZXhpc3RpbmcgVE9QIGxldmVsIFRMVj8gIFBsZWFzZSBsZXQg bWUga25vdyB3aHkgdGhpcyBUTFYgd291bGQgbm90IGJlIHByb3Blcj8gDQogICANCg0KtyAgICAg ICAgIE91ciBhcHByb2FjaCBpcyB0byBSRS11c2UgdGhlIE9TUEYgVEUgTFNBIG5vZGUgYXR0cmli dXRlIFRMViB1bmRlciB3aGljaCB3ZSBkZWZpbmUgYWxsIHRoZSBuZWNlc3Nhcnkgc3ViLVRMVnMu ICC3ICAgICAgICAgSSBzdGlsbCBoYXZlIHNvbWUgcHJvYmxlbSBhcyB0byB3aHkgeW91IHN0aWxs IGhhdmUgdGhlc2Ugc3ViLVRMVjogU3ViLVRMViBUeXBlICAgICAgIExlbmd0aCAgICAgTmFtZQ0K DQogICAgICAgVEJEICAgICAgICA0IEJ5dGVzICAgIFRFLW1ldHJpYyBbYWxpa2UgUkZDMzYzMF0N Cg0KICAgICAgIFRCRCAgICAgICAgNCBCeXRlcyAgICBBZG1pbmlzdHJhdGl2ZSBHcm91cCBbYWxp a2UgUkZDMzYzMF0NCg0KICAgICAgIFRCRCAgICAgICAgOCBCeXRlcyAgICBMaW5rIExvY2FsL1Jl bW90ZSBJZGVudGlmaWVycyBbYWxpa2UgUkZDNDIwM10NCg0KICAgICAgIFRCRCAgICAgICAgdmFy aWFibGUgICBTaGFyZWQgUmlzayBMaW5rIEdyb3VwIFthbGlrZSBSRkM0MjAzXQ0KDQq3ICAgICAg ICAgU2VjdGlvbiAyLjQgaXMgbm90IGNsZWFyIHRvIG1lLiAgWW91IGRpZG4ndCBpbmNsdWRlIHN1 Yi1UTFYgaW4gU2VjdGlvbiAyLiAgQXJlIHlvdSBzYXlpbmcgdGhhdCBjb25uZWN0aXZpdHkgbWF0 cml4IGlzIGEgcGFydCBvZiB5b3VyIFJCQSBUTFY/IEhvdyBpcyB0aGlzIGNvbm5lY3Rpdml0eSBt YXRyaXggZGlmZmVyZW50IGZyb20gdGhlIG9uZSBkZWZpbmVkIGluIHNlY3Rpb24gMy41IGluIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNv bnN0cmFpbnQtZW5jb2RlLyA/ICBSZWdhcmRzLEdyZWcgJiBZb3VuZyANCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgQ0NBTVAgbWFpbGluZyBsaXN0DQogIENDQU1QQGlldGYub3JnDQogIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== --Boundary_(ID_jKY/KbkmrQyCPjIBfOVb2g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9 Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCjxN RVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAuMjkxMiIgbmFtZT1HRU5FUkFUT1I+PCEtLVtp ZiAhbXNvXT4NCjxTVFlMRT52XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0N Cm9cOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0Kd1w6KiB7DQoJQkVIQVZJ T1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQouc2hhcGUgew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1 bHQjVk1MKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlmXS0tPg0KPFNUWUxFPg0KPCEtLQ0KIC8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsN CglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6 MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KaDENCgl7bWFyZ2luLXRvcDoxMi4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjMuMHB0Ow0KCW1hcmdpbi1sZWZ0Oi4zaW47DQoJdGV4dC1pbmRl bnQ6LS4zaW47DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCgltc28tbGlzdDpsMyBsZXZlbDEg bGZvMTsNCglmb250LXNpemU6MTYuMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OlRhaG9tYTt9DQpwLlN0eWxlMSwgbGkuU3R5bGUxLCBkaXYuU3R5 bGUxDQoJe21hcmdpbi10b3A6MTIuMHB0Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTozLjBwdDsNCgltYXJnaW4tbGVmdDouM2luOw0KCXRleHQtaW5kZW50Oi0uM2luOw0KCXBh Z2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzE7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5 OkFyaWFsOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5yZmNmaWd1cmUsIGxpLnJmY2ZpZ3VyZSwg ZGl2LnJmY2ZpZ3VyZQ0KCXttYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi4zaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWxpbmUtaGVpZ2h0OjEyLjBwdDsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAcGFnZSBTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEu MjVpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQogLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQzOTk1NTk3MjsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTc1MzI0MDE4IDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6OTMwNTA2 Njk4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDc1 Mzc1OTYgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjEuMGluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTAzOTA5MjI2OTsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYxODg5NDA4MCA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY4OSA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYw Qjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwzDQoJe21zby1saXN0LWlkOjE3OTIzNjA4Mjg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjEyODg0ODUwMDY7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1zdHlsZS1saW5rOiJI ZWFkaW5nIDEiOw0KCW1zby1sZXZlbC10ZXh0OiUxOw0KCW1zby1sZXZlbC10YWItc3RvcDouM2lu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDouM2luOw0K CXRleHQtaW5kZW50Oi0uM2luOw0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyIjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjRpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6LjRpbjsNCgl0ZXh0LWluZGVudDotLjRpbjsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTMiOw0K CW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDouNWluOw0KCXRleHQtaW5kZW50Oi0uNWluOw0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtdGV4dDoi JTFcLiUyXC4lM1wuJTQiOw0KCW1zby1sZXZlbC10YWItc3RvcDouNmluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDouNmluOw0KCXRleHQtaW5kZW50Oi0u NmluO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRc LiU1IjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjdpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6LjdpbjsNCgl0ZXh0LWluZGVudDotLjdpbjt9DQpAbGlz dCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNVwuJTYiOw0K CW1zby1sZXZlbC10YWItc3RvcDouOGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDouOGluOw0KCXRleHQtaW5kZW50Oi0uOGluO30NCkBsaXN0IGwzOmxl dmVsNw0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTciOw0KCW1z by1sZXZlbC10YWItc3RvcDouOWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDouOWluOw0KCXRleHQtaW5kZW50Oi0uOWluO30NCkBsaXN0IGwzOmxldmVs OA0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTdcLiU4IjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjEuMGluOw0KCXRleHQtaW5kZW50Oi0xLjBpbjt9DQpAbGlzdCBsMzps ZXZlbDkNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNVwuJTZcLiU3XC4lOFwu JTkiOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjFpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MS4xaW47DQoJdGV4dC1pbmRlbnQ6LTEuMWluO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPg0K PC9TVFlMRT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjIwNTAiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT48L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVTIHZMaW5rPXB1cnBsZSBsaW5rPWJsdWUgYmdD b2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkhpIFBpZXJyZSBhbmQgWW91bmcs PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbD5BIGZldyBwb2ludHMgZm9yIGNsYXJpZmNpYXRpb24uPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbD5UaGVyZSBhcmUgdGhyZWUgT1NQRiBkcmFmdHMgcmVsYXRlZCB0 byBXU09OOjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+KDEpIDxBIA0KaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL3dnL2NjYW1wL2RyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJp bGl0eS1vc3BmLyI+ZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9z cGY8L0E+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPigyKSA8VT48Rk9OVCAN CmNvbG9yPSMwMDAwZmY+ZHJhZnQtcGVsb3NvLWNjYW1wLXdzb24tb3NwZi1vZW8vPC9GT05UPjwv VT48L0ZPTlQ+PC9ESVY+DQo8RElWPigzKSA8QSANCmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9pZC9kcmFmdC16aGFuZy1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtZXh0LTAwLnR4 dCI+PEZPTlQgDQpmYWNlPUFyaWFsPmRyYWZ0LXpoYW5nLWNjYW1wLWdlbmVyYWwtY29uc3RyYWlu dHMtb3NwZi1leHQ8L0ZPTlQ+PC9BPjxGT05UIA0KZmFjZT1BcmlhbD4gPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbD5Gb3IgKDEpIGFuZCAoMiksIHRoZXkgYXJlIHRhbGtpbmcgYWJvdXQgV1NPTiBzcGVj aWZpYyANCnJvdXRpbmcgc3R1ZmYsIHdoaWNoIChzaG91bGQpIGZvbGxvdyZuYnNwO1tXU09OLUVu Y29kZV0uIEZvciAoMyksIGl0IGlzIGdlbmVyaWMgDQpzdHVmZiwgd2hpY2ggZm9sbG93cyBbR2Vu ZXJhbC1FbmNvZGVdLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+U28sIHRvIG1ha2UgdGhpbmdzIGNs ZWFyLCBJIHRoaW5rIHdlIGNhbiBkaXZpZGUgdGhlIGlzc3VlcyANCmludG8gdHdvIHBpZWNlcy4g PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbD4oMSkgSXMgdGhlcmUgYW55dGhpbmcmbmJzcDttaXNzZWQg aW4gW1dTT04tRW5jb2RlXSBhbmQgDQpbR2VuZXJhbC1FbmNvZGVdPyA8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsPiBJ ZiB5ZXMsIA0KdGhlbiBsaXN0IHdoYXQgaXMgbWlzc2VkIGFuZCBnbyB0byB0aGVzZSBlbmNvZGlu ZyBkcmFmdHMgdG8gcmVmaW5lIHRoZW0uIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIG5vLCB0aGVuIHdlIGdvIHRv IA0KKDIpLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+KDIpIEZvbGxvdyB0aGUgW1dTT04tRW5jb2Rl XSBhbmQgDQpbR2VuZXJhbC1FbmNvZGVdJm5ic3A7ZHJhZnRzIHRvIGRlZmluZSBwcm90b2NvbCA8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsPkRvZXMgWzxBIA0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL3dnL2NjYW1wL2RyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1v c3BmLyI+ZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGY8L0E+ XSANCmZvbGxvdyBbV1NPTi1FbmNvZGVdPyBXaGF0IGlzIG1pc3NlZD8gPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkRvZXMgWzxVPjxG T05UIA0KY29sb3I9IzAwMDBmZj5kcmFmdC1wZWxvc28tY2NhbXAtd3Nvbi1vc3BmLW9lb108L0ZP TlQ+PC9VPiBmb2xsb3cgW1dTT04tRW5jb2RlXT8gDQpXaGF0IHNob3VsZCBiZSBhZGRlZCB0byZu YnNwOyBbPEEgDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvY2NhbXAvZHJhZnQtaWV0 Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYvIj5kcmFmdC1pZXRmLWNjYW1w LXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZjwvQT5dPzwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPkRvZXMgWzxBIA0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2lkL2RyYWZ0LXpoYW5nLWNjYW1wLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi1leHQtMDAudHh0 Ij48Rk9OVCANCmZhY2U9QXJpYWw+ZHJhZnQtemhhbmctY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50 cy1vc3BmLWV4dDwvRk9OVD48L0E+XSBmb2xsb3cgDQpbR2VuZXJhbC1FbmNvZGVdPyA8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlllcy4gV2hhdCBlbHNlIHNob3VsZCBiZSByZWZpbmVk PzwvRElWPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxCUj5CZXN0IFJlZ2FyZHM8QlI+Jm5ic3A7PEJSPkZhdGFpPEJSPiZuYnNwOzwvRElWPg0K PEJMT0NLUVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVw eDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJH SU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7 Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNL R1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjog YmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9eWxlZUBodWF3ZWkuY29tIGhyZWY9Im1h aWx0bzp5bGVlQGh1YXdlaS5jb20iPllvdW5nIExlZTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9 IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWNjYW1wQGll dGYub3JnIA0KICBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPidDQ0FNUCc8L0E+IDwvRElW Pg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+ IEZyaWRheSwgT2N0b2JlciAyOSwgMjAxMCAxMjo1MCBBTTwvRElWPg0KICA8RElWIHN0eWxlPSJG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFtDQ0FNUF0gTWVyZ2lu ZyBvZiB0aGUgV1NPTiBzcGVjaWZpYyANCiAgT1NQRiBleHRlbnNpb25zPC9ESVY+DQogIDxESVY+ PEJSPjwvRElWPg0KICA8RElWIGNsYXNzPVNlY3Rpb24xPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SGkgUGllcnJlLCAN CiAgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5UaGlzIGVtYWlsIGlzIHRvIA0KICBkaXNj dXNzIHRoZSBwZW5kaW5nIGlzc3VlcyBpbiByZWdhcmQgdG8gbWVyZ2luZyB0d28gZHJhZnRzIHRo YXQgZGlzY3Vzc2VzIFdTT04gDQogIHNwZWNpZmljIE9TUEYgZXh0ZW5zaW9uczogPG86cD48L286 cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5h dnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg Rk9OVC1GQU1JTFk6IEFyaWFsIj5DdXJyZW50bHkgd2UgaGF2ZSBvbmUgDQogIFdHIGRyYWZ0Ojxv OnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48QSANCiAgdGl0bGU9aHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3Ry YWludC1lbmNvZGUvIA0KICBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS8iPmh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5j b2RlLzwvQT4uPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5BbmQgeW91ciBpbmRpdmlkdWFs IA0KICBkcmFmdDo8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEEgDQog IGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVsb3NvLWNjYW1w LXdzb24tb3NwZi1vZW8vIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBl bG9zby1jY2FtcC13c29uLW9zcGYtb2VvLzwvQT48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9 Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFN SUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD48UFJFPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tR0Igc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5XZSBhcmUgbW9yZSB0aGFuIGhhcHB5IHRvIGluY29ycG9y YXRlIGFueSBuZXcgYWRkaXRpb24gZnJvbSB5b3VyIGRyYWZ0IGludG8gdGhlIGFmb3JlbWVudGlv bmVkIGV4aXN0aW5nIFdHIGRyYWZ0LiBMZXQgbWUgc3VtbWFyaXplZCB0aGUga2V5IGlzc3VlcyB3 ZSBuZWVkIHRvIGRpc2N1c3MgaW4gdGhlIGZvbGxvd2luZzogPG86cD48L286cD48L1NQQU4+PC9G T05UPjwvUFJFPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1u YXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4N CiAgPFVMIHN0eWxlPSJNQVJHSU4tVE9QOiAwaW4iIHR5cGU9ZGlzYz4NCiAgICA8TEkgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSJDT0xPUjogbmF2eTsgbXNvLWxpc3Q6IGwyIGxldmVsMSBsZm8yIj48 Rk9OVCANCiAgICBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SSB0aGluayB3ZSBhZ3JlZWQg b24gdGhlIA0KICAgIGVuY29kaW5nIG9mIHRoZSBUTFaScyB0aGF0IGFyZSBuZWNlc3NhcnkgZm9y IFdTT04gc3BlY2lmaWMgaW5mb3JtYXRpb24gDQogICAgYWNjb3JkaW5nIHRvOiA8QSANCiAgICB0 aXRsZT1odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtcndh LXdzb24tZW5jb2RlLyANCiAgICBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLyI+aHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS88L0E+IA0KICAgIDxv OnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L0xJPjwvVUw+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8VUwgc3R5bGU9Ik1BUkdJTi1UT1A6IDBpbiIgdHlw ZT1kaXNjPg0KICAgIDxMSSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IkNPTE9SOiBuYXZ5OyBtc28t bGlzdDogbDIgbGV2ZWwxIGxmbzIiPjxGT05UIA0KICAgIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFy aWFsIj5MZXQgbWUgdHJ5IHRvIHVuZGVyc3RhbmQgeW91ciANCiAgICByYXRpb25hbGUgdG8gY3Jl YXRlIGEgbmV3IFRvcCBMZXZlbCBSQkEgVExWLiBZb3VyIG9yaWdpbmFsIHJhdGlvbmFsZSBmb3Ig DQogICAgTy1FLU8gVExWIChvbGQgbmFtZSBmb3IgUkJBIFRMVikgd2FzIHRvIGRpZmZlcmVudGlh dGUgZHluYW1pYyBpbmZvcm1hdGlvbiANCiAgICBmcm9tIHN0YXRpYy4gQnV0IEkgZG9uknQgc2Vl IHlvdXIgb3JpZ2luYWwgcmF0aW9uYWxlIGluIHlvdXIgcmV2aXNpb24uIElmIA0KICAgIHRoYXQg aXMgc3RpbGwgYW4gaW1wbGljaXQgcmF0aW9uYWxlLCB5b3UgbmVlZCB0byBjbGVhcmx5IHN0YXRl IHRoYXQuIA0KICAgIDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L0xJPjwvVUw+DQogIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8VUwgc3R5bGU9Ik1BUkdJ Ti1UT1A6IDBpbiIgdHlwZT1kaXNjPg0KICAgIDxVTCBzdHlsZT0iTUFSR0lOLVRPUDogMGluIiB0 eXBlPWNpcmNsZT4NCiAgICAgIDxMSSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IkNPTE9SOiBuYXZ5 OyBtc28tbGlzdDogbDIgbGV2ZWwyIGxmbzIiPjxGT05UIA0KICAgICAgZmFjZT1BcmlhbCBjb2xv cj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBBcmlhbCI+SWYgc28sIEZhdGFpknMgZHJhZnQgY2xlYXJseSANCiAgICAgIHN0YXRl IHRoZSB3YXkgdG8gZGlmZmVyZW50aWF0ZSBkeW5hbWljIGluZm8gZnJvbSBzdGF0aWMgaW5mbyB1 c2luZyBhbiANCiAgICAgIE9wYXF1ZSBMU0EgbWVjaGFuaXNtIGRpc2N1c3NlZCBpbiBTZWN0aW9u IDQgb2YgPEEgDQogICAgICB0aXRsZT1odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS8gDQogICAgICBocmVmPSJo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1j b25zdHJhaW50LWVuY29kZS8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLzwvQT4uIA0KICAgICAgSW4gc3Vj aCBhcywgd2UgZG9uknQgbmVlZCB0byBjcmVhdGUgYSBuZXcgVE9QIExldmVsIFRMVi4gDQogICAg ICA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9MST48L1VMPjwvVUw+DQogIDxQIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNzVpbiI+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj1uYXZ5IA0KICBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+DQogIDxVTCBzdHlsZT0iTUFSR0lOLVRPUDogMGluIiB0eXBlPWRpc2M+DQogICAgPFVM IHN0eWxlPSJNQVJHSU4tVE9QOiAwaW4iIHR5cGU9Y2lyY2xlPg0KICAgICAgPExJIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0iQ09MT1I6IG5hdnk7IG1zby1saXN0OiBsMiBsZXZlbDIgbGZvMiI+PEZP TlQgDQogICAgICBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5JZiBub3QsIEkgYW0gc3Rp bGwgbm90IHN1cmUgDQogICAgICB3aHkgd2UgbmVlZCBhIG5ldyBUT1AgVExWLiA8bzpwPjwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9MST48L1VMPjwvVUw+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8VUwgc3R5bGU9Ik1BUkdJTi1UT1A6IDBpbiIgdHlwZT1k aXNjPg0KICAgIDxVTCBzdHlsZT0iTUFSR0lOLVRPUDogMGluIiB0eXBlPWNpcmNsZT4NCiAgICAg IDxVTCBzdHlsZT0iTUFSR0lOLVRPUDogMGluIiB0eXBlPWRpc2M+DQogICAgICAgIDxMSSBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9IkNPTE9SOiBuYXZ5OyBtc28tbGlzdDogbDIgbGV2ZWwzIGxmbzIi PjxGT05UIA0KICAgICAgICBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAg ICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPldoeSBub3Qg anVzdCB1c2UgdGhlIFRvcCANCiAgICAgICAgTGV2ZWwgT1NQRiBURSBMU0Egbm9kZSBhdHRyaWJ1 dGUgVExWIHdoaWNoIGlzIGV4aXN0aW5nIFRPUCBsZXZlbCBUTFY/IA0KICAgICAgICAmbmJzcDtQ bGVhc2UgbGV0IG1lIGtub3cgd2h5IHRoaXMgVExWIHdvdWxkIG5vdCBiZSBwcm9wZXI/IA0KICAg ICAgICA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9MST48L1VMPjwvVUw+PC9VTD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJp YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PFBSRSBzdHlsZT0iTUFSR0lO LUxFRlQ6IDEuNWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgbXNvLWxpc3Q6IGwyIGxldmVsMyBs Zm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Rk9OVCBmYWNlPVN5bWJvbCBzaXplPTI+PFNQQU4g c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5bWJvbCI+PFNQQU4gc3R5bGU9 Im1zby1saXN0OiBJZ25vcmUiPrc8Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9MT48 U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPjwvRk9OVD48L1NQQU4+PC9T UEFOPjwvRk9OVD48IVtlbmRpZl0+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5PjxTUEFOIHN0 eWxlPSJDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5PdXIgYXBwcm9hY2ggaXMgdG8g UkUtdXNlIDwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbD48U1BBTiBzdHlsZT0iRk9OVC1G QU1JTFk6IEFyaWFsIj50aGUgT1NQRiBURSBMU0Egbm9kZSBhdHRyaWJ1dGUgVExWIHVuZGVyIHdo aWNoIHdlIGRlZmluZSBhbGwgdGhlIG5lY2Vzc2FyeSBzdWItVExWcy4gPG86cD48L286cD48L1NQ QU4+PC9GT05UPjwvUFJFPjxQUkU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluOyBURVhULUlO REVOVDogLTAuMjVpbjsgbXNvLWxpc3Q6IGwyIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExp c3RzXT48Rk9OVCBmYWNlPVN5bWJvbCBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IFN5bWJvbCI+PFNQQU4gc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPrc8 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9MT48U1BBTiBzdHlsZT0iRk9OVDogN3B0 ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9TUEFOPjwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9OVD48IVtlbmRpZl0+ PEZPTlQgZmFjZT1BcmlhbD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsIj5JIHN0aWxs IGhhdmUgc29tZSBwcm9ibGVtIGFzIHRvIHdoeSB5b3Ugc3RpbGwgaGF2ZSB0aGVzZSBzdWItVExW OjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1BSRT48UFJFPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86 cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUFJFPg0KICA8UCBjbGFzcz1yZmNmaWd1cmUg DQogIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0OyBQQUdFLUJSRUFLLUFGVEVSOiBhdXRvOyBN QVJHSU4tTEVGVDogMGluOyBNQVJHSU4tUklHSFQ6IDBpbjsgbXNvLW1hcmdpbi10b3AtYWx0OiAw aW4iPjxGT05UIA0KICBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05U LVNJWkU6IDEycHQiPlN1Yi1UTFYgDQogIFR5cGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTGVuZ3RoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBOYW1lPG86cD48L286 cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9cmZjZmlndXJlIA0KICBzdHlsZT0iTUFS R0lOLUJPVFRPTTogMTJwdDsgUEFHRS1CUkVBSy1BRlRFUjogYXV0bzsgTUFSR0lOLUxFRlQ6IDIx LjU1cHQ7IE1BUkdJTi1SSUdIVDogMGluOyBtc28tbWFyZ2luLXRvcC1hbHQ6IDBpbiI+PEZPTlQg DQogIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgVEJEJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQgQnl0ZXMmbmJzcDsmbmJzcDsmbmJzcDsgDQogIFRF LW1ldHJpYyBbYWxpa2UgUkZDMzYzMF08bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8 UCBjbGFzcz1yZmNmaWd1cmUgDQogIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0OyBQQUdFLUJS RUFLLUFGVEVSOiBhdXRvOyBNQVJHSU4tTEVGVDogMjEuNTVwdDsgTUFSR0lOLVJJR0hUOiAwaW47 IG1zby1tYXJnaW4tdG9wLWFsdDogMGluIj48Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXciIHNp emU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KICBUQkQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg NCBCeXRlcyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgQWRtaW5pc3RyYXRpdmUgR3JvdXAgW2FsaWtl IFJGQzM2MzBdPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9cmZjZmln dXJlIA0KICBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdDsgUEFHRS1CUkVBSy1BRlRFUjogYXV0 bzsgTUFSR0lOLUxFRlQ6IDIxLjU1cHQ7IE1BUkdJTi1SSUdIVDogMGluOyBtc28tbWFyZ2luLXRv cC1hbHQ6IDBpbiI+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTM+PFNQQU4gDQog IHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgVEJE Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDggQnl0ZXMmbmJzcDsm bmJzcDsmbmJzcDsgTGluayANCiAgTG9jYWwvUmVtb3RlIElkZW50aWZpZXJzIFthbGlrZSBSRkM0 MjAzXTxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPXJmY2ZpZ3VyZSAN CiAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQ7IFBBR0UtQlJFQUstQUZURVI6IGF1dG87IE1B UkdJTi1MRUZUOiAyMS41NXB0OyBNQVJHSU4tUklHSFQ6IDBpbjsgbXNvLW1hcmdpbi10b3AtYWx0 OiAwaW4iPjxGT05UIA0KICBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0zPjxTUEFOIGxhbmc9RU4t R0IgDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgVEJEJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhcmlhYmxl Jm5ic3A7Jm5ic3A7IFNoYXJlZCBSaXNrIA0KICBMaW5rIEdyb3VwIDwvU1BBTj5bYWxpa2UgUkZD NDIwM108L0ZPTlQ+PFNQQU4gDQpsYW5nPUVOLUdCPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48UFJF IHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBtc28tbGlz dDogbDAgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxGT05UIGZhY2U9U3ltYm9s IHNpemU9Mj48U1BBTiBsYW5nPUVOLUdCIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBTeW1ib2wiPjxTUEFOIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj63PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiBzaXplPTE+PFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3 IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+PCFbZW5kaWZdPjxGT05UIGZhY2U9 QXJpYWw+PFNQQU4gbGFuZz1FTi1HQiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsIj5TZWN0aW9u IDIuNCBpcyBub3QgY2xlYXIgdG8gbWUuICZuYnNwO1lvdSBkaWRuknQgaW5jbHVkZSBzdWItVExW IGluIFNlY3Rpb24gMi4gJm5ic3A7QXJlIHlvdSBzYXlpbmcgdGhhdCBjb25uZWN0aXZpdHkgbWF0 cml4IGlzIGEgcGFydCBvZiB5b3VyIFJCQSBUTFY/IEhvdyBpcyB0aGlzIGNvbm5lY3Rpdml0eSBt YXRyaXggZGlmZmVyZW50IGZyb20gdGhlIG9uZSBkZWZpbmVkIGluIHNlY3Rpb24gMy41IGluIDxB IHRpdGxlPWh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1n ZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLyBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS8iPmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0 cmFpbnQtZW5jb2RlLzwvQT4gPyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QUkU+PFBSRT48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBsYW5nPUVOLUdCIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05U PjwvUFJFPjxQUkU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gbGFuZz1FTi1HQiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPlJlZ2FyZHMsPG86cD48L286 cD48L1NQQU4+PC9GT05UPjwvUFJFPjxQUkU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4g bGFuZz1FTi1HQiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPkdy ZWcgJmFtcDsgWW91bmc8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QUkU+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hh cGV0eXBlIGlkPSJfeDAwMDBfdDc0IiBjb29yZHNpemU9IjIxNjAwLDIxNjAwIiANCiBvOnNwdD0i NzQiIHBhdGg9Im0xMDg2MCwyMTg3YzEwNDUxLDE3NDYsOTUyOSwxMDE4LDkwMTUsNzMwLDc4NjUs MTUyLDY2ODUsLDU0MTUsLDQxNzUsMTUyLDI5OTUsNTc1LDE5NjcsMTMwNSwxMTUwLDIxODcsNTc1 LDMyMjIsMjQyLDQyMjAsLDU0MTAsMjQyLDY1NjAsNTc1LDc1OTdsMTA4NjAsMjE2MDAsMjA5OTUs NzU5N3Y0ODUsLTEwMzcsNjA1LC0yMTg3LDQ4NSwtMzM3N2MyMTExNSwzMjIyLDIwNDIwLDIxODcs MTk2MzIsMTMwNSwxODU3NSw1NzUsMTc0MjUsMTUyLDE2Mjc1LCwxNTAwNSwsMTM3MzUsMTUyLDEy NzA1LDczMHYtNTI5LDI4OCwtMTQ1MSwxMDE2LC0xODQ1LDE0NTd4ZSI+DQogPHY6c3Ryb2tlIGpv aW5zdHlsZT0ibWl0ZXIiIC8+DQogPHY6cGF0aCBncmFkaWVudHNoYXBlb2s9InQiIG86Y29ubmVj dHR5cGU9ImN1c3RvbSIgbzpjb25uZWN0bG9jcz0iMTA4NjAsMjE4NzsyOTI4LDEwODAwOzEwODYw LDIxNjAwOzE4NjcyLDEwODAwIiANCiAgbzpjb25uZWN0YW5nbGVzPSIyNzAsMTgwLDkwLDAiIHRl eHRib3hyZWN0PSI1MDM3LDIyNzcsMTY1NTcsMTM2NzciIC8+DQo8L3Y6c2hhcGV0eXBlPjx2OnNo YXBlIGlkPSJEdHNTaGFwZU5hbWUiIG86c3BpZD0iX3gwMDAwX3MxMDI2IiB0eXBlPSIjX3gwMDAw X3Q3NCIgDQogYWx0PSI0N0U1MjlDRzA5N0Q1OTIwQDVCQjJDNUQyQkVENTQwNTA5N0A4aDg9QEBk TTYyNzkzISEhISEhQklIT0BdTTYyNzkzISEhMTExMTExMTExMTBCQ0dCRDM1MTlPbnNsYG0vZW51 ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhODBM OFo4O0Q4X002Mjc5MyEhISEhIUJJSE9AXW02Mjc5MyEhITExMTExMTExMTEwQkNHQkQzNTE5MTEw QkNHQkQzNTE5ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhITg2RzsmbHQ7OD0/OGBNNjI3OTMhISEhISFCSUhPQF1NNjI3OTMhISExMTExMTExMTExMEIz MjJDNzFENDExMEIzMjJDNzFENCEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISE4Oz87QTg7P0BATTYyNzkzISEhISEhQklIT0BdbTYyNzkzISEhMUA2QjFC NUIxMTBCMzIyQzcxRDQxMTBCMzIyQzcxRDQhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhITEhMSIgDQogc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdp bi1sZWZ0OjA7bWFyZ2luLXRvcDowO3dpZHRoOi4wNXB0O2hlaWdodDouMDVwdDsNCiB6LWluZGV4 OjE7dmlzaWJpbGl0eTpoaWRkZW4nPg0KIDx3OmFuY2hvcmxvY2svPg0KPC92OnNoYXBlPjwhW2Vu ZGlmXS0tPjwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPFA+DQogIDxIUj4NCg0KICA8UD48L1A+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Q0NBTVAgbWFp bGluZyANCiAgbGlzdDxCUj5DQ0FNUEBpZXRmLm9yZzxCUj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wPEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_jKY/KbkmrQyCPjIBfOVb2g)-- From daniele.ceccarelli@ericsson.com Fri Oct 29 04:55:51 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB453A693F for ; Fri, 29 Oct 2010 04:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp6aXWSHyt-N for ; Fri, 29 Oct 2010 04:55:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2AD023A6810 for ; Fri, 29 Oct 2010 04:55:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7b28ae00000135b-51-4ccab6b71f99 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D4.2F.04955.7B6BACC4; Fri, 29 Oct 2010 13:57:43 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.62]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 29 Oct 2010 13:57:43 +0200 From: Daniele Ceccarelli To: Lou Berger , "BELOTTI, SERGIO (SERGIO)" Date: Fri, 29 Oct 2010 13:57:41 +0200 Thread-Topic: R: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Thread-Index: Act20AHtlvT7Ot/gQtSLIEkYqajQggAeAiCg Message-ID: References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> <4CC96BEA.1000608@labn.net> <4CC9C44D.3060608@labn.net> In-Reply-To: <4CC9C44D.3060608@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Snigdho, "ccamp@ietf.org" , Bardalai , Khuzema, "Ong, Lyndon" , Pithewan , "Ashok@core3.amsl.com" Subject: Re: [CCAMP] R: OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 11:55:52 -0000 Hi Lou, PMFJI but I think it is worth making a clarification. We all know and believe that each solution must meet *both* framework requi= rements (technology specific ones) and CCAMP requirements (tecnohology agno= stic,reuse, scalability etc). The requirements defined in the framework ID = obviously do not address point (b) " it captures, or should even capture, a= ll CCAMP requirements" but absolutely do not aim at suggesting not to use c= ommon mechanisms. On the other hand since the framework draft can be surely improved, it just= has to represent a basic starting point for the information model analysis= . Any proposed technology specific format should be at least aligned with t= he framework content. I believe this was the intention that Pietro wanted t= o explain. Than the framework requirements are analyzed in the info model draft agains= t the CCAMP requirements. Such ID tries to explains what can be reused, wha= t needs to be extended and what should be replaced. RFC4202/3 could be pote= ntially extended to meet also all the framework requirements, but with evid= ent scalability and efficiency issues (an example is carried out in Section= 5 of http://tools.ietf.org/id/draft-bccdg-ccamp-gmpls-ospf-agnostic-00.txt= , where non technology specific requirements, like for example priority adv= ertisement, are considered). This is why an alternative solution is being d= iscussed.=20 Best Regards, Daniele -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: gioved=EC 28 ottobre 2010 20.43 To: BELOTTI, SERGIO (SERGIO) Cc: Rajan Rao; ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithe= wan; Ashok@core3.amsl.com; Daniele Ceccarelli; Fatai Zhang; GRANDI, PIETRO = VITTORIO (PIETRO VITTORIO) Subject: Re: R: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: d= raft-ashok-ccamp-gmpls-ospf-g709-01 Sergio, I think talking solutions is just fine. I was really reacting to "The fra= mework is the only reference for requirements that have to be supported". = It's not clear to me that the framework is (a) fully agreed upon, or (b) th= at it captures, or should even capture, all CCAMP requirements. It certain= ly should capture all technology-specific requirements. (Also, if the requ= irements end-up reading "don't use common mechanisms" then I personally thi= nk something is probably broken from a CCAMP perspective.) If you feel a point has been previously covered on the list, you certainly = can take advantage of the list archive and point to where the point was dis= cussed. Lou On 10/28/2010 9:02 AM, BELOTTI, SERGIO (SERGIO) wrote: > Hi Lou, > > I can take the action to answer your e-mail since I shared with him the c= ontent of Pietro's mail. > It seems to me our intention was exactly in the opposite direction of wha= t you interpreted. > We do not touch "how to communicate" but we just referenced requirements = and information needed to accomplish them. > We did not discuss about the format to communicate priority flexibility b= ut just remind requirement for that and why the need to have it was already= discussed and contained in two regular document one dealing with requireme= nt and the other one related to information to be communicated (not how) . > This seems completely in line with the path indicated in the slides your = referenced. > It was not absolutely in our intention jump directly to " decide on=20 > how existing mechanisms are to be reused and what technology-specific obj= ects are to be introduced" > > On the other hand I think it is correct to highlight when some drafts try= ing to propose format without taking into account requirement already discu= ssed. > > Thanks > > Sergio > > > > -----Messaggio originale----- > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto=20 > di Lou Berger > Inviato: gioved=EC 28 ottobre 2010 14.26 > A: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) > Cc: Rajan Rao; ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema=20 > Pithewan; Ashok@core3.amsl.com > Oggetto: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted:=20 > draft-ashok-ccamp-gmpls-ospf-g709-01 > > Pietro, > > I have a general comment, not on the specific drafts being discussed:=20 > I read your main and am left with the impression that you think that=20 > we need not make any attempt to leverage, to the maximum extent=20 > possible, what is already present in GMPLS. I don't believe this is=20 > the case, nor what the WG has agreed to. > > As has been said before, by the WG charter, the chairs and others, it=20 > is the mandate of CCAMP to developed "common" solutions wherever=20 > possible, not technology specific ones. As we covered in Maastrict,=20 > see http://www.ietf.org/proceedings/78/slides/ccamp-28/ccamp-28.htm ,=20 > the WG is still in the earlier stages of defining a GMPLS-based solution = for OTN. > > It seems to me, that this thread is really part of the "how=20 > information is to be communicated" discussion identified in slide 3=20 > (of ccamp-28.htm). Such discussions are an important step in the=20 > standardization cycle, and it's good that discussions on reuse are=20 > underway and continue. > > But, please keep in mind that once there is agreement on requirements=20 > and information to be communicated, we can then decided how to=20 > communicate the information and agree on how we "Maximizing reuse of=20 > existing mechanisms". Maximizing reuse is an important optimization=20 > and generalization step in the CCAMP standardization cycle. (as has=20 > been done before for each of technologies supported by GMPLS.) > > The WG has not yet decided on how existing mechanisms are to be reused=20 > and what technology-specific objects are to be introduced. So please=20 > don't cut short any discussion on re-use. > > Much thanks, > Lou > > PS Again, this is not an endorsement of any specific draft or proposal. > > On 10/28/2010 4:30 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote: >> 3) Snip: >> >> Thirdly, it can not support priority flexibility, so it is not=20 >> efficient from the routing scalability perspective. >> >> [Rajan] { >> >> The whole idea is to stay with the GMPLS architecture already in place. >> The technology specific extensions should go into SCSI. This has been=20 >> done successfully for SONET/SDH case (Ref to examples in RFC 4202).=20 >> Do not see a reason to deviation from the original GMPLS model. >> >> } >> >> The original idea for GMPLS has been already discussed in the frame=20 >> work document draft-ietf-ccamp-gmpls-g709-framework-03. The framework=20 >> is the only >> >> reference for requirements that have to be supported. Moreover, as=20 >> required by CCAMP chair an example of the difference in efficiency=20 >> between the original IETF format >> >> and the new format is shown in the draft=20 >> draft-bccdg-ccamp-gmpls-ospf-agnostic. >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From loa@pi.nu Fri Oct 29 07:58:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9B83A6A71; Fri, 29 Oct 2010 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkQS-hYaZWua; Fri, 29 Oct 2010 07:58:17 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 8C7FD3A6944; Fri, 29 Oct 2010 07:58:17 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 6E6C0514027; Fri, 29 Oct 2010 17:00:10 +0200 (CEST) Message-ID: <4CCAE17A.1030606@pi.nu> Date: Fri, 29 Oct 2010 17:00:10 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "mpls@ietf.org" , pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, CCAMP , MPLS-TP ad hoc team , "mpls-tp@ietf.org" Subject: [CCAMP] change of meeting times for mpls and pwe3 in Beijing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 14:58:18 -0000 MPLS and PWE3 wg, we are doing a late swap of agenda slots for the mpls and pwe3 working groups at the IETF in Beijing. The mpls working group will be meeting: Monday 15.10 - 16.10 Wednesday 9.00 - 11.30 The pwe3 working group will be meeting: Monday 9.00 - 11.30 Monday 13.00 - 15.00 We don't know if this will be captured on the printed agenda, but the online agenda has been changed and we will make sure that it will be on the IETF message board. Loa for the MPLS and PWE3 chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Fri Oct 29 08:05:54 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C2B3A684A; Fri, 29 Oct 2010 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeEL8C9+MqlC; Fri, 29 Oct 2010 08:05:54 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id D78A93A6831; Fri, 29 Oct 2010 08:05:53 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 97F7751403A; Fri, 29 Oct 2010 17:07:47 +0200 (CEST) Message-ID: <4CCAE343.5030809@pi.nu> Date: Fri, 29 Oct 2010 17:07:47 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "mpls@ietf.org" , pwe3@ietf.org References: <4CCAE17A.1030606@pi.nu> In-Reply-To: <4CCAE17A.1030606@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, CCAMP , MPLS-TP ad hoc team , "mpls-tp@ietf.org" Subject: Re: [CCAMP] [mpls-tp] change of meeting times for mpls and pwe3 in Beijing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 15:05:55 -0000 All, I've obviously not be looking at the agenda closely enough! The second mpls wg meeting will Thursday - so: Monday 15.10 - 16.10 Thursday 9.00 - 11.30 for the mpls wg /Loa On 2010-10-29 17:00, Loa Andersson wrote: > MPLS and PWE3 wg, > > we are doing a late swap of agenda slots for the mpls and pwe3 > working groups at the IETF in Beijing. > > The mpls working group will be meeting: > > Monday 15.10 - 16.10 > Wednesday 9.00 - 11.30 > > The pwe3 working group will be meeting: > > Monday 9.00 - 11.30 > Monday 13.00 - 15.00 > > We don't know if this will be captured on the printed agenda, but the > online agenda has been changed and we will make sure that it will be > on the IETF message board. > > Loa > > for the MPLS and PWE3 chairs > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From lberger@labn.net Fri Oct 29 08:34:40 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3323A6953 for ; Fri, 29 Oct 2010 08:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGusJrkZC1pZ for ; Fri, 29 Oct 2010 08:34:39 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id BDBAB3A688A for ; Fri, 29 Oct 2010 08:34:38 -0700 (PDT) Received: (qmail 29329 invoked by uid 0); 29 Oct 2010 15:36:32 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 29 Oct 2010 15:36:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=nOSOBxloFu/anw3kzI69xDr+9+rxk+i3vbGXBOj+iqEXIzYA4XUJjGqjouZVd1N7EnUwIuNLIbVZl6XuT6LRdrxwcVlN7NgvSncemnzl6JxxlBtYkaQSLAydC0FmEH1D; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PBr0I-0007mw-VF; Fri, 29 Oct 2010 09:36:32 -0600 Message-ID: <4CCAEA00.8060403@labn.net> Date: Fri, 29 Oct 2010 11:36:32 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Daniele Ceccarelli References: <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95CCD3@SV-EXDB1.infinera.com> <0AFD1B67B949784DA087CDA9F0DD4AD901FCFF4E@mdmxm03.ciena.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA692E95D024@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04BF1@SV-EXDB1.infinera.com> <01e401cb7506$c996ade0$654c460a@china.huawei.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E04D30@SV-EXDB1.infinera.com> <4CC96BEA.1000608@labn.net> <4CC9C44D.3060608@labn.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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@ietf.org" , Snigdho Bardalai , "Ong, Lyndon" , Khuzema Pithewan , "Ashok@core3.amsl.com" Subject: Re: [CCAMP] R: OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 15:34:40 -0000 Daniele, I think we're in agreement here. Discussion of ALL solutions at this point seems just right to me too. I don't think we've reach the point of throwing out any specific encoding formats and this was really my point. Again, my comments are general comments, and should not be taken as supporting or endorsing any specific proposal. Thanks, Lou On 10/29/2010 7:57 AM, Daniele Ceccarelli wrote: > Hi Lou, > > PMFJI but I think it is worth making a clarification. > > We all know and believe that each solution must meet *both* framework requirements (technology specific ones) and CCAMP requirements (tecnohology agnostic,reuse, scalability etc). The requirements defined in the framework ID obviously do not address point (b) " it captures, or should even capture, all CCAMP requirements" but absolutely do not aim at suggesting not to use common mechanisms. > > On the other hand since the framework draft can be surely improved, it just has to represent a basic starting point for the information model analysis. Any proposed technology specific format should be at least aligned with the framework content. I believe this was the intention that Pietro wanted to explain. > > Than the framework requirements are analyzed in the info model draft against the CCAMP requirements. Such ID tries to explains what can be reused, what needs to be extended and what should be replaced. RFC4202/3 could be potentially extended to meet also all the framework requirements, but with evident scalability and efficiency issues (an example is carried out in Section 5 of http://tools.ietf.org/id/draft-bccdg-ccamp-gmpls-ospf-agnostic-00.txt, where non technology specific requirements, like for example priority advertisement, are considered). This is why an alternative solution is being discussed. > > Best Regards, > > Daniele > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: giovedì 28 ottobre 2010 20.43 > To: BELOTTI, SERGIO (SERGIO) > Cc: Rajan Rao; ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com; Daniele Ceccarelli; Fatai Zhang; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) > Subject: Re: R: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 > > Sergio, > I think talking solutions is just fine. I was really reacting to "The framework is the only reference for requirements that have to be supported". It's not clear to me that the framework is (a) fully agreed upon, or (b) that it captures, or should even capture, all CCAMP requirements. It certainly should capture all technology-specific requirements. (Also, if the requirements end-up reading "don't use common mechanisms" then I personally think something is probably broken from a CCAMP perspective.) > > If you feel a point has been previously covered on the list, you certainly can take advantage of the list archive and point to where the point was discussed. > > Lou > > On 10/28/2010 9:02 AM, BELOTTI, SERGIO (SERGIO) wrote: >> Hi Lou, >> >> I can take the action to answer your e-mail since I shared with him the content of Pietro's mail. >> It seems to me our intention was exactly in the opposite direction of what you interpreted. >> We do not touch "how to communicate" but we just referenced requirements and information needed to accomplish them. >> We did not discuss about the format to communicate priority flexibility but just remind requirement for that and why the need to have it was already discussed and contained in two regular document one dealing with requirement and the other one related to information to be communicated (not how) . >> This seems completely in line with the path indicated in the slides your referenced. >> It was not absolutely in our intention jump directly to " decide on >> how existing mechanisms are to be reused and what technology-specific objects are to be introduced" >> >> On the other hand I think it is correct to highlight when some drafts trying to propose format without taking into account requirement already discussed. >> >> Thanks >> >> Sergio >> >> >> >> -----Messaggio originale----- >> Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto >> di Lou Berger >> Inviato: giovedì 28 ottobre 2010 14.26 >> A: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) >> Cc: Rajan Rao; ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema >> Pithewan; Ashok@core3.amsl.com >> Oggetto: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: >> draft-ashok-ccamp-gmpls-ospf-g709-01 >> >> Pietro, >> >> I have a general comment, not on the specific drafts being discussed: >> I read your main and am left with the impression that you think that >> we need not make any attempt to leverage, to the maximum extent >> possible, what is already present in GMPLS. I don't believe this is >> the case, nor what the WG has agreed to. >> >> As has been said before, by the WG charter, the chairs and others, it >> is the mandate of CCAMP to developed "common" solutions wherever >> possible, not technology specific ones. As we covered in Maastrict, >> see http://www.ietf.org/proceedings/78/slides/ccamp-28/ccamp-28.htm , >> the WG is still in the earlier stages of defining a GMPLS-based solution for OTN. >> >> It seems to me, that this thread is really part of the "how >> information is to be communicated" discussion identified in slide 3 >> (of ccamp-28.htm). Such discussions are an important step in the >> standardization cycle, and it's good that discussions on reuse are >> underway and continue. >> >> But, please keep in mind that once there is agreement on requirements >> and information to be communicated, we can then decided how to >> communicate the information and agree on how we "Maximizing reuse of >> existing mechanisms". Maximizing reuse is an important optimization >> and generalization step in the CCAMP standardization cycle. (as has >> been done before for each of technologies supported by GMPLS.) >> >> The WG has not yet decided on how existing mechanisms are to be reused >> and what technology-specific objects are to be introduced. So please >> don't cut short any discussion on re-use. >> >> Much thanks, >> Lou >> >> PS Again, this is not an endorsement of any specific draft or proposal. >> >> On 10/28/2010 4:30 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote: >>> 3) Snip: >>> >>> Thirdly, it can not support priority flexibility, so it is not >>> efficient from the routing scalability perspective. >>> >>> [Rajan] { >>> >>> The whole idea is to stay with the GMPLS architecture already in place. >>> The technology specific extensions should go into SCSI. This has been >>> done successfully for SONET/SDH case (Ref to examples in RFC 4202). >>> Do not see a reason to deviation from the original GMPLS model. >>> >>> } >>> >>> The original idea for GMPLS has been already discussed in the frame >>> work document draft-ietf-ccamp-gmpls-g709-framework-03. The framework >>> is the only >>> >>> reference for requirements that have to be supported. Moreover, as >>> required by CCAMP chair an example of the difference in efficiency >>> between the original IETF format >>> >>> and the new format is shown in the draft >>> draft-bccdg-ccamp-gmpls-ospf-agnostic. >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > > > > From loa@pi.nu Fri Oct 29 09:45:40 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7023A67FB; Fri, 29 Oct 2010 09:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyoX69Qtw0J5; Fri, 29 Oct 2010 09:45:37 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 814653A67DB; Fri, 29 Oct 2010 09:45:35 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 47A2D514027; Fri, 29 Oct 2010 18:47:29 +0200 (CEST) Message-ID: <4CCAFAA1.7050902@pi.nu> Date: Fri, 29 Oct 2010 18:47:29 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "mpls@ietf.org" , pwe3@ietf.org References: <4CCAE17A.1030606@pi.nu> <4CCAE343.5030809@pi.nu> In-Reply-To: <4CCAE343.5030809@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, CCAMP , MPLS-TP ad hoc team , "mpls-tp@ietf.org" Subject: [CCAMP] change of meeting times for mpls and pwe3 in Beijing - update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 16:45:40 -0000 All, after further discussion we agreed that the PWE3 working group will meet on Monday morning 9.00 - 11.30. The MPLS working group will meet Monday afternoon 15.10 - 16.10 and Thursday morning 9.00 - 11.30. The first slot Monday afternoon (1-3pm) will bused by the secretariat to resolveremaining conflicts. /Loa On 2010-10-29 17:07, Loa Andersson wrote: > All, > > I've obviously not be looking at the agenda closely enough! > > The second mpls wg meeting will Thursday - so: > > Monday 15.10 - 16.10 > Thursday 9.00 - 11.30 > > for the mpls wg > > > /Loa > > > On 2010-10-29 17:00, Loa Andersson wrote: >> MPLS and PWE3 wg, >> >> we are doing a late swap of agenda slots for the mpls and pwe3 >> working groups at the IETF in Beijing. >> >> The mpls working group will be meeting: >> >> Monday 15.10 - 16.10 >> Wednesday 9.00 - 11.30 >> >> The pwe3 working group will be meeting: >> >> Monday 9.00 - 11.30 >> Monday 13.00 - 15.00 >> >> We don't know if this will be captured on the printed agenda, but the >> online agenda has been changed and we will make sure that it will be >> on the IETF message board. >> >> Loa >> >> for the MPLS and PWE3 chairs >> >> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From rrao@infinera.com Fri Oct 29 12:03:33 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15793A6A49 for ; Fri, 29 Oct 2010 12:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6ga4DFqVpgZ for ; Fri, 29 Oct 2010 12:03:20 -0700 (PDT) Received: from outgoing2.infinera.com (outgoing2.infinera.com [8.4.225.37]) by core3.amsl.com (Postfix) with ESMTP id 200F23A683A for ; Fri, 29 Oct 2010 12:03:20 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub2.infinera.com ([10.100.97.37]) with mapi; Fri, 29 Oct 2010 12:04:33 -0700 From: Rajan Rao To: "ccamp@ietf.org" , Fatai Zhang Date: Fri, 29 Oct 2010 12:04:35 -0700 Thread-Topic: RESPONSE TO => FW: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Thread-Index: Act3PquV+PNZ8lg7Q6aOspVigb2/3AAKHrqAAAnob2A= Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302SVEXDB1infine_" MIME-Version: 1.0 Cc: Khuzema Pithewan , Mohit Misra , Radhakrishna Valiveti Subject: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 19:03:33 -0000 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302SVEXDB1infine_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fatai, Interesting discussion. Please find the response below. Authors of draft-khuzema -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, October 29, 2010 1:26 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham Cc: ccamp@ietf.org; Biao Lu Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, You said there are the following differences between two drafts: - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) - TPN format We have to repeat that there is not much substantial difference between two= drafts except multi-stage muxing. We don't want to talk more on "NMC", "NVC", "TPN", because they have been d= iscussed before and it is quite easy for [draft-zhang] to do that. For exam= ple, for NMC, there is an editors note in the previous versions such as 04= version to discuss NMC stuff (and some people opposed to deprecate NMC). F= or NVC, it is obviously that [draft-zhang] can support it. Now we can focus your key driver-multi-stage muxing. 1) At page 3, in the list of added OTN features is present explicitly the "= Multi-stage ODU Multiplexing". Actually, multi-stage is not present at all = as requirement/feature in G.709. Our intention to postpone technical soluti= on regarding multi-stage multiplexing is justified by on going ITU-T SG15 p= rogress. Before thinking about specific signaling and routing solutions we = need to have stable ITU-T requirements. This why in all our common drafts (= FWK, Info-Model, Routing and Signaling drafts) we just placed some placehol= der on the subject. [AK, KP, RR] { Your understanding is not correct. Please refer to Figure-7-1A (G.709 12/2= 009). It clearly shows multi-stage muxing. G.709 doesn't mandate it has to = be single stage. The G.709 OTN frame formats fully support this capability. Vendors may choose to implement limited number of muxing levels. This shoul= d not impact the signaling solution we come up with. } 2) We are confused by your simplified multi-stage muxing label distribution= rule There is no detailed text to describe multi-stage muxing label distribution= procedures in your draft and your explaination in your below mail just foc= uses on one single node rather than how to create the end-to-end LSP. It is known that GMPLS standard procedure impose that every node has to all= ocate a label/labels consistent with the Generalized Label Request. Very im= portant: Generalized Label Request cannot be changed during signaling path. [AK, KP, RR]{ There is no disagreement here. Generalized label request doesn't change.= It is fully consistent with RFC-4328. This is precisely the reason why we = spelled out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuz= ema). Multi-stage label concept is enforced on the Generalized Label only. This a= ffects only the labels exchanged between the peers. This does not affect th= e Generalized Label Request which is relayed end-to-end. } For example, taking ODU1-ODU2-ODU3 two-stage muxing, which means that we ne= ed a service ODU1 that will be muxed into ODU2 and then ODU3. Assume the pa= th is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demu= xing. How you to create the LSP? how you to distribute the labels in Node B= , C, D? What is the traffic parameters will be transmitted in the nodes B, = C, D and nodes A, E? [AK, KP, RR]{ There are 2 ways to handle this case: with FA or without FA. Both are expla= ined with an example below We have expanded the example as follows: A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 Assume that: - ODU0 LSP is created from A to E. - ODU3 links between B-C and C-D support TS-Granularity of 2.5G only. H= ence ODU0 service can be supported on this interface only through ODU3-ODU2= -ODU0 or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example. - Generalized Label request in this case will be for ODU0 only. Case-1) Without FA: The ODU2 layer created on B-C and C-D does not run betw= een B & D. They terminate between B-C and C-D respectively. Following is = the layering and multi-stage label that needs to exchanged between the node= s. A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 |<---------------------------------------------------------------= >| | ODU0 = | |<---------------->| |<------------= ---->| | ODU1 | | ODU1 = | | |<--------------->|<---------------->| = | | | ODU2 | ODU2 | = | | |<--------------->|<---------------->| = | | | ODU3 | ODU3 | = | | | | | = | Label | | | | = | #of stages| 1 | 2 | 2 | 1 = | Stage-1 | ODU1<--ODU0 | ODU3<--ODU2 | ODU3<--ODU2 | ODU1<--= ODU0 | Stage-2 | | ODU2<--ODU0 | ODU2<--ODU0 | = | ---------------------------------------------------------------------------= --- Case-2) With FA: If ODU2 needs to run between B---D, we need to create an FA-LSP for ODU2 la= yer & this will be a TE-Link by itself. In that case, ODU0 will be routed d= irectly over ODU2 - which is single stage only (no need of multi-stage labe= l in that case). The creation of FA-LSP is outside the scope of our draft. } Thanks Ashok/Khuzema/Rajan Thanks, Authors of [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] ----- Original Message ----- From: "Rajan Rao" To: "Fatai Zhang" ; "Khuzema Pithewan" ; "Mohit Misra" ; "Ashok Kunjidhapatham" Cc: ; "Biao Lu" Sent: Thursday, October 28, 2010 2:17 PM Subject: RE: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Fatai, Please see response inline. thanks Rajan ________________________________________ From: Fatai Zhang [zhangfatai@huawei.com] Sent: Wednesday, October 27, 2010 6:08 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra Cc: ccamp@ietf.org; Zhang, Fatai Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, Happy to see your draft, but except multi-stage muxing supported in your dr= aft, I don't see any substantial difference between your draft and [draft-= zhang-ccamp-gmpls-evolving-g709-06.txt]. [Rajan]{ Multi stage muxing is one of the key drivers for signaling extensions. Any= solution is incomplete without this. The label format proposed is intended= to support G.709-v3 & future OTN extensions. Section 5.2 in draft-ietf-cc= amp-gmpls-g709-framework-03 touches on this aspect!! We see following key differences between the drafts: Our draft addresses - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) } You may say that TPN info is incorporated into label Object, but you know i= t is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and= we already stated it in the slides for IETF78th meeting ( we just make the= door open at this moment and there are some advantages to decouple TPN and= Label). [Rajan]{ The key thing here is the mux layers. The TPN in label object is intended = to address per mux layer case.... more efficient. I think this should be captured in framework doc (section 3.1.2.1in framewo= rk doc doesn't cover hierarchy aspect clearly). } In addtion, for multi-stage muxing, I really suspect that it can be resolve= d so easily, because it is MLN stuff and it needs to indicate how to create= the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can be done in = this way as your draft describes, we all will be much happy. [Rajan]{ The label structure we have defined is to address muxing levels of G.709. = This is not solving MLN using FA. i.e. it doesn't result in creation of FA = automatically. There is no FA involved or intended here (out of scope). Ple= ase refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-cc= amp-gmpls-ospf-g709/. For example, we need 3 labels to create an ODU0 LSP with following muxing= structure on a given TeLink Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-ODU0 Num-of-mux-stages =3D 3 Stage-1 - Label#1: for ODU2 layer with 8 out of 32 bits set Stage-2 - Label#2: for ODU1 layer with 2 out of 8 bits set Stage-3 - Label#3: for ODU0 layer with 1 out of 2 bits set } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: ccamp@ietf.org Cc: Khuzema Pithewan ; Mohit Misra Sent: Wednesday, October 27, 2010 5:26 AM Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls= -signaling-g709-00.txt Hi, We have a draft on "GMPLS Signaling extensions for OTN" available for revie= w. It can be accessed from the following link: http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt The above draft is not on IETF repository as we missed the submission deadl= ine. We will submit to IETF as soon as possible. Please review and comment. Abstract: As OTN network capabilities continue to evolve, there is an increased need= to support GMPLS control for the same. [RFC4328] introduced GMPLS signalin= g extensions for supporting early version of G.709 [G.709-v1].The basic rou= ting considerations from signaling perspective is also specified in [RFC432= 8]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] h= ave introduced new ODU containers (both fixed and flexible) and additional = ODU multiplexing capabilities, enabling support for optimal service aggrega= tion. This document extends [RFC4328] to provide GMPLS signaling support for the = new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling ext= ensions described in this document caters to ODU layer switching only. Opti= cal Channel Layer switching considerations in [RFC4328] are not modified in= this document. Thanks Authors ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302SVEXDB1infine_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fatai,

 

Interesting discussio= n. Please find the response below.

 

Authors of draft-khuz= ema

 

-----Original Message-----
From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: ccamp@ietf.org; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt

 

Hi Rajan,

 

You said there are the following differences betwee= n two drafts:

-  G.709 multi-stage multiplexing (v3 & be= yond)

-  NMC treatment (ref to section-4 in the draf= t)

-  Support for VCAT (NVC >1 )

- TPN format

 

We have to repeat that there is not much substantia= l difference between two drafts except multi-stage muxing.

 

We don't want to talk more on "NMC", "NVC", "TPN", because they have been discussed before a= nd it is quite easy for [draft-zhang] to do that. For example, for NMC, there = is an editors note in the previous versions  such as 04 version to discus= s NMC stuff (and some people opposed to deprecate NMC). For NVC, it is obviou= sly that [draft-zhang] can support it.

 

Now we can focus your key driver-multi-stage muxing= .

 

1) At page 3, in the list of added OTN features is present explicitly the "Multi-stage ODU Multiplexing". Actually, = multi-stage is not present at all as requirement/featur= e in G.709. Our intention to postpone technical solution regarding multi-= stage multiplexing is justified by on going ITU-T SG15 progress. Before thinking about specific signaling and routing solutions we need to have stable ITU-T requirements. This why in all our common drafts (FWK, Info-Model, Routing a= nd Signaling drafts) we just placed some placeholder on the subject.

 

[AK, KP, RR] { <= /o:p>

=A0Your understanding= is not correct. Please refer to Figure-7-1A (G.709 12/2009). It clearly shows multi-stage muxing. G.709 doesn’t mandate it has to be single stage. = The G.709 OTN frame formats fully support this capability.

 

Vendors may choose to implement limited number of muxing levels. This should not impact the signa= ling solution we come up with.

}

 

 

2) We are confused by your simplified multi-stage m= uxing label distribution rule

 

There is no detailed text to describe multi-stage m= uxing label distribution procedures in your draft and your explaination in your b= elow mail just focuses on one single node rather than how to create the end-to-e= nd LSP.

 

It is known that GMPLS standard procedure impose th= at every node has to allocate a label/labels consistent with the Generalized L= abel Request. Very important: Generalized Label Request cannot be changed during signaling path.

[AK, KP, RR]{

=A0 There is no disag= reement here.=A0 Generalized label request doesn’t change. It is fully consis= tent with RFC-4328. This is precisely the reason why we spelled out NMC treatmen= t with ODU2e case (ref to section 4.0 in draft-khuzema).

 

Multi-stage label con= cept is enforced on the Generalized Label only. This affects only the labels exchanged between the peers. This does not affect the Generalized Label Req= uest  which is relayed end-to-end.

}

 

For example, taking ODU1-ODU2-ODU3 two-stage muxing= , which means that we need a service ODU1 that will be muxed into ODU2 and th= en ODU3. Assume the path is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demuxing. How you to create the LSP? how you to distribute= the labels in Node B, C, D? What is the traffic parameters will be transmitted = in the nodes B, C, D and nodes A, E?

 

[AK, KP, RR]{

 

Ther= e are 2 ways to handle this case: with FA or without FA. Both are explained with an example below =A0=A0=A0=A0=A0

 

 We have expande= d the example as follows:

 

   &nb= sp;      A---------------B---------------C---------------D----------------E

   &nb= sp;            OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

 Assume that:

   - ODU0 L= SP is created from A to E.

   - ODU3 l= inks between B-C and C-D support TS-Granularity of 2.5G only.  Hence ODU0 service can be supported on this interface only through ODU3-ODU2-ODU0 = ; or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example.

-    Generalized La= bel request in this case will be for ODU0 only.

 

Case-1) Without FA: T= he ODU2 layer created on B-C and C-D does not run between B & D.  They terminate between B-C and C-D respectively.  Following is the layering= and multi-stage label that needs to exchanged between the nodes.

 

 

          A---------------B---------------C---------------D----------------E

          =       OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

          |<-------------------------------------------------------------=E0| &= nbsp;       

          |                  &nb= sp;        ODU0   &n= bsp;            = ;            &n= bsp;    |

          |=DF--------= ----=E0| &= nbsp;           &nbs= p;            &= nbsp;    |=DF--------= ----=E0| &= nbsp;         

          |       ODU1     |         &n= bsp;            = ;         |      ODU1     |

          |&nbs= p;            &= nbsp;  |=DF--------= ---=E0|= =DF--------= ----=E0| &= nbsp;           &nbs= p; |

          |            &n= bsp;   |      ODU2    |      ODU2      |               |

          |                |=DF-----------=E0|=DF------------=E0|     &nb= sp;         |

          |            &n= bsp;   |      ODU3    |   &= nbsp;  ODU3      |            &n= bsp;  |

          |        &n= bsp;       |            &n= bsp; |                |      &n= bsp;        |

Label     |            &n= bsp;   |            &n= bsp; |            &n= bsp;   |            &n= bsp;  |

#of stages|        1       |         2    |&nbs= p;        2      |         1     = ;|

Stage-1   |   ODU1=DFODU0&nbs= p;  |   ODU3=DFODU2  |   ODU3=DFODU2   |  &nbs= p; ODU1=DFODU0 &nb= sp;|

Stage-2   |            &n= bsp;   |   ODU2=DFODU0  |   ODU2=DFODU0   |            &n= bsp;  |

------------------------------------------------------------= ------------------

 

Case= -2) With FA:

If ODU2 needs to run = between B---D, we need to create an FA-LSP for ODU2 layer & this will be a TE-L= ink by itself. In that case, ODU0 will be routed directly over ODU2 – whi= ch is single stage only (no need of multi-stage label in that case).

 

The = creation of FA-LSP is outside the scope of our draft.

}

Thanks

Asho= k/Khuzema/Rajan

 

Thanks,

 

Authors of [draft-zhang-ccamp-gmpls-evolving-g709-0= 6.txt]

 

 

 

 

----- Original Message -----

From: "Rajan Rao" <rrao@infinera.com&g= t;

To: "Fatai Zhang" <zhangfatai@huawei.com>; "Khuzema Pithewan" <kpithewan@infinera.com>; "Mohit Misra" <mmisra@infinera.com>; "Ashok Kunjidhapatham" <akunjidhapatham@infinera.com>

Cc: <ccamp@ietf.org>; "Biao Lu" <blu@infinera.com>

Sent: Thursday, October 28, 2010 2:17 PM=

Subject: RE: [CCAMP] Signaling extensions for G.709= - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

 

Fatai,

 

Please see response inline.

 

thanks

Rajan

________________________________________=

From: Fatai Zhang [zhangfatai@huawei.com]

Sent: Wednesday, October 27, 2010 6:08 PM

To: Rajan Rao; Khuzema Pithewan; Mohit Misra

Cc: ccamp@ietf.org; Zhang, Fatai

Subject: Re: [CCAMP] Signaling extensions for G.709= - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

Happy to see your draft, but except multi-stage mux= ing supported in your draft,  I don't see any substantial difference betwe= en your draft and [draft-zhang-ccamp-gmpls-evolving-g709-06.txt].

 

[Rajan]{

Multi stage muxing is one of the key drivers for&nb= sp; signaling extensions. Any solution is incomplete without this. The label fo= rmat proposed is intended to support G.709-v3 & future OTN extensions. Secti= on 5.2 in  draft-ietf-ccamp-gmpls-g709-framework-03  touches on this aspect!!

 

We see following key differences between the drafts= :

 Our draft addresses

-        &n= bsp; G.709 multi-stage multiplexing (v3 & beyond)

-        &n= bsp; NMC treatment (ref to section-4 in the draft)

-        &n= bsp; Support for VCAT (NVC >1 )

}

 

You may say that TPN info is incorporated into labe= l Object, but you know it is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and we already st= ated it in the slides for IETF78th meeting ( we just make the door open at this moment and there are some advantages to decouple TPN and Label).=

 

[Rajan]{

The key thing here is the mux layers.  The TPN= in label object is intended to address per mux layer case…. more efficie= nt.

I think this should be captured in framework doc (s= ection 3.1.2.1in framework doc doesn't cover hierarchy aspect clearly).

}

 

In addtion, for multi-stage muxing, I really suspec= t that it can be resolved so easily, because it is MLN stuff and it needs to indic= ate how to create the infrastructure FA-LSP (See RFC4206 and 4206bis). If it ca= n be done in this way as your draft describes, we all will be much happy.

 

[Rajan]{

The label structure we have defined is to address m= uxing levels of G.709.  This is not solving MLN using FA. i.e. it doesn̵= 7;t result in creation of FA automatically. There is no FA involved or intended here (out of scope). Please refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/.<= o:p>

 

 For example,  we need 3 labels to create= an ODU0 LSP with following muxing structure on a given TeLink

 

Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-O= DU0

 

Num-of-mux-stages =3D 3

Stage-1 - Label#1: for ODU2 layer with 8 out of 32 = bits set

Stage-2 - Label#2: for ODU1 layer with 2 out of 8 b= its set

Stage-3 - Label#3: for ODU0 layer with 1 out of 2 b= its set

 

}

 

 

Best Regards

 

Fatai

 

----- Original Message -----

From: Rajan Rao<mailto:rrao@infinera.com>

To: ccamp@ietf.org<mailto:ccamp@ietf.org>

Cc: Khuzema Pithewan<mailto:kpithewan@infinera.c= om> ; Mohit Misra<mailto:mmisra@infinera.com>

Sent: Wednesday, October 27, 2010 5:26 AM

Subject: [CCAMP] Signaling extensions for G.709 - d= raft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi,

 

We have a draft on “GMPLS Signaling extension= s for OTN” available for review.  It can be accessed from the followin= g link:

http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g= 709-00.txt

The above draft is not on IETF repository as we mis= sed the submission deadline.  We will submit to IETF as soon as possible.<= o:p>

 

Please review and comment.

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased  need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is a= lso specified in [RFC4328].

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support fo= r optimal service aggregation.

This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in this document caters to OD= U layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document.

 

Thanks

Authors

 

________________________________

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

--_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302SVEXDB1infine_-- From jdrake@juniper.net Fri Oct 29 13:41:32 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9914C3A6857 for ; Fri, 29 Oct 2010 13:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Bry1fTH0GzG for ; Fri, 29 Oct 2010 13:41:17 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 761733A6ADE for ; Fri, 29 Oct 2010 13:41:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTMsx0Nj+A09XVcrt/lIBVBLKCl9siyK0@postini.com; Fri, 29 Oct 2010 13:43:00 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 29 Oct 2010 13:39:55 -0700 From: John E Drake To: Rajan Rao , "ccamp@ietf.org" , Fatai Zhang Date: Fri, 29 Oct 2010 13:40:46 -0700 Thread-Topic: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Thread-Index: Act3PquV+PNZ8lg7Q6aOspVigb2/3AAKHrqAAAnob2AABiR60A== Message-ID: <5E893DB832F57341992548CDBB33316398B51FC59F@EMBX01-HQ.jnpr.net> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB33316398B51FC59FEMBX01HQjnprn_" MIME-Version: 1.0 Cc: Khuzema Pithewan , Radhakrishna Valiveti , Mohit Misra Subject: Re: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 20:41:32 -0000 --_000_5E893DB832F57341992548CDBB33316398B51FC59FEMBX01HQjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Per RFC6001, the B-D ODU2 link would be advertised as a virtual TE Link. T= his is necessary because otherwise the CSPF at A will not consider routing = the ODU0 LSP via B, C, and D. When the ODU0 Path message is received at B, it is held up while a separate= ODU2 Path message is sent from B to C to D to activate the B-D ODU2 Link. = Once it is activated, using LSP Hierarchy ( RFC4206) B sends the ODU0 requ= est to D, which in turn sends it to E. When we were first developing GMPLS, we looked at packaging multiple LSP se= tup requests together and decided it was a Bad Idea(tm). So, the multistag= e signaling you are suggesting is not only unnecessary, but not in alignmen= t with the GMPLS architecture. The other alternatives are to instantiate the B-D ODU2 link or B-C and C-D= ODU2 links beforehand. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Friday, October 29, 2010 12:05 PM To: ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti Subject: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.709 - = draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Fatai, Interesting discussion. Please find the response below. Authors of draft-khuzema -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, October 29, 2010 1:26 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham Cc: ccamp@ietf.org; Biao Lu Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, You said there are the following differences between two drafts: - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) - TPN format We have to repeat that there is not much substantial difference between two= drafts except multi-stage muxing. We don't want to talk more on "NMC", "NVC", "TPN", because they have been d= iscussed before and it is quite easy for [draft-zhang] to do that. For exam= ple, for NMC, there is an editors note in the previous versions such as 04= version to discuss NMC stuff (and some people opposed to deprecate NMC). F= or NVC, it is obviously that [draft-zhang] can support it. Now we can focus your key driver-multi-stage muxing. 1) At page 3, in the list of added OTN features is present explicitly the "= Multi-stage ODU Multiplexing". Actually, multi-stage is not present at all = as requirement/feature in G.709. Our intention to postpone technical soluti= on regarding multi-stage multiplexing is justified by on going ITU-T SG15 p= rogress. Before thinking about specific signaling and routing solutions we = need to have stable ITU-T requirements. This why in all our common drafts (= FWK, Info-Model, Routing and Signaling drafts) we just placed some placehol= der on the subject. [AK, KP, RR] { Your understanding is not correct. Please refer to Figure-7-1A (G.709 12/2= 009). It clearly shows multi-stage muxing. G.709 doesn't mandate it has to = be single stage. The G.709 OTN frame formats fully support this capability. Vendors may choose to implement limited number of muxing levels. This shoul= d not impact the signaling solution we come up with. } 2) We are confused by your simplified multi-stage muxing label distribution= rule There is no detailed text to describe multi-stage muxing label distribution= procedures in your draft and your explaination in your below mail just foc= uses on one single node rather than how to create the end-to-end LSP. It is known that GMPLS standard procedure impose that every node has to all= ocate a label/labels consistent with the Generalized Label Request. Very im= portant: Generalized Label Request cannot be changed during signaling path. [AK, KP, RR]{ There is no disagreement here. Generalized label request doesn't change.= It is fully consistent with RFC-4328. This is precisely the reason why we = spelled out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuz= ema). Multi-stage label concept is enforced on the Generalized Label only. This a= ffects only the labels exchanged between the peers. This does not affect th= e Generalized Label Request which is relayed end-to-end. } For example, taking ODU1-ODU2-ODU3 two-stage muxing, which means that we ne= ed a service ODU1 that will be muxed into ODU2 and then ODU3. Assume the pa= th is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demu= xing. How you to create the LSP? how you to distribute the labels in Node B= , C, D? What is the traffic parameters will be transmitted in the nodes B, = C, D and nodes A, E? [AK, KP, RR]{ There are 2 ways to handle this case: with FA or without FA. Both are expla= ined with an example below We have expanded the example as follows: A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 Assume that: - ODU0 LSP is created from A to E. - ODU3 links between B-C and C-D support TS-Granularity of 2.5G only. H= ence ODU0 service can be supported on this interface only through ODU3-ODU2= -ODU0 or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example. - Generalized Label request in this case will be for ODU0 only. Case-1) Without FA: The ODU2 layer created on B-C and C-D does not run betw= een B & D. They terminate between B-C and C-D respectively. Following is = the layering and multi-stage label that needs to exchanged between the node= s. A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 |<---------------------------------------------------------------= >| | ODU0 = | |<---------------->| |<------------= ---->| | ODU1 | | ODU1 = | | |<--------------->|<---------------->| = | | | ODU2 | ODU2 | = | | |<--------------->|<---------------->| = | | | ODU3 | ODU3 | = | | | | | = | Label | | | | = | #of stages| 1 | 2 | 2 | 1 = | Stage-1 | ODU1<--ODU0 | ODU3<--ODU2 | ODU3<--ODU2 | ODU1<--= ODU0 | Stage-2 | | ODU2<--ODU0 | ODU2<--ODU0 | = | ---------------------------------------------------------------------------= --- Case-2) With FA: If ODU2 needs to run between B---D, we need to create an FA-LSP for ODU2 la= yer & this will be a TE-Link by itself. In that case, ODU0 will be routed d= irectly over ODU2 - which is single stage only (no need of multi-stage labe= l in that case). The creation of FA-LSP is outside the scope of our draft. } Thanks Ashok/Khuzema/Rajan Thanks, Authors of [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] ----- Original Message ----- From: "Rajan Rao" To: "Fatai Zhang" ; "Khuzema Pithewan" ; "Mohit Misra" ; "Ashok Kunjidhapatham" Cc: ; "Biao Lu" Sent: Thursday, October 28, 2010 2:17 PM Subject: RE: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Fatai, Please see response inline. thanks Rajan ________________________________________ From: Fatai Zhang [zhangfatai@huawei.com] Sent: Wednesday, October 27, 2010 6:08 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra Cc: ccamp@ietf.org; Zhang, Fatai Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, Happy to see your draft, but except multi-stage muxing supported in your dr= aft, I don't see any substantial difference between your draft and [draft-= zhang-ccamp-gmpls-evolving-g709-06.txt]. [Rajan]{ Multi stage muxing is one of the key drivers for signaling extensions. Any= solution is incomplete without this. The label format proposed is intended= to support G.709-v3 & future OTN extensions. Section 5.2 in draft-ietf-cc= amp-gmpls-g709-framework-03 touches on this aspect!! We see following key differences between the drafts: Our draft addresses - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) } You may say that TPN info is incorporated into label Object, but you know i= t is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and= we already stated it in the slides for IETF78th meeting ( we just make the= door open at this moment and there are some advantages to decouple TPN and= Label). [Rajan]{ The key thing here is the mux layers. The TPN in label object is intended = to address per mux layer case.... more efficient. I think this should be captured in framework doc (section 3.1.2.1in framewo= rk doc doesn't cover hierarchy aspect clearly). } In addtion, for multi-stage muxing, I really suspect that it can be resolve= d so easily, because it is MLN stuff and it needs to indicate how to create= the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can be done in = this way as your draft describes, we all will be much happy. [Rajan]{ The label structure we have defined is to address muxing levels of G.709. = This is not solving MLN using FA. i.e. it doesn't result in creation of FA = automatically. There is no FA involved or intended here (out of scope). Ple= ase refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-cc= amp-gmpls-ospf-g709/. For example, we need 3 labels to create an ODU0 LSP with following muxing= structure on a given TeLink Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-ODU0 Num-of-mux-stages =3D 3 Stage-1 - Label#1: for ODU2 layer with 8 out of 32 bits set Stage-2 - Label#2: for ODU1 layer with 2 out of 8 bits set Stage-3 - Label#3: for ODU0 layer with 1 out of 2 bits set } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: ccamp@ietf.org Cc: Khuzema Pithewan ; Mohit Misra Sent: Wednesday, October 27, 2010 5:26 AM Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls= -signaling-g709-00.txt Hi, We have a draft on "GMPLS Signaling extensions for OTN" available for revie= w. It can be accessed from the following link: http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt The above draft is not on IETF repository as we missed the submission deadl= ine. We will submit to IETF as soon as possible. Please review and comment. Abstract: As OTN network capabilities continue to evolve, there is an increased need= to support GMPLS control for the same. [RFC4328] introduced GMPLS signalin= g extensions for supporting early version of G.709 [G.709-v1].The basic rou= ting considerations from signaling perspective is also specified in [RFC432= 8]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] h= ave introduced new ODU containers (both fixed and flexible) and additional = ODU multiplexing capabilities, enabling support for optimal service aggrega= tion. This document extends [RFC4328] to provide GMPLS signaling support for the = new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling ext= ensions described in this document caters to ODU layer switching only. Opti= cal Channel Layer switching considerations in [RFC4328] are not modified in= this document. Thanks Authors ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_5E893DB832F57341992548CDBB33316398B51FC59FEMBX01HQjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 =

Per RFC6001, the B-D ODU= 2 link would be advertised as a virtual TE Link.=A0 This is necessary because othe= rwise the CSPF at A will not consider routing the ODU0 LSP via B, C, and D.<= /o:p>

 =

When the ODU0 Path messa= ge is received at B, it is held up while a separate ODU2 Path message is sent fro= m B to C to D to activate the B-D ODU2 Link.=A0 Once it is activated, using LSP Hi= erarchy ( RFC4206) B sends the ODU0 request to D, which in turn sends it to E.=

 =

When we were first devel= oping GMPLS, we looked at packaging multiple LSP setup requests together and deci= ded it was a Bad Idea™.=A0 So, the multistage signaling you are suggestin= g is not only unnecessary, but not in alignment with the GMPLS architecture.

 =

The other alternatives a= re to instantiate the B-D ODU2 link or =A0B-C and C-D ODU2 links beforehand.

 =

Thanks,

 =

John

 =

Sent from my iPhone=

 =

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Rajan Rao
Sent: Friday, October 29, 2010 12:05 PM
To: ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Subject: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions fo= r G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Fatai,

 

Interesting discussio= n. Please find the response below.

 

Authors of draft-khuz= ema

 

-----Original Message-----
From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: ccamp@ietf.org; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

You said there are the following differences betwee= n two drafts:

-  G.709 multi-stage multiplexing (v3 & be= yond)

-  NMC treatment (ref to section-4 in the draf= t)

-  Support for VCAT (NVC >1 )

- TPN format

 

We have to repeat that there is not much substantia= l difference between two drafts except multi-stage muxing.

 

We don't want to talk more on "NMC", "NVC", "TPN", because they have been discussed before a= nd it is quite easy for [draft-zhang] to do that. For example, for NMC, there = is an editors note in the previous versions  such as 04 version to discus= s NMC stuff (and some people opposed to deprecate NMC). For NVC, it is obviou= sly that [draft-zhang] can support it.

 

Now we can focus your key driver-multi-stage muxing= .

 

1) At page 3, in the list of added OTN features is present explicitly the "Multi-stage ODU Multiplexing". Actually, = multi-stage is not present at all as requirement/featur= e in G.709. Our intention to postpone technical solution regarding multi-stage multiplexing is justified by on going ITU-T SG15 progress. Befo= re thinking about specific signaling and routing solutions we need to have sta= ble ITU-T requirements. This why in all our common drafts (FWK, Info-Model, Rou= ting and Signaling drafts) we just placed some placeholder on the subject.<= /o:p>

 

[AK, KP, RR] { <= /o:p>

 Your understand= ing is not correct. Please refer to Figure-7-1A (G.709 12/2009). It clearly shows multi-stage muxing. G.709 doesn’t mandate it has to be single stage. = The G.709 OTN frame formats fully support this capability.

 

Vendors may choose to implement limited number of muxing levels. This should not impact the signa= ling solution we come up with.

}

 

 

2) We are confused by your simplified multi-stage m= uxing label distribution rule

 

There is no detailed text to describe multi-stage m= uxing label distribution procedures in your draft and your explaination in your b= elow mail just focuses on one single node rather than how to create the end-to-e= nd LSP.

 

It is known that GMPLS standard procedure impose th= at every node has to allocate a label/labels consistent with the Generalized L= abel Request. Very important: Generalized Label Request cannot be changed during signaling path.

[AK, KP, RR]{

  There is no disagreement here.  Generalized label request doesn’t change. It= is fully consistent with RFC-4328. This is precisely the reason why we spelled= out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuzema).

 

Multi-stage label con= cept is enforced on the Generalized Label only. This affects only the labels exchanged between the peers. This does not affect the Generalized Label Req= uest  which is relayed end-to-end.

}

 

For example, taking ODU1-ODU2-ODU3 two-stage muxing= , which means that we need a service ODU1 that will be muxed into ODU2 and th= en ODU3. Assume the path is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demuxing. How you to create the LSP? how you to distribute= the labels in Node B, C, D? What is the traffic parameters will be transmitted = in the nodes B, C, D and nodes A, E?

 

[AK, KP, RR]{

 

Ther= e are 2 ways to handle this case: with FA or without FA. Both are explained with an example below      

 

 We have expande= d the example as follows:

 

   &nb= sp;      A---------------B---------------C---------------D----------------E

   &nb= sp;            OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

 Assume that:

   - ODU0 L= SP is created from A to E.

   - ODU3 l= inks between B-C and C-D support TS-Granularity of 2.5G only.  Hence ODU0 service can be supported on this interface only through ODU3-ODU2-ODU0 = ; or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example.

-    Generalized La= bel request in this case will be for ODU0 only.

 

Case-1) Without FA: T= he ODU2 layer created on B-C and C-D does not run between B & D.  They terminate between B-C and C-D respectively.  Following is the layering= and multi-stage label that needs to exchanged between the nodes.

 

 

          A---------------B---------------C---------------D----------------E

          =       OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

          |<-------------------------------------------------------------=E0| &= nbsp;       

          |                  &nb= sp;        ODU0   &n= bsp;            = ;            &n= bsp;    |

          |=DF--------= ----=E0| &= nbsp;           &nbs= p;            &= nbsp;    |=DF--------= ----=E0| &= nbsp;         

          |       ODU1     |         &n= bsp;            = ;         |      ODU1     |

          |            &n= bsp;   |=DF--------= ---=E0|= =DF--------= ----=E0| &= nbsp;           &nbs= p; |

          |            &n= bsp;   |      ODU2    |      ODU2      |               |

          |                |=DF-----------=E0|=DF------------=E0|     &nb= sp;         |

          |            &n= bsp;   |      ODU3    |      ODU3      |            &n= bsp;  |

          |        &n= bsp;       |            &n= bsp; |                |      &n= bsp;        |

Label     |            &n= bsp;   |            &n= bsp; |            &n= bsp;   |            &n= bsp;  |

#of stages|        1       |         2    |&nbs= p;        2      |         1     = ;|

Stage-1   |   ODU1=DFODU0&nbs= p;  |   ODU3=DFODU2  |   ODU3=DFODU2   |  &nbs= p; ODU1=DFODU0 &nb= sp;|

Stage-2   |            &n= bsp;   |   ODU2=DFODU0  |   ODU2=DFODU0   |            &n= bsp;  |

------------------------------------------------------------= ------------------

 

Case= -2) With FA:

If ODU2 needs to run = between B---D, we need to create an FA-LSP for ODU2 layer & this will be a TE-L= ink by itself. In that case, ODU0 will be routed directly over ODU2 – whi= ch is single stage only (no need of multi-stage label in that case).

 

The = creation of FA-LSP is outside the scope of our draft.

}

Thanks

Asho= k/Khuzema/Rajan

 

Thanks,

 

Authors of [draft-zhang-ccamp-gmpls-evolving-g709-0= 6.txt]

 

 

 

 

----- Original Message -----

From: "Rajan Rao" <rrao@infinera.com&g= t;

To: "Fatai Zhang" <zhangfatai@huawei.com>; "Khuzema Pithewan" <kpithewan@infinera.com>; "Mohit Misra" <mmisra@infinera.com>; "Ashok Kunjidhapatham" <akunjidhapatham@infinera.com>

Cc: <ccamp@ietf.org>; "Biao Lu" <blu@infinera.com>

Sent: Thursday, October 28, 2010 2:17 PM=

Subject: RE: [CCAMP] Signaling extensions for G.709= - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

 

Fatai,

 

Please see response inline.

 

thanks

Rajan

________________________________________=

From: Fatai Zhang [zhangfatai@huawei.com]

Sent: Wednesday, October 27, 2010 6:08 PM

To: Rajan Rao; Khuzema Pithewan; Mohit Misra

Cc: ccamp@ietf.org; Zhang, Fatai

Subject: Re: [CCAMP] Signaling extensions for G.709= - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

Happy to see your draft, but except multi-stage mux= ing supported in your draft,  I don't see any substantial difference betwe= en your draft and [draft-zhang-ccamp-gmpls-evolving-g709-06.txt].

 

[Rajan]{

Multi stage muxing is one of the key drivers for&nb= sp; signaling extensions. Any solution is incomplete without this. The label fo= rmat proposed is intended to support G.709-v3 & future OTN extensions. Secti= on 5.2 in  draft-ietf-ccamp-gmpls-g709-framework-03  touches on this aspect!!

 

We see following key differences between the drafts= :

 Our draft addresses

-        &n= bsp; G.709 multi-stage multiplexing (v3 & beyond)

-        &n= bsp; NMC treatment (ref to section-4 in the draft)

-        &n= bsp; Support for VCAT (NVC >1 )

}

 

You may say that TPN info is incorporated into labe= l Object, but you know it is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] = to do that and we already stated it in the slides for IETF78th meeting ( we ju= st make the door open at this moment and there are some advantages to decouple= TPN and Label).

 

[Rajan]{

The key thing here is the mux layers.  The TPN= in label object is intended to address per mux layer case…. more efficie= nt.

I think this should be captured in framework doc (s= ection 3.1.2.1in framework doc doesn't cover hierarchy aspect clearly).

}

 

In addtion, for multi-stage muxing, I really suspec= t that it can be resolved so easily, because it is MLN stuff and it needs to indic= ate how to create the infrastructure FA-LSP (See RFC4206 and 4206bis). If it ca= n be done in this way as your draft describes, we all will be much happy.

 

[Rajan]{

The label structure we have defined is to address m= uxing levels of G.709.  This is not solving MLN using FA. i.e. it doesn̵= 7;t result in creation of FA automatically. There is no FA involved or intended here (out of scope). Please refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/.<= o:p>

 

 For example,  we need 3 labels to create= an ODU0 LSP with following muxing structure on a given TeLink

 

Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-O= DU0

 

Num-of-mux-stages =3D 3

Stage-1 - Label#1: for ODU2 layer with 8 out of 32 = bits set

Stage-2 - Label#2: for ODU1 layer with 2 out of 8 b= its set

Stage-3 - Label#3: for ODU0 layer with 1 out of 2 b= its set

 

}

 

 

Best Regards

 

Fatai

 

----- Original Message -----

From: Rajan Rao<mailto:rrao@infinera.com>

To: ccamp@ietf.org<mailto:ccamp@ietf.org>

Cc: Khuzema Pithewan<mailto:kpithewan@infinera.c= om> ; Mohit Misra<mailto:mmisra@infinera.com>

Sent: Wednesday, October 27, 2010 5:26 AM

Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi,

 

We have a draft on “GMPLS Signaling extension= s for OTN” available for review.  It can be accessed from the followin= g link:

http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g= 709-00.txt

The above draft is not on IETF repository as we mis= sed the submission deadline.  We will submit to IETF as soon as possible.<= o:p>

 

Please review and comment.

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased  need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is a= lso specified in [RFC4328].

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support fo= r optimal service aggregation.

This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in this document caters to OD= U layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document.

 

Thanks

Authors

 

________________________________

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

--_000_5E893DB832F57341992548CDBB33316398B51FC59FEMBX01HQjnprn_-- From rrao@infinera.com Fri Oct 29 14:49:19 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8350A3A6AC4 for ; Fri, 29 Oct 2010 14:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6perIgBKHN+2 for ; Fri, 29 Oct 2010 14:49:03 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 20FBA3A67D6 for ; Fri, 29 Oct 2010 14:49:02 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Fri, 29 Oct 2010 14:50:16 -0700 From: Rajan Rao To: John E Drake , "ccamp@ietf.org" , Fatai Zhang Date: Fri, 29 Oct 2010 14:50:10 -0700 Thread-Topic: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Thread-Index: Act3PquV+PNZ8lg7Q6aOspVigb2/3AAKHrqAAAnob2AABiR60AAB+FyA Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05353@SV-EXDB1.infinera.com> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302@SV-EXDB1.infinera.com> <5E893DB832F57341992548CDBB33316398B51FC59F@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB33316398B51FC59F@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05353SVEXDB1infine_" MIME-Version: 1.0 Cc: Khuzema Pithewan , Radhakrishna Valiveti , Biao, Mohit Misra Subject: Re: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 21:49:19 -0000 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05353SVEXDB1infine_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, et al Please see response inline. Thanks Rajan From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, October 29, 2010 1:41 PM To: Rajan Rao; ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.70= 9 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Hi, Per RFC6001, the B-D ODU2 link would be advertised as a virtual TE Link. T= his is necessary because otherwise the CSPF at A will not consider routing = the ODU0 LSP via B, C, and D. [Rajan] { This is not the case. Even without virtual TE link or FA-LSP the ODU0 LSP= s can be setup between A-E. This is because we advertise #ODU0s for OTU3 l= inks B-C & C-D. Note that #ODU0 containers advertised is non-zero even tho= ugh TSG=3D2.5G. This is the key point here. We are no longer bound by MinLSP-BW as ODU0 BW is advertized as a separate = sub-TLV within SCSI. The instantiation of ODU2 to support ODU0 is done as part of signaling whic= h brings in the label format for mux levels. The instantiation of mux laye= rs is a local matter. This can be different on each segment. The labels te= ll exactly what to instantiate on the local interface. In this example, each NE decides locally (segment basis) how ODU0 should/ca= n be supported. If it requires additional mux layers they are requested in= the label going down stream. } When the ODU0 Path message is received at B, it is held up while a separate= ODU2 Path message is sent from B to C to D to activate the B-D ODU2 Link. = Once it is activated, using LSP Hierarchy ( RFC4206) B sends the ODU0 requ= est to D, which in turn sends it to E. [Rajan] { This is allowed. As said below, this is an alternate way. We can do without= this as shown in the examples. } When we were first developing GMPLS, we looked at packaging multiple LSP se= tup requests together and decided it was a Bad Idea(tm). So, the multistag= e signaling you are suggesting is not only unnecessary, but not in alignmen= t with the GMPLS architecture. [Rajan] { Not sure on the alignment. Think of a scenario where I have muxing rest= riction within an FA. What do you do here? Create more FAs? Works of cour= se with scaling implications. } The other alternatives are to instantiate the B-D ODU2 link or B-C and C-D= ODU2 links beforehand. [Rajan] { Agree, this is listed as FA case in the example below. } Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Friday, October 29, 2010 12:05 PM To: ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti Subject: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.709 - = draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Fatai, Interesting discussion. Please find the response below. Authors of draft-khuzema -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, October 29, 2010 1:26 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham Cc: ccamp@ietf.org; Biao Lu Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, You said there are the following differences between two drafts: - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) - TPN format We have to repeat that there is not much substantial difference between two= drafts except multi-stage muxing. We don't want to talk more on "NMC", "NVC", "TPN", because they have been d= iscussed before and it is quite easy for [draft-zhang] to do that. For exam= ple, for NMC, there is an editors note in the previous versions such as 04= version to discuss NMC stuff (and some people opposed to deprecate NMC). F= or NVC, it is obviously that [draft-zhang] can support it. Now we can focus your key driver-multi-stage muxing. 1) At page 3, in the list of added OTN features is present explicitly the "= Multi-stage ODU Multiplexing". Actually, multi-stage is not present at all = as requirement/feature in G.709. Our intention to postpone technical soluti= on regarding multi-stage multiplexing is justified by on going ITU-T SG15 p= rogress. Before thinking about specific signaling and routing solutions we = need to have stable ITU-T requirements. This why in all our common drafts (= FWK, Info-Model, Routing and Signaling drafts) we just placed some placehol= der on the subject. [AK, KP, RR] { Your understanding is not correct. Please refer to Figure-7-1A (G.709 12/2= 009). It clearly shows multi-stage muxing. G.709 doesn't mandate it has to = be single stage. The G.709 OTN frame formats fully support this capability. Vendors may choose to implement limited number of muxing levels. This shoul= d not impact the signaling solution we come up with. } 2) We are confused by your simplified multi-stage muxing label distribution= rule There is no detailed text to describe multi-stage muxing label distribution= procedures in your draft and your explaination in your below mail just foc= uses on one single node rather than how to create the end-to-end LSP. It is known that GMPLS standard procedure impose that every node has to all= ocate a label/labels consistent with the Generalized Label Request. Very im= portant: Generalized Label Request cannot be changed during signaling path. [AK, KP, RR]{ There is no disagreement here. Generalized label request doesn't change.= It is fully consistent with RFC-4328. This is precisely the reason why we = spelled out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuz= ema). Multi-stage label concept is enforced on the Generalized Label only. This a= ffects only the labels exchanged between the peers. This does not affect th= e Generalized Label Request which is relayed end-to-end. } For example, taking ODU1-ODU2-ODU3 two-stage muxing, which means that we ne= ed a service ODU1 that will be muxed into ODU2 and then ODU3. Assume the pa= th is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demu= xing. How you to create the LSP? how you to distribute the labels in Node B= , C, D? What is the traffic parameters will be transmitted in the nodes B, = C, D and nodes A, E? [AK, KP, RR]{ There are 2 ways to handle this case: with FA or without FA. Both are expla= ined with an example below We have expanded the example as follows: A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 Assume that: - ODU0 LSP is created from A to E. - ODU3 links between B-C and C-D support TS-Granularity of 2.5G only. H= ence ODU0 service can be supported on this interface only through ODU3-ODU2= -ODU0 or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example. - Generalized Label request in this case will be for ODU0 only. Case-1) Without FA: The ODU2 layer created on B-C and C-D does not run betw= een B & D. They terminate between B-C and C-D respectively. Following is = the layering and multi-stage label that needs to exchanged between the node= s. A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 |<---------------------------------------------------------------= >| | ODU0 = | |<---------------->| |<------------= ---->| | ODU1 | | ODU1 = | | |<--------------->|<---------------->| = | | | ODU2 | ODU2 | = | | |<--------------->|<---------------->| = | | | ODU3 | ODU3 | = | | | | | = | Label | | | | = | #of stages| 1 | 2 | 2 | 1 = | Stage-1 | ODU1<--ODU0 | ODU3<--ODU2 | ODU3<--ODU2 | ODU1<--= ODU0 | Stage-2 | | ODU2<--ODU0 | ODU2<--ODU0 | = | ---------------------------------------------------------------------------= --- Case-2) With FA: If ODU2 needs to run between B---D, we need to create an FA-LSP for ODU2 la= yer & this will be a TE-Link by itself. In that case, ODU0 will be routed d= irectly over ODU2 - which is single stage only (no need of multi-stage labe= l in that case). The creation of FA-LSP is outside the scope of our draft. } Thanks Ashok/Khuzema/Rajan Thanks, Authors of [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] ----- Original Message ----- From: "Rajan Rao" To: "Fatai Zhang" ; "Khuzema Pithewan" ; "Mohit Misra" ; "Ashok Kunjidhapatham" Cc: ; "Biao Lu" Sent: Thursday, October 28, 2010 2:17 PM Subject: RE: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Fatai, Please see response inline. thanks Rajan ________________________________________ From: Fatai Zhang [zhangfatai@huawei.com] Sent: Wednesday, October 27, 2010 6:08 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra Cc: ccamp@ietf.org; Zhang, Fatai Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, Happy to see your draft, but except multi-stage muxing supported in your dr= aft, I don't see any substantial difference between your draft and [draft-= zhang-ccamp-gmpls-evolving-g709-06.txt]. [Rajan]{ Multi stage muxing is one of the key drivers for signaling extensions. Any= solution is incomplete without this. The label format proposed is intended= to support G.709-v3 & future OTN extensions. Section 5.2 in draft-ietf-cc= amp-gmpls-g709-framework-03 touches on this aspect!! We see following key differences between the drafts: Our draft addresses - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) } You may say that TPN info is incorporated into label Object, but you know i= t is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and= we already stated it in the slides for IETF78th meeting ( we just make the= door open at this moment and there are some advantages to decouple TPN and= Label). [Rajan]{ The key thing here is the mux layers. The TPN in label object is intended = to address per mux layer case.... more efficient. I think this should be captured in framework doc (section 3.1.2.1in framewo= rk doc doesn't cover hierarchy aspect clearly). } In addtion, for multi-stage muxing, I really suspect that it can be resolve= d so easily, because it is MLN stuff and it needs to indicate how to create= the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can be done in = this way as your draft describes, we all will be much happy. [Rajan]{ The label structure we have defined is to address muxing levels of G.709. = This is not solving MLN using FA. i.e. it doesn't result in creation of FA = automatically. There is no FA involved or intended here (out of scope). Ple= ase refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-cc= amp-gmpls-ospf-g709/. For example, we need 3 labels to create an ODU0 LSP with following muxing= structure on a given TeLink Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-ODU0 Num-of-mux-stages =3D 3 Stage-1 - Label#1: for ODU2 layer with 8 out of 32 bits set Stage-2 - Label#2: for ODU1 layer with 2 out of 8 bits set Stage-3 - Label#3: for ODU0 layer with 1 out of 2 bits set } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: ccamp@ietf.org Cc: Khuzema Pithewan ; Mohit Misra Sent: Wednesday, October 27, 2010 5:26 AM Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls= -signaling-g709-00.txt Hi, We have a draft on "GMPLS Signaling extensions for OTN" available for revie= w. It can be accessed from the following link: http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt The above draft is not on IETF repository as we missed the submission deadl= ine. We will submit to IETF as soon as possible. Please review and comment. Abstract: As OTN network capabilities continue to evolve, there is an increased need= to support GMPLS control for the same. [RFC4328] introduced GMPLS signalin= g extensions for supporting early version of G.709 [G.709-v1].The basic rou= ting considerations from signaling perspective is also specified in [RFC432= 8]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] h= ave introduced new ODU containers (both fixed and flexible) and additional = ODU multiplexing capabilities, enabling support for optimal service aggrega= tion. This document extends [RFC4328] to provide GMPLS signaling support for the = new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling ext= ensions described in this document caters to ODU layer switching only. Opti= cal Channel Layer switching considerations in [RFC4328] are not modified in= this document. Thanks Authors ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05353SVEXDB1infine_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

John, et al

 

Please see response inline= .

 

Thanks

Rajan

 =

From: John E Drake [mailto:jdrake@juniper.net]
Sent: Friday, October 29, 2010 1:41 PM
To: Rajan Rao; ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extension= s for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi,

 =

Per RFC6001, the B-D ODU= 2 link would be advertised as a virtual TE Link.  This is necessary because otherwise the CSPF at A will not consider routing the ODU0 LSP via B, C, an= d D.

 =

[Rajan] {

This is not the case. =A0E= ven without virtual TE link or FA-LSP =A0the ODU0 LSPs can be setup between A-E. This i= s =A0because we advertise #ODU0s for OTU3 links B-C & C-D.=A0 Note that #ODU0 contai= ners advertised is non-zero even though TSG=3D2.5G. This is the key point here. =

We are no longer bound by MinLSP-BW as ODU0 BW is advertized as a separate sub-TLV within SCSI. =

 

The instantiation of ODU2 = to support ODU0 is done as part of signaling which brings in the label format = for mux levels.=A0 The instantiation of mux layers is a local matter.=A0 This c= an be different on each segment. The labels tell exactly what to instantiate on the local interface.=A0

 

In this example, each NE d= ecides locally (segment basis) how ODU0 should/can be supported. =A0If it requires additional mux layers they are requested in the label going down stream.

}

 =

When the ODU0 Path messa= ge is received at B, it is held up while a separate ODU2 Path message is sent from B to C = to D to activate the B-D ODU2 Link.  Once it is activated, using LSP Hierar= chy ( RFC4206) B sends the ODU0 request to D, which in turn sends it to E.=

[Rajan] {

This is allowed. As said b= elow, this is an alternate way. We can do without this as shown in the examples.<= o:p>

}

 

When we were first devel= oping GMPLS, we looked at packaging multiple LSP setup requests together and deci= ded it was a Bad Idea™.  So, the multistage signaling you are sugges= ting is not only unnecessary, but not in alignment with the GMPLS architecture.<= o:p>

[Rajan] {

=A0Not sure on the alignme= nt.=A0 =A0=A0Think of a scenario where I have muxing restriction within an FA. What do you do here?=A0 Create more FAs?=A0 Works of course with scaling implications.=A0= =A0

}

The other alternatives a= re to instantiate the B-D ODU2 link or  B-C and C-D ODU2 links beforehand. <= o:p>

[Rajan] {

=A0Agree, =A0this is liste= d as FA case in the example below.

}

 =

Thanks,

 =

John

 =

Sent from my iPhone=

 =

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Rajan Rao
Sent: Friday, October 29, 2010 12:05 PM
To: ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Subject: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions fo= r G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Fatai,

 

Interesting discussio= n. Please find the response below.

 

Authors of draft-khuz= ema

 

-----Original Message-----
From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: ccamp@ietf.org; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

You said there are the following differences betwee= n two drafts:

-  G.709 multi-stage multiplexing (v3 & be= yond)

-  NMC treatment (ref to section-4 in the draf= t)

-  Support for VCAT (NVC >1 )

- TPN format

 

We have to repeat that there is not much substantia= l difference between two drafts except multi-stage muxing.

 

We don't want to talk more on "NMC", "NVC", "TPN", because they have been discussed before a= nd it is quite easy for [draft-zhang] to do that. For example, for NMC, there = is an editors note in the previous versions  such as 04 version to discus= s NMC stuff (and some people opposed to deprecate NMC). For NVC, it is obviou= sly that [draft-zhang] can support it.

 

Now we can focus your key driver-multi-stage muxing= .

 

1) At page 3, in the list of added OTN features is present explicitly the "Multi-stage ODU Multiplexing". Actually, = multi-stage is not present at all as requirement/featur= e in G.709. Our intention to postpone technical solution regarding multi-stage multiplexing is justified by on going ITU-T SG15 progress. Befo= re thinking about specific signaling and routing solutions we need to have sta= ble ITU-T requirements. This why in all our common drafts (FWK, Info-Model, Rou= ting and Signaling drafts) we just placed some placeholder on the subject.<= /o:p>

 

[AK, KP, RR] { <= /o:p>

 Your understand= ing is not correct. Please refer to Figure-7-1A (G.709 12/2009). It clearly shows = multi-stage muxing. G.709 doesn’t mandate it has to be single stage. The G.709 OT= N frame formats fully support this capability.

 

Vendors may choose to implement limited number of muxing levels. This should not impact the signa= ling solution we come up with.

}

 

 

2) We are confused by your simplified multi-stage m= uxing label distribution rule

 

There is no detailed text to describe multi-stage m= uxing label distribution procedures in your draft and your explaination in your b= elow mail just focuses on one single node rather than how to create the end-to-e= nd LSP.

 

It is known that GMPLS standard procedure impose th= at every node has to allocate a label/labels consistent with the Generalized L= abel Request. Very important: Generalized Label Request cannot be changed during signaling path.

[AK, KP, RR]{

  There is no disagreement here.  Generalized label request doesn’t change. It= is fully consistent with RFC-4328. This is precisely the reason why we spelled= out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuzema).

 

Multi-stage label con= cept is enforced on the Generalized Label only. This affects only the labels exchanged between the peers. This does not affect the Generalized Label Req= uest  which is relayed end-to-end.

}

 

For example, taking ODU1-ODU2-ODU3 two-stage muxing= , which means that we need a service ODU1 that will be muxed into ODU2 and th= en ODU3. Assume the path is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demuxing. How you to create the LSP? how you to distribute= the labels in Node B, C, D? What is the traffic parameters will be transmitted = in the nodes B, C, D and nodes A, E?

 

[AK, KP, RR]{

 

Ther= e are 2 ways to handle this case: with FA or without FA. Both are explained with an example below      

 

 We have expande= d the example as follows:

 

   &nb= sp;      A---------------B---------------C---------------D----------------E

   &nb= sp;            OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

 Assume that:

   - ODU0 L= SP is created from A to E.

   - ODU3 l= inks between B-C and C-D support TS-Granularity of 2.5G only.  Hence ODU0 service can be supported on this interface only through ODU3-ODU2-ODU0 = ; or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example.

-    Generalized La= bel request in this case will be for ODU0 only.

 

Case-1) Without FA: T= he ODU2 layer created on B-C and C-D does not run between B & D.  They terminate between B-C and C-D respectively.  Following is the layering= and multi-stage label that needs to exchanged between the nodes.

 

 

          A---------------B---------------C---------------D----------------E

          =       OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

          |<-------------------------------------------------------------=E0| &= nbsp;       

          |             &= nbsp;           &nbs= p; ODU0          &nb= sp;            =           |

          |=DF--------= ----=E0| &= nbsp;           &nbs= p;            &= nbsp;    |=DF--------= ----=E0| &= nbsp;         

          |       ODU1     |         &n= bsp;            = ;         |      ODU1     |

          |            &n= bsp;   |=DF--------= ---=E0|= =DF--------= ----=E0| &= nbsp;           &nbs= p; |

          |            &n= bsp;   |      ODU2    |      ODU2      |               |

          |                |=DF-----------=E0|=DF------------=E0|     &nb= sp;         |

          |            &n= bsp;   |      ODU3    |      ODU3      |            &n= bsp;  |

          |        &n= bsp;       |            &n= bsp; |                |      &n= bsp;        |

Label     |            &n= bsp;   |            &n= bsp; |            &n= bsp;   |            &n= bsp;  |

#of stages|        1       |         2    |&nbs= p;        2      |         1     = ;|

Stage-1   |   ODU1=DFODU0&nbs= p;  |   ODU3=DFODU2  |   ODU3=DFODU2   |  &nbs= p; ODU1=DFODU0 &nb= sp;|

Stage-2   |            &n= bsp;   |   ODU2=DFODU0  |   ODU2=DFODU0   |            &n= bsp;  |

------------------------------------------------------------= ------------------

 

Case= -2) With FA:

If ODU2 needs to run = between B---D, we need to create an FA-LSP for ODU2 layer & this will be a TE-L= ink by itself. In that case, ODU0 will be routed directly over ODU2 – whi= ch is single stage only (no need of multi-stage label in that case).

 

The = creation of FA-LSP is outside the scope of our draft.

}

Thanks

Asho= k/Khuzema/Rajan

 

Thanks,

 

Authors of [draft-zhang-ccamp-gmpls-evolving-g709-0= 6.txt]

 

 

 

 

----- Original Message -----

From: "Rajan Rao" <rrao@infinera.com&g= t;

To: "Fatai Zhang" <zhangfatai@huawei.com>; "Khuzema Pithewan" <kpithewan@i= nfinera.com>; "Mohit Misra" <mmisra@infinera.com>; "Ashok Kunjidhapatham" <akunjidhapatham@infinera.com>

Cc: <ccamp@ietf.org>; "Biao Lu" <blu@infinera.com>

Sent: Thursday, October 28, 2010 2:17 PM=

Subject: RE: [CCAMP] Signaling extensions for G.709= - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

 

Fatai,

 

Please see response inline.

 

thanks

Rajan

________________________________________=

From: Fatai Zhang [zhangfatai@huawei.com]

Sent: Wednesday, October 27, 2010 6:08 PM

To: Rajan Rao; Khuzema Pithewan; Mohit Misra

Cc: ccamp@ietf.org; Zhang, Fatai

Subject: Re: [CCAMP] Signaling extensions for G.709= - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

Happy to see your draft, but except multi-stage mux= ing supported in your draft,  I don't see any substantial difference betwe= en your draft and [draft-zhang-ccamp-gmpls-evolving-g709-06.txt].

 

[Rajan]{

Multi stage muxing is one of the key drivers for&nb= sp; signaling extensions. Any solution is incomplete without this. The label fo= rmat proposed is intended to support G.709-v3 & future OTN extensions. Secti= on 5.2 in  draft-ietf-ccamp-gmpls-g709-framework-03  touches on this aspect!!

 

We see following key differences between the drafts= :

 Our draft addresses

-        &n= bsp; G.709 multi-stage multiplexing (v3 & beyond)

-        &n= bsp; NMC treatment (ref to section-4 in the draft)

-        &n= bsp; Support for VCAT (NVC >1 )

}

 

You may say that TPN info is incorporated into labe= l Object, but you know it is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and we already st= ated it in the slides for IETF78th meeting ( we just make the door open at this moment and there are some advantages to decouple TPN and Label).=

 

[Rajan]{

The key thing here is the mux layers.  The TPN= in label object is intended to address per mux layer case…. more efficie= nt.

I think this should be captured in framework doc (s= ection 3.1.2.1in framework doc doesn't cover hierarchy aspect clearly).

}

 

In addtion, for multi-stage muxing, I really suspec= t that it can be resolved so easily, because it is MLN stuff and it needs to indic= ate how to create the infrastructure FA-LSP (See RFC4206 and 4206bis). If it ca= n be done in this way as your draft describes, we all will be much happy.

 

[Rajan]{

The label structure we have defined is to address m= uxing levels of G.709.  This is not solving MLN using FA. i.e. it doesn̵= 7;t result in creation of FA automatically. There is no FA involved or intended here (out of scope). Please refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/.<= o:p>

 

 For example,  we need 3 labels to create= an ODU0 LSP with following muxing structure on a given TeLink

 

Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-O= DU0

 

Num-of-mux-stages =3D 3

Stage-1 - Label#1: for ODU2 layer with 8 out of 32 = bits set

Stage-2 - Label#2: for ODU1 layer with 2 out of 8 b= its set

Stage-3 - Label#3: for ODU0 layer with 1 out of 2 b= its set

 

}

 

 

Best Regards

 

Fatai

 

----- Original Message -----

From: Rajan Rao<mailto:rrao@infinera.com>

To: ccamp@ietf.org<mailto:ccamp@ietf.org>

Cc: Khuzema Pithewan<mailto:kpithewan@infinera.c= om> ; Mohit Misra<mailto:mmisra@infinera.com>

Sent: Wednesday, October 27, 2010 5:26 AM

Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi,

 

We have a draft on “GMPLS Signaling extension= s for OTN” available for review.  It can be accessed from the followin= g link:

http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g= 709-00.txt

The above draft is not on IETF repository as we mis= sed the submission deadline.  We will submit to IETF as soon as possible.<= o:p>

 

Please review and comment.

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased  need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is a= lso specified in [RFC4328].

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support fo= r optimal service aggregation.

This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in this document caters to OD= U layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document.

 

Thanks

Authors

 

________________________________

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

--_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05353SVEXDB1infine_-- From jdrake@juniper.net Fri Oct 29 15:37:13 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9933B3A6AE4 for ; Fri, 29 Oct 2010 15:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.075 X-Spam-Level: X-Spam-Status: No, score=-6.075 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DzBC7pExCwS for ; Fri, 29 Oct 2010 15:36:28 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 0A3D63A6ACD for ; Fri, 29 Oct 2010 15:36:27 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTMtM3TkWYJss6RSt4qUmTIQ5MLOMkLFE@postini.com; Fri, 29 Oct 2010 15:38:24 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 29 Oct 2010 15:35:10 -0700 From: John E Drake To: Rajan Rao , "ccamp@ietf.org" , Fatai Zhang Date: Fri, 29 Oct 2010 15:36:02 -0700 Thread-Topic: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Thread-Index: Act3PquV+PNZ8lg7Q6aOspVigb2/3AAKHrqAAAnob2AABiR60AAB+FyAAAEqZrA= Message-ID: <5E893DB832F57341992548CDBB33316398B51FC7D7@EMBX01-HQ.jnpr.net> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302@SV-EXDB1.infinera.com> <5E893DB832F57341992548CDBB33316398B51FC59F@EMBX01-HQ.jnpr.net> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05353@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05353@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB33316398B51FC7D7EMBX01HQjnprn_" MIME-Version: 1.0 Cc: Khuzema Pithewan , Radhakrishna Valiveti , Biao, Mohit Misra Subject: Re: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2010 22:37:24 -0000 --_000_5E893DB832F57341992548CDBB33316398B51FC7D7EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Snipped, comments inline Sent from my iPhone From: Rajan Rao [mailto:rrao@infinera.com] Sent: Friday, October 29, 2010 2:50 PM To: John E Drake; ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.70= 9 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt John, et al Please see response inline. Thanks Rajan From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, October 29, 2010 1:41 PM To: Rajan Rao; ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.70= 9 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Hi, Per RFC6001, the B-D ODU2 link would be advertised as a virtual TE Link. T= his is necessary because otherwise the CSPF at A will not consider routing = the ODU0 LSP via B, C, and D. [Rajan] { This is not the case. Even without virtual TE link or FA-LSP the ODU0 LSP= s can be setup between A-E. This is because we advertise #ODU0s for OTU3 l= inks B-C & C-D. JD: You are advertising ODU0 services on ODU3s that do not support them. = That isn't consistent with the GMPLs architecture. Note that #ODU0 containers advertised is non-zero even though TSG=3D2.5G. T= his is the key point here. We are no longer bound by MinLSP-BW as ODU0 BW is advertized as a separate = sub-TLV within SCSI. JD: In GMPLS, one could always advertise capabilities that one did not pos= sess. It's just not considered good form. The instantiation of ODU2 to support ODU0 is done as part of signaling whic= h brings in the label format for mux levels. The instantiation of mux laye= rs is a local matter. This can be different on each segment. The labels te= ll exactly what to instantiate on the local interface. In this example, each NE decides locally (segment basis) how ODU0 should/ca= n be supported. If it requires additional mux layers they are requested in= the label going down stream. JD: If you want to bring up one hop FAs on demand, that is fine. However= , the activation of these should be done with separate signaling requests. = That is how it is defined in the GMPLS architecture, as described in the n= ext paragraph. Rather than holding up the A-E ODU0 request at B while signaling the B-D OD= U2, B holds up the A-E ODU0 request while signaling the B-C ODU2, then forw= ards the A-E ODU0 request to C. C holds it up while signaling the C-D ODU2= , then forwards the A-E ODU0 request to D. If you want to do it this way, rather than with a two hop dynamic B-D ODU2 = FA, what should be advertised is B-C and C-D ODU2 virtual TE links. } --_000_5E893DB832F57341992548CDBB33316398B51FC7D7EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Snipped, comments inline=

 =

Sent from my iPhone=

 =

From: Rajan Rao [mailto:rrao@infinera.com]
Sent: Friday, October 29, 2010 2:50 PM
To: John E Drake; ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extension= s for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

John, et al

 

Please see response inline= .

 

Thanks

Rajan

 =

From: John E Drake [mailto:jdrake@juniper.net]
Sent: Friday, October 29, 2010 1:41 PM
To: Rajan Rao; ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extension= s for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi,

 =

Per RFC6001, the B-D ODU= 2 link would be advertised as a virtual TE Link.  This is necessary because otherwise the CSPF at A will not consider routing the ODU0 LSP via B, C, an= d D.

 =

[Rajan] {

This is not the case. &nbs= p;Even without virtual TE link or FA-LSP  the ODU0 LSPs can be setup between = A-E. This is  because we advertise #ODU0s for OTU3 links B-C & C-D.&nbs= p;

 =

JD:  You are advert= ising ODU0 services on ODU3s that do not support them.   That isn’= ;t consistent with the GMPLs architecture.

 =

Note that #ODU0 containers= advertised is non-zero even though TSG=3D2.5G. This is the key point here. =

We are no longer bound by MinLSP-BW as ODU0 BW is advertized as a separate sub-TLV within SCSI. =

 =

JD:  In GMPLS, one = could always advertise capabilities that one did not possess.   It̵= 7;s just not considered good form.

 

The instantiation of ODU2 = to support ODU0 is done as part of signaling which brings in the label format = for mux levels.  The instantiation of mux layers is a local matter.  = This can be different on each segment. The labels tell exactly what to instantia= te on the local interface. 

 

In this example, each NE d= ecides locally (segment basis) how ODU0 should/can be supported.  If it requi= res additional mux layers they are requested in the label going down stream.

 =

JD:   If you w= ant to bring up one hop FAs on demand, that is fine.  However, the activation= of these should be done with separate signaling requests.  That is how it= is defined in the GMPLS architecture, as described in the next paragraph.=

 =

Rather than holding up t= he A-E ODU0 request at B while signaling the B-D ODU2, B holds up the A-E ODU0 req= uest while signaling the B-C ODU2, then forwards the A-E ODU0 request to C. = ; C holds it up while signaling the C-D ODU2, then forwards the A-E ODU0 reques= t to D.

 =

If you want to do it thi= s way, rather than with a two hop dynamic B-D ODU2 FA, what should be advertised i= s B-C  and C-D ODU2 virtual TE links.

 =

}

 =

--_000_5E893DB832F57341992548CDBB33316398B51FC7D7EMBX01HQjnprn_-- From rrao@infinera.com Fri Oct 29 17:07:45 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2663A6996 for ; Fri, 29 Oct 2010 17:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=2.02] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7c9-vTXvz45 for ; Fri, 29 Oct 2010 17:07:44 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 93B973A695E for ; Fri, 29 Oct 2010 17:07:44 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Fri, 29 Oct 2010 17:08:58 -0700 From: Rajan Rao To: "draft-bccdg-ccamp-gmpls-ospf-agnostic@tools.ietf.org" Date: Fri, 29 Oct 2010 17:09:03 -0700 Thread-Topic: draft-bccdg-ccamp-gmpls-ospf-agnostic Thread-Index: Act3xqkUb6c0JmddTZGqa/plpejyHw== Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053ED@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053EDSVEXDB1infine_" MIME-Version: 1.0 Cc: Khuzema Pithewan , "ccamp@ietf.org" Subject: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 30 Oct 2010 00:07:45 -0000 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053EDSVEXDB1infine_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, We are trying to understand the generalization that is described in the dra= ft. Here are comments/questions: 1) Service Type: There seems to be an assumption that future technolog= ies are going to be container based, which may not be the case. - We do not know how TDM (post OTN) is going to evolve. With ODU= flex kind of functionality we are already moving away from fixed containers= . 2) If a customer deploys hybrid NEs that supports both SONET + OTN, wh= at is advertised by each NE? - SONET BW using BA or use RFC 4202 way? 3) If we introduce OTN box into a Sonet network, what is the expected = behavior? - Say Sonet is using RFC 4202 based BW advertisement 4) Repeating signal type for each priority is inefficient. Thanks Rajan --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053EDSVEXDB1infine_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors,

 

We are trying to understand the generalization that is described in the draft.  Here are comments/questions:

 

1)&n= bsp;     Service Type: There seems to be an assumptio= n that future technologies are going to be container based, which may not be = the case. 

-      =     We do not know how TDM (post OTN) is going to evolv= e.   With ODUflex kind of functionality we are already moving away from fixed contain= ers.

 

2)&n= bsp;     If a customer deploys hybrid NEs that supports both SONET + OTN, what is advertised by each NE?

-      =     SONET BW using BA or use RFC 4202 way?

 

3)&n= bsp;     If we introduce OTN box into a Sonet network, what = is the expected behavior?

-      =     Say Sonet is using RFC 4202 based BW advertisement<= o:p>

 

4)&n= bsp;     Repeating signal type for each priority is ineffici= ent.  

 

Thanks

Rajan

--_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053EDSVEXDB1infine_-- From rrao@infinera.com Fri Oct 29 17:59:01 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09A53A68BB for ; Fri, 29 Oct 2010 17:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBeS8jz5mtQC for ; Fri, 29 Oct 2010 17:58:44 -0700 (PDT) Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id A3C803A6819 for ; Fri, 29 Oct 2010 17:58:44 -0700 (PDT) Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Fri, 29 Oct 2010 17:59:58 -0700 From: Rajan Rao To: John E Drake , "ccamp@ietf.org" , Fatai Zhang Date: Fri, 29 Oct 2010 17:59:51 -0700 Thread-Topic: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Thread-Index: Act3PquV+PNZ8lg7Q6aOspVigb2/3AAKHrqAAAnob2AABiR60AAB+FyAAAcZTgA= Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053FD@SV-EXDB1.infinera.com> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302@SV-EXDB1.infinera.com> <5E893DB832F57341992548CDBB33316398B51FC59F@EMBX01-HQ.jnpr.net> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05353@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05353@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053FDSVEXDB1infine_" MIME-Version: 1.0 Cc: Biao, Radhakrishna Valiveti , Khuzema Pithewan , Mohit Misra Subject: Re: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 30 Oct 2010 00:59:01 -0000 --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053FDSVEXDB1infine_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, et al With the muxing structure of G.709, customers may chose to use the mux st= ages their own ways. Having FA-LSPs or virtual links on pt-2-pt segments do= esn't make much sense and will lead to scaling issues & managing complexiti= es. The signaling extensions can easily take care of OTN muxing hierarchy as sh= own in our draft. We should address MLN RFC-6001 alignment by adding OTN-= MLN details in the framework doc. Thanks Rajan From: Rajan Rao Sent: Friday, October 29, 2010 2:50 PM To: John E Drake; ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.70= 9 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt John, et al Please see response inline. Thanks Rajan From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, October 29, 2010 1:41 PM To: Rajan Rao; ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.70= 9 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Hi, Per RFC6001, the B-D ODU2 link would be advertised as a virtual TE Link. T= his is necessary because otherwise the CSPF at A will not consider routing = the ODU0 LSP via B, C, and D. [Rajan] { This is not the case. Even without virtual TE link or FA-LSP the ODU0 LSP= s can be setup between A-E. This is because we advertise #ODU0s for OTU3 l= inks B-C & C-D. Note that #ODU0 containers advertised is non-zero even tho= ugh TSG=3D2.5G. This is the key point here. We are no longer bound by MinLSP-BW as ODU0 BW is advertized as a separate = sub-TLV within SCSI. The instantiation of ODU2 to support ODU0 is done as part of signaling whic= h brings in the label format for mux levels. The instantiation of mux laye= rs is a local matter. This can be different on each segment. The labels te= ll exactly what to instantiate on the local interface. In this example, each NE decides locally (segment basis) how ODU0 should/ca= n be supported. If it requires additional mux layers they are requested in= the label going down stream. } When the ODU0 Path message is received at B, it is held up while a separate= ODU2 Path message is sent from B to C to D to activate the B-D ODU2 Link. = Once it is activated, using LSP Hierarchy ( RFC4206) B sends the ODU0 requ= est to D, which in turn sends it to E. [Rajan] { This is allowed. As said below, this is an alternate way. We can do without= this as shown in the examples. } When we were first developing GMPLS, we looked at packaging multiple LSP se= tup requests together and decided it was a Bad Idea(tm). So, the multistag= e signaling you are suggesting is not only unnecessary, but not in alignmen= t with the GMPLS architecture. [Rajan] { Not sure on the alignment. Think of a scenario where I have muxing rest= riction within an FA. What do you do here? Create more FAs? Works of cour= se with scaling implications. } The other alternatives are to instantiate the B-D ODU2 link or B-C and C-D= ODU2 links beforehand. [Rajan] { Agree, this is listed as FA case in the example below. } Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Friday, October 29, 2010 12:05 PM To: ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti Subject: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.709 - = draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Fatai, Interesting discussion. Please find the response below. Authors of draft-khuzema -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, October 29, 2010 1:26 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham Cc: ccamp@ietf.org; Biao Lu Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, You said there are the following differences between two drafts: - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) - TPN format We have to repeat that there is not much substantial difference between two= drafts except multi-stage muxing. We don't want to talk more on "NMC", "NVC", "TPN", because they have been d= iscussed before and it is quite easy for [draft-zhang] to do that. For exam= ple, for NMC, there is an editors note in the previous versions such as 04= version to discuss NMC stuff (and some people opposed to deprecate NMC). F= or NVC, it is obviously that [draft-zhang] can support it. Now we can focus your key driver-multi-stage muxing. 1) At page 3, in the list of added OTN features is present explicitly the "= Multi-stage ODU Multiplexing". Actually, multi-stage is not present at all = as requirement/feature in G.709. Our intention to postpone technical soluti= on regarding multi-stage multiplexing is justified by on going ITU-T SG15 p= rogress. Before thinking about specific signaling and routing solutions we = need to have stable ITU-T requirements. This why in all our common drafts (= FWK, Info-Model, Routing and Signaling drafts) we just placed some placehol= der on the subject. [AK, KP, RR] { Your understanding is not correct. Please refer to Figure-7-1A (G.709 12/2= 009). It clearly shows multi-stage muxing. G.709 doesn't mandate it has to = be single stage. The G.709 OTN frame formats fully support this capability. Vendors may choose to implement limited number of muxing levels. This shoul= d not impact the signaling solution we come up with. } 2) We are confused by your simplified multi-stage muxing label distribution= rule There is no detailed text to describe multi-stage muxing label distribution= procedures in your draft and your explaination in your below mail just foc= uses on one single node rather than how to create the end-to-end LSP. It is known that GMPLS standard procedure impose that every node has to all= ocate a label/labels consistent with the Generalized Label Request. Very im= portant: Generalized Label Request cannot be changed during signaling path. [AK, KP, RR]{ There is no disagreement here. Generalized label request doesn't change.= It is fully consistent with RFC-4328. This is precisely the reason why we = spelled out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuz= ema). Multi-stage label concept is enforced on the Generalized Label only. This a= ffects only the labels exchanged between the peers. This does not affect th= e Generalized Label Request which is relayed end-to-end. } For example, taking ODU1-ODU2-ODU3 two-stage muxing, which means that we ne= ed a service ODU1 that will be muxed into ODU2 and then ODU3. Assume the pa= th is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demu= xing. How you to create the LSP? how you to distribute the labels in Node B= , C, D? What is the traffic parameters will be transmitted in the nodes B, = C, D and nodes A, E? [AK, KP, RR]{ There are 2 ways to handle this case: with FA or without FA. Both are expla= ined with an example below We have expanded the example as follows: A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 Assume that: - ODU0 LSP is created from A to E. - ODU3 links between B-C and C-D support TS-Granularity of 2.5G only. H= ence ODU0 service can be supported on this interface only through ODU3-ODU2= -ODU0 or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example. - Generalized Label request in this case will be for ODU0 only. Case-1) Without FA: The ODU2 layer created on B-C and C-D does not run betw= een B & D. They terminate between B-C and C-D respectively. Following is = the layering and multi-stage label that needs to exchanged between the node= s. A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 |<---------------------------------------------------------------= >| | ODU0 = | |<---------------->| |<------------= ---->| | ODU1 | | ODU1 = | | |<--------------->|<---------------->| = | | | ODU2 | ODU2 | = | | |<--------------->|<---------------->| = | | | ODU3 | ODU3 | = | | | | | = | Label | | | | = | #of stages| 1 | 2 | 2 | 1 = | Stage-1 | ODU1<--ODU0 | ODU3<--ODU2 | ODU3<--ODU2 | ODU1<--= ODU0 | Stage-2 | | ODU2<--ODU0 | ODU2<--ODU0 | = | ---------------------------------------------------------------------------= --- Case-2) With FA: If ODU2 needs to run between B---D, we need to create an FA-LSP for ODU2 la= yer & this will be a TE-Link by itself. In that case, ODU0 will be routed d= irectly over ODU2 - which is single stage only (no need of multi-stage labe= l in that case). The creation of FA-LSP is outside the scope of our draft. } Thanks Ashok/Khuzema/Rajan Thanks, Authors of [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] ----- Original Message ----- From: "Rajan Rao" To: "Fatai Zhang" ; "Khuzema Pithewan" ; "Mohit Misra" ; "Ashok Kunjidhapatham" Cc: ; "Biao Lu" Sent: Thursday, October 28, 2010 2:17 PM Subject: RE: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Fatai, Please see response inline. thanks Rajan ________________________________________ From: Fatai Zhang [zhangfatai@huawei.com] Sent: Wednesday, October 27, 2010 6:08 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra Cc: ccamp@ietf.org; Zhang, Fatai Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, Happy to see your draft, but except multi-stage muxing supported in your dr= aft, I don't see any substantial difference between your draft and [draft-= zhang-ccamp-gmpls-evolving-g709-06.txt]. [Rajan]{ Multi stage muxing is one of the key drivers for signaling extensions. Any= solution is incomplete without this. The label format proposed is intended= to support G.709-v3 & future OTN extensions. Section 5.2 in draft-ietf-cc= amp-gmpls-g709-framework-03 touches on this aspect!! We see following key differences between the drafts: Our draft addresses - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) } You may say that TPN info is incorporated into label Object, but you know i= t is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and= we already stated it in the slides for IETF78th meeting ( we just make the= door open at this moment and there are some advantages to decouple TPN and= Label). [Rajan]{ The key thing here is the mux layers. The TPN in label object is intended = to address per mux layer case.... more efficient. I think this should be captured in framework doc (section 3.1.2.1in framewo= rk doc doesn't cover hierarchy aspect clearly). } In addtion, for multi-stage muxing, I really suspect that it can be resolve= d so easily, because it is MLN stuff and it needs to indicate how to create= the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can be done in = this way as your draft describes, we all will be much happy. [Rajan]{ The label structure we have defined is to address muxing levels of G.709. = This is not solving MLN using FA. i.e. it doesn't result in creation of FA = automatically. There is no FA involved or intended here (out of scope). Ple= ase refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-cc= amp-gmpls-ospf-g709/. For example, we need 3 labels to create an ODU0 LSP with following muxing= structure on a given TeLink Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-ODU0 Num-of-mux-stages =3D 3 Stage-1 - Label#1: for ODU2 layer with 8 out of 32 bits set Stage-2 - Label#2: for ODU1 layer with 2 out of 8 bits set Stage-3 - Label#3: for ODU0 layer with 1 out of 2 bits set } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: ccamp@ietf.org Cc: Khuzema Pithewan ; Mohit Misra Sent: Wednesday, October 27, 2010 5:26 AM Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls= -signaling-g709-00.txt Hi, We have a draft on "GMPLS Signaling extensions for OTN" available for revie= w. It can be accessed from the following link: http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt The above draft is not on IETF repository as we missed the submission deadl= ine. We will submit to IETF as soon as possible. Please review and comment. Abstract: As OTN network capabilities continue to evolve, there is an increased need= to support GMPLS control for the same. [RFC4328] introduced GMPLS signalin= g extensions for supporting early version of G.709 [G.709-v1].The basic rou= ting considerations from signaling perspective is also specified in [RFC432= 8]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] h= ave introduced new ODU containers (both fixed and flexible) and additional = ODU multiplexing capabilities, enabling support for optimal service aggrega= tion. This document extends [RFC4328] to provide GMPLS signaling support for the = new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling ext= ensions described in this document caters to ODU layer switching only. Opti= cal Channel Layer switching considerations in [RFC4328] are not modified in= this document. Thanks Authors ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053FDSVEXDB1infine_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

John, et al

 =

With the muxing structur= e of G.709, =A0=A0customers may chose to use the mux stages their own ways. Havi= ng FA-LSPs or virtual links on pt-2-pt segments doesn’t make much sense and will lead to scaling issues & managing complexities.

 =

The signaling extensions= can easily take care of OTN muxing hierarchy as shown in our draft.=A0 We should addre= ss MLN RFC-6001 alignment =A0by adding OTN-MLN details in the =A0framework doc.

 =

Thanks=

Rajan<= /p>

 =

From: Rajan Rao Sent: Friday, October 29, 2010 2:50 PM
To: John E Drake; ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extension= s for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

John, et al

 

Please see response inline= .

 

Thanks

Rajan

 =

From: John E Drake [mailto:jdrake@juniper.net]
Sent: Friday, October 29, 2010 1:41 PM
To: Rajan Rao; ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extension= s for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi,

 =

Per RFC6001, the B-D ODU= 2 link would be advertised as a virtual TE Link.  This is necessary because otherwise the CSPF at A will not consider routing the ODU0 LSP via B, C, an= d D.

 =

[Rajan] {

This is not the case. &nbs= p;Even without virtual TE link or FA-LSP  the ODU0 LSPs can be setup between = A-E. This is  because we advertise #ODU0s for OTU3 links B-C & C-D.&nbs= p; Note that #ODU0 containers advertised is non-zero even though TSG=3D2.5G. T= his is the key point here.

We are no longer bound by MinLSP-BW as ODU0 BW is advertized as a separate sub-TLV within SCSI. =

 

The instantiation of ODU2 = to support ODU0 is done as part of signaling which brings in the label format = for mux levels.  The instantiation of mux layers is a local matter.  = This can be different on each segment. The labels tell exactly what to instantia= te on the local interface. 

 

In this example, each NE d= ecides locally (segment basis) how ODU0 should/can be supported.  If it requi= res additional mux layers they are requested in the label going down stream.

}

 =

When the ODU0 Path messa= ge is received at B, it is held up while a separate ODU2 Path message is sent fro= m B to C to D to activate the B-D ODU2 Link.  Once it is activated, using = LSP Hierarchy ( RFC4206) B sends the ODU0 request to D, which in turn sends it = to E.

[Rajan] {

This is allowed. As said b= elow, this is an alternate way. We can do without this as shown in the examples.<= o:p>

}

 

When we were first devel= oping GMPLS, we looked at packaging multiple LSP setup requests together and deci= ded it was a Bad Idea™.  So, the multistage signaling you are sugges= ting is not only unnecessary, but not in alignment with the GMPLS architecture.<= o:p>

[Rajan] {

 Not sure on the alignment.    Think of a scenario where I have muxing restriction within an FA. What do you do here?  Create more FAs?  Works of course with scaling implications.  

}

The other alternatives a= re to instantiate the B-D ODU2 link or  B-C and C-D ODU2 links beforehand. <= o:p>

[Rajan] {

 Agree,  this is= listed as FA case in the example below.

}

 =

Thanks,

 =

John

 =

Sent from my iPhone=

 =

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Rajan Rao
Sent: Friday, October 29, 2010 12:05 PM
To: ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Subject: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions fo= r G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Fatai,

 

Interesting discussio= n. Please find the response below.

 

Authors of draft-khuz= ema

 

-----Original Message-----
From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: ccamp@ietf.org; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

You said there are the following differences betwee= n two drafts:

-  G.709 multi-stage multiplexing (v3 & be= yond)

-  NMC treatment (ref to section-4 in the draf= t)

-  Support for VCAT (NVC >1 )

- TPN format

 

We have to repeat that there is not much substantia= l difference between two drafts except multi-stage muxing.

 

We don't want to talk more on "NMC", "NVC", "TPN", because they have been discussed before a= nd it is quite easy for [draft-zhang] to do that. For example, for NMC, there = is an editors note in the previous versions  such as 04 version to discus= s NMC stuff (and some people opposed to deprecate NMC). For NVC, it is obviou= sly that [draft-zhang] can support it.

 

Now we can focus your key driver-multi-stage muxing= .

 

1) At page 3, in the list of added OTN features is present explicitly the "Multi-stage ODU Multiplexing". Actually, = multi-stage is not present at all as requirement/featur= e in G.709. Our intention to postpone technical solution regarding multi-stage multiplexing is justified by on going ITU-T SG15 progress. Befo= re thinking about specific signaling and routing solutions we need to have sta= ble ITU-T requirements. This why in all our common drafts (FWK, Info-Model, Rou= ting and Signaling drafts) we just placed some placeholder on the subject.<= /o:p>

 

[AK, KP, RR] { <= /o:p>

 Your understand= ing is not correct. Please refer to Figure-7-1A (G.709 12/2009). It clearly shows multi-stage muxing. G.709 doesn’t mandate it has to be single stage. = The G.709 OTN frame formats fully support this capability.

 

Vendors may choose to implement limited number of muxing levels. This should not impact the signa= ling solution we come up with.

}

 

 

2) We are confused by your simplified multi-stage m= uxing label distribution rule

 

There is no detailed text to describe multi-stage m= uxing label distribution procedures in your draft and your explaination in your b= elow mail just focuses on one single node rather than how to create the end-to-e= nd LSP.

 

It is known that GMPLS standard procedure impose th= at every node has to allocate a label/labels consistent with the Generalized L= abel Request. Very important: Generalized Label Request cannot be changed during signaling path.

[AK, KP, RR]{

  There is no disagreement here.  Generalized label request doesn’t change. It= is fully consistent with RFC-4328. This is precisely the reason why we spelled= out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuzema).

 

Multi-stage label con= cept is enforced on the Generalized Label only. This affects only the labels exchanged between the peers. This does not affect the Generalized Label Req= uest  which is relayed end-to-end.

}

 

For example, taking ODU1-ODU2-ODU3 two-stage muxing= , which means that we need a service ODU1 that will be muxed into ODU2 and th= en ODU3. Assume the path is A-B-C-D-E, in node B and node D will finish the tw= o-stage muxing/demuxing. How you to create the LSP? how you to distribute the label= s in Node B, C, D? What is the traffic parameters will be transmitted in the nod= es B, C, D and nodes A, E?

 

[AK, KP, RR]{

 

Ther= e are 2 ways to handle this case: with FA or without FA. Both are explained with an example below      

 

 We have expande= d the example as follows:

 

   &nb= sp;      A---------------B---------------C---------------D----------------E

   &nb= sp;            OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

 Assume that:

   - ODU0 L= SP is created from A to E.

   - ODU3 l= inks between B-C and C-D support TS-Granularity of 2.5G only.  Hence ODU0 service can be supported on this interface only through ODU3-ODU2-ODU0 = ; or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example.

-    Generalized La= bel request in this case will be for ODU0 only.

 

Case-1) Without FA: T= he ODU2 layer created on B-C and C-D does not run between B & D.  They terminate between B-C and C-D respectively.  Following is the layering= and multi-stage label that needs to exchanged between the nodes.

 

 

          A---------------B---------------C---------------D----------------E

          =       OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

          |<-------------------------------------------------------------=E0| &= nbsp;       

          |                  &nb= sp;        ODU0   &n= bsp;            = ;            &n= bsp;    |

          |=DF--------= ----=E0| &= nbsp;           &nbs= p;            &= nbsp;    |=DF--------= ----=E0| &= nbsp;         

          |       ODU1     |         &n= bsp;            = ;         |      ODU1     |

          |            &n= bsp;   |=DF--------= ---=E0|= =DF--------= ----=E0| &= nbsp;           &nbs= p; |

          |            &n= bsp;   |      ODU2    |      ODU2      |               |

          |                |=DF-----------=E0|=DF------------=E0|     &nb= sp;         |

          |            &n= bsp;   |      ODU3    |      ODU3      |            &n= bsp;  |

          |        &n= bsp;       |            &n= bsp; |                |      &n= bsp;        |

Label     |            &n= bsp;   |            &n= bsp; |            &n= bsp;   |            &n= bsp;  |

#of stages|        1       |         2    |&nbs= p;        2      |         1     = ;|

Stage-1   |   ODU1=DFODU0&nbs= p;  |   ODU3=DFODU2  |   ODU3=DFODU2   |  &nbs= p; ODU1=DFODU0 &nb= sp;|

Stage-2   |            &n= bsp;   |   ODU2=DFODU0  |   ODU2=DFODU0   |            &n= bsp;  |

------------------------------------------------------------= ------------------

 

Case= -2) With FA:

If ODU2 needs to run = between B---D, we need to create an FA-LSP for ODU2 layer & this will be a TE-L= ink by itself. In that case, ODU0 will be routed directly over ODU2 – whi= ch is single stage only (no need of multi-stage label in that case).

 

The = creation of FA-LSP is outside the scope of our draft.

}

Thanks

Asho= k/Khuzema/Rajan

 

Thanks,

 

Authors of [draft-zhang-ccamp-gmpls-evolving-g709-0= 6.txt]

 

 

 

 

----- Original Message -----

From: "Rajan Rao" <rrao@infinera.com&g= t;

To: "Fatai Zhang" <zhangfatai@huawei.com>; "Khuzema Pithewan" <kpithewan@infinera.com>; "Mohit Misra" <mmisra@infinera.com>; "Ashok Kunjidhapatham" <akunjidhapatham@infinera.com>

Cc: <ccamp@ietf.org>; "Biao Lu" <blu@infinera.com>

Sent: Thursday, October 28, 2010 2:17 PM=

Subject: RE: [CCAMP] Signaling extensions for G.709= - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

 

Fatai,

 

Please see response inline.

 

thanks

Rajan

________________________________________=

From: Fatai Zhang [zhangfatai@huawei.com]

Sent: Wednesday, October 27, 2010 6:08 PM

To: Rajan Rao; Khuzema Pithewan; Mohit Misra

Cc: ccamp@ietf.org; Zhang, Fatai

Subject: Re: [CCAMP] Signaling extensions for G.709= - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

Happy to see your draft, but except multi-stage mux= ing supported in your draft,  I don't see any substantial difference betwe= en your draft and [draft-zhang-ccamp-gmpls-evolving-g709-06.txt].

 

[Rajan]{

Multi stage muxing is one of the key drivers for&nb= sp; signaling extensions. Any solution is incomplete without this. The label fo= rmat proposed is intended to support G.709-v3 & future OTN extensions. Secti= on 5.2 in  draft-ietf-ccamp-gmpls-g709-framework-03  touches on this aspect!!

 

We see following key differences between the drafts= :

 Our draft addresses

-        &n= bsp; G.709 multi-stage multiplexing (v3 & beyond)

-        &n= bsp; NMC treatment (ref to section-4 in the draft)

-        &n= bsp; Support for VCAT (NVC >1 )

}

 

You may say that TPN info is incorporated into labe= l Object, but you know it is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] = to do that and we already stated it in the slides for IETF78th meeting ( we ju= st make the door open at this moment and there are some advantages to decouple= TPN and Label).

 

[Rajan]{

The key thing here is the mux layers.  The TPN= in label object is intended to address per mux layer case…. more efficie= nt.

I think this should be captured in framework doc (s= ection 3.1.2.1in framework doc doesn't cover hierarchy aspect clearly).

}

 

In addtion, for multi-stage muxing, I really suspec= t that it can be resolved so easily, because it is MLN stuff and it needs to indic= ate how to create the infrastructure FA-LSP (See RFC4206 and 4206bis). If it ca= n be done in this way as your draft describes, we all will be much happy.

 

[Rajan]{

The label structure we have defined is to address m= uxing levels of G.709.  This is not solving MLN using FA. i.e. it doesn̵= 7;t result in creation of FA automatically. There is no FA involved or intended here (out of scope). Please refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/.<= o:p>

 

 For example,  we need 3 labels to create= an ODU0 LSP with following muxing structure on a given TeLink

 

Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-O= DU0

 

Num-of-mux-stages =3D 3

Stage-1 - Label#1: for ODU2 layer with 8 out of 32 = bits set

Stage-2 - Label#2: for ODU1 layer with 2 out of 8 b= its set

Stage-3 - Label#3: for ODU0 layer with 1 out of 2 b= its set

 

}

 

 

Best Regards

 

Fatai

 

----- Original Message -----

From: Rajan Rao<mailto:rrao@infinera.com>

To: ccamp@ietf.org<mailto:ccamp@ietf.org>

Cc: Khuzema Pithewan<mailto:kpithewan@infinera.c= om> ; Mohit Misra<mailto:mmisra@infinera.com>

Sent: Wednesday, October 27, 2010 5:26 AM

Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi,

 

We have a draft on “GMPLS Signaling extension= s for OTN” available for review.  It can be accessed from the followin= g link:

http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g= 709-00.txt

The above draft is not on IETF repository as we mis= sed the submission deadline.  We will submit to IETF as soon as possible.<= o:p>

 

Please review and comment.

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased  need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is a= lso specified in [RFC4328].

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support fo= r optimal service aggregation.

This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in this document caters to OD= U layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document.

 

Thanks

Authors

 

________________________________

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

--_000_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053FDSVEXDB1infine_-- From jdrake@juniper.net Sat Oct 30 07:22:31 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABD73A69E7 for ; Sat, 30 Oct 2010 07:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K42urD6yf6XU for ; Sat, 30 Oct 2010 07:22:30 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id EE6603A69C5 for ; Sat, 30 Oct 2010 07:22:29 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTMwqUdjB9sc3L72eEf8s+reoMvW5SyfO@postini.com; Sat, 30 Oct 2010 07:24:27 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Sat, 30 Oct 2010 07:23:11 -0700 From: John E Drake To: Rajan Rao , "draft-bccdg-ccamp-gmpls-ospf-agnostic@tools.ietf.org" Date: Sat, 30 Oct 2010 07:24:01 -0700 Thread-Topic: draft-bccdg-ccamp-gmpls-ospf-agnostic Thread-Index: Act3xqkUb6c0JmddTZGqa/plpejyHwAdbr3w Message-ID: <5E893DB832F57341992548CDBB33316398B51FCA38@EMBX01-HQ.jnpr.net> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053ED@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053ED@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB33316398B51FCA38EMBX01HQjnprn_" MIME-Version: 1.0 Cc: Khuzema Pithewan , "ccamp@ietf.org" , "Ext - GFrank@Infinera.com" Subject: Re: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 30 Oct 2010 14:22:31 -0000 --_000_5E893DB832F57341992548CDBB33316398B51FCA38EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments inline. The point you continue to ignore is that the information= in the BA could be re-encoded however the group decides. Sent from my iPhone From: Rajan Rao [mailto:rrao@infinera.com] Sent: Friday, October 29, 2010 5:09 PM To: draft-bccdg-ccamp-gmpls-ospf-agnostic@tools.ietf.org Cc: ccamp@ietf.org; Ashok Kunjidhapatham; Khuzema Pithewan; Biao Lu; Ext - = GFrank@Infinera.com Subject: draft-bccdg-ccamp-gmpls-ospf-agnostic Authors, We are trying to understand the generalization that is described in the dra= ft. Here are comments/questions: 1) Service Type: There seems to be an assumption that future technolog= ies are going to be container based, which may not be the case. - We do not know how TDM (post OTN) is going to evolve. With ODU= flex kind of functionality we are already moving away from fixed containers= . JD: The default is IEEE floating point bytes per second. A technology spe= cific advertisement can change the units. ODUj is advertised with an insta= nce count, while ODUflex is advertised with the default. 2) If a customer deploys hybrid NEs that supports both SONET + OTN, wh= at is advertised by each NE? - SONET BW using BA or use RFC 4202 way? JD: SDH would be advertised using 4202, unless a technology specific SDH B= A is defined. In this case, during the transition period the nodes that un= derstand both would probably advertise both. Note that SDH signaling is no= t changed by the new BA. 3) If we introduce OTN box into a Sonet network, what is the expected = behavior? - Say Sonet is using RFC 4202 based BW advertisement JD: Ships in the night. 4) Repeating signal type for each priority is inefficient. JD: No, it is necessary. You will not have the same bandwidth at differen= t priority levels. Thanks Rajan --_000_5E893DB832F57341992548CDBB33316398B51FCA38EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments inline. &n= bsp; The point you continue to ignore is that the information in the BA could be re-encoded however the group decides.

 =

Sent from my iPhone=

 =

From: Rajan Rao [mailto:rrao@infinera.com]
Sent: Friday, October 29, 2010 5:09 PM
To: draft-bccdg-ccamp-gmpls-ospf-agnostic@tools.ietf.org
Cc: ccamp@ietf.org; Ashok Kunjidhapatham; Khuzema Pithewan; Biao Lu;= Ext - GFrank@Infinera.com
Subject: draft-bccdg-ccamp-gmpls-ospf-agnostic

 

Authors,

 

We are trying to understand the generalization that is described in the draft.  Here are comments/questions:

 

1)&n= bsp;     Service Type: There seems to be an assumptio= n that future technologies are going to be container based, which may not be = the case. 

-      =     We do not know how TDM (post OTN) is going to evolv= e.   With ODUflex kind of functionality we are already moving away f= rom fixed containers.

 =

JD:  The default is= IEEE floating point bytes per second.  A technology specific advertisement = can change the units.  ODUj is advertised with an instance count, while&nb= sp; ODUflex is advertised with the default.

 =

2)&n= bsp;     If a customer deploys hybrid NEs that supports both SONET + OTN, what is advertised by each NE?

-      =     SONET BW using BA or use RFC 4202 way?

 =

JD:  SDH would be a= dvertised using 4202, unless a technology specific SDH BA is defined.  In this c= ase, during the transition period the nodes that understand both would probably = advertise both.  Note that SDH signaling is not changed by the new BA.  

 

3)&n= bsp;     If we introduce OTN box into a Sonet network, what = is the expected behavior?

-      =     Say Sonet is using RFC 4202 based BW advertisement<= o:p>

 =

JD:  Ships in the n= ight.

 

4)&n= bsp;     Repeating signal type for each priority is ineffici= ent.

 =

JD:  No, it is necessary.  You will not have the same bandwidth at different priority levels.

 

 

Thanks

Rajan

--_000_5E893DB832F57341992548CDBB33316398B51FCA38EMBX01HQjnprn_-- From jdrake@juniper.net Sat Oct 30 07:38:38 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3D83A67E3 for ; Sat, 30 Oct 2010 07:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUVSqo6LC7iy for ; Sat, 30 Oct 2010 07:38:20 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 291673A6A00 for ; Sat, 30 Oct 2010 07:37:35 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTMwt9EL+ChYNFD/+s5TWDSxryT4ARKex@postini.com; Sat, 30 Oct 2010 07:39:35 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Sat, 30 Oct 2010 07:34:23 -0700 From: John E Drake To: Rajan Rao , "ccamp@ietf.org" , Fatai Zhang Date: Sat, 30 Oct 2010 07:35:14 -0700 Thread-Topic: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Thread-Index: Act3PquV+PNZ8lg7Q6aOspVigb2/3AAKHrqAAAnob2AABiR60AAB+FyAAAcZTgAAHKAG8A== Message-ID: <5E893DB832F57341992548CDBB33316398B51FCA3C@EMBX01-HQ.jnpr.net> References: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302@SV-EXDB1.infinera.com> <5E893DB832F57341992548CDBB33316398B51FC59F@EMBX01-HQ.jnpr.net> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05353@SV-EXDB1.infinera.com> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053FD@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E053FD@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB33316398B51FCA3CEMBX01HQjnprn_" MIME-Version: 1.0 Cc: Khuzema Pithewan , Radhakrishna Valiveti , Biao, Mohit Misra Subject: Re: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 30 Oct 2010 14:38:38 -0000 --_000_5E893DB832F57341992548CDBB33316398B51FCA3CEMBX01HQjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments inline. Sent from my iPhone From: Rajan Rao [mailto:rrao@infinera.com] Sent: Friday, October 29, 2010 6:00 PM To: John E Drake; ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu; Rajan Ra= o Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.70= 9 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt John, et al With the muxing structure of G.709, customers may chose to use the mux st= ages their own ways. Having FA-LSPs or virtual links on pt-2-pt segments do= esn't make much sense and will lead to scaling issues & managing complexiti= es. JD: You are making an assertion. Since in this example we are talking ab= out a node that can activate an ODU2 dynamically, it could advertise the OD= U0, as you suggested. Why you would want to do this rather than having mul= ti-hop FAs between select points in the network is beyond me, except as a d= ebating point. JD: However, the more important point is that *existing* GMPLS signaling *= exactly* supports the configuration in your example. The signaling extensions can easily take care of OTN muxing hierarchy as sh= own in our draft. We should address MLN RFC-6001 alignment by adding OTN-= MLN details in the framework doc. JD: See above. Btw, in your proposal where are the parameters associated = with establishing the ODU2 carried? Thanks Rajan From: Rajan Rao Sent: Friday, October 29, 2010 2:50 PM To: John E Drake; ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.70= 9 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt John, et al Please see response inline. Thanks Rajan From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, October 29, 2010 1:41 PM To: Rajan Rao; ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.70= 9 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Hi, Per RFC6001, the B-D ODU2 link would be advertised as a virtual TE Link. T= his is necessary because otherwise the CSPF at A will not consider routing = the ODU0 LSP via B, C, and D. [Rajan] { This is not the case. Even without virtual TE link or FA-LSP the ODU0 LSP= s can be setup between A-E. This is because we advertise #ODU0s for OTU3 l= inks B-C & C-D. Note that #ODU0 containers advertised is non-zero even tho= ugh TSG=3D2.5G. This is the key point here. We are no longer bound by MinLSP-BW as ODU0 BW is advertized as a separate = sub-TLV within SCSI. The instantiation of ODU2 to support ODU0 is done as part of signaling whic= h brings in the label format for mux levels. The instantiation of mux laye= rs is a local matter. This can be different on each segment. The labels te= ll exactly what to instantiate on the local interface. In this example, each NE decides locally (segment basis) how ODU0 should/ca= n be supported. If it requires additional mux layers they are requested in= the label going down stream. } When the ODU0 Path message is received at B, it is held up while a separate= ODU2 Path message is sent from B to C to D to activate the B-D ODU2 Link. = Once it is activated, using LSP Hierarchy ( RFC4206) B sends the ODU0 requ= est to D, which in turn sends it to E. [Rajan] { This is allowed. As said below, this is an alternate way. We can do without= this as shown in the examples. } When we were first developing GMPLS, we looked at packaging multiple LSP se= tup requests together and decided it was a Bad Idea(tm). So, the multistag= e signaling you are suggesting is not only unnecessary, but not in alignmen= t with the GMPLS architecture. [Rajan] { Not sure on the alignment. Think of a scenario where I have muxing rest= riction within an FA. What do you do here? Create more FAs? Works of cour= se with scaling implications. } The other alternatives are to instantiate the B-D ODU2 link or B-C and C-D= ODU2 links beforehand. [Rajan] { Agree, this is listed as FA case in the example below. } Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Friday, October 29, 2010 12:05 PM To: ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti Subject: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.709 - = draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Fatai, Interesting discussion. Please find the response below. Authors of draft-khuzema -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, October 29, 2010 1:26 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham Cc: ccamp@ietf.org; Biao Lu Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, You said there are the following differences between two drafts: - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) - TPN format We have to repeat that there is not much substantial difference between two= drafts except multi-stage muxing. We don't want to talk more on "NMC", "NVC", "TPN", because they have been d= iscussed before and it is quite easy for [draft-zhang] to do that. For exam= ple, for NMC, there is an editors note in the previous versions such as 04= version to discuss NMC stuff (and some people opposed to deprecate NMC). F= or NVC, it is obviously that [draft-zhang] can support it. Now we can focus your key driver-multi-stage muxing. 1) At page 3, in the list of added OTN features is present explicitly the "= Multi-stage ODU Multiplexing". Actually, multi-stage is not present at all = as requirement/feature in G.709. Our intention to postpone technical soluti= on regarding multi-stage multiplexing is justified by on going ITU-T SG15 p= rogress. Before thinking about specific signaling and routing solutions we = need to have stable ITU-T requirements. This why in all our common drafts (= FWK, Info-Model, Routing and Signaling drafts) we just placed some placehol= der on the subject. [AK, KP, RR] { Your understanding is not correct. Please refer to Figure-7-1A (G.709 12/2= 009). It clearly shows multi-stage muxing. G.709 doesn't mandate it has to = be single stage. The G.709 OTN frame formats fully support this capability. Vendors may choose to implement limited number of muxing levels. This shoul= d not impact the signaling solution we come up with. } 2) We are confused by your simplified multi-stage muxing label distribution= rule There is no detailed text to describe multi-stage muxing label distribution= procedures in your draft and your explaination in your below mail just foc= uses on one single node rather than how to create the end-to-end LSP. It is known that GMPLS standard procedure impose that every node has to all= ocate a label/labels consistent with the Generalized Label Request. Very im= portant: Generalized Label Request cannot be changed during signaling path. [AK, KP, RR]{ There is no disagreement here. Generalized label request doesn't change.= It is fully consistent with RFC-4328. This is precisely the reason why we = spelled out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuz= ema). Multi-stage label concept is enforced on the Generalized Label only. This a= ffects only the labels exchanged between the peers. This does not affect th= e Generalized Label Request which is relayed end-to-end. } For example, taking ODU1-ODU2-ODU3 two-stage muxing, which means that we ne= ed a service ODU1 that will be muxed into ODU2 and then ODU3. Assume the pa= th is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demu= xing. How you to create the LSP? how you to distribute the labels in Node B= , C, D? What is the traffic parameters will be transmitted in the nodes B, = C, D and nodes A, E? [AK, KP, RR]{ There are 2 ways to handle this case: with FA or without FA. Both are expla= ined with an example below We have expanded the example as follows: A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 Assume that: - ODU0 LSP is created from A to E. - ODU3 links between B-C and C-D support TS-Granularity of 2.5G only. H= ence ODU0 service can be supported on this interface only through ODU3-ODU2= -ODU0 or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example. - Generalized Label request in this case will be for ODU0 only. Case-1) Without FA: The ODU2 layer created on B-C and C-D does not run betw= een B & D. They terminate between B-C and C-D respectively. Following is = the layering and multi-stage label that needs to exchanged between the node= s. A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 |<---------------------------------------------------------------= >| | ODU0 = | |<---------------->| |<------------= ---->| | ODU1 | | ODU1 = | | |<--------------->|<---------------->| = | | | ODU2 | ODU2 | = | | |<--------------->|<---------------->| = | | | ODU3 | ODU3 | = | | | | | = | Label | | | | = | #of stages| 1 | 2 | 2 | 1 = | Stage-1 | ODU1<--ODU0 | ODU3<--ODU2 | ODU3<--ODU2 | ODU1<--= ODU0 | Stage-2 | | ODU2<--ODU0 | ODU2<--ODU0 | = | ---------------------------------------------------------------------------= --- Case-2) With FA: If ODU2 needs to run between B---D, we need to create an FA-LSP for ODU2 la= yer & this will be a TE-Link by itself. In that case, ODU0 will be routed d= irectly over ODU2 - which is single stage only (no need of multi-stage labe= l in that case). The creation of FA-LSP is outside the scope of our draft. } Thanks Ashok/Khuzema/Rajan Thanks, Authors of [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] ----- Original Message ----- From: "Rajan Rao" To: "Fatai Zhang" ; "Khuzema Pithewan" ; "Mohit Misra" ; "Ashok Kunjidhapatham" Cc: ; "Biao Lu" Sent: Thursday, October 28, 2010 2:17 PM Subject: RE: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Fatai, Please see response inline. thanks Rajan ________________________________________ From: Fatai Zhang [zhangfatai@huawei.com] Sent: Wednesday, October 27, 2010 6:08 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra Cc: ccamp@ietf.org; Zhang, Fatai Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, Happy to see your draft, but except multi-stage muxing supported in your dr= aft, I don't see any substantial difference between your draft and [draft-= zhang-ccamp-gmpls-evolving-g709-06.txt]. [Rajan]{ Multi stage muxing is one of the key drivers for signaling extensions. Any= solution is incomplete without this. The label format proposed is intended= to support G.709-v3 & future OTN extensions. Section 5.2 in draft-ietf-cc= amp-gmpls-g709-framework-03 touches on this aspect!! We see following key differences between the drafts: Our draft addresses - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) } You may say that TPN info is incorporated into label Object, but you know i= t is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and= we already stated it in the slides for IETF78th meeting ( we just make the= door open at this moment and there are some advantages to decouple TPN and= Label). [Rajan]{ The key thing here is the mux layers. The TPN in label object is intended = to address per mux layer case.... more efficient. I think this should be captured in framework doc (section 3.1.2.1in framewo= rk doc doesn't cover hierarchy aspect clearly). } In addtion, for multi-stage muxing, I really suspect that it can be resolve= d so easily, because it is MLN stuff and it needs to indicate how to create= the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can be done in = this way as your draft describes, we all will be much happy. [Rajan]{ The label structure we have defined is to address muxing levels of G.709. = This is not solving MLN using FA. i.e. it doesn't result in creation of FA = automatically. There is no FA involved or intended here (out of scope). Ple= ase refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-cc= amp-gmpls-ospf-g709/. For example, we need 3 labels to create an ODU0 LSP with following muxing= structure on a given TeLink Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-ODU0 Num-of-mux-stages =3D 3 Stage-1 - Label#1: for ODU2 layer with 8 out of 32 bits set Stage-2 - Label#2: for ODU1 layer with 2 out of 8 bits set Stage-3 - Label#3: for ODU0 layer with 1 out of 2 bits set } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: ccamp@ietf.org Cc: Khuzema Pithewan ; Mohit Misra Sent: Wednesday, October 27, 2010 5:26 AM Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls= -signaling-g709-00.txt Hi, We have a draft on "GMPLS Signaling extensions for OTN" available for revie= w. It can be accessed from the following link: http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt The above draft is not on IETF repository as we missed the submission deadl= ine. We will submit to IETF as soon as possible. Please review and comment. Abstract: As OTN network capabilities continue to evolve, there is an increased need= to support GMPLS control for the same. [RFC4328] introduced GMPLS signalin= g extensions for supporting early version of G.709 [G.709-v1].The basic rou= ting considerations from signaling perspective is also specified in [RFC432= 8]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] h= ave introduced new ODU containers (both fixed and flexible) and additional = ODU multiplexing capabilities, enabling support for optimal service aggrega= tion. This document extends [RFC4328] to provide GMPLS signaling support for the = new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling ext= ensions described in this document caters to ODU layer switching only. Opti= cal Channel Layer switching considerations in [RFC4328] are not modified in= this document. Thanks Authors ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_5E893DB832F57341992548CDBB33316398B51FCA3CEMBX01HQjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Comments inline.

 =

Sent from my iPhone=

 =

From: Rajan Rao [mailto:rrao@infinera.com]
Sent: Friday, October 29, 2010 6:00 PM
To: John E Drake; ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu; R= ajan Rao
Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extension= s for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

John, et al

 =

With the muxing structur= e of G.709,   customers may chose to use the mux stages their own ways= . Having FA-LSPs or virtual links on pt-2-pt segments doesnR= 17;t make much sense and will lead to scaling issues & managing complexities= .

 =

JD:=A0 You are making an= assertion. =A0=A0Since in this example we are talking about a node that can activate a= n ODU2 dynamically, it could advertise the ODU0, as you suggested.=A0 Why you woul= d want to do this rather than having multi-hop FAs between select points in the network is beyond me, except as a debating point.

 =

JD:=A0 However, the more= important point is that *existing* GMPLS signaling *exactly* supports t= he configuration in your example.

 =

The signaling extensions= can easily take care of OTN muxing hierarchy as shown in our draft.  We sh= ould address MLN RFC-6001 alignment  by adding OTN-MLN details in the  framework doc.

 =

JD:=A0 See above.=A0 Btw= , in your proposal where are the parameters associated with establishing the ODU2 carried?

 =

Thanks=

Rajan<= /p>

 =

From: Rajan Rao Sent: Friday, October 29, 2010 2:50 PM
To: John E Drake; ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti; Biao Lu Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extension= s for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

John, et al

 

Please see response inline= .

 

Thanks

Rajan

 =

From: John E Drake [mailto:jdrake@juniper.net]
Sent: Friday, October 29, 2010 1:41 PM
To: Rajan Rao; ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Subject: RE: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extension= s for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi,

 =

Per RFC6001, the B-D ODU= 2 link would be advertised as a virtual TE Link.  This is necessary because otherwise the CSPF at A will not consider routing the ODU0 LSP via B, C, an= d D.

 =

[Rajan] {

This is not the case. &nbs= p;Even without virtual TE link or FA-LSP  the ODU0 LSPs can be setup between = A-E. This is  because we advertise #ODU0s for OTU3 links B-C & C-D.&nbs= p; Note that #ODU0 containers advertised is non-zero even though TSG=3D2.5G. T= his is the key point here.

We are no longer bound by MinLSP-BW as ODU0 BW is advertized as a separate sub-TLV within SCSI. =

 

The instantiation of ODU2 = to support ODU0 is done as part of signaling which brings in the label format = for mux levels.  The instantiation of mux layers is a local matter.  = This can be different on each segment. The labels tell exactly what to instantia= te on the local interface. 

 

In this example, each NE d= ecides locally (segment basis) how ODU0 should/can be supported.  If it requi= res additional mux layers they are requested in the label going down stream.

}

 =

When the ODU0 Path messa= ge is received at B, it is held up while a separate ODU2 Path message is sent fro= m B to C to D to activate the B-D ODU2 Link.  Once it is activated, using = LSP Hierarchy ( RFC4206) B sends the ODU0 request to D, which in turn sends it = to E.

[Rajan] {

This is allowed. As said b= elow, this is an alternate way. We can do without this as shown in the examples.<= o:p>

}

 

When we were first devel= oping GMPLS, we looked at packaging multiple LSP setup requests together and deci= ded it was a Bad Idea™.  So, the multistage signaling you are sugges= ting is not only unnecessary, but not in alignment with the GMPLS architecture.<= o:p>

[Rajan] {

 Not sure on the alignment.    Think of a scenario where I have muxing restriction within an FA. What do you do here?  Create more FAs?  Works of course with scaling implications.  

}

The other alternatives a= re to instantiate the B-D ODU2 link or  B-C and C-D ODU2 links beforehand. <= o:p>

[Rajan] {

 Agree,  this is= listed as FA case in the example below.

}

 =

Thanks,

 =

John

 =

Sent from my iPhone=

 =

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Rajan Rao
Sent: Friday, October 29, 2010 12:05 PM
To: ccamp@ietf.org; Fatai Zhang
Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti
Subject: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions fo= r G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Fatai,

 

Interesting discussio= n. Please find the response below.

 

Authors of draft-khuz= ema

 

-----Original Message-----
From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: ccamp@ietf.org; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

You said there are the following differences betwee= n two drafts:

-  G.709 multi-stage multiplexing (v3 & be= yond)

-  NMC treatment (ref to section-4 in the draf= t)

-  Support for VCAT (NVC >1 )

- TPN format

 

We have to repeat that there is not much substantia= l difference between two drafts except multi-stage muxing.

 

We don't want to talk more on "NMC", "NVC", "TPN", because they have been discussed before a= nd it is quite easy for [draft-zhang] to do that. For example, for NMC, there = is an editors note in the previous versions  such as 04 version to discus= s NMC stuff (and some people opposed to deprecate NMC). For NVC, it is obviou= sly that [draft-zhang] can support it.

 

Now we can focus your key driver-multi-stage muxing= .

 

1) At page 3, in the list of added OTN features is present explicitly the "Multi-stage ODU Multiplexing". Actually, = multi-stage is not present at all as requirement/featur= e in G.709. Our intention to postpone technical solution regarding multi-stage multiplexing is justified by on going ITU-T SG15 progress. Befo= re thinking about specific signaling and routing solutions we need to have sta= ble ITU-T requirements. This why in all our common drafts (FWK, Info-Model, Rou= ting and Signaling drafts) we just placed some placeholder on the subject.<= /o:p>

 

[AK, KP, RR] { <= /o:p>

 Your understand= ing is not correct. Please refer to Figure-7-1A (G.709 12/2009). It clearly shows multi-stage muxing. G.709 doesn’t mandate it has to be single stage. = The G.709 OTN frame formats fully support this capability.

 

Vendors may choose to implement limited number of muxing levels. This should not impact the signa= ling solution we come up with.

}

 

 

2) We are confused by your simplified multi-stage m= uxing label distribution rule

 

There is no detailed text to describe multi-stage m= uxing label distribution procedures in your draft and your explaination in your b= elow mail just focuses on one single node rather than how to create the end-to-e= nd LSP.

 

It is known that GMPLS standard procedure impose th= at every node has to allocate a label/labels consistent with the Generalized L= abel Request. Very important: Generalized Label Request cannot be changed during signaling path.

[AK, KP, RR]{

  There is no di= sagreement here.  Generalized label request doesn’t change. It is fully consistent with RFC-4328. This is precisely the reason why we spelled out N= MC treatment with ODU2e case (ref to section 4.0 in draft-khuzema).=

 

Multi-stage label con= cept is enforced on the Generalized Label only. This affects only the labels exchanged between the peers. This does not affect the Generalized Label Req= uest  which is relayed end-to-end.

}

 

For example, taking ODU1-ODU2-ODU3 two-stage muxing= , which means that we need a service ODU1 that will be muxed into ODU2 and th= en ODU3. Assume the path is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demuxing. How you to create the LSP? how you to distribute= the labels in Node B, C, D? What is the traffic parameters will be transmitted = in the nodes B, C, D and nodes A, E?

 

[AK, KP, RR]{

 

Ther= e are 2 ways to handle this case: with FA or without FA. Both are explained with an example below      

 

 We have expande= d the example as follows:

 

   &nb= sp;      A---------------B---------------C---------------D----------------E

   &nb= sp;            OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

 Assume that:

   - ODU0 L= SP is created from A to E.

   - ODU3 l= inks between B-C and C-D support TS-Granularity of 2.5G only.  Hence ODU0 service can be supported on this interface only through ODU3-ODU2-ODU0 = ; or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example.

-    Generalized La= bel request in this case will be for ODU0 only.

 

Case-1) Without FA: T= he ODU2 layer created on B-C and C-D does not run between B & D.  They terminate between B-C and C-D respectively.  Following is the layering= and multi-stage label that needs to exchanged between the nodes.

 

 

          A---------------B---------------C---------------D----------------E

          =       OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

          |<-------------------------------------------------------------=E0| &= nbsp;       

          |                  &nb= sp;        ODU0   &n= bsp;            = ;            &n= bsp;    |

          |=DF--------= ----=E0| &= nbsp;           &nbs= p;            &= nbsp;    |=DF--------= ----=E0| &= nbsp;         

          |       ODU1     |         &n= bsp;            = ;         |      ODU1     |

          |            &n= bsp;   |=DF--------= ---=E0|= =DF--------= ----=E0| &= nbsp;           &nbs= p; |

          |            &n= bsp;   |      ODU2    |      ODU2      |               |

          |                |=DF-----------=E0|=DF------------=E0|     &nb= sp;         |

          |            &n= bsp;   |      ODU3    |      ODU3      |            &n= bsp;  |

          |        &n= bsp;       |            &n= bsp; |                |      &n= bsp;        |

Label     |            &n= bsp;   |            &n= bsp; |            &n= bsp;   |            &n= bsp;  |

#of stages|        1       |         2    |&nbs= p;        2      |         1     = ;|

Stage-1   |   ODU1=DFODU0&nbs= p;  |   ODU3=DFODU2  |   ODU3=DFODU2   |  &nbs= p; ODU1=DFODU0 &nb= sp;|

Stage-2   |            &n= bsp;   |   ODU2=DFODU0  |   ODU2=DFODU0   |            &n= bsp;  |

------------------------------------------------------------= ------------------

 

Case= -2) With FA:

If ODU2 needs to run = between B---D, we need to create an FA-LSP for ODU2 layer & this will be a TE-L= ink by itself. In that case, ODU0 will be routed directly over ODU2 – whi= ch is single stage only (no need of multi-stage label in that case).

 

The = creation of FA-LSP is outside the scope of our draft.

}

Thanks

Asho= k/Khuzema/Rajan

 

Thanks,

 

Authors of [draft-zhang-ccamp-gmpls-evolving-g709-0= 6.txt]

 

 

 

 

----- Original Message -----

From: "Rajan Rao" <rrao@infinera.com&g= t;

To: "Fatai Zhang" <zhangfatai@huawei.com>; "Khuzema Pithewan" <kpithewan@infinera.com>; "Mohit Misra" <mmisra@infinera.com>; "Ashok Kunjidhapatham" <akunjidhapatham@infinera.com>

Cc: <ccamp@ietf.org>; "Biao Lu" <blu@infinera.com>

Sent: Thursday, October 28, 2010 2:17 PM=

Subject: RE: [CCAMP] Signaling extensions for G.709= - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

 

Fatai,

 

Please see response inline.

 

thanks

Rajan

________________________________________=

From: Fatai Zhang [zhangfatai@huawei.com]

Sent: Wednesday, October 27, 2010 6:08 PM

To: Rajan Rao; Khuzema Pithewan; Mohit Misra

Cc: ccamp@ietf.org; Zhang, Fatai

Subject: Re: [CCAMP] Signaling extensions for G.709= - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

Happy to see your draft, but except multi-stage mux= ing supported in your draft,  I don't see any substantial difference betwe= en your draft and [draft-zhang-ccamp-gmpls-evolving-g709-06.txt].

 

[Rajan]{

Multi stage muxing is one of the key drivers for&nb= sp; signaling extensions. Any solution is incomplete without this. The label fo= rmat proposed is intended to support G.709-v3 & future OTN extensions. Secti= on 5.2 in  draft-ietf-ccamp-gmpls-g709-framework-03  touches on this aspect!!

 

We see following key differences between the drafts= :

 Our draft addresses

-        &n= bsp; G.709 multi-stage multiplexing (v3 & beyond)

-        &n= bsp; NMC treatment (ref to section-4 in the draft)

-        &n= bsp; Support for VCAT (NVC >1 )

}

 

You may say that TPN info is incorporated into labe= l Object, but you know it is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and we already st= ated it in the slides for IETF78th meeting ( we just make the door open at this moment and there are some advantages to decouple TPN and Label).=

 

[Rajan]{

The key thing here is the mux layers.  The TPN= in label object is intended to address per mux layer case…. more efficie= nt.

I think this should be captured in framework doc (s= ection 3.1.2.1in framework doc doesn't cover hierarchy aspect clearly).

}

 

In addtion, for multi-stage muxing, I really suspec= t that it can be resolved so easily, because it is MLN stuff and it needs to indic= ate how to create the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can be done in this way as your draft describes, we all will be much happy.

 

[Rajan]{

The label structure we have defined is to address m= uxing levels of G.709.  This is not solving MLN using FA. i.e. it doesn̵= 7;t result in creation of FA automatically. There is no FA involved or intended here (out of scope). Please refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/.<= o:p>

 

 For example,  we need 3 labels to create= an ODU0 LSP with following muxing structure on a given TeLink

 

Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-O= DU0

 

Num-of-mux-stages =3D 3

Stage-1 - Label#1: for ODU2 layer with 8 out of 32 = bits set

Stage-2 - Label#2: for ODU1 layer with 2 out of 8 b= its set

Stage-3 - Label#3: for ODU0 layer with 1 out of 2 b= its set

 

}

 

 

Best Regards

 

Fatai

 

----- Original Message -----

From: Rajan Rao<mailto:rrao@infinera.com>

To: ccamp@ietf.org<mailto:ccamp@ietf.org>

Cc: Khuzema Pithewan<mailto:kpithewan@infinera.c= om> ; Mohit Misra<mailto:mmisra@infinera.com>

Sent: Wednesday, October 27, 2010 5:26 AM

Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi,

 

We have a draft on “GMPLS Signaling extension= s for OTN” available for review.  It can be accessed from the followin= g link:

http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g= 709-00.txt

The above draft is not on IETF repository as we mis= sed the submission deadline.  We will submit to IETF as soon as possible.<= o:p>

 

Please review and comment.

Abstract:

As OTN network capabilities continue to evolve, the= re is an increased  need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is a= lso specified in [RFC4328].

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support fo= r optimal service aggregation.

This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in this document caters to OD= U layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document.

 

Thanks

Authors

 

________________________________

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

--_000_5E893DB832F57341992548CDBB33316398B51FCA3CEMBX01HQjnprn_-- From sergio.belotti@alcatel-lucent.com Sun Oct 31 03:19:36 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719DD3A67E5 for ; Sun, 31 Oct 2010 03:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzyqVW-yPwvs for ; Sun, 31 Oct 2010 03:19:21 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 3A7F13A63EB for ; Sun, 31 Oct 2010 03:19:19 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9VAL2Yv024032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 31 Oct 2010 11:21:02 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sun, 31 Oct 2010 11:21:02 +0100 From: "BELOTTI, SERGIO (SERGIO)" To: Rajan Rao Date: Sun, 31 Oct 2010 11:20:59 +0100 Thread-Topic: [CCAMP] FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Thread-Index: Act3PquV+PNZ8lg7Q6aOspVigb2/3AAKHrqAAAnob2AAVJo2gA== Message-ID: References: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302@SV-EXDB1.infinera.com> In-Reply-To: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3E05302@SV-EXDB1.infinera.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F050945A8D8E9A44A71039532BA344D80FDFD430FRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: Khuzema Pithewan , "ccamp@ietf.org" , Radhakrishna Valiveti , Mohit Misra Subject: [CCAMP] R: FW: RESPONSE TO => FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Oct 2010 10:19:36 -0000 --_000_F050945A8D8E9A44A71039532BA344D80FDFD430FRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1) At page 3, in the list of added OTN features is present explicitly the "= Multi-stage ODU Multiplexing". Actually, multi-stage is not present at all = as requirement/feature in G.709. Our intention to postpone technical soluti= on regarding multi-stage multiplexing is justified by on going ITU-T SG15 p= rogress. Before thinking about specific signaling and routing solutions we = need to have stable ITU-T requirements. This why in all our common drafts (= FWK, Info-Model, Routing and Signaling drafts) we just placed some placehol= der on the subject. [AK, KP, RR] { Your understanding is not correct. Please refer to Figure-7-1A (G.709 12/2= 009). It clearly shows multi-stage muxing. G.709 doesn't mandate it has to = be single stage. The G.709 OTN frame formats fully support this capability. Vendors may choose to implement limited number of muxing levels. This shoul= d not impact the signaling solution we come up with. } Rao, I'd like to understand where in Figure-7.1A (G.709 12/2009) you desume mult= i-stage multiplexing as requirement? This is an interesting point since I w= as present in the ITU meeting in which this figure was discussed and know p= erfectly story and meaning of it. Are you talking about single domain or multi-domain? This is the first clar= ification needed to have a clear picture of what we are discussing. About sinle domain , on the opposite of your statement, is explicitly said that any information= and picture about possible interconnection of different multiplexing is ou= tside the scope of the G.709. In the 7-1A you can deduce information about the possible new multiplexing = capability , needed to introduce due to the new container not the chain of = possible multiplexing stage. Full stop. What we context in your sentence it is not the "possibility) to make in a = multi-domain network heterogeneous interconnection of stage of multiplexing= but that this is a requirement as you mention for the new container like O= DU0 or ODUflex that instead are clear differentiation respect older G.709 v= ersion. If you are referring to multi-domain , so your statement about requirement = , want to say we need to touch multi-domain multi-area signalling and routi= ng scope ?? Best Regards Sergio Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 ________________________________ Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Raj= an Rao Inviato: venerd=EC 29 ottobre 2010 21.05 A: ccamp@ietf.org; Fatai Zhang Cc: Khuzema Pithewan; Mohit Misra; Radhakrishna Valiveti Oggetto: [CCAMP] FW: RESPONSE TO =3D> FW: Signaling extensions for G.709 - = draft-khuzema-ccamp-gmpls-signaling-g709-00.txt Fatai, Interesting discussion. Please find the response below. Authors of draft-khuzema -----Original Message----- From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, October 29, 2010 1:26 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham Cc: ccamp@ietf.org; Biao Lu Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, You said there are the following differences between two drafts: - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) - TPN format We have to repeat that there is not much substantial difference between two= drafts except multi-stage muxing. We don't want to talk more on "NMC", "NVC", "TPN", because they have been d= iscussed before and it is quite easy for [draft-zhang] to do that. For exam= ple, for NMC, there is an editors note in the previous versions such as 04= version to discuss NMC stuff (and some people opposed to deprecate NMC). F= or NVC, it is obviously that [draft-zhang] can support it. Now we can focus your key driver-multi-stage muxing. 1) At page 3, in the list of added OTN features is present explicitly the "= Multi-stage ODU Multiplexing". Actually, multi-stage is not present at all = as requirement/feature in G.709. Our intention to postpone technical soluti= on regarding multi-stage multiplexing is justified by on going ITU-T SG15 p= rogress. Before thinking about specific signaling and routing solutions we = need to have stable ITU-T requirements. This why in all our common drafts (= FWK, Info-Model, Routing and Signaling drafts) we just placed some placehol= der on the subject. [AK, KP, RR] { Your understanding is not correct. Please refer to Figure-7-1A (G.709 12/2= 009). It clearly shows multi-stage muxing. G.709 doesn't mandate it has to = be single stage. The G.709 OTN frame formats fully support this capability. Vendors may choose to implement limited number of muxing levels. This shoul= d not impact the signaling solution we come up with. } 2) We are confused by your simplified multi-stage muxing label distribution= rule There is no detailed text to describe multi-stage muxing label distribution= procedures in your draft and your explaination in your below mail just foc= uses on one single node rather than how to create the end-to-end LSP. It is known that GMPLS standard procedure impose that every node has to all= ocate a label/labels consistent with the Generalized Label Request. Very im= portant: Generalized Label Request cannot be changed during signaling path. [AK, KP, RR]{ There is no disagreement here. Generalized label request doesn't change.= It is fully consistent with RFC-4328. This is precisely the reason why we = spelled out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuz= ema). Multi-stage label concept is enforced on the Generalized Label only. This a= ffects only the labels exchanged between the peers. This does not affect th= e Generalized Label Request which is relayed end-to-end. } For example, taking ODU1-ODU2-ODU3 two-stage muxing, which means that we ne= ed a service ODU1 that will be muxed into ODU2 and then ODU3. Assume the pa= th is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demu= xing. How you to create the LSP? how you to distribute the labels in Node B= , C, D? What is the traffic parameters will be transmitted in the nodes B, = C, D and nodes A, E? [AK, KP, RR]{ There are 2 ways to handle this case: with FA or without FA. Both are expla= ined with an example below We have expanded the example as follows: A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 Assume that: - ODU0 LSP is created from A to E. - ODU3 links between B-C and C-D support TS-Granularity of 2.5G only. H= ence ODU0 service can be supported on this interface only through ODU3-ODU2= -ODU0 or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example. - Generalized Label request in this case will be for ODU0 only. Case-1) Without FA: The ODU2 layer created on B-C and C-D does not run betw= een B & D. They terminate between B-C and C-D respectively. Following is = the layering and multi-stage label that needs to exchanged between the node= s. A---------------B---------------C---------------D----------------= E OTU1 OTU3 OTU3 OTU1 |<---------------------------------------------------------------= >| | ODU0 = | |<---------------->| |<------------= ---->| | ODU1 | | ODU1 = | | |<--------------->|<---------------->| = | | | ODU2 | ODU2 | = | | |<--------------->|<---------------->| = | | | ODU3 | ODU3 | = | | | | | = | Label | | | | = | #of stages| 1 | 2 | 2 | 1 = | Stage-1 | ODU1<--ODU0 | ODU3<--ODU2 | ODU3<--ODU2 | ODU1<--= ODU0 | Stage-2 | | ODU2<--ODU0 | ODU2<--ODU0 | = | ---------------------------------------------------------------------------= --- Case-2) With FA: If ODU2 needs to run between B---D, we need to create an FA-LSP for ODU2 la= yer & this will be a TE-Link by itself. In that case, ODU0 will be routed d= irectly over ODU2 - which is single stage only (no need of multi-stage labe= l in that case). The creation of FA-LSP is outside the scope of our draft. } Thanks Ashok/Khuzema/Rajan Thanks, Authors of [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] ----- Original Message ----- From: "Rajan Rao" To: "Fatai Zhang" ; "Khuzema Pithewan" ; "Mohit Misra" ; "Ashok Kunjidhapatham" Cc: ; "Biao Lu" Sent: Thursday, October 28, 2010 2:17 PM Subject: RE: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Fatai, Please see response inline. thanks Rajan ________________________________________ From: Fatai Zhang [zhangfatai@huawei.com] Sent: Wednesday, October 27, 2010 6:08 PM To: Rajan Rao; Khuzema Pithewan; Mohit Misra Cc: ccamp@ietf.org; Zhang, Fatai Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-g= mpls-signaling-g709-00.txt Hi Rajan, Happy to see your draft, but except multi-stage muxing supported in your dr= aft, I don't see any substantial difference between your draft and [draft-= zhang-ccamp-gmpls-evolving-g709-06.txt]. [Rajan]{ Multi stage muxing is one of the key drivers for signaling extensions. Any= solution is incomplete without this. The label format proposed is intended= to support G.709-v3 & future OTN extensions. Section 5.2 in draft-ietf-cc= amp-gmpls-g709-framework-03 touches on this aspect!! We see following key differences between the drafts: Our draft addresses - G.709 multi-stage multiplexing (v3 & beyond) - NMC treatment (ref to section-4 in the draft) - Support for VCAT (NVC >1 ) } You may say that TPN info is incorporated into label Object, but you know i= t is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and= we already stated it in the slides for IETF78th meeting ( we just make the= door open at this moment and there are some advantages to decouple TPN and= Label). [Rajan]{ The key thing here is the mux layers. The TPN in label object is intended = to address per mux layer case.... more efficient. I think this should be captured in framework doc (section 3.1.2.1in framewo= rk doc doesn't cover hierarchy aspect clearly). } In addtion, for multi-stage muxing, I really suspect that it can be resolve= d so easily, because it is MLN stuff and it needs to indicate how to create= the infrastructure FA-LSP (See RFC4206 and 4206bis). If it can be done in = this way as your draft describes, we all will be much happy. [Rajan]{ The label structure we have defined is to address muxing levels of G.709. = This is not solving MLN using FA. i.e. it doesn't result in creation of FA = automatically. There is no FA involved or intended here (out of scope). Ple= ase refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-cc= amp-gmpls-ospf-g709/. For example, we need 3 labels to create an ODU0 LSP with following muxing= structure on a given TeLink Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU1-ODU0 Num-of-mux-stages =3D 3 Stage-1 - Label#1: for ODU2 layer with 8 out of 32 bits set Stage-2 - Label#2: for ODU1 layer with 2 out of 8 bits set Stage-3 - Label#3: for ODU0 layer with 1 out of 2 bits set } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: ccamp@ietf.org Cc: Khuzema Pithewan ; Mohit Misra Sent: Wednesday, October 27, 2010 5:26 AM Subject: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls= -signaling-g709-00.txt Hi, We have a draft on "GMPLS Signaling extensions for OTN" available for revie= w. It can be accessed from the following link: http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g709-00.txt The above draft is not on IETF repository as we missed the submission deadl= ine. We will submit to IETF as soon as possible. Please review and comment. Abstract: As OTN network capabilities continue to evolve, there is an increased need= to support GMPLS control for the same. [RFC4328] introduced GMPLS signalin= g extensions for supporting early version of G.709 [G.709-v1].The basic rou= ting considerations from signaling perspective is also specified in [RFC432= 8]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and[GSUP.43] h= ave introduced new ODU containers (both fixed and flexible) and additional = ODU multiplexing capabilities, enabling support for optimal service aggrega= tion. This document extends [RFC4328] to provide GMPLS signaling support for the = new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling ext= ensions described in this document caters to ODU layer switching only. Opti= cal Channel Layer switching considerations in [RFC4328] are not modified in= this document. Thanks Authors ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_F050945A8D8E9A44A71039532BA344D80FDFD430FRMRSSXCHMBSB1d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

1) At page 3, in the list o= f added OTN features is present explicitly the "Multi-stage ODU Multiplexing". Actually, m= ulti-stage is not present at all as requirement/feature in G.709. Our intention to postpone technical solution regarding multi-stage multiplexing= is justified by on going ITU-T SG15 progress. Before thinking about specific signaling and routing solutions we need to have stable ITU-T requirements. = This why in all our common drafts (FWK, Info-Model, Routing and Signaling drafts= ) we just placed some placeholder on the subject.

 

[AK, KP, RR] = {

 Your understanding is not correct. Please refer to Figure-7-1A (G.709 12/2009). = It clearly shows multi-stage muxing. G.709 doesn’t mandate it has to be single stage. The G.709 OTN frame formats fully support this capability.

 

Vendors may c= hoose to implement limited number of muxing levels. This should not impact the signaling solution we come up with.

}<= /span>

 

Rao,

 

I’d like to understand where in Figure-7.1A (G.709 12/2009) you desume multi-stage multiplexing as requirement? This is an interesting point since I was prese= nt in the ITU meeting in which this figure was discussed and know perfectly st= ory and meaning of it.

Are you talking abo= ut single domain or multi-domain? This is the first clarification needed to ha= ve a clear picture of what we are discussing.

About sinle domain = ,

on the opposite of = your statement, =A0is explicitly said that any information and picture about pos= sible interconnection of different multiplexing is outside the scope of the G.709= .

In the 7-1A you can deduce information about the possible new multiplexing capability , needed = to introduce due to the new container not the chain of possible multiplexing stage. Full stop.

 

What we context in = your sentence it is not the “possibility) to make in a=A0 multi-domain net= work heterogeneous interconnection of stage of multiplexing but that this is a requirement as you mention for the new container like ODU0 or ODUflex that = instead are clear differentiation respect older G.709 version.

 

If you are referrin= g to multi-domain , so your statement about requirement , want to say we need to touch multi-domain multi-area signalling and routing scope ?? =A0

 

 

Best Regards

 

Sergio

 

Sergio Belotti

System Architecture=
Optics Division-Terrestrial Optics Unit=
ALCATEL-LUCENT

+39 039 6863033
+39 039 6863590

Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Rajan Rao
Inviato: venerd=EC 29 ottobr= e 2010 21.05
A: ccamp@ietf.org; Fatai Zha= ng
Cc: Khuzema Pithewan; Mohit = Misra; Radhakrishna Valiveti
Oggetto: [CCAMP] FW: RESPONS= E TO =3D> FW: Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Fatai,

 

Interesting discussio= n. Please find the response below.

 

Authors of draft-khuz= ema

 

-----Original Message-----
From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Friday, October 29, 2010 1:26 PM
To: Rajan Rao; Khuzema Pithewan; Mohit Misra; Ashok Kunjidhapatham
Cc: ccamp@ietf.org; Biao Lu
Subject: Re: [CCAMP] Signaling extensions for G.709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

You said there are the following differences bet= ween two drafts:

-  G.709 multi-stage multiplexing (v3 & beyond)

-  NMC treatment (ref to section-4 in the d= raft)

-  Support for VCAT (NVC >1 )=

- TPN format

 

We have to repeat that there is not much substan= tial difference between two drafts except multi-stage muxing.

 

We don't want to talk more on "NMC", "NVC", "TPN", because they have been discussed before a= nd it is quite easy for [draft-zhang] to do that. For example, for NMC, there = is an editors note in the previous versions  such as 04 version to discus= s NMC stuff (and some people opposed to deprecate NMC). For NVC, it is obviou= sly that [draft-zhang] can support it.

 

Now we can focus your key driver-multi-stage mux= ing.

 

1) At page 3, in the list of added OTN features = is present explicitly the "Multi-stage ODU Multiplexing". Actually, = multi-stage is not present at all as requirement/feature in G.709. Our intention to postpone techn= ical solution regarding multi-stage multiplexing is justified by on going ITU-T = SG15 progress. Before thinking about specific signaling and routing solutions we need to have stable ITU-T requirements. This why in all our common drafts (= FWK, Info-Model, Routing and Signaling drafts) we just placed some placeholder o= n the subject.

 

[AK, KP, RR] { <= /o:p>

 Your understand= ing is not correct. Please refer to Figure-7-1A (G.709 12/2009). It clearly shows multi-stage muxing. G.709 doesn’t mandate it has to be single stage. = The G.709 OTN frame formats fully support this capability.

 

Vendors may choose to implement limited number of muxing levels. This should not impact the signa= ling solution we come up with.

}

 

 

2) We are confused by your simplified multi-stag= e muxing label distribution rule

 

There is no detailed text to describe multi-stag= e muxing label distribution procedures in your draft and your explaination in your below mail just focuses on one single node rather than how to create t= he end-to-end LSP.

 

It is known that GMPLS standard procedure impose= that every node has to allocate a label/labels consistent with the Generalized L= abel Request. Very important: Generalized Label Request cannot be changed during signaling path.

[AK, KP, RR]{

  There is no disagreement here.  Generalized label request doesn’t change. It= is fully consistent with RFC-4328. This is precisely the reason why we spelled= out NMC treatment with ODU2e case (ref to section 4.0 in draft-khuzema).

 

Multi-stage label con= cept is enforced on the Generalized Label only. This affects only the labels exchanged between the peers. This does not affect the Generalized Label Req= uest  which is relayed end-to-end.

}

 

For example, taking ODU1-ODU2-ODU3 two-stage mux= ing, which means that we need a service ODU1 that will be muxed into ODU2 and th= en ODU3. Assume the path is A-B-C-D-E, in node B and node D will finish the two-stage muxing/demuxing. How you to create the LSP? how you to distribute= the labels in Node B, C, D? What is the traffic parameters will be transmitted = in the nodes B, C, D and nodes A, E?

 

[AK, KP, RR]{

<= o:p> 

There are 2 ways to h= andle this case: with FA or without FA. Both are explained with an example below      

 

 We have expande= d the example as follows:

 

   &nb= sp;      A---------------B---------------C---------------D----------------E

   &nb= sp;            OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

 Assume that:

   - ODU0 L= SP is created from A to E.

   - ODU3 l= inks between B-C and C-D support TS-Granularity of 2.5G only.  Hence ODU0 service can be supported on this interface only through ODU3-ODU2-ODU0 = ; or ODU3-ODU1-ODU0. Say we pick ODU3-ODU2-ODU0 for this example.

-      =   Generalized Label request in this case= will be for ODU0 only.

 

Case-1) Without FA: T= he ODU2 layer created on B-C and C-D does not run between B & D.  They terminate between B-C and C-D respectively.  Following is the layering= and multi-stage label that needs to exchanged between the nodes.

 

 

          A---------------B---------------C---------------D----------------E

           &nbs= p;    OTU1         = ;    OTU3            OTU3          OTU1<= /span>

 

          |<-------------------------------------------------------------=E0|         

          |                  &nb= sp;        ODU0   &n= bsp;            = ;            &n= bsp;    |

          |=DF------------<= font size=3D2 color=3D"#002060" face=3DWingdings>=E0|          = ;            &n= bsp;        |=DF------------<= font size=3D2 color=3D"#002060" face=3DWingdings>=E0|          &nbs= p;

          |       ODU1     |&= nbsp;           &nbs= p;            &= nbsp;     |      ODU1     |

          |            &n= bsp;   |=DF-----------=E0|=DF------------<= font size=3D2 color=3D"#002060" face=3DWingdings>=E0|          = ;     |

          |            &n= bsp;   |      ODU2    |      ODU2      |               |

          |                |=DF-----------=E0|=DF------------<= font size=3D2 color=3D"#002060" face=3DWingdings>=E0|          = ;     |

          |            &n= bsp;   |      ODU3    |      ODU3      |            &n= bsp;  |

          |        &n= bsp;       |            &n= bsp; |                |      &n= bsp;        |

Label     |            &n= bsp;   |            &n= bsp; |            &n= bsp;   |            &n= bsp;  |

#of stages|        1       |         2    |&nbs= p;        2      |         1     = ;|

Stage-1   |   ODU1=DFODU0   | &nb= sp; ODU3=DFODU2  |   OD= U3=DFODU2   |    ODU1=DFODU0  |

Stage-2   |            &n= bsp;   |   ODU2=DFODU0  |   OD= U2=DFODU0   |            &n= bsp;  |

----------------------------------------------------------------------= --------

 

Case-2) With FA:

If ODU2 needs to run = between B---D, we need to create an FA-LSP for ODU2 layer & this will be a TE-L= ink by itself. In that case, ODU0 will be routed directly over ODU2 – whi= ch is single stage only (no need of multi-stage label in that case).

 

The creation of FA-LS= P is outside the scope of our draft.

}

Thanks

Ashok/Khuzema/Rajan

 

Thanks,

 

Authors of [draft-zhang-ccamp-gmpls-evolving-g709-06.txt]

 

 

 

 

----- Original Message ----- <= /font>

From: "Rajan Rao" <rrao@infinera.co= m>

To: "Fatai Zhang" <zhangfatai@huawei.com>; "Khuzema Pithewan" <kpithewan@infinera.com>; "Mohit Misra" <mmisra@infinera.com>; "Ashok Kunjidhapatham" <akunjidhapatham@infinera.com>

Cc: <ccamp@ietf.org>; "Biao Lu" <blu@infinera.com>

Sent: Thursday, October 28, 2010 2:17 PM

Subject: RE: [CCAMP] Signaling extensions for G.= 709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

 

Fatai,

 

Please see response inline.

 

thanks

Rajan

________________________________________

From: Fatai Zhang [zhangfatai@huawei.com]

Sent: Wednesday, October 27, 2010 6:08 PM

To: Rajan Rao; Khuzema Pithewan; Mohit Misra

Cc: ccamp@ietf.org; Zhang, Fatai

Subject: Re: [CCAMP] Signaling extensions for G.= 709 - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi Rajan,

 

Happy to see your draft, but except multi-stage = muxing supported in your draft,  I don't see any substantial difference betwe= en your draft and [draft-zhang-ccamp-gmpls-evolving-g709-06.txt].

 

[Rajan]{

Multi stage muxing is one of the key drivers for=   signaling extensions. Any solution is incomplete without this. The label fo= rmat proposed is intended to support G.709-v3 & future OTN extensions. Secti= on 5.2 in  draft-ietf-ccamp-gmpls-g709-framework-03  touches on this= aspect!!

 

We see following key differences between the dra= fts:

 Our draft addresses

-        = ;  G.709 multi-stage multiplexing (v3 & beyond)

-        = ;  NMC treatment (ref to section-4 in the draft)

-        = ;  Support for VCAT (NVC >1 )

}

 

You may say that TPN info is incorporated into l= abel Object, but you know it is easy for [draft-zhang-ccamp-gmpls-evolving-g709-06.txt] to do that and we already st= ated it in the slides for IETF78th meeting ( we just make the door open at this moment and there are some advantages to decouple TPN and Label).=

 

[Rajan]{

The key thing here is the mux layers.  The = TPN in label object is intended to address per mux layer case…. more efficie= nt.

I think this should be captured in framework doc (section 3.1.2.1in framework doc doesn't cover hierarchy aspect clearly). <= o:p>

}

 

In addtion, for multi-stage muxing, I really sus= pect that it can be resolved so easily, because it is MLN stuff and it needs to indicate how to create the infrastructure FA-LSP (See RFC4206 and 4206bis).= If it can be done in this way as your draft describes, we all will be much hap= py.

 

[Rajan]{

The label structure we have defined is to addres= s muxing levels of G.709.  This is not solving MLN using FA. i.e. it doesn’t result in creation of FA automatically. There is no FA involv= ed or intended here (out of scope). Please refer to section-3.0 in https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/.<= o:p>

 

 For example,  we need 3 labels to cre= ate an ODU0 LSP with following muxing structure on a given TeLink

 

Muxing hierarchy on a TeLink: OTU3-ODU3-ODU2-ODU= 1-ODU0

 

Num-of-mux-stages =3D 3=

Stage-1 - Label#1: for ODU2 layer with 8 out of = 32 bits set

Stage-2 - Label#2: for ODU1 layer with 2 out of = 8 bits set

Stage-3 - Label#3: for ODU0 layer with 1 out of = 2 bits set

 

}

 

 

Best Regards

 

Fatai

 

----- Original Message -----

From: Rajan Rao<mailto:rrao@infinera.com><= o:p>

To: ccamp@ietf.org<mailto:ccamp@ietf.org><= o:p>

Cc: Khuzema Pithewan<mailto:kpithewan@infinera.com> ; Mohit Misra<mailto:mmisra@infinera.com>

Sent: Wednesday, October 27, 2010 5:26 AM

Subject: [CCAMP] Signaling extensions for G.709 = - draft-khuzema-ccamp-gmpls-signaling-g709-00.txt

 

Hi,

 

We have a draft on “GMPLS Signaling extens= ions for OTN” available for review.  It can be accessed from the following link:

http://www.infinera.com/rfc/draft-khuzema-ccamp-gmpls-signaling-g= 709-00.txt

The above draft is not on IETF repository as we = missed the submission deadline.  We will submit to IETF as soon as possible.<= o:p>

 

Please review and comment.

Abstract:

As OTN network capabilities continue to evolve, = there is an increased  need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is a= lso specified in [RFC4328].

The recent revision of ITU-T Recommendation G.70= 9 [G.709-v3] and[GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support fo= r optimal service aggregation.

This document extends [RFC4328] to provide GMPLS= signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. T= he signaling extensions described in this document caters to ODU layer switchi= ng only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document.

 

Thanks

Authors

 

________________________________

 

_______________________________________________<= o:p>

CCAMP mailing list

CCAMP@ietf.org=

https://www.ietf.org/mailman/listinfo/ccamp

--_000_F050945A8D8E9A44A71039532BA344D80FDFD430FRMRSSXCHMBSB1d_--