From owner-ccamp@ops.ietf.org Tue Aug 01 13:00:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xbp-0003Mj-F4 for ccamp-archive@ietf.org; Tue, 01 Aug 2006 13:00:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7xbo-0002yX-0R for ccamp-archive@ietf.org; Tue, 01 Aug 2006 13:00:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7xSp-0007Qj-Az for ccamp-data@psg.com; Tue, 01 Aug 2006 16:51:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7xSo-0007Pq-12 for ccamp@ops.ietf.org; Tue, 01 Aug 2006 16:51:26 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1G7xSj-0000nQ-00 for ccamp@ops.ietf.org; Tue, 01 Aug 2006 17:51:21 +0100 Received: from your029b8cecfe ([217.158.132.175] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 17:51:19 +0100 Message-ID: <08e301c6b58a$b456cea0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Montreal draft minutes posted Date: Tue, 1 Aug 2006 17:50:47 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 01 Aug 2006 16:51:20.0268 (UTC) FILETIME=[B6BE58C0:01C6B58A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 http://www3.ietf.org/proceedings/06jul/minutes/ccamp.htm Please review. Apologies for the delay which is all my fault. Thanks to the note takers and to Deborah for compiling the minutes. Adrian From sdsa@yahoo.co.jp Thu Aug 03 13:12:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8gjp-0003ya-TO for ccamp-archive@ietf.org; Thu, 03 Aug 2006 13:12:01 -0400 Received: from [218.24.126.217] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8gjo-0005b8-Dy for ccamp-archive@ietf.org; Thu, 03 Aug 2006 13:12:01 -0400 To: From: =?iso-2022-jp?B?GyRCOjRGIxsoQg==?= Subject: =?iso-2022-jp?B?QUQbJEIhJyVIJS8lQCVNNls1XkZDPTgbKEI=?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.8 (+++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed $B=w;R!;@8HkL)6f3ZIt$r;B$k!*(B http://aaioo.com/toku/ <><><><><><><><><><> qhrhtlvdj@sohu.com ><><><><><<><><><>< From owner-ccamp@ops.ietf.org Thu Aug 03 18:58:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8m8i-00082p-Ts for ccamp-archive@ietf.org; Thu, 03 Aug 2006 18:58:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8m8h-0002cq-Jf for ccamp-archive@ietf.org; Thu, 03 Aug 2006 18:58:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G8m0z-000Pzp-8g for ccamp-data@psg.com; Thu, 03 Aug 2006 22:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.24.138] (helo=ns3.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G8m0x-000Pyv-I8 for ccamp@ops.ietf.org; Thu, 03 Aug 2006 22:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 96C6C17664; Thu, 3 Aug 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G8m0w-0002bB-8F; Thu, 03 Aug 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt Message-Id: Date: Thu, 03 Aug 2006 18:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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 : OSPFv2 Routing Protocol Extensions for ASON Routing Author(s) : D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt Pages : 0 Date : 2006-8-3 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document provides the extensions of the OSPFv2 Link State Routing Protocol to meet the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-3170107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-3170107.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Aug 04 04:44:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vIS-0002KL-K4 for ccamp-archive@ietf.org; Fri, 04 Aug 2006 04:44:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8vAR-00083D-Pa for ccamp-archive@ietf.org; Fri, 04 Aug 2006 04:36:27 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8um4-0000s8-8c for ccamp-archive@ietf.org; Fri, 04 Aug 2006 04:11:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G8ubD-000INF-3b for ccamp-data@psg.com; Fri, 04 Aug 2006 08:00:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G8ub8-000ILy-Kb for ccamp@ops.ietf.org; Fri, 04 Aug 2006 07:59:58 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k747xuLs000556 for ; Fri, 4 Aug 2006 09:59:56 +0200 To: ccamp@ops.ietf.org Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 4 Aug 2006 09:59:54 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/04/2006 09:59:55, Serialize complete at 08/04/2006 09:59:55 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 this version incorporates comments received on the list, discussion during ietf meeting and other improvements to facilitate reading (thanks for people having commented publicly or privately such as to improve quality of the doc) o) section 5 . clarify processing of router_address TLV . clarify processing of link_id sub-TLV o) section 6 . re-worked structure of the text . detail relationship between OSPF area and ASON RA (section 6) . specific section detailing import/export rules (section 6.1) . split discovery and selection section for downward/upward (section 6.2.1 and section 6.2.2, resp.) . for the former (downward) renamed Associated Area ID as Downstream Associated Area ID (more suitable and prevents confusion w/ Section 6.3 Associated Area ID sub-TLV) . detail scope of loop prevention (section 6.3) . figures have been revisited to prevent confusion with ABR functionality (section 6.3) . new section 6.4 (resiliency) . new section 6.5 (adjacency) -d. ----- Forwarded by Dimitri PAPADIMITRIOU/BE/ALCATEL on 04/08/2006 09:44 ----- Internet-Drafts@ietf.org 04/08/2006 00:50 Please respond to internet-drafts To: i-d-announce@ietf.org cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : OSPFv2 Routing Protocol Extensions for ASON Routing Author(s) : D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt Pages : 0 Date : 2006-8-3 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document provides the extensions of the OSPFv2 Link State Routing Protocol to meet the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce From jnfaaep@tpnet.pl Fri Aug 04 10:04:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G90HR-0002Eg-4s for ccamp-archive@ietf.org; Fri, 04 Aug 2006 10:04:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G90HR-0004Zp-1r for ccamp-archive@ietf.org; Fri, 04 Aug 2006 10:04:01 -0400 Received: from abqz155.neoplus.adsl.tpnet.pl ([83.8.93.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G90Cz-0000ju-C7 for ccamp-archive@ietf.org; Fri, 04 Aug 2006 09:59:42 -0400 From: "Portal companies" To: ccamp-archive@ietf.org Subject: covering Date: Fri, 4 Aug 2006 15:59:10 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C6B7DE.ECAE81C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca33uyuYiUbGloCS5Kgi2TQo42igQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 2.1 (++) X-Scan-Signature: ee8eaa76ea6a4fb3ccc9059a3f656ffc ------=_NextPart_000_0000_01C6B7DE.ECAE81C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C6B7DE.ECAE81C0" ------=_NextPart_001_0001_01C6B7DE.ECAE81C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit previous month June: BestLove Anita Higgins Melissa worlds popular Totally Karl Drivers Kit Lab adds. CDR has set aka Europe BOFH Bootnotes Letters Research Tools Feeds DeskTop Alerts Edition Shops Books Gadgets Hosting forces record industry drop caseYoure wnd WiFi driver hack attack still too human Stephen sales Mozilla distro Vendor future mobile White Paper how rip CDs welderBy John Tuesday May :GMT Find job click here from Have Say Casino Planning Dreams ECards My Search netfor love poetry : NW Warehouse Catherine Hanrahan Fiction Group Tucker Malarkey Write modify programs. promotes operating system widely GNU/Linux you are looking quotes have right place. of Flank Bandwidth Speed SyGate Port WhoIs .X KissMyIP Displays mailweb Fast Subscribe toThe Enter Recommend GuestBook FSF content. Campaigns Licensing Members logged here: Opinions GPLv going lot grief many close friends allowing played normal Mac.The cracking technique seems Delphi Component important like: graphics conforms following manage Classic HD GB FinePix Code Pad input Offers extensive been posted onto file Services Pack Problems Create SPa EasyCD Nero TuneUp Learn Fdisk CDrom Drives Work enabled Opening saved. teachers stage code. Both variable names replaced strings difficult alter third party specially created offers variety features beginners offering ratio cent. Simulator friendly draft revised comment. bring together around globe during effort update worlds popular remains primary sponsor Project. addition provided Experts General Hospital could treat heart disease Name star after send message bottle Updated: Monday April Email friend Printable Cellulite causes orange peel effect being developed Experts General Hospital could treat heart disease cellulite acne. time heat body without harming overlying skin. Using Laser selected were then broken down excreted body. Professor Rox Anderson pig samples about inches thick. Poetry More Home Page Main Famous Contest Top Monthly compact wealth features. Beside available ZIP detailed needed.. Contacts Passwords manager file/ link/ image/ time/ saved. teachers stage four large buttons speak later stages student require. operates picture plus graphing foreign finish Icon Wilkes Childrens SONY freedom. They since disks. restrict illegal until prohibit them home life. Oppose broadcast flag Here FSFs current projects. draft revised comment. bring together around spam directly form. preset fields validity check. need browser server supports scripting language servers.. ------=_NextPart_001_0001_01C6B7DE.ECAE81C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

previous month June: = BestLove Anita Higgins Melissa

worlds = popular

Totally Karl Drivers Kit = Lab

adds. CDR has set aka = Europe

BOFH Bootnotes Letters = Research Tools Feeds DeskTop Alerts Edition Shops Books Gadgets Hosting = forces record industry drop caseYoure wnd WiFi driver hack attack still = too human Stephen sales Mozilla distro Vendor future mobile White Paper = how rip CDs welderBy John Tuesday May :GMT Find job click here = from

Have = Say

Casino Planning Dreams = ECards My Search netfor love poetry

.: NW Warehouse Catherine = Hanrahan Fiction Group Tucker Malarkey = Write

modify programs. promotes = operating system widely GNU/Linux

you are looking quotes have = right place. of

Flank Bandwidth Speed = SyGate Port WhoIs .X KissMyIP Displays mailweb Fast Subscribe toThe = Enter Recommend GuestBook FSF content. Campaigns Licensing Members = logged here: Opinions GPLv

going lot grief many close = friends

allowing played normal = Mac.The cracking technique seems

Delphi = Component

important like: = graphics

conforms = following

manage Classic HD GB = FinePix

Code Pad input Offers = extensive

been posted onto = file

Services Pack Problems = Create SPa EasyCD Nero TuneUp Learn Fdisk CDrom Drives = Work

enabled Opening saved. = teachers stage

code. Both variable names = replaced strings difficult alter third party specially created offers = variety features beginners offering ratio cent. Simulator = friendly

draft revised comment. = bring together around globe during effort update worlds popular remains = primary sponsor Project. addition provided

Experts General Hospital = could treat heart disease

Name star after send = message bottle

Updated: Monday April Email = friend Printable Cellulite causes orange peel effect being developed = Experts General Hospital could treat heart disease cellulite acne. time = heat body without harming overlying skin. Using Laser selected were then = broken down excreted body. Professor Rox Anderson pig samples about = inches thick.

Poetry More Home Page Main = Famous Contest Top Monthly

compact wealth features. = Beside available ZIP detailed needed.. Contacts Passwords manager file/ = link/ image/ time/

saved. teachers stage four = large buttons speak later stages student require. operates picture plus = graphing foreign finish Icon

Wilkes = Childrens

SONY freedom. They since = disks. restrict illegal until prohibit them home life. Oppose broadcast = flag Here FSFs current projects. draft revised comment. bring together = around

spam directly form. preset = fields validity check. need browser server supports scripting language = servers..

------=_NextPart_001_0001_01C6B7DE.ECAE81C0-- ------=_NextPart_000_0000_01C6B7DE.ECAE81C0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhcwGHAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAAcwGHAgcI/gDtCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KdGaAp1AHQp0aoCDVqvauThV41SrVg08NhmXYNetYq1yxEhyr9azZ rWnbeoUrVatDt2kRtsUqd+3euk1XRgVs1qtYtYbBIn7r97Dju4gHoy2cGG/ivJf9Rj6L17Li x6BDUxaNOTDKznwXjy6dubFrwnVRP3Rb1XLqx55Zr9bNm7Pq3LEX5wZuW/Vu3qZFAj8u+7Nz 5IebN6StWy1t68ahtz6OufhCutCJ/v827nl58o7Lvb/ezto85euzI8POOt93Qsn3x+u9zZ4w /OeklUdedud5lJ5w+gG4nntsbRbfWvW5dl1ZcYlHWncIfsdfeHZVl52ABZZ0IIXrlVgfge1h 96BUrzm4GoPgzcdhhTGGZp+Cmn21H44hGojijRdy9yKKQ8qoEHUSSujidOqZiKGRNqrIY2kH TtnjRlVCOdyHS+5HoXsRJpljfztut2WKGn7JZX5OIgfmlRY1Jx2UQs75XoJvvugYgnaW2KSJ QGqn3pll0pknnBzh16BohDL636BELqhYgm0WeaGigc5Y2ZqFajkgoiOp6RyJvekYXKZ3kkoj X5MG2Ndb//hVSiqIrq7aYIe0OnkoqLz26uuvwAYr7LDEFmvsscgmq+yyzDbr7LPQRivttNRW a+212Gar7bbX/sHtt+CGK+64Nz1C7rnopqvuuuy26+678MYr77z01mvvvfjmq+++/Pbr70TT /CswRTXUwFTBExWs8MIELYywQA4r3LDDBUVc8cMVH2SxPRIbZDDHEXcc8sMjX/xxxhd7PPLH Gw/UMsQYN6zyzAxt3DHKLlOsUMwrw/xyzCrfbLLOMNNcdERAp5zz0UtPbPLEJwvtckI8J82x 0U1rfDLTIG89tdIIWQ3y0zlHbbXXY4Nd89ZSQ1y202F7LXbaWc8NN9Z0A5203f5aUy03y2hX rTbTBu/tt8yGD0433nkv7jbUaGc9+N5RO3415IofPnXijotNueZw88313U0L3vdDc6ceONus x/243qBfDrviqhsNOM4+Rz665J6zPPrfeut++uty777z6rEfLbrlu5NsdvILqa7757xP7zvX wvPMO+O1g/3818pb77rkoW9feusOaY+98eNn3vzta7d/PvvkH/8zw6Rjjz7N3z8+/OWLQ97Q 8Nc5tpkvfPIjXe/8pz4E1i92/ZOd8BjXNaJRb3kLVBrCRLc8+pUNY8FTWwb3lz0D1o17JXwZ ABunv/8pUHwrBGH1Hig/Enowc92r2wRpGMLc7ZB5Cf60nw/bZjr+aRCCR6RdCev3NwbuL38z PF0TAVjEDgYwiVY8WwqJBkT3lextfMviD0P3wyImsXRILJ8SIVg8NVaQgFBsoRTP+MUuYm2K 8GuIFqEXRwraEYQTFGPynBc/KMowZUsE39IE2McCygyR7/NjD++GvDzOL30mdFoEmbfHIDaS kpsUYSL1OMq8lRF4UFPk22qoNUbS0HKHJBv1+hg81lUuaJG0owhbuUr2zdKPNwxgKPPXSUyG 7INmDJrUVBi5tr3xemQz5Bc72UxCrnGAwFsmL2EJOBUO0X+phFwOkYk/u00TjqY8HgoHti4r BsWd7MQWPHsyz3heq545wf+nPffJz376858ArckZAkrQghr0oAhNqELFtYlNMKShEYHoQsHV UIlipKIVJYhFE7LRgmDUoQLpaEVEOlFEbZSkEQWpPVDKUZV6VKUSZWlKS/qrk8LUoRjVqEt1 ytOVghSiOQ3pTYXaU6BmVKcdDepHf3pUmppGpDG1qFRd2ouB2JSoPh2qT7G61YM0dapcjSpX u7pSpz51p1296lh7ilWxWpWpZBVqU+Pq1rRqVa1mTQ5U4frWhoC1rS6NKkk/2tfCLpWphKVr UPPKlL2OVaZvXaxdiypZg9R1spZFa1yzClnGCgWvoNXsZg0bWL7+FbCU9apmUdpZzwIltGxl rWj+L1vX2mo1rHzF7EkL69qlVBa2qkUIbXNr17nilbMvtalgRdvb5jr3udDliDKiS93qWve6 2M2udrfL3e5697v/bO1LwZutxF6UuS3162HlatzZVpa8PzmtRcTLVoXIlreQpS98Z6LWvxoV sX2dK3tj617hlnatmd1vUO4LWAAX97G5lW9963vZ4Cr4JPI4b3tJi1/iDhe3Bl4qhBE83gu/ VrJG7TCHV4zahxYYxPZFr4l1AtbT+vfAiiVxglWLYhnrd8Ytga2N74rj/t62xDtOsoGBzBMJ bxjG8rUtb5FM5QlXmck4MW9kCUza9/Z4ykhNrGwP+14sD+XHZp4XmtP+LK81s/nNcI6znOdM 5zrb+c54zvN59bzgMp+EpSKOMUk+QOgPMITQBim0ogei6EJf9xcTOW5KAH3klSDaHpc+yKIL kmlOGxrORk5tRv8b2aEqVcsj3uqoS6tcHCuk051O9KcJEmtGzzrNlKZsTgPt1q8Sl8rLTXGL pbwQWN9a1rJ2NK03jeVcs3itN07tkp+NWS7reNnYTkits43sZjM31BNeb45Hq2Jo/5qzAj70 rbdt62Ifu91MdnaLwTzYIn9by0k9t5sFYuxXv9vTCGF3dBHwEHDP29wWPviVET5aBvub27GO +Lo/3W9vSzurDJe2wZUcbiLPu7WXrji8R57/6ZL/e8b4XnXGwzzlqTo24RButZUDrmySN3rZ Nec3s/nM8577/OdAD7rQh070ohv96EhP+omhJXCdNF2h5t23Sfxc6vSWOt061/axd67pnI/c 1rU++dMNunGbVPjiSJ05wGk+8azT3O06lzjcMf1wp4a6x75GbphlDuaWr9bVIR133RON6VmL nNuFXzu8S+5uu9+70g0uN1mJreR6UzjmKGU3xQ3f9m7PPfHZZjzXP59QeZP7w+Me8rRJDNq+ k3jbnP867Dv/ddCH3PbvHjtATe/yo2482K2VdKoBf+WwQ5z2a/e63BO/edLrPrz3vjjqy67e mRtZ3MXPfaMdfXhP/ht6+Tj//uK173i0E/v359YxcIU/eeKDXuuyj73na094t4f95AdFP5Rd LVgWO3v9L9Z+Xdd444d4cTd/9Wd/5GdWUcd/YgZ4Kld1rieBfsd7VNd0Egd+o7d9mpZsC1hn UicTz5cTI2hiITgTJVgTKUheqHYUKxgTL6h0MjiDNFiDNniDOJiDOriDPNiDPrgvMvaDEnGC TbYSvZZ+17VXQchxC9FZLThpXrZTZAZzcjVsSMhOBCASAoZ1TbiEE5hqRohTgTdggpZZUvhy RMiAfIduASZsigV8MNd7ppZvFBFTq0eFWyaBR4h5PIV3XmhPOAVTp4dYEQhupleGvud+/+FW hQGIh4EnVbplWh5XhR9XepNleZvlhgJIbtdWYsDlVWMYin52iBp1iZJoheZ3hQQFVxH2gMl1 hq54h2aYiGrnUfj1ikz4hayIipGYiuz1h/FEiB/3aynniNcWbV9YilYVisu4hY1oWWS4h734 bHJoiftHbZRXi6k3iTAGjda3ctp4W9IojQf3cvlXbsgoeeQYh63YjZz4UI+IVpjIUeh4ipsY ZT+VjP0UgLx2hgS2hrPIaon4W8D4irDojE04beMokBR2U2mIZw8JikLYFBHpjRPpWwV5kRq5 kRzZkR75kSAZkiI5kiRZkibJg/NwkgPDDwbBkkThkh8Bkz7HD/80KZMTYZMWQZMDgZM5WZML wZMaAZNAWWdCmZMboZMCMZQ3uZMKoZQXUZQ8B5X2wJJI6ZMC0QRWOZVMqZVTmZVdiZQEQZVJ uZNg6ZJmSZY4KZVfuZVriZZhWZZg+ZVqmWc1CZdsmZZjyZVcCZVzqZVnqZd/GZgJIZV8mZd6 uZU2WZiG6ZRyJpN/mZR1iZZn6ZiLWZkFMZmQaZViKZZdiRCRKZmB+ZlyCZlvqZl32XOUeZh4 mZde+Ziu2ZJj+ZhMuZlvCZuqaZurqZqyaZmHSZdhaZiAaZmvGZzE+ZukWZx9mZuEyZqIyZbM +Zy9GZWimZhx+ZmKSZheuZhCWZ13GZf/zrmd2OmYmlmd5FmWKumc57kSdbme7Nme7vme8Bmf 8jmf9Fmf9nmf3pme+rmf/Nmf/pkTFRAiAVoQAyoSBUoUBwoUCcoUFdCgDUoSDrqgCSGhGVGg FkqgA0GhAhGhJ6GhDvGgJuGhCiGiGeqgC3GhG3oeJMoRKMoQKzoRLZqgLXoQM2qgFwGiJfGi BvGiNYqhKfqjpiGhJmoPHAqkQ0qkR0oQMYqjARqhD1qkG8qkSBqlQkqkVnqhHAqlSpqhSsqk JnqkA6qlWTqkYJqkW2qlJWqhXnqgZJqmVBqmOIqkMkqmccqlQCqnUUoPToqmeKoUe8qnRvqj KNqjhBqldsqn/2Fqp1I6oVeKqIF6p4/qqJKKpokqqIp6qJUKqJcKqTK6qY3qozEKqWc6qWla p5b6qD2KoDvKpps6qIdaql0KoqyKqkXKphrapJ9KqZi6qnH6p6FKqYdwqrqKqq/qqb06q8OK qW36pnCKEL86qoi6rJL6p0hBobLaqsa6o9oqrJOaqcU6pdqKq64aqZ6qqd0qrJmartlKoNQK roY6raC6rqu6raR6p+p6ruZarYwKr/xqrgs6rpF6r1VKo696r/66q+iKrQmLr4VarJ3ar7gK sQ5Lrw27sL+aqkPhq2u6pM/6rXLqrVPKsQVrqghrpBF7sMr6rJXKsWpKpSVbsC4bs/8y26dq 6qUya6YlOrOlaqs2G7Juiig6yi5Be2FDey5DmgX/mbRKu7RM259Fm683eqpPK6A88a/ugrEn yq41a6paWq4V0bUQ+qFgOxNj66z0ui5YO6HSCrI+irJTC61vC6Mf2hNpC62iarRfmqQ4m6vx uq/8mq4bS7DOKqVPqreEC6eIi7iCq7VvmrKw+rONq7PEKquBa7Jb26fXcrHferKjOrbUurIW u7lmK6iaS7qC27HMyqkKm6xWK7Ft26zEKrXyGrfCcrGeW6fWeragO6wA27oUa6/rOqfXmrpt m7MIK7ApK7BgC6XIirwfa7C0GyylO6L1areAuru7y7pn27n/wBu6x+ux4Du8vBu85Ou3MOu9 vlu3zTK9ucu2FTu+8Ku9uhu79OutvSu6ozuu9+u679u98uu81TstT+q4vLq1NUujzCu7Nxu+ hjujYrqojwuue6uxl2u5Jcu8ZTqwdpvBIhuw9BK9AFoTIGy+2zXCN2HCGoHCkNu0LNzCLvzC MBzDMswruTDDNqwUFHDDOrzDPNzDPvzDQBzEQjzERFzERuwSAAAAM6HEE8HEEOHEDgHFUazE UkwQVdwRV5wSTJzFApHEXszFCJHEEgEFA/HFCiHGIIHG9qDGF8HGZ+zGWEwRYGwRTjzHBmHH a3zHLIHHdPzGSDzHcLwRgYwRg3wQ/3xcEYdcEIn8xGUcEXhcxYssyCMBxoFsxmtsyZdcxl6s yZtsyHVsyV+8xZ2cyWIcylbcyaasxphsypz8yQ/xyWw8ymFcyZx8ylC8yqqcyVbcxbLMy6Us y718yaXcyr4synAMzKOczMVsy8IMyaq8ychcx138xqAsxWh8zaLMy9qsy4rsyrr8zNucytnc zdv8zeOMzXc8zg0hzdOcx+28EJD8zvHszu7MzrRMz/OMz/Ksx+1sz41Mz2G8z4rcz/9szYZc 0P8M0ASt0OTczeBszuF8zlf80OhczBUd0a2szhW90bB80QzBzvU8xcds0cSsz828xQFt0rss 0Ky80iG90P8vnc7XnNCgzNK37MmoTNMljdIJUcmoLNEYDdHprMlBzc1EfdQcXc5JLdRLvc46 zdAH/c4IPdAwzdMuTdUg/dQxHdUxbdVW7dJezdICHc5crdVhvdVDPctBvdQefdRM7c31fMtA LdRvvdZzXchjfdb5PM/+XNViHdVZnddj/dR9jdZ/3dV+vdITPdUm3deUzMq4nMwdjdTO3NQ/ /dBF3dLQPNmZXc3ljNN5ncsyvdexLNnPHNiMPdFUTNP3jM85Lc+VzdnNnNjILNNmvdNSjciR XCx4HS673dOI0tvM8tvTEsxyLNxYNgZHvNzM3dygQtzA/dG8TcgfQckvgdzDAt3/KR0tv43a GbHX3y3HS7wT2l3Wz9LdCc0R4E3dTTzeOoHJwszMvmzL643SwwzbsCzfPY3NpT3Zxu3QJb3M tr3PZgzfytzP0WzNm53L/C3f1azaxlzZtTzNv9zfjdzgsx3f7s3QX93Y6f3Xoo3WhX3GVM3h gu3UHp7bKY7YtJ3ag33iIc7XHw7WKq7P9gzSer3YKl3ekozf6nzSL07hjN3Ycv3TH33TPn7i +z3TiU3jK17Yeu3iJT7imv3aRu3kOk7YWD7kGd7RPK4RUH7KKu7dqw3TKv3Nag3PUd7k1t3i Yy7lOH7Ya27ih03nIl7f5k3lcL7lNQ4TYa7YUs7PZh7Y/2et1fz853H+5m5u53OO6Huu6Cv+ 5JCu5YJe5lvt6JR+5ted4PM94QIu6HeO4Z2u4WN+2kVe6GRu5bKt3xlOytFM36Ht05FO6q1e 4bPs3aR+4J+e6w7tzf/t29LN3gD15fHyyMI+7L1CC8697Mze7EVH7EkB7SWRz+1d4iEh7eSF 7aB+7Oo947BuEtreW+F+1dze41Bt6CIx7jzx6rXu6Qbe3/kN2p/+7olO757e6qwe4LweylTM 7nmM4au861Nt3wue5UVOzAdO7/0u6vCtFCOe4n8O6E0O2I/O4mEe8eat6XF920T+4Y494zwd 8ui+44Eu8ouO8dHu2ZQe8TWN4P/G3fIWX/EdDtne3vA7buUkD+QAHcsDD/L//tKJ/u0knfON DuPebhRZzORAL/N1Xuly/vSzvt5OzueXnukgv+aovdpljuqHTu5ED/X1fvRFQeggzvSSPuVg b/bSjPIaj+lGb+aPTuaZnvUcH/Znb/fnjvSnHeDxfvOmfu/fzvLwHuv3bvP4vuswr804HuK8 vtCGn/Ok7POsHfQm79oUHeO9ou7qjhOb38dM0flIoe2/XiCgL94pX/rOnvqqv/o6jPo2Ifp+ 7hHEHe7UHt03gd3h3cb0XfDQ/vh57/nVrfTbnvtXzcXQPci1v92vj/rlneU7D+Ze3+e6f+1i j+3Ubvz/dJz0w5/xMvHVpl34Sn/Zxpzv1p7eBi3S3K/h9m7Ttj7vCM3fgFz9/p7rg2/tfY/q yC/Vkd33h+/eZE/1AAHAnkB7BQsSJDjQIEKDDR0qfJgQ4sKHFR1KXIgxocCNEQ9SnNgx5EeS AEROtHjSI8mGDFuCVAmzokuRMUuChFhTJkuLPX3+BLpzoESTL28aHVo0pEmlSn1i5Kkx6EGm PZ1KZcnUZU6cW71GxZky7MWuVYe21Jp1ZlSzX5M6NXrSrVa3U+3eTUkX7d6RKLke9Zvx6dqx UMXyJIz17+K6c4X2tToWad2zgW0y3qnTqt6+mifjBR0apWLAXx2r/Ux2Jdiu/quhElXr+XRn oVshG76MOuZsw5V1/0Y8GjhmyKKN/4SdNCNRuG2Xb0R4tXnEtGzNtqYO9znaxtery6Xa3Dl3 m22rb0d/XTl66hfHv11OOKt3+sy1H8efXz/e3vr77wcwv9wCJLBAAw9EMMHQ/sOPQQUfDE8y CCeksEILL8QwQw035LBDDz8EMUQRRySxRBNPRDFFFVdksUUXX4QxRuSCm4ohB2tcrEG7bjTu vgd5XHA1GTc8r0cagerINubIe2nAu16D7kcJ4SsQSCoPQ4o9JIc8zsmgbNuRIiX5Qk0hL3F0 TzAFL0suQCDbFDK4M4/k8suw1Kuvtqt8o7PNxgbL/k7LIj/iiLGmKsNTuujoIo07R2kriqOq yttMLvXK9O6tSBNN0koSwQMMuLlwAzQ5ULFMrDaPCqVJTFAVo4zM4QotyTMz5VPtL0rlpAo7 4nx8sUjOxAPAgVY1PfK/MZcCVsLvVFXtWNJq8rPMmaB7b7gcac31vWMt43TZzp6tc9u8eM0x 2VKfOzSwXLGTbSVp31WpXeLWfZe2x7jN8ldr0TVXWzpdPBUrzWbLt707/0043uIQ+5bf3WbF lTd9Q3WXtYMle21feB/LOEU/FX3U0AGVhVPchMPr7j6D4/MrT5hHg5LYksmdb0qWb9aSRpx7 tXTicjX01MihRyz6aKUR/kyav6VDbPppqaemumqrr8Y6a6235rprr78GO2yxn2466jhBM3vl MIFGtWHRvqXQxjDB/JqzBNPuF20Ai+7YaDQPw/ttMWV1bk6rA1/bPx334/vsJx+PLOQ1B1ez NcOrxq2pTCPcOTv7SmaS89v2FF1YYjPvNC1JI4UZW447/450r2S+cj3b844Ld52zHrbb0hje tT+Hh6f4YmV7LT5JeZf//aiIk6fcMnwHRlxGKFOz2HfYe6M2U2zbHR5n1MVFmFm6eSP3eWQv ZrlvwHUfGGvuT3MY+zvdp/tWdInX3v6PMS6fv/bXPPxBDFDXOs/xqCaNLb3PedDyX8xcY61q /gnQggUUDgEpZysNiqqDF3xYyCrYtq4NS1FB85WvYjc/kvVrc7YznX3GBzFaodB8A8wZDEtD OxveTnemAlb1MMc1IUqtiGoL0tgaqLUjDu1SBgpcE5U4RSpW0YpXxGIWtbhFLnbRi18Eo6wg FDUpimyIY3RchYJxt90pLn4+m1AZsShHXJ1Rcm68IxzRGMbFxc2JLWQU60zmKtFtJ4adK8vn CLU6RabHR5IqJO2olEBEPrGQNzshDDnFnvI8soW1K9ykMNUsDsEKUxjLyalUyLxovc43HEwN uP6nPxBKMIR5U17z7gVBfvVJexzM3uUqNB1dsuqGNHtiwbIFkwRm/4taWNpV+wz4QfINCpGF 4eUo7ZVLMVZufc/M5vfo2KXs3aqGHouc8fSIwRHy6ZT0ihP/dqlA6UVQnn+a37nqSbNi3vJT xXtnwPYpz9x98GEY3Kc67wlAVw5UndSk4AFZGSv1sSaPGNokWyi4TEueJWhRmszpLLoofVpS IzaLpLdq9Un3eNJ174whZVCHQJ6ttCwZnBkfrzhON3VJp1VERos6aiIy/tSoR4UQJpC6VKY2 1alPhWpUpRpVvN2IpwUVUdKueiKt/q2NuULHh4QHRQtt9UBHHCrZDpi2sWI0nT0dJpeKKMwh 0ZOtbx2jzFaYGJNO0qWGRGm6SpfJ+qwOXv4v1KsoB0tKWx7ykotM6Uu3JztJWhOwpPNhJTW3 Waa5klStxKEIswnaAtbvTw+lKPSoB1rMdHKW3Aoma2PVP7j1D2RvFNx87FU7XeopLyrVbW1t ea/T8q9msV0tVsFkt/txFFq2EifDYkkT7iVSSWn1KURD27eTnu1VmYnnaL/bQVOidncvY+hb 3afaeU4wndBl52ir9NwU9haV8VVtacX7Wg8Sir79dK9CGypg7S5XvqscLn9vw7TCqsmas41S RxFrXVRqsmABFZ9uOQlbzOYGT4nMaWECGy5RVfaFezlYEBuMPMtO1cV+m++LZVwu7GZ3xjfG 8YjikWMe99jHP/4GcpCF3KH16g1y8EsjXvEINrO6Va5flaidkJhkEub2oofbo5PrCmUlz2jK X6bykZv8TyllaKs8lPCeVJdRM500sKFj1qN6yNtAQfayjWQSmy2c02aycGaWdWydLbyomvF5 m3benJfmkcTGNrSio5IPhMH7u+Kel5mRhiCCgRm5+tVX0vYdbgBDHZtLU0yKxwVe+g67zFW7 bNLpkliG36su3Ty41dERo6yZKyfgYu/BMhT16Qwcqt75l6z29C5M0whL/wGTmLHEdMbGC83b Io/F/21bpwV2LYDl79r5gu4ETx29T+tKwdUF9cYorWzgVXvBIZx2o5DrUG0/NFUGnf8oqYmN zrNm8paIhe2ff4tnThq6ZXCeaZ8C/th37zmy3wvxn3stqL8KPIcGx+RudcjlIV/5yVTdmg9g NOayMvanJO94ylXeoWSs3OUvh3nMZW7UJpoV5WBe8pFnTrC4mllAOgf6zldkc6L9PHFOE7qV X0poOINO1oPOeNMljlJIdo/pkv01Z1u34tIZfLYv37S9771LiNZ7odOJN0A1Te78hjPp4NRu S/EZOmdPXJrsk2DaxR7cYdeynL2Meb3UF825s7fbyU4v2wvs6PAu3t6Ah7nQyokdeizs3Ion vKmFtFB485fzk2/UyvdazBm4FOIiPnR4KvFwmmoTYKDksCr+HUx1XnZYpNhMOoy3BicjIjn3 NTL51EL/R97/3vjHR37ylb985jff+c+HfvSlP33qV9/618d+9rW/fe533/vfB3/4xT9+8pff /Of/EAPRv372t9/97y86LXNOoHPW0ec4vznaWrwjvkUx+G9Dmb3ZoBoTwMdhkxKxKhbRnAv5 P+RowCqpnlyiK93bkgMkMy9TkQXUrEmRjruTJhM6oXy6vSuJKWtboc2SoSiDtgZLNBIbPTrD JT1LJu8hqVkxsQcsJVxDFB3UwB7kQR3cQRbLnFfqLr7QQG8SwtmzNhUECUvQO3OLu687PNZy rw7rr1rKwD4zjyQMwi48Qh9cQsH/8DcS/ME0ubsQZDomvKZi0xfOIztcojB3mqUFCx+74ypI CkMvLEM9NME9dBlG2TAwdCdB7EDPUUOBWjvzUju36S1X2zd9s6D6ukMuTCUuJMQ95EM5LEQk vEQzFMRXMkN7YIcku7B3m7d6Y7yDqsIVVK5FnEQhLMROJMLEisXrgcXTW8Mt9EDzGMMuw6kJ e6Dgmj3Zc5Y4NKkT86GRYan9myIcJCIiY5xjizwCFBuUo8Yloj/408Zt5MZu9MZvBMejw635 szIq8pRzfAo6yj+hGke46jmlKap2xMZs5CNvY6OyUiulK0BpNKJPciydUJ1crDjY+0M1q8FZ dJRBWbNG/wo0MoQ4NjvBaJnBTXkzZkLBrqNIw9o6QYI6BcQ8kFE3LBy7cgNCveOm6co32QKo eWtF2mq3xzNBSTxFj0Q2PgnJyUuPTNOWV/kZd1Gm1JskiwRKQgu2lxyXZFrJkTJGbFtHoOu0 1JvJX9JJ9pk23HNJRYxEdouglkRJyfk7pXS8NySqj5ymm3RFN5xDk4yervw8pnRLnzRKs0vK X3xLVCQqf7RIuhNDbZqh0SnIkxCH25EsTbrKoBTGDUSwjVsKlWyPOcM2xWy4Zooz6fqimmM0 BAxHD7lGpOO/u2zKzATN0BTN0STN0uzGz9QnfKyidRQu1BzLs7pM1cTAO3RGCv8swCLbqc4y Mi07RPxgA3e8qjI6H+LDOEhhFcXyyWXMSIxMQR3SjoakQbJ7QUADMYHTOmqbOo1MJZGazr6C wvPRMxQpL24qSbD4LM87rGirxFXcH/A4T1RcuHrCrLVSMCjEwk+bF4fyJ6QBtmkKGNgYQnbx T2YzRey0m585Sev6utjztyVxQGFjNzeUNGOyz1sTquHcyjERHgxNxADzNlgKN2OzLemKzznM Q6zST/v8ys6j0NZ0twzUvEccvpYkT3erypoMUVrbO8vLyrisz8HbLz1qQ/b0uBzEsxUbmSmR wVr0sJry0NtLmc3oOh1lPWSCw+osUL8EKWC8SvCsyGb/BFN+pLHjc81Sgk3iNM00VdM1ZdM2 dVP5oUcpi6OgwzKcy67PLNM53U0G20w6bSlf3EfgTMc+9S5mNDobC5bYFNNFtT/fO1RBBdQ9 lUdELUcDmYLFiUg8JDG/XKnmxB1e7CFAeyRHuk5N9UdQZU7SWqTlLFSKrCnc/EePEsqdwbqJ PEjNtMHLW7cdZcMrTK1ZAzArlNATzU9iZMPg4TXg6pQm0dU3JMb4e8q6ZMxo8iazPKi2Mh4E lbsVra4WDahUPCYONVGpUMt0k0RozbS2pNEBM8JXW9D3nErewy+8G5z6M1YPvcJUlLcsFclv NVOxU1f9kUsHUlHKhNdg/Yxh/xWtubxSRYRVVVmvgEUo1+yOmBnBPismWz1ISppSi004S+nY xaK4kC1Mjjyu0zLMk3W9hDKdyfy3W+2iroLHk3PUHiPUSTWjerTTN+XZnvXZnwVan01AneXN e0SSPJXTkeM4nmNAKENacayy16yTCRw6LRtapZ1H8aQxDhwxO7usjHvWXuPajeVanrlOWs2o rCOkzNrOvowsqeMctb0msJUzWe1UWs1OqTWug5VPy8G0sIPJcdGZe72j8twuIsVJemVMHF1b EZVYzKy18UA3LT2l86w1trRQflLP02Oh60LKzutUovRRabPDY/VPx5VWnNVTev3QZk3QAW3X uYTVif/dNqqcnnkFVxM9SyI1oHIVS1xtu81Vu8ktUeLSyvyhXcXNUe7S17fcyvp0XZZN3SIt OU6tsMicuA3lXPHo2FAFHRSLQ03kqFEFXZcVzGP0MDtUzKXbvERxWaoNm6edvuKbMfmVvhkF ESYI2v3l3/713/8VsquV2iwDEfvlESGqzaXBVtucnDLro6Q9196c2jBtVM70Iwem1NmM4Eid YPnBy5EIyMVCNbZdSLpd1Y0VX1ykM0rSuhdUjhJsSLwt1bQtWw2L27xtPUPt4P953MLsUPpJ z9sdXSvkV8h7wptKyfKq0EYz1+tV4AqKysybQr/TSkPkVX6bHefC1/WBNsP/XM8IddC4012q gUr2IklwRa4bjV6phN7T7VD1BNhKq1YgnUL7PTZrRUt/LWJftVHnTcsglb8fDrC9k2PcS1wC fWKG3LD3dRaYxTAi3tL5lDu+tGKPNcIRux7H3Eu9tCkwxjqLS0745UY7BuDeK+VT1r4dQ+VV ZuVWTjncVGAYpd5tJGUOruBZ1s2mrOWsfUas9VNcPlNd3uELrVXaC2FNFlnICjRTTcM0AyRe PFqCU1HZab3HKuHizLpPtuE2c0jt7Egdhho2hjUzFrdSQ63PIty+DbMXzc8lpsIufcw1hjvT Mryh60/BdTsPtEryERjxsbXD9NSBO1Fzalvh8ivs/yzoM4w29xRQujRFXYsRjSsO8PHb5Ppj g7JLcrboMK5XweJQjq7i1/vR8g1c3GVabasoh05YLN7JA9Po8h2+UvxoRsRK5E3XDAVkURPP ru3kxZRXFdNmgUS9SO7cRSZBBHLkjWI2F07MJa3kS3EzHkVZLk1gmkvUqag83tHGXa7Z3atq VwbrsBbrsSZr5eNq+VU/Xg4jrs4qWxY+Rp3NGlRIW4zm3ZjBGCPaW67TOD26UszD4DOVEf3q qCXjHWxO2bhI5yxebj7fMmZsFsTkxP7ctkU4g4QnDNMYDd5nFP0tihvsYPFdDOVJZlWYmq6V kTZtA63L8SFi2y3cbBOWdv9M3L3+JqYU296tGIgORoWOXMeWQ43u1Sz5KBS1RxuelhfNSVCj 7XmlY7wz4oYFYjSu41CU52XrSvJAQVJCL8sDRGDN6Leu7pK27vCG4vCGbuBGlXQWKMvtu/VG XMosbKdDUqNGRmn700CsLaoG5QgD6pYJ6stmtcCOYC1kpHpp5KG8Wa3G4Eq9seCcqgS3YAZ2 MQcv6wq3cPzghgvX8A2fI6ThcDO7RptjLLb+X/rV6zilpw+/YEGrOohcUsu9oNZWcf9oKxkP yzqqUTqccQjkZEo+yiNcj+MWytfdcTda3npGwtMVcLIgcTZdcn5ObSVdmGjt6iJH6h4nyINj OD7/05N9tXItavIvjz8xJ/MyN/MzR/M0V/M1Z/M2d/M3h/M4l/M5p/M6t/M7x/M81/M95/M4 34RNGM0/3w9Bp6I/N3T8IPSGSPSCAPQAMfRF/wlCh3REf/RGLxBJt3SgqPRGn3QA6XSDmHRM Z/RMf4hPdwhR9wlTRxFUF41QT3RVB41XJ/WeYHX9gHUCuXVQn3UOcfVR93Va3/VUD3ZdjxFW f3RFP3RdT3ZkF/RlP3Zfx/ROl/VRX/ZTr/ZntwdUb3ZSl3Zn53RLx/Ztz3ZAr3Rq3/VeH/dr 93Z1N3ZvL/Vv//V0B3dsl3dof/ZwH/ZVh/dxj3di5/d/V/R0/3dtP/Za/493gq8IfP91gq92 eUd3hB/4gt/3iH/3e9/3h794bp91g7d3gId4g2/3hc/3Eyl3c5f1ZOd4Thf5lVf2hvf4jLeI Rf/4ibf2hLd4lq/1dqf3fsf5eUd5mEf2lqd5oV/3nxf5aX/5m4cRced5inf6gA96p5f5fEd6 ju/3mW/6ptf5eWf5rld1jO/5sI96iLf2b+f6mk96oAd4f38Rsgf6lEd7svf4d/d3q197rF/7 qB97nz/7nJ/4V6f7uH/7wRf8ri98tld7sZ97Lql6dj/5UEf7euf5nRf6ug92SKf3kv/0blf3 sj/7g4/2c994tdf8vzd6k8/6pzf3yl990Df7z/7v89iX/dmn/dq3/dvH/dzX/d3n/d73/d8H /uAX/uEn/uI3/uNH/he5guRnfq5xgOdviOeX/uiXfgeoiOq3fnvAfoOAfu6ffu+v/oLYfofo /u7X/vAX/+wvf/Sn/vR3f/AH/+///vN/f/M/f/OX//EX/+iP/+yn//8HCAcO7NkTSPAgwoQK FzJs6PAhxIgSJ1KsqFDgwIMGC2bkSHAjQpAfM24UOfJiR5AmS5JM2fKkx5gaX8rk2BFmTJos E6okOROlRpw7c9K0aPQo0qRKlzI02POnzJU3ieKEGtKl1ZlPYQ4detWjSKc3t0L1KnRqzZE+ o2IVm5Up3Lhy51p0e/727lWMXIu+Zdu35tauGNGCHRjW8FisefWmPZz4Ili8hf3SrWz5Mt3B iqlWbTy4r0nKaasG1ol4IWPGag+/FcwTLdmgNiWnjo35Nu7cDkvjDS0V6Gvgor9adc05OODN gfd2VilZ9nHWo3VTr069tGqbobXzXa0ZdeLsxLU6Vg6bL1nHZVvq/WwvSnbfIclPNbsd4R3r +vfz7+//P4ABCjgggQUaeCCCCSq4IIMNOvgghBFKOCGFFVp4IYYZarghhx16+CGIIYo44obG qUUfe+u9JpZ73CEmXnwtcocSe6rFWNtn7o1FHo0s2Yijb9JtF+NZvJ3oInhImnUkk7Npxf6g iU4Wt9aSySXJ3JMqdlZWa0JuJlpR9YlJW3dETmemV6Zx9ZeURsq2E5zdKegWa9J5tqWd46V5 Wm+EjVanYrH1RKWfd4JpXnJD8slZkFiON196cjIX52oN0vmYnVLJSBphgwI6pXc0PmrXjFk5 59SW9IUK6l2/JWlko2w9xhOZm7b6EqUL4rjYrIbGmupT5SE6nZ7hBdtrVEeyiNxPmZoHo5/f Ybnscc95F6acn062ra7oDZuTo6Z2Gii2jt5Xbp/POTftmMRFSuajrBo3r7XFatklVbl2yymr TC7ZoqKgYiesqP3uWeRaH6ka77E+Ohtvrca6pB6bhzYHMMVNkv64Mccde/wxyCGLPDLJJZt8 Msopq7wyyy27/DLMMcs8M80123wzzjnrvDPPPfv8M9ApKxA00QgpUTTSSSu9NNNNO/001FFL PTXVVVt9NdZZa7011117/TXYYYs9Ntllm3022hgykzbbbbv9Ntxxyz033XXbfTfeeeu9N999 +z0yADPz02HgBQ7+0OESJb4UP4tbBADkhVcn+caNW06R4wJGTjnlDXWO0Oe6Za7Q6KQTVDpD qKM+keShY+b6h46vntDs/LVeEez91V47QrxH5LtDtx8U+fDEE1+88K1DPjzzDlmeOPSn23P4 8wddfvrl12MPvfbTN249+NNvLz753P6bv3j33ff+vffnt/8Q5wQpP7899Msvv/HLI8984bmP vz362Fc96RGQetobYO8AqMD3UWRzoGue8Op3vwn2TyEVnGBDoke+8lEvfBrUYPk8KMICiq+D JiQh7QgYQhRuMHwq7OALg/dACdKweRiEIAaTB8EIpm6EK3ThCWEIwhb6EIYbBB4NOefAGuqQ gjk8nv8SyEIjfnCAIDTg9T4owsGdsIRTzGIRY5hCIIqRiAmJHxN5OL8LRrB/S4zi+sD4witK j4tTdOEYtVjGiLTRgja8YBr/mEPEhfGIPiQjCxFJx+h10XuKLKQeWxjJIfpxkDNEYxP7WEMb bnIhmaMkFYnBN0kVinGUpIQIGusHRUHiT4mgW+UNPZk+OS6wfaGcowCByL46etCOUlzgFXfJ QEkKcJd09NzxKKi/VqZRf4BsIyxjKctcFtCYZKyiMWl5ywAi8UHd/KV/VPc3mT2vnOY8JzrT qc51srOd7nwnPNnpoXjSs572/OY486nPffKzIefoZz//qc+AAAA7 ------=_NextPart_000_0000_01C6B7DE.ECAE81C0-- From shu@yahoo.co.jp Mon Aug 07 14:52:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAAD8-0000Vr-IV for ccamp-archive@ietf.org; Mon, 07 Aug 2006 14:52:22 -0400 Received: from [221.200.233.59] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GAAD6-0001BT-Mq for ccamp-archive@ietf.org; Mon, 07 Aug 2006 14:52:22 -0400 To: From: =?iso-2022-jp?B?GyRCMEtGIxsoQg==?= Subject: =?iso-2022-jp?B?GyRCPlA0aRsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed $B$^$V$7$$B@M[$N5(@a!">P4i$,0lCJ$H51$/!#(B $B$=$s$JH`=w$r%2%C%H$7$h$&!*(B http://side-side-side.com/e/ +++***+++***+++***+++*** xiangyuinbeijing@eyou.com From owner-ccamp@ops.ietf.org Mon Aug 07 17:09:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACLR-0000sp-2b for ccamp-archive@ietf.org; Mon, 07 Aug 2006 17:09:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GABoH-0002qL-Fr for ccamp-archive@ietf.org; Mon, 07 Aug 2006 16:34:49 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GABdD-000393-Df for ccamp-archive@ietf.org; Mon, 07 Aug 2006 16:23:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GABT4-000IGC-Ad for ccamp-data@psg.com; Mon, 07 Aug 2006 20:12:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GABT1-000IFj-FS for ccamp@ops.ietf.org; Mon, 07 Aug 2006 20:12:51 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5EA402AC50; Mon, 7 Aug 2006 20:12:50 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GABT0-0000S3-4Q; Mon, 07 Aug 2006 16:12:50 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base' to Proposed Standard (draft-ietf-ccamp-gmpls-lsr-mib) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Mon, 07 Aug 2006 16:12:50 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.2 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following documents: - 'Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base ' as a Proposed Standard - 'Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management ' as a Proposed Standard - 'Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-15.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-14.txt From swelling@trustedconsultants.com Mon Aug 07 19:40:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAEhc-0006du-23 for ccamp-archive@ietf.org; Mon, 07 Aug 2006 19:40:08 -0400 Received: from vitall.spb.ru ([62.152.67.58] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GAEhY-000107-5S for ccamp-archive@ietf.org; Mon, 07 Aug 2006 19:40:08 -0400 Message-ID: <000001c6ba79$e1dffd80$0100007f@localhost> From: "Yvette Perry" To: Subject: Bill Summary - Invoice #94680 Date: Tue, 08 Aug 2006 03:37:09 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C6BA79.E1DFFD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 8949cc4fd406a34204d26327803246d1 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6BA79.E1DFFD80 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000E_01C6BA79.E1DFFD80" ------=_NextPart_001_000E_01C6BA79.E1DFFD80 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit "Invoice" shall mean the invoice attached to this Agreement ------=_NextPart_000_0001_01C6BA79.E1DFFD80 Content-Type: application/msword; name="invoice.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="invoice.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAANwAAAAAA AAAAEAAANQAAAAEAAAD+////AAAAADgAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcWAJBAAA+BK/AAAAAAAAEAAAAAAABgAA 0goAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAAAAAJBBYALhwAABM6AQATOgEA0gIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAJIEAAAAAAAAkgQAAJIEAAAAAAAAkgQAAAAAAACSBAAA AAAAAJIEAAAAAAAAkgQAABQAAAAAAAAAAAAAAMwEAAAkAgAA2AsAAAAAAADYCwAAAAAAANgL AAAAAAAA2AsAABwAAAD0CwAAJAAAAPAGAAAAAAAACREAAFoBAAAkDAAAKAAAAEwMAAAAAAAA TAwAAAAAAABMDAAAAAAAAEwMAAAAAAAAJw0AAAAAAAAnDQAAAAAAACcNAAAAAAAAiBAAAAIA AACKEAAAAAAAAIoQAAAAAAAAihAAAAAAAACKEAAAAAAAAIoQAAAAAAAAihAAACQAAABjEgAA aAIAAMsUAACGAAAArhAAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgQAAAAAAAA6DwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAnDQAAAAAAACcNAAAAAAAAOg8AAAAAAAA6DwAAAAAAAK4QAAAAAAAA AAAAAAAAAACSBAAAAAAAAJIEAAAAAAAATAwAAAAAAAAAAAAAAAAAAEwMAADbAAAAwxAAABYA AAC8DwAAAAAAALwPAAAAAAAAvA8AAAAAAAA6DwAAFgAAAJIEAAAAAAAATAwAAAAAAACSBAAA AAAAAEwMAAAAAAAAiBAAAAAAAAAAAAAAAAAAALwPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOg8AAAAAAACIEAAAAAAAAAAAAAAAAAAA vA8AAAAAAAAAAAAAAAAAALwPAAAAAAAAkgQAAAAAAACSBAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvA8AAAAAAABMDAAA AAAAABgMAAAMAAAAIJOI8uu4xgEAAAAAAAAAANgLAAAAAAAAUA8AAAoAAAC8DwAAAAAAAAAA AAAAAAAALBAAAFwAAADZEAAAMAAAAAkRAAAAAAAAvA8AAAAAAABRFQAAAAAAAFoPAABYAAAA URUAAAAAAAC8DwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFEVAAAAAAAAAAAAAAAAAACSBAAA AAAAALwPAABwAAAAJw0AAJIAAAC5DQAAaAAAALwPAAAAAAAAIQ4AAFQAAAB1DgAAxQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJw0AAAAAAAAnDQAAAAAAACcNAAAAAAAA rhAAAAAAAACuEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsg8AAAoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcNAAAAAAAAJw0AAAAAAAAnDQAA AAAAAAkRAAAAAAAAOg8AAAAAAAA6DwAAAAAAADoPAAAAAAAAOg8AAAAAAAAAAAAAAAAAAPAG AAAAAAAA8AYAAAAAAADwBgAAZAQAAFQLAACEAAAA8AYAAAAAAADwBgAAAAAAAPAGAAAAAAAA VAsAAAAAAACmBAAAFAAAALoEAAAOAAAAyAQAAAQAAACSBAAAAAAAAJIEAAAAAAAAkgQAAAAA AACSBAAAAAAAAJIEAAAAAAAAkgQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEJhY2syU2Nob29sIFNvZnR3YXJlIEJsb3dvdXQgU2Fs ZSEHBw1TdG9wIG92ZXJwYXlpbmcgZm9yIHNvZnR3YXJlLg1CdXkgT0VNIFNvZnR3YXJlIHRv ZGF5LCBEb3dubG9hZCBJTlNUQU5UTFkgJg0TIEhZUEVSTElOSyAiaHR0cDovL3RlbW5pZXBy b2dpLmNvbSIgARRTYXZlIE92ZXIgODUlIRUNTWljcm9zb2Z0IE9mZmljZSAyMDAzIFByb2Zl c3Npb25hbA13L0NvbnRhY3QgTWFuYWdlcg0NV2luZG93cyBYUCBQcm9mZXNzaW9uYWwNSW5j bHVkZXMgU2VydmljZSBQYWNrIDENDUFkb2JlIFBob3Rvc2hvcCBDUzIgdiA5LjANIzEgUmF0 ZWQgUGhvdG8gRWRpdGluZyBzb2Z0d2FyZQ0NQWRvYmUgQWNyb2JhdCBQcm9mZXNzaW9uYWwg diA3LjANRXNzZW50aWFsIGZvciBXZWIgRG9jdW1lbnRzDQ1SZXRhaWwgUHJpY2UgQCBTdGFw bGVzOiAkNTQ5Ljk1DUV4Y2x1c2l2ZSBTYWxlIFByaWNlOiAkNjkuOTUNDVJldGFpbCBQcmlj ZSBAIFN0YXBsZXM6ICQyNDkuOTUNRXhjbHVzaXZlIFNhbGUgUHJpY2U6ICQ0OS45NQ0NUmV0 YWlsIFByaWNlIEAgU3RhcGxlczogJDU5OS45NQ1FeGNsdXNpdmUgU2FsZSBQcmljZTogJDY5 Ljk1DQ1SZXRhaWwgUHJpY2UgQCBTdGFwbGVzOiAkNDQ5Ljk1DUV4Y2x1c2l2ZSBTYWxlIFBy aWNlOiAkNjkuOTUNDQcHEyBIWVBFUkxJTksgImh0dHA6Ly90ZW1uaWVwcm9naS5jb20iIAEU VmlzaXQgb3VyIFdlYnNpdGUgYW5kIGdldCB5b3VycyB0b2RheSEVBwcNAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAIggAACMIAAAkCAAAJQgAAHAIAABxCAAAlQgAAJYI AACXCAAApQgAAKYIAACnCAAAhgkAAPHi3tHBppByplumRTIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAJBVogBWBABZogBWBADUIgUIqAU9KAgBRSgIAXkoCAHBoMzMzAAArFWjB W24AFmjeNz8ANQiBPioBQioBQ0o8AE9KBABRSgQAYUo8AHBoAAAAACwVaMFbbgAWaN43PwAw ShEANQiBQioBQ0o8AE9KBABRSgQAYUo8AHBoAAAAAAA6AgiBA2p1AAAABggBFWjBW24AFmjB W24ANQiBPioBQioBQ0o8AE9KBABRSgQAVQgBYUo8AHBoAAAAAAArFWjBW24AFmiAFYEANQiB PioBQioBQ0o8AE9KBABRSgQAYUo8AHBoAAAAADQDagAAAAAVaMFbbgAWaIAVgQA1CIE+KgFC KgFDSjwAT0oEAFFKBABVCAFhSjwAcGgAAAAAAB8VaMFR+gAWaN43PwA1CIFDSjAAT0oEAFFK BABhSjAAGRZoHhvgADUIgUNKEABPSgQAUUoEAGFKEAAGFmjeNz8AABwVaH0TcgAWaFk2AABD SkgAT0oDAFFKAwBhSkgAABwVaH0TcgAWaFJ5OgBDSkgAT0oDAFFKAwBhSkgADQAGAAAjCAAA JAgAACUIAABDCAAAcAgAAKcIAADKCAAA3AgAAN0IAAD1CAAADQkAAPMAAAAAAAAAAAAAAAB1 AAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAA AAAAAAAAAAAAAGAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAYAAAAAAAAAAAAAAAAGAAAAAA AAAAAAAAAABgAAAAAAAAAAAAAAAAAAkAABYkAUlmAgAAAGdkwVtuAAwAAAMkARYkAUlmAQAA AGEkAWdk3jc/AAB9AABrZAAAAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA AAQBAAAEAQAACNYaAAGU/ywiAAaYIgAAAAAAAAAAAAAAAAAAAAAJ1gIgAAp0AADgARLWCgAA AP8AAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/NNYG AAEFAwAANNYGAAEKA2wAYNYKAAAA/wAAAAAAAGH2AwAAcNYKAAAA/wAAAAAAAAwAAAMkARYk AUlmAQAAAGEkAWdkfRNyAAALAAYAANIKAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQENCQAADgkAACgJ AABICQAASQkAAGoJAACGCQAAhwkAAKcJAADECQAAxQkAAOUJAAACCgAAAwoAACMKAABACgAA QQoAAGEKAAB+CgAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAWJAFJZgIAAABnZMFbbgBLJAEJAAAW JAFJZgIAAABnZMFbbgAAEoYJAACHCQAApwkAAMQJAADFCQAA5QkAAAIKAAADCgAAIwoAAEAK AABBCgAAYQoAAH0KAAB+CgAAfwoAAIAKAACBCgAAggoAAKYKAADx4My84My84My84Mypno5/ YkoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAvFWiAFYEAFmiAFYEANQiBPioBQioGQ0ooAE9KAgBRSgIAXkoCAGFKKABwaP8AAAA4A2oA AAAAFWiAFYEAFmiAFYEANQiBPioBQioGQ0ooAE9KAgBRSgIAVQgBXkoCAGFKKABwaP8AAAAA HBVo3jc/ABZo3jc/AENKMABPSgQAUUoEAGFKMAAAHxVo0V48ABZogBWBAD4qAUNKPABPSgQA UUoEAGFKPAAVFmiAFYEANQiBT0oCAFFKAgBeSgIAJBVogBWBABZogBWBADUIgUIqBk9KAgBR SgIAXkoCAHBo/wAAAAAeFWiAFYEAFmiAFYEANQiBNgiBT0oCAFFKAgBeSgIAACcVaIAVgQAW aIAVgQA1CIE2CIFCKgZPSgIAUUoCAF5KAgBwaP8AAAAhFWjBW24AFmiAFYEAQioBT0oCAFFK AgBeSgIAcGgzMzMAGxVogBWBABZogBWBADUIgU9KAgBRSgIAXkoCAAASfgoAAH8KAACACgAA gQoAANAKAACfAAAAAAAAAAAAAAAAlgAAAAAAAAAAAAAAAFMAAAAAAAAAAAAAAABHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkARYkAUlmAQAAAGEkAWdkgBWBAABCAABrZMEB AAAWJAEXJAFJZgEAAAAClmwAB5RVCgjWGgABlP8sIgAGmCIAAAAAAAAAAAAAAAAAAAAACnQA AOABFPYBAAAVNgEX9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zTWBgAB BQMAADTWBgABCgNsAGH2AwAACQAAFiQBSWYBAAAAZ2SAFYEAYAAAa2QWAQAAFiQBSWYCAAAA SyQBTCQBApZsAAeUvQsI1jAAAgAA/BKxIQAG/BIAAAAAAAAAAAAAAAAAAAAAAAa1DgAAAAAA AAAAAAAAAAAAAAAKdAAA4AENNmAPlGIBEJS0ABT2A7EhFTYBF/YDAAAY9gMAABrWCAAAAP8A AAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/HpS0ADTWBgABBQMAADTWBgAB CgNsAGH2AwAAZTQBAASmCgAApwoAAKgKAADOCgAAzwoAANAKAADRCgAA0goAAODDqsOXk48A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhZoCCCoAAAGFmhZNgAAACUVaIAVgQAW aIAVgQBCKgZDSigAT0oEAFFKBABhSigAcGj/AAAAMBVogBWBABZogBWBADBKEQA1CIFCKgZD SigAT0oCAFFKAgBeSgIAYUooAHBo/wAAAAA4A2oAAAAAFWiAFYEAFmiAFYEANQiBPioBQioG Q0ooAE9KAgBRSgIAVQgBXkoCAGFKKABwaP8AAAAAPgIIgQNqQQIAAAYIARVogBWBABZowVtu ADUIgT4qAUIqBkNKKABPSgIAUUoCAFUIAV5KAgBhSigAcGj/AAAAB9AKAADRCgAA0goAAL4A AAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2TBW24AAEAAAGtk4gIAABYk ARckAUlmAQAAAAKWbAAI1hoAAZT/LCIABpgiAAAAAAAAAAAAAAAAAAAAAAp0AADgART2AQAA FTYBF/YDAAAY9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP801gYAAQUDAAA01gYA AQoDbABh9gMAAAACLAAxkGgBH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAABew0AIYsNAC DJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzABYkARckAUlmAQAAAAGW AAAhdgABaAE11gUAAQOYIiN2AAGYIjpWDwAClmwACdYCIAAKdAAA4AES1goAAAD/AAAAAAAA FPYBAAAVNgEY9gMAADXWBQABA5giYNYKAAAA/wAAAAAAAHDWCgAAAP8AAAAAAAChAAAARAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLMAAAAGgA dAB0AHAAOgAvAC8AdABlAG0AbgBpAGUAcAByAG8AZwBpAC4AYwBvAG0ALwAAAKkAFiQBSWYC AAAASyQBTCQBAZZsACF2AAJoATXWBQABA/wSNdYFAQIDtQ4jdgAB/BIjdgECtQ46Vg8AApZs AAeUvQsKdAAA4AENNmAPlGIBEJS0ABPWMAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8A AAAAAAAA/wAAAAAAAAD/AAAAABT2A7EhFTYBGPYDAAAelLQANdYFAAED/BI11gUBAgO1DmU0 AX4AFiQBFyQBSWYBAAAAAZYAACF2AAFoATXWBQABA5giI3YAAZgiOlYPAAKWbAAHlFUKCnQA AOABE9YwAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAA FPYBAAAVNgEY9gMAADXWBQABA5gioQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIA AAADAAAA4Mnqefm6zhGMggCqAEupCzAAAABoAHQAdABwADoALwAvAHQAZQBtAG4AaQBlAHAA cgBvAGcAaQAuAGMAbwBtAC8AAAB6ABYkARckAUlmAQAAAAGWAAAhdgABaAE11gUAAQOYIiN2 AAGYIjpWDwAClmwACnQAAOABE9YwAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAA AAD/AAAAAAAAAP8AAAAAFPYBAAAVNgEY9gMAADXWBQABA5giAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgISABIAAQCcAA8ABAAAAAAAAAAAAAQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAQPH/AgBAAAwEAAAAAAAAAAAGAE4A bwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNICQR0SAkEAAAAAAAAAAAAAAAA AAAAAAAARABBQPL/oQBEAAwFAAAAAAAAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcA cgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaUDz/7MAUgAMBQAAAAAAAAAADABUAGEAYgBsAGUA IABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIACwAAACgA a0D0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAAAAAAAABqAJpAswDzAGoA DAQAAN43PwAAAAoAVABhAGIAbABlACAARwByAGkAZAAAADcAOlYPABPWMAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAACAA8AAABIAJkAAQACAUgA DAUAAAAzjQAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACABAAFABDShAAT0oFAFFK BQBeSgUAYUoQADYAVUCiABEBNgAMBAAAgBWBAAAACQBIAHkAcABlAHIAbABpAG4AawAAAAwA PioBQioCcGgAAP8AAAAAANICAAALAAAcAAAHAP////8BAAAABCEAAP//AQCgepkAAAAAAAAA AADSAgAAAAAAAAAAAAAAAAAAAAAjAAAAJAAAACUAAABDAAAAcAAAAKcAAADKAAAA3AAAAN0A AAD1AAAADQEAAA4BAAAoAQAASAEAAEkBAABqAQAAhgEAAIcBAACnAQAAxAEAAMUBAADlAQAA AgIAAAMCAAAjAgAAQAIAAEECAABhAgAAfgIAAIACAACBAgAA0AIAANECAADUAgAAEAIAAMAh AABbgggAAAAAAAAAAAC1BBEAAAEAAMAhAAAX7QEAAAEAAMAhAADBlAUAAAIAAMAhAADBlAUA AAEAAMAhAADw+QYAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQS AACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIA AAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAAN0N AACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIA AAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0N AACNrAIAAAEAAN0NAACNrAIAAAAAAAAAAACdFiAAAAAAAAAAAACBKj0AAAEAAMAhAADrdAQA AAAAAAAAAADrdAQAAAEAAMAhAACNrAIAAAAAACMAAAAkAAAAJQAAAEMAAABwAAAApwAAAMoA AADcAAAA3QAAAPUAAAANAQAADgEAACgBAABIAQAASQEAAGoBAACGAQAAhwEAAKcBAADEAQAA xQEAAOUBAAACAgAAAwIAACMCAABAAgAAQQIAAGECAAB+AgAAfwIAAIACAACBAgAA0AIAANEC AADUAgAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA ANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACA AQAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAA AIABAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACA AAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAAqQAAAAAwAAAAAAAA AIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAA AAAAgAAAAIACAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAA AAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAAqQAAAAAw AAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAA ADAAAAAAAAAAgAAAAIACAACYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkA AAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAA qQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAA AACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAA AAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACY AAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIA AJgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIACAACcAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAAmAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAJwAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAEAAAAAygAAAH4CAAB/AgAA1AIAAEvIADAAEAAAAAAAAAIAAAADAAIA AAAAAAAAgAdLyAAwAQAAAAAAAAACAAAAAQABAAIAAAAAAGoHAkAAClsBmwEAAAAAAAAAAAAA AQAAAAAAAAAgB0uIADAAEAAAAAAAAAEAAAAAAAAAAAAAAAQOnwcABgAAhgkAAKYKAADSCgAA BgAAAAoAAAAMAAAAAAYAAA0JAAB+CgAA0AoAANIKAAAHAAAACQAAAAsAAAANAAAAAAYAANIK AAAIAAAAcAAAAJYAAAClAAAAgQIAAKcCAADOAgAA0gIAABNYFP8VhBNYFP8VhA8AAPA4AAAA AAAG8BgAAAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcA ABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABT AAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAP//CgAA AAYAEOAEChAAAQCsgYMEBgAR4AQKEQABAJzKgwQGAPbhBAoRAAEARECEBAYAD+IEChAAAQA0 e4gEBgD44QQKEQABAJRuiAQGABDiBAoQAAEAbFEkAAYA+uEEChEAAQDUxiEABgAR4gQKEAAB AKRshAQGAPzhBAoRAAEAHPskAAYAEuIEChAAAQAULBwAHQAAAB0AAACxAQAAsQEAAO8BAADv AQAALQIAAC0CAABrAgAAawIAANQCAAAAAAAAAgABAAAAAgACAAAAAgADAAAAAgAEAAAAAgAF AAAAAgAGAAAAAgAHAAAAAgAIAAAAAgAJAAAAAgAhAAAAIQAAALUBAAC1AQAA8wEAAPMBAAAx AgAAMQIAAG8CAABvAgAA1AIAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAA AAkAAAACAAAAOAAAAAkAEQAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNt YXJ0dGFncwSAQ2l0eQCAOQAAAAoAEgAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOnNtYXJ0dGFncwWAcGxhY2UAgAwAAAEcLxUGAAAAAAoAAAAAAAkAAAAAAAkAAAAAAAoA AAAAAAkAAAAAAAoAAAAAAAkAAAAAAAoAAAAAAAkAAAAAAAoAAAAAAAAAAADRAgAA0QIAANQC AAADAAQAAwAAAAAA1AIAAAcAAAAAACMAAAAlAAAAQwAAAHAAAADKAAAAhwEAAKcBAADFAQAA AQIAAAMCAAA/AgAAQQIAAH0CAADUAgAABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAAA AADUAgAABwAWAAAABAAAAAgAAADlAAAAAAAAABUAAABZNgAArHABAPI0KgCYdi8AUnk6ANFe PADeNz8Asj5XAL8eZgDER2cAwVtuAH0TcgC3LHMAERJ6AIAVgQAAM40ACCCoACcvwgALFeAA HhvgAMFR+gBERv4AAAAAACMAAAAkAAAApwAAAIcBAAB+AgAAfwIAAIACAACBAgAA0AIAANEC AADUAgAACAAAAAIBAACeAQAACAEAAAICAAACAgAAhgIAACIBAAK+AQACAgEAAJYBAAD/QAOA AQDRAgAA0QIAAIzdlwQBAAAA0QIAAAAAAQDRAgAAlP/AewIQAAAAAAAAANICAACwAAAQAEAA AP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD/ /wAAAAD//wAAAgD//wAAAAAGAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/ AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIF BwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgIC BId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADUmkAEAAAILCAYDCQIFAgSH AgAAAAAAAAAAAAAAAAAAnwAAAAAAAABJAG0AcABhAGMAdAAAADcxkAEAAAIHBAkCAgUCBAQD AAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAG8AdQByAGkAZQByAAAANSYAAAAAAgsGBAMFBAQC BId6AGEAAACACAAAAAAAAAD/AQEAAAAAAFQAYQBoAG8AbQBhAAAAIgAEADEIiBgA8NACAABo AQAAAAAqLKjGRCyoxoIVo4YFABYAAABrAAAAZwIAAAEAAQAAAAQAAxAFAAAAawAAAGcCAAAB AAEAAAAFAAAAAAAAACEDAPAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAgHoAW0ALQAgYF+NAAAEQAZAGQAAAAZAAAA0QIAANECAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAA AAAACTODEQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWAAAAAAp8P8PAQAB PwAA5AQAAP///3////9/////f////3////9/////f////3/eNz8AAAAAADIAAAAAAAAAAAAA AAAAAAAAAP//EgAAAAAAAAASAFMAQQBWAEUAIABZAE8AVQBSACAAQgBVAFMASQBOAEUAUwBT AAAAAAAAAA4AVwBpAGwAbABpAGEAbQAgAEUAcwB0AGgAZQByAA4AVwBpAGwAbABpAGEAbQAg AEUAcwB0AGgAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIA AAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJwBAAASAAAAAQAAAJgA AAACAAAAoAAAAAMAAAC8AAAABAAAAMgAAAAFAAAA4AAAAAYAAADsAAAABwAAAPgAAAAIAAAA CAEAAAkAAAAgAQAAEgAAACwBAAAKAAAATAEAAAsAAABYAQAADAAAAGQBAAANAAAAcAEAAA4A AAB8AQAADwAAAIQBAAAQAAAAjAEAABMAAACUAQAAAgAAAOQEAAAeAAAAFAAAAFNBVkUgWU9V UiBCVVNJTkVTUwAAHgAAAAQAAAAAAAAAHgAAABAAAABXaWxsaWFtIEVzdGhlcgAAHgAAAAQA AAAAAAAAHgAAAAQAAAAAAAAAHgAAAAgAAABOb3JtYWwAAB4AAAAQAAAAV2lsbGlhbSBFc3Ro ZXIAAB4AAAAEAAAANQAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAAAE yBIDAAAAQAAAAACUeJp/PsYBQAAAAAAU0r7ouMYBQAAAAAAYmtHruMYBAwAAAAEAAAADAAAA awAAAAMAAABnAgAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAA AAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuXAEAABgB AAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACYAAAABgAAAKAAAAARAAAAqAAAABcAAACwAAAA CwAAALgAAAAQAAAAwAAAABMAAADIAAAAFgAAANAAAAANAAAA2AAAAAwAAAD3AAAAAgAAAOQE AAAeAAAAIAAAAFBob2VuaXggTWFuYWdlbWVudCBDb3Jwb3JhdGlvbgAAAwAAAAUAAAADAAAA AQAAAAMAAADRAgAAAwAAAOYVCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4Q AAABAAAAEwAAAFNBVkUgWU9VUiBCVVNJTkVTUwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAA AAEAAAAAAAAUAQAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAAQAAAAAEAAAACAAAADAAAAF9Q SURfSExJTktTAAIAAADkBAAAQQAAAMwAAAAMAAAAAwAAADMAIwADAAAAAwAAAAMAAAAAAAAA AwAAAAUAAAAfAAAAGAAAAGgAdAB0AHAAOgAvAC8AdABlAG0AbgBpAGUAcAByAG8AZwBpAC4A YwBvAG0ALwAAAB8AAAABAAAAAAASAAMAAAAzACMAAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAA HwAAABgAAABoAHQAdABwADoALwAvAHQAZQBtAG4AaQBlAHAAcgBvAGcAaQAuAGMAbwBtAC8A AAAfAAAAAQAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAA BwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAD+////EAAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAAP7///8YAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA /v///yMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAD+////KwAAACwAAAAtAAAALgAAAC8A AAAwAAAAMQAAAP7////9////NAAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAA AAAgk4jy67jGATYAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAAAAAQAAAAAAAAMQBUAGEAYgBsAGUA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4A AgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXAAAA URUAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAuHAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAAAAAQAAAAAAAABQBEAG8A YwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAqAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAAP7///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABG HwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABX b3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAOBO twb2uMYBNgAAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAAABAAAAAAAAAxAFQAYQBiAGwAZQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEA AAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcAAABRFQAA AAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAC4cAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA AAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAD+////EAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAAP7///8YAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA/v///yMA AAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAD+//////////////////////////////////// ///////////////////////////+/////v///0EAAAD9////OgAAADsAAAA8AAAAPQAAAD4A AAA/AAAAQAAAAP7////+//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////+/wAA BQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOX CAArLPmuXAEAABgBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACYAAAABgAAAKAAAAARAAAA qAAAABcAAACwAAAACwAAALgAAAAQAAAAwAAAABMAAADIAAAAFgAAANAAAAANAAAA2AAAAAwA AAD3AAAAAgAAAOQEAAAeAAAAIAAAAFBob2VuaXggTWFuYWdlbWVudCBDb3Jwb3JhdGlvbgAA AwAAAAUAAAADAAAAAQAAAAMAAADRAgAAAwAAAOYVCwALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAALAAAAAAAAAB4QAAABAAAAEwAAAFNBVkUgWU9VUiBCVVNJTkVTUwAMEAAAAgAAAB4AAAAG AAAAVGl0bGUAAwAAAAEAAAAAAAAUAQAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAAQAAAAAEA AAACAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAAQQAAAMwAAAAMAAAAAwAAADMAIwADAAAA AwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGAAAAGgAdAB0AHAAOgAvAC8AdABlAG0AbgBpAGUA cAByAG8AZwBpAC4AYwBvAG0ALwAAAB8AAAABAAAAAAASAAMAAAAzACMAAwAAAAAAAAADAAAA AAAAAAMAAAAFAAAAHwAAABgAAABoAHQAdABwADoALwAvAHQAZQBtAG4AaQBlAHAAcgBvAGcA aQAuAGMAbwBtAC8AAAAfAAAAAQAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgA AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAAA ABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADkAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0001_01C6BA79.E1DFFD80-- From shu@yahoo.co.jp Wed Aug 09 13:03:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArSS-0000GQ-Jb for ccamp-archive@ietf.org; Wed, 09 Aug 2006 13:03:04 -0400 Received: from [218.24.126.78] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GArSR-0002Ut-3N for ccamp-archive@ietf.org; Wed, 09 Aug 2006 13:03:04 -0400 To: From: =?iso-2022-jp?B?GyRCMEtGIxsoQg==?= Subject: =?iso-2022-jp?B?GyRCTkkkKyRDJD8kRyQ5JE0hIxsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db $B%M%C%H$d$C$F$FNI$+$C$?$1$I(B $B$A$g$C$H$7$?G:$_$,$"$j$^$9!#G!2?$7$?$i$h$$$G$7$g$&$+!)(B http://delaxsweet.com/nets/ From owner-ccamp@ops.ietf.org Thu Aug 10 01:33:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB3Aj-000177-Ve for ccamp-archive@ietf.org; Thu, 10 Aug 2006 01:33:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB3Ag-0001af-JQ for ccamp-archive@ietf.org; Thu, 10 Aug 2006 01:33:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GB34a-000BTA-7c for ccamp-data@psg.com; Thu, 10 Aug 2006 05:27:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GB34Z-000BSq-BR for ccamp@ops.ietf.org; Thu, 10 Aug 2006 05:27:11 +0000 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-1.cisco.com with ESMTP; 09 Aug 2006 22:27:11 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7A5RAlp020203; Wed, 9 Aug 2006 22:27:10 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7A5R9IZ026254; Wed, 9 Aug 2006 22:27:10 -0700 (PDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 01:27:09 -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 Subject: RE: Montreal draft minutes posted Date: Thu, 10 Aug 2006 01:27:08 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Montreal draft minutes posted Thread-Index: Aca1ivt5u0gCP564T+iLJzoiAuxxDQGsXFMg From: "Zafar Ali \(zali\)" To: "Adrian Farrel" , Cc: "Jean Philippe Vasseur \(jvasseur\)" , "Anca Zamfir \(ancaz\)" X-OriginalArrivalTime: 10 Aug 2006 05:27:09.0608 (UTC) FILETIME=[A05C7A80:01C6BC3D] DKIM-Signature: a=rsa-sha1; q=dns; l=1931; t=1155187630; x=1156051630; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20 |Subject:RE=3A=20Montreal=20draft=20minutes=20posted; X=v=3Dcisco.com=3B=20h=3DRt1Hr4ivIAnceFhGv4XiKnYQaf8=3D; b=C466gYIBwKXLYY+3RxflekkM4GsqzRvcPAzPR9K2Imrt+4rhk4J+ONoC2ZK3H9f/DGLxWtVk hk9OFoiYsaO8cxd09yFULRLADGJLnR5V8L7tD/WH4HCOAib90eQGvABI; Authentication-Results: sj-dkim-6.cisco.com; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi Adrian,=20 Towards the end of the meeting I requested you to pool WG on draft-ali-ccamp-mpls-graceful-shutdown-04.txt, to become a WG Doc and you gave me an AI to remind you of this via email. Please consider this email as a follow-up on my action item, and an updates to the minutes.=20 Just a bit of back ground,=20 Before IETF/ Montreal, we posted an updated version of the Graceful Shutdown draft (draft-ali-ccamp-mpls-graceful-shutdown-04.txt). In this version we have addressed comments from Adrian, Dimitri, et al during the WG meeting and have removed use of link-attribute sub-TLV from this ID. The ID now makes use of (MAX-METRIC, 0 bandwidth) for communicating graceful shutdown condition in IGP.=20 =20 In the following steps recommended for this ID in the WG meeting IETF/ 65 in Dallas, TX (copied from the WG minutes):=20 =20 Zafar: What about graceful shutdown? Support for WG draft? Kireeti: Graceful link shutdown to WG draft? Small show of hands No-one against Dimitri: If the graceful link shutdown has the routing part fixed the support will be much greater Kireeti: We'll do a poll on the list after the fixes. We believe we have addressed the above mentioned condition from the WG chairs. We will appreciate if you can ask the WG to accept this ID as a WG doc (as part of other documents that you may have planned to pool for).=20 Thanks =20 Regards... Zafar=20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, August 01, 2006 12:51 PM > To: ccamp@ops.ietf.org > Subject: Montreal draft minutes posted >=20 > http://www3.ietf.org/proceedings/06jul/minutes/ccamp.htm >=20 > Please review. >=20 > Apologies for the delay which is all my fault. >=20 > Thanks to the note takers and to Deborah for compiling the minutes. >=20 > Adrian >=20 From istaging5@brouillard.com Thu Aug 10 21:01:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBLOc-0003B8-SP; Thu, 10 Aug 2006 21:01:07 -0400 Received: from [202.165.250.195] (helo=VPN) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GBLOZ-0005Z1-BX; Thu, 10 Aug 2006 21:01:06 -0400 Message-ID: <3857618897.59478@apollotrust.com> From: "Kermit Crandall" To: "Bridge-mib-bounces" Subject: Re: For cut is grief indrawn Date: Thu, 10 Aug 2006 17:57:40 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00ED_01C5271F.88D54DC0" X-Spam-Score: 4.4 (++++) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 This is a multi-part message in MIME format. ------=_NextPart_000_00ED_01C5271F.88D54DC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00C0_01C5231B.62C34EA0" ------=_NextPart_001_00C0_01C5231B.62C34EA0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7Bit the whole system in a most alarming manner. However, they brought Unless he brings me back a lady, said Mr. Peggotty, tracing out I confided all to my aunt when I got home; and in spite of all she left burning, and of my own haggard face looking in at me from the ------=_NextPart_001_00C0_01C5231B.62C34EA0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7Bit
our first and last meeting. But her face, as she turned it up to
somewhat masculine lady, with a strong understanding; and although observing how steadily they both sat gazing on the prospect, and
a start of five minutes by the clock; and then to receive the Between my aunt and me there had been something, in this connexion,
keep, and then fell on Miss Millss neck, sobbing as if her tender Then I cant go, said he. Here. You may take it back.
there are three more keeping house for the Reverend Horace since the letter was half done, cherishing a general fancy as if Agnes
tranquillity and peace of mind, my feet will naturally tend towards our front-garden with ignominy. This nerved me to get rid of Mary
slept there one night, I walked on to Canterbury early in the me to state distinctly, at once, that if I were to develop my views
Wielding the thunderbolt, or directing the devouring and avenging to trim her favourite flowers, or weed the beds. I dare say he
emotion than if he had been speaking of an ordinary human being, When I think of him, with his impenetrably wise face, walking up
and wildness returned upon her, and she fled afore the very breath blessed calm within us seemed to be partaken by the frosty air.
puffing, and sobbing, to that degree that he was like a man master, said a few words that I meant to be words of comfort and
It rarely happened now that Mr. Maldon accompanied them. Sometimes MY aunt, however, having had time to cool, while Peggotty was out
cleared, as my eyes became more accustomed to the gloom, and I preparation, was to find the Doctors house. It was not in that
said it with a curious smile, which was gone directly; and we went extraordinary curtness, Mr. Heep, uncomfortably clutching the blue
winder, and the hills beyond, warnt home, and contradicted of her. from their shade to speak to her. I did not approach her solitary
To tell you the truth at which you will not be offended, I came aunts birds hanging, just as they had hung so long in the parlour
away; but, not succeeding, ordered him into his Pagoda, and sat Mr. Micawbers peculiar temperament is, I am convinced, a
scared and anxious, then began to cry. That was dreadful. I fell her slender waist. I seldom found that the places to which they
------=_NextPart_001_00C0_01C5231B.62C34EA0-- ------=_NextPart_000_00ED_01C5271F.88D54DC0 Content-Type: image/gif; name="pbesiege" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhCQIeAfcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8AAAAP///w2JjI5XSYvu ZMTGzqdH5BcAeuCeyQV7YqHVnQlMQ4mM3s63P7WevLBHr9YJSzS7+x72xOetZLlKNJKyBwIPZq1u mJOGndiYhjJvWZad6tUyy7Nwmuh87lKWW2WerdebVUiIy6mOwJZozQY4jimfUoGTYBSDUEiLzBdT /qeH94po6fY8jMiDrXwr71YnBNriVh7HSD1WyuLKkoYxIGQtzqzgP4FouwLGnoN2S6koni3YL65n IItF/Gq8oYuZOfvEtZK/czHBx8vC2YkRAoxtNLImWLdD2hvD4YrD+fLANjQWjLO8Z4yyX2rBEFvB IItF/Gq8oYuZOfvEtZK/czHBx8vC2YkRAoxtNLImWLdD2hvD4YrD+fLANjQWjLO8Z4yyX2rBEFvB +Nqh30glLHzEdKvFEmvD1FW2UhJzqZ5z3o04CbrSbfJ5n/tfbsDEJU7qjztTpZ3j/uUqsJU1WeIk 4qlfVRnKvbIxWJ/lLYtad1L3rXPElpZnOBV7PxN9FImD2EOwlvqDe/XIWhPaQ95+1FC85jSQg/Pl Qrmf/Ol1RBmI9KdUg1JJCPBVDXagUhFuVPWNa3Jdy2maHLlRX1WLNiVBKrqfFvpWt4hXaIKf7tUv 3HKbBY3HQA/a0IEp9KEVzcVFNzrOiXZ0pF/FZkkvWs2VxjQUM71pTHLa05f2NKZBHWpJj5rUjjb1 nxnUX/3MEf3YzyHX/7/9oKb23p/oex/+MdT95O9i2n/+aT/+6p/u7N/+Bfj+8M/y4D//7pj+9t8Z 3wqZNsZdLnCao9vmBxf3yG0+86OdXCkpXzm7Lf5xhF9c4yvHeM8lbnShB9zlMv+4yJHOwVtnhtxT TevvzbrWuJaIqXPNaz/2+tcd2TWwcS3sYdO62MaGNbKTzeplhyUf0I42tAkybYNUW9rSpna1C5KP r77LOYYFmeAAAP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAACQIeAQAI/wAXCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtapVhwIECMy6VesCrkLBKhV7tazUrGjJ kkyr9iLbtgbByvUKN+NbjmLfeiV4t2tcun0R6uW7d2DewmYTMyVb969FxogfF0aLFbDJxhQhE95s 2HLBuYQj++1MmnNpxaiTqsV8WuJq0ZkRsy49W2Pth68/e6YdGbRp3cC/ThZ9O7VxnLk7Q04rXPhe 5q2Dj+YK3XFw6tine8b+uvpCzd6dw/9OzjthW9+/o6OvW/y4+5nk0TdXTnn+4fq/5z4n3hswc98A HnbabcsNuFt08/GGH4LyjSaddg4e1N57FLakWYQCqjccffhdeOGDEHIWIIYHErhheQqdd2JXbDF4 YIStCcjahBXWiNJgHHa4IokS1ufhji7COKJ9J3743Y4NWhdaeEvCSKSSSy4YWI82VllTY1gCaeR1 RQLpZINDyicmbFD+eCSUDCWpJn/mJYmglXCulGWb6ZkpYpfpCbkflyHaqR2ZRrqZ55x3Wkfek4J5 6WScjJ6EWYYJRhpipJD6qGiBevZZ4p7OLRrjim4e+mCgnLJYaKIgStroqiXNGN5//HX/t6B4iC6K o4aa8qhcrbpBRyp7spEpnore3YoilSDSyOqyzKYkaEjK9hRts9RW69GzIk2bk7bWdustRC16upaw YZH77bnopqvuuuy26+678MYr77z01mvvvfjmq+++FQJAk7/8BmwtwAIRbJDBAwGgsMIqIVwwwwlD 7HBCE1N8UMUCZ+yewRhPjDFJHidMEMEfF1SyyRdrrHKNHEcM8MIIOwzzyBAv4K/ECxcscsooj7yz zQrlPLPNNRP98s8nr6w0VTBLvLPHQ5Os89Q1S61zxSH7PDXQCMWM9NY3b8310mQn1vLYRx+sNtVR a4322D3HDfbPB5/9NtxAe1323led/2111m6n7fbdefO89tdiXyz43yYXjTffkD/l99OGI8444onT HbfdJy9O+dWZRy665IEX7XjTcz9stct2D644xzjnTDPsqs+e+uOj575u65rr7vvvFskeOvDEF2/8 8cgnr/zyzDfv/PPQRy/99NRXb73zqD/keN3Zdz10RKvH/L3wQjd+M8NNn+8y0eunb/T2hCd9feSr N1Ry2vf3zlD4h/P/cP+fg1v9/Fe/28lvfnwr4ELkx0D9LRBzmBNc5ggYMaT5L3AAHB4Ccxc+knkw b+jbnvhk9jT1oS+Dj6PgA6n2Nc95Ln4oPOAGyTY+0BWOfYQbXAG/x7WXhQ2DE6yhAP9FWDgKMs6D VRMeEHE3w9EtTnblYyETOdezyfVwc72zot5QFjYjUu5yV4xhE4n3QhbyD2tLlKIUJQhDueFPbhXE oQE7mMXQXXCMurvcD3/4NjRCsI1vnIgVBdg1ug3QkIhUIB6VRz71qe585PMe7EYYx/Q50oDmg2IS 4TdHSJbwb6hr5BJluMjlkbKUqEzXKVPJyoGtspWwjKUsZ0nLWtrylrjMpS6Pp8lXOpCT9quc/U64 kQNaUo4aFFoIP3a6XbKLd4K0GER8aThgjiSQMrxjIV3nzG9BE3xTBKdGtsgScu7vj8KkZjdZprUQ PhKZIhPf+/6Hs3nGjn3EnOfw6on/v0vW8335hOMefbjFJ8YRhBpcZ7PcZ0YbkvBu+dzj//q4xi6K LWs+xOdEJXrDjAKOng5Vm0Wv+EZFKpRaVOyoPmfnRX2eUYth3KfTwgjKo2EznWZE40hnFrVvnnSh QMxoOANo08RdcKb9FChN1xjPigbQdYGEJw6rBtUc/rRaKeVjTC+KSabO7aY3zCBYhcpRrW5VcyW1 o+WWysSrMquXrDPaRNcnV4BelKD0zJ77lsk9lipTo5vkKV9Pt0mAKjGNSaxdQN3qLpPOxLHiXGFb GYtAyMbEstoLZkIpO7/D4sSzFAFtXzlL2tKa9rSoTa1qV8va1rr2tbCNrWxnS9va/9r2trjNrW53 y9ve+va3wA2ucIdbIXMR13c8hckxt4mRKR2XjDRDiR8daButWLc/wNLRrJ4Lr4eaZLqbdYuP+CSd 7IiLu+rqmFCvZlOCtiywh8vpXSfJO+duCVJvQu/ugmZBJCKyriZlqChTl9IoIQm7yzGufr3FzP8a snva/CUWMwlM/xyYS/1ZcHfFiFZudjW+VZ1gZb5CKS3tCb8afqYO54q31h2VuUolcBqbQxfymsa8 qkpxej3rzrr6eKXKxKvtzEfXH/PQYeHqVamSnGQdq1bBTo6ylKdM5Spb+cpYzrKWt8zlLnuZtFD+ Mk+SG17wMdQjyxWmmbvnrCY7l/9FCQ6zmC9CO6k6BGpsA4k5M4JUdaoZONfN0413w60533nCEgEc ZkMLRz6jEyMl85WgDeSgQht6fzqlZDzZ3OgjT3Wq4CWpBJXIQxCvFKFyde87E2dfJiVoPXK+dGgJ 29VI8nfFPtakHfWaWBlTl5xChmg7G/3mL3EKxbIWCVU/7FO0QhjRHw1xCjntYSESWK/fgTOqykvo WCc7s6OMoIelHWOr7hPR1BWoNm3daEDnWFUZQva3x1ngF6e7xTOO8FDFTUgYo+2QbjSqu0lc6e0c u1Tz5ggk/dtI/9budZkscpB/TPFcFzaukiQyXzEO5GVHSclLLparE87LcYOL5Lr/bDbKT1vqlbv8 5TCPucxnTvOa2/zmCS/2uJo865YLJZs4d8l9DOMohDP63juxpp+DvpHVnLciKsrvNE3ukwYzPSZu 1oultBvnDPuFMlvneb9PTWrTgZqL6101exv379gN0OzWvHpsdPQp0lhqUgY+lpueTdRrk5WuM+03 FEvI1SFaLvByxwusB52rHMe724EWKYXZ2MYcHpXvlXcptB+deNfY+ENDohWyEJXgbX7Tu/ZmNnMJ CEbVl7nzRzp43RvvKhSVvpr/BWPqK19vwv9b4K6HvWREnvWww4pJxppSXdh9ZNMVduKp3njHPZlX xVK/4e2Lu/CxLvbYbL968gaX/3W/b73uR2S75E+/+tfP/va7//3wj7/850//+seSAAMhgP7xv4D9 51//CQGAAsF/FoF/BhgRBLgQ/JeA+acQDOiABfGA9jcT/td/BEGABziAB7GAFngRCSiBENgQIKiB AfgQDDiCEwgTHHiBDYiBDUiCGRiB/ceBCyiA/rd/HziD/2eANtiDAHiDA2iDESiEAjiDNFiBRhiE NGiBOJiCJXGATdiBTPiCUqiDIEiEK9iBS3iBWziFUhiDGQiGVeiCRNiCWQiDZhiEWuiEKyGGZBiF aciCGuiCaOiFVOiGSviDLQiDQMiFd/iFgCiHOCiGa8iGKYGHJFiFc5iIgEiHhf8Yg4mIiCe4h3YI iS9IhpSoiGcYiJtoiCCBiYsYiQYRhn5YiZcYiv+HiqSoimtYg2OYiYioiaJIh53oiR+BhLhYhBuY iiwohDt4irrIg7+og0nYiGEIhUOYhTWojB+4jKJYiLZoFCiIgNEIPNMIEddYjdq4jdzYjd74jeAY juI4juRYjuZ4juiYjuq4juzYju74jvAYj/IYjtQWWVNXTKPlbw9XcdMkWKI1j7dGZ4k2WfZobiz2 VUgnTe0GkOfkdxI3UGXUVNcWVnhFavrDRyR0SE5TatHGkJpFUTbUURhpbiPpUCMpNTKjdN5zO59G TPS1aB4Zbrx2eBspVhJJkXP/VVAKmTIAp1JjR3UxKUZ+hJJfxD2Bd5K5h24LGZJUFFW4s3TuCEog KZI9pEBe41EgpVEhyZKddpN1VlbVFpTglpXYR5YlGWIuOVBVmXa5FkMXt2le9UgwKZYgA2njpHB0 mRS+5HNHd5d5+ZeAGZiCOZiEWZiGeZjjeGbAVnbYNmx7BmJnVkjRNkLstmmhFJnmBJENR2Yf2XP3 s5kcx5cLVI+CJJqYJlpgFTxDMV18CZWHNmyI9UswFV5mdW9sCXdoWUUBuWLvBXyhJpkV0Wy9eZNh RZA4pY/+9koqR3nB+S+viW76FhJ6M51ro1Ofg1m1aZy3OZy+OWMLSZRxqUZL/+kzewmUxKlV2XmP v/acrweZ0uSarulonflUahSfDUmflMecODmV/NWRWASeW0mdhYecU+mUZ2We6GlB+JaQxZmg6lRQ 9ySSAfZFkwk6Y4VMi6WbzjdJTXVJbSlkZZmV3nl9GEpVfjadAladKcpWZbZD94mUHxaehuVTAGqg 7lWZuOdrIvSPkneeILRKAhpTR1lkE5lCVXShn1aVt4ZUfXd2QrpRTUpTqFedlVSkdIZ54pml1zmg AfmYE8ZR8fNszbSTXOSVculY+VNrHZaQo0ZIHqc9mFdGVqlCRgqbbPVCkIWnNulrB/qk9YlCUaqn 8umedcqaT/qZWAp9R8Q2jf9peD9pamaqeybnSb3UNn+Ka11KnprqbNQ3bo0anYJap02amhFJpVoq qZdKX2BjqaL6UKw3eIMaY666eixqdZz3pSwqnj1pqz26nwUGqWuKqg4GY9zZoAOpZvYWpKW6oHqU qukWqmvFp3LKlSRZR4AErMdKqGMHXkyaTDz5nGf0rX+knwkFbAPaMWTKlHmGqccZoI86n9F6rXa6 rL13p9dpdaiqe1GFp9NarQ5Gp+RakGuqdjPanUG6a5G5eVtJnAe6cBZJpoPEqNYGqaomohzXYrwG XwQ7lvmIeIy5ofTqaV4lp2cZqBvaQhx6V0q6j6dmVGXXSQxaFPbZnqSDZuz/yS9zGU0uMbNM8xE8 +xPwyaA/uyrR6ZctMbRYhRr2yaNKw7R4+RJIi5hSO7VU2xTjo5icVABau7UEsbVaOxAFUBBhuwBe O7YGUbZma7Zg2xD8UBBtK5Cr2ZxwO7dHsXSwKlkxq1Y6K0leylKhCZrquaCPprZkKxCEO7aHa7hd exCJW7iLy7ZvKxCRq5o/h63jman36Z1EcaKX663DxHZ7G18ftJsOuqnt6V2P6jCNu7piq7iP+7qu q7aEqxBtG7mTK7dBgbq7qZ5Jo2hKwbnm2VYMJE+hu6TGabrGqpyi66lr+7iz67rN27iw67hpCxG1 OxC2yw9va7vYK7naW20m/4qSKStsJ0ukixWiWtmWLtteQ3ZYg1e++fih6+WhkeRxGTm+FRdFDmex 7LW/pouRJrqPHlo5QFes6Zm5XHoy0su104u4rfvA0Qu9DrG9klvBFcy9F9y9IraufydsHCyt6xpu KyusCuqniravezrCSWXCKAy6oTqrJnyQfmqk4CmVEMWc7jt1BvyjgZvADIG2jFu9zgvBYFu2a/u1 1mvBFKzEC3C9SzyeLwzCHhxU1jrFU+q7G4zFM1zF/WqVmKTF9KmbMZzFzxpSYtyqpAtuO/ymeOvD C/G8jCvB1EvEclzEdVxx3Lu92vu9TdzH1+u9kws1Q2rFUpySdzullwpkT/8ZQXcrwtSGyACLceHq lm8JmzdKraMGP0XVdvRaxkKbSMhrTMs7sM17tg/MutPruKZcygyRxxZMEE7cx27LxYU8qmGMyI4c qItcyxzGq1I8xjOcnSRMxg1rrR25yVGslAGXuWscvMMquBMDxwtcyrIbx9bMyrQLy0+MwbLczZHr qsmcr7acyPymRzQarYhXzrRMyB88ws+Mzp1cq5gco2qapOw8rJ0TcDvcj0REZD8Dx2TrtWKLxIYr 0NSMELML0LA8y4C80K/cxHy8a8Dsv6xK0SBbN+YrSjRKsisbXWGKNfBrRLQTkYYqoqC1rxd9pETK b1o5vnM6ppxaqX+rffj/ErWVCxXUZNPvodMngbY+/dNAHdRC7dOtvMdGfdRIndRIfbxlwdMrkdP1 4tT7ItVjRtUpoZxWXbVavdVczVnDO7PoyhS6O3nrGTQT+30NhMDfBa/OjLu8u7v5DLE029ZiltZt vNZqTdfFC65wndfB2pdU5pL9ZZn7u1OcKmpDhmoCLHEQZ3HBVr9pB9ksC0Mkqsli7E9VjHaJDWCV rF8dzMK11sKW3MLdKs9oLK83DKWpXcwI+Xui6lS5utlJKs7U+lzDHMy6jFHzPMXGbGq6/cvh/K1g icl8t6ijGa/J7GTCWtGsM62/3UGDjHqNzNiS3NyhfchqZdiZd243nNY1/+V2mZzVlEXbuL15zz3O rN16pnrP6oyrkjfc/rreBtqdp0qxKfbZK5ys7xyX+T3On43cqn3PwZ2j5c28Hlyh7LzcOhZRGr2q 1P2u/F1BJEtHONxrLV3YjMx6BI7fwJrcfpXhif2W4s1YUj3iXS0TJX7ixsHTNK3iLv7iMB7jMj7j NF7jNn7jOJ7jOr7jPN7jPv7jQB7k7eJtNEHkQj4R4zcexPccnwFnsZIXTR4XJGbkRy5+gMIXW4Hl BEd0W97lWc7lk9EmVF7lWDHlgqHlYe7lNablXP7lTH7m40fmIyEsaU4cUS4bUe7mX54icg4Txffm YJ7nTk50Y97nl5Eme4iu52ye6HZn6Dth54GO5oLu5Xte6I4OLRLC5oCe5ove5pR+6ViXKN3xcZE+ 6ZYO6qie6qq+6qze6q7+6rAe67I+67Re67Z+67ie6/yCD7xOELyOD77e6wPx6yxB7MMu7AJh7MmO DcMup/qLbOpijEqPcvnED9m/RmGlnYZXkpqMI0ueMniGoeleF0VT7XJiWcZK3Ea786u9jIp34ieR V0bp5ZP2fcliXjrZY+YBV2ppDwIHiOnmmw5ViVGWVyJQ55Zdwqnnnj+RiVOWW9q5gKB2Atplnnwm 54ug0/pmQYcNrX33gpXEekS0dmWOg36CiQr7t0cVhg6AEtJKuBB1LfzM5FprNMi5fMe+oD0qH8hb GpHlGq8Vjd+fYC41ZZlLJvK9Ci0DEufQdI754Jx/vrFgTZFdTDZ9/0NNrjI9WbPaZto2q9Oz+uLt V0bp5ZP2fcliXjrZY+YBV2ppDwIHiOnmmw5ViVGWVyJQ55Zdwqnnnj+RiVOWW9q5gKB2Atplnnwm yRdC0oJV0vK+RwwrxfpXBROoSe2a76ydMe40L3VtiE0T1DNVstUmlmW3Tt42PNkpjjfkw1jkpbTg ------=_NextPart_000_00ED_01C5271F.88D54DC0-- From owner-ccamp@ops.ietf.org Fri Aug 11 06:29:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBUGT-00012K-P5 for ccamp-archive@ietf.org; Fri, 11 Aug 2006 06:29:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBUGS-0005wp-9t for ccamp-archive@ietf.org; Fri, 11 Aug 2006 06:29:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GBUB6-000BAU-KT for ccamp-data@psg.com; Fri, 11 Aug 2006 10:23:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GBUB5-000B9y-Dj for ccamp@ops.ietf.org; Fri, 11 Aug 2006 10:23:43 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GBUBD-0007D2-00 for ccamp@ops.ietf.org; Fri, 11 Aug 2006 11:23:51 +0100 Received: from your029b8cecfe ([217.158.132.40] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 11:23:41 +0100 Message-ID: <036a01c6bd30$35423890$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Two new communications from the OIF Date: Fri, 11 Aug 2006 11:23:27 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 11 Aug 2006 10:23:41.0807 (UTC) FILETIME=[37C057F0:01C6BD30] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi, We have received two new communications from the OIF from their recent meeting and in response to our communications on the OIF E-NNI and on Ethernet traffic parameters. The latter asks a question of us, to which we need to respond. There appears to be no response to either of our communications on draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt and on 1:n protection. We still owe our thoughts on the OIF's interworking document so we should do four things: 1. Answer the Ethernet traffic parameters question 2. Poll to find out whether the OIF has any input on draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt, pointing out that the 01 revision is available 3. Poll on 1:n protection to see if we answered all of the questions satisfactorily 4. Send a response on OIF interworking As usual, input is welcome on the list or privately. Deborah and I will post draft text when we have it. I will post the two incoming communications at http://www.olddog.co.uk/incoming.htm Thanks, Adrian From owner-ccamp@ops.ietf.org Sat Aug 12 10:39:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBudz-0001l1-Da for ccamp-archive@ietf.org; Sat, 12 Aug 2006 10:39:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBudu-0006MH-Nz for ccamp-archive@ietf.org; Sat, 12 Aug 2006 10:39:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GBuSX-0009pp-Ng for ccamp-data@psg.com; Sat, 12 Aug 2006 14:27:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GBuSS-0009p4-9k for ccamp@ops.ietf.org; Sat, 12 Aug 2006 14:27:25 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GBuSM-0006sL-00 for ccamp@ops.ietf.org; Sat, 12 Aug 2006 15:27:19 +0100 Received: from your029b8cecfe ([217.158.132.104] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Aug 2006 15:27:08 +0100 Message-ID: <054801c6be1b$61333c60$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Brungard, Deborah A, ALABS" , "Dimitri Papadimitriou" Subject: Please publish draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt Date: Sat, 12 Aug 2006 15:26:16 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0545_01C6BE23.A76B2EB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 12 Aug 2006 14:27:09.0159 (UTC) FILETIME=[64D31F70:01C6BE1B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9dc1e69317bb70324fa4170d71d27661 This is a multi-part message in MIME format. ------=_NextPart_000_0545_01C6BE23.A76B2EB0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Please publish the attached I-D and notify the CCAMP mailing list. Thanks, Adrian ------=_NextPart_000_0545_01C6BE23.A76B2EB0 Content-Type: text/plain; format=flowed; name="draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt" CCAMP Working Group Editors Internet Draft D. Papadimitriou (Alcatel) Updates RFC 3473 A. Farrel (Old Dog Consulting) Proposed Category: Standard Track Expiration Date: February 2007 August 2006 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs). This document specifies how GMPLS RSVP-TE signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation. The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 1] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Table of Content 1. Conventions used in this document ............................. 3 2. Introduction .................................................. 3 2.1 Applicability to ASON ........................................ 4 3. Requirements .................................................. 4 3.1 Basic Call Function .......................................... 4 3.2 Call/Connection Separation ................................... 4 3.3 Call Segments ................................................ 5 4. Concepts and Terms ............................................ 5 4.1 What is a Call? .............................................. 5 4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs .......... 5 4.3 Exchanging Access Link Capabilities .......................... 6 4.3.1 Network-initiated Calls .................................... 7 4.3.2 User-initiated Calls ....................................... 7 4.3.3 Utilizing Call Setup ....................................... 7 5. Protocol Extensions for Calls and Connections ................. 8 5.1 Call Setup and Teardown ...................................... 8 5.2 Call Identification .......................................... 8 5.2.1 Long Form Call Identification .............................. 9 5.2.2 Short Form Call Identification ............................. 9 5.2.3 Short Form Call ID Encoding ................................ 9 5.3 LINK_CAPABILITY object ...................................... 10 5.4 Revised Message Formats ..................................... 11 5.4.1 Notify Message ............................................ 21 5.5 ADMIN_STATUS Object ......................................... 21 6. Procedures in Support of Calls and Connections ............... 32 6.1 Call/Connection Setup Procedures ............................ 32 6.2 Call Setup .................................................. 32 6.2.1 Accepting Call Setup ...................................... 54 6.2.2 Call Setup Failure and Rejection .......................... 65 6.3 Adding a Connections to a Call .............................. 65 6.3.1 Adding a Reverse Direction LSP to a Call .................. 76 6.4 Call-Free Connection Setup .................................. 76 6.5 Call Collision .............................................. 76 6.6 Call/Connection Teardown .................................... 87 6.6.1 Removal of a Connection from a Call ....................... 98 6.6.2 Removal of the Last Connection from a Call ................ 98 6.6.3 Teardown of an "Empty" Call ............................... 98 6.6.4 Attempted Teardown of a Call with Existing Connections .... 98 6.6.5 Teardown of a Call from the Egress ........................ 20 6.7 Control Plane Survivability ................................. 20 7. Applicability of Call and Connection Procedures .............. 21 7.1 Network-initiated Calls ..................................... 21 7.2 User-initiated Calls ........................................ 21 7.3 External Call Managers ...................................... 22 7.3.1 Call Segments ............................................. 22 8. Non-support of Call ID ....................................... 22 8.1 Non-Support by External Call Managers ....................... 23 8.2 Non-Support by Transit Node ................................. 23 draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 2] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 8.3 Non-Support by Egress Node .................................. 24 9. Security Considerations ...................................... 24 9.1 Call and Connection Security Considerations ................. 24 10. IANA Considerations ......................................... 25 10.1 RSVP Objects ............................................... 25 10.2 RSVP Error Codes and Error Values .......................... 25 10.3 RSVP ADMIN_STATUS object Bits .............................. 25 11. Acknowledgements ............................................ 26 12. References .................................................. 26 12.1 Normative References ....................................... 26 12.2 Informative References ..................................... 27 13. Authors' Addresses .......................................... 28 1. Conventions used in this document 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 [RFC2119]. In addition, the reader is assumed to be familiar with the terminology used in [RFC3471], [RFC3473], [RFC3477] and [RFC3945]. 2. Introduction This document defines protocol procedures and extensions to support Calls within Generalized MPLS (GMPLS). A Call is an association between endpoints and possibly between key transit points (such as network boundaries) in support of an instance of a service. The end-to-end association is termed a "Call," and the association between two transit points or between an endpoint and a transit point is termed a "Call Segment." An entity that processes a Call or Call Segment is called a "Call Manager." A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In GMPLS such Connections are known as Label Switched Paths (LSPs). A Call may be associated with zero, one, or more than one Connection, and a Connection may be associated with zero or one Call. Thus full and logical Call/Connection separation is needed. An example of the requirement for Calls can be found in the ITU-T's Automatically Switched Optical Network (ASON) architecture [G.8080] and specific requirements for support of Calls in this context can be found in [RFC4139]. Note, however, that while the mechanisms described in this document meet the requirements stated in [RFC4139], they have wider applicability. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 3] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 The mechanisms defined in this document are equally applicable to any packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable interfaces, LSC interfaces, or FSC interfaces. The mechanisms and protocol extensions are backward compatible, and can be used for Call management where only the Call Managers need to be aware of the protocol extensions. 2.1 Applicability to ASON [RFC4139] details the requirements on GMPLS signaling to satisfy the ASON architecture described in [G.8080]. The mechanisms described in this document meet the requirements for Calls as described in Sections 4.2 and 4.3 of [RFC4139] and the additional Call-related requirements in Sections 4.4, 4.7, 5 and 6 of [RFC4139]. [ASON-APPL] describes the applicability of GMPLS protocols to the ASON architecture. 3. Requirements 3.1 Basic Call Function The Call concept is used to deliver the following capabilities. - Verification and identification of the Call initiator (prior to LSP setup). - Support of virtual concatenation with diverse path component LSPs. - Association of multiple LSPs with a single Call (note aspects related to recovery are detailed in [RFC4426] and [GMPLS-E2E]). - Facilitation of control plane operations by allowing operational status change of the associated LSP. Procedures and protocol extensions to support Call setup, and the association of Calls with Connections are described in Section 5 and onwards of this document. 3.2 Call/Connection Separation Full and logical Call and Connection separation is required. That is: - It MUST be possible to establish a Connection without dependence on a Call. - It MUST be possible to establish a Call without any associated Connections. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 4] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 - It MUST be possible to associate more than one Connection with a Call. - Removal of the last Connection associated with a Call SHOULD NOT result in the automatic removal of the Call except as a matter of local policy at the ingress of the Call. - Signaling of a Connection associated with a Call MUST NOT require the distribution or retention of Call-related information (state) within the network. 3.3 Call Segments Call Segment capabilities MUST be supported. Procedures and (GMPLS) RSVP-TE signaling protocol extensions to support Call Segments are described in Section 7.3.1 of this document. 4. Concepts and Terms The concept of a Call and a Connection are also discussed in the ASON architecture [G.8080] and [RFC4139]. This section is not intended as a substitute for those documents, but is a brief summary of the key terms and concepts. 4.1 What is a Call? A Call is an agreement between endpoints possibly in cooperation with the nodes that provide access to the network. Call setup may include capability exchange, policy, authorization and security. A Call is used to facilitate and manage a set of Connections that provide end to end data services. While Connections require state to be maintained at nodes along the data path within the network, Calls do not involve the participation of transit nodes except to forward the Call management requests as transparent messages. A Call may be established and maintained independently of the Connections that it supports. 4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs Clearly there is a hierarchical relationship between Calls and Connections. One or more Connections may be associated with a Call. A Connection may not be part of more than one Call. A Connection may, however, exist without a Call. In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS TE Tunnel. Commonly a Tunnel is identified with a single LSP, but it draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 5] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 should be noted that for protection, load balancing and many other functions, a Tunnel may be supported by multiple parallel LSPs. The following identification reproduces this hierarchy. - Call IDs are unique within the context of the pair of addresses that are the source and destination of the Call. - Tunnel IDs are unique within the context of the Session (that is the destination of the Tunnel). Applications may also find it convenient to keep the Tunnel ID unique within the context of a Call. - LSP IDs are unique within the context of a Tunnel. Note that the Call_ID value of zero is reserved and MUST NOT be used during LSP-independent Call establishment. Throughout the remainder of this document, the terms LSP and Tunnel are used interchangeably with the term Connection. The case of a Tunnel that is supported by more than one LSP is covered implicitly. 4.3 Exchanging Access Link Capabilities In an overlay model, it is useful for the ingress node of an LSP to know the link capabilities of the link between the network and the remote overlay network. In the language of [RFC4208], the ingress node can make use of information about the link between the egress network node (NN) and the remote edge node (EN). We call this link the egress network link. This information may allow the ingress node to tailor its LSP request to fit those capabilities and to better utilize network resources with regard to those capabilities. For example, this might be used in transparent optical networks to supply information on lambda availability on egress network links, or, where the egress NN is capable of signal regeneration, it might provide a mechanism for negotiating signal quality attributes (such as bit error rate). Similarly, in multi-domain routing environments it could be used to provide end-to-end selection of component links (i.e., spatial attribute negotiation) where TE links have been bundled based on technology specific attributes. In some circumstances, the Traffic Engineering Database (TED) may contain sufficient information for decisions to be made about which egress network link to use. In other circumstances, the TED might not contain this information and Call setup may provide a suitable mechanism to exchange information for this purpose. The Call-responder may use the Call parameters to select a subset of the available egress network links between the egress NN and the remote EN, and may report these links and their capabilities on the Call response so that the Call-initiator may select a suitable link. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 6] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 The sections that follow indicate the cases where the TED may be used, and those where Call parameter exchange may be appropriate. 4.3.1 Network-initiated Calls In this case the ingress (and correspondingly the egress) lie within the network and there may be no need to distribute additional link capability information over and above the information distributed by the TE and GMPLS extensions to the IGP. Further, it is possible that future extensions to these IGPs will allow the distribution of more detailed information including optical impairments. 4.3.2 User-initiated Calls In this case the ingress (and correspondingly the egress) lie outside the network. Edge link information may not be visible within the core network, nor (and specifically) at other edge nodes. This may prevent an ingress from requesting suitable LSP characteristics to ensure successful LSP setup. Various solutions to this problem exist, including the definition of static TE links (that is, not advertised by a routing protocol) between the NNs and ENs. Nevertheless, special procedures may be necessary to advertise to the edge nodes outside of the network information about egress network links without also advertising the information specific to the contents of the network. In the future, when the requirements on the information that needs to be supported are better understood, TE extensions to EGPs may be defined that provide this function, and new rules for leaking TE information between routing instances may be used. 4.3.3 Utilizing Call Setup When IGP and EGP solutions are not available at the User-to-Network Interface (UNI), there is still a requirement to have, at the local edge nodes, the knowledge of the remote edge link capabilities. The Call setup procedure provides an opportunity to discover edge link capabilities of remote edge nodes before LSP setup is attempted. - The Call-responder can return information on one or more egress network links. The Call-reponder could return a full list of the available links with information about the link capabilities, or it could filter the list to return information about only those links which might be appropriate to support the Connections needed by the Call. To do this second option, the Call-responder must determine such appropriate links from information carried in the Call request including destination of the Call, and the level of service (bandwidth, protection, etc.) required. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 7] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 - On receiving a Call response, the Call-initiator must determine paths for the Connections (LSPs) that it will set up. The way that it does this is out of scope for this document since it is an implementation-specific, algorithmic process. However, it can take as input the information about the available egress network links as supplied in the Call response. The LINK_CAPABILITY object is defined to allow this information to be exchanged. The information that is included in this object is similar to that distributed by GMPLS-capable IGPs (see [RFC4202]). 5. Protocol Extensions for Calls and Connections This section describes the protocol extensions needed in support of Call identification and management of Calls and Connections. Procedures for the use of these protocol extensions are described in Section 6. 5.1 Call Setup and Teardown Calls are established independently of Connections through the use of the Notify message. The Notify message is a targeted message and does not follow the path of LSPs through the network. Simultaneous Call and Connection establishment (sometimes referred to as piggybacking) is not supported. 5.2 Call Identification As soon as the concept of a Call is introduced, it is necessary to support some means of identifying the Call. This becomes particularly important when Calls and Connections are separated and Connections must contain some reference to the Call. A Call may be identified by a sequence of bytes that may have considerable (but not arbitrary) length. A Call ID of 40 bytes would not be unreasonable. It is not the place of this document to supply rules for encoding or parsing Call IDs, but it must provide a suitable means to communicate Call IDs within the protocol. The full Call identification is referred to as the long Call ID. The Call_ID is only relevant at the sender and receiver nodes. Maintenance of this information in the signaling state is not mandated at any intermediate node. Thus no change in [RFC3473] transit implementations is required and there are no backward compatibility issues. Forward compatibility is maintained by using the existing default values to indicate that no Call processing is required. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 8] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Further, the long Call ID is not required as part of the Connection (LSP) state even at the sender and receiver nodes so long as some form of correlation is available. This correlation is provided through the short Call ID. 5.2.1 Long Form Call Identification The long Call ID is only required on the Notify message used to establish the Call. It is carried in the "Session Name" field of the SESSION_ATTRIBUTE Object on the Notify message. A unique value per Call is inserted in the "Session Name" field by the initiator of the Call. Subsequent network nodes MAY inspect this object and MUST forward this object transparently across network interfaces until reaching the egress node. Note that the structure of this field MAY be the object of further formatting depending on the naming convention(s). However, [RFC3209] defines the "Session Name" field as a Null padded display string, and that any formatting conventions for the Call ID must be limited to this scope. 5.2.2 Short Form Call Identification The Connections (LSPs) associated with a Call need to carry a reference to the Call - the short Call ID. A new field is added to the signaling protocol to identify an individual LSP with the Call to which it belongs. The new field is a 16-bit identifier (unique within the context of the address pairing provided by the Tunnel_End_Point_Address and the Sender_Address of the SENDER TEMPLATE object) that MUST be exchanged on the Notify message during Call initialization and is used on all subsequent LSP messages that are associated with the Call. This identifier is known as the short Call ID and is encoded as described in Section 5.2.3. The Call ID MUST NOT be used as part of the processing to determine the session to which an RSVP signaling message applies. This does not generate any backward compatibility issue since the reserved field of the SESSION object defined in [RFC3209] MUST NOT be examined on receipt. In the unlikely case of short Call_ID exhaustion, local node policy decides upon specific actions to be taken, but might include the use of second Sender_Address. Local policy details are outside of the scope of this document. 5.2.3 Short Form Call ID Encoding The short Call ID is carried in a 16-bit field in the SESSION object carried on the Notify message used during Call setup, and on all messages during LSP setup and management. The field used was previously reserved (MUST be set to zero on transmission and ignored draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 9] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 on receipt). This ensures backward compatibility with nodes that do not utilize Calls. The figure below shows the new version of the object. Class =3D SESSION, Class-Num =3D 1, C-Type =3D 7(IPv4)/8(IPv6) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv4/IPv6 Tunnel end point address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call_ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209]) Call_ID: 16 bits A 16-bit identifier used in the SESSION object that remains constant over the life of the Call. The Call_ID value MUST be set to zero when there is no corresponding Call. Tunnel ID: 16 bits (see [RFC3209]) Extended Tunnel ID: 32 bits/128 bits (see [RFC3209]) 5.3 LINK_CAPABILITY object The LINK_CAPABILITY object is introduced to support link capability exchange during Call setup and MAY be included in a Notify message used for Call setup. This optional object includes the link local capabilities of a link joining the Call-initiating node (or Call-terminating node) to the network. The specific node is indicated by the source address of the Notify message. The link reported can be a single link or can be a bundled link [RFC4201]. The Class Number is selected so that the nodes that do not recognize this object drop it silently. That is, the top bit is set and the next bit is clear. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 10] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 This object has the following format: Class-Num =3D TBA (form 10bbbbbb), C_Type =3D 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The contents of the LINK_CAPABILITY object is defined as series of variable-length data items called subobjects. The subobject format is defined in [RFC3209]. The following subobjects are currently defined. - Type 1: the link local IPv4 address of a link or a numbered bundle using the format defined in [RFC3209] - Type 2: the link local IPv6 address of a link or a numbered bundle using the format defined in [RFC3209] - Type 4: the link local identifier of an unnumbered link or bundle using the format defined in [RFC3477] - Type 64: the Maximum Reservable Bandwidth corresponding to this link or bundle (see [RFC4201]) - Type 65: the interface switching capability descriptor (see [RFC4202]) corresponding to this link or bundle (see also [RFC4201]). Note: future revisions of this document may extend the above list. A single instance of this object MAY be used to exchange capablity information relating to more than one link or bundled link. In this case, the following ordering MUST be used: - each link MUST be identified by an identifier subobject (Type 1, 2 or 4) - capability subobjects (Type 64 or 65, and future subobjects) MUST be placed after the identifier subobject for the link or bundle to which they refer. Mulitple instances of the LINK_CAPABILITY object within the same Notify message are not supported by this specification. In the event that a Notify message contains multiple LINK_CAPABILITY objects, the receiver SHOULD process the first one as normal and SHOULD ignore subsequent instances of the object. 5.4 Revised Message Formats The Notify message is enhanced to support Call establishment and teardown of Calls. See Section 6 for a description of the procedures. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 11] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 5.4.1 Notify Message The Notify message is modified in support of Call establishment by the optional addition of the LINK CAPABILTY object. Further, the SESSION ATTRIBUTE object is added to the sequence to carry the long Call ID. The presence of the SESSION ATTRIBUTE object MAY be used to distinguish a Notify message used for Call management, but see Section 5.5 for another mechanism. The MAY be used to simultaneously set up multiple Calls. The format of the Notify Message is as follows: ::=3D [ ] [[ | ]...] [ ] ::=3D [ ] ::=3D [ ] [ ...] [ ] [ ] [ | ] ::=3D see [RFC3473] ::=3D see [RFC3473] 5.5 ADMIN_STATUS Object Notify messages exchanged for Call control and management purposes carry a specific new bit (the Call Management or C bit) in the ADMIN STATUS object. [RFC3473] indicates that the format and contents of the ADMIN_STATUS object are as defined in [RFC3471]. The new "C" bit is added for Call control as shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved |C|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reflect (R): 1 bit - see [RFC3471] Testing (T): 1 bit - see [RFC3471] Administratively down (A): 1 bit - see [RFC3471] Deletion in progress (D): 1 bit - see [RFC3471] draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 12] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Call Management (C): 1 bit This bit is set when the message is being used to control and manage a Call. The procedures for the use of the C bit are described in Section 6. 6. Procedures in Support of Calls and Connections 6.1 Call/Connection Setup Procedures This section describes the processing steps for Call and Connection setup. There are three cases considered: - A Call is set up without any associated Connection. It is assumed that Connections will be added to the Call at a later time, but this is neither a requirement nor a constraint. - A Connection may be added to an existing Call. This may happen if the Call was set up without any associated Connections, or if another Connection is added to a Call that already has one or more associated Connections. - A Connection may be established without any reference to a Call (see Section 6.4). This encompasses the previous LSP setup procedure. Note that a Call MAY NOT be imposed upon a Connection that is already established. To do so would require changing the short Call ID in the SESSION OBJECT of the existing LSPs and this would constitute a change in the Session Identifier. This is not allowed by existing protocol specifications. Call and Connection teardown procedures are described later in Section 6.6. 6.2 Call Setup A Call is set up before, and independent of, LSP (i.e. Connection) setup. Call setup MAY necessitate verification of the link status and link capability negotiation between the Call ingress node and the Call egress node. The procedure described below is applied only once for a Call and hence only once for the set of LSPs associated with a Call. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 13] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 The Notify message (see [RFC3473]) is used to signal the Call setup request and response. The new Call Management (C) bit in the ADMIN_STATUS object is used to indicate that this Notify is managing a Call. The Notify message is sent with source and destination IPv4/IPv6 addresses set to any of the routable ingress/egress node addresses respectively. At least one session MUST be listed in the of the Notify message. In order to allow for long identification of the Call, the SESSION_ATTRIBUTE object is added as part of the . Note that the ERROR SPEC object is not relevant in Call setup and MUST carry the Error Code zero ("Confirmation") to indicate that there is no error. During Call setup, the ADMIN STATUS object is sent with the following bits set. Bits not listed MUST be set to zero. R - to cause the egress to respond C - to indicate that the Notify message is managing a Call. The SESSION, SESSION ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects included in the of the Notify message are built as follows. - The SESSION object includes as Tunnel_End_Point_Address any of the Call-terminating (egress) node's IPv4/IPv6 routable addresses. The Call_ID is set to a non-zero value unique within the context of the address pairing provided by the Tunnel_End_Point_Address and the Sender_Address from the SENDER TEMPLATE object (see below). This value will be used as the short Call ID carried on all messages for LSPs associated with this Call. Note that the Call_ID value of zero is reserved and MUST NOT be used since it will be present in SESSION objects of LSPs that are not associated with Calls. The Tunnel_ID of the SESSION object is not relevant for this procedure and SHOULD be set to zero. The Extended_Tunnel_ID of the SESSION object is not relevant for this procedure and MAY be set to zero or to an address of the ingress node. - The SESSION ATTRIBUTE object contains priority flags. Currently no use of these flags is envisioned, however, future work may identify value in assigning priorities to Calls; accordingly the Priority fields MAY be set to non-zero values. None of the Flags in the SESSION ATTRIBUTE object is relevant to this process and this field SHOULD be set to zero. The Session Name field is used to carry the long Call Id as described in Section 5. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 14] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 - The SENDER_TEMPLATE object includes as Sender Address any of the Call-initiating (ingress) node's IPv4/IPv6 routable addresses. The LSP_ID is not relevant and SHOULD be set to zero. - The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC objects MUST be ignored upon receipt and SHOULD be set to zero when sent. Additionally, ingress/egress nodes that need to communicate their respective link local capabilities may include a LINK_CAPABILITY object in the Notify message. The receiver of a Notify message may identify whether it is part of Call management or reporting an error by the presence or absence of the SESSION ATTRIUBTE object in the . Full clarity, however, may be achieved by inspection of the new Call Management (C) bit in the ADMIN STATUS object. Note that the POLICY_DATA object may be included in the and MAY be used to identify requestor credentials, account numbers, limits, quotas, etc. This object is opaque to RSVP, which simply passes it to policy control when required. Message IDs MUST be used during Call setup. 6.2.1 Accepting Call Setup A node that receives a Notify message carrying the ADMIN STATUS object with the R and C bits set is being requested to set up a Call. The receiver MAY perform authorization and policy according to local requirements. If the Call is acceptable, the receiver responds with a Notify message reflecting the information from the Call request with two exceptions. - The responder removes any LINK CAPABLITY object that was received and MAY insert a LINK_CAPABILITY object that describes its own access link. - The ADMIN STATUS object is sent with only the C bit set. All other bits MUST be set to zero. The responder MUST use the Message ID object to ensure reliable delivery of the response. If no Message ID Acknowledgement is received after the configured number of retries, the responder SHOULD continue to assume that the Call was successfully established. Call liveliness procedures are covered in Section 6.7. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 15] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 6.2.2 Call Setup Failure and Rejection Call setup may fail or be rejected. If the Notify message can not be delivered, no Message ID acknowledgement will be received by the sender. In the event that the sender has retransmitted the Notify message a configurable number of times without receiving a Message ID Acknowledgement (as described in [RFC2961]), the initiator SHOULD declare the Call failed and SHOULD send a Call teardown request (see Section 6.6). It is also possible that a Message ID Acknowledgement is received but no Call response Notify message is received. In this case, the initiator MAY re-send the Call setup request a configurable number of times (see Section 6.7) before declaring that the Call has failed. At this point the initiator MUST send a Call teardown request (see Section 6.6). If the Notify message cannot be parsed or is in error it MAY be responded to with a Notify message carrying the error code 13 ("Unknown object class") or 14 ("Unknown object C-Type") if appropriate to the error detected. The Call setup MAY be rejected by the receiver because of security, authorization or policy reasons. Suitable error codes already exist [RFC2205] and can be used in the ERROR SPEC object included in the Notify message sent in response. Error response Notify messages SHOULD also use the Message ID object to achieve reliable delivery. No action should be taken on the failure to receive a Message ID Acknowledgement after the configured number of retries. 6.3 Adding a Connections to a Call Once a Call has been established, LSPs can be added to the Call. Since the short Call ID is part of the SESSION Object, any LSP that has the same Call ID value in the SESSION Object belongs to the same Call, and the Notify message used to establish the Call carried the same Call ID in its SESSION object. There will be no confusion between LSPs that are associated with a Call and those which are not, since the Call ID value MUST be equal to zero for LSPs which are not associated with a Call, and MUST NOT be equal to zero for a valid Call ID. LSPs for different Calls can be distinguished because the Call ID is unique within the context of the source address (in the SENDER TEMPLATE object) and the destination address (in the SESSION object). draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 16] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Ingress and egress nodes MAY group together LSPs associated with the same Call and process them as a group according to implementation requirements. Transit nodes need not be aware of the association of multiple LSPs with the same Call. The ingress node MAY choose to set the "Session Name" of an LSP to match the long Call ID of the associated Call. The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages including on Notify messages that pertain to the LSP and MUST be ignored. 6.3.1 Adding a Reverse Direction LSP to a Call Note that once a Call has been established it is symmetric. That is, either end of the Call may add LSPs to the Call. Special care is needed when managing LSPs in the reverse direction since the addresses in the SESSION and SENDER TEMPLATE are reversed. However, since the short Call ID is unique in the context of a given ingress-egress address pair it may safely be used to associate the LSP with the Call. Note that since Calls are defined here to be symmetrical, the issue of potential Call ID collision arises. This is discussed in Section 6.5. 6.4 Call-Free Connection Setup It continues to be possible to set up LSPs as per [RFC3473] without associating them with a Call. If the short Call ID in the SESSION Object is set to zero, there is no associated Call and the Session Name field in the SESSION ATTRIBUTE object MUST be interpreted simply as the name of the session (see [RFC3209]). The C bit of the ADMIN STATUS object MUST NOT be set on messages for LSP control, including on Notify messages that pertain to LSPs, and MUST be ignored when received on such messages. 6.5 Call Collision Since Calls are symmetrical, it is possible that both ends of a Call will attempt to establish Calls with the same long Call IDs at the same time. This is only an issue if the source and destination address pairs match. This situation can be avoided by applying some rules to the contents of the long Call ID, but such mechanisms are outside the scope of this document. If a node that has sent a Call setup request and has not yet received a response, itself receives a Call setup request with the same long draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 17] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Call ID and matching source/destination addresses, it SHOULD process as follows. - If its source address is numerically greater than the remote source address, it MUST discard the received message and continue to wait for a response to its setup request. - If its source address is numerically smaller than the remote source address, it MUST discard state associated with the Call setup that it initiated, and MUST respond to the received Call setup. If a node receives a Call setup request carrying an address pair and long Call ID that match an existing Call, the node MUST return an error message (Notify message) with the new Error Code "Call Management" and the new Error Value "Duplicate Call" in response to the new Call request, and MUST NOT make any changes to the existing Call. A further possibility for contention arises when short Call IDs are assigned by a pair of nodes for two distinct Calls that are set up simultaneously using different long Call IDs. In this event a node receives a Call setup request carrying a short Call ID that matches one that it previously sent for the same address pair. The following processing MUST be followed. - If the receiver's source address is numerically greater than the remote source address, the receiver returns an error (Notify message) with the new Error Code "Call Management" and the new Error Value "Call ID Contention". - If the receiver's source address is numerically less than the remote source address, the receiver accepts and processes the Call request. It will receive an error message sent as described above, and at that point it selects a new short Call ID and re-sends the Call setup request. 6.6 Call/Connection Teardown As with Call/Connection setup, there are several cases to consider. - Removal of a Connection from a Call - Removal of the last Connection from a Call - Teardown of an "empty" Call The case of tearing down an LSP that is not associated with a Call does not need to be examined as it follows exactly the procedures described in [RFC3473]. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 18] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 6.6.1 Removal of a Connection from a Call An LSP that is associated with a Call may be deleted using the standard procedures described in [RFC3473]. No special procedures are required. Note that it is not possible to remove an LSP from a Call without deleting the LSP. It is not valid to change the short Call ID from non-zero to zero since this involves a change to the SESSION object, which is not allowed. 6.6.2 Removal of the Last Connection from a Call When the last LSP associated with a Call is deleted, the question arises as to what happens to the Call. Since a Call may exist independently of Connections, it is not always acceptable to say that the removal of the last LSP from a Call removes the Call. The removal of the last LSP does not remove the Call and the procedures described in the next Section MUST be used to delete the Call. 6.6.3 Teardown of an "Empty" Call When all LSPs have been removed from a Call, the Call may be torn down or left for use by future LSPs. Deletion of Calls is achieved by sending a Notify message just as for Call setup, but the ADMIN STATUS object carries the R, D and C bits on the teardown request and the D and C bits on the teardown response. Other bits MUST be set to zero. When a Notify message is sent for deleting a Call and the initiator does not receive the corresponding reflected Notify message (or possibly even the Message ID Ack), the initiator MAY retry the deletion request using the same retry procedures as used during Call establishment. If no response is received after full retry, the node deleting the Call MAY declare the Call deleted, but under such circumstances the node SHOULD avoid re-using the long or short Call IDs for at least five times the Notify refresh period. 6.6.4 Attempted Teardown of a Call with Existing Connections If a Notify request with the D bit of the ADMIN STATUS object set is received for a Call for which LSPs still exist, the request MUST be rejected with the Error Code "Call Management" and Error Value "Connections Still Exist". The state of the Call MUST NOT be changed. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 19] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 6.6.5 Teardown of a Call from the Egress Since Calls are symmetric they may be torn down from the ingress or egress. When the Call is "empty" (has no associated LSPs) it may be deleted by the egress sending a Notify message just as described above. Note that there is a possibility that both ends of a Call initiate Call deletion at the same time. In this case, the Notify message acting as teardown request MAY be interpreted by its recipient as a teardown response. But since the Notify messages acting as teardown requests carry the R bit in the ADMIN STATUS object, they MUST be responded to anyway. If a teardown request Notify message is received for an unknown Call ID, it is, nevertheless, responded to in the affirmative. 6.7 Control Plane Survivability Delivery of Notify messages is secured using message ID acknowledgements as described in previous sections. Notify messages provide end-to-end communication that does not rely on constant paths through the network. Notify messages are routed according to IGP routing information. No consideration is, therefore, required for network resilience (for example, make-before-break, protection, fast re-route), although end-to-end resilience is of interest for node restart and completely disjoint networks. Periodic Notify messages SHOULD be sent by the initiator and terminator of the Call to keep the Call alive and to handle ingress or egress node restart. The time period for these retransmissions is a local matter, but it is RECOMMENDED that this period should be twice the shortest refresh period of any LSP associated with the Call. When there are no LSPs associated with a Call, an LSR is RECOMMENDED to use a refresh period of no less than one minute. The Notify messages are identical to those sent as if establishing the Call for the first time, except for the LINK_CAPABILITY object, which may have changed since the Call was first established, due to, e.g., the establishment of Connections, link failures, or the addition of new component links. The current link information is useful for the establishment of subsequent Connections. A node that receives a refresh Notify message carrying the R bit in the ADMIN STATUS object MUST respond with a Notify response. A node that receives a refresh Notify message (response or request) MAY reset its timer - thus, in normal processing, Notify refreshes involve a single exchange once per time period. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 20] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 A node (sender or receiver) that is unsure of the status of a Call MAY immediately send a Notify message as if establishing the Call for the first time. Failure to receive a refresh Notify request has no specific meaning. A node that fails to receive a refresh Notify request MAY send its own refresh Notify request to establish the status of the Call. If a node receives no response to a refresh Notify request (including no Message ID Acknowledgement) a node MAY assume that the remote node is unreachable or unavailable. It is a local policy matter whether this causes the local node to teardown associated LSPs and delete the Call. In the event that an edge node restarts without preserved state, it MAY relearn LSP state from adjacent nodes and Call state from remote nodes. If a Path or Resv message is received with a non-zero Call ID but without the C bit in the ADMIN STATUS, and for a Call ID that is not recognized, the receiver is RECOMMENDED to assume that the Call establishment is delayed and ignore the received message. If the Call setup never materializes, the failure by the restarting node to refresh state will cause the LSPs to be torn down. Optionally, the receiver of such an LSP message for an unknown Call ID may return an error (PathErr or ResvErr message) with the error code "Call Management" and Error Value "Unknown Call ID". 7. Applicability of Call and Connection Procedures This section considers the applicability of the different Call establishment procedures at the NNI and UNI reference points. This section is informative and is not intended to prescribe or prevent other options. 7.1 Network-initiated Calls Since the link properties and other traffic-engineering attributes are likely known through the IGP, the LINK_CAPABILITY object is not usually required. In multi-domain networks, it is possible that access link properties and other traffic-engineering attributes are not known since the domains do not share this sort of information. In this case, the Call setup mechanism may include the LINK_CAPABILITY object. 7.2 User-initiated Calls It is possible that the access link properties and other traffic- engineering attributes are not shared across the core network. In this case, the Call setup mechanism may include the LINK_CAPABILITY object. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 21] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Further, the first node within the network may be responsible for managing the Call. In this case, the Notify message that is used to set up the Call is addressed by the user network edge node to the first node of the core network. Moreover, neither the long Call ID nor the short Call ID is supplied (the Session Name Length is set to zero and the Call ID value is set to zero). The Notify message is passed to the first network node which is responsible for generating the long and short Call IDs before dispatching the message to the remote Call end point (which is known from the SESSION object). Further, when used in an overlay context, the first core node is allowed (see [RFC4208]) to replace the Session Name assigned by the ingress node and passed in the Path message. In the case of Call management, the first network node: 1) MAY insert a long Call ID in the Session Name of a Path message 2) MUST replace the Session Name with that originally issued by the user edge node when it returns the Resv message to the ingress node. 7.3 External Call Managers Third party Call management agents may be used to apply policy and authorization at a point that is neither the initiator nor terminator of the Call. The previous example is a particular case of this, but the process and procedures are identical. 7.3.1 Call Segments Call Segments exist between a set of default and configured External Call Managers along a path between the ingress and egress nodes, and use the protocols described in this document. The techniques that are used by a given service provider to identify which External Call Managers within its network should process a given Call are beyond the scope of this document. An External Call Manager uses normal IP routing to route the Notify message to the next External Call Manager. Notify messages (requests and responses) are therefore encapsulated in IP packets that identify the sending and receiving External Call Managers, but the addresses used to identify the Call (the Sender Address in the SENDER TEMPLATE object and the Tunnel Endpoint Address in the SESSION object) continue to identify the endpoints of the Call. 8. Non-support of Call ID It is important that the procedures described above operate as seamlessly as possible with legacy nodes that do not support the extensions described. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 22] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Clearly, there is no need to consider the case where the Call initiator does not support Call setup initiation. 8.1 Non-Support by External Call Managers It is unlikely that a Call initiator will be configured to send Call establishment Notify requests to an external Call manager, including the first network node, if that node does not support Call setup. A node that receives an unexpected Call setup request will fall into one of the following categories. - Node does not support RSVP. The message will fail to be delivered or responded. No Message ID Acknowledgement will be sent. The initiator will retry and then give up. - Node supports RSVP or RSVP-TE but not GMPLS. The message will be delivered but not understood. It will be discarded. No Message ID Acknowledgement will be sent. The initiator will retry and then give up. - Node supports GMPLS but not Call management. The message will be delivered, but parsing will fail because of the presence of the SESSION ATTRIBUTE object. A Message ID Acknowledgement may be sent before the parse fails. When the parse fails the Notify message may be discarded in which case the initiator will retry and then give up, alternatively a parse error may be generated and returned in a Notify message which will indicate to the initiator that Call management is not supported. 8.2 Non-Support by Transit Node Transit nodes SHOULD not examine Notify messages that are not addressed to them. However, they will see short Call IDs in all LSPs associated with Calls. Previous specifications state that these fields SHOULD be ignored on receipt and MUST be transmitted as zero. This is interpreted by some implementations as meaning that the fields should be zeroed before the objects are forwarded. If this happens, LSP setup will not be possible. If either of the fields is zeroed either on the Path or the Resv message, the Resv message will reach the initiator with the field set to zero - this is indication to the initiator that some node in the network is preventing Call management. Use of Explicit Routes may help to mitigate this issue by avoiding such nodes. Ultimately, however, it may be necessary to upgrade the offending nodes to handle these protocol extensions. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 23] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 8.3 Non-Support by Egress Node It is unlikely that an attempt will be made to set up a Call to remote node that does not support Calls. If the egress node does not support Call management through the Notify message it will react (as described in Section 8.1) in the same way as an External Call Manager. 9. Security Considerations Please refer to each of the referenced documents for a description of the security considerations applicable to the features that they provide. 9.1 Call and Connection Security Considerations Call setup is vulnerable to attacks both of spoofing and denial of service. Since Call setup uses Notify messages, the process can be protected by the measures applicable to securing those messages as described in [RFC3473]. Note, additionally, that the process of independent Call establishment, where the Call is set up separately from the LSPs, may be used to apply an extra level of authentication and policy for the end-to-end LSPs above that which is available with Call-less, hop-by-hop LSP setup. It may be possible to protect the Call setup exchange using end-to-end security mechanisms such as those provided by IPsec (see [RFC2402] and [RFC2406]). The frequency of Call establishment is application dependent and hard to generalize. Key exchange for Call-related message exchanges is therefore something that should be configured or arranged dynamically in different deployments according to the advice in [RFC4107]. Note that the remote RSVP-TE signaling relationship between Call endpoints is no different from the signaling relationship between LSRs that establish an LSP. That is, the LSRs are not necessarily IP-adjacent in the control plane in either case. Thus key exchange should be regarded as a remote procedure, not a single hop procedure. There are several procedures for automatic remote exchange of keys, and IKE [RFC2409] is particularly suggested in [RFC3473]. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 24] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 10. IANA Considerations 10.1 RSVP Objects A new RSVP object is introduced: o LINK_CAPABILITY object Class-Num =3D TBA (form 10bbbbbb) The Class Number is selected so that nodes not recognizing this object drop it silently. That is, the top bit is set and the next bit is cleared. C-Type =3D 1 (TE Link Capabilities) The LINK_CAPABILITY object is only defined for inclusion on Notify messages. Refer to Section 5.3 of this document. 10.2 RSVP Error Codes and Error Values New RSVP Error Codes and Error Values are introduced o Error Codes: - Call Management (value TBA) o Error Values: - Call Management/Call ID Contention (value TBA) - Call Management/Connections still Exist (value TBA) - Call Management/Unknown Call ID (value TBA) - Call Management/Duplicate Call (value TBA) 10.3 RSVP ADMIN_STATUS object Bits [GMPLS-E2E] requests IANA to manage the bits of the RSVP ADMIN_STATUS object. One new bit, the C bit, is defined in this document. Bit number 28 is suggested. See Section 5.5 of this document. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 25] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 11. Acknowledgements The authors would like to thank George Swallow, Yakov Rekhter, Lou Berger, Jerry Ash and Kireeti Kompella for their very useful input to, and comments on, an earlier revision of this document. Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions during and after working group last call, and to Deborah Brungard for a final, detailed review. 12. References 12.1 Normative References [GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, "RSVP- TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery," draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in progress. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [RFC2205] R. Braden et al., "Resource ReSerVation Protocol (RSVP)- Version 1 Functional Specification," RFC 2205, September 1997. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header," RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Payload (ESP)," RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. [RFC3471] L. Berger (Editor) et al., "Generalized MPLS - Signaling Functional Description," RFC 3471, January 2003. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 26] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 [RFC3473] L. Berger (Editor) et al., "Generalized MPLS Signaling - RSVP-TE Extensions," RFC 3473, January 2003. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)," RFC 3477, January 2003. [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4139] D. Papadimitriou, et al., "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)," RFC 4139, July 2005. [RFC4201] Kompella K., Rekhter Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering," RFC 4201, October 2005. [RFC4202] Kompella, K. and Y. Rekhter (Editors) et al., "Routing Extensions in Support of Generalized MPLS," RFC 4202, October 2005. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [RFC4426] Lang, J.P., and B. Rajagopalan (Editors) et al., "Generalized MPLS Recovery Functional Specification," RFC 4426, March 2006. 12.2 Informative References [ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS) RSVP-TE signaling usage in support of Automatically Switched Optical Network (ASON)," draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress. [RFC4107] S. Bellovin and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. For information on the availability of the following document, please see http://www.itu.int. [G.8080] ITU-T, "Architecture for the Automatically Switched Optical Network (ASON)," Recommendation G.8080/ Y.1304, November 2001 (and Revision, January 2003). draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 27] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 13. Authors' Addresses Dimitri Papadimitriou (Alcatel) Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245 EMail: John.E.Drake2@boeing.com Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com Zafar Ali (Cisco) 100 South Main St. #200 Ann Arbor, MI 48104, USA EMail: zali@cisco.com Arthi Ayyangar (Nuova Systems) 2600 San Tomas Expressway Santa Clara, CA 95051 EMail: arthi@nuovasystems.com Don Fedyk (Nortel Networks) 600 Technology Park Drive Billerica, MA, 01821, USA Email: dwfedyk@nortel.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 28] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 29] =0C ------=_NextPart_000_0545_01C6BE23.A76B2EB0-- From owner-ccamp@ops.ietf.org Sat Aug 12 11:05:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBv2x-0004TM-5e for ccamp-archive@ietf.org; Sat, 12 Aug 2006 11:05:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBv2v-0008TX-NI for ccamp-archive@ietf.org; Sat, 12 Aug 2006 11:05:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GBuzW-000Cff-Gy for ccamp-data@psg.com; Sat, 12 Aug 2006 15:01:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GBuzV-000CfS-TB for ccamp@ops.ietf.org; Sat, 12 Aug 2006 15:01:34 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GBuzk-0000cB-00 for ccamp@ops.ietf.org; Sat, 12 Aug 2006 16:01:48 +0100 Received: from your029b8cecfe ([217.158.132.27] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Aug 2006 16:01:31 +0100 Message-ID: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Polling for new WG I-Ds Date: Sat, 12 Aug 2006 15:56:02 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 12 Aug 2006 15:01:31.0858 (UTC) FILETIME=[324A0320:01C6BE20] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi, As discussed in Montreal, we need to poll for a couple of new WG drafts. http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt has been updated by the authors to provide further details and clarification. http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt has been updated since the version discussed in Montreal. http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt has been updated as Zafar says in his previous email. Please send yes or no for these I-Ds. Reasons and opinions are also welcomed. Thanks, Adrian From owner-ccamp@ops.ietf.org Sat Aug 12 11:06:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBv3q-0005Gv-NB for ccamp-archive@ietf.org; Sat, 12 Aug 2006 11:06:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBv3q-00006V-0N for ccamp-archive@ietf.org; Sat, 12 Aug 2006 11:06:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GBuzN-000CdJ-3k for ccamp-data@psg.com; Sat, 12 Aug 2006 15:01:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GBuzK-000Cd4-Po for ccamp@ops.ietf.org; Sat, 12 Aug 2006 15:01:23 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GBuzY-0000aZ-00 for ccamp@ops.ietf.org; Sat, 12 Aug 2006 16:01:36 +0100 Received: from your029b8cecfe ([217.158.132.27] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Aug 2006 16:01:14 +0100 Message-ID: <056a01c6be20$21380c30$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Updated version of draft-ietf-ccamp-gmpls-rsvp-te-call Date: Sat, 12 Aug 2006 15:37:39 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 12 Aug 2006 15:01:15.0483 (UTC) FILETIME=[288762B0:01C6BE20] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc Hi, We have just submitted an updated version of draft-ietf-ccamp-gmpls-rsvp-te-call. These changes result from: - WG chair review by Deborah - extensive post WG last call discussions on the CCAMP list. Note that we polled the MPLS WG via the mailing list on the use of the previously reserved bits in the Session object and received no comments. Changes are: == Throughout... Minor punctuation changes == Throughout s/LINK CAPABILITY/LINK_CAPABILITY/ == Abstract s/connection/Connection/ (twice) == Section 2 s/connection/Connection/ (four times) == Section 2 OLD A Call may be associated with zero, one more Connections, NEW A Call may be associated with zero, one, or more than one Connection, == Section 4.2 Use period not colon before list. == Section 3.3 s/Call Segments capabilities/Call Segment capabilities/ == Section 4.3 OLD It is useful for the ingress node of an LSP to know the link capabilities of the link between the network and the egress node. This information may allow the ingress node to tailor its LSP request to fit those capabilities and to better utilize network resources with regard to those capabilities. In particular, this may be used to achieve end-to-end spectral routing attribute negotiation for signal quality negotiation (such as BER) in photonic environments where network edges are signal regeneration capable. Similarly, it may be used to provide end-to-end spatial routing attribute negotiation in multi-area routing environments, in particular, when TE links have been bundled based on technology specific attributes. Call setup may provide a suitable mechanism to exchange information for this purpose, although several other possibilities exist. NEW In an overlay model, it is useful for the ingress node of an LSP to know the link capabilities of the link between the network and the remote overlay network. In the language of [RFC4208], the ingress node can make use of information about the link between the egress network node (NN) and the remote edge node (EN). We call this link the egress network link. This information may allow the ingress node to tailor its LSP request to fit those capabilities and to better utilize network resources with regard to those capabilities. For example, this might be used in transparent optical networks to supply information on lambda availability on egress network links, or, where the egress NN is capable of signal regeneration, it might provide a mechanism for negotiating signal quality attributes (such as bit error rate). Similarly, in multi-domain routing environments it could be used to provide end-to-end selection of component links (i.e., spatial attribute negotiation) where TE links have been bundled based on technology specific attributes. In some circumstances, the Traffic Engineering Database (TED) may contain sufficient information for decisions to be made about which egress network link to use. In other circumstances, the TED might not contain this information and Call setup may provide a suitable mechanism to exchange information for this purpose. The Call-responder may use the Call parameters to select a subset of the available egress network links between the egress NN and the remote EN, and may report these links and their capabilities on the Call response so that the Call-initiator may select a suitable link. The sections that follow indicate the cases where the TED may be used, and those where Call parameter exchange may be appropriate. == Section 4.3.1 OLD In this case, there may be no need to distribute additional link capability information over and above the information distributed by the TE and GMPLS extensions to the IGP. Further, it is possible that future extensions to these IGPs will allow the distribution of more detailed information including optical impairments. NEW In this case the ingress (and correspondingly the egress) lie within the network and there may be no need to distribute additional link capability information over and above the information distributed by the TE and GMPLS extensions to the IGP. Further, it is possible that future extensions to these IGPs will allow the distribution of more detailed information including optical impairments. == Section 4.3.2 OLD In this case, edge link information may not be visible within the core network, nor (and specifically) at other edge nodes. This may prevent an ingress from requesting suitable LSP characteristics to ensure successful LSP setup. Various solutions to this problem exist including the definition of static TE links (that is, not advertised by a routing protocol) between the core network and the edge nodes. Nevertheless, special procedures may be necessary to advertise edge TE link information to the edge nodes outside of the network without advertising the information specific to the contents of the network. In the future, when the requirements are understood on the information that needs to be supported, TE extensions to EGPs may be defined that provide this function. NEW In this case the ingress (and correspondingly the egress) lie outside the network. Edge link information may not be visible within the core network, nor (and specifically) at other edge nodes. This may prevent an ingress from requesting suitable LSP characteristics to ensure successful LSP setup. Various solutions to this problem exist, including the definition of static TE links (that is, not advertised by a routing protocol) between the NNs and ENs. Nevertheless, special procedures may be necessary to advertise to the edge nodes outside of the network information about egress network links without also advertising the information specific to the contents of the network. In the future, when the requirements on the information that needs to be supported are better understood, TE extensions to EGPs may be defined that provide this function, and new rules for leaking TE information between routing instances may be used. == Section 4.3.3 OLD When IGP and EGP solutions are not available at the UNI, there is still a requirement to have, at the local edge nodes, the knowledge of the remote edge link capabilities. The Call setup procedure provides an opportunity to discover edge link capabilities of remote edge nodes before LSP setup is attempted. The LINK CAPABILITY object is defined to allow this information to be exchanged. The information that is included in this object is similar to that distributed by GMPLS-capable IGPs (see [RFC4202]). NEW When IGP and EGP solutions are not available at the User-to-Network Interface (UNI), there is still a requirement to have, at the local edge nodes, the knowledge of the remote edge link capabilities. The Call setup procedure provides an opportunity to discover edge link capabilities of remote edge nodes before LSP setup is attempted. - The Call-responder can return information on one or more egress network links. The Call-reponder could return a full list of the available links with information about the link capabilities, or it could filter the list to return information about only those links which might be appropriate to support the Connections needed by the Call. To do this second option, the Call-responder must determine such appropriate links from information carried in the Call request including destination of the Call, and the level of service (bandwidth, protection, etc.) required. - On receiving a Call response, the Call-initiator must determine paths for the Connections (LSPs) that it will set up. The way that it does this is out of scope for this document since it is an implementation-specific, algorithmic process. However, it can take as input the information about the available egress network links as supplied in the Call response. The LINK_CAPABILITY object is defined to allow this information to be exchanged. The information that is included in this object is similar to that distributed by GMPLS-capable IGPs (see [RFC4202]). == Section 5.1 s/connection/Connection/ (twice) == Section 5.2 s/connection/Connection/ (three times) == Section 5.2.2 s/connection/Connection/ == Section 5.3 Use period not colon before list. == Section 5.3 OLD The LINK CAPABILITY object is introduced to support link capability exchange during Call setup and MAY be included in a Notify message used for Call setup. This optional object includes the bundled link local capabilities of the Call initiating node (or terminating node) indicated by the source address of the Notify message. NEW The LINK_CAPABILITY object is introduced to support link capability exchange during Call setup and MAY be included in a Notify message used for Call setup. This optional object includes the link local capabilities of a link joining the Call-initiating node (or Call-terminating node) to the network. The specific node is indicated by the source address of the Notify message. The link reported can be a single link or can be a bundled link [RFC4201]. == Section 5.3 OLD - Type 1: the link local IPv4 address (numbered bundle) using the format defined in [RFC3209] - Type 2: the link local IPv6 address (numbered bundle) using the format defined in [RFC3209] - Type 4: the link local identifier (unnumbered links and bundles) using the format defined in [RFC3477] - Type 64: the Maximum Reservable Bandwidth corresponding to this bundle (see [RFC4201]) - Type 65: the interface switching capability descriptor (see [RFC4202]) corresponding to this bundle (see also [RFC4201]). NEW - Type 1: the link local IPv4 address of a link or a numbered bundle using the format defined in [RFC3209] - Type 2: the link local IPv6 address of a link or a numbered bundle using the format defined in [RFC3209] - Type 4: the link local identifier of an unnumbered link or bundle using the format defined in [RFC3477] - Type 64: the Maximum Reservable Bandwidth corresponding to this link or bundle (see [RFC4201]) - Type 65: the interface switching capability descriptor (see [RFC4202]) corresponding to this link or bundle (see also [RFC4201]). == Section 5.3 OLD This object MAY also be used to exchange more than one bundled link capability. In this case, the following ordering MUST be followed: one identifier subobject (Type 1, 2 or 4) MUST be inserted before any capability subobject (Type 64 or 65) to which it refers. NEW A single instance of this object MAY be used to exchange capability information relating to more than one link or bundled link. In this case, the following ordering MUST be used: - each link MUST be identified by an identifier subobject (Type 1, 2 or 4) - capability subobjects (Type 64 or 65, and future subobjects) MUST be placed after the identifier subobject for the link or bundle to which they refer. Multiple instances of the LINK_CAPABILITY object within the same Notify message are not supported by this specification. In the event that a Notify message contains multiple LINK_CAPABILITY objects, the receiver SHOULD process the first one as normal and SHOULD ignore subsequent instances of the object. == Section 5.4.1 s/ATTIBUTE/ATTRIBUTE/ == Section 5.5 OLD The format and the contents of the ADMIN_STATUS object are both dictated by [RFC3473] in favor of [RFC3471]. The new "C" bit is added as shown below. NEW [RFC3473] indicates that the format and contents of the ADMIN_STATUS object are as defined in [RFC3471]. The new "C" bit is added for Call control as shown below. == Section 6.1 s/connection/Connection/ == Section 6.1 bullet two s/a further Connection/another Connection/ == Section 6.2 Use period not colon before list. == Section 6.2 bullet one s/call terminating/Call-terminating/ == Section 6.2 bullet two s/value is assigning/value in assigning/ == Section 6.2 bullet three s/call initiating/Call-initiating/ == Section 6.6.1 s/RFC3743/RFC3473/ == Section 6.6.3 3rd para Alignment fixed s/at least the five/at least five/ == Section 6.7 s/call/Call/ s/connection/Connection/ (twice) s/link failures, and the addition/link failures, or the addition/ == Section 7.3.1 s/call/Call/ == Section 9.1 OLD Note, additionally, that the process of Call establishment independent of LSP setup may be used to apply an extra level of authentication and policy to hop-by-hop LSP setup. NEW Note, additionally, that the process of independent Call establishment, where the Call is set up separately from the LSPs, may be used to apply an extra level of authentication and policy for the end-to-end LSPs above that which is available with Call-less, hop-by-hop LSP setup. == Section 9.1 s/Insect/IPsec/ == Section 9.1 ADD The frequency of Call establishment is application dependent and hard to generalize. Key exchange for Call-related message exchanges is therefore something that should be configured or arranged dynamically in different deployments according to the advice in [RFC4107]. Note that the remote RSVP-TE signaling relationship between Call endpoints is no different from the signaling relationship between LSRs that establish an LSP. That is, the LSRs are not necessarily IP-adjacent in the control plane in either case. Thus key exchange should be regarded as a remote procedure, not a single hop procedure. There are several procedures for automatic remote exchange of keys, and IKE [RFC2409] is particularly suggested in [RFC3473]. == Section 11. Updated acknowledgements == Section 12.1 Added RFC 2709 == Section 12.2 Added RFC 4107 == Section 13 Updated Arthi's coordinates == Regards, Adrian and Dimitri From owner-ccamp@ops.ietf.org Sun Aug 13 00:35:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC7hF-0005c8-T7 for ccamp-archive@ietf.org; Sun, 13 Aug 2006 00:35:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GC7hE-000720-Jb for ccamp-archive@ietf.org; Sun, 13 Aug 2006 00:35:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GC7cL-000GqP-57 for ccamp-data@psg.com; Sun, 13 Aug 2006 04:30:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [210.141.112.39] (helo=UTMC1102.kddi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GC7cJ-000Gq8-TC for ccamp@ops.ietf.org; Sun, 13 Aug 2006 04:30:28 +0000 Received: from usjk1038 (unknown [10.5.16.70]) by UTMC1102.kddi.com (Postfix) with SMTP id 01EA423BD for ; Sun, 13 Aug 2006 13:30:26 +0900 (JST) Received: from UTMC1123.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id BD0C81BCD for ; Sun, 13 Aug 2006 13:30:22 +0900 (JST) Received: from UTMC1112.kddi.com (unknown [10.5.16.9]) by UTMC1123.kddi.com (Postfix) with ESMTP id A1A281BC8 for ; Sun, 13 Aug 2006 13:30:22 +0900 (JST) Received: from [127.0.0.1] ([133.128.75.150] [133.128.75.150]) by post-ims.kddi.com with ESMTP; Sun, 13 Aug 2006 13:30:22 +0900 Date: Sun, 13 Aug 2006 13:30:22 +0900 From: Kenji Kumaki To: ccamp@ops.ietf.org Subject: Re: Montreal draft minutes posted In-Reply-To: <08e301c6b58a$b456cea0$0a23fea9@your029b8cecfe> References: <08e301c6b58a$b456cea0$0a23fea9@your029b8cecfe> Message-Id: <20060813132909.1B2D.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-WAuditID: 0608131330220000118251 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi, I believe that ccamper give me some comments. >Deborah: Should make any comments during the next few weeks on the list and do a respin. Thanks, Kenji On Tue, 1 Aug 2006 17:50:47 +0100 "Adrian Farrel" wrote: > http://www3.ietf.org/proceedings/06jul/minutes/ccamp.htm > > Please review. > > Apologies for the delay which is all my fault. > > Thanks to the note takers and to Deborah for compiling the minutes. > > Adrian > -- Kenji Kumaki From shu@yahoo.co.jp Sun Aug 13 12:46:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCJ6G-0006A2-9K for ccamp-archive@ietf.org; Sun, 13 Aug 2006 12:46:08 -0400 Received: from [221.200.232.15] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GCJ6E-0007YG-QB for ccamp-archive@ietf.org; Sun, 13 Aug 2006 12:46:08 -0400 To: From: =?iso-2022-jp?B?GyRCMEtGIxsoQg==?= Subject: =?iso-2022-jp?B?GyRCMkYhIiQkJCskLCQqMmEkNCQ3JEckOSQrISkbKEI=?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 $B2F$N%A%'%C%/%]%$%s%H>pJs$r%3%3$G%2%C%H(B http://110012.com/enter/ From owner-ccamp@ops.ietf.org Mon Aug 14 13:12:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCfz8-0006Mb-Fc for ccamp-archive@ietf.org; Mon, 14 Aug 2006 13:12:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCfz5-0002YW-5F for ccamp-archive@ietf.org; Mon, 14 Aug 2006 13:12:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCfq1-000Lyx-4n for ccamp-data@psg.com; Mon, 14 Aug 2006 17:02:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCfq0-000Lyj-I8 for ccamp@ops.ietf.org; Mon, 14 Aug 2006 17:02:52 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7EH2jIW010532; Mon, 14 Aug 2006 10:02:45 -0700 (PDT) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7EH2Rvr010325; Mon, 14 Aug 2006 10:02:37 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7EH2QOc026050; Mon, 14 Aug 2006 10:02:26 -0700 (PDT) Received: from [133.164.59.80] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k7EH2Pw03957; Mon, 14 Aug 2006 10:02:25 -0700 (PDT) Message-ID: <44E0AC9C.3010509@us.fujitsu.com> Date: Mon, 14 Aug 2006 10:02:20 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds References: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> In-Reply-To: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a yes to all btw, draft-caviglia-ccamp-pc-and-sc-reqs-02.txt is now http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-03.txt Richard -- Adrian Farrel wrote: > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > From owner-ccamp@ops.ietf.org Mon Aug 14 15:54:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCiVk-0004Xm-GB for ccamp-archive@ietf.org; Mon, 14 Aug 2006 15:54:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCiVj-0000Vq-3N for ccamp-archive@ietf.org; Mon, 14 Aug 2006 15:54:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCiRo-0008SJ-7I for ccamp-data@psg.com; Mon, 14 Aug 2006 19:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCiRn-0008Rn-8O for ccamp@ops.ietf.org; Mon, 14 Aug 2006 19:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5BED1327BB; Mon, 14 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GCiRm-0006Qy-7f; Mon, 14 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt Message-Id: Date: Mon, 14 Aug 2006 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --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 : Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls Author(s) : D. Papadimitriou, A. Farrel Filename : draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt Pages : 29 Date : 2006-8-14 In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs). This document specifies how GMPLS RSVP-TE signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation. The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-14112441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-14112441.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Aug 14 17:14:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCjlV-0003km-LN for ccamp-archive@ietf.org; Mon, 14 Aug 2006 17:14:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCjlU-0002Js-6j for ccamp-archive@ietf.org; Mon, 14 Aug 2006 17:14:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCjfi-000Dr4-H8 for ccamp-data@psg.com; Mon, 14 Aug 2006 21:08:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,HTML_90_100, HTML_MESSAGE,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [205.177.121.2] (helo=ns1.cpanel.btnaccess.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCjfg-000Dql-ON for ccamp@ops.ietf.org; Mon, 14 Aug 2006 21:08:29 +0000 Received: from [65.213.193.40] (helo=admin0hg5amcej) by ns1.cpanel.btnaccess.com with esmtpa (Exim 4.52) id 1GCjfe-0005vr-0s for ccamp@ops.ietf.org; Mon, 14 Aug 2006 17:08:26 -0400 From: "Stephanie Pruitt" To: Subject: CFP-MPLS 2006 International Conference, Oct 15-18 2006 Date: Mon, 14 Aug 2006 17:08:23 -0400 Message-ID: <002c01c6bfe5$c74f0b20$28c1d541@admin0hg5amcej> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C6BFC4.403D6B20" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: Aca/5cbTpuI8ue7NS5KO9ZL/Qqpq2A== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C6BFC4.403D6B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Early bird registration ends soon! Register for MPLS 2006 International Conference Today! OCTOBER 15-18, 2006 Omni Shoreham Hotel WASHINGTON, D.C. 9th Annual International Conference on MPLS and Related Technologies To register: Click here: http://www.mpls2006.com/onlineregis.htm Conference Program: http://www.isocore.com/mpls2006/program.htm Conference Hotel Information: To reserve your room at the hotel, please visit: http://www.mpls2006.com/hotel.htm Stephanie Pruitt MPLS 2006 12359 Sunrise Valley Drive, Suite 100 Reston, VA 20191 Office: (703) 860-1777 Fax: (703) 860-1778 ------=_NextPart_000_002D_01C6BFC4.403D6B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Early bird registration ends = soon!

Register for MPLS 2006 International Conference = Today!

OCTOBER 15-18, 2006
Omni Shoreham Hotel
WASHINGTON, = D.C.
9th Annual International Conference on MPLS and Related = Technologies

 <= /span>

To register:
Click = here: http://www.mpls2006.com= /onlineregis.htm

 

Conference = Program:

http://www.isocore.= com/mpls2006/program.htm

 

Conference Hotel Information:

To reserve your room at the hotel, please = visit:

http://www.mpls2006.com/hotel= .htm

 

 

Stephanie Pruitt

MPLS = 2006

12359 Sunrise Valley Drive, = Suite = 100

Reston, VA 20191=

Office: (703) 860-1777

Fax: = (703) 860-1778

 

------=_NextPart_000_002D_01C6BFC4.403D6B20-- From proclaimers@victoriamri.com Mon Aug 14 17:37:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCk7T-0002pz-0Q for ccamp-archive@ietf.org; Mon, 14 Aug 2006 17:37:11 -0400 Received: from [210.213.127.124] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GCk7O-0004Dt-9d for ccamp-archive@ietf.org; Mon, 14 Aug 2006 17:37:10 -0400 Message-ID: <000001c6bfe8$af3d8400$0100007f@localhost> From: "Emma Cunningham" To: Subject: August Payment Summary, Invoice #99443 Date: Mon, 15 Aug 1988 05:46:02 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C6BFE8.AF3D8400" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 8949cc4fd406a34204d26327803246d1 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6BFE8.AF3D8400 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000E_01C6BFE8.AF3D8400" ------=_NextPart_001_000E_01C6BFE8.AF3D8400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Vendor Invoice attached ------=_NextPart_000_0001_01C6BFE8.AF3D8400 Content-Type: application/msword; name="invoice.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="invoice.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAANwAAAAAA AAAAEAAANQAAAAEAAAD+////AAAAADgAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcWAJBAAA+BK/AAAAAAAAEAAAAAAABgAA 0goAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAAAAAJBBYALhwAABM6AQATOgEA0gIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAJIEAAAAAAAAkgQAAJIEAAAAAAAAkgQAAAAAAACSBAAA AAAAAJIEAAAAAAAAkgQAABQAAAAAAAAAAAAAAMwEAAAkAgAA2AsAAAAAAADYCwAAAAAAANgL AAAAAAAA2AsAABwAAAD0CwAAJAAAAPAGAAAAAAAACREAAFoBAAAkDAAAKAAAAEwMAAAAAAAA TAwAAAAAAABMDAAAAAAAAEwMAAAAAAAAJw0AAAAAAAAnDQAAAAAAACcNAAAAAAAAiBAAAAIA AACKEAAAAAAAAIoQAAAAAAAAihAAAAAAAACKEAAAAAAAAIoQAAAAAAAAihAAACQAAABjEgAA aAIAAMsUAACGAAAArhAAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgQAAAAAAAA6DwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAnDQAAAAAAACcNAAAAAAAAOg8AAAAAAAA6DwAAAAAAAK4QAAAAAAAA AAAAAAAAAACSBAAAAAAAAJIEAAAAAAAATAwAAAAAAAAAAAAAAAAAAEwMAADbAAAAwxAAABYA AAC8DwAAAAAAALwPAAAAAAAAvA8AAAAAAAA6DwAAFgAAAJIEAAAAAAAATAwAAAAAAACSBAAA AAAAAEwMAAAAAAAAiBAAAAAAAAAAAAAAAAAAALwPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOg8AAAAAAACIEAAAAAAAAAAAAAAAAAAA vA8AAAAAAAAAAAAAAAAAALwPAAAAAAAAkgQAAAAAAACSBAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvA8AAAAAAABMDAAA AAAAABgMAAAMAAAAIJOI8uu4xgEAAAAAAAAAANgLAAAAAAAAUA8AAAoAAAC8DwAAAAAAAAAA AAAAAAAALBAAAFwAAADZEAAAMAAAAAkRAAAAAAAAvA8AAAAAAABRFQAAAAAAAFoPAABYAAAA URUAAAAAAAC8DwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFEVAAAAAAAAAAAAAAAAAACSBAAA AAAAALwPAABwAAAAJw0AAJIAAAC5DQAAaAAAALwPAAAAAAAAIQ4AAFQAAAB1DgAAxQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJw0AAAAAAAAnDQAAAAAAACcNAAAAAAAA rhAAAAAAAACuEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsg8AAAoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcNAAAAAAAAJw0AAAAAAAAnDQAA AAAAAAkRAAAAAAAAOg8AAAAAAAA6DwAAAAAAADoPAAAAAAAAOg8AAAAAAAAAAAAAAAAAAPAG AAAAAAAA8AYAAAAAAADwBgAAZAQAAFQLAACEAAAA8AYAAAAAAADwBgAAAAAAAPAGAAAAAAAA VAsAAAAAAACmBAAAFAAAALoEAAAOAAAAyAQAAAQAAACSBAAAAAAAAJIEAAAAAAAAkgQAAAAA AACSBAAAAAAAAJIEAAAAAAAAkgQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEJhY2syU2Nob29sIFNvZnR3YXJlIEJsb3dvdXQgU2Fs ZSEHBw1TdG9wIG92ZXJwYXlpbmcgZm9yIHNvZnR3YXJlLg1CdXkgT0VNIFNvZnR3YXJlIHRv ZGF5LCBEb3dubG9hZCBJTlNUQU5UTFkgJg0TIEhZUEVSTElOSyAiaHR0cDovL3RlbW5pZXBy b2dpLmNvbSIgARRTYXZlIE92ZXIgODUlIRUNTWljcm9zb2Z0IE9mZmljZSAyMDAzIFByb2Zl c3Npb25hbA13L0NvbnRhY3QgTWFuYWdlcg0NV2luZG93cyBYUCBQcm9mZXNzaW9uYWwNSW5j bHVkZXMgU2VydmljZSBQYWNrIDENDUFkb2JlIFBob3Rvc2hvcCBDUzIgdiA5LjANIzEgUmF0 ZWQgUGhvdG8gRWRpdGluZyBzb2Z0d2FyZQ0NQWRvYmUgQWNyb2JhdCBQcm9mZXNzaW9uYWwg diA3LjANRXNzZW50aWFsIGZvciBXZWIgRG9jdW1lbnRzDQ1SZXRhaWwgUHJpY2UgQCBTdGFw bGVzOiAkNTQ5Ljk1DUV4Y2x1c2l2ZSBTYWxlIFByaWNlOiAkNjkuOTUNDVJldGFpbCBQcmlj ZSBAIFN0YXBsZXM6ICQyNDkuOTUNRXhjbHVzaXZlIFNhbGUgUHJpY2U6ICQ0OS45NQ0NUmV0 YWlsIFByaWNlIEAgU3RhcGxlczogJDU5OS45NQ1FeGNsdXNpdmUgU2FsZSBQcmljZTogJDY5 Ljk1DQ1SZXRhaWwgUHJpY2UgQCBTdGFwbGVzOiAkNDQ5Ljk1DUV4Y2x1c2l2ZSBTYWxlIFBy aWNlOiAkNjkuOTUNDQcHEyBIWVBFUkxJTksgImh0dHA6Ly90ZW1uaWVwcm9naS5jb20iIAEU VmlzaXQgb3VyIFdlYnNpdGUgYW5kIGdldCB5b3VycyB0b2RheSEVBwcNAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAIggAACMIAAAkCAAAJQgAAHAIAABxCAAAlQgAAJYI AACXCAAApQgAAKYIAACnCAAAhgkAAPHi3tHBppByplumRTIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAJBVogBWBABZogBWBADUIgUIqAU9KAgBRSgIAXkoCAHBoMzMzAAArFWjB W24AFmjeNz8ANQiBPioBQioBQ0o8AE9KBABRSgQAYUo8AHBoAAAAACwVaMFbbgAWaN43PwAw ShEANQiBQioBQ0o8AE9KBABRSgQAYUo8AHBoAAAAAAA6AgiBA2p1AAAABggBFWjBW24AFmjB W24ANQiBPioBQioBQ0o8AE9KBABRSgQAVQgBYUo8AHBoAAAAAAArFWjBW24AFmiAFYEANQiB PioBQioBQ0o8AE9KBABRSgQAYUo8AHBoAAAAADQDagAAAAAVaMFbbgAWaIAVgQA1CIE+KgFC KgFDSjwAT0oEAFFKBABVCAFhSjwAcGgAAAAAAB8VaMFR+gAWaN43PwA1CIFDSjAAT0oEAFFK BABhSjAAGRZoHhvgADUIgUNKEABPSgQAUUoEAGFKEAAGFmjeNz8AABwVaH0TcgAWaFk2AABD SkgAT0oDAFFKAwBhSkgAABwVaH0TcgAWaFJ5OgBDSkgAT0oDAFFKAwBhSkgADQAGAAAjCAAA JAgAACUIAABDCAAAcAgAAKcIAADKCAAA3AgAAN0IAAD1CAAADQkAAPMAAAAAAAAAAAAAAAB1 AAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAA AAAAAAAAAAAAAGAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAYAAAAAAAAAAAAAAAAGAAAAAA AAAAAAAAAABgAAAAAAAAAAAAAAAAAAkAABYkAUlmAgAAAGdkwVtuAAwAAAMkARYkAUlmAQAA AGEkAWdk3jc/AAB9AABrZAAAAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA AAQBAAAEAQAACNYaAAGU/ywiAAaYIgAAAAAAAAAAAAAAAAAAAAAJ1gIgAAp0AADgARLWCgAA AP8AAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/NNYG AAEFAwAANNYGAAEKA2wAYNYKAAAA/wAAAAAAAGH2AwAAcNYKAAAA/wAAAAAAAAwAAAMkARYk AUlmAQAAAGEkAWdkfRNyAAALAAYAANIKAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQENCQAADgkAACgJ AABICQAASQkAAGoJAACGCQAAhwkAAKcJAADECQAAxQkAAOUJAAACCgAAAwoAACMKAABACgAA QQoAAGEKAAB+CgAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAWJAFJZgIAAABnZMFbbgBLJAEJAAAW JAFJZgIAAABnZMFbbgAAEoYJAACHCQAApwkAAMQJAADFCQAA5QkAAAIKAAADCgAAIwoAAEAK AABBCgAAYQoAAH0KAAB+CgAAfwoAAIAKAACBCgAAggoAAKYKAADx4My84My84My84Mypno5/ YkoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAvFWiAFYEAFmiAFYEANQiBPioBQioGQ0ooAE9KAgBRSgIAXkoCAGFKKABwaP8AAAA4A2oA AAAAFWiAFYEAFmiAFYEANQiBPioBQioGQ0ooAE9KAgBRSgIAVQgBXkoCAGFKKABwaP8AAAAA HBVo3jc/ABZo3jc/AENKMABPSgQAUUoEAGFKMAAAHxVo0V48ABZogBWBAD4qAUNKPABPSgQA UUoEAGFKPAAVFmiAFYEANQiBT0oCAFFKAgBeSgIAJBVogBWBABZogBWBADUIgUIqBk9KAgBR SgIAXkoCAHBo/wAAAAAeFWiAFYEAFmiAFYEANQiBNgiBT0oCAFFKAgBeSgIAACcVaIAVgQAW aIAVgQA1CIE2CIFCKgZPSgIAUUoCAF5KAgBwaP8AAAAhFWjBW24AFmiAFYEAQioBT0oCAFFK AgBeSgIAcGgzMzMAGxVogBWBABZogBWBADUIgU9KAgBRSgIAXkoCAAASfgoAAH8KAACACgAA gQoAANAKAACfAAAAAAAAAAAAAAAAlgAAAAAAAAAAAAAAAFMAAAAAAAAAAAAAAABHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkARYkAUlmAQAAAGEkAWdkgBWBAABCAABrZMEB AAAWJAEXJAFJZgEAAAAClmwAB5RVCgjWGgABlP8sIgAGmCIAAAAAAAAAAAAAAAAAAAAACnQA AOABFPYBAAAVNgEX9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zTWBgAB BQMAADTWBgABCgNsAGH2AwAACQAAFiQBSWYBAAAAZ2SAFYEAYAAAa2QWAQAAFiQBSWYCAAAA SyQBTCQBApZsAAeUvQsI1jAAAgAA/BKxIQAG/BIAAAAAAAAAAAAAAAAAAAAAAAa1DgAAAAAA AAAAAAAAAAAAAAAKdAAA4AENNmAPlGIBEJS0ABT2A7EhFTYBF/YDAAAY9gMAABrWCAAAAP8A AAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/HpS0ADTWBgABBQMAADTWBgAB CgNsAGH2AwAAZTQBAASmCgAApwoAAKgKAADOCgAAzwoAANAKAADRCgAA0goAAODDqsOXk48A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhZoCCCoAAAGFmhZNgAAACUVaIAVgQAW aIAVgQBCKgZDSigAT0oEAFFKBABhSigAcGj/AAAAMBVogBWBABZogBWBADBKEQA1CIFCKgZD SigAT0oCAFFKAgBeSgIAYUooAHBo/wAAAAA4A2oAAAAAFWiAFYEAFmiAFYEANQiBPioBQioG Q0ooAE9KAgBRSgIAVQgBXkoCAGFKKABwaP8AAAAAPgIIgQNqQQIAAAYIARVogBWBABZowVtu ADUIgT4qAUIqBkNKKABPSgIAUUoCAFUIAV5KAgBhSigAcGj/AAAAB9AKAADRCgAA0goAAL4A AAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2TBW24AAEAAAGtk4gIAABYk ARckAUlmAQAAAAKWbAAI1hoAAZT/LCIABpgiAAAAAAAAAAAAAAAAAAAAAAp0AADgART2AQAA FTYBF/YDAAAY9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP801gYAAQUDAAA01gYA AQoDbABh9gMAAAACLAAxkGgBH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAABew0AIYsNAC DJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzABYkARckAUlmAQAAAAGW AAAhdgABaAE11gUAAQOYIiN2AAGYIjpWDwAClmwACdYCIAAKdAAA4AES1goAAAD/AAAAAAAA FPYBAAAVNgEY9gMAADXWBQABA5giYNYKAAAA/wAAAAAAAHDWCgAAAP8AAAAAAAChAAAARAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLMAAAAGgA dAB0AHAAOgAvAC8AdABlAG0AbgBpAGUAcAByAG8AZwBpAC4AYwBvAG0ALwAAAKkAFiQBSWYC AAAASyQBTCQBAZZsACF2AAJoATXWBQABA/wSNdYFAQIDtQ4jdgAB/BIjdgECtQ46Vg8AApZs AAeUvQsKdAAA4AENNmAPlGIBEJS0ABPWMAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8A AAAAAAAA/wAAAAAAAAD/AAAAABT2A7EhFTYBGPYDAAAelLQANdYFAAED/BI11gUBAgO1DmU0 AX4AFiQBFyQBSWYBAAAAAZYAACF2AAFoATXWBQABA5giI3YAAZgiOlYPAAKWbAAHlFUKCnQA AOABE9YwAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAA FPYBAAAVNgEY9gMAADXWBQABA5gioQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIA AAADAAAA4Mnqefm6zhGMggCqAEupCzAAAABoAHQAdABwADoALwAvAHQAZQBtAG4AaQBlAHAA cgBvAGcAaQAuAGMAbwBtAC8AAAB6ABYkARckAUlmAQAAAAGWAAAhdgABaAE11gUAAQOYIiN2 AAGYIjpWDwAClmwACnQAAOABE9YwAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAA AAD/AAAAAAAAAP8AAAAAFPYBAAAVNgEY9gMAADXWBQABA5giAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgISABIAAQCcAA8ABAAAAAAAAAAAAAQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAQPH/AgBAAAwEAAAAAAAAAAAGAE4A bwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNICQR0SAkEAAAAAAAAAAAAAAAA AAAAAAAARABBQPL/oQBEAAwFAAAAAAAAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcA cgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaUDz/7MAUgAMBQAAAAAAAAAADABUAGEAYgBsAGUA IABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIACwAAACgA a0D0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAAAAAAAABqAJpAswDzAGoA DAQAAN43PwAAAAoAVABhAGIAbABlACAARwByAGkAZAAAADcAOlYPABPWMAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAACAA8AAABIAJkAAQACAUgA DAUAAAAzjQAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACABAAFABDShAAT0oFAFFK BQBeSgUAYUoQADYAVUCiABEBNgAMBAAAgBWBAAAACQBIAHkAcABlAHIAbABpAG4AawAAAAwA PioBQioCcGgAAP8AAAAAANICAAALAAAcAAAHAP////8BAAAABCEAAP//AQCgepkAAAAAAAAA AADSAgAAAAAAAAAAAAAAAAAAAAAjAAAAJAAAACUAAABDAAAAcAAAAKcAAADKAAAA3AAAAN0A AAD1AAAADQEAAA4BAAAoAQAASAEAAEkBAABqAQAAhgEAAIcBAACnAQAAxAEAAMUBAADlAQAA AgIAAAMCAAAjAgAAQAIAAEECAABhAgAAfgIAAIACAACBAgAA0AIAANECAADUAgAAEAIAAMAh AABbgggAAAAAAAAAAAC1BBEAAAEAAMAhAAAX7QEAAAEAAMAhAADBlAUAAAIAAMAhAADBlAUA AAEAAMAhAADw+QYAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQS AACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIA AAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAAN0N AACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIA AAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0N AACNrAIAAAEAAN0NAACNrAIAAAAAAAAAAACdFiAAAAAAAAAAAACBKj0AAAEAAMAhAADrdAQA AAAAAAAAAADrdAQAAAEAAMAhAACNrAIAAAAAACMAAAAkAAAAJQAAAEMAAABwAAAApwAAAMoA AADcAAAA3QAAAPUAAAANAQAADgEAACgBAABIAQAASQEAAGoBAACGAQAAhwEAAKcBAADEAQAA xQEAAOUBAAACAgAAAwIAACMCAABAAgAAQQIAAGECAAB+AgAAfwIAAIACAACBAgAA0AIAANEC AADUAgAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA ANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACA AQAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAA AIABAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACA AAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAAqQAAAAAwAAAAAAAA AIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAA AAAAgAAAAIACAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAA AAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAAqQAAAAAw AAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAA ADAAAAAAAAAAgAAAAIACAACYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkA AAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAA qQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAA AACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAA AAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACY AAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIA AJgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIACAACcAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAAmAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAJwAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAEAAAAAygAAAH4CAAB/AgAA1AIAAEvIADAAEAAAAAAAAAIAAAADAAIA AAAAAAAAgAdLyAAwAQAAAAAAAAACAAAAAQABAAIAAAAAAGoHAkAAClsBmwEAAAAAAAAAAAAA AQAAAAAAAAAgB0uIADAAEAAAAAAAAAEAAAAAAAAAAAAAAAQOnwcABgAAhgkAAKYKAADSCgAA BgAAAAoAAAAMAAAAAAYAAA0JAAB+CgAA0AoAANIKAAAHAAAACQAAAAsAAAANAAAAAAYAANIK AAAIAAAAcAAAAJYAAAClAAAAgQIAAKcCAADOAgAA0gIAABNYFP8VhBNYFP8VhA8AAPA4AAAA AAAG8BgAAAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcA ABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABT AAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAP//CgAA AAYAEOAEChAAAQCsgYMEBgAR4AQKEQABAJzKgwQGAPbhBAoRAAEARECEBAYAD+IEChAAAQA0 e4gEBgD44QQKEQABAJRuiAQGABDiBAoQAAEAbFEkAAYA+uEEChEAAQDUxiEABgAR4gQKEAAB AKRshAQGAPzhBAoRAAEAHPskAAYAEuIEChAAAQAULBwAHQAAAB0AAACxAQAAsQEAAO8BAADv AQAALQIAAC0CAABrAgAAawIAANQCAAAAAAAAAgABAAAAAgACAAAAAgADAAAAAgAEAAAAAgAF AAAAAgAGAAAAAgAHAAAAAgAIAAAAAgAJAAAAAgAhAAAAIQAAALUBAAC1AQAA8wEAAPMBAAAx AgAAMQIAAG8CAABvAgAA1AIAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAA AAkAAAACAAAAOAAAAAkAEQAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNt YXJ0dGFncwSAQ2l0eQCAOQAAAAoAEgAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOnNtYXJ0dGFncwWAcGxhY2UAgAwAAAEcLxUGAAAAAAoAAAAAAAkAAAAAAAkAAAAAAAoA AAAAAAkAAAAAAAoAAAAAAAkAAAAAAAoAAAAAAAkAAAAAAAoAAAAAAAAAAADRAgAA0QIAANQC AAADAAQAAwAAAAAA1AIAAAcAAAAAACMAAAAlAAAAQwAAAHAAAADKAAAAhwEAAKcBAADFAQAA AQIAAAMCAAA/AgAAQQIAAH0CAADUAgAABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAAA AADUAgAABwAWAAAABAAAAAgAAADlAAAAAAAAABUAAABZNgAArHABAPI0KgCYdi8AUnk6ANFe PADeNz8Asj5XAL8eZgDER2cAwVtuAH0TcgC3LHMAERJ6AIAVgQAAM40ACCCoACcvwgALFeAA HhvgAMFR+gBERv4AAAAAACMAAAAkAAAApwAAAIcBAAB+AgAAfwIAAIACAACBAgAA0AIAANEC AADUAgAACAAAAAIBAACeAQAACAEAAAICAAACAgAAhgIAACIBAAK+AQACAgEAAJYBAAD/QAOA AQDRAgAA0QIAAIzdlwQBAAAA0QIAAAAAAQDRAgAAlP/AewIQAAAAAAAAANICAACwAAAQAEAA AP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD/ /wAAAAD//wAAAgD//wAAAAAGAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/ AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIF BwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgIC BId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADUmkAEAAAILCAYDCQIFAgSH AgAAAAAAAAAAAAAAAAAAnwAAAAAAAABJAG0AcABhAGMAdAAAADcxkAEAAAIHBAkCAgUCBAQD AAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAG8AdQByAGkAZQByAAAANSYAAAAAAgsGBAMFBAQC BId6AGEAAACACAAAAAAAAAD/AQEAAAAAAFQAYQBoAG8AbQBhAAAAIgAEADEIiBgA8NACAABo AQAAAAAqLKjGRCyoxoIVo4YFABYAAABrAAAAZwIAAAEAAQAAAAQAAxAFAAAAawAAAGcCAAAB AAEAAAAFAAAAAAAAACEDAPAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAgHoAW0ALQAgYF+NAAAEQAZAGQAAAAZAAAA0QIAANECAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAA AAAACTODEQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWAAAAAAp8P8PAQAB PwAA5AQAAP///3////9/////f////3////9/////f////3/eNz8AAAAAADIAAAAAAAAAAAAA AAAAAAAAAP//EgAAAAAAAAASAFMAQQBWAEUAIABZAE8AVQBSACAAQgBVAFMASQBOAEUAUwBT AAAAAAAAAA4AVwBpAGwAbABpAGEAbQAgAEUAcwB0AGgAZQByAA4AVwBpAGwAbABpAGEAbQAg AEUAcwB0AGgAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIA AAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJwBAAASAAAAAQAAAJgA AAACAAAAoAAAAAMAAAC8AAAABAAAAMgAAAAFAAAA4AAAAAYAAADsAAAABwAAAPgAAAAIAAAA CAEAAAkAAAAgAQAAEgAAACwBAAAKAAAATAEAAAsAAABYAQAADAAAAGQBAAANAAAAcAEAAA4A AAB8AQAADwAAAIQBAAAQAAAAjAEAABMAAACUAQAAAgAAAOQEAAAeAAAAFAAAAFNBVkUgWU9V UiBCVVNJTkVTUwAAHgAAAAQAAAAAAAAAHgAAABAAAABXaWxsaWFtIEVzdGhlcgAAHgAAAAQA AAAAAAAAHgAAAAQAAAAAAAAAHgAAAAgAAABOb3JtYWwAAB4AAAAQAAAAV2lsbGlhbSBFc3Ro ZXIAAB4AAAAEAAAANQAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAAAE yBIDAAAAQAAAAACUeJp/PsYBQAAAAAAU0r7ouMYBQAAAAAAYmtHruMYBAwAAAAEAAAADAAAA awAAAAMAAABnAgAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAA AAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuXAEAABgB AAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACYAAAABgAAAKAAAAARAAAAqAAAABcAAACwAAAA CwAAALgAAAAQAAAAwAAAABMAAADIAAAAFgAAANAAAAANAAAA2AAAAAwAAAD3AAAAAgAAAOQE AAAeAAAAIAAAAFBob2VuaXggTWFuYWdlbWVudCBDb3Jwb3JhdGlvbgAAAwAAAAUAAAADAAAA AQAAAAMAAADRAgAAAwAAAOYVCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4Q AAABAAAAEwAAAFNBVkUgWU9VUiBCVVNJTkVTUwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAA AAEAAAAAAAAUAQAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAAQAAAAAEAAAACAAAADAAAAF9Q SURfSExJTktTAAIAAADkBAAAQQAAAMwAAAAMAAAAAwAAADMAIwADAAAAAwAAAAMAAAAAAAAA AwAAAAUAAAAfAAAAGAAAAGgAdAB0AHAAOgAvAC8AdABlAG0AbgBpAGUAcAByAG8AZwBpAC4A YwBvAG0ALwAAAB8AAAABAAAAAAASAAMAAAAzACMAAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAA HwAAABgAAABoAHQAdABwADoALwAvAHQAZQBtAG4AaQBlAHAAcgBvAGcAaQAuAGMAbwBtAC8A AAAfAAAAAQAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAA BwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAD+////EAAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAAP7///8YAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA /v///yMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAD+////KwAAACwAAAAtAAAALgAAAC8A AAAwAAAAMQAAAP7////9////NAAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAA AAAgk4jy67jGATYAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAAAAAQAAAAAAAAMQBUAGEAYgBsAGUA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4A AgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXAAAA URUAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAuHAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAAAAAQAAAAAAAABQBEAG8A YwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAqAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAAP7///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABG HwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABX b3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAOBO twb2uMYBNgAAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAAABAAAAAAAAAxAFQAYQBiAGwAZQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEA AAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcAAABRFQAA AAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAC4cAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA AAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAD+////EAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAAP7///8YAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA/v///yMA AAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAD+//////////////////////////////////// ///////////////////////////+/////v///0EAAAD9////OgAAADsAAAA8AAAAPQAAAD4A AAA/AAAAQAAAAP7////+//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////+/wAA BQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOX CAArLPmuXAEAABgBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACYAAAABgAAAKAAAAARAAAA qAAAABcAAACwAAAACwAAALgAAAAQAAAAwAAAABMAAADIAAAAFgAAANAAAAANAAAA2AAAAAwA AAD3AAAAAgAAAOQEAAAeAAAAIAAAAFBob2VuaXggTWFuYWdlbWVudCBDb3Jwb3JhdGlvbgAA AwAAAAUAAAADAAAAAQAAAAMAAADRAgAAAwAAAOYVCwALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAALAAAAAAAAAB4QAAABAAAAEwAAAFNBVkUgWU9VUiBCVVNJTkVTUwAMEAAAAgAAAB4AAAAG AAAAVGl0bGUAAwAAAAEAAAAAAAAUAQAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAAQAAAAAEA AAACAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAAQQAAAMwAAAAMAAAAAwAAADMAIwADAAAA AwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGAAAAGgAdAB0AHAAOgAvAC8AdABlAG0AbgBpAGUA cAByAG8AZwBpAC4AYwBvAG0ALwAAAB8AAAABAAAAAAASAAMAAAAzACMAAwAAAAAAAAADAAAA AAAAAAMAAAAFAAAAHwAAABgAAABoAHQAdABwADoALwAvAHQAZQBtAG4AaQBlAHAAcgBvAGcA aQAuAGMAbwBtAC8AAAAfAAAAAQAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgA AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAAA ABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADkAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0001_01C6BFE8.AF3D8400-- From owner-ccamp@ops.ietf.org Mon Aug 14 21:25:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCngL-0000qy-2j for ccamp-archive@ietf.org; Mon, 14 Aug 2006 21:25:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCngJ-0004Ws-QC for ccamp-archive@ietf.org; Mon, 14 Aug 2006 21:25:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCna7-0004a2-CR for ccamp-data@psg.com; Tue, 15 Aug 2006 01:18:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.54] (helo=szxga02-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCna1-0004ZW-2X for ccamp@ops.ietf.org; Tue, 15 Aug 2006 01:18:57 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J40005EXN4M6M@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Tue, 15 Aug 2006 09:36:23 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4000BAVN4MUF@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Tue, 15 Aug 2006 09:36:22 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4000LH3MV9C7@szxml04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 15 Aug 2006 09:30:46 +0800 (CST) Date: Tue, 15 Aug 2006 09:18:59 +0800 From: Dan Li Subject: Re: Polling for new WG I-Ds To: Adrian Farrel , ccamp@ops.ietf.org Message-id: <002301c6c008$c915ac70$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi, Yes to all. Regards, Dan ----- Original Message ----- From: "Adrian Farrel" To: Sent: Saturday, August 12, 2006 10:56 PM Subject: Polling for new WG I-Ds > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > > > From odawatchers@itsower.com Mon Aug 14 22:26:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCodE-0006FQ-II for ccamp-archive@ietf.org; Mon, 14 Aug 2006 22:26:16 -0400 Received: from p3126-ipad405marunouchi.tokyo.ocn.ne.jp ([222.146.139.126] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GCodB-0001TQ-ON for ccamp-archive@ietf.org; Mon, 14 Aug 2006 22:26:16 -0400 Message-ID: <000001c6c012$4a971f00$0100007f@localhost> From: "Keaton Long" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Tue, 15 Aug 2006 11:26:11 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C012.4A971F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 ------=_NextPart_000_0001_01C6C012.4A971F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable More than 200 software titles from world leading manufacturers =20 a.. MS Windows XP Professional with SP2 - $49.95=20 b.. Adobe Photoshop CS2 V 9.0 - $69.95=20 c.. Microsoft Office XP Professional - $49.95=20 d.. Adobe Acrobat 5.0 - $39.95 Visit our Website ------=_NextPart_000_0001_01C6C012.4A971F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 More than 200=20 software titles from world leading=20 manufacturers  
  • MS Windows XP Professional with SP2 - = $49.95
  • Adobe Photoshop CS2 V 9.0 - $69.95
  • Microsoft Office XP Professional - = $49.95
  • Adobe Acrobat 5.0 - $39.95
 
------=_NextPart_000_0001_01C6C012.4A971F00-- From nobody@no4.dothost.co.kr Tue Aug 15 04:03:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCttM-0004AH-Ds for ccamp-archive@ietf.org; Tue, 15 Aug 2006 04:03:17 -0400 Received: from no4.dothost.co.kr ([218.239.223.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCttH-00006A-Kj for ccamp-archive@ietf.org; Tue, 15 Aug 2006 04:03:16 -0400 Received: from nobody by no4.dothost.co.kr with local (Exim 4.52) id 1GCttR-0007z6-J0 for ccamp-archive@ietf.org; Tue, 15 Aug 2006 17:03:21 +0900 To: ccamp-archive@ietf.org Subject: voce recebeu uma charge X-Message-Status: s1:0 X-SID-PRA: charge X-SID-Result: TempError Errors-To: charge From: charge MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-encoding: 8bit Reply-To: charge Message-ID: Conversion-With-Loss: Yes Sensitivity: 3 Expiry-Date: Never X-Priority: 3 X-MSmail-Priority: High X-Originating-Email: [charge] X-Originating-IP: [200.201.120.121] X-iGspam-global: Unsure, spamicity=0.748491 - pe=7.48e-01 - pf=0.748491 - pg=0.748491 X-oemPro-CSID: MjgxXzI3NA== X-oemPro-MsgId: Y2NhbXAtYXJjaGl2ZUBpZXRmLm9yZw0= Sender: Nobody Date: Tue, 15 Aug 2006 17:03:21 +0900 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - no4.dothost.co.kr X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - no4.dothost.co.kr X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 4.1 (++++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
 
 


Olá, Carol (carol_bbr@yahoo.com.br) lhe enviou uma charge.

Titulo da charge:
"Piada..."

"Não há nada impossível, porque os sonhos de ontem são as esperanças de hoje e podem converter-se em realidade amanhã."

Para lê-lo, basta abrir/clicar no link abaixo:

http://charges.uol.com.br/vercharge.php?idcharge=1340&modo=som

* Para maior segurança recomendamos que apenas abra ( Abrir/Executar ) o arquivo invés de salva-lo em seu computador. Isso protege você de arquivos mal-intencionados.

Não se esqueça de retribuir o cartão que recebeu. O Charges.com.br terá o maior prazer em entregar os seus cartões.

Um abraço,

Equipe charges.com.br

Todos os direitos autorais são reservados
Charges.com.br 2006
From owner-ccamp@ops.ietf.org Tue Aug 15 05:25:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCvAv-0001vt-O8 for ccamp-archive@ietf.org; Tue, 15 Aug 2006 05:25:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCvAt-0006z9-Rx for ccamp-archive@ietf.org; Tue, 15 Aug 2006 05:25:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCv3q-0006Iw-7c for ccamp-data@psg.com; Tue, 15 Aug 2006 09:18:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.1 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCv3o-0006Id-RN for ccamp@ops.ietf.org; Tue, 15 Aug 2006 09:18:09 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k7F9I5AV009852; Tue, 15 Aug 2006 18:18:05 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k7F9I40Y010755; Tue, 15 Aug 2006 18:18:04 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k7F9I3B2003790; Tue, 15 Aug 2006 18:18:03 +0900 (JST) Received: from dmailsv1.y.ecl.ntt.co.jp (dmailsv1.y.ecl.ntt.co.jp [129.60.53.14]) by nttmail3.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k7F9I3KS001671; Tue, 15 Aug 2006 18:18:03 +0900 (JST) Received: from mailsv04.y.ecl.ntt.co.jp by dmailsv1.y.ecl.ntt.co.jp (8.13.7/dmailsv-1.6) with ESMTP id k7F9I2gU012425; Tue, 15 Aug 2006 18:18:02 +0900 (JST) Received: from localhost by mailsv04.y.ecl.ntt.co.jp (8.13.7/Lab-1.6) with ESMTP id k7F9I1M4023938; Tue, 15 Aug 2006 18:18:02 +0900 (JST) Message-Id: <6.0.0.20.2.20060815181729.05a653b0@mailsv4.y.ecl.ntt.co.jp> X-Sender: wi002@mailsv4.y.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Tue, 15 Aug 2006 18:17:55 +0900 To: "Adrian Farrel" , From: Wataru Imajuku Subject: Re: Polling for new WG I-Ds In-Reply-To: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> References: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi, All Yes to all. Best Regards Wataru At 23:56 06/08/12, Adrian Farrel wrote: >Hi, > >As discussed in Montreal, we need to poll for a couple of new WG drafts. > >http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt has been updated by the authors to provide further details and clarification. > >http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt has been updated since the version discussed in Montreal. > >http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt has been updated as Zafar says in his previous email. > > >Please send yes or no for these I-Ds. > >Reasons and opinions are also welcomed. > >Thanks, >Adrian > > > > ------------------------------------- Wataru Imajuku@NTT Network Innovation Labs TEL: +81-46-859-4315 FAX: +81-468-59-5541 From owner-ccamp@ops.ietf.org Tue Aug 15 08:26:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCy0R-0003Vu-MP for ccamp-archive@ietf.org; Tue, 15 Aug 2006 08:26:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCy0P-00060q-6S for ccamp-archive@ietf.org; Tue, 15 Aug 2006 08:26:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCxuV-000Iu0-BY for ccamp-data@psg.com; Tue, 15 Aug 2006 12:20:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,FORGED_RCVD_HELO,SPF_PASS autolearn=no version=3.1.1 Received: from [213.46.243.15] (helo=amsfep14-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GCxuJ-000Isq-GD for ccamp@ops.ietf.org; Tue, 15 Aug 2006 12:20:32 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep14-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20060815122014.DOZP13274.amsfep14-int.chello.nl@[192.168.1.4]>; Tue, 15 Aug 2006 14:20:14 +0200 Message-ID: <44E1BBFE.3010106@chello.nl> Date: Tue, 15 Aug 2006 14:20:14 +0200 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds References: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> In-Reply-To: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello Adrian, You asked: > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. Yes to all. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From U3dautarky@davidbeauchamp.net Tue Aug 15 14:48:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3xI-00004v-RI; Tue, 15 Aug 2006 14:48:01 -0400 Received: from [210.107.114.99] (helo=KAYACFS) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GD3xD-0006WB-MY; Tue, 15 Aug 2006 14:48:00 -0400 From: "Saul Corbin" To: "Bridge-mib" Subject: Re: A turnoff to scared Date: Tue, 15 Aug 2006 11:44:09 -0800 Message-ID: <83993945799.2676498392232@abspresort.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00EE_01C5291A.98B67DA0" X-Spam-Score: 4.8 (++++) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C5291A.98B67DA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00F0_01C5093D.12A32DA0" ------=_NextPart_001_00F0_01C5093D.12A32DA0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit that ever I have seen, is so restored, I have observed today, that certain than that it never can take place, and never will. If Be silent, you. Look at me, I say, proud mother of a proud, false For the Lords love, said Mr. Peggotty, falling back, and putting ------=_NextPart_001_00F0_01C5093D.12A32DA0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7Bit
tell Dora, if Dora were in a state to hear it, that he had spoken
Emly, if youll ony let me, to the worlds end. I know how tis; to lay that money down afore him. If I do that, and find my Emly,
have not abused. My meaning simply is, that whatever I have tried monuments, pews, fonts, organs, and church windows, in which there
Now, Dora, my love, I returned, gently trying to remove the to have made out, without her own consent. I believe there never
overlooked, is to advertise in all the papers; to describe himself repurchase them at the time of their seizure; in the first place,
at all; so it was settled that I should have the other room; and, conversation; and as I was too full of my desperate intentions to
further, though much pressed. Pound being produced by D. takes into a roar of laughter, and rubbed his hands up and down his legs,
She had got over the fender now, and I had got over my suspicion. silent. Presently we sat down, side by side; and her angel-face
head after speaking, and became upright again when silent. Miss passionless air, that it seemed as if nothing could disturb. She
affecting to read the paper with his eyes on the ceiling; and I appointment at the turnpike, presents a dazzling combination of
Good God. cried Traddles, looking up. Its Copperfield. and Millss maid, and taken the area way to the back kitchen. I have
sound. In another hour it had much increased, and the sky was more to be called The Astonishment, than anything else I can think of.
hollow, painfully suggestive piece of business altogether. We left inquiries with reference to the physical welfare of Mrs.
a goose, and she didnt like me at any rate, and the short evening having taken this bad turn, poor fellow, they would have been man
As I had long forborne to encourage him with hopes that hung on say in justice to society, by which he has been hitherto
first time. I have been telling your daughter how well I have has been quicker than was supposed; Omer and Joram can run their
I was charmed with her childish, winning way. I fondly explained loved before, and lovers would love again; but no lover had loved,
expression of rage and grief. It was in an evil hour that you Not that her happiness was of long duration, pursued Traddles,
------=_NextPart_001_00F0_01C5093D.12A32DA0-- ------=_NextPart_000_00EE_01C5291A.98B67DA0 Content-Type: image/gif; name="qgrafter" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhvQFGAfcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8AAAAP///wdk3q4rPt7K ndeSpnySpih5I/laF2QpGZiaHbepLowCsL/zm+QqJ/bgqNA2qfipFSd5SPcQm9vJnNHWnSjRneI6 vlzJwyqqVscrnfUlKhh1pYkIjWnrGcNxKBE3opXIw+nYopgqvnB1Ufnaan5Gb/EZyqKch6+ykH6Y ircYiqHoilt4h3SSirboixg4hw8xi5dIinfYh4noiAmRi7Soh6sojb3IhZwYJsRojEzYhcaYidb4 o2JrLlLakqtsQfbcA264r467LJfDnmvvTYwGS6+44kor6rfPqtltstKuW++9COM15kL8dmutwY/e LiGp2kX+cWugxe1GaatW3cqWt3ECLmlzK9zYrlUtp/2sY31LXOa+1rPODS5zhUO6Uw0XutINn2RR zMVpDEZqfMNmDMUxXMNBPMM9tEVvnMVvBMdNfERCNMRzxMVGXEN0JEM/TMdwHMV0lEZmDMRDxEZE CRq/iK3WfbGIdLyME7W4RQ0O8DBfzKHo0GVHOyJAkPiYHkHWNpwnlQWRaWxdIRcwxC8KapJOgVgm wLFxrx5snPRz2qqnZ2e+WWHt4AqHs//1rb21a+7Qm/9eX/219N+ZKYtG3/u27YnfwSMUv5b8cYTO p8CKLM4iRm2TGvJ6r9DKSnF0JoKCmf7qEkrKrnZzqiILPciKrAjiRCILn4X/EqHQekiHKhn4uaQ5 NPxORBNfUi+jEE/cDjj4NmQxRrv4SpHG9W68akUZOerqxRJ3BPKyGjm77raRhgwyJh/1SzLIzKiq vwzkwDLZvg4EQf+7wBAkQZfYwBL8thNEwW1TwRW8thZ0wWmDwRh8thmkwWWzwRscthzUwVzjwR6c s6JwsSZG0RTKjXo0Qxf9qEgHE9KRmlRDHT2pSjFT0pW6VCktfalMixLTmdp0JDVljQAEIJCdqsWn BaiEcJMl17AAAP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAAvQFGAQAI/wAXCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKlTngIEPNUZdWrVqVhRRt26leHVkFy57gwrdePXgmTP LggrUO3asmQPpiXo1m3bslnzirS7kK9ZvED9UvRL+OvVs2oL08WbGLBBwXojV4Qs17FHyjcxPxSs eOBhwI0Thn672KtlyagHn74r9u5ixF09S239eHVV2qxBzzbMlrRsh7DfNubL2fZq175LIxzNu6Hm 1NCXH0cLl3F15LytV5auHbv11s2Ti/9XCLu777rTx/8mH5u6aMefkTtPH71+7bjbz1sOLt5u2uvr 8TeafPEBp5tykCU4l3rU+Xccf6Q9x6B9FNb2Xm8FKuedhhxy+Bl+AyaXoWkeAvheX8aRmF9lveX2 nIQVpkbcgfpZGCCN7q1Yo479dfcijjueyJ50KtrI42vyoRjjkkcmWSB6CAK5npFB5jhlj+UJ6aSJ RA7ZZZITMveglF8yaeaMspn4pJpkholjeFAK91qbV0I44pVUNognmlFqCWaeZi5Z2G1c4mZom/9t Oad5SIboJnhA4tahldzFuaiPYwI6aaCcVugojBiBKpSonZba1Kf0fUSqT6ua6ipRLe7/maqqs45a 66u45qrrrrz26uuvwAYr7LDEFmvsscgmq+yyzDbr7LMaAQDttPVJO5C1B2FLEADccotSt9hqy5C4 ApFL7blJaWtuudmupC67D5m7Lrr0DvVuud4uAG5B5O57bb766mutv+Ea1G+3+Kqbb8Hw1utwUeAu fG3D2xI8ccDwAsxwwOsC3DDDBQ+87cMk2zsyxhjLa/DFEVO8sbTzCnwxyiKPLG7MJedc070gt8sv yyvPHPK4HwNd8c06J70Tz0b/7HTKTdN8ctAZC110zUpnrdO9AivMr8Ufa/y1x/P6i2/CRxdNsdZs c8p123DXi/DMcddt991456333nz3/+3334AHLvjgbXccr9kNeZxtxDG3LBHOhPM6d0SMh0v25BSp 7DPKiS9UM84bxxt5saFT/vTLFmlONeRTe+5Q6Z2PLizSUnOsOudQr931yxKrvfq/wJ8Ns7eYr118 7cQPj/vyskvuNMhlt5778j1LjTXzuwMt8sBY31464p/D/HTzvtJePUJvp3w88sbjbjjNcyNc/fu+ V2309diTj6v5UVPtvu5T+9zYxney0G3PavSrXdQE+D/9/Qp19kPf6ej2u+mJL38BrNoBryZBq2XQ fvhzYLCKB7YOpo2CY+Nd91DYNeBpTH5m69jlbvbChO2LbCIMHOtassMc+jBzOenhD/+HSMQiGvGI SEyiEpfIxCY68YlQjKIUp1ih+CnucegTIgEBqBD5caSHlZOZ9NIGw8bRjopBHCMWTfi6LwZPJQwU IgS7uEU00iR9WExg7DJyRpb0kWj1YyMG7fgSnikve1fk2NeyJ7OFDS95aIOk5cS2OOFl7JBidOQN BXlBTU4Qfm88pBYJeRLGaY9dIVxhIycWPg7mjnjTY14rYZnJV77yggSkZSdXJj4B+pKFpIQJ1zb4 yINREmrc6531mKZIzskwjmqLny1l+TxUGq6XNmQkDoO5sw9yj4vMRGb7fNe7Vkpvl9Mc2i37N87u HexsLvsZ7LhZSG86c5wRhKAqmwn/TfpBc538RGU1/WfLECqQmBGk50ysOMlHwvNfybTh9TzZSMeZ MnnGPNoNlYfJMJZRjBANaeX8WbHgwXCQCrXJPO8IzDW6jospJV1LZbJSl9IRpjEl1vpUmsiJ7HSA OQ2qUIdK1KIa9ahITapSl8rUpjr1qVCNqlSnStWqWvWqFLoVVgO1yUKaUpCTiZVwZtSesbZqqzfx Wik5uZfZ9AhPImIUWpfSr2+xFSyxeVN6wjNXppTtm6zcXjLf9cIr8k+ZLYRo+vAzJQWl6ax9XehN 4TdJukVUgSmkKEjPh1kX6dVLmopsUBpn2fF99aBgxacxf1odO2WqTKI12Sfv2TqS/4LzrtQz0Fre +qfewjW2o63tQxsYT3KmlricLd1t2qKhDFkKssD1qmFFWViNilSzaANqYrfLSN2J1aw3atF3oys4 rZL3vOhNr3rXy972uve98I2vfOf7N/PSN5s1zdxpOxLG475uv1r57qDaM160qrWngFyk+kDyRz6a 041D2s2c/EQg+zb1jKME4Bz5W8eLbDhaKDpMaNXD18j2FJPZtSbitgi+WjryrqI8YTYTslqbRXSw M8YdYzflosZa2Kkk3OdlB9nHIVtRwxatYTTViE/16bOAW9yxb3NU4ugec454zKXjkMtCPcIOwGqM oTct2pfcjLhPU74qhj2IWdB1eP/NGsZtXff40O8dk8m/kTClhFTluW4TtfVzs3BV22U5L5DGpzOg //AnruXullLOZRNwi3ndyqZ4p0GubiQxqt2QXnqGf6UhR0GtWE8vT6wg+k55oHtft+F5M63mW5Zj 7cMV0/rWuM61rnfN6177+tfAPoqUTbKg1G0ZYhDJ8Huz45mT9NmmyqYpaYPdIS79xUiQnfVPpk3t Hj92QeI9lKTiKqe8Fru0OeYu5qgrT8CWOrCLbGiOFUbYaPc13HXSjrk3dB8CS5pBWw6nKo9MWXgq OrHQK65akYfY+e5bUfxe04okzhqAu4/Ms90wlgPOZnozuuMzRS98/l1hfo/1SxT/N7PPsjxnQNPW 5RlnGWddnl+Rw4lRNzc5ygG0ahMe/HxY/mCbQV5Lg8c8kO7d8bkxNJdhLz1WfJmcvE293Y8ytIVS z7pDhXfjrWu90t2eyLBVE/aHPRsiji67wwqMdlar/e1wj7vc5073utv97njPu96DTYCBEODvfV8A 4P3+94QUXiCBt0jfFx+RxC8k8I73u0IiP/mCUH7vjz+84xPPeMQfBPKCx8jmG++Qy0ve8A+JvOkx j/rQE4Tzro897EN/+cWDHvKaLzzgR394wes+97j/fecHH3vEa973hL898X0ffM8zfvd6fz7xYT/7 4useIcc/vudd33nCO1/yoP++//i7333ZI5/24A//6amPe+6z/vXmZ//yna968J/e/eiHv/jzv3vy 4x/6qld9/ld929d/5od/75d/CkiA46d/C7h++7d9D6h+Ejh88fd5FXiBEliAlgeBxZd31Gd/GdiB FJh99xd+5Xd+A5iBIch/5deCE3h/HLh/KPh+y3eDvYeBxkeCJdh7ygd/Pph7xqd+tsd9z2d52meE RLh5zXeAFJiAH7F6EiGFUAgsVAgRV1iFWriFXNiFXviFYBiGYjiGZFiGZniGaJiGariGbNiGbviG cBiHZlgAdFiHClEAG1GHdrgSeoiHGuGHPgGIA0GHBkGIBGGICyCICKGIFcGIM/+xhwUBiI74h4PI FJN4EJcoEZmYEpuoiT+BiALhh4IoipWYiKbIEJ1oE6lYiovIih6xikIBi7CIio/YEbMIE6N4iKGo i6eIh6l4izExi5koiSEBjIGYEJA4ispIjKDoipXYjIjoi8q4i86IiboIjb94iqYYjYm4jKxIitgY id5YiLxIjbkYitJIi4qIjaRIjb3YjYfIjL4ojs8oinpYiNF4j9YIj/Eoj/Q4iKBIjAAJjsbIEn3I iwL5jtpoj+44kHtoiALJkBGpjRTZigDpju2IjBjZjhCJkR7JjxNpjiJJjq6YkRV5kiR5jiGZkBJZ ihI5jyPZkQ35jeVIjvPIkuj/+JEZiZMxaZI64Yg8yYgheZJA6ZJGqZAKmY00iZIWGZRHiZQ7OZML KZU1qZI1SZWR+JHlGJUxqZNdOZJTSZIUeYk3GZZQ6ZVayZUJuRNFiZZbqZXVGJbpOJMr2RDniJQL cZBuqZZP6ZPbOI372JAmuY45iYn6SJR9+ZS7yI1JyY9m2ZZjqZFluZeUWZlr+ZOBOZRLeZkoGZGE +ZaFSYub6RBWCZZ8aZpS2YxxeZd4SZh+GZmIiZpgGZpfCY1LmZWC2ZTbOJqyyZNnaZZsmZmJKZfV CJmn6ZKSuIp3eZzOeJzOaZnNGZiz6ZMcKZa9OZx4SZyNKZudWZIWqZ2/yZCP/zmcnIkTk2iHOxmQ jNmZ+siS63mRrEmU7fmN70mXldmNy8iV+NmPA2mY6yiUQnmR1rmQ6pmPjAmgdYmOvnmetimcG7mg MLmft4mewIkul6mad1OQkaGhWnOhfsOheQGiSVOeH+oqIloykMiUfXOiloihcviiMBqjMgpsHmqL +HiYD8GiWCmauMmGJMoRAWoRIHqiOrqFP5qHA+qJQpoRRaqF4mmU4biY4xibV2mPAdmfUsqfepmc /pikY/mf9cifAqqgZVeWKnmahDiUCPqQE0qeEaqf4emXxomWMommO8prZoqQ5MmdQXqjoBmefKqn 3LmaqbmnoNmk7ZWne1qfvv8Zl/YJnX9amr95lbOZpWnZpbQZbOAIm57Zo2nppbvZpuD5qYZKpYIa jz36mS6KqOi1oJAqqpQ6nq9KqtdZqClZqqoanSqKa676mPW5n695kKqaolxanGmam2QKlwq6nsTK rMn6rMk4ozwqrcPCqtSaGtZ6rdq6rdzard76reAaruI6ruRaruZ6ruzlPbkkY+/WPirTX2CWWbcD U5DzUzg1WSEnQaeFYWLWQP21Ox7Xcu4qUQ3lRcl2bB3mU/E6Evb2UhO0cDA3TPLULl6Gr/nDOoKG QcrWsAkVSx77YB5LQR8nXITVTv61OQ6LERyrsiJRZPc0c6lkslCGshqbsBj/a7HR41N8JLP980sd K7JN5krTxE73mrBGazr1FBIuW7I/qzsjyz80y20aZDvuFDLzKmMDl0lWKzQIFkhP20G4ZFDYU6+s dD8DRbMWa2qWdmkgxWQoJnULtk8r17b2mmASC0K3dbbGRbAjm0UxxEAWZHRvZraXJLjlhHQBxHGJ C7XhE3DTlbPNNLSXpLiJ069DO3Cp9FWHW7gL1lnPA7jRdnDsE7JOS2iIC7AZm09LNlvAND9NA3Sl i2g867SuS7oKdrsTK1CTC7cne7SA60Ff5nOri1qCNnMVgUuou0JiO2dL67b5CrWBy7axW0FZO7xV 61DSNLtjq7piS1CFpk7R/0uvBsNpY5u9LSe3eetkyoQ6xUu0Ops+yqu9H2szzhty0Iu+4Qu0owu7 qpu/FdSzMqtOFUtc9Ku7sVRTYLQ5v2u93ju8RBe5YOu+Ovu9JRVog5Zb9Xuv98vAnktz/ftkeNu2 /7u3/uoyy6u32ztod4u2svu5H/y6DTy60ftnssu/xxtmBHw8trY+olZCSLevMhc2H0Z1Vfdu+sS7 q9TCAJZplGQ++wo+tqa/HTtYSJxg8SbEWItC8Mq1BoS8DSZkd7YkKxsZYzwVZbxt56QsZ5wVa9wU bYwTolu0UvXG6ZIaWYeueJzHetxGQOxflAsS/BDIgkwQgzwQ/FAQh7wAif/MEIssEI0MRFvYty28 rijVu4aMEIvcyJl8yQ0RyIS8s6+WthCWF6Eryo+jOXQ8yXQGSA0Ww9CLtIx8EI+8yY7MybFMyx4G Ykobw0JRczh1tTaFwiolOgG8WejGS/R2Ql/XMI9cywlxyJrsENBsy4WMy4lcyHJsxR4hsEbhyzXL y8Q8t1sTzoz7T+xadPw7xILsyc6MyYr8yZ3szNd8ydb8zu08TInUUVS3bjNUUqJGxGprzP28ZAOd Yp72ttilYsjMrjpMS+nUZQWdxK47ZEm8R33cM2YEvDDcwbYMz8+MyNIsz+08z9M8z4v2w+ZcvTM8 XCQMvOak0oAF06sDunH/Jks07bnVi7/pLLgANT8JnLfQQ7YMx1CItT7NbM8f7dEGPdL2vM4k/c6Z zM4KN1k3PbP2NL35JdMyrNJs9sBEa1DB+821C8HifNWXu9EWHcEhrL/Gy826c9SzDNJKrRCbbNKf XNIGscj4rDqNW1hri3EY3MElpNU7nVn/O3WorMDtysOrC74phNWNrVj4q8RqLbkl/ML9uzxHjdTN HNfxbMh2Xc9MXVxjNNZd/bNhjdMbXdgrbbQgTLpgjdZaHNkGbNYavdbnS86Vjb6Uu7ZV99cdjchS PdebnddyrcjDjcvI3cgCN764zbmsnduxu74cHN0/fNsN17Q+fd37W7/U/925Y23Dq5w0/PquKuTP +0xqt4tp6BS+/Pzd6pbPYNy5BSTdFc3YMzZRNBa2l0NZv/vecqQUTj3gBF7g2PzMBp7gCn7IGZbK zTPGDp6yOrOxCgXhRxXhhNO1sLzHHL5eGJ7NpszK0nawawy5aTTB4QzKKs7CID7eo/zhlcziycZS M24mMO7N7gLJPYHjLIviNyxZNc4kN56vfqTjSyMxEZ3FGnTeunt1BWdNZf3e8JbeyTy+RuZMsBTU FOtugqU9XlNXYnPlBU1pT77US27lUA7QtlNnac62Vz6xwJ3PTobeZY5isLy5gQ2+m5twWx1NMdva 4F3dhcZwQRO2OB3T0P+d6PRtUjyN6ITe56pddImb2SYVRzf93e80w5nb2JfevQ4r3sYFwsYL6DqN 2qtNvS816j6b2uGN2Xm+t9bt6lF+2Nzd3bLOTm0924IO6S4V1I9Lw62O5Zgu22st2eTk175t1bEt TgBL660N6ryOudk71Jp2tvZNxc4u7UU97bctdFw87Lx+5xJMTaKO1oSt63/u7U076Ko+td9s62cd 6e7twLCetqVO70fH1fX+SfZ92vA+2WlN6aHO6KTe6Bw8s7Ee69Ze00GX77QNUBUsZIZr7gdP7IDG 6oRb8JLe7fe+v5dO5JV0UCd2ZW0O3C7U6CRv7WPOxQx9YgFd6JYl5w//X9UOPeXCbvNFjPJVvvAK xuQOL/JdHLI+n9rxbUEpP8xE5NYS3jcwzrC1pusprjc8Ps61JvNRL/Ua3uFav/XUSsMgX+MBDs4M Bsc9HsorbkeZ/kYb0eA0BEeq7BNTv/bclPYsffb/hbsmYeJo3OJyP0VOXrYGDLf9bfLJnruRK/hm zj6Df9DVzl0tv7XGvOYnr8yR7/gXv/J870C5LsBB3NOEi8DW4+e17uiOPu/yjrkTj851bznPLXSG Du9NlOsBBemFrfTurtWvHu6Z7enSXe4Cf/G/rEjn3vR3I/volPAZH8W3b707fOpCfL2Fn/u+77/A n/jYhO3NbvlLZPzx/4781H9KGi+8tG/xpY3qMz/6uM5Ls1/+Mf5Dsj/+IJTTnKvYro7xqh//+y79 FP/s1/77Hgz7ALFA4ECCBQ0eRJhQ4UKGDR0+hBhRYkQAFQcCMIhRoMYFHCt6vHgRo0eLG01uHHmS IEiVH0OK5Fjwo8aRMWeK7IgS5sqSGXt27Mky51ChFmPqHEp050GhQG0GfXl04lSqVa1exZpVq0Sp W71m/Bp2alexZc2eRZtWLdqma7OSdeu1bVy6de3exWvVZd6qcPlS3ftX8GDChQ0fRpxY8WLGjR0/ hhxZ8mTKlS1fxpxZ82bOnT1/Bh1a9GjSpU2fRp1a9WrWrV2/hh1b9v9s2rVt38adW/du3r19/wYe XPhw4sWNH0eeXPly5s2dP4ceXfp06tWtX8eeXft27t29fwcfXvx48uXNfxXwOP159prTvz8oQP78 gfPXr6+/gH5B+/jx6zcIvv/aI1Cy/QKMj6D78hNowAYVfDDCAOUrsEIDAXQQQP4Q8o/BDRlcMEH4 LCTRsQwl9BDB/zJc8cETUywxxsn6QxFBCG2MkEIZd/zMwRc1hLFB+/L7kUcjI/NRoQFZTBDII5+c sUkUl7yRyRqhxJKxE4e8UcgOnUyxyCzHJLNMM89EM00112SzTTffhDNOOeeks04778QzTz335LNP P/8ENFBBByW0UEMxW8MnUYISxWdRRQdi1K5IIX1UoEktrfRQTR27dIFOP810U1FHJbVUU09FNVVV TaLpa5rLYLdAhDHuZvBLmMKa+Zp1DURiIytpQeWC0o209KTU85B8XnoqfSHsJrTLGX5UtaiZAQ5d mHFFx3Ev992sGDJfwqVHV647urNAwYZhu149mzbr14D94tZtW/Rg3p4hgoabuqBl07EX30asHDXy ircYiqHoilt4h3SSirboixg4hw8xi5dIinfYh4noiAmRi7Soh6sojb3IhZwYJsRojEzYhcaYidb4 5SbVkN7NN5Ve6kl+6qPuEKzOL6v+5jOFfp4k4iUe6Bwe5npe6Cc+29kN6Ppd6Hee69t95zFu3r4+ DSNhzZZ36tZ8Dahb3S9SfdfpwdYRk5W3zLBduZMYjdKCnSEhoixXGdlemUI1XdSNnRZjqpZqWS70 ------=_NextPart_000_00EE_01C5291A.98B67DA0-- From xdduvbhjtu@rr.com Tue Aug 15 16:33:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5bN-0005Z9-Hk for ccamp-archive@ietf.org; Tue, 15 Aug 2006 16:33:29 -0400 Received: from dt090n7f.tampabay.res.rr.com ([24.92.166.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD5bG-0008LN-4H for ccamp-archive@ietf.org; Tue, 15 Aug 2006 16:33:29 -0400 From: "All image" To: ccamp-archive@ietf.org Subject: tracking Date: Tue, 15 Aug 2006 16:33:18 +0400 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C6C088.83EAB480" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcbAiIPq8aSxyEQETO6Xgixdp9QOJw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.9 (+++) X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5 ------=_NextPart_000_0004_01C6C088.83EAB480 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C6C088.83EAB480" ------=_NextPart_001_0005_01C6C088.83EAB480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit needs. You count deliver results. Overview View database formats: ASCII Text Delimited Fixed Width Studies Insurance Claim Rebate ...and answers Ready Call Counties inthe Ranking Each Large out reference Almost items Abstract The National BookState AreaData states easy daily notices letters postcards /W more High volume impact multiple finishing complete mailing Address Postal File Formats todays popular database formats: ASCII Text Delimited Fixed Width Microsoft Access versions Excel SPSS/SAS DBF /E needs. You count deliver results. Overview View setup testing Shipping receiving coding tracking reporting Quality assurance Complete color black white Automated indexing bar code OCR Manual key Fulltext All image formats including TIFF JPEG Featuring both USbased offshore OCR Manual archival Secure Web Merge purge duplicate case gender Laser Mailroom Cut sheet printing Pressure seal quality laser invoices daily notices letters postcards /W more High volume impact multiple finishing complete mailing Address Postal File Formats todays popular database formats: ASCII Text Delimited Fixed Width Microsoft Access versions from Census plus Profiles withdata Federal Bureau Customer Compendia Branch Last Revised: July Skip this aa Links: Search Subjects AZ FAQs Tools Catalog Privacy Policy Us Microsoft Access versions Excel SPSS/SAS DBF /E Contact started: Online contact CST Email: wide array for: Invoice Mailing AZ FAQs Tools Catalog Privacy Policy Us Page wide array for: Invoice Mailing Setup Rewards address capture process needs. You count deliver results. Overview View setup testing Shipping receiving DBF /E Contact started: Online Skip this aa Links: Search Subjects AZ FAQs industry. Whether quick support onetime entry AreaData states easy access facts about people National BookState AreaData states easy access facts about items black white Automated indexing bar code OCR Manual key Fulltext All now available place school plan official housing from Census plus other U.S. counties Cities Places online Adobe Acrobat files features BookTop Counties inthe Ranking Each Large out reference Almost items Abstract The National BookState AreaData states easy Customer Compendia Branch Last Revised: July Skip this aa Links: Search Subjects AZ FAQs Tools Catalog Privacy indexing bar code OCR Manual key Fulltext All image formats including TIFF For over years Company has been providing services designed meet the specific of multiple finishing complete mailing Address Postal File Formats todays popular database Whether quick support onetime entry projects listen customer develop common sense solutions while using most Our served customers well have proven Well put work you. BookUncle Sams Reference Shelf Edition CDROM now available place school plan official housing offer With full range solve many companies face today. From City BookUncle Sams Reference ------=_NextPart_001_0005_01C6C088.83EAB480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

needs. You count deliver = results. Overview View

database formats: ASCII = Text Delimited Fixed Width

Studies Insurance Claim = Rebate ...and answers Ready Call

Counties inthe Ranking Each = Large out reference Almost items Abstract The National BookState = AreaData states easy

daily notices letters = postcards /W more High volume impact multiple finishing complete mailing = Address Postal File Formats todays popular database formats: ASCII Text = Delimited Fixed Width Microsoft Access versions Excel SPSS/SAS DBF = /E

needs. You count deliver = results. Overview View setup testing Shipping receiving coding tracking = reporting Quality assurance Complete color black white Automated = indexing bar code OCR Manual key Fulltext All image formats including = TIFF JPEG Featuring both USbased offshore

OCR = Manual

archival Secure Web Merge = purge duplicate case gender Laser Mailroom Cut sheet printing Pressure = seal quality laser invoices daily notices letters postcards /W more High = volume impact multiple finishing complete mailing Address Postal File = Formats todays popular database formats: ASCII Text Delimited Fixed = Width Microsoft Access versions

from Census = plus

Profiles withdata Federal = Bureau Customer Compendia Branch Last Revised: July Skip this aa Links: = Search Subjects AZ FAQs Tools Catalog Privacy Policy = Us

Microsoft Access versions = Excel SPSS/SAS DBF /E Contact started: Online contact CST Email: wide = array for: Invoice Mailing

AZ FAQs Tools Catalog = Privacy Policy Us Page

wide array for: Invoice = Mailing Setup Rewards

address capture process = needs. You count deliver results. Overview View setup testing Shipping = receiving

DBF /E Contact started: = Online

Skip this aa Links: Search = Subjects AZ FAQs

industry. Whether quick = support onetime entry

AreaData states easy access = facts about people

National BookState AreaData = states easy access facts about

items

black white Automated = indexing bar code OCR Manual key Fulltext = All

now available place school = plan official housing from Census plus other U.S. counties Cities Places = online Adobe Acrobat files features BookTop Counties inthe Ranking Each = Large out reference Almost items Abstract The National BookState = AreaData states easy

Customer Compendia Branch = Last Revised: July Skip this aa Links: Search Subjects AZ FAQs Tools = Catalog Privacy

indexing bar code OCR = Manual key Fulltext All image formats including = TIFF

For over years Company has = been providing services designed meet the specific = of

multiple finishing complete = mailing Address Postal File Formats todays popular = database

Whether quick support = onetime entry projects

listen customer develop = common sense solutions while using most Our served customers well have = proven

Well put work = you.

BookUncle Sams Reference = Shelf Edition CDROM now available place school plan official = housing

offer With full range solve = many companies face today. From

City BookUncle Sams = Reference

------=_NextPart_001_0005_01C6C088.83EAB480-- ------=_NextPart_000_0004_01C6C088.83EAB480 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhxgH0AYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAAxgH0AQcI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihy5EAvJkyhTqlyJsALLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1hldgpgTyCVAFQE2gvQ6V+As2gDGDxLkO3A s2EFluI6cGwps2ndrgWLMG+Ae2/VBhZ49sBgvIYJC/a7OC9gxVkjS9Z5LwCCf2PPdkXwF2/e vW0F/+N89vK/AwESn07tOe1B0pYPMn6sF6/ispDx4rbdGq1ix7knCx/+ErVh1IVXG64tWzTv f5XnPh67e2tX5gejdwYt1m1t78l5/qNNDL553fLE06sfyfluZdSA517GXvC76K9j4/6TPzrA 3ecJ4ccXd/3hZt9tVFzXWCcJiufcYQUK1Mlu61VoYUZsfWVWWOB9Vh9jAnEGWGWmwQcda71h J+KJpoWWF3nOgbeijJ116FqKKJby34U89hjRXKjdJZ9/v93ooofGKfdWWBoW6VtBSSb5IVqd qHagbUM2tp9lNj6ZV5UD6ejjmGQqVNlWx/m3HX2htfnPVmntVtmcECIEJ5Wg2fOVlTFqaVd5 f2qZ554DHaBamYiWiVxssMG40IGZ5dXVauEBaFCkaU16GGmJSScQnbwtmpuolubGaaKoohpp YHThSKBt/1Iq6dWATjIXa6zBVRbXomiZptdXgv4DbK3B6hpcqsha+NWOcLJqZJ1sWXeenNsR W5C03VH4nJ7bHQAnmMEhF26X6GH2FWBsJqvuuuy26+678MYr77z01mvvvfjmK1Av+vbr778A ByzwwAQXbPDBCCec3gFkDNBKiwIxPAAZhw4wAEEWC5RxQRZ3fI+mA3Us8sUba3zxPyVLTPFB Iw/wGMotc9wyySebbPLIBlnc4sYzY+bwQK0MYM/MNd8sss+tAC300EkLFLSmKlc8wM4nIxC0 wxAr/NTVHbfItcVNw4zxySWHPDIZIMMcc9k8n3zAyIca3XHTPY+9dtFt4yxz2P55H33a1KMN YBjRMuv99mUICB4x4Imr9vXPJvN9ceIjZ631Um+30tU9kGfelT1BJ8Y22UXbjFnoCI0+tukW bzZxzjUPTXpDqpttekIdiz77QWSg3bvMqZc+UO/2/D6872QU6vDnqKut+z8NmzZ08pc79bRY mjstdF2Q11727UwHv7rtYkMPOO6xdy88y3i3f3vwraBd/vcDUX4++bAjZD/E+yutafgwi19X 6Je56jmFfu+bn/vKN74E4k9tetvY23LHPpFlD4IdE5/ZYoZB+unMZQrUm/bC9kC7+W2EBgka Cb/XtsQB5nsqTJsBkYJABrJugR5cYP42GMGaHYBrcf7roOKEqEG5ZZCIwHta346IQuBV8IT/ UGEKIZfAtkVRaGVr3gyZcr3TTSpoLUoc3XAovJIBcIfvsyJB7EE5NMrOgexroAIXkjGmqdEg /ZOjHuvXNYLk8YphVB/SardFpngOOp1b3umG2Ly3PSaHygtiGskokOj5rIzp2x0ddThHhUjw iDUknvFKSMpKIo8goqTe37IHuiF+soaFZErDROa1kYVtgrQ0Is1EJr84PlCNuLRYEGemOxE6 cZK6ROMsk/k3xA0Rjkg8XOASI83GKc2C+FtmKWN5lAk+DEoNW5kfr9YK1fRsZB9DnxzvGLUn CpOHTDymDZcIyRDR82Jn7P+iDU2YwXwujYr6bCf+2rhNbhr0oAhNqEIXytCGOvShEI2oRCdK 0Ypa9KIYzahGN8rRjnr0oyANqUhHStKSmvSkKE2pSlfK0BKw9KUwjWlC7LGJmk6qpgXBKUIO QI6atqMrOrVHO3wK1E2YRqc8JSqUerqJn/5Dp0/dhFiG2tSu9PSmQd0EOQZS065KFapZtalA vArVqNaUHEf1ajvGSlazKpWrUj0NU526xq5itat0FepbwfrVtsLVq1N961/t2tSBDJWmamXr pahKV6+ila2ALSs3EdDVxEhWsobdxGa0GlXMFJayaz2rYg87Gs5mdrNb5StmyLHWf7SDHPY4 gFH+PStWysZNtYotbU0PhVmdkhaphb1sXGm6Vbi6VrOlLW79Kptb4q62ta8tqnFzaxCo2oO1 AokuQSQ71OMEN66yDW1c64Jd18K2s8eV7nbH+5EpyCu8m7Ase9Fb3fjmVKqkXe9scbpbhPR3 vcYdqmlAa9vTMFe2tx0vbuHL2/mil6biNa5wp6vY/x6EwdTFqYBD9F0KY5a6Gy5ta6krFpuK VbXcna2IH9xhACNUwKad8EEYqymc9rS+5EgtfgWb2ap6WKo35ipsOdvdwub3x9OFsXLpy1Vc SFjBfb1viUfcWRrP2KgxHq59gzxWHSP5IFDl8lOXjFnZ/hfF8xUzZ9H+XJB2UJmbnA2yjC/F 1MJ2VqddjapsKSvV6+K1IH72KWQjy14ba9bEh15yhska1zgX2sFsNrBhGO1WHxs30Hbe7lbl rFb1VhjKFJYyictKadoiF70IZjKT+QtqSrsZoaA97mXm/Jq5dpbLrP5HjqGKAFsXpNeCVq2a t1rktRa7vkiOdYhVTV9WM1fVOI21i0fjaw4be79xpeymC+3lRft3vMOedqGeTVb5FiTckS6U JGdoZubSeqe5zm+u+TxfM8M7yqNVcazb7V0Lf7mz7bZwb7UcYVFPN9WhNjB7A25f1YY41rhW 7ofp+/BMqxqxGGd2igfcYggzO6EbjvW7B9L/08t4HKcet7dOmarr2Xqc5C5vcWev+1Ohnhex yMW5DHFb5dlKW+Nx3fDADX5V45bcs1QOeccLS3N72LwrqUb4x+nb9KeL+7jeLfjVq65d32Lb 4HDOubPzXOrAatXcmGHsrLONcqqSI256Pbu30y7YniqX5cj2tlgRm3C3PhbohB73iNt+1gR/ buyWjjtd5Sr3vpNY8Wlj9MvTO3DA0t3Sjk1r4GXK+c57npuj+LzoR0/60pv+9KhPvepXz/rW u/71sO/JqfPs2a3qfNBBpSrapx4nGKGFNp/JSylABpznUKFBeX8yyYfs17rY1eBhRW7RzVpi vOv6vIWaa1Etf/tK/juV0qxOq9kXP33aO1chE5dI+mf6/GYP18oL1n6lHXzc7GvV00qJeW3t S+8GO3+tIgdq5sEioVIjD+IWnEEhbmEiblEKyJd8n5Zd55V+/Qd9bNdfe2Zqm2Vv5gUypKVt oVaBLCZxrZZlSLdiEaN/yFVg6Ed/E7F++kNuoOZxARhgK2haHxd3HHYAJ+eCRWFf/CZpBtZd 03Zkc8cdY4EuosEWzKEXV2IbbAEkCTFhGqZi6Ydh0wZcRFhgQYhgVZg1/hZqWMhzaPZ1Rrhc /QaEamhfEshnUYUAr1Ui/wV5bUh4WgVsh7dkYwhqZ4hmkvRhTeV1YJcURBZfRoZcSjZt/2J2 hB8yGE6oFk0oGO3hJlD4F6UxhfPFamaGVQmRiFkYdFhme4UYXpRniKfWY4tHYp6YVYNXgjl2 ay7oXMd2WAjGhfGlcvHlXLW4ZX1WWAhmb+1gcmenhoeyiqC2iO53XJbmeAWnVUMFXW+GFFeF aOfnaJ9YX83XiJCxgAboGsJHfILBgGcBKmCWiX0ViPJleULWcvflV9bYchhnYjqGjoBWZ1RG atuGe4vnh1iGb7QnENN4aInGjmNGkLkGi13WcsEIc811AFTlcUb4jpFGdjNojy72CXlnU8oW jUcxi4YIgIfYIjz3b9pYib93LLYxiUeyJnTRJOUoZWLFaTF4bf8Qo1rKNlseSYoxSX/Almm8 FpKd9XPJaGMsh2vslZPftXkHiXhS1ZOPhWdNWVWGdn7WJmvJaJTJGCLVln5QqViG0hRdeGDl RmF9KIBIaICvUoCHgh3cuG5UCF4N54IM539eOZZh2V/AtW4cSF9ziWpsOJRRWYWcOG4YyFyL KJNdiYyjIVv5eGeNtmNESJiGqWDENntARplQMpKiJpNPcXu3p3St+H8r1gRmqY0kUiqROBDW wYQPwhvU8W0wqWXdZhCgeY216ZnPl1VLdnSTB1W1GWaWqXwt14trtZcaeJwIlnK3uJRSlZyH 6HSc9YtTaW/05oE+54vEeIL2FnW8KIz/oQmbkkZTk+aDRWF3MPeYh1eaevV2jHgkneArrekX zxEkrEkg/IGNFElx/aiOUZWe17h3K4eDeOebKnZ57Plj/glVpAiYHPZ+PpU15gmQCtpTI/Za uJhbSdVadGhe1JljHCha6+WfjHegl7eQI5oYcUeiU8eXPbV7sVdR0/eiMkoRZ2U5M3qjOJqj OrqjPNqjPvqjQBqkQjqkRFqkRnqkSJqkSrqkTNqkTvqkUBqlUjqlVFqlF7UDVpqlwgEHWtql XvqlYBqmYjqmZFqmZnqmaDoTALCmMAEAA+GmHLGmbCoQcjqndQqndWoQd0oQcEqncuqnf9qn fQqogpqngMqn/39Kp29KqIhaqIn6D4+6qJD6qIY6qYlaqW9KqZI6qCklqC9hpx3hqZCqp6Sq qHx6EG4qqqNqqqvaqqyKp6W6qoMKq6YqqrYaq7MqqbK6qbhaELfqqpx6UsFKqWxqp5d6rKDK qpOqqJUaqI6qq6+qrNLaqpwarKOqqtgKrdQ6rcN6qtv6rd3qqwiRreDaq966q9XKUulaq+yq qszKq+maquK6q9eqrbqKp4a6p5Y6rPm6qZHqqHOaqQGrr5YKrbQqq5rqq80asNFaq8SKrPw6 sPJqrya1rvQKq7YaqPA6r8aarBiLqed6sPZqrdzar8B6rxxLsby6shc7sgqRqw0brv/eKrMs 66oo5am/irGLirMbO7MT27L1uhC/eq4qa7PlerINy7IyK7IHS6vkurQhW7PcOrXz+q0r9bAr m6oP+7PuGrOXyq77Kq0LC7Eiq7Aae6rkarVei7UCO6sDe68Sy7Zw+7Zmm6xAG7XTinokK7Qd tbcq4bekB7h6KrgTRbgiYbhpmriKiyxjsLiOmyxf6xB7G6kMAbiIaxAEkLkEwIaam7mt1bmZ +w+gi32PqxQ8K7njWrSxmroUEbquRQBd4boHQABr5boD4br2sLmluxRui6/PCrbairPF6ru/ 27UMgbu0K7oEcLvLa7sCYbvOu7tHEbmni66o+rZO+67aG7T/EwG9zbu8z/u9BYG8iia9SDGx 1ZupfBu02Vu9PysR3qu8EZO8oPu9mku65lsUp+u+24uy7NuuOxvArQu+8gu6n0vA4TsaBFC+ +fsWP3GshxrB9NqoePuxcZu0DoG8tYvACUwQsksA69bAF3K5HeG67UAAlxG98uvBBLwJsCvC Y8KwLNG5KqbC9bvCp7HAMLzDPNzDPvzDQBzEQjzCVYu6EBG5H0G5BSvBSjzED1yoEXG56Run BivA3EvCTiwTEhvBY6u1dguzc9u2TPyyVby975vFQiGvamzFXJuyFgu8Z2y8qFrGVxy2aBwU a9zG/GvHcZyyDku8hOuu/CvHd5wT/+3Lxtt6qxaLvsFrtOuLtHVMyIV8E9m7xBnbsXKMxBAr xo5MwX8ssKA8yemBxaJ8OTJcyqicyqqsEvKwyq78yrD8w02ct+MKslEsEUost7HsE4RMwqRc xA0hyIi8y7wcvM76xRyLrIxasEhMxso6xcTMy//ayNzrstkKzY8Mxl78y9HMEloLrl+7tGeb yHnqy3Tcxt28E8Jsxv0Lx1bbx0d8zmqbzjiRy5uctwALrJtst0JLt7pMz07xy5IM0Opyykds 0ASd0AllBArd0A790BAd0RkxyxQRsSRbthPRrEor0X+rurdctdbKzeY6tCLN0R+NssfMxSkd teVcrMvMx/+sO8HYbNIgscjvjMgWTaqVXMcvm7CQTNMkYdPYWs5WrLRn27TzPNJ0DNQjMcj+ i9KlitQ7jc4JQdJEy9SHG7dUHbbCC9KM6tLgzM+N2rvAXCZaABOt7LgDjdXyQtFs/dZwHddy Pdd0Xdd2fdd4ndd6vdd83dd+/deAHdiCPdiEXdiGfdiBndaIvdiM3diLzQ+QTRCQHdkCMdmU bdkGgdmVrdn8UBCW3dkDAdqhTdn/8NmjLdqnLdqaXdqrXdqS/dqgrdqSjdqhXdusPdmuXdm2 jdtAHNu2ndu0ndvCrdvEHdy0HdyuLdvFndm/TdzAvdsH0dnK/dys7dy+7dnXfdz/uu3b093D yv3dzO3c1i3e5I3c0t3c5D3cng3dy83c4F3c2a0Ql53e533e6n3f+fvdvH3bl73fqZ3a1w3g 473Zqr3a/k3g/U3api3c3P3ayU3dB17fCN7g9n3bSfoMM/HeDu7gxj3gG07frd3eCKHd7d3d E77ZDA7f4k3i873eEr7ePxzgHQ7j6q3h6D3j1J3jv03iOR7gOz7g2W3jKn7fEi7jvU3aRM7Z N77bnI3Zps3iCm7gSI7gP87fFb7dsO3h1R3ewG3gzb3fyO3YYh4Rn13mZn7maJ7mar7mbN7m bv7mcB7ncD7mdF7ndn7neJ7nej4w/arNp9y7ZE2ogMy3/28M6Ey7r9u8zn6K6ILeydQcz5w8 uL+7xJQezG4tubbsx5KO0FpcEYwczNTK6UlczXMcwP5cxU9bs2dc1Yve6jzNzo4s1OqbqzQ7 uOp70Fft1U5Ny6Xu6EYM6p0MxjYh0MBL6Bjc1BPc66bezntM6u+76r2+xbCuvZkc1dZL68qu sLeuyWjr0d3OzqQMs2z7zbkezhorw+J+wVy87JT+zzvr7p9M7pVeryENqn1evNy+1bbO7tA+ 7X2srwTbq2tsxvfetsars/Serxqdunk8zCF76ZH87qK+unr87s9M1MzqtExrshEP7lLt8N/+ 6hWM8MEu8Ixs7zhNsYKL8vQeyv+XXLaf7utQHfNTre9Ty7M0n+3djr7hrPO+/vHTXrlo29Lj LOxfvdFGDcHR2uyNvqwMX9TRvvSZbrT7C+sYb70+P8cnb7ODzvXiOrSHWvQtz+hHm+zWvOxg L/HM3PKK7POTC9VBv9LP7PV4K7bDrOgY7c5MX/JaD/VK3c46X/Udz9P9/vbs7vRpv+pWLfMx y+xln/ch7cZSy+uH7PR8n9RzD+7e7r+DfOg++/gVnPLUTtUVj8+JrPIbLcm7/rGjf9Mxfb0s /6p06/ftPvQUnbNej+0SP/tXTfLXuvClrvGYr8+CrPCTDvFj7cmWbPlN79JQrOgIe/xb/Ozq Xvt3z/v/z++vlqvuhzz9rp/1SVHSw64R4Y7HwyH+jB8S5Q/+psu75F/R5i8c6J/+o37SZb3n +J//+r//yZIL/P//APFP4ECCBQ0eRJhQ4UKGDR0+hBhR4kSKFS1exJhR40aOHT1+BBlS5EiS JU2eRJlS5cqKAAYCgPlSoMuJMGn+sxlzps6XNnvqzOkyaMGcMwneRIgUaU2QSw3SdEr0YNSj RiNSlYkTos+TWFV6tRgVrNaPN81aHTs1q1W2SrOeXep2rdC1CXmmXYj3al62SZ8yhCoRbGCH Z03qJYl4q1q+Hg3/pHsXKNm+lB+/rQpXal3NlBXSJcv1MVSenkGLxml2ctHU/kpjClUN2zVo rbIjxzaKu/XR16l/bia6GrVk0pNz74zLdbflt6VrI0dL/Df04KFfA5XseePl5767144LnHtV mXCLDiX/3LnfwJ1PM+9rHPzx3IQvk6b/HXP96Plhb75vJ//Sm8u39torL8G2OFOwu/fuI0y9 BmmjkLze6HNPscLqcrC88/5KbzwGWQtPu9bwSwtB9CKzrMS2PhxwNKciLI62/b6j8UQb0WKQ OfQq85FHw2AMTbv1zBsOxxkhu000J5kMEbnTiNSwIe7eyw9IF0WMz0jxgFuQN7lYlIrMHsMs sDOyGKgsRzVvrDBIAnnsUk4Qo7TPzjh3bLPBBHfc/rLML2/80r1BO5KrSD1NhK9O0wj1ss8o GzOwQDQDXHC1CdFU1EE+7dtz0yUb7TTONBU8EENTAz31UktdrRDFTZuzrtRaHQtONfhQm8q5 5EC9K9cLhQRzMAtLgzBR04SbTtfletr1NvHMHLY4La3lLVqxpFNUWgFXfcrX5hKdrVjjlLsQ 3SOnnO/ZYRFlKV55OfxsXntRqrLKe/fNSF9+/7VyMYAH3k4wgg9GOGGFF2a4YYcfhjhiiSem uGKLL8Y4Y4035rhjjz8GOWSRRya5ZJNPNmgeg7xBuWWXX4Y5Zplnprlmm2/GOWYXBe5VN3fF ZWpOIOlcTDF//x2ToqMN/oY0r/VEWrri7K6iSs1Y6Q2aUgCZ3uvipLNObOsNh24K5ql59XKs q7PMTDlYvcP2v9/kfhZaFrHdzUkE66aORHXd/Hu6SqGj2+2+vVuOtcENT1y6woHOtT5m+0Z7 yl91s03wg+9eNDPAFlV8QMxSlZC/R+EmVVb51jaPU6tBFzV2xG811ce9cawV0077w53e1klf u/fURX0Qa345P5HtCP2CvcsrS9eMVaJtI1dJn0p882kqm8f98toBdxsATybdHklkIQX//EKJ ja5a5Ue1Ll3Jnz5ewiGNDP3Q4N16nszoD7VV1f7EIez5SVLdkx0C54SpNy0wgcEbVAHZ5jtU /sVoVnyKlAJvp7A84YdsjHLU/jynpVdRa3id6w+4DCW607nvdbKyoKosNKtMoYp130NfDQ/I OtOxazQAzFC3SDWwPA0OhKnzm88MVztXqSpHdhtXuEpHncYdTnPf6py6ehc4LEKxfeF6Ym+G ZDkwEnBP2uNWBxEnxlddcYwdip/xHJaikNUgZwiL2mHAVpI8xgsvfbxjIIU1R651RZCHRGQi FblIRv6LDY2EZCQlOUlKVtKSl8RkJjW5SU520pOfBGUoRTlKUpYSkTvj2QjF8jlKGater5Tj DD/YL7UsjyPKwtrSABmWDdmSkaikpV1YKcxZFtNoAROaIaGmtIvs/7IlqcRj8ijHrcUJJ43X Ox81lyhNGGETb+9qnGwOl0QxUTGF0xRnOs2oRBPG7XroLKM0jRhH8FyneuFU53Hw1izUpTF5 5pMSPfn2leLF0FO2K9ILq6PAR/1PgzYkH5xQd8IAwfChtmrVQR0KPRQ2L5sDVN4DA/jETAEP oQEEqQj9SKft/dND70xo+SL4JEHps32Wcx+UdkXDI7nOdjCFYwNdiieIYqijQxUeAoWKUx76 J3QKNaibUqojAc1LjVG1E0szCCgapm2qK2wj/KR6wOmNUD9yGmtGdaifval0rTjc6Kd2h9au EhWr97PgBpOJL/a5sIt+TWgCdZjTvMpwrP7qw+jrKDqiLl4Ul7mDqOq+2lWLsit2Qm1UUwlb vcmptLIdUixLisjGc1ZztFZsV5jSJa7o+RBu2flVCVe3z9dij4wIXd62BLpaT6Uqbmbcoo1+ 2zpzAQ6L5Ypcux5HI8nq87YDtZgzTck8ZkYzYsCMZP6mW5ZmWve6YNpueMU7XvKW17znRW96 1bte9rbXve+Fb3zlO1/61te+98VvLckKIukqM7//DYkvX9lfPQLYwFwDqNwyN7c1rqtG/Gwu /tgpzsQd8cD5betBpzim23GWeKU9HUOxlFr1WuPCz/QfShn4UmSVr6WBXShVJXjWE18YeSM2 oUQFaNcSTpBokv7CbI0N/EOprpiF3DsjBe+6ViGfmMhXg5C24jnG3DKRilzETm6bvGWJcYnL X26Z4ggMZjKX2cxnRnOa1bxmNrfZzW+Gc5zlPGc619nOdy6JKo5HJCvRr2zErOkqW6m1vQh3 X2obJjTpOMRi8kVfY8aIgOvX6DaO5NGwpC6ieflY0Saaurz09JgvvTmGEZdv2zrQ5PA5WNbq 7baxzVuW52fOzE4xtYzDMhdX/U5r6c2LzdqmaQPKa7+KGVCaKqc8wblan/WQnsud9Tf9XOB+ nilND+owCis62SzhdaRlHZ1NXXNkqIoYrYct6ltVKcLT2lSGp/Lwu0H8PZM6m7jZ9v8yH68d vjth6Yw5PfZfHPrg2axO3VUVVPE4+9T1vQ+oIx7qUHQHVxZrtoKhDdLlOkplD/L4hS2lHsJX ymShrZDd4b5TYRlqIm8zcUkpNrSPt5rVmZMU4idMKgTpSleMbxTJHncgC3V+vx2P/KhQNeln d2hWmDd2p2Vteb9BWlUcLtnqbzxsvBvaWItn1LI15PC5jwXZ+GTb3hc8akp+CF0sEwu2tU7u ZV0L68zOltZv41+zr2zwnxl33Ap+e7IZ+GoP7U6xy0Y2FLFeHRhuUz4V9udfqTmyfOG5YGPj 60P0AmmRaYjzcFYb4wIsekwT2vKnR33qVb961rc+Idhwfez+ZT972tfe9rfHvewrrzWvSDrl q9Q0ZMg26liqXfNsrW7pKS3HPPqeiMt/fiE/3Zg/7tXCjqIx9GM8beMXzfqmTzm8gvmwz1t6 77jxtdMXTLgG72zB5FR/cr15/qQ4y9WCY/as4clvsDdU77FOMijToryTNcirJ/TLP3kCtlZz ItOBPJjStecrNxy7FXKjOpxTKlaLMZRKO/v5uc+Sn3LrK1tLvHgLoriqwC0qqb/iOcqirHpT rpPCt+JbqaWCwBfLuZLiP5WTuFxiLmbDDmHyn4cbtooToh6coBtDvvlJDh1DObdSwSy6KRjL QQsUup8COKqaHQk0ILDyKSPLvq3/czfpEbjBmr4BOjmD0qpAeTnQCjEMkqXDo0KK0yrRmUFz 8zqgU8OdKjoujCH5kbcq7DmmgyMNc57Swrj9cC3D4rojFKweEy6zM8NqysOOi0I51CisykNo ER4Fk8JEnDRdEyNpE8NlkbJByjhS1LjXUi5tisPjopXGO5cvOqlJIcH2mzJZrLXFQzvUGi1p +a024TtngzDM8aIIzL3wI5nN0xhmTEaoIb2QCT3ugxhnfMZrxMZs1MZt5MZu9MZvBMdwFMdx JMdyJK/dw7Te065bOsPxuz5AozQCUxY4NBbsaprPoEZ2hEca/DFP04jyY4yuUT7wY0eAXCOl cZZOY6yA/2QPgbFGg/Q8zIOmf1RIUbSnvfM/7RG8KLo7QmySAjQ2AQKWJkI4kLSh/7u/+BO+ B6w/9QmfUXSjntE/aOOmkyyT+du1BHyqAtxIEpmoyimbCeTAjyIh1eLAI6IQLfu5MnwoLUMe GINCpJvHb2MUrho8K8QTbLM6uPtD2YlKn+KPpOtAWrJBIKRDltOpZQlCQLO5TVxHFfFJMxE3 LaS5KyFC3bEeKzsrS4Q6hms4swM5/GHK3gKsr0QiCFQ5KsSVBvLC4RkPEVm7D1qRHtPErZEr ufRAQdvLMzFMozqyLgy6IBMrR9REDAqPxjSUQcRA0twwmSNLr6RAS7SytfM3vf88TUKRyoDc LCUDzDmkqBsikNpktM0EQ5fzyrMzouc5RM9sShfEOX+rtsjkrr5TPFUkxOJSrefCpViBP16c yrp5TJYyOGmbkRxDvLUkLcObHdoCODQyxsB6O+mkNe70RWFDorvjFbikRe2rGYP8PgBDx4+x xn+YAkXyT37Er4jsPIk0xwZ1UDqzggeVUHm5gAm10AvF0AzV0A3l0A41G3dEUIFUJVAbyImU vn08UYacKxQtxP8U0QrSR/DiT2U8vu6azhulNhJl0e7zxxedPudjUBn9M3nRpWey0bAAGqDs E8KTMPxrp/2Dp8jhNcLhyfQkwPJsK8LDHAfjJ+oMHJr/ZLEirLBk+xkNyrJXw7XEe7Z/Qix3 usiBa7HhkjwKi8ZM80jmvECf8ygo47Yq1DCwWsRSXLh520KSgh0RpB3H7NOYM9OMW9TnLFRH DamrK7zFIsbCDNGAQjvMjBZOHCQ2TLeCSqqDVEum4sOaesNd5DNw89QeREIC0kGi5CikEtNK LEnfnDi0RME2lDEYzUtyIUImbBEEu84bIyzFrEvByjBQFKJJtBSr5MxdlFFDzSFUmjF6lFQI YkxlNSrVpDE+TcK5AtThPMptdVEA4R/KbDhbI7tMrJSB2zhfbbxQHUytA0H+itZdBc14hVeL atdFtFI3xMrLnDrTtNV/7RGl/8NU/nyXfYJMjrSlBKRELWXSJp0nmCzT8LTLKlvThUrT98y1 bKEyVAVGWBRZjGyu4ahYWBuVJHFAzhjPCDs1mdXJbxJQism38TrQHZWa/qxGdHGvnVVRqalT DzXao0XapFXapWXapnXap4XaqJVaTCpaZBLaFNW3IEUmIX3Rq/WvAJvRz2m+oV2JnGUlrzVR gAGkqEHbr8haXDE/q7pJbYrTW+PScVLZBTRUMP1YJ81A6xQ8x8NJl/3SbOrbuCPcdYGe8dzC cGqbBrTbVNNOP4OJPpBSZTvTLkUbo9vKsPNT+hTLyqy2gRW71tLATexKYly5zwW6YcydtPLE Z/XYif+KwXsT3Uq7Q3PTubIlWQlzSSOEVc/8t1BhFb/pGa5KzFfVuG1zomox3iVdp+2cEL/s xHjtx9DizmANucYVkwLiuGSlVYV8xB0Tzb/s3En1U5JTKOVMVeZtUXKNWEgN3lFF3c6M3ys0 V2Q1HuVMQ+I0IPGFXUtlXZMb3d38y6orzLlrFZc8y9g8WOdsU20bOyL7FqUUV0n0RDlkVr68 Q8Ba3Hc8jGDZzyX6t3gaU/00WUbzTsUFXDZCrnl614VsxSrb0uv8NfpTSymKRF3xFjI9TRp2 wMqZXLuMlAA8RZn9pT3KUU86puTrUYo8MAV1205aR4Lc2icG0aldPXbQ4i7/9uIvBuMwFuMx JuMyNuMzziRmZFSwxWJrAz/is1qkIdtzpVGu1cy9attTKjQ61lGedeOBLD8gvRdX8lGuZdE+ lBmLnLBivKaLhETkmzwcNrbgotPAc1zGo1I5fT/MLRcwLUbkzNvFrWTbCqPHu+QxnMVpokU0 pds8Fsj+ZTdRHbpuZStJ/MBGHFfZBMuFbUX4hGBbtt3OqlShOIHUFVTueTpOBFcntN3zJT+a KsnnvdWYussyVLis3EF1Q9QaQeB87abAbM0fGSkS9mAVuqAb5LfJ5OZUnbkGw1fnAiqkOraq lWPsW1EgYx+1mstblDlQ3crrTdh8FRvZDWfmKV+D/yIHaaVU/Qq0YsmhOkFePaVg9K1GXBYp AkZUvMuWAYZNhM06WWqhprpEPIS6hM1gDB5dd3XfyGTU+81AkH5SQmXWhJFYRdbcVa5UW5RL T5bkWJxTqrPk2tJhyqlPX97PRhwoF4ZBluxUwCPl4DRloCWfVAbqkTTFEr4yNI40Q65jrWYv e5xjrxbrsSbrsjbrs0brtL4jC1Drtnbrt24YsJ5iri7IEFtig3ZIrb05e1Ziun7i2+zqdoQX l35mT7UX+NEjTlumNiYmtk3HrS7RGg0/rEAMZQBIQS41+8tclMXbRqYwVS7qYHPUvLuiVUPc c3GcUbRkYovJJFpZk5TFUf8OXCydG9jOUtIh0yBuZf1xKWty5YB5yjR0IVmmuXK13mseN44O IUltzkD0oAYW2CVsZl7+mvaV1+iUQVtMacO8ZuwOW7cdwvYcbsQ8wN1Nq+zUr+6OVXvdvg95 1XzuZmG9rCkE1t1U3paFWWiODXAVYd+d6rWky312YLMdZA88XwlC3m9V3z9WwpYGoQ2G3tA8 7v/lwawKYIou4j+uw5dmVUgFQ2uGyoIttb4CznvF1f8NYKXT6Vom3VzVV1p27oOrcH8Flaa+ bok6WBRRkeNO7kCdzQUW8YX5xeAiu/zE6ZdtEXYSqBU3tEgeU4s94Wsicppog+Scz1SErB7f aTT/nU/aok5W9JaVxeScrmmNXEEUDLP4+m3J/sYqNi83V1t6hms2OwdQYpk5x/M8Fxlk0PM+ 93NszIM/F/RBJ2vMJjVCBxlDJ5g1R3TH6OHDDUlG3Fgnle0wbPQR3+7WHWak1ubrzseP4WKv Tp+Cy14D/pT9jmgKv3RCKu6lkx69emgnXHWKGAK5tV7dpZWixPVWn/XMPsU56NKO5XQflvIn B+Fe/9DvRvZLErNld/Znh/Zol/Zpp/Zqt/Zr76R8wPYNtdxt9/ZvB/dwF/dxJ/dyN/dzR/d0 V/d1Z/d2d/d3h/d4X3YBoHcBGIh6t3eBwHeC2Hd9r3d///d8/4d8F3iC/x/4fS/4guh3gC/4 hf93hb/3e394fBf4gY94i9d3iad3ft/4jPd4ju94jBf5gw/4i6d4hX94hgf5hg95jd/4irf4 kyf5hP94lef3m/d4mF+vijf4nDd5nKd5kaf5ju95ob/4oy96jNf5oPd3n0d6gyh6oq/5qHd6 nM/5pP/4oU8Irf/5rh/5rzd6sOf6rw96ey/7mmcvns/6tR95qmd7pe95pjd7qPd6pad7hJD6 tj/6iOf5uAd6utd5vT94tA97u8f7uk96t997tl/6p2/8tVd7pk97oE95h6f8lj/7mDd8sj+I sYf7ym/5jJ97wRf70df8xCf8l797nzd9pO93mf5/esFX+5mHestneaJPecIPe7m3+vaa/cfv fb+PfcPPe85ffdQH+96H+6lf/M0neOR/fOAnfuD3fIiv+s0n/tW/ecnH/uQf+oUnfd//e+sP /uvP/Od/e933fKwv/Ktn/tTv+uJ3/vSX/aYn/+q3eugff+kvf+uH+cAHCAH/Bgr8V9DgQIIJ FzJs6PAhxIgSJ1KsaPEiRogCNh48mNDjR44fRyoM2ZHkyYUgCYo02ZHjy5UpDbYsqRIlSZob Ve60KbPmzJwpYYKEybMnS6RBdSJF6LJg0JVMbfq8mfEq1qxat3Lt6vUr2LBix5Ita/Ys2rRq 17KFOK8t3Lhy59Kta/73Lt68evfy7ev379dIgAcTLmz4MOLEihczbuz4MeTIkidTrmz5MubM mjdz7uz5M+jQovVmGm36NOrUqlezbu36NezYsmezrjnVoUejSX8qBapb99PdDWcCH2pbuFXk OW8njwlV6PDmyqtSZwpV6XKERBnaBk61OO3BQ5OPJF6d+nju2Z2yb8/+Oc6SS82bV1g/pPyb 9+3jdxoVunbS5UfVe9ENWFV9UoWXl0zk8Ydedun5Z6B7Ba4n0H8WzgfdfRgC2B98+XnY4EsH FhXgSbldGOGK6nEIoIIL4gWUgxKGeKJ8vrXk3YcVtqeihscxZyN6Qo74HX8eCnikheUF2Nvk Uta56CON8flXpYyAhejedhqyeGCLUmU45Y8QVnjjbyileSZLSKLI5Zo9bchkl032aKeBQHZ5 Y5Z9ScillXwuSaGVAhLopolgJrpoeg3ShGiUjQpqaIeBTunohJZm2udf3R13YnFGYhkcnj8K SaB3WOL4ZHk7qrehT9196WSOTcHoYm7YobqeTkdtyeqvnAo7LLHFGnsssskquyyzzTr7LLTR SjsttdVaey222Wq7LbfdevstuOGKOy655Zp7Lrrpqrsuu+26+y688co7L7312nsvvvnqu29D AQEAOw== ------=_NextPart_000_0004_01C6C088.83EAB480-- From orion@dm.mailpia.net Tue Aug 15 22:27:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDB7h-0006Xy-AK for ccamp-archive@ietf.org; Tue, 15 Aug 2006 22:27:13 -0400 Received: from [125.187.32.135] (helo=m01.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDB7e-0007wF-Ka for ccamp-archive@ietf.org; Tue, 15 Aug 2006 22:27:13 -0400 Received: (qmail 8336 invoked by uid 0); 16 Aug 2006 11:20:41 +0900 Message-ID: <20060816022041.8335.qmail@m01.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCN241axsoQjQzGyRCS3wbKEI=?= =?ISO-2022-JP?B?GyRCMV9KXT5aQ2YheSVhITwlayVeJSwlOCVzIXkbKEI=?= From: 777pachinkovillage Reply-to: delivery_rt Date: 2006-08-16 11:07:01 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060816110302_cbrd Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 $B"#"#"#"#"#9b3[F|J'$$!#B(!"F|<}(B4$BK|1_0J>e"#"#"#"#"#(B $B(.(,(,(,(,(,(,(,!|Jg=8?M?t8BDj!|(,(,(,(,(,(,(,(/(B $B!!(B $B!!(B $B!!!!!!!!!!!!%W%l%$%9%?%C%U(B $B!!!!!!!!!!6HL33HBg$K$D$-6[5^BgJg=8(B!! $B(1(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(0(B $B!!!A2T$27n<}(B100$BK|1_0J>e(B!!$BL\;X$;%Q%A%s%38fEB!A!!!!(B $B!!!!!!!!!!"!5.J}$O:#$N@83h$KK~B-$G$9$+!)"!(B $B!!!!!!!!!!!!!!!!!!"-L4$r8=!$F$J$$$+$HG:$s(B $B$G$$$?$"$kF|9-9p$G%=%U%H%&%(!<%V$N$3$H$rCN$j!"(B $B:G=i$OH>?.H>5?$GLd$$9g$o$;$r$7$^$7$?!#$7$+$7!"%9(B $B%?%C%U$NJ}$N?F@Z$JBP1~!"$o$+$j$d$9$$@bL@$r$J46A[(B $B$G$9!#(B $B!!$=$l$+$i$OIi$1$k$3$H$bL5$/!"Bg9%$-$J%9%m%C%H$r(B $B$7$J$,$iCy6b$bCy$^$k$H$$$&KhF|$G$9!#$3$l$b%=%U%H(B $B%&%(!<%VMM$N$*$+$2$G$9!#$3$l$+$i$b59$7$/$*4j$$$7(B $B$^$9!#(B $B"!%=%U%H%&%(!<%V>pJs4IM}It!!>.NS$+$i(B $B!!E-LZ$5$s!"$$$D$b$J$,$i$*$a$G$H$&$4$6$$$^$9!#M_(B $B$7$,$C$F$$$?#B#M#W#7%7%j!<%:$G$9$,!"$b$7$+$7$F!"(B $B$=$m$=$mGc$($k$N$G$O(B?? $B"-i,i/?'$N?M@8$O$3$A$i"-(B http://softwave.fem.jp/ $B"#%7%c%$%K%s%0%9%?!<%W%l%$%9%?%C%U(B $B!!@h7n$N7n<}Nc(B $B#8#6K|(B $B2TF/F|?t#9F|(B $B!{?@F`@n8):_=;(B:$B#2#4:P!!6\Bt$5$s!JpJs4IM}It!!>>Eh$+$i(B $B!!6\Bt$5$s!"@h7n$b%8%c%s%8%c%s%P%j%P%j(B!!$B$*$a$G$H(B $B$&$4$6$$$^$9!##2?ML\$N$*;R$5$s$r?H$4$b$C$F$$$k$+(B $B$i%R%-$,6/$+$C$?$j$7$F(B!? --------------------$B1~Jg;q3J(B-------------------- $B"#CK=w(B $BG/Np(B $B7P83ITLd(B $B"#=i?4e5-$N%W%l%$%9%?%C%U$N3'$5$s$N(B $B$*@<$G$bH=$k$H$*$j!"0l@Z!"Fq$7$$$3$H$d!"0cK!@-$O(B $B$"$j$^$;$s!#$`$7$me?4!W(B $B$^$:$O"-$r%/%j%C%/!*!*(B http://softwave.fem.jp/ $B!!3t<02qM;{K\D.(B2-6-8 4$B3,(B $B!!!!!!!!!!!!!!!!!!!!(B0120-197-028 $B!!%a!<%k%^%,%8%s%,ITMW$JJ}$O$3$A$i$^$G(B $B!!(B info_wave1@yahoo.co.jp From owner-ccamp@ops.ietf.org Wed Aug 16 02:56:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDFK9-0002Ar-F2 for ccamp-archive@ietf.org; Wed, 16 Aug 2006 02:56:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDFK3-0007eD-V0 for ccamp-archive@ietf.org; Wed, 16 Aug 2006 02:56:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDFDV-0003en-Qj for ccamp-data@psg.com; Wed, 16 Aug 2006 06:49:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDFDT-0003eW-UJ for ccamp@ops.ietf.org; Wed, 16 Aug 2006 06:49:28 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7G6nDWp011721; Wed, 16 Aug 2006 07:49:16 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: Re: Polling for new WG I-Ds To: "Adrian Farrel" Cc: " X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 16 Aug 2006 08:48:05 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 16/08/2006 07:49:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi All, yes to all. Regards Diego "Adrian Farrel" @ops.ietf.org on 12/08/2006 16.56.02 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: cc: Subject: Polling for new WG I-Ds Hi, As discussed in Montreal, we need to poll for a couple of new WG drafts. http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt has been updated by the authors to provide further details and clarification. http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt has been updated since the version discussed in Montreal. http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt has been updated as Zafar says in his previous email. Please send yes or no for these I-Ds. Reasons and opinions are also welcomed. Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Aug 16 12:23:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDOAm-0003O1-U0 for ccamp-archive@ietf.org; Wed, 16 Aug 2006 12:23:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDOAi-00020s-3a for ccamp-archive@ietf.org; Wed, 16 Aug 2006 12:23:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDNk9-000KSc-SY for ccamp-data@psg.com; Wed, 16 Aug 2006 15:55:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDNk4-000KRL-9N for ccamp@ops.ietf.org; Wed, 16 Aug 2006 15:55:40 +0000 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7GFtQp20506; Wed, 16 Aug 2006 11:55:26 -0400 (EDT) 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_01C6C14C.6374150F" Subject: RE: Polling for new WG I-Ds Date: Wed, 16 Aug 2006 16:55:21 +0100 Message-ID: In-Reply-To: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: Aca+INzrNHRdUMHKSc6OnlT4eSXuTgDJK7JQ From: "Trevor Wilson" To: "Adrian Farrel" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f8666d0fe62cdc46c134d4b3d7d66be This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C14C.6374150F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, I have read the ID-draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt which I have duplicated below in a word document and applied comments and changes (see change bars) for your perusal. I have the following questions and comments (also in the attached): - Section 3.2: Is Fixed synonymous with no-LCAS ? If so, then in the Fixed co-routed scenario, there can be no graceful degradation in the event of a failure. This is more applicable to the dynamic, diversely-routed scenario (and in fact could apply to the dynamic co-routed scenario, although this is far more unlikely). Regarding 'graceful degradation in the event of a failure': surely this is a misnomer ? Graceful degradation can only be achieved if the VCG capacity is hitlessly decreased. A full blown failure on any VCG member will cause a hit to the traffic, albeit temporary. A hitless decrease can in certain circumstances, be achieved by using a signal degrade to trigger the LCAS remove operation. Suggested text for 3.2 (partial) Fixed, diversely routed: A fixed bandwidth VCG, transported over=20 at least two diversely routed subsets of member signals. In this=20 case, the subsets are link-disjoint over at least one link of the=20 route. The intent here is more efficient use of network resources (no unique route has the required bandwidth), (note=20 that differential delay may be a limiting factor). Dynamic, diversely routed: A dynamic VCAT group, transported over=20 at least two diversely routed subsets of member signals. The=20 intent here is dynamic resizing and resilience (but differential=20 delay may be a limiting factor). Graceful degradation is possible in the event of a TSD (Trail Signal Degrade) on a VCG member(s) =20 Section 4 Typo on second line of last paragraph: VC4-7v should be VC-4-7v. Section 4.1.3 G.7042 section 6.4 addresses VCG capacity decrease (temporary removal due to member failure) and section 6.5 addresses VCG capacity decrease (permanent removal). Each of these has distinct meanings and I think that this ID should make that distinction also, or at least be more pedantic in the use of 'removal'. Perhaps (as far as GMPLS is concerned) there is only the need to address the VCG capacity decrease (permanent removal), since the 'temporary removal' is an autonomous action performed by the LCAS protocol and does not require any management intervention. Suggested text for 4.1.3: - 4.1.3. Decreasing VCG capacity=20 VCG capacity can be decreased in two ways o Temporary removal of a VCG member(s) due to failure o Planned permanent removal of a VCG member(s) which requires management intervention 4.1.3.1 Temporary Removal of a VCG member This is an autonomous action performed by the LCAS protocol whenever a failure occurs on an active VCG member(s). The relevant VCG member will then be in the DNU state. There is no management intervention required to perform this operation. This member can then be permanently removed from the VCG. (4.1.3.2) 4.1.3.2 Planned permanent removal of a VCG member The procedure to remove a component signal is similar to that used to add components as described in Section 4.1.2. The LCAS in-band=20 signaling step is taken first to take the component out of the group as the result of a remove command from the LCAS controller; the permanently removed member will then be in the IDLE state. LCAS signaling is described in [ITU-T-G.7042]=20 In this case, the NVC value is decremented by 1 and the timeslot=20 identifier for the dropped component is removed from the ordered list in the Generalized Label. =20 This permanent removal procedure is only applicable to LCAS-capable-VCAT.=20 Best regards, Trevor Trevor Wilson Nortel Networks Belfast Lab Tel: +44 2890 363701 ESN 751 3701 Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: 12 August 2006 15:56 To: ccamp@ops.ietf.org Subject: Polling for new WG I-Ds Hi, As discussed in Montreal, we need to poll for a couple of new WG drafts. http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lca s-04.txt=20 has been updated by the authors to provide further details and=20 clarification. http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs- 02.txt=20 has been updated since the version discussed in Montreal. http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdo wn-04.txt=20 has been updated as Zafar says in his previous email. Please send yes or no for these I-Ds. Reasons and opinions are also welcomed. Thanks, Adrian=20 ------_=_NextPart_001_01C6C14C.6374150F Content-Type: application/msword; name="ID-draft bernstein.... VCAT-LCAS..TW-comments.doc" Content-Transfer-Encoding: base64 Content-Description: ID-draft bernstein.... VCAT-LCAS..TW-comments.doc Content-Disposition: attachment; filename="ID-draft bernstein.... VCAT-LCAS..TW-comments.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAAwEAAAAAAAAA EAAABgEAAAEAAAD+////AAAAAPwAAAAFAQAABAEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEACUAJBAAA8BK/AAAAAAAAMAAAAAAABgAA2o8AAA4AYmpiarisuKwAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIuwAANrGAADaxgAAi4YAAAAAAAAAAAAAAAAAAE4BAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAH4HAAAAAAAAfgcAAH4H AAAAAAAAfgcAAAAAAACaBwAAJgAAANIHAAAMAAAA3gcAABQAAAAAAAAAAAAAAPIHAAAAAAAA2qwA AAAAAADarAAAAAAAANqsAAAAAAAA2qwAADQAAAAOrQAAPAEAAPIHAAAAAAAAMdQAAKQBAABWrgAA AAAAAFauAAAAAAAAVq4AAAAAAABWrgAAAAAAAFauAAAAAAAAVq4AAAAAAABWrgAAAAAAAFauAAAA AAAAiNMAAAIAAACK0wAAAAAAAIrTAAAAAAAAitMAAAAAAACK0wAAAAAAAIrTAAAAAAAAitMAACQA AADV1QAAUgIAACfYAABwAAAArtMAABUAAAAAAAAAAAAAAAAAAAAAAAAAfgcAABwAAAC8ugAAAAAA AAAAAAAAAAAAAAAAAAAAAABWrgAAAAAAAFauAAAAAAAAvLoAAAAAAAC8ugAAAAAAAK7TAAAAAAAA AAAAAAAAAAB+BwAAAAAAAH4HAAAAAAAAVq4AAAAAAAAAAAAAAAAAAFauAAAAAAAAw9MAADIAAADS yQAAAAAAANLJAAAAAAAA0skAAAAAAAC8ugAASAQAAH4HAAAAAAAAVq4AAAAAAAB+BwAAAAAAAFau AAAAAAAAiNMAAAAAAAAAAAAAAAAAAMLJAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAvLoAAAAAAACI0wAAAAAAAAAAAAAAAAAA0skAAAAAAADSyQAA VgAAABzSAAB8AAAAfgcAAAAAAAB+BwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1NIAAAAAAABWrgAAAAAAAEquAAAMAAAA8Bs+vUvB xgEAAAAAAAAAANqsAAAAAAAABL8AAJAKAACY0gAADAAAAAAAAAAAAAAAiNMAAAAAAAD10wAAPAAA ADHUAAAAAAAApNIAADAAAACX2AAAAAAAAJTJAAAAAAAAl9gAABgAAADU0gAAAAAAAAAAAAAAAAAA 8gcAAAAAAADyBwAAAAAAAH4HAAAAAAAAfgcAAAAAAAB+BwAAAAAAAH4HAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJfYAAAAAAAAAAAAAAAAAADABwAAEgAAANTSAAC0AAAAVq4AABYDAABssQAANAIAALDJ AAASAAAAoLMAAMQBAABktQAAWAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVq4A AAAAAABWrgAAAAAAAFauAAAAAAAArtMAAAAAAACu0wAAAAAAAPIHAAAAAAAA8gcAACRxAAAWeQAA xDMAAAAAAAAAAAAAlMkAABwAAADyBwAAAAAAAPIHAAAAAAAAFnkAAAAAAAACAAEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhpIGFs bCwNDUkgaGF2ZSByZWFkIHRoZSBJRC1kcmFmdC1iZXJuc3RlaW4tY2NhbXAtZ21wbHMtdmNhdC1s Y2FzLTA0LnR4dCB3aGljaCBJIGhhdmUgZHVwbGljYXRlZCBiZWxvdyBhbmQgYXBwbGllZCBjb21t ZW50cyBhbmQgY2hhbmdlcyAoc2VlIGNoYW5nZSBiYXJzKSBmb3IgeW91ciBwZXJ1c2FsLiBJIGhh dmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzOiAtDQ1TZWN0aW9uIDMuMjoN DUlzIEZpeGVkIHN5bm9ueW1vdXMgd2l0aCBuby1MQ0FTID8NDUlmIHNvLCB0aGVuIGluIHRoZSBG aXhlZCBkaXZlcnNsZXktcm91dGVkIHNjZW5hcmlvLCB0aGVyZSBjYW4gYmUgbm8gZ3JhY2VmdWwg ZGVncmFkYXRpb24gaW4gdGhlIGV2ZW50IG9mIGEgZmFpbHVyZS4NDVRoaXMgaXMgbW9yZSBhcHBs aWNhYmxlIHRvIHRoZSBkeW5hbWljLCBkaXZlcnNsZXktcm91dGVkIHNjZW5hcmlvIChhbmQgaW4g ZmFjdCBjb3VsZCBhcHBseSB0byB0aGUgZHluYW1pYyBjby1yb3V0ZWQgc2NlbmFyaW8sIGFsdGhv dWdoIHRoaXMgaXMgZmFyIG1vcmUgdW5saWtlbHkpLg0NUmVnYXJkaW5nIJFncmFjZWZ1bCBkZWdy YWRhdGlvbiBpbiB0aGUgZXZlbnQgb2YgYSBmYWlsdXJlkjogc3VyZWx5IHRoaXMgaXMgYSBtaXMt bm9tZXIgPyBHcmFjZWZ1bCBkZWdyYWRhdGlvbiBjYW4gb25seSBiZSBhY2hpZXZlZCBpZiB0aGUg VkNHIGNhcGFjaXR5IGlzIGhpdGxlc3NseSBkZWNyZWFzZWQuIFRoaXMgaGl0bGVzcyBkZWNyZWFz ZSBjYW4gYmUgYWNoaWV2ZWQgYnkgdXNpbmcgYSBzaWduYWwgZGVncmFkZSB0byB0cmlnZ2VyIHRo ZSBMQ0FTIHJlbW92ZSBvcGVyYXRpb24uIEEgZnVsbCBibG93biBmYWlsdXJlIHdpbGwgY2F1c2Ug YSBoaXQgdG8gdGhlIHRyYWZmaWMuDUkgc3VnZ2VzdCBhbWVuZGluZyB0aGUgdGV4dCBhcyBmb2xs b3dzOiAtDQ1GaXhlZCwgZGl2ZXJzZWx5IHJvdXRlZDogQSBmaXhlZCBiYW5kd2lkdGggVkNHLCB0 cmFuc3BvcnRlZCBvdmVyIA0gICAgICBhdCBsZWFzdCB0d28gZGl2ZXJzZWx5IHJvdXRlZCBzdWJz ZXRzIG9mIG1lbWJlciBzaWduYWxzLiAgSW4gdGhpcyANICAgICAgY2FzZSwgdGhlIHN1YnNldHMg YXJlIGxpbmstZGlzam9pbnQgb3ZlciBhdCBsZWFzdCBvbmUgbGluayBvZiB0aGUgDSAgICAgIHJv dXRlLiAgVGhlIGludGVudCBoZXJlIGlzIG1vcmUgZWZmaWNpZW50IHVzZSBvZiBuZXR3b3JrIHJl c291cmNlcyANICAgICAgKG5vIHVuaXF1ZSByb3V0ZSBoYXMgdGhlIHJlcXVpcmVkIGJhbmR3aWR0 aCksIGFuZCBhZGRpdGlvbmFsIA0gICAgICByZXNpbGllbmNlIGFuZCBncmFjZWZ1bCBkZWdyYWRh dGlvbiBpbiB0aGUgY2FzZSBvZiBmYWlsdXJlIChub3RlIA0gICAgICB0aGF0IGRpZmZlcmVudGlh bCBkZWxheSBtYXkgYmUgYSBsaW1pdGluZyBmYWN0b3IpLg0NRHluYW1pYywgZGl2ZXJzZWx5IHJv dXRlZDogQSBkeW5hbWljIFZDQVQgZ3JvdXAsIHRyYW5zcG9ydGVkIG92ZXIgDSAgICAgIGF0IGxl YXN0IHR3byBkaXZlcnNlbHkgcm91dGVkIHN1YnNldHMgb2YgbWVtYmVyIHNpZ25hbHMuICBUaGUg DSAgICAgIGludGVudCBoZXJlIGlzIGR5bmFtaWMgcmVzaXppbmcgYW5kIHJlc2lsaWVuY2UgKGJ1 dCBkaWZmZXJlbnRpYWwgDSAgICAgIGRlbGF5IG1heSBiZSBhIGxpbWl0aW5nIGZhY3RvcikuIEdy YWNlZnVsIGRlZ3JhZGF0aW9uIGlzIHBvc3NpYmxlIGluIHRoZSBldmVudCBvZiBhIFRTRCAoVHJh aWwgU2lnbmFsIERlZ3JhZGUpIG9uIGEgVkNHIG1lbWJlcihzKQ0NDVNlY3Rpb24gNA0NVHlwbyBv biBzZWNvbmQgbGluZSBvZiBsYXN0IHBhcmFncmFwaDogVkM0LTd2IHNob3VsZCBiZSBWQy00LTd2 Lg0NDVNlY3Rpb24gNC4xLjMNDUcuNzA0MiBzZWN0aW9uIDYuNCBhZGRyZXNzZXMgVkNHIGNhcGFj aXR5IGRlY3JlYXNlICh0ZW1wb3JhcnkgcmVtb3ZhbCBkdWUgdG8gbWVtYmVyIGZhaWx1cmUpIGFu ZCBzZWN0aW9uIDYuNSBhZGRyZXNlcyBWQ0cgY2FwYWNpdHkgZGVjcmVhc2UgKHBlcm1hbmVudCBy ZW1vdmFsKS4gRWFjaCBvZiB0aGVzZSBoYXMgZGlzdGluY3QgbWVhbmluZ3MgYW5kIEkgdGhpbmsg dGhhdCB0aGlzIElEIHNob3VsZCBtYWtlIHRoYXQgZGlzdGluY3Rpb24gYWxzbywgb3IgYXQgbGVh c3QgYmUgbW9yZSBwZWRhbnRpYyBpbiB0aGUgdXNlIG9mIJFyZW1vdmFski4NDVBlcmhhcHMgKGFz IGZhciBhcyBHTVBMUyBpcyBjb25jZXJuZWQpIHRoZXJlIGlzIG9ubHkgdGhlIG5lZWQgdG8gYWRk cmVzcyB0aGUgVkNHIGNhcGFjaXR5IGRlY3JlYXNlIChwZXJtYW5lbnQgcmVtb3ZhbCksIHNpbmNl IHRoZSCRdGVtcG9yYXJ5IHJlbW92YWySIGlzIGFuIGF1dG9ub21vdXMgYWN0aW9uIHBlcmZvcm1l ZCBieSB0aGUgTENBUyBwcm90b2NvbCBhbmQgZG9lcyBub3QgcmVxdWlyZSBhbnkgbWFuYWdlbWVu dCBpbnRlcnZlbnRpb24uDQ1TdWdnZXN0ZWQgdGV4dCBmb3IgNC4xLjM6IC0NDTQuMS4zLiBEZWNy ZWFzaW5nIFZDRyBjYXBhY2l0eSANDVZDRyBjYXBhY2l0eSBjYW4gYmUgZGVjcmVhc2VkIGluIHR3 byB3YXlzDVRlbXBvcmFyeSByZW1vdmFsIG9mIGEgVkNHIG1lbWJlcihzKSBkdWUgdG8gZmFpbHVy ZQ1QbGFubmVkIHBlcm1hbmFuZW10IHJlbW92YWwgb2YgYSBWQ0cgbWVtYmVyKHMpIHdoaWNoIHJl cXVpcmVzICBtYW5hZ2VtZW50IGludGVydmVudGlvbg0NVGVtcG9yYXJ5IFJlbW92YWwgb2YgYSBW Q0cgbWVtYmVyDQ1UaGlzIGlzIGFuIGF1dG9ub21vdXMgYWN0aW9uIHBlcmZvcm1lZCBieSB0aGUg TENBUyBwcm90b2NvbCB3aGVuZXZlciBhIGZhaWx1cmUgb2NjdXJzIG9uIGFuIGFjdGl2ZSBWQ0cg bWVtYmVyKHMpLiBUaGUgcmVsZXZhbnQgVkNHIG1lbWJlciB3aWxsIHRoZW4gYmUgaW4gdGhlIERO VSBzdGF0ZS4NDVRoZXJlIGlzIG5vIG1hbmFnZW1lbnQgaW50ZXJ2ZW50aW9uIHJlcXVpcmVkIHRv IHBlcmZvcm0gdGhpcyBvcGVyYXRpb24uDQ1UaGlzIG1lbWJlciBjYW4gdGhlbiBiZSBwZXJtYW5l bnRseSByZW1vdmVkIGZyb20gdGhlIFZDRy4gKDQuMS4zLjIpDQ00LjEuMy4yCQlQbGFubmVkIHBl cm1hbmVudCByZW1vdmFsIG9mIGEgVkNHIG1lbWJlcg0NICAgVGhlIHByb2NlZHVyZSB0byByZW1v dmUgYSBjb21wb25lbnQgc2lnbmFsIGlzIHNpbWlsYXIgdG8gdGhhdCB1c2VkIHRvIA0gICBhZGQg Y29tcG9uZW50cyBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuMi4gIFRoZSBMQ0FTIGluLWJh bmQgDSAgIHNpZ25hbGluZyBzdGVwIGlzIHRha2VuIGZpcnN0IHRvIHRha2UgdGhlIGNvbXBvbmVu dCBvdXQgb2YgdGhlIGdyb3VwIGFzIHRoZSByZXN1bHQgb2YgYSByZW1vdmUgY29tbWFuZCBmcm9t IHRoZSBMQ0FTIGNvbnRyb2xsZXI7IHRoZSBwZXJtYW5lbnRseSByZW1vdmVkIG1lbWJlciB3aWxs IHRoZW4gYmUgaW4gdGhlIElETEUgc3RhdGUuDSAgIExDQVMgc2lnbmFsaW5nIGlzIGRlc2NyaWJl ZCBpbiBbSVRVLVQtRy43MDQyXSANDSAgIEluIHRoaXMgY2FzZSwgdGhlIE5WQyB2YWx1ZSBpcyBk ZWNyZW1lbnRlZCBieSAxIGFuZCB0aGUgdGltZXNsb3QgDSAgIGlkZW50aWZpZXIgZm9yIHRoZSBk cm9wcGVkIGNvbXBvbmVudCBpcyByZW1vdmVkIGZyb20gdGhlIG9yZGVyZWQgbGlzdCANICAgaW4g dGhlIEdlbmVyYWxpemVkIExhYmVsLiAgDQ1UaGlzIHBlcm1hbmVudCByZW1vdmFsIHByb2NlZHVy ZSBpcyBvbmx5IGFwcGxpY2FibGUgdG8gTENBUy1jYXBhYmxlLVZDQVQuIA0NDQ0NDENDQU1QIFdv cmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRy4gQmVy bnN0ZWluIA1JbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBHcm90dG8gTmV0d29ya2luZyANVXBkYXRlczogUkZDIDM5NDYgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gQ2F2aWdsaWEgDUNhdGVnb3J5OiBTdGFuZGFy ZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uIA1F eHBpcmVzOiBGZWJydWFyeSAyMDA3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIu IFJhYmJhdCAoZWQuKSANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZ1aml0c3UgDSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEguIHZhbiBIZWx2b29ydCANICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SHVhd2VpIA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBdWd1c3QgNCwgMjAwNiANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDSANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANICAgICAgIE9wZXJh dGluZyBWaXJ0dWFsIENvbmNhdGVuYXRpb24gKFZDQVQpIGFuZCB0aGUgTGluayBDYXBhY2l0eSAN ICAgICAgQWRqdXN0bWVudCBTY2hlbWUgKExDQVMpIHdpdGggR2VuZXJhbGl6ZWQgTXVsdGktUHJv dG9jb2wgTGFiZWwgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3dpdGNoaW5nIChHTVBM UykgDSAgICAgICAgICAgICAgIGRyYWZ0LWJlcm5zdGVpbi1jY2FtcC1nbXBscy12Y2F0LWxjYXMt MDQudHh0IA0NDVN0YXR1cyBvZiB0aGlzIE1lbW8gDQ0gICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50 ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCAgICAgICANICAgYW55IGFw cGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlz ICAgICAgIA0gICBhd2FyZSBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkg b2Ygd2hpY2ggaGUgb3Igc2hlICAgICAgIA0gICBiZWNvbWVzIGF3YXJlIHdpbGwgYmUgZGlzY2xv c2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mICAgICAgIA0gICBCQ1AgNzkuICAN DSAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nIA0gICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdv cmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IA0gICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NICAgRHJhZnRzLiANDSAgIEludGVy bmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocyANICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgDSAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIA0gICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iIA0NICAgVGhlIGxpc3Qgb2Yg Y3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0gICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCANDSAgIFRoZSBsaXN0IG9mIElu dGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQgDSAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCANDSAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgd2lsbCBleHBpcmUgb24gRmVicnVhcnkgNCwgMjAwNy4gDQ0gICAgIA0NQWJzdHJhY3QgDQ0g ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyByZXF1aXJlbWVudHMgZm9yLCBhbmQgdXNlIG9mLCB0 aGUgR2VuZXJhbGl6ZWQgDSAgIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMp IGNvbnRyb2wgcGxhbmUgaW4gY29uanVuY3Rpb24gDSANIA0gDUJlcm5zdGVpbiAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSA0LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDFdIA0MDUlu dGVybmV0LURyYWZ0ICAgIE9wZXJhdGluZyBWQ0FUIGFuZCBMQ0FTIHdpdGggR01QTFMgICAgICAg IEF1Z3VzdCAyMDA2IA0gICAgDQ0gICB3aXRoIHRoZSBWaXJ0dWFsIENvbmNhdGVuYXRpb24gKFZD QVQpIGxheWVyIDEgaW52ZXJzZSBtdWx0aXBsZXhpbmcgDSAgIG1lY2hhbmlzbSBhbmQgaXRzIGNv bXBhbmlvbiBMaW5rIENhcGFjaXR5IEFkanVzdG1lbnQgU2NoZW1lIChMQ0FTKSANICAgd2hpY2gg Y2FuIGJlIHVzZWQgZm9yIGhpdGxlc3MgZHluYW1pYyByZXNpemluZyBvZiB0aGUgaW52ZXJzZSAN ICAgbXVsdGlwbGV4IGdyb3VwLiAgVGhlc2UgdGVjaG5pcXVlcyBhcHBseSB0byB0aGUgT3B0aWNh bCBUcmFuc3BvcnQgDSAgIE5ldHdvcmsgKE9UTiksIFN5bmNocm9ub3VzIE9wdGljYWwgTmV0d29y ayAoU09ORVQpLCBTeW5jaHJvbm91cyANICAgRGlnaXRhbCBIaWVyYXJjaHkgKFNESCksIGFuZCBQ bGVzaW9jaHJvbm91cyBEaWdpdGFsIEhpZXJhcmNoeSAoUERIKSANICAgc2lnbmFscy4gDQ1Db252 ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgDQ0gICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsIA0gICAiU0hPVUxE IiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4g dGhpcyANICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBS RkMtMjExOSBbUkZDMjExOV0uIA0NVGFibGUgb2YgQ29udGVudHMgDQ0gICAgDSAgIDEuIEludHJv ZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjMgDSAgIDIuIENoYW5nZXMgZnJvbSBkcmFmdC1iZXJuc3RlaW4tY2NhbXAtZ21wbHMtdmNhdC1s Y2FzLTAzLi4uLi4uLi4uLjMgDSAgIDMuIFZDQVQvTENBUyBTY2VuYXJpb3MgYW5kIFNwZWNpZmlj IFJlcXVpcmVtZW50cy4uLi4uLi4uLi4uLi4uLi4uLjMgDSAgICAgIDMuMS4gTXVsdGlwbGUgVkNB VCBHcm91cHMgcGVyIEdNUExTIEVuZHBvaW50Li4uLi4uLi4uLi4uLi4uLi4uLjMgDSAgICAgIDMu Mi4gQ29tcG9uZW50IFNpZ25hbCBDb25maWd1cmF0aW9uIFJlcXVpcmVtZW50cy4uLi4uLi4uLi4u Li4uLjQgDSAgICAgIDMuMy4gVkNBVCBPcGVyYXRpb24gV2l0aCBvciBXaXRob3V0IExDQVMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjQgDSAgIDQuIEdNUExTIE1lY2hhbmlzbXMgZm9yIFNpZ25hbGlu ZyBWQ0FUL0xDQVMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDSAgICAgIDQuMS4gQ28tUm91dGVk IFNpZ25hbHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDSAgICAg ICAgIDQuMS4xLiBPbmUtc2hvdCBTZXR1cCBvZiBDby1Sb3V0ZWQgU2lnbmFsLi4uLi4uLi4uLi4u Li4uLi4uLjUgDSAgICAgICAgIDQuMS4yLiBJbmNyZW1lbnRhbCBTZXR1cCBvZiBDby1Sb3V0ZWQg U2lnbmFsLi4uLi4uLi4uLi4uLi4uLjUgDSAgICAgICAgIDQuMS4zLiBSZW1vdmluZyBhIENvbXBv bmVudCBTaWduYWwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDSAgICAgICAgIDQuMS40LiBS ZW1vdmluZyBNdWx0aXBsZSBDb21wb25lbnQgU2lnbmFscyBpbiBPbmUgU2hvdC4uLi4uLjYgDSAg ICAgICAgIDQuMS41LiBVc2Ugb2YgbXVsdGlwbGUgTFNQcyBmb3IgQ28tUm91dGVkIFNpZ25hbHMu Li4uLi4uLi4uLjcgDSAgICAgICAgIDQuMS42LiBUZWFyZG93biBvZiBXaG9sZSBWQ0cuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDSAgICAgIDQuMi4gRGl2ZXJzZWx5IFJvdXRlZCBT aWduYWxzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDSAgICAgICAgIDQuMi4x LiBBc3NvY2lhdGluZyBEaXZlcnNlbHkgUm91dGVkIFNpZ25hbHMuLi4uLi4uLi4uLi4uLi4uLjcg DSAgICAgICAgIDQuMi4yLiBQcm9jZWR1cmVzIGZvciBWQ0cgU2V0dXAgVXNpbmcgRGl2ZXJzZWx5 IFJvdXRlZCANICAgICAgICAgQ29tcG9uZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uOCANICAgICAgICAgNC4yLjMuIFByb2NlZHVyZXMgZm9yIFZD RyBSZWR1Y3Rpb24vVGVhcmRvd24gVXNpbmcgRGl2ZXJzZWx5IA0gICAgICAgICBSb3V0ZWQgQ29t cG9uZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0gICAg ICAgICA0LjIuNC4gVXBkYXRlIG9mIEFscmVhZHkgRXN0YWJsaXNoZWQgTFNQcy4uLi4uLi4uLi4u Li4uLi4uLi45IA0gICAgICAgICA0LjIuNS4gT25lIExTUCBwZXIgQ2lyY3VpdC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0gICA1LiBJQU5BIENvbnNpZGVyYXRpb25zLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0gICA2LiBTZWN1cml0eSBD b25zaWRlcmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0g ICA3LiBDb250cmlidXRvcnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjExIA0gICA4LiBBY2tub3dsZWRnbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjExIA0gICA5LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEyIA0gICAgICA5LjEuIE5v cm1hdGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEy IA0gICAgICA5LjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjEyIA0gICBBdXRob3IncyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEzIA0gDSANQmVybnN0ZWluICAgICAgICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDQsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQwNSW50 ZXJuZXQtRHJhZnQgICAgT3BlcmF0aW5nIFZDQVQgYW5kIExDQVMgd2l0aCBHTVBMUyAgICAgICAg QXVndXN0IDIwMDYgDSAgICANDSAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQgDSAgIERpc2NsYWltZXIgb2YgVmFsaWRp dHkuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQgDSAgIENvcHly aWdodCBTdGF0ZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMTQgDSAgIEFja25vd2xlZGdtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTUgDSAgICANMS4gSW50cm9kdWN0aW9uIA0NICAgVGhlIEdlbmVy YWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpIHN1aXRlIG9mIA0g ICBwcm90b2NvbHMgYWxsb3dzIHRoZSBhdXRvbWF0ZWQgY29udHJvbCBvZiBkaWZmZXJlbnQgc3dp dGNoaW5nIA0gICB0ZWNobm9sb2dpZXMgaW5jbHVkaW5nIFNPTkVUL1NESC4gICANDSAgIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGV4dGVuc2lvbnMgdG8gUlNWUC1URSB0byBzdXBwb3J0IHRoZSBW aXJ0dWFsIA0gICBDb25jYXRlbmF0aW9uIChWQ0FUKSBsYXllciAxIGludmVyc2UgbXVsdGlwbGV4 aW5nIG1lY2hhbmlzbSBhbmQgaXRzIA0gICBjb21wYW5pb24gTGluayBDYXBhY2l0eSBBZGp1c3Rt ZW50IFNjaGVtZSAoTENBUykuICBUaGVzZSBleHRlbnNpb25zIA0gICBlbmFibGUgdGhlIHNldHVw IG9mIGRpdmVyc2VseSByb3V0ZWQgY2lyY3VpdHMgdGhhdCBhcmUgbWVtYmVycyBvZiB0aGUgDSAg IHNhbWUgVkNBVCBncm91cC4gDQ0yLiBDaGFuZ2VzIGZyb20gZHJhZnQtYmVybnN0ZWluLWNjYW1w LWdtcGxzLXZjYXQtbGNhcy0wMyANDSAgIG8gIERyb3BwZWQgYXBwZW5kaWNlcyANDSAgIG8gIFVw ZGF0ZWQgcmVmZXJlbmNlcyANDSAgIG8gIEZpeGVkIGVycm9yIHcvciB0byBzZXNzaW9ucy4gVGhl IExTUHMgYmVsb25nIHRvIGRpZmZlcmVudCBzZXNzaW9ucyANDSAgIG8gIE1hbnkgZWRpdG9yaWFs IGNoYW5nZXMgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgDQ0gICBvICBSZXdyb3RlIHRoZSBpbnRy b2R1Y3Rpb24gDQ0zLiBWQ0FUL0xDQVMgU2NlbmFyaW9zIGFuZCBTcGVjaWZpYyBSZXF1aXJlbWVu dHMgDQ0gICBUaGVyZSBhcmUgYSBudW1iZXIgb2Ygc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGZvciB0 aGUgc3VwcG9ydCBvZiANICAgVkNBVC9MQ0FTIGluIEdNUExTIHRoYXQgY2FuIGJlIGRlcml2ZWQg ZnJvbSB0aGUgY2FycmllcnMnIA0gICBhcHBsaWNhdGlvbi1zcGVjaWZpYyBkZW1hbmRzIGZvciB0 aGUgdXNlIG9mIFZDQVQvTENBUyBhbmQgZnJvbSB0aGUgDSAgIGZsZXhpYmxlIG5hdHVyZSBvZiBW Q0FUL0xDQVMuICBUaGVzZSBhcmUgc2V0IG91dCBpbiB0aGUgZm9sbG93aW5nIA0gICBzZWN0aW9u LiANDTMuMS4gTXVsdGlwbGUgVkNBVCBHcm91cHMgcGVyIEdNUExTIEVuZHBvaW50ICANDSAgIElu IGdlbmVyYWwsIGFuIExTUiBjYW4gYmUgaW5ncmVzcy9lZ3Jlc3Mgb2Ygb25lIG9yIG1vcmUgVkNB VCBncm91cHMuICANICAgVkNBVCBhbmQgTENBUyBhcmUgaW50ZXJmYWNlIGNhcGFiaWxpdGllcy4g IEFuIExTUiBtYXkgaGF2ZSwgZm9yIA0gICBleGFtcGxlLCBWQ0FULWNhcGFibGUgaW50ZXJmYWNl cyB0aGF0IGFyZSBub3QgTENBUy1jYXBhYmxlLiAgSXQgbWF5IA0gICBhdCB0aGUgc2FtZSB0aW1l IGhhdmUgaW50ZXJmYWNlcyB0aGF0IGFyZSBuZWl0aGVyIFZDQVQgbm9yIExDQVMtDSAgIGNhcGFi bGUuIA0NDQ0gDSANQmVybnN0ZWluICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDQsIDIw MDcgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQwNSW50ZXJuZXQtRHJhZnQgICAgT3BlcmF0aW5n IFZDQVQgYW5kIExDQVMgd2l0aCBHTVBMUyAgICAgICAgQXVndXN0IDIwMDYgDSAgICANDTMuMi4g Q29tcG9uZW50IFNpZ25hbCBDb25maWd1cmF0aW9uIFJlcXVpcmVtZW50cyANDSAgIFdlIGxpc3Qg aW4gdGhpcyBzZWN0aW9uIHRoZSBkaWZmZXJlbnQgc2NlbmFyaW9zIHRoYXQgU0hPVUxEIGJlIA0g ICBzdXBwb3J0ZWQuICBIZXJlIHdlIHVzZSB0aGUgdGVybSAiVkNHIiB0byByZWZlciB0byB0aGUg ZW50aXJlIFZDQVQgDSAgIGdyb3VwIGFuZCB0aGUgdGVybWlub2xvZ3kgInNldCIgYW5kICJzdWJz ZXQiIHRvIHJlZmVyIHRvIHRoZSANICAgY29sbGVjdGlvbiBvZiBwb3RlbnRpYWwgVkNBVCBncm91 cCBtZW1iZXIgc2lnbmFscy4gDQ0gICBvICBGaXhlZCwgY28tcm91dGVkOiBBIGZpeGVkIGJhbmR3 aWR0aCBWQ0csIHRyYW5zcG9ydGVkIG92ZXIgYSBjby0NICAgICAgcm91dGVkIHNldCBvZiBtZW1i ZXIgc2lnbmFscy4gIFRoaXMgaXMgdGhlIGNhc2Ugd2hlcmUgdGhlIGludGVuZGVkIA0gICAgICBi YW5kd2lkdGggb2YgdGhlIFZDRyBkb2VzIG5vdCBjaGFuZ2UgYW5kIGFsbCBtZW1iZXIgc2lnbmFs cyBmb2xsb3cgDSAgICAgIHRoZSBzYW1lIHJvdXRlIGFuZCBtaW5pbWl6ZSBkaWZmZXJlbnRpYWwg ZGVsYXkuICBUaGUgaW50ZW50IGhlcmUgDSAgICAgIGlzIHRoZSBjYXBhYmlsaXR5IHRvIGFsbG9j YXRlIGFuIGFtb3VudCBvZiBiYW5kd2lkdGggY2xvc2UgdG8gdGhhdCANICAgICAgcmVxdWlyZWQg YXQgdGhlIGNsaWVudCBsYXllci4gDQ0gICBvICBGaXhlZCwgZGl2ZXJzZWx5IHJvdXRlZDogQSBm aXhlZCBiYW5kd2lkdGggVkNHLCB0cmFuc3BvcnRlZCBvdmVyIA0gICAgICBhdCBsZWFzdCB0d28g ZGl2ZXJzZWx5IHJvdXRlZCBzdWJzZXRzIG9mIG1lbWJlciBzaWduYWxzLiAgSW4gdGhpcyANICAg ICAgY2FzZSwgdGhlIHN1YnNldHMgYXJlIGxpbmstZGlzam9pbnQgb3ZlciBhdCBsZWFzdCBvbmUg bGluayBvZiB0aGUgDSAgICAgIHJvdXRlLiAgVGhlIGludGVudCBoZXJlIGlzIG1vcmUgZWZmaWNp ZW50IHVzZSBvZiBuZXR3b3JrIHJlc291cmNlcyANICAgICAgKG5vIHVuaXF1ZSByb3V0ZSBoYXMg dGhlIHJlcXVpcmVkIGJhbmR3aWR0aCksIGFuZCBhZGRpdGlvbmFsIA0gICAgICByZXNpbGllbmNl IGFuZCBncmFjZWZ1bCBkZWdyYWRhdGlvbiBpbiB0aGUgY2FzZSBvZiBmYWlsdXJlIChub3RlIA0g ICAgICB0aGF0IGRpZmZlcmVudGlhbCBkZWxheSBtYXkgYmUgYSBsaW1pdGluZyBmYWN0b3IpLiAF DQ0gICBvICBEeW5hbWljLCBjby1yb3V0ZWQ6IEEgZHluYW1pYyBWQ0cgKGJhbmR3aWR0aCBjYW4g YmUgaW5jcmVhc2VkIG9yIA0gICAgICBkZWNyZWFzZWQgdmlhIHRoZSBhZGRpdGlvbiBvciByZW1v dmFsIG9mIG1lbWJlciBzaWduYWxzKSwgDSAgICAgIHRyYW5zcG9ydGVkIG92ZXIgYSBjby1yb3V0 ZWQgc2V0IG9mIG1lbWJlcnMuICBJbnRlbnQgaGVyZSBpcyANICAgICAgZHluYW1pYyBzaXppbmcg b2YgYmFuZHdpZHRoLiANDSAgIG8gIER5bmFtaWMsIGRpdmVyc2VseSByb3V0ZWQ6IEEgZHluYW1p YyBWQ0FUIGdyb3VwLCB0cmFuc3BvcnRlZCBvdmVyIA0gICAgICBhdCBsZWFzdCB0d28gZGl2ZXJz ZWx5IHJvdXRlZCBzdWJzZXRzIG9mIG1lbWJlciBzaWduYWxzLiAgVGhlIA0gICAgICBpbnRlbnQg aGVyZSBpcyBkeW5hbWljIHJlc2l6aW5nIGFuZCByZXNpbGllbmNlIChidXQgZGlmZmVyZW50aWFs IA0gICAgICBkZWxheSBtYXkgYmUgYSBsaW1pdGluZyBmYWN0b3IpLiBHcmFjZWZ1bCBkZWdyYWRh dGlvbiBpcyBwb3NzaWJsZSBpbiB0aGUgZXZlbnQgb2YgYSBUU0QgKFRyYWlsIFNpZ25hbCBEZWdy YWRlKSBvbiBhIFZDRyBtZW1iZXIocykNDTMuMy4gVkNBVCBPcGVyYXRpb24gV2l0aCBvciBXaXRo b3V0IExDQVMgDQ0gICBWQ0FUIGNhcGFiaWxpdGllcyBtYXkgYmUgcHJlc2VudCB3aXRoIG9yIHdp dGhvdXQgdGhlIHByZXNlbmNlIG9mIA0gICBMQ0FTLiAgVGhlIHVzZSBvZiBMQ0FTIGlzIGJlbmVm aWNpYWwgdG8gdGhlIHByb3Zpc2lvbiBvZiBzZXJ2aWNlcywgDSAgIGJ1dCBpbiB0aGUgYWJzZW5j ZSBvZiBMQ0FTLCBWQ0FUIGlzIHN0aWxsIGEgdmFsaWQgdGVjaG5pcXVlLiAgDSAgIFRoZXJlZm9y ZSBHTVBMUyBtZWNoYW5pc21zIGZvciB0aGUgb3BlcmF0aW9uIG9mIFZDQVQgYXJlIFJFUVVJUkVE IGZvciANICAgYm90aCB0aGUgY2FzZSB3aGVyZSBMQ0FTIGlzIGF2YWlsYWJsZSBhbmQgdGhlIGNh c2Ugd2hlcmUgaXQgaXMgbm90IA0gICBhdmFpbGFibGUuICBUaGUgR01QTFMgcHJvY2VkdXJlcyBm b3IgdGhlIHR3byBjYXNlcyBTSE9VTEQgYmUgDSAgIGlkZW50aWNhbC4gDQ00LiBHTVBMUyBNZWNo YW5pc21zIGZvciBTaWduYWxpbmcgVkNBVC9MQ0FTIA0NICAgV2UgZGVzY3JpYmUgaW4gdGhpcyBz ZWN0aW9uIHRoZSBzaWduYWxpbmcgbWVjaGFuaXNtcyB0aGF0IGFscmVhZHkgDSAgIGV4aXN0IGlu IEdNUExTIHVzaW5nIFJTVlAtVEUgW1JGQzM0NzNdIGFuZCB0aGUgZXh0ZW5zaW9ucyBuZWVkZWQs IGZvciANICAgZGl2ZXJzZWx5IHJvdXRlZCBwYXRocyBhbmQgaW4gc3VwcG9ydCBvZiB0aGUgTENB UyBwcm9jZWR1cmUuIA0gDSANQmVybnN0ZWluICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDQsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQwNSW50ZXJuZXQtRHJhZnQgICAgT3Bl cmF0aW5nIFZDQVQgYW5kIExDQVMgd2l0aCBHTVBMUyAgICAgICAgQXVndXN0IDIwMDYgDSAgICAN DSAgIFNlY3Rpb24gNC4xIGlzIGluY2x1ZGVkIGZvciBpbmZvcm1hdGlvbmFsIHB1cnBvc2VzIG9u bHkuICBJdCANICAgZGVzY3JpYmVzIGV4aXN0aW5nIHByb2NlZHVyZXMgYW5kIG1ha2VzIG5vIGNo YW5nZXMuIA0NICAgU2VjdGlvbiA0LjIgZGVzY3JpYmVzIG5ldyBwcm9jZWR1cmVzIHRvIHN1cHBv cnQgZGl2ZXJzZWx5IHJvdXRlZCBWQ0FUIA0gICBncm91cHMuICBXaGVyZSBwb3NzaWJsZSBpdCBy ZXVzZXMgYXBwbGljYWJsZSBleGlzdGluZyBwcm9jZWR1cmVzIGZyb20gDSAgIHNlY3Rpb24gNC4x LiAgDQ00LjEuIENvLVJvdXRlZCBTaWduYWxzIA0NICAgTm90ZSB0aGF0IHRoaXMgc2VjdGlvbiBp cyBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LiANDSAgIFRoZSBleGlzdGluZyBzaWdu YWxpbmcgcHJvdG9jb2xzIHN1cHBvcnQgY28tcm91dGVkIHNpZ25hbCBzZXR1cCB1c2luZyANICAg dGhlIE5WQyBmaWVsZCBhcyBleHBsYWluZWQgaW4gc2VjdGlvbiAyLjEgb2YgW1JGQzM5NDZiaXNd LiAgSW4gdGhpcyANICAgY2FzZSwgb25lIHNpbmdsZSBMU1AgaXMgc2V0IHVwIGluIHN1cHBvcnQg b2YgdGhlIFZDQVQgZ3JvdXAuIA0NICAgVGhlcmUgYXJlIHR3byBvcHRpb25zIGZvciBzZXR0aW5n IHVwIHRoZSBWQ0FUIGdyb3VwLCBkZXBlbmRpbmcgb24gDSAgIGhhcmR3YXJlIGNhcGFiaWxpdHks IG9yIG1hbmFnZW1lbnQgcHJlZmVyZW5jZXM6IG9uZS1zaG90IHNldHVwIGFuZCANICAgaW5jcmVt ZW50YWwgc2V0dXAuIA0NICAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyBleHBsYWluIHRoZSBwcm9j ZWR1cmUgYmFzZWQgb24gYW4gZXhhbXBsZSBvZiANICAgc2V0dGluZyB1cCBhIFZDLTQtN3YgU0RI IFZDQVQgZ3JvdXAgKGNvcnJlc3BvbmRpbmcgdG8gYW4gU1RTLTNjLTd2IA0gICBTT05FVCBWQ0FU IGdyb3VwKS4gDQ00LjEuMS4gT25lLXNob3QgU2V0dXAgb2YgQ28tUm91dGVkIFNpZ25hbCANDSAg IEFuIFJTVlAtVEUgUGF0aCBtZXNzYWdlIGlzIHVzZWQgd2l0aCB0aGUgZm9sbG93aW5nIHBhcmFt ZXRlcnMuIA0NICAgV2l0aCByZWdhcmRzIHRvIHRoZSB0cmFmZmljIHBhcmFtZXRlcnMsIHRoZSBl bGVtZW50YXJ5IHNpZ25hbCBpcyANICAgY2hvc2VuICg2IGZvciBWQy00L1NUUy0zY19TUEUpLiAg VGhlIHZhbHVlIG9mIE5WQyBpcyB0aGVuIHNldCB0byA3LiANDSAgIEEgTXVsdGlwbGllciBUcmFu c2Zvcm0gZ3JlYXRlciB0aGFuIDEgKHNheSBOPjEpIGlzIHVzZWQgaWYgdGhlIA0gICBvcGVyYXRv ciB3YW50cyB0byBzZXQgdXAgTiBWQ0FUIGdyb3VwcyB0aGF0IHdpbGwgYmVsb25nIHRvLCBhbmQg YmUgDSAgIGFzc2lnbmVkIHRvLCBvbmUgTFNQLiANDSAgIFNESCBvciBTT05FVCBsYWJlbHMgaW4g dHVybiBoYXZlIHRvIGJlIGFzc2lnbmVkIGZvciBlYWNoIG1lbWJlciBvZiANICAgdGhlIFZDRyBh bmQgY29uY2F0ZW5hdGVkIHRvIGZvcm0gYSBzaW5nbGUgR2VuZXJhbGl6ZWQgTGFiZWwgDSAgIGNv bnN0cnVjdGVkIGFzIGFuIG9yZGVyZWQgbGlzdCBvZiAzMi1iaXQgdGltZXNsb3QgaWRlbnRpZmll cnMgb2YgdGhlIA0gICBzYW1lIGZvcm1hdCBhcyBURE0gbGFiZWxzLiAgW1JGQzM5NDZiaXNdIHJl cXVpcmVzIHRoYXQgdGhlIG9yZGVyIG9mIA0gICB0aGUgbGFiZWxzIHJlZmxlY3QgdGhlIG9yZGVy IG9mIHRoZSBwYXlsb2FkcyB0byBjb25jYXRlbmF0ZSwgYW5kIG5vdCANICAgdGhlIHBoeXNpY2Fs IG9yZGVyIG9mIHRpbWUtc2xvdHMuIA0NNC4xLjIuIEluY3JlbWVudGFsIFNldHVwIG9mIENvLVJv dXRlZCBTaWduYWwgDQ0gICBJbiBzb21lIGNhc2VzLCBpdCBtYXkgYmUgbmVjZXNzYXJ5IG9yIGRl c2lyYWJsZSB0byBzZXQgdXAgdGhlIFZDRyANICAgbWVtYmVycyBpbmRpdmlkdWFsbHksIG9yIHRv IGFkZCBncm91cCBtZW1iZXJzIHRvIGFuIGV4aXN0aW5nIGdyb3VwLiANDQ0gDSANQmVybnN0ZWlu ICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDQsIDIwMDcgICAgICAgICAgICAgICAgW1Bh Z2UgNV0gDQwNSW50ZXJuZXQtRHJhZnQgICAgT3BlcmF0aW5nIFZDQVQgYW5kIExDQVMgd2l0aCBH TVBMUyAgICAgICAgQXVndXN0IDIwMDYgDSAgICANDSAgIE9uZSBleGFtcGxlIG9mIHRoaXMgbmVl ZCBpcyB3aGVuIHRoZSBoYXJkd2FyZSB0aGF0IHN1cHBvcnRzIFZDQVQgY2FuIA0gICBvbmx5IGFk ZCBWQ0FUIGVsZW1lbnRzIG9uZSBhdCBhIHRpbWUgb3IgY2Fubm90IGF1dG9tYXRpY2FsbHkgbWF0 Y2ggDSAgIHRoZSBlbGVtZW50cyBhdCB0aGUgaW5ncmVzcyBhbmQgZWdyZXNzIGZvciB0aGUgcHVy cG9zZXMgb2YgaW52ZXJzZSANICAgbXVsdGlwbGV4aW5nLiAgU2VyaWFsIG9yIGluY3JlbWVudGFs IHNldHVwIHNvbHZlcyB0aGlzIHByb2JsZW0uIA0NICAgSW4gb3JkZXIgdG8gYWNjb21wbGlzaCBp bmNyZW1lbnRhbCBzZXR1cCBhbiBpdGVyYXRpdmUgcHJvY2VzcyBpcyB1c2VkIA0gICB0byBhZGQg Z3JvdXAgbWVtYmVycy4gIEZvciBlYWNoIGl0ZXJhdGlvbiwgTlZDIGlzIGluY3JlbWVudGVkIHVw IHRvIA0gICB0aGUgZmluYWwgdmFsdWUgcmVxdWlyZWQuICBUaGUgaXRlcmF0aW9uIGNvbnNpc3Rz IG9mIHRoZSBzdWNjZXNzZnVsIA0gICBjb21wbGV0aW9uIG9mIFBhdGggYW5kIFJlc3Ygc2lnbmFs aW5nLiAgQXQgZmlyc3QsIE5WQyA9IDEgYW5kIHRoZSANICAgbGFiZWwgaW5jbHVkZXMganVzdCBv bmUgdGltZXNsb3QgaWRlbnRpZmllciAgDQ0gICBBdCBlYWNoIG9mIHRoZSBuZXh0IGl0ZXJhdGlv bnMsIE5WQyBpcyBzZXQgdG8gKE5WQyArMSksIG9uZSBtb3JlIA0gICB0aW1lc2xvdCBpZGVudGlm aWVyIGlzIGFkZGVkIHRvIHRoZSBvcmRlcmVkIGxpc3QgaW4gdGhlIEdlbmVyYWxpemVkIA0gICBM YWJlbCAoaW4gdGhlIFBhdGggb3IgUmVzdiBtZXNzYWdlKS4gIEEgbm9kZSB0aGF0IHJlY2VpdmVz IGEgUGF0aCANICAgbWVzc2FnZSB0aGF0IGNvbnRhaW5zIGNoYW5nZWQgZmllbGRzIHdpbGwgcHJv Y2VzcyB0aGUgZnVsbCBQYXRoIA0gICBtZXNzYWdlIGFuZCwgYmFzZWQgb24gdGhlIG5ldyB2YWx1 ZSBvZiBOVkMsIGl0IHdpbGwgYWRkIGEgY29tcG9uZW50IA0gICBzaWduYWwgdG8gdGhlIFZDQVQg Z3JvdXAsIGFuZCBzd2l0Y2ggdGhlIG5ldyB0aW1lc2xvdCBiYXNlZCBvbiB0aGUgDSAgIG5ldyBs YWJlbCBpbmZvcm1hdGlvbi4gDQ0gICBGb2xsb3dpbmcgdGhlIGFkZGl0aW9uIG9mIHRoZSBuZXcg bGFiZWwgdG8gdGhlIExTUCwgTENBUyBtYXkgYmUgdXNlZCANICAgaW4tYmFuZCB0byBhZGQgdGhl IG5ldyBsYWJlbCBpbnRvIHRoZSBleGlzdGluZyBWQ0FUIGdyb3VwLiAgTENBUyANICAgc2lnbmFs aW5nIGZvciB0aGlzIGZ1bmN0aW9uIGlzIGRlc2NyaWJlZCBpbiBbSVRVLVQtRy43MDQyXS4gDQ00 LjEuMy4gRGVjcmVhc2luZyBWQ0cgY2FwYWNpdHkgDQ1WQ0cgY2FwYWNpdHkgY2FuIGJlIGRlY3Jl YXNlZCBpbiB0d28gd2F5cw1UZW1wb3JhcnkgcmVtb3ZhbCBvZiBhIFZDRyBtZW1iZXIocykgZHVl IHRvIGZhaWx1cmUgKGdvZXMgdG8gRE5VIHN0YXRlKQ1QbGFubmVkIHBlcm1hbmFuZW10IHJlbW92 YWwgb2YgYSBWQ0cgbWVtYmVyKHMpIChnb2VzIHRvIElETEUgc3RhdGUpIFRoaXMgYWN0aW9uIGlz IGluaXRpYXRlZCBieSBtYW5hZ2VtZW50IGludGVydmVudGlvbi4NDVRlbXBvcmFyeSBSZW1vdmlu ZyBhbCBvZiBhIFZDRyBtZW1iZXIgQ29tcG9uZW50IFNpZ25hbCANDVRoaXMgaXMgYW4gYXV0b25v bW91cyBhY3Rpb24gcGVyZm9ybWVkIGJ5IHRoZSBMQ0FTIHByb3RvY29sIHdoZW5ldmVyIGEgZmFp bHVyZSBvY2N1cnMgb24gYW4gYWN0aXZlIFZDRyBtZW1iZXIocykuIFRoZSByZWxldmFudCBWQ0cg bWVtYmVyIHdpbGwgdGhlbiBiZSBpbiB0aGUgRE5VIHN0YXRlLg0NVGhlcmUgaXMgbm8gbWFuYWdl bWVudCBpbnRlcnZlbnRpb24gcmVxdWlyZWQgdG8gcGVyZm9ybSB0aGlzIG9wZXJhdGlvbi4NDVRo aXMgbWVtYmVyIGNhbiB0aGVuIGJlIHBlcm1hbmVudGx5IHJlbW92ZWQgZnJvbSB0aGUgVkNHLiAo NC4xLjMuMikNDTQuMS4zLjIJCVBsYW5uZWQgcGVybWFuZW50IHJlbW92YWwgb2YgYSBWQ0cgbWVt YmVyDQ0gICBUaGUgcHJvY2VkdXJlIHRvIHJlbW92ZSBhIGNvbXBvbmVudCBzaWduYWwgaXMgc2lt aWxhciB0byB0aGF0IHVzZWQgdG8gDSAgIGFkZCBjb21wb25lbnRzIGFzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDQuMS4yLiAgVGhlIExDQVMgaW4tYmFuZCANICAgc2lnbmFsaW5nIHN0ZXAgaXMgdGFr ZW4gZmlyc3QgdG8gdGFrZSB0aGUgY29tcG9uZW50IG91dCBvZiB0aGUgZ3JvdXAgYXMgdGhlIHJl c3VsdCBvZiBhIHJlbW92ZSBjb21tYW5kIGZyb20gdGhlIExDQVMgY29udHJvbGxlcjsgdGhlIHBl cm1hbmVudGx5IHJlbW92ZWQgbWVtYmVyIHdpbGwgdGhlbiBiZSBpbiB0aGUgSURMRSBzdGF0ZS4g IA0gICBMQ0FTIHNpZ25hbGluZyBpcyBkZXNjcmliZWQgaW4gW0lUVS1ULUcuNzA0Ml0uIA0NICAg SW4gdGhpcyBjYXNlLCB0aGUgTlZDIHZhbHVlIGlzIGRlY3JlbWVudGVkIGJ5IDEgYW5kIHRoZSB0 aW1lc2xvdCANICAgaWRlbnRpZmllciBmb3IgdGhlIGRyb3BwZWQgY29tcG9uZW50IGlzIHJlbW92 ZWQgZnJvbSB0aGUgb3JkZXJlZCBsaXN0IA0gICBpbiB0aGUgR2VuZXJhbGl6ZWQgTGFiZWwuICAN DVRoaXMgcGVybWFuZW50IHJlbW92YWwgcHJvY2VkdXJlIGlzIG9ubHkgYXBwbGljYWJsZSB0byBM Q0FTLWNhcGFibGUtVkNBVC4gVGhpcyBmdW5jdGlvbiBpcyBub3Qgc3VwcG9ydGVkIHdpdGhvdXQg DSAgIG1hbmFnZW1lbnQgaW50ZXJ2ZW50aW9uIGZvciBWQ0FULW9ubHkgaW50ZXJmYWNlcyBhcyBy ZW1vdmluZyBvbmUgDSAgIGNvbXBvbmVudCBvZiB0aGUgVkNHIHdpbGwgcmVzdWx0IGluIGVycm9y cyBpbiB0aGUgaW52ZXJzZS0NICAgbXVsdGlwbGV4aW5nIHByb2NlZHVyZSBvZiBWQ0FUIGFuZCBy ZXN1bHQgaW4gdGhlIHRlYXJkb3duIG9mIHRoZSANICAgd2hvbGUgZ3JvdXAuICBTbywgdGhpcyBp cyBhIGZlYXR1cmUgdGhhdCBvbmx5IExDQVMtY2FwYWJsZSBWQ0FUIA0gICBpbnRlcmZhY2VzIGNh biBzdXBwb3J0IHdpdGhvdXQgbWFuYWdlbWVudCBpbnRlcnZlbnRpb24gYXQgdGhlIGVuZCANICAg cG9pbnRzLiANDQ00LjEuNC4gUmVtb3ZpbmcgTXVsdGlwbGUgQ29tcG9uZW50IFNpZ25hbHMgaW4g T25lIFNob3QgDQ0gICBUaGUgcHJvY2VkdXJlIGlzIHNpbWlsYXIgdG8gNC4xLjMuICBJbiB0aGlz IGNhc2UsIHRoZSBOVkMgdmFsdWUgaXMgDSAgIGNoYW5nZWQgdG8gdGhlIG5ldyB2YWx1ZSBhbmQg YWxsIHJlbGV2YW50IHRpbWVzbG90IGlkZW50aWZpZXJzIGZvciANICAgdGhlIGNvbXBvbmVudHMg dG8gYmUgdG9ybiBkb3duIGFyZSByZW1vdmVkIGZyb20gdGhlIG9yZGVyZWQgbGlzdCBpbiANICAg dGhlIEdlbmVyYWxpemVkIExhYmVsLiAgVGhpcyBpcyBhbHNvIG5vdCBzdXBwb3J0ZWQgZm9yIFZD QVQtb25seSANICAgaW50ZXJmYWNlcyB3aXRob3V0IG1hbmFnZW1lbnQgaW50ZXJ2ZW50aW9uIGFz IHJlbW92aW5nIG9uZSBjb21wb25lbnQgDSANIA1CZXJuc3RlaW4gICAgICAgICAgICAgIEV4cGly ZXMgRmVicnVhcnkgNCwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA2XSANDA1JbnRlcm5ldC1E cmFmdCAgICBPcGVyYXRpbmcgVkNBVCBhbmQgTENBUyB3aXRoIEdNUExTICAgICAgICBBdWd1c3Qg MjAwNiANICAgIA0NICAgb2YgdGhlIFZDRyB3aWxsIHRlYXIgZG93biB0aGUgd2hvbGUgZ3JvdXAs IGJ1dCB0aGUgdXNlIG9mIExDQVMgY2FuIA0gICBmYWNpbGl0YXRlIHRoaXMgcHJvY2VkdXJlLiAN DTQuMS41LiBVc2Ugb2YgbXVsdGlwbGUgTFNQcyBmb3IgQ28tUm91dGVkIFNpZ25hbHMgDQ0gICBD by1yb3V0ZWQgc2lnbmFscyBtYXkgYWxzbyBiZSBzdXBwb3J0ZWQgYnkgZGlzdGluY3QgTFNQcyBz aWduYWxlZCANICAgc2VwYXJhdGVseSB1c2luZyBleGFjdGx5IHRoZSB0ZWNobmlxdWVzIGRlc2Ny aWJlZCBmb3IgZGl2ZXJzZWx5IA0gICByb3V0ZWQgc2lnbmFscyBpbiBTZWN0aW9uIDQuMi4gDQ00 LjEuNi4gVGVhcmRvd24gb2YgV2hvbGUgVkNHIA0NICAgVGhlIGVudGlyZSBMU1AgaXMgZGVsZXRl ZCBpbiBhIHNpbmdsZSBzdGVwIChpLmUuLCBhbGwgY29tcG9uZW50cyBhcmUgDSAgIHJlbW92ZWQg aW4gb25lIGdvKSB1c2luZyBkZWxldGlvbiBwcm9jZWR1cmVzIG9mIFtSRkMzNDczXS4gDQ00LjIu IERpdmVyc2VseSBSb3V0ZWQgU2lnbmFscyANDSAgIFRoZSBpbml0aWFsIEdNUExTIHNwZWNpZmlj YXRpb24gZGlkIG5vdCBzdXBwb3J0IGRpdmVyc2VseSByb3V0ZWQgDSAgIHNpZ25hbHMgdXNpbmcg dGhlIE5WQyBjb25zdHJ1Y3QuICBJbiBmYWN0LCBbUkZDMzk0NmJpc10gc2F5czogDQ0gICAgICAg ICBbLi4uXSBUaGUgc3RhbmRhcmQgZGVmaW5pdGlvbiBmb3IgdmlydHVhbCBjb25jYXRlbmF0aW9u IGFsbG93cyANICAgICAgICAgZWFjaCB2aXJ0dWFsIGNvbmNhdGVuYXRpb24gY29tcG9uZW50cyB0 byB0cmF2ZWwgb3ZlciBkaXZlcnNlIA0gICAgICAgICBwYXRocy4gIFdpdGhpbiBHTVBMUywgdmly dHVhbCBjb25jYXRlbmF0aW9uIGNvbXBvbmVudHMgbXVzdCANICAgICAgICAgdHJhdmVsIG92ZXIg dGhlIHNhbWUgKGNvbXBvbmVudCkgbGluayBpZiB0aGV5IGFyZSBwYXJ0IG9mIHRoZSANICAgICAg ICAgc2FtZSBMU1AuICBUaGlzIGlzIGR1ZSB0byB0aGUgd2F5IHRoYXQgbGFiZWxzIGFyZSBib3Vu ZCB0byBhIA0gICAgICAgICAoY29tcG9uZW50KSBsaW5rLiAgTm90ZSBob3dldmVyLCB0aGF0IHRo ZSByb3V0aW5nIG9mIGNvbXBvbmVudHMgDSAgICAgICAgIG9uIGRpZmZlcmVudCBwYXRocyBpcyBp bmRlZWQgZXF1aXZhbGVudCB0byBlc3RhYmxpc2hpbmcgDSAgICAgICAgIGRpZmZlcmVudCBMU1Bz LCBlYWNoIG9uZSBoYXZpbmcgaXRzIG93biByb3V0ZS4gIFNldmVyYWwgTFNQcyANICAgICAgICAg Y2FuIGJlIGluaXRpYXRlZCBhbmQgdGVybWluYXRlZCBiZXR3ZWVuIHRoZSBzYW1lIG5vZGVzIGFu ZCANICAgICAgICAgdGhlaXIgY29ycmVzcG9uZGluZyBjb21wb25lbnRzIGNhbiB0aGVuIGJlIGFz c29jaWF0ZWQgdG9nZXRoZXIgDSAgICAgICAgIChpLmUuLCB2aXJ0dWFsbHkgY29uY2F0ZW5hdGVk KS4gDQ0gICBEaXZlcnNlIHJvdXRpbmcgb2Ygc2lnbmFscyBjYW4gYmUgYSB1c2VmdWwgY2FwYWJp bGl0eSBidXQgcmVxdWlyZXMgDSAgIHRoZSBleHRlbnNpb25zIGlkZW50aWZpZWQgaW4gdGhpcyBk b2N1bWVudC4gDQ00LjIuMS4gQXNzb2NpYXRpbmcgRGl2ZXJzZWx5IFJvdXRlZCBTaWduYWxzIA0N ICAgVGhlIGZlYXR1cmUgdGhhdCBuZWVkcyB0byBiZSBhZGRlZCBpcyB0aGUgZnVuY3Rpb25hbGl0 eSB0byBhc3NvY2lhdGUgDSAgIHRoZSBjb21wb25lbnRzIG9mIHRoZSBzYW1lIFZDRy4gIEZvciB0 aGlzIHB1cnBvc2UsIHdlIHVzZSB0aGUgDSAgIEFzc29jaWF0aW9uIE9iamVjdCB0aGF0IHdhcyBk ZWZpbmVkIGluIFtFMkUtUkVDT1ZFUlldIHRvIGFzc29jaWF0ZSANICAgd29ya2luZyBhbmQgcmVj b3ZlcnkgTFNQcy4gDQ1UaGUgTENBUyBmZWF0dXJlIGlzIHRvIGVuYWJsZSBoaXRsZXNzIGNhcGFj aXR5IGNoYW5nZSBvbiB0aGUgdHJhbnNwb3J0IHBpcGUNDSAgIEEgZGl2ZXJzZWx5IHJvdXRlZCBW Q0cgdXNlcyBhIG51bWJlciBvZiByb3V0ZXMgUiA8PSBWQ0cgc2l6ZSwgYXMgc29tZSANICAgcm91 dGVzIG1heSBiZSB0aGUgc2FtZSBmb3Igc2V2ZXJhbCBjb21wb25lbnRzLiAgQSBudW1iZXIgb2Yg TFNQcywgTCANICAgKFZDRyA+PSBMID49IFIpIGFyZSB1c2VkIHdpdGggZWFjaCBMU1AgZXN0YWJs aXNoaW5nIGF0IGxlYXN0IG9uZSANICAgY29tcG9uZW50IG9mIHRoZSBWQ0csIGFuZCBhdCBtb3N0 IGFsbCBvZiB0aGUgY28tcm91dGVkIG1lbWJlcnMgb2YgdGhlIA0gICBncm91cC4gIEZvciBhIHNl dCBvZiBjIGNvbXBvbmVudHMgdXNpbmcgdGhlIHNhbWUgcm91dGUsIHdlIHNldCB1cCB0aGUgDSAg IExTUCB3aXRoIE5WQyA9IGMgZXhhY3RseSBhcyBleHBsYWluZWQgaW4gc2VjdGlvbiA0LjEuMS4g IFRoZXJlZm9yZSwgDSANIA1CZXJuc3RlaW4gICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkg NCwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA3XSANDA1JbnRlcm5ldC1EcmFmdCAgICBPcGVy YXRpbmcgVkNBVCBhbmQgTENBUyB3aXRoIEdNUExTICAgICAgICBBdWd1c3QgMjAwNiANICAgIA0N ICAgdGhlIGFzc29jaWF0aW9uIG9mIGdyb3VwIG1lbWJlcnMgb3Igb2Ygc3ViLWdyb3VwcyB0byBm b3JtIHRoZSBWQ0cgDSAgIHJlcXVpcmVzIHRoZSBhc3NvY2lhdGlvbiBvZiB0aGUgTFNQcyB1c2Vk IHRvIGVzdGFibGlzaCB0aGUgZ3JvdXAgDSAgIG1lbWJlcnMuIA0NICAgVG8gYmUgYWJsZSB0byBk aXN0aW5ndWlzaCB0aGUgTFNQcyBpbiB0aGUgVkNHIGVhY2ggbXVzdCBoYXZlIGEgdW5pcXVlIA0g ICBpZGVudGlmaWVyLiBMU1BzIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSBjb21iaW5hdGlvbiBvZiBT ZXNzaW9uIGFuZCANICAgU2VuZGVyIFRlbXBsYXRlIGZpZWxkcy4gIEl0IGlzIGNvbW1vbiBwcmFj dGljZSB3aGVuIG1ha2UtYmVmb3JlLWJyZWFrIA0gICBbUkZDMzIwOV0gaXMgc3VwcG9ydGVkIHRv IGFsbG93IExTUHMgd2l0aCB0aGUgc2FtZSBTZXNzaW9uLCBidXQgDSAgIGRpZmZlcmVudCBTZW5k ZXIgVGVtcGxhdGVzIChzcGVjaWZpY2FsbHkgd2l0aCBkaWZmZXJlbnQgTFNQIElEcykgdG8gDSAg IHNoYXJlIHJlc291cmNlcy4gIFNpbmNlIHJlc291cmNlIHNoYXJpbmcgYmV0d2VlbiBWQ0cgbWVt YmVycyBtdXN0IG5vdCANICAgYmUgYWxsb3dlZCAoYmVjYXVzZSB3ZSB3YW50IGVhY2ggTFNQIHRv IGNvbnRyaWJ1dGUgY2FwYWNpdHkgdG8gdGhlIA0gICBWQ0cpLCBidXQgc2luY2Ugd2Ugd2FudCB0 byBjb250aW51ZSB0byBzdXBwb3J0IG1ha2UtYmVmb3JlLWJyZWFrIGZvciANICAgZWFjaCBncm91 cCBtZW1iZXIsIGl0IGlzIG5lY2Vzc2FyeSB0byBkaXN0aW5ndWlzaCB0aGUgTFNQcyBpbiB0aGUg VkNHIA0gICBieSB2YXJ5aW5nIHRoZSBmaWVsZHMgaW4gdGhlIFNlc3Npb24gb2JqZWN0LiAgU3Bl Y2lmaWNhbGx5LCBhIA0gICBkaWZmZXJlbnQgVHVubmVsIElEIGlzIHVzZWQgdG8gaWRlbnRpZnkg ZWFjaCBMU1AgaW4gdGhlIFZDRy4gDQ0gICBUaHVzLCBWQ0cgbWVtYmVycyBjYW5ub3QgYmUgYXNz b2NpYXRlZCB0aHJvdWdoIHRoZSBTZXNzaW9uIG9iamVjdCwgDSAgIGFuZCB0aGUgQXNzb2NpYXRp b24gb2JqZWN0IGlzIHVzZWQgaW5zdGVhZC4gDQ0gICBUaGUgYXNzaWdubWVudCBvZiB0aGUgQXNz b2NpYXRpb24gSUQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgR01QTFMgDSAgIGJ1dCBNVVNUIGJl IHVuaXF1ZSBmb3IgZWFjaCBWQ0FUIGdyb3VwLiANDSAgIE5vdGUgdGhhdCB0aGUgdXNlIG9mIHRo ZSBBc3NvY2lhdGlvbiBvYmplY3QgdG8gYXNzb2NpYXRlIG1lbWJlcnMgb2YgYSANICAgVkNHIGRv ZXMgbm90IHByZWNsdWRlIHRoZSB1c2Ugb2YgYW5vdGhlciBpbnN0YW5jZSBvZiB0aGUgb2JqZWN0 IHdpdGggDSAgIGEgZGlmZmVyZW50IEFzc29jaWF0aW9uIElEIHRvIGluZGljYXRlIHRoZSBhc3Nv Y2lhdGlvbiBvZiB3b3JraW5nIGFuZCANICAgcmVjb3ZlcnkgTFNQcywgYXMgW0UyRS1SRUNPVkVS WV0gYWxsb3dzIHRoZSB1c2Ugb2YgbXVsdGlwbGUgDSAgIEFzc29jaWF0aW9uIG9iamVjdHMuICBX ZSBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlIEFzc29jaWF0aW9uIA0gICBvYmplY3RzIHVzZWQg Zm9yIHRoZSBWQ0FUIGdyb3VwIGFuZCBvdGhlciBBc3NvY2lhdGlvbiBvYmplY3RzIHRocm91Z2gg DSAgIHRoZSBkZWZpbml0aW9uIG9mIGEgbmV3IGFzc29jaWF0aW9uIHR5cGUgdG8gaW5kaWNhdGUg dGhhdCB0aGlzIGlzIGEgDSAgIFZDRyBhc3NvY2lhdGlvbi4gDQ0gICBBc3NvY2lhdGlvbiBUeXBl OiAxNiBiaXRzICANDSAgICAgICAgICAgICAgIFZhbHVlICAgICAgIFR5cGUgIA0gICAgICAgICAg ICAgICAtLS0tLSAgICAgICAtLS0tICANDSAgICAgICAgICAgICAgICAgMyAgICAgICAgIFZDQVQg Z3JvdXAgIA0NICAgU2VlIFtFMkUtUkVDT1ZFUlldIGZvciB0aGUgZGVmaW5pdGlvbiBvZiBvdGhl ciBmaWVsZHMgYW5kIHZhbHVlcyBvZiANICAgdGhlIEFzc29jaWF0aW9uIG9iamVjdC4gDQ00LjIu Mi4gUHJvY2VkdXJlcyBmb3IgVkNHIFNldHVwIFVzaW5nIERpdmVyc2VseSBSb3V0ZWQgQ29tcG9u ZW50cyANDSAgIEZvciBldmVyeSByb3V0ZSBSLCB1c2UgdGhlIHByb2NlZHVyZSBvdXRsaW5lZCBp biBzZWN0aW9uIDQuMS4xIG9yIA0gICA0LjEuMiBkZXBlbmRpbmcgb24gdGhlIGNhcGFiaWxpdHkg b2YgdGhlIGVxdWlwbWVudCBvciBsb2NhbCBwb2xpY3kuICANICAgVGhlIFBhdGggbWVzc2FnZSBN VVNUIGluY2x1ZGUgdGhlIEFzc29jaWF0aW9uIG9iamVjdCB3aXRoIHR5cGUgc2V0IHRvIA0gICAz LCBhbmQgZWFjaCBQYXRoIG1lc3NhZ2UgTVVTVCB1c2UgdGhlIHNhbWUgQXNzb2NpYXRpb24gSUQu IA0gDSANQmVybnN0ZWluICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDQsIDIwMDcgICAg ICAgICAgICAgICAgW1BhZ2UgOF0gDQwNSW50ZXJuZXQtRHJhZnQgICAgT3BlcmF0aW5nIFZDQVQg YW5kIExDQVMgd2l0aCBHTVBMUyAgICAgICAgQXVndXN0IDIwMDYgDSAgICANDSAgIEZvbGxvd2lu ZyB0aGUgYWRkaXRpb24gb2YgZWFjaCBuZXcgTFNQIChpLmUuLCBvbmNlIHRoZSBSRVNWIG1lc3Nh Z2UgDSAgIGhhcyBiZWVuIHJlY2VpdmVkIGJ5IHRoZSBpbmdyZXNzIExTUiksIExDQVMgc2lnbmFs aW5nIGlzIHVzZWQgaW4tYmFuZCANICAgdG8gaGl0bGVzc2x5IGFkZCB0aGUgbmV3IGxhYmVsIGlu dG8gdGhlIGV4aXN0aW5nIGdyb3VwIFtJVFUtVC0NICAgRy43MDQyXS4gDQ00LjIuMy4gUHJvY2Vk dXJlcyBmb3IgVkNHIFJlZHVjdGlvbi9UZWFyZG93biBVc2luZyBEaXZlcnNlbHkgUm91dGVkIA0g ICBDb21wb25lbnRzIA0NICAgVG8gcmVtb3ZlIHRoZSBjb21wb25lbnQgY2lyY3VpdHMgb24gYW55 IHJvdXRlLCBMQ0FTIHNpZ25hbGluZyBpcyB1c2VkIA0gICBpbi1iYW5kIHRvIHJlbW92ZSB0aGUg bGFiZWxzIGFzc29jaWF0ZWQgd2l0aCB0aGUgTFNQIGZyb20gdGhlIGdyb3VwLiAgDSAgIExDQVMg c2lnbmFsaW5nIGlzIGRlZmluZWQgaW4gW0lUVS1ULUcuNzA0Ml0uIA0NICAgSW4gYWRkaXRpb24s IHRoZSBwcm9jZWR1cmVzIG91dGxpbmVkIGluIHNlY3Rpb24gNC4xLjMgb3IgNC4xLjQgYXJlIA0g ICB1c2VkIHRvIHRlYXIgZG93biB0aGUgdW53YW50ZWQgTFNQLiAgDQ0gICBBZ2FpbiwgdGhpcyBj YW4gb25seSBiZSBkb25lIG9uIExDQVMtY2FwYWJsZSBpbnRlcmZhY2VzLiAgSWYgdGhlIA0gICBw cm9jZWR1cmUgaXMgYXR0ZW1wdGVkIG9uIFZDQVQtb25seSBpbnRlcmZhY2VzLCB0aGVuIHRoZSB3 aG9sZSBWQ0cgaXMgDSAgIHRvcm4gZG93biAodGhpcyBpcyBub3QgYSBncmFjZWZ1bCB0ZWFyZG93 biBzbyBpbmdyZXNzL2VncmVzcyBpbml0aWF0ZSANICAgYSBQYXRoIFRlYXIvUmVzdiBUZWFyKSBv biBhbGwgcm91dGVzLiANDTQuMi40LiBVcGRhdGUgb2YgQWxyZWFkeSBFc3RhYmxpc2hlZCBMU1Bz IA0NICAgRXN0YWJsaXNoZWQgY28tcm91dGVkIFZDQVQgZ3JvdXBzIGN1cnJlbnRseSBkbyBub3Qg c3VwcG9ydCB0aGUgDSAgIEFzc29jaWF0aW9uIG9iamVjdC4gIElmIGEgY28tcm91dGVkIFZDQVQg R3JvdXAgc2l6ZSBpcyB0byBiZSANICAgaW5jcmVhc2VkIHdpdGggbmV3IGRpdmVyc2VseSByb3V0 ZWQgbWVtYmVycywgd2UgdXNlIHRoZSBMU1AgDSAgIG1vZGlmaWNhdGlvbiBwcm9jZWR1cmUgZGVz Y3JpYmVkIGluIFtSRkMyMjA1XS4gIEFuIEFzc29jaWF0aW9uIG9iamVjdCANICAgaXMgYWRkZWQg dG8gdGhlIFBhdGggbWVzc2FnZSBmb3IgdGhlIGV4aXN0aW5nIExTUChzKS4gIFRoYXQgDSAgIEFz c29jaWF0aW9uIG9iamVjdCBjYW4gdGhlbiBiZSB1c2VkIHRvIHNldCB1cCBuZXcgZGl2ZXJzZWx5 IHJvdXRlZCANICAgZ3JvdXAgbWVtYmVycy4gDQ0gICBUaGUgc2FtZSBhcHBsaWVzIHRvIFNPTkVU L1NESCBMU1BzLiAgQW4gb3BlcmF0b3IgbWF5IGRlY2lkZSB0byB1c2UgYW4gDSAgIGFscmVhZHkg Y3Jvc3MtY29ubmVjdGVkIFNPTkVUL1NESCBMU1AgZm9yIGRpdmVyc2VseS1yb3V0ZWQgVkNBVC4g IEluIA0gICB0aGlzIGNhc2UgdGhlIG1vZGlmaWNhdGlvbiBwcm9jZWR1cmUgZGVzY3JpYmVkIGlu IFtSRkMyMjA1XSBpcyB1c2VkIA0gICBhcyB3ZWxsLiANDTQuMi41LiBPbmUgTFNQIHBlciBDaXJj dWl0IA0NICAgVGhlc2UgcHJvY2VkdXJlcyBjYW4gc3VwcG9ydCB0aGUgdXNlIG9mIGFzIG1hbnkg TFNQcyBhcyB0aGVyZSBhcmUgDSAgIGNpcmN1aXRzIGluIHRoZSBWQ0cuICBUaGlzIGNhbiBiZSBk b25lIHdoZW4gZWFjaCBjaXJjdWl0IGlzIA0gICBzZXBhcmF0ZWx5IHJvdXRlZCwgb3Igd2hlbiBz b21lIG9mIHRoZSBjaXJjdWl0cyBhcmUgY28tcm91dGVkLCBhbmQgDSAgIGVhY2ggTFNQIHdpbGwg YmUgdXNlZCB0byBzZXQgdXAgb25lIGVsZW1lbnQgb2YgdGhlIFZDRy4gIFRoZSANICAgQXNzb2Np YXRpb24gb2JqZWN0IGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhlIFZDRyBhc3NvY2lhdGlvbi4gDQ0N DQ0NIA0gDUJlcm5zdGVpbiAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA0LCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDldIA0MDUludGVybmV0LURyYWZ0ICAgIE9wZXJhdGluZyBWQ0FU IGFuZCBMQ0FTIHdpdGggR01QTFMgICAgICAgIEF1Z3VzdCAyMDA2IA0gICAgDQ01LiBJQU5BIENv bnNpZGVyYXRpb25zIA0NICAgVGhpcyBkb2N1bWVudCByZXF1ZXN0cyBmcm9tIElBTkEgdGhlIGFz c2lnbm1lbnQgb2YgYSBuZXcgQXNzb2NpYXRpb24gDSAgIFR5cGUgd2l0aGluIHRoZSBBc3NvY2lh dGlvbiBvYmplY3QuICBUaGlzIG9iamVjdCB3YXMgZGVmaW5lZCBpbiBbRTJFLQ0gICBSRUNPVkVS WV0uIA0NICAgVGhlIHZhbHVlIDMgIlZDQVQgZ3JvdXAiIGlzIHN1Z2dlc3RlZCBpbiBzZWN0aW9u IDQuMi4xLiAgDQ02LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyANDSAgIFRoaXMgZG9jdW1lbnQg aW50cm9kdWNlcyBhIG5ldyB1c2Ugb2YgdGhlIEFzc29jaWF0aW9uIG9iamVjdCBmb3IgDSAgIEdN UExTIHNpZ25hbGluZyBbUkZDMzQ3M10gdG8gYXNzb2NpYXRlIGRpdmVyc2VseSByb3V0ZWQgVkNB VCBncm91cCANICAgbWVtYmVycy4gIEl0IGRvZXMgbm90IGludHJvZHVjZSBhbnkgbmV3IHNpZ25h bGluZyBtZXNzYWdlcywgbm9yIA0gICBjaGFuZ2UgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIExT UnMgdGhhdCBhcmUgYWRqYWNlbnQgaW4gdGhlIGNvbnRyb2wgDSAgIHBsYW5lLiAgVGhpcyBhc3Nv Y2lhdGlvbiBpbmZvcm1hdGlvbiBpbiB0aGUgZXZlbnQgb2YgYW4gaW50ZXJjZXB0aW9uIA0gICBt YXkgaW5kaWNhdGUgdGhhdCB0aGVyZSBhcmUgbWVtYmVycyBvZiB0aGUgc2FtZSBWQ0FUIGdyb3Vw IHRoYXQgdGFrZSANICAgYSBkaWZmZXJlbnQgcm91dGUgYW5kIG1heSBpbmRpY2F0ZSB0byBhbiBp bnRlcmNlcHRvciB0aGF0IHRoZSBuZXR3b3JrIA0gICBtYXkgYmUgbW9yZSByb2J1c3QuIA0NICAg T3RoZXJ3aXNlLCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBhbnkgYWRkaXRpb25h bCBzZWN1cml0eSANICAgY29uc2lkZXJhdGlvbnMuIA0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DSANIA1CZXJuc3RlaW4gICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNCwgMjAwNyAgICAg ICAgICAgICAgIFtQYWdlIDEwXSANDA1JbnRlcm5ldC1EcmFmdCAgICBPcGVyYXRpbmcgVkNBVCBh bmQgTENBUyB3aXRoIEdNUExTICAgICAgICBBdWd1c3QgMjAwNiANICAgIA0NNy4gQ29udHJpYnV0 b3JzIA0NICAgV2F0YXJ1IEltYWp1a3UgKE5UVCkgIA0gICAxLTEgSGlrYXJpLW5vLW9rYSBZb2tv c3VrYSBLYW5hZ2F3YSAyMzktMDg0NyAgDSAgIEphcGFuIA0gICAgDSAgIFBob25lICs4MS00Ni04 NTktNDMxNSANICAgRW1haWw6IGltYWp1a3Uud2F0YXJ1QGxhYi5udHQuY28uanAgIA0gICAgDSAg IEp1bGllbiBNZXVyaWMgDSAgIEZyYW5jZSBUZWxlY29tIA0gICAyLCBhdmVudWUgUGllcnJlIE1h cnppbiANICAgMjIzMDcgTGFubmlvbiBDZWRleCANICAgRnJhbmNlIA0gICAgDSAgIFBob25lOiAr IDMzIDIgOTYgMDUgMjggMjggDSAgIEVtYWlsOiBqdWxpZW4ubWV1cmljQG9yYW5nZS1mdC5jb20g DSAgICANICAgTHluZG9uIE9uZyAgDSAgIENpZW5hIA0gICBQTyBCb3ggMzA4ICANICAgQ3VwZXJ0 aW5vLCBDQSA5NTAxNSANICAgVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIA0gICAgDSAgIFBob25l OiArMSA0MDggNzA1IDI5NzggDSAgIEVtYWlsOiBseW9uZ0BjaWVuYS5jb20gDSAgICANICAgIA04 LiBBY2tub3dsZWRnbWVudHMgDQ0gICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIE1h YXJ0ZW4gVmlzc2VycyBhbmQgQWRyaWFuIEZhcnJlbCBmb3IgDSAgIGV4dGVuc2l2ZSByZXZpZXdz IGFuZCBjb250cmlidXRpb25zIHRvIHRoaXMgZHJhZnQuIA0NDQ0NDQ0NDQ0NDQ0NDQ0gDSANQmVy bnN0ZWluICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDQsIDIwMDcgICAgICAgICAgICAg ICBbUGFnZSAxMV0gDQwNSW50ZXJuZXQtRHJhZnQgICAgT3BlcmF0aW5nIFZDQVQgYW5kIExDQVMg d2l0aCBHTVBMUyAgICAgICAgQXVndXN0IDIwMDYgDSAgICANDTkuIFJlZmVyZW5jZXMgDQ05LjEu IE5vcm1hdGl2ZSBSZWZlcmVuY2VzIA0NICAgW1JGQzIxMTldICAgICAgQnJhZG5lciwgUy4sICJL ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIA0gICAgICAgICAgICAgICAgICBS ZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LiANDSAgIFtS RkMyMjA1XSAgICAgIEJyYWRlbiwgUi4sIFpoYW5nLCBMLiwgQmVyc29uLCBTLiwgSGVyem9nLCBT LiBhbmQgUy4gDSAgICAgICAgICAgICAgICAgIEphbWluLCAiUmVzb3VyY2UgUmVTZXJWYXRpb24g UHJvdG9jb2wgKFJTVlApIC0tIA0gICAgICAgICAgICAgICAgICBWZXJzaW9uIDEsIEZ1bmN0aW9u YWwgU3BlY2lmaWNhdGlvbiIsIFJGQyAyMjA1LCANICAgICAgICAgICAgICAgICAgU2VwdGVtYmVy IDE5OTcuIA0NICAgW1JGQzMyMDldICAgICAgQXdkdWNoZSwgRC4sIEJlcmdlciwgTC4sIEdhbiwg RC4sIExpLCBULiwgU3Jpbml2YXNhbiwgDSAgICAgICAgICAgICAgICAgIFYuLCBhbmQgRy4gU3dh bGxvdywgIlJTVlAtVEU6IEV4dGVuc2lvbnMgdG8gUlNWUCBmb3IgDSAgICAgICAgICAgICAgICAg IExTUCBUdW5uZWxzIiwgUkZDIDMyMDksIERlY2VtYmVyIDIwMDEuIA0NICAgW1JGQzM0NzNdICAg ICAgQmVyZ2VyLCBMLiwgIkdlbmVyYWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIA0gICAgICAg ICAgICAgICAgICBTd2l0Y2hpbmcgKEdNUExTKSBTaWduYWxpbmcgUmVzb3VyY2UgUmVzZXJWYXRp b24gDSAgICAgICAgICAgICAgICAgIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcgKFJTVlAt VEUpIEV4dGVuc2lvbnMiLCANICAgICAgICAgICAgICAgICAgUkZDIDM0NzMsIEphbnVhcnkgMjAw My4gDQ0gICBbUkZDMzk0NmJpc10gICBNYW5uaWUsIEUuIGFuZCBELiBQYXBhZGltaXRyaW91LCAi R2VuZXJhbGl6ZWQgTXVsdGktDSAgICAgICAgICAgICAgICAgIFByb3RvY29sIExhYmVsIFN3aXRj aGluZyAoR01QTFMpIEV4dGVuc2lvbnMgZm9yIA0gICAgICAgICAgICAgICAgICBTeW5jaHJvbm91 cyBPcHRpY2FsIE5ldHdvcmsgKFNPTkVUKSBhbmQgU3luY2hyb25vdXMgDSAgICAgICAgICAgICAg ICAgIERpZ2l0YWwgSGllcmFyY2h5IChTREgpIENvbnRyb2wiLCBJRVRGIGRyYWZ0LCB3b3JrIGlu IA0gICAgICAgICAgICAgICAgICBwcm9ncmVzcywgRGVjZW1iZXIgMjAwNS4gDQ0gICBbRTJFLVJF Q09WRVJZXSBMYW5nLCBKLlAuLCBSZWtodGVyLCBZLiwgYW5kIEQuIFBhcGFkaW1pdHJpb3UgKGVk cy4pLCANICAgICAgICAgICAgICAgICAgIlJTVlAtVEUgRXh0ZW5zaW9ucyBpbiBzdXBwb3J0IG9m IEVuZC10by1FbmQgDSAgICAgICAgICAgICAgICAgIEdlbmVyYWxpemVkIE11bHRpLVByb3RvY29s IExhYmVsIFN3aXRjaGluZyAoR01QTFMpLQ0gICAgICAgICAgICAgICAgICBiYXNlZCBSZWNvdmVy eSIsIElFVEYgZHJhZnQsIHdvcmsgaW4gcHJvZ3Jlc3MsIEFwcmlsIA0gICAgICAgICAgICAgICAg ICAyMDA1LiANDTkuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyANDSAgIFtBTlNJLVQxLjEwNV0g IEFtZXJpY2FuIE5hdGlvbmFsIFN0YW5kYXJkcyBJbnN0aXR1dGUsICJTeW5jaHJvbm91cyANICAg ICAgICAgICAgICAgICAgT3B0aWNhbCBOZXR3b3JrIChTT05FVCkgLSBCYXNpYyBEZXNjcmlwdGlv biBpbmNsdWRpbmcgDSAgICAgICAgICAgICAgICAgIE11bHRpcGxleCBTdHJ1Y3R1cmUsIFJhdGVz LCBhbmQgRm9ybWF0cyIsIEFOU0kgVDEuMTA1LQ0gICAgICAgICAgICAgICAgICAyMDAxLCBNYXkg MjAwMS4gDQ0gICBbSVRVLVQtRy43MDQyXSBJbnRlcm5hdGlvbmFsIFRlbGVjb21tdW5pY2F0aW9u cyBVbmlvbiwgIkxpbmsgQ2FwYWNpdHkgDSAgICAgICAgICAgICAgICAgIEFkanVzdG1lbnQgU2No ZW1lIChMQ0FTKSBmb3IgVmlydHVhbCBDb25jYXRlbmF0ZWQgDSAgICAgICAgICAgICAgICAgIFNp Z25hbHMiLCBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjcwNDIsIEZlYnJ1YXJ5IDIwMDQuIA0NDQ0N IA0gDUJlcm5zdGVpbiAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA0LCAyMDA3ICAgICAg ICAgICAgICAgW1BhZ2UgMTJdIA0MDUludGVybmV0LURyYWZ0ICAgIE9wZXJhdGluZyBWQ0FUIGFu ZCBMQ0FTIHdpdGggR01QTFMgICAgICAgIEF1Z3VzdCAyMDA2IA0gICAgDQ0gICBbSVRVLVQtRy43 MDQzXSBJbnRlcm5hdGlvbmFsIFRlbGVjb21tdW5pY2F0aW9ucyBVbmlvbiwgIlZpcnR1YWwgDSAg ICAgICAgICAgICAgICAgIENvbmNhdGVuYXRpb24gb2YgUGxlc2lvY2hyb25vdXMgRGlnaXRhbCBI aWVyYXJjaHkgDSAgICAgICAgICAgICAgICAgIChQREgpIFNpZ25hbHMiLCBJVFUtVCBSZWNvbW1l bmRhdGlvbiBHLjcwNDMsIEp1bHkgDSAgICAgICAgICAgICAgICAgIDIwMDQuIA0NICAgW0lUVS1U LUcuNzA3XSAgSW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNhdGlvbnMgVW5pb24sICJOZXR3b3Jr IE5vZGUgDSAgICAgICAgICAgICAgICAgIEludGVyZmFjZSBmb3IgdGhlIFN5bmNocm9ub3VzIERp Z2l0YWwgSGllcmFyY2h5IA0gICAgICAgICAgICAgICAgICAoU0RIKSIsIElUVS1UIFJlY29tbWVu ZGF0aW9uIEcuNzA3LCBEZWNlbWJlciAyMDAzLiANDSAgIFtJVFUtVC1HLjcwOV0gIEludGVybmF0 aW9uYWwgVGVsZWNvbW11bmljYXRpb25zIFVuaW9uLCAiSW50ZXJmYWNlcyANICAgICAgICAgICAg ICAgICAgZm9yIHRoZSBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3JrIChPVE4pIiwgSVRVLVQgDSAg ICAgICAgICAgICAgICAgIFJlY29tbWVuZGF0aW9uIEcuNzA5LCBNYXJjaCAyMDAzLiANDUF1dGhv cidzIEFkZHJlc3NlcyANDSAgIEdyZWcgQmVybnN0ZWluIA0gICBHcm90dG8gTmV0d29ya2luZyAN ICAgICAgIA0gICBQaG9uZTogKzEtNTEwLTU3My0yMjM3IA0gICBFbWFpbDogZ3JlZ2JAZ3JvdHRv LW5ldHdvcmtpbmcuY29tIA0gICAgDQ0gICBEaWVnbyBDYXZpZ2xpYSAgDSAgIEVyaWNzc29uIA0g ICBWaWEgQS4gTmVncm9uZSAxL0EgMTYxNTMgDSAgIEdlbm9hIEl0YWx5IA0gICAgDSAgIFBob25l OiArMzkgMDEwIDYwMCAzNzM2IA0gICBFbWFpbDogZGllZ28uY2F2aWdsaWFAKG1hcmNvbmkuY29t LCBlcmljc3Nvbi5jb20pICAgDSAgICANDSAgIFJpY2hhcmQgUmFiYmF0IA0gICBGdWppdHN1IExh Ym9yYXRvcmllcyBvZiBBbWVyaWNhIA0gICAxMjQwIEVhc3QgQXJxdWVzIEF2ZSwgTVMgMzQ1IA0g ICBTdW5ueXZhbGUsIENBIDk0MDg1IA0gICBVbml0ZWQgU3RhdGVzIG9mIEFtZXJpY2EgDSAgICAg ICANICAgUGhvbmU6ICsxIDQwOC01MzAtNDUzNyANICAgRW1haWw6IHJpY2hhcmRAdXMuZnVqaXRz dS5jb20gDSAgICANDQ0NDQ0NDSANIA1CZXJuc3RlaW4gICAgICAgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgNCwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDEzXSANDA1JbnRlcm5ldC1EcmFmdCAg ICBPcGVyYXRpbmcgVkNBVCBhbmQgTENBUyB3aXRoIEdNUExTICAgICAgICBBdWd1c3QgMjAwNiAN ICAgIA0NICAgSHV1YiB2YW4gSGVsdm9vcnQgDSAgIEh1YXdlaSBUZWNobm9sb2dpZXMsIEx0ZC4g DSAgIEtvbGtncmllbmQgMzgsIDEzNTYgQkMgQWxtZXJlIA0gICBUaGUgTmV0aGVybGFuZHMgDSAg ICANICAgUGhvbmU6ICAgKzMxIDM2IDUzMTUwNzYgDSAgIEVtYWlsOiAgIGhoZWx2b29ydEBodWF3 ZWkuY29tIA0NSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudCANDSAgIFRoZSBJRVRGIHRh a2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55IA0g ICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0 IGJlIGNsYWltZWQgdG8gDSAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBv ZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4gDSAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4 dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyANICAgbWlnaHQgb3Ig bWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFz IA0gICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmln aHRzLiAgSW5mb3JtYXRpb24gDSAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byBy aWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUgDSAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQ IDc5LiANDSAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNy ZXRhcmlhdCBhbmQgYW55IA0gICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZh aWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuIA0gICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEg Z2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YgDSAgIHN1Y2ggcHJv cHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzIA0gICBzcGVj aWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9z aXRvcnkgYXQgDSAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLiANDSAgIFRoZSBJRVRGIGludml0 ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkgDSAg IGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJv cHJpZXRhcnkgDSAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJl IHJlcXVpcmVkIHRvIGltcGxlbWVudCANICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNz IHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdCANICAgaWV0Zi1pcHJAaWV0Zi5vcmcuIA0N RGlzY2xhaW1lciBvZiBWYWxpZGl0eSANDSAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbiANICAgIkFTIElTIiBiYXNp cyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRT IA0gICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFO RCBUSEUgSU5URVJORVQgDSAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdB UlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwgDSAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlU RUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgDSAgIElORk9STUFUSU9OIEhF UkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEIA0gICBXQVJS QU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS UE9TRS4gDQ1Db3B5cmlnaHQgU3RhdGVtZW50IA0NICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMjAwNikuIA0NDSANIA1CZXJuc3RlaW4gICAgICAgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgNCwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDE0XSANDA1JbnRlcm5ldC1EcmFm dCAgICBPcGVyYXRpbmcgVkNBVCBhbmQgTENBUyB3aXRoIEdNUExTICAgICAgICBBdWd1c3QgMjAw NiANICAgIA0NICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vu c2VzIGFuZCByZXN0cmljdGlvbnMgDSAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQg YXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIA0gICByZXRhaW4gYWxsIHRoZWlyIHJp Z2h0cy4gDQ1BY2tub3dsZWRnbWVudCANDSAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1 bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUgDSAgIEludGVybmV0IFNvY2lldHku IA0NICAgIA0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NIA0gDUJlcm5zdGVp biAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA0LCAyMDA3ICAgICAgICAgICAgICAgW1Bh Z2UgMTVdIA0MDQVJcyB0aGUgdGVybSCRRml4ZWSSIHN5bm9ueW1vdXMgd2l0aCBuby1MQ0FTLiBJ ZiBzbyB0aGVuIHRoZXJlIGNhbiBiZSBubyCRZ3JhY2VmdWwgZGVncmFkYXRpb26SIGluIHRoZSBG aXhlZCwgZGl2ZXJzZWx5LXJvdXRlZCBzY2VuYXJpby4gSW4gZmFjdCB0aGlzIGFwcGxpZXMgYWxz byB0byB0aGUgRml4ZWQsIGNvLXJvdXRlZCBzY2VuYXJpby4NR3JhY2VmdWwgZGVncmFkYXRpb24g aXMgbW9yZSBhcHBsaWNhYmxlIHRvIHRoZSBkeW5hbWljIHNjZW5hcmlvczsgYWx0aG91Z2ggSSBi ZWxpZXZlIGl0IGFwcGxpZXMgbW9yZSB0byB0aGUgZGl2ZXJzZWx5IJZyb3V0ZWQgc2NlbmFyaW8u DQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAADwgAACMIAAArCAAA 1wgAANoIAADbCAAA3AgAAOcIAADoCAAA6QgAAOoIAAD5CAAAAwkAAAUJAAATCQAAFAkAACcJAAAw CQAAQAkAAEEJAACACQAAgQkAACUKAAAnCgAAmQoAAJ4KAACtCgAAsAoAALUKAADUCgAAcQsAAHIL AACdCwAA7wwAAPjw+Ojg+NXGu7C7qLucu/i7lLv4u+C7jOCE4ITghHxuZlsAAAAAAAAAABQVaJo2 kQAWaJd1XwBtSAkIc0gJCAAOFmiXdV8AbUgJCHNICQgAGwEIgQRIAQAFaA2EqGYWaGMiUABtSAkI c0gJCA4WaO83VwBtSAkIc0gJCAAOFmhjIlAAbUgJCHNICQgADhZoKHSjAG1ICQhzSAkIAA4WaAdw gQBtSAkIc0gJCAAXFWgHcIEAFmgodKMAPioBbUgJCHNICQgOFmg3GnIAbUgJCHNICQgAFBVo3RO5 ABZoN23qAG1ICQhzSAkIABQVaN0TuQAWaCh0owBtSAkIc0gJCAAdFWjdE7kAFmgodKMANQiBPioB XAiBbUgJCHNICQgUFWgEcCIAFmgEcCIAbUgJCHNICQgADhZo3EtyAG1ICQhzSAkIAA4WaNJgegBt SAkIc0gJCAAOFmipEqkAbUgJCHNICQgADhZoBHAiAG1ICQhzSAkIIgAGAAAICAAACQgAANsIAADc CAAA6QgAAOoIAAANCQAADgkAAIIJAACDCQAAJgoAACcKAAByCwAAnAsAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAAChAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAQyQBRcaAAAABAA2EqGYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJd1XwAABAAAZ2Rj IlAAAAQAAGdkKHSjAAAEAABnZAdwgQAABAAAZ2TSYHoAAAEAAAAOAAYAAIuOAADZjwAA/v4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQKcCwAAnQsAAN8LAAAoDAAAcQwA ALsMAAD/DAAARw0AAIANAACBDQAAxA0AAAkOAABRDgAA2Q4AANoOAADbDgAA5Q4AAOYOAAAnDwAA KA8AALkAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0 AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAA AAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAK8AAAAAAAAAAAAA AAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAKoAAAAAAAAAAAAAAACqAAAAAAAAAAAAAAAAqgAA AAAAAAAAAAAAAKoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAGdkKHSjAAAEAABnZNNygAAA BAAAZ2SXdV8ARgAARcaAAAABAA2EqGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJd1XwAAE+8MAABADQAAfg0AAH8NAACADQAA gQ0AAHcOAAB4DgAA2A4AANsOAADlDgAAJg8AACgPAAApDwAANw8AADgPAABLDwAAVA8AAKUPAACt DwAAcBAAAIwRAABAEgAAQRIAAOHWzsbO1riqzpuQiIBxZltTW1NbSD1TAAAAFBVo3RO5ABZorFsq AG1ICQhzSAkIABQVaN0TuQAWaI5QPwBtSAkIc0gJCAAOFmgOSJAAbUgJCHNICQgAFBVo3RO5ABZo 7H3PAG1ICQhzSAkIABQVaN0TuQAWaJo2kQBtSAkIc0gJCAAdFWjdE7kAFmiaNpEANQiBPioBXAiB bUgJCHNICQgOFmiaNpEAbUgJCHNICQgADhZoKHSjAG1ICQhzSAkIABQVaN0TuQAWaCh0owBtSAkI c0gJCAAdFWjdE7kAFmgodKMANQiBPioBXAiBbUgJCHNICQgbAQiBBEgBAAVoFISoZhZo03KAAG1I CQhzSAkIGwEIgQRIAQAFaBOEqGYWaJd1XwBtSAkIc0gJCA4WaGMiUABtSAkIc0gJCAAOFmiXdV8A bUgJCHNICQgAFBVomjaRABZol3VfAG1ICQhzSAkIADsACIEVaJo2kQAWaJd1XwAXaJd1XwBjSAEA Y0gAAGNIAQBkaAAAAABkaAAAAABkaBOEqGZtSAkIc0gJCAAXKA8AACkPAAA3DwAAOA8AAG8QAABw EAAAbxEAAHARAACMEQAAjREAAK0RAACuEQAA2BEAAAwSAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADw AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAA AAAAAAAAAOsAAAAAAAAAAAAAAAChAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABJAAAKJgALRgYARcaAAQABABOEqGYAAAAAAAAAAAAXFxcXFxcXFxcA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAbwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKxbKgAABAAAZ2Ss WyoAAAQAAGdkjlA/AAAEAABnZA5IkAAABAAAZ2QodKMAAA0MEgAAYxIAAGQSAACGEgAAhxIAADAT AAAxEwAAeRMAAHoTAAC+EwAAvxMAAPITAAC1AAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAAGYAAAAA AAAAAAAAAACwAAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAACwAAAAAAAAAAAA AAAAsAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAACwAAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAASQAACiYDC0YFAEXGgAEAAQAThKhmAQMFBwAAAAAAAAAAAAAAAAAAAAAEAAAA AQAAAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAALgABAC4AAgAuAAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2SsWyoAAAQAAGdkrFsqAABJ AAAKJgALRgYARcaAAQABABOEqGYAAAAAAAAAAAAXFxcXFxcXFxcAAAIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKxbKgAAC/ITAADzEwAAPRQAAIEUAABEFQAAdhUA AHcVAAC8FQAABhYAACUWAAAmFgAAcRYAAHIWAABzFgAAdBYAAHUWAAC/FgAACBcAAFEXAACaFwAA 4xcAACwYAAB2GAAAwBgAAAkZAAAuGQAAMBkAAFcZAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADp AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAA AAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAA AADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEAAAEA AAAEAABnZI5QPwAABAAAZ2QOSJAAAAQAAGdkrFsqAAAbQRIAAKkUAADJFAAAAxUAAAUVAABDFQAA bxYAAHEWAAByFgAAcxYAAHQWAAB2FgAA4zcAAOQ3AADVOQAACDoAABk6AAAoOgAAMjoAADU6AAD8 QAAA/UAAANdKAADvSgAAG0sAABxLAABOSwAA9e3i7eL12s/ax7+0qLSajH6afrRwtGJURlQAAAAA AAAbAQiBBEgBAAVo63uoRhZo+HDcAG1ICQhzSAkIGwEIgQRIAQAFaOV7qEYWaPhw3ABtSAkIc0gJ CBsBCIEESAEABWjke6hGFmj4cNwAbUgJCHNICQgbAQiBBEgBAAVoAXuoRhZoxSQLAG1ICQhzSAkI GwEIgQRIAQAFaAyEqGYWaJd1XwBtSAkIc0gJCBsBCIEESAEABWgLhKhmFmiXdV8AbUgJCHNICQgb AQiBBEgBAAVoCoSoZhZol3VfAG1ICQhzSAkIFgNqAAAAABZoxSQLADBKFgA8CIFVCAEAFBVomjaR ABZomjaRAG1ICQhzSAkIAA4WaJo2kQBtSAkIc0gJCAAOFmiOUD8AbUgJCHNICQgAFBVomjaRABZo rFsqAG1ICQhzSAkIAA4WaKxbKgBtSAkIc0gJCAAUFWjdE7kAFmgOSJAAbUgJCHNICQgADhZoDkiQ AG1ICQhzSAkIABQVaN0TuQAWaKxbKgBtSAkIc0gJCBpXGQAAnBkAAOIZAAASGgAATxoAAFAaAABR GgAAZhoAAGcaAACwGgAA+hoAAEUbAACQGwAAnRsAAJ4bAADkGwAAKRwAAGwcAAB4HAAAeRwAAMMc AAAMHQAATx0AAI4dAACPHQAAyh0AAP4dAAD/HQAARB4AAG0eAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAAAAAAAEAABnZJo2kQAAHW0eAABuHgAApx4AAKgeAACuHgAArx4AALke AAC6HgAABB8AAEwfAABOHwAAUB8AAFIfAACbHwAAnR8AAOYfAADrHwAA7B8AADMgAAB6IAAAvCAA AAIhAABGIQAAjiEAAJshAACcIQAAvyEAAMAhAAAIIgAAUSIAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQAAGdkmjaRAAAdUSIAAJgiAACZIgAArCIAAK0iAACyIgAA+iIA AEIjAACKIwAA0iMAABokAABiJAAAqiQAAPIkAAA6JQAAgiUAAMolAAASJgAAWiYAAKImAADqJgAA MicAAHMnAAC7JwAAAigAAEooAACSKAAA2igAACIpAABqKQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEAAB1qKQAAsikAAPopAABCKgAAiioAANIqAAAaKwAA HCsAAB4rAABnKwAAaSsAALIrAAC3KwAAuCsAAAAsAABILAAAkCwAANgsAADdLAAA7iwAAO8sAAAz LQAAdS0AAJ0tAACeLQAA5y0AAC8uAAB3LgAAwS4AANYuAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEAABnZJo2kQAAHdYuAADXLgAAES8AABIvAAAsLwAALS8AAEcvAABI LwAAki8AAJMvAADJLwAAyi8AAOovAADrLwAAHTAAAB4wAABhMAAAnzAAAOYwAAAsMQAAOTEAADox AABpMQAAajEAALQxAAD4MQAAQDIAAIQyAACRMgAAkjIAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAAAAAAAAQAAGdkmjaRAAAdkjIAAJMyAACUMgAAljIAAJgyAADhMgAA4zIAACwz AAAxMwAAMjMAAGQzAABlMwAAqDMAAO8zAAAwNAAAZzQAAGg0AACuNAAA+DQAAEI1AACKNQAA1DUA APk1AAD6NQAAQjYAAIs2AADUNgAAHjcAAGI3AACqNwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEAAB2qNwAA5TcAAOY3AAAuOAAAbzgAALM4AADXOAAA2DgA ACE5AABmOQAArjkAADY6AAA3OgAAYToAAGI6AACnOgAA7joAADA7AAB6OwAAwTsAAAI8AAARPAAA EjwAAD88AABAPAAAhjwAANA8AAARPQAAEz0AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAGdkl3VfAAAEAABnZJo2kQAAHBM9AAAVPQAAXj0AAGA9AACpPQAArj0AAK89AADwPQAA KD4AACk+AABzPgAAvT4AAM8+AADQPgAA6D4AAOk+AAAoPwAAKT8AAHM/AAC7PwAA/D8AAP0/AABD QAAAikAAAKFAAACiQAAA6kAAADFBAABIQQAASUEAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQAAGdkmjaRAAAdSUEAAHRBAAB1QQAAuEEAALlBAAD+QQAARkIAAEdCAACK QgAA0UIAAOtCAADsQgAAM0MAAHNDAAC8QwAABEQAAE1EAABzRAAAdEQAAKJEAACjRAAA6UQAADFF AAAyRQAAM0UAADVFAAA3RQAAgEUAAIJFAADLRQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAAAAAAABAAAZ2SaNpEAAB3LRQAA0EUAANFFAAAaRgAAYUYAAKhGAADsRgAA7UYAADdH AAB/RwAAx0cAAA1IAAA+SAAAP0gAAIRIAADMSAAAEkkAAFZJAACeSQAA5UkAAABKAAABSgAASkoA AI9KAADPSgAA0EoAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAEAABnZJo2kQAAGdBKAADwSgAA8UoAABtLAABjSwAAuQAAAAAAAAAAAAAAAHEA AAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAAAAAAABLAAAKJgALRgYAQyQBRcaA AAABAOZ7qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABnZPhw3AAARwAAQyQBRcaAAAABAOV7qEYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZPhw3ABGAABFxoAA AAEA5HuoRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGdk+HDcAAAETksAAGJLAABjSwAAbEsAAH9LAACSSwAArEsAAMNLAADaSwAA 20sAANxLAADnSwAA7EsAAPBLAADxSwAAAkwAABRMAAAVTAAAh0wAAL5MAAC/TAAA8ePV48fxueO5 46ughqB4XlB4QjQbAQiBBEgBAAVo6XuoRhZo+HDcAG1ICQhzSAkIGwEIgQRIAQAFaBV8qEYWaEoa 3wBtSAkIc0gJCBsBCIEESAEABWjoe6hGFmiaNpEAbUgJCHNICQgzAAiBFWiaNpEAFmiaNpEAF2j4 cNwAY0gBAGRoAAAAAGRoAAAAAGRo6HuoRm1ICQhzSAkIGwEIgQRIAQAFaOh7qEYWaPhw3ABtSAkI c0gJCDMACIEVaJo2kQAWaJo2kQAXaPhw3ABjSAEAZGgAAAAAZGgAAAAAZGjne6hGbUgJCHNICQgU FWiaNpEAFmiaNpEAbUgJCHNICQgAGwEIgQRIAQAFaOd7qEYWaPhw3ABtSAkIc0gJCBsBCIEESAEA BWgEhKhmFmjFV0cAbUgJCHNICQgbAQiBBEgBAAVo7HuoRhZo+HDcAG1ICQhzSAkIGwEIgQRIAQAF aOt7qEYWaPhw3ABtSAkIc0gJCBsBCIEESAEABWjme6hGFmj4cNwAbUgJCHNICQgbAQiBBEgBAAVo A4SoZhZoxVdHAG1ICQhzSAkIABRjSwAA3EsAAN1LAAAVTAAAtAAAAAAAAAAAAAAAAGwAAAAAAAAA AAAAAAAhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABLAAAKJgMLRgUAQyQBRcaAAAABAOd7qEYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABnZPhw3AAARwAAQyQBRcaAAAABAOd7qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZPhw3ABLAAAKJgALRgYAQyQBRcaAAAAB AOZ7qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABnZMVXRwAAAxVMAAAWTAAAv0wAAMBMAAAITQAACU0AALcAAAAAAAAAAAAAAAC3 AAAAAAAAAAAAAAAAbwAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABHAABDJAFFxoAAAAEA6XuoRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdk+HDcAABHAABDJAFFxoAAAAEA 6HuoRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGdk+HDcAAAFv0wAAMBMAAAOTQAATE0AAE1NAACATQAAgU0AADhOAABYTgAAkk4A AJROAADSTgAA1E4AALZPAAC4TwAAxE8AAMVPAAACUAAA8ePVx7muo5uNf3FXo0k7LTsAGwEIgQRI AQAFaBp8qEYWaEoa3wBtSAkIc0gJCBsBCIEESAEABWgZfKhGFmhKGt8AbUgJCHNICQgbAQiBBEgB AAVoBXyoRhZofU6xAG1ICQhzSAkIMwAIgRVomjaRABZomjaRABdoDkiQAGNIAQBkaAAAAABkaAAA AABkaPqCqGZtSAkIc0gJCBsBCIEESAEABWj6gqhmFmgOSJAAbUgJCHNICQgbAQiBBEgBAAVo+YKo ZhZoDkiQAG1ICQhzSAkIGwEIgQRIAQAFaAR8qEYWaA5IkABtSAkIc0gJCA4WaA5IkABtSAkIc0gJ CAAUFWiaNpEAFmiaNpEAbUgJCHNICQgAFBVomjaRABZo+HDcAG1ICQhzSAkIABsBCIEESAEABWjr e6hGFmj4cNwAbUgJCHNICQgbAQiBBEgBAAVo6nuoRhZo+HDcAG1ICQhzSAkIGwEIgQRIAQAFaBZ8 qEYWaEoa3wBtSAkIc0gJCBsBCIEESAEABWjpe6hGFmj4cNwAbUgJCHNICQgbAQiBBEgBAAVo6Huo RhZo+HDcAG1ICQhzSAkIABEJTQAATU0AAE5NAACBTQAAtwAAAAAAAAAAAAAAAG8AAAAAAAAAAAAA AAAnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAQyQBRcaAAAABAOp7qEYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABnZPhw3AAARwAAQyQBRcaAAAABAOt7qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZPhw3AAARwAAQyQBRcaAAAABAOl7 qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABnZEoa3wAAA4FNAACCTQAAzE0AABBOAADVTgAACE8AAAlPAABOTwAAmE8AALdPAAC4 TwAAKlAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAK0AAAAAAAAAAAAAAABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAQyQBRcaA AAABAAV8qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABnZEoa3wAARwAAQyQBRcaAAAABAAV8qEYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJo2kQAABAAAZ2QO SJAAAAQAAGdkmjaRAAALKlAAAG9QAACtUAAA8lAAADZRAAB8UQAAiFEAAIlRAACKUQAAwlEAAMNR AAAKUgAAUVIAAJlSAADeUgAAJ1MAAClTAAArUwAAdFMAAHZTAAC/UwAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAAsgAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAQyQBRcaAAAABAAh8qEYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJo2 kQAABAAAZ2SaNpEAABQCUAAAh1EAAIhRAACJUQAA5VoAAOZaAAAWWwAAMlsAADNbAACLjgAAjI4A ANiPAADZjwAA2o8AAOXXzMGzpZeMwYJ+esEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhZoPCxjAAAGFmgHcIEAABMDagAAAAAWaAdw gQAwShYAVQgBFBVomjaRABZorFsqAG1ICQhzSAkIABsBCIEESAEABWglfKhGFmipWO8AbUgJCHNI CQgbAQiBBEgBAAVoJHyoRhZorFsqAG1ICQhzSAkIGwEIgQRIAQAFaCR8qEYWaJo2kQBtSAkIc0gJ CBQVaJo2kQAWaJo2kQBtSAkIc0gJCAAUFWiaNpEAFmgxZSgAbUgJCHNICQgAGwEIgQRIAQAFaAZ8 qEYWaJo2kQBtSAkIc0gJCDMACIEVaJo2kQAWaJo2kQAXaEoa3wBjSAEAZGgAAAAAZGgAAAAAZGga fKhGbUgJCHNICQgADb9TAADEUwAAxVMAAAxUAAArVAAALFQAAF9UAABgVAAAplQAAOpUAAANVQAA DlUAACxVAAAtVQAAdlUAALVVAAC2VQAA1VUAANZVAAAbVgAAXVYAAF5WAACnVgAA7lYAADRXAAB8 VwAAw1cAAA1YAABPWAAAllgAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAQAAGdkmjaRAAAdllgAANtYAAAkWQAATlkAAE9ZAACWWQAAxlkAAMdZAAD0WQAA9VkAAD5aAACA WgAAx1oAAOZaAADnWgAAM1sAADRbAAB+WwAAxlsAAAtcAABVXAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACyAAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAQyQBRcaAAAABACR8qEYAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJo2kQAA BAAAZ2SaNpEAABRVXAAAn1wAAOdcAADpXAAA61wAADRdAAA2XQAAf10AAIRdAACFXQAAy10AABBe AAAdXgAAHl4AAGheAACuXgAA+F4AADxfAACEXwAAzl8AABVgAABeYAAAqGAAAOpgAAArYQAALGEA AHNhAACjYQAApGEAAOthAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAE AABnZJo2kQAAHethAAAXYgAAGGIAAGJiAACrYgAA9WIAADVjAAB4YwAAwmMAAApkAAAfZAAAIGQA AD9kAABAZAAAYmQAAIRkAACFZAAArWQAAK5kAAD2ZAAAEmUAABNlAABWZQAAV2UAAJ1lAADmZQAA MGYAAG9mAABxZgAAc2YAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQA AGdkmjaRAAAdc2YAALxmAAC+ZgAAB2cAAAxnAAANZwAAVWcAAJ9nAADhZwAA7mcAAO9nAAA0aAAA Q2gAAERoAACOaAAA2GgAAAlpAAAKaQAAUWkAAHppAAB7aQAAwGkAAApqAABUagAAfmoAAH9qAACq agAAq2oAAO5qAAAvawAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABAAA Z2SaNpEAAB0vawAAb2sAALlrAAD5awAAQGwAAFNsAABUbAAAnmwAAOdsAAAvbQAAPG0AAD1tAABZ bQAAWm0AAKBtAADgbQAAJ24AAGhuAACobgAAqW4AAKpuAACrbgAArG4AAK1uAACvbgAAsW4AAPpu AAD8bgAARW8AAEpvAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEAABn ZJo2kQAAHUpvAABLbwAAY28AAGRvAACtbwAA9m8AAAVwAAAGcAAAQ3AAAERwAABgcAAAYXAAAKZw AADtcAAAMXEAAHtxAADEcQAADXIAAFdyAABvcgAAcHIAALhyAADMcgAAzXIAAM5yAADPcgAA0HIA ANFyAADScgAA03IAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQAAGdk mjaRAAAd03IAANRyAADVcgAA1nIAANdyAADYcgAA2XIAANpyAADbcgAA3HIAAN1yAADecgAA33IA AOByAADhcgAA4nIAAONyAADkcgAA5XIAAOZyAADocgAA6nIAADNzAAA1cwAAfnMAAINzAACEcwAA lXMAAJZzAACwcwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABAAAZ2Sa NpEAAB2wcwAA4nMAAOxzAADxcwAAC3QAADR0AAA5dAAAS3QAAF50AAB6dAAAknQAAJ10AACidAAA wHQAAOd0AADsdAAA/HQAAAZ1AAAWdQAALnUAAEt1AABQdQAAa3UAAIZ1AACLdQAAkHUAAKR1AACl dQAA73UAACZ2AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEAABnZJo2 kQAAHSZ2AAAndgAAKHYAACl2AAAqdgAAK3YAACx2AAAtdgAALnYAAC92AAAwdgAAMXYAADJ2AAAz dgAANHYAADV2AAA3dgAAOXYAAIJ2AACEdgAAzXYAANJ2AADTdgAA4nYAAON2AAD+dgAA/3YAAEZ3 AACMdwAAjXcAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQAAGdkmjaR AAAdjXcAANV3AAAYeAAAW3gAAH54AAB/eAAAyHgAABB5AABKeQAAS3kAAIx5AADQeQAAF3oAAEJ6 AABDegAAinoAAM16AAAUewAAXXsAAIl7AACKewAA03sAABN8AABZfAAAoXwAALp8AAC7fAAA2HwA ANl8AAAgfQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEA AB0gfQAAaX0AALJ9AADVfQAA1n0AACB+AABlfgAArn4AAK9+AACwfgAAsX4AALJ+AAC0fgAAtn4A AP9+AAABfwAASn8AAE9/AABQfwAAlH8AANl/AAAegAAAN4AAADiAAACBgAAAxIAAAAqBAAALgQAA UoEAAJWBAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEAABnZJo2kQAA HZWBAADKgQAAy4EAAN+BAADggQAA84EAAAmCAAARggAALIIAAFOCAABYggAAWYIAAG2CAAB6ggAA l4IAAKeCAACsggAAyIIAAACDAAAFgwAABoMAABmDAAA9gwAAXoMAAHaDAACTgwAAm4MAALaDAADY gwAA3YMAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQAAGdkmjaRAAAd 3YMAAN6DAADfgwAA4IMAAOGDAADigwAA44MAAOSDAADmgwAA6IMAADGEAAAzhAAAfIQAAIGEAACC hAAAmIQAALaEAADYhAAA7IQAAPGEAAANhQAAL4UAADCFAABRhQAAUoUAAJiFAADihQAAKoYAAHGG AAC4hgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEAAB24 hgAAAocAAEeHAABnhwAAaIcAAKuHAADwhwAAOogAAHeIAADBiAAA3ogAAN+IAAAniQAAbIkAALOJ AAD1iQAADIoAAA2KAAAligAAJooAAHCKAAC6igAAAYsAAEmLAACLiwAAzosAABWMAAAWjAAAK4wA ACyMAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEAABnZJo2kQAAHSyM AABbjAAAXIwAAF2MAABfjAAAYYwAAKqMAACsjAAA9YwAAPqMAAD7jAAAQY0AAIeNAACkjQAApY0A ALWNAAC2jQAA+40AABGOAAASjgAAF44AABiOAAAZjgAAGo4AABuOAAAcjgAAHY4AAB6OAAAfjgAA II4AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQAAGdkmjaRAAAdII4A ACGOAAAijgAAI44AACSOAAAljgAAJo4AACeOAAAojgAAKY4AACqOAAArjgAALI4AAC2OAAAujgAA L44AADCOAAAxjgAAMo4AADOOAAA0jgAANY4AADaOAAA3jgAAOI4AADmOAAA6jgAAO44AADyOAAA+ jgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEAAB0+jgAA QI4AAImOAACLjgAAUI8AANiPAADZjwAA2o8AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPgAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABBcAZ2TFJAsAAAEXAAAEAABnZJo2kQAAByAAMZBo AR+w0C8gsOA9IbAIByKwCAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAGgASAAEAnAAPAAMA AAADAAAAAABMAABA8f8CAEwADAAAAAAAAAAAAAoATgBvAHIAbQBhAGwALABOAGUAdwAAAAIAAAAc AENKGABfSA0EYUoYAG1ICQRuSAQIc0gJBHRIBAhaAAFAAQACAFoADAAAALQp+AAAAAkASABlAGEA ZABpAG4AZwAgADEAAAAQAAEABiQBE6TwABSkPABAJgAeADUIgUNKIABLSCAAT0oCAFFKAgBcCIFe SgIAYUogAFwAAkABAAIAXAAMAAAAtCn4AAAACQBIAGUAYQBkAGkAbgBnACAAMgAAABAAAgAGJAET pPAAFKQ8AEAmASAANQiBNgiBQ0ocAE9KAgBRSgIAXAiBXQiBXkoCAGFKHABWAANAAQACAFYADAAA ALQp+AAAAAkASABlAGEAZABpAG4AZwAgADMAAAAQAAMABiQBE6TwABSkPABAJgIaADUIgUNKGgBP SgIAUUoCAFwIgV5KAgBhShoASgAEQAEAAgBKAAwAAAC0KfgAAAAJAEgAZQBhAGQAaQBuAGcAIAA0 AAAAEAAEAAYkAROk8AAUpDwAQCYDDgA1CIFDShwAXAiBYUocAAAAAAAAAAAAAABEAEFA8v+hAEQA DAEAAAAAAAAAABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAA AAAAUgBpQPP/swBSAAwBAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMA ADTWBgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABrQPT/wQAoAAABAAAAAAAAAAAHAE4AbwAg AEwAaQBzAHQAAAACAAAAAAAAAJYA/k8RAAIAlgAMAAAAtCn4AAAACwBBAG4AbgBlAHgAXwBUAGkA dABsAGUAAAA1AA8AAyQBBSQBByQBCiYAC0YEAA3GBQAB0AIGD4TQAhGEmP4TpFAAFKQUAF6E0AJg hJj+YSQBAC8AQ0oYAEtIAABPSgAAUEoAAFFKAABcCIFeSgAAX0gBBGFKFABtSAkIc0gJCHRICQQA nAD+TyEAAgGcAAwAAAC0KfgAAAAMAEEAbgBuAGUAeABfAFQAaQB0AGwAZQAxAAAANwAQAAMkAwUk AQomAQtGBAANxgcBaAEBoAUGD4SgBRGEmP4TpDkBFKQAAEAmCV6EoAVghJj+YSQDADEANgiBQ0oW AE9KAABQSgAAUUoAAFwIgV0IgV5KAABfSAEEYUoUAG1ICQhzSAkIdEgJBACWAP5PMQASAZYADAAA ALQp+AAAAAwAQQBuAG4AZQB4AF8AVABpAHQAbABlADIAAAA3ABEAAyQDBSQBCiYCC0YEAA3GBwHQ AgFwCAYPhHAIEYSY/hOktQAUpAAAQCYJXoRwCGCEmP5hJAMAKwBDShQAT0oAAFBKAABRSgAAXAiB XkoAAF9IAQRhShQAbUgJCHNICQh0SAkEAIoA/k9BACIBigAMAAAAtCn4AAAADABBAG4AbgBlAHgA XwBUAGkAdABsAGUAMwAAADcAEgADJAMFJAEKJgMLRgQADcYHAdACAUALBg+EQAsRhJj+E6S1ABSk AABAJglehEALYISY/mEkAwAfAENKFABQSgAAXAiBX0gBBGFKFABtSAkIc0gJCHRICQQAdgD+TwEA MgF2AAwAAAClXdYAAAAIAFIAZQBxACcAbQBlAG4AdAAAAC4AEwANxgUAAW4EwA+EpQYRhJL7E6R4 ADUkADckADgkADlEAgBIJABehKUGYISS+x4ANQiBUEoAAFwIgV9IAQRhShQAbUgJCHNICQh0SAkE igD+TwEAQgGKAAwAAACTCZEAAAAQAFIAZQBxACcAbQBlAG4AdABfAEkAbgBkAGUAbgB0ADEAAAAx ABQADcYIAAJuBKUGwMAPhKUGEYTJ/ROkeAA1JAA3JAA4JAA5RAIASCQAXoSlBmCEyf0AHgA1CIFQ SgAAXAiBX0gBBGFKFABtSAkIc0gJCHRICQR8AP5PAQBSAXwADAAAAJMJkQAAABAAUgBlAHEAJwBt AGUAbgB0AF8ASQBuAGQAZQBuAHQAMgAAACYAFQANxgUAAdwIwA+EpQYTpHgANSQANyQAOCQAOUQC AEgkAF6EpQYbADUIgVBKAABfSAEEYUoUAG1ICQhzSAkIdEgJBABCACdAogBhAUIADAEAAMUkCwAA ABEAQwBvAG0AbQBlAG4AdAAgAFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShAAYUoQADwAHkABAHIB PAAMAQAAxSQLAAAADABDAG8AbQBtAGUAbgB0ACAAVABlAHgAdAAAAAIAFwAIAENKFABhShQAQABq QHEBcgFAAAwBAADFJAsAAAAPAEMAbwBtAG0AZQBuAHQAIABTAHUAYgBqAGUAYwB0AAAAAgAYAAYA NQiBXAiBSACZQAEAkgFIAAwBAADFJAsAAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAAAgAZ ABQAQ0oQAE9KBABRSgQAXkoEAGFKEAANAFQAcgBlAHYAbwByACAAVwBpAGwAcwBvAG4A4y8AANqH AAACAFQAVwAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////3eqhGAAAAAAAAAAAAAAAAAAAAAAAATQEA AFABAAAAAAAA2ocAAAwAAOwAAAoA/////wAAAAAIAAAACQAAANsAAADcAAAA6QAAAOoAAAANAQAA DgEAAIIBAACDAQAAJgIAACcCAAByAwAAnAMAAJ0DAADfAwAAKAQAAHEEAAC7BAAA/wQAAEcFAACA BQAAgQUAAMQFAAAJBgAAUQYAANkGAADaBgAA2wYAAOUGAADmBgAAJwcAACgHAAApBwAANwcAADgH AABvCAAAcAgAAG8JAABwCQAAjAkAAI0JAACtCQAArgkAANgJAAAMCgAAYwoAAGQKAACGCgAAhwoA ADALAAAxCwAAeQsAAHoLAAC+CwAAvwsAAPILAADzCwAAPQwAAIEMAABEDQAAdg0AAHcNAAC8DQAA Bg4AACUOAAAmDgAAcQ4AAHIOAABzDgAAdA4AAHUOAAC/DgAACA8AAFEPAACaDwAA4w8AACwQAAB2 EAAAwBAAAAkRAAAuEQAAMBEAAFcRAACcEQAA4hEAABISAABPEgAAUBIAAFESAABmEgAAZxIAALAS AAD6EgAARRMAAJATAACdEwAAnhMAAOQTAAApFAAAbBQAAHgUAAB5FAAAwxQAAAwVAABPFQAAjhUA AI8VAADKFQAA/hUAAP8VAABEFgAAbRYAAG4WAACnFgAAqBYAAK4WAACvFgAAuRYAALoWAAAEFwAA TBcAAE4XAABQFwAAUhcAAJsXAACdFwAA5hcAAOsXAADsFwAAMxgAAHoYAAC8GAAAAhkAAEYZAACO GQAAmxkAAJwZAAC/GQAAwBkAAAgaAABRGgAAmBoAAJkaAACsGgAArRoAALIaAAD6GgAAQhsAAIob AADSGwAAGhwAAGIcAACqHAAA8hwAADodAACCHQAAyh0AABIeAABaHgAAoh4AAOoeAAAyHwAAcx8A ALsfAAACIAAASiAAAJIgAADaIAAAIiEAAGohAACyIQAA+iEAAEIiAACKIgAA0iIAABojAAAcIwAA HiMAAGcjAABpIwAAsiMAALcjAAC4IwAAACQAAEgkAACQJAAA2CQAAN0kAADuJAAA7yQAADMlAAB1 JQAAnSUAAJ4lAADnJQAALyYAAHcmAADBJgAA1iYAANcmAAARJwAAEicAACwnAAAtJwAARycAAEgn AACSJwAAkycAAMknAADKJwAA6icAAOsnAAAdKAAAHigAAGEoAACfKAAA5igAACwpAAA5KQAAOikA AGkpAABqKQAAtCkAAPgpAABAKgAAhCoAAJEqAACSKgAAkyoAAJQqAACWKgAAmCoAAOEqAADjKgAA LCsAADErAAAyKwAAZCsAAGUrAACoKwAA7ysAADAsAABnLAAAaCwAAK4sAAD4LAAAQi0AAIotAADU LQAA+S0AAPotAABCLgAAiy4AANQuAAAeLwAAYi8AAKovAADlLwAA5i8AAC4wAABvMAAAszAAANcw AADYMAAAITEAAGYxAACuMQAANjIAADcyAABhMgAAYjIAAKcyAADuMgAAMDMAAHozAADBMwAAAjQA ABE0AAASNAAAPzQAAEA0AACGNAAA0DQAABE1AAATNQAAFTUAAF41AABgNQAAqTUAAK41AACvNQAA 8DUAACg2AAApNgAAczYAAL02AADPNgAA0DYAAOg2AADpNgAAKDcAACk3AABzNwAAuzcAAPw3AAD9 NwAAQzgAAIo4AAChOAAAojgAAOo4AAAxOQAASDkAAEk5AAB0OQAAdTkAALg5AAC5OQAA/jkAAEY6 AABHOgAAijoAANE6AADrOgAA7DoAADM7AABzOwAAvDsAAAQ8AABNPAAAczwAAHQ8AACiPAAAozwA AOk8AAAxPQAAMj0AADM9AAA1PQAANz0AAIA9AACCPQAAyz0AANA9AADRPQAAGj4AAGE+AACoPgAA 7D4AAO0+AAA3PwAAfz8AAMc/AAANQAAAPkAAAD9AAACEQAAAzEAAABJBAABWQQAAnkEAAOVBAAAA QgAAAUIAAEpCAACPQgAAz0IAANBCAADwQgAA8UIAABtDAABjQwAA3EMAAN1DAAAVRAAAFkQAAL9E AADARAAACEUAAAlFAABNRQAATkUAAIFFAACCRQAAzEUAABBGAADVRgAACEcAAAlHAABORwAAmEcA ALdHAAC4RwAAKkgAAG9IAACtSAAA8kgAADZJAAB8SQAAiEkAAIlJAACKSQAAwkkAAMNJAAAKSgAA UUoAAJlKAADeSgAAJ0sAAClLAAArSwAAdEsAAHZLAAC/SwAAxEsAAMVLAAAMTAAAK0wAACxMAABf TAAAYEwAAKZMAADqTAAADU0AAA5NAAAsTQAALU0AAHZNAAC1TQAAtk0AANVNAADWTQAAG04AAF1O AABeTgAAp04AAO5OAAA0TwAAfE8AAMNPAAANUAAAT1AAAJZQAADbUAAAJFEAAE5RAABPUQAAllEA AMZRAADHUQAA9FEAAPVRAAA+UgAAgFIAAMdSAADmUgAA51IAADNTAAA0UwAAflMAAMZTAAALVAAA VVQAAJ9UAADnVAAA6VQAAOtUAAA0VQAANlUAAH9VAACEVQAAhVUAAMtVAAAQVgAAHVYAAB5WAABo VgAArlYAAPhWAAA8VwAAhFcAAM5XAAAVWAAAXlgAAKhYAADqWAAAK1kAACxZAABzWQAAo1kAAKRZ AADrWQAAF1oAABhaAABiWgAAq1oAAPVaAAA1WwAAeFsAAMJbAAAKXAAAH1wAACBcAAA/XAAAQFwA AGJcAACEXAAAhVwAAK1cAACuXAAA9lwAABJdAAATXQAAVl0AAFddAACdXQAA5l0AADBeAABvXgAA cV4AAHNeAAC8XgAAvl4AAAdfAAAMXwAADV8AAFVfAACfXwAA4V8AAO5fAADvXwAANGAAAENgAABE YAAAjmAAANhgAAAJYQAACmEAAFFhAAB6YQAAe2EAAMBhAAAKYgAAVGIAAH5iAAB/YgAAqmIAAKti AADuYgAAL2MAAG9jAAC5YwAA+WMAAEBkAABTZAAAVGQAAJ5kAADnZAAAL2UAADxlAAA9ZQAAWWUA AFplAACgZQAA4GUAACdmAABoZgAAqGYAAKlmAACqZgAAq2YAAKxmAACtZgAAr2YAALFmAAD6ZgAA /GYAAEVnAABKZwAAS2cAAGNnAABkZwAArWcAAPZnAAAFaAAABmgAAENoAABEaAAAYGgAAGFoAACm aAAA7WgAADFpAAB7aQAAxGkAAA1qAABXagAAb2oAAHBqAAC4agAAzGoAAM1qAADOagAAz2oAANBq AADRagAA0moAANNqAADUagAA1WoAANZqAADXagAA2GoAANlqAADaagAA22oAANxqAADdagAA3moA AN9qAADgagAA4WoAAOJqAADjagAA5GoAAOVqAADmagAA6GoAAOpqAAAzawAANWsAAH5rAACDawAA hGsAAJVrAACWawAAsGsAAOJrAADsawAA8WsAAAtsAAA0bAAAOWwAAEtsAABebAAAemwAAJJsAACd bAAAomwAAMBsAADnbAAA7GwAAPxsAAAGbQAAFm0AAC5tAABLbQAAUG0AAGttAACGbQAAi20AAJBt AACkbQAApW0AAO9tAAAmbgAAJ24AAChuAAApbgAAKm4AACtuAAAsbgAALW4AAC5uAAAvbgAAMG4A ADFuAAAybgAAM24AADRuAAA1bgAAN24AADluAACCbgAAhG4AAM1uAADSbgAA024AAOJuAADjbgAA /m4AAP9uAABGbwAAjG8AAI1vAADVbwAAGHAAAFtwAAB+cAAAf3AAAMhwAAAQcQAASnEAAEtxAACM cQAA0HEAABdyAABCcgAAQ3IAAIpyAADNcgAAFHMAAF1zAACJcwAAinMAANNzAAATdAAAWXQAAKF0 AAC6dAAAu3QAANh0AADZdAAAIHUAAGl1AACydQAA1XUAANZ1AAAgdgAAZXYAAK52AACvdgAAsHYA ALF2AACydgAAtHYAALZ2AAD/dgAAAXcAAEp3AABPdwAAUHcAAJR3AADZdwAAHngAADd4AAA4eAAA gXgAAMR4AAAKeQAAC3kAAFJ5AACVeQAAynkAAMt5AADfeQAA4HkAAPN5AAAJegAAEXoAACx6AABT egAAWHoAAFl6AABtegAAenoAAJd6AACnegAArHoAAMh6AAAAewAABXsAAAZ7AAAZewAAPXsAAF57 AAB2ewAAk3sAAJt7AAC2ewAA2HsAAN17AADeewAA33sAAOB7AADhewAA4nsAAON7AADkewAA5nsA AOh7AAAxfAAAM3wAAHx8AACBfAAAgnwAAJh8AAC2fAAA2HwAAOx8AADxfAAADX0AAC99AAAwfQAA UX0AAFJ9AACYfQAA4n0AACp+AABxfgAAuH4AAAJ/AABHfwAAZ38AAGh/AACrfwAA8H8AADqAAAB3 gAAAwYAAAN6AAADfgAAAJ4EAAGyBAACzgQAA9YEAAAyCAAANggAAJYIAACaCAABwggAAuoIAAAGD AABJgwAAi4MAAM6DAAAVhAAAFoQAACuEAAAshAAAW4QAAFyEAABdhAAAX4QAAGGEAACqhAAArIQA APWEAAD6hAAA+4QAAEGFAACHhQAApIUAAKWFAAC1hQAAtoUAAPuFAAARhgAAEoYAABeGAAAYhgAA GYYAABqGAAAbhgAAHIYAAB2GAAAehgAAH4YAACCGAAAhhgAAIoYAACOGAAAkhgAAJYYAACaGAAAn hgAAKIYAACmGAAAqhgAAK4YAACyGAAAthgAALoYAAC+GAAAwhgAAMYYAADKGAAAzhgAANIYAADWG AAA2hgAAN4YAADiGAAA5hgAAOoYAADuGAAA8hgAAPoYAAECGAACJhgAAi4YAAFCHAADYhwAA24cA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgABiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAYgADABAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgDBSAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJiABiAAMAIAAAAAAACA AAAAgAAAAAAAAAAAEACYgAYgADADAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAQAJiDBSAAMAEAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAgAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA CACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAI AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmkAAABcwAAAAAAAAAIAAAACAAAAAAAAAAAAABJhAAAAXMAAAAAAAAACAAAAAgAAAAAAA AAAAgAQKAAAAADAAAAAAAAAAAAAAAAAAANz+4AAEAAAHAAAAAAgAAAAJAAAA2wAAANwAAADpAAAA 6gAAAA0BAAAOAQAAggEAAIMBAAAmAgAAJwIAAHIDAACcAwAAnQMAAN8DAAAoBAAAcQQAALsEAAD/ BAAARwUAAIAFAACBBQAAxAUAAAkGAABRBgAA2QYAANoGAADbBgAA5QYAAOYGAAAnBwAAKAcAACkH AAA3BwAAOAcAAG8IAABwCAAAbwkAAHAJAACMCQAAjQkAAK0JAACuCQAA2AkAAAwKAABjCgAAZAoA AIYKAACHCgAAMAsAADELAAB5CwAAegsAAL4LAAC/CwAA8gsAAPMLAAA9DAAAgQwAAEQNAAB2DQAA dw0AALwNAAAGDgAAJQ4AACYOAABxDgAAcg4AAHMOAAB0DgAAdQ4AAL8OAAAIDwAAUQ8AAJoPAADj DwAALBAAAHYQAADAEAAACREAAC4RAAAwEQAAVxEAAJwRAADiEQAAEhIAAE8SAABQEgAAURIAAGYS AABnEgAAsBIAAPoSAABFEwAAkBMAAJ0TAACeEwAA5BMAACkUAABsFAAAeBQAAHkUAADDFAAADBUA AE8VAACOFQAAjxUAAMoVAAD+FQAA/xUAAEQWAABtFgAAbhYAAKcWAACoFgAArhYAAK8WAAC5FgAA uhYAAAQXAABMFwAAThcAAFAXAABSFwAAmxcAAJ0XAADmFwAA6xcAAOwXAAAzGAAAehgAALwYAAAC GQAARhkAAI4ZAACbGQAAnBkAAL8ZAADAGQAACBoAAFEaAACYGgAAmRoAAKwaAACtGgAAshoAAPoa AABCGwAAihsAANIbAAAaHAAAYhwAAKocAADyHAAAOh0AAIIdAADKHQAAEh4AAFoeAACiHgAA6h4A ADIfAABzHwAAux8AAAIgAABKIAAAkiAAANogAAAiIQAAaiEAALIhAAD6IQAAQiIAAIoiAADSIgAA GiMAABwjAAAeIwAAZyMAAGkjAACyIwAAtyMAALgjAAAAJAAASCQAAJAkAADYJAAA3SQAAO4kAADv JAAAMyUAAHUlAACdJQAAniUAAOclAAAvJgAAdyYAAMEmAADWJgAA1yYAABEnAAASJwAALCcAAC0n AABHJwAASCcAAJInAACTJwAAyScAAMonAADqJwAA6ycAAB0oAAAeKAAAYSgAAJ8oAADmKAAALCkA ADkpAAA6KQAAaSkAAGopAAC0KQAA+CkAAEAqAACEKgAAkSoAAJIqAACTKgAAlCoAAJYqAACYKgAA 4SoAAOMqAAAsKwAAMSsAADIrAABkKwAAZSsAAKgrAADvKwAAMCwAAGcsAABoLAAAriwAAPgsAABC LQAAii0AANQtAAD5LQAA+i0AAEIuAACLLgAA1C4AAB4vAABiLwAAqi8AAOUvAADmLwAALjAAAG8w AACzMAAA1zAAANgwAAAhMQAAZjEAAK4xAAA2MgAANzIAAGEyAABiMgAApzIAAO4yAAAwMwAAejMA AMEzAAACNAAAETQAABI0AAA/NAAAQDQAAIY0AADQNAAAETUAABM1AAAVNQAAXjUAAGA1AACpNQAA rjUAAK81AADwNQAAKDYAACk2AABzNgAAvTYAAM82AADQNgAA6DYAAOk2AAAoNwAAKTcAAHM3AAC7 NwAA/DcAAP03AABDOAAAijgAAKE4AACiOAAA6jgAADE5AABIOQAASTkAAHQ5AAB1OQAAuDkAALk5 AAD+OQAARjoAAEc6AACKOgAA0ToAAOs6AADsOgAAMzsAAHM7AAC8OwAABDwAAE08AABzPAAAdDwA AKI8AACjPAAA6TwAADE9AAAyPQAAMz0AADU9AAA3PQAAgD0AAII9AADLPQAA0D0AANE9AAAaPgAA YT4AAKg+AADsPgAA7T4AADc/AAB/PwAAxz8AAA1AAAA+QAAAP0AAAIRAAADMQAAAEkEAAFZBAACe QQAA5UEAAABCAAABQgAASkIAAI9CAADPQgAA0EIAAPBCAADxQgAAG0MAAGNDAADcQwAA3UMAABVE AAAWRAAAv0QAAMBEAAAIRQAACUUAAE1FAABORQAAgUUAAIJFAADMRQAAEEYAANVGAAAIRwAACUcA AE5HAACYRwAAt0cAALhHAAAqSAAArUgAAPJIAAA2SQAAfEkAAIhJAACJSQAA9VEAAD5SAACAUgAA x1IAAOZSAADnUgAAM1MAADyGAAA+hgAAQIYAAImGAACLhgAA24cAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAIABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAgAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAIABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAXlAATAMMAAAAAAAAAEAAAABAAAAAAAA AAAAkAF5QAEwDDAAAAAAAAABAAAAAQAAAAAAAAAAAIABeUABMAwwAAAAAAAAAQAAAAEAAAAAAAAA AACAB5hAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYQAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmEAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAAZhAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAGYQAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAgBmEAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA AZhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAGYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAB mEAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAAZhAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAGY QAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAABmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAZhA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAGYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5gAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5gAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5iABiAAMAAAAAAA AACAAAAAgAAAAAAAAAAAgAeYgAYgADABAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAACAB5iDBSAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAA AAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAA ADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAA MAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAw AAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAA AAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAA AAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAA AAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAA AACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAA gAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA gAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACA AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAA AAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAA ADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAA MAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAw AAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAA AAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAA AAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAA AAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAA AACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAA gAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA gAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACA AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAA AAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAA ADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAA MAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAw AAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAA AAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAA AAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAA AAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAA AACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAA gAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA gAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACA AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAA AAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAA ADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAA MAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAw AAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAA AAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAA AAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAA AAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAA AACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAA gAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA gAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACA AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAADgAAAAAAAHmAAA AAAwAAAAAAAAAIAAAACAAAAA4AAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAOAAAAAAAAeYAAAA ADAAAAAAAAAAgAAAAIAAAADgAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAA AAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAA AAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAA AAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAA AACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAA gAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA UAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQ AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAHmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQB5iABiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAkAeYgAYg ADABAAAAAAAAgAAAAIAAAAAAAAAAABAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACQB5iDBSAA MAAAAAAzBQAAAAAAgAAAAAAAAAAAkAeYAwUgADABAAAAMwUAAAAAAIAAAAAAAAAAABAHeUABMHsx AAAAAAAAAQAAAAEAAAAACAAAAACQB3lAATB7MQAAAAAAAAEAAAABAAAAAAgAAAAAkAeYAwUgADAB AAAAMwUAAAAAAIAAAAAAAAAAABAHmAMFIAAwAQAAADMFAAAAAACAAAAAAAAAAAAQB5hDBSAAMAEA AAAzBQAAAAAAgAAAAAAAAAAAEAeYAwUgADABAAAAMwUAAAAAAIAAAAAAAAAAABAHmAMFIAAwAQAA ADMFAAAAAACAAAAAAAAAAAAAB3lAATCCMQAAAAAAAAEAAAABAAAAAAgAAAAAgAd5QAEwgjEAAAAA AAABAAAAAQAAAAAIAAAAAIAHeUABMIIxAAAAAAAAAQAAAAEAAAAACAAAAACAB3lAATCCMQAAAAAA AAIAAAABAAAAAAgAAAAAgAd5QAEwADAAAAAAAAABAAAAAQAAAAAIAAAAAAAHeUABMIcxAAAAAAAA AQAAAAEAAAAACAAAAACAB3lAATCHMQAAAAAAAAIAAAABAAAAAAgAAAAAgAd5QAEwADAAAAAAAAAB AAAAAQAAAAAIAAAAAAAHeUABMAAwAAAAAAAAAQAAAAEAAAAACAAAAAAQB3lAATAAMAAAAAAAAAEA AAABAAAAAAgAAAAAEAd5QAEwADAAAAAAAAABAAAAAQAAAAAIAAAAAAgHeUABMI0xAAAAAAAAAQAA AAEAAAB4DN8APDL+B3lAATCNMQAAAAAAAAEAAAABAAAAAAgAAAAAiAd5QAEwjTEAAAAAAAACAAAA AQAAAAAIAAAAAIgHeUABMAAwAAAAAAAAAQAAAAEAAAAACAAAAAAIB3lAATAAMAAAAAAAAAEAAAAB AAAAAAgAAAAAEAd5QAEwADAAAAAAAAABAAAAAQAAAAAIAAAAAAAHeUABMI8xAAAAAAAAAQAAAAEA AAB4DN8ArDL+B3lAATCPMQAAAAAAAAEAAAABAAAAAAgAAAAAgAd5QAEwjzEAAAAAAAACAAAAAQAA AAAIAAAAAIAHeUABMAAwAAAAAAAAAQAAAAEAAAAACAAAAAAAB3lAATAAMAAAAAAAAAEAAAABAAAA AAgAAAAAEAd5QAEwADAAAAAAAAABAAAAAQAAAAAIAAAAABAHeUABMAAwAAAAAAAAAQAAAAEAAAAA CAAAAAAAB3lAATAAMAAAAAAAAAEAAAABAAAAeAzfAPyCBQd5QAEwADAAAAAAAAABAAAAAQAAAAAI AAAAAAAHeUABMAAwAAAAAAAAAgAAAAEAAAAACAAAAAAABwAAAAAAMAAAAAAAAAAAAAAAAAAAAAAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIDfAAEAAAA9gQIHeUABMAAAAAAAAAAAAQAAAAEAAAAAAAAA gBPfBwAGAADvDAAAQRIAAE5LAAC/TAAAAlAAANqPAABIAAAATAAAAFAAAABcAAAAXwAAAGMAAAAA BgAAnAsAACgPAAAMEgAA8hMAAFcZAABtHgAAUSIAAGopAADWLgAAkjIAAKo3AAATPQAASUEAAMtF AADQSgAAY0sAABVMAAAJTQAAgU0AACpQAAC/UwAAllgAAFVcAADrYQAAc2YAAC9rAABKbwAA03IA ALBzAAAmdgAAjXcAACB9AACVgQAA3YMAALiGAAAsjAAAII4AAD6OAADajwAASQAAAEsAAABNAAAA TgAAAE8AAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAF0AAABe AAAAYAAAAGEAAABiAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4A AABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAAAYAANmPAABKAAAA//84AAAABgBeLGoAAAAB ACzuIgAGAF8sagAAAAEArPGAAwYAYCxqAAAAAQDMiX4DBgBhLGoAAAABAAzEGwAGAGIsagAAAAEA PP1/AwYAYyxqAAAAAQC08n8DBgBkLGoAAAABAPQhHAAGAGUsagAAAAEAhBOAAwYAZixqAAAAAQB8 /H8DBgBnLGoAAAABANyTgAMGAGgsagAAAAEALLx/AwYAaSxqAAAAAQC8/H8DBgBqLGoAAAABAMx9 gAMGAGssagAAAAEAjMMbAAYAbCxqAAEAAQBUcIEDBgBtLGoAAAABADQSgAMGAG4sagABAAEA1KqA AwYAbyxqAAAAAQCEJ4ADBgBwLGoAAQABAGy7CAkGAHEsagAAAAEADH8KCQYAcixqAAEAAQDMfgoJ BgBzLGoAAAABALwhDAcGAHQsagABAAEA3FiBAwYAdSxqAAAAAQAcCfoIBgB2LGoAAQABALRBfgMG AHcsagABAAEALB3zBgYAeCxqAAEAAQAcXYEDBgB5LGoAAAABACyWfgMGAHosagABAAEAjH4KCQYA eyxqAAAAAQBcLQgHBgB8LGoAAAABAGwhCAcGAH0sagAAAAEARDAIBwYAfixqAAAAAQCcsYEDBgB/ LGoAAAABAPwUhAMGAIAsagAAAAEA9CEgAAYAgSxqAAAAAQBkEyAABgCCLGoAAQABAEzEGwAGAIMs agAAAAEAbB+IAwYAhCxqAAEAAQCMDyAABgCFLGoAAAABAKQHfgMGAIYsagABAAEA9EaEAwYAhyxq AAAAAQD8v34DBgCILGoAAQABAFQ2ggMGAIksagABAAEATCmCAwYAiixqAAAAAQDs+yIABgCLLGoA AQABAMzPAAcGAIwsagABAAEArDWCAwYAjSxqAAEAAQAM4H8DBgCOLGoAAAABAMSuhwMGAI8sagAB AAEA9DCCAwYAkCxqAAAAAQAcRoIDBgCRLGoAAAACAPxLGwAGAJIsagAAAAEA1EyCAwYAkyxqAAEA AQDMOIIDBgCULGoAAAABAFQqIAAGAJUsagAAAAEAJDiCA/kQAACUFgAAcRcAAD0jAAC3KgAANDUA AKY6AABWPQAASksAAApVAACSXgAA0GYAAAlrAADFawAAxWsAAOVrAADlawAATmwAAE5sAACVbAAA lWwAAAltAAAJbQAAGW0AABltAAAkbQAAJ20AADFtAAAxbQAAWG4AAAl2AADVdgAAg3cAAGt4AAA+ eQAAmnoAAJp6AACgegAAoHoAADR7AAA0ewAAQHsAAEB7AABWewAAYXsAAGF7AABsewAAb3sAAHl7 AAB5ewAAB3wAAIV8AADffAAA33wAAICEAABfhgAA24cAAAAAAAABAAEAAAABAAIAAAABAAMAAAAB AAQAAAABAAUAAAABAAYAAAABAAcAAAABAAgAAAABAAkAAAABAAoAAAABAAsAAAABAAwAAAABAA0A AAACAA4AAAACAA8AAAACABAAAAACABEAAAACABIAAAACABMAAAACABQAAAACABYAAAACABUAAAAC ABkAAAACABcAAAACABgAAAACABoAAAACABsAAAACABwAAAACAB0AAAABAB4AAAABAB8AAAABACAA AAABACEAAAABACIAAAABACMAAAACACQAAAACACUAAAACACYAAAACACcAAAACACgAAAACACoAAAAC ACkAAAACACsAAAACAC4AAAACACwAAAACAC0AAAACAC8AAAACADAAAAACADEAAAACADIAAAABADMA AAABADQAAAACADUAAAACADYAAAABADcAAAABAAcRAACkFgAAgRcAAE0jAADHKgAARDUAAKw6AABm PQAAWksAABpVAACiXgAA4GYAABlrAADNawAAzWsAAOprAADqawAAVGwAAFRsAACbbAAAm2wAAA9t AAATbQAAIm0AACZtAAAsbQAALG0AAEltAABJbQAAaG4AAA52AADldgAAiHcAAHB4AABDeQAAn3oA AJ96AAClegAApXoAADt7AAA7ewAARHsAAFh7AABYewAAansAAG57AAB0ewAAdHsAAJF7AACRewAA F3wAAJZ8AADqfAAA6nwAAJCEAABvhgAA24cAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAH AAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABYA AQAVAAAAGAABABkAAQAXAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAA ACQAAAAlAAAAJgAAACcAAAAoAAAAKgABACkAAAArAAAALQABAC4AAQAsAAAALwAAADAAAAAxAAAA MgAAADMAAAA0AAAANQAAADYAAAA3AAAACQAAADgAAAAqAAAAKoB1cm46c2NoZW1hcy1taWNyb3Nv ZnQtY29tOm9mZmljZTpzbWFydHRhZ3MEgENpdHkAgEIAAAAoAAAAKoB1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MOgGNvdW50cnktcmVnaW9uAIA5AAAAMgAAACqAdXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzBYBwbGFjZQCAOAAAADgAAAAq gHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwSAZGF0ZQCAOwAAACMA AAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncweAYWRkcmVzcwCA OgAAACIAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwaAU3Ry ZWV0AIA5AAAAHwAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdz BYBTdGF0ZQCAPgAAAB4AAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0 dGFncwqAUG9zdGFsQ29kZQCAPgAAAAUAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOnNtYXJ0dGFncwqAUGVyc29uTmFtZQCADAAAAQEAAAAIAAAAAYAyBIAyMDA2BIAyMDA3AYA0 AYA4A4BEYXkFgE1vbnRoBIBZZWFyOAADAAAABgAAAAQAAAAFAAAAAwAAAAcAAAABAAAAOAADAAAA BgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAAD AAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAA OAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAMgAAAAAAOAADAAAABgAAAAAAAAAFAAAAAwAA AAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAA AwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAF AAAAAwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAMgAAAAAAKgAAAAAA MgAAAAAAKAAAAAAAMgAAAAAAKAAAAAAAMgAAAAAAKAAAAAAAIwAAAAAAIgAAAAAAMgAAAAAAKgAA AAAAHwAAAAAAHgAAAAAAMgAAAAAAKAAAAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAA MgAAAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAMgAAAAAAMgAAAAAAMgAAAAAAMgAA AAAAKgAAAAAAMgAAAAAAKAAAAAAAMgAAAAAAKAAAAAAAMgAAAAAAKgAAAAAAHwAAAAAAMgAAAAAA KgAAAAAAHwAAAAAAHgAAAAAAMgAAAAAAKAAAAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAAC AAAABQAAAAAAMgAAAAAAKAAAAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAADAAAA BgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAAAAAACcBAAA3AQAAqwEAALQBAAB0AgAAfQIAAMECAADK AgAApQcAAK0HAAAUCgAAHwoAAIQMAACNDAAATA0AAFUNAABHDwAATw8AANUPAADbDwAAbBAAAHQQ AAC4EAAAvhAAAOcUAADwFAAAZhkAAHQZAAB9HAAAhhwAADIeAAA2HgAAeCAAAHwgAABvJwAAcycA ACo0AAAzNAAAYzQAAGw0AAA5NwAAQjcAAOE/AADlPwAA5j8AAO8/AADlQAAA6UAAAJJCAACbQgAA a0MAAHZDAAATRgAAHEYAAN1GAADmRgAAQ0wAAEdMAACXTAAAm0wAAJxMAACkTAAAYlAAAGZQAACQ UAAAlFAAAN9SAADjUgAAvVMAAMFTAADuVQAA8lUAAD9WAABDVgAAd1YAAHtWAAAbVwAAH1cAAJdY AACbWAAAAVsAAAVbAACEXwAAjV8AAKVfAACuXwAAe2AAAIRgAADgYAAA6WAAAGNiAABnYgAApGIA AKhiAAB1ZAAAeWQAAI1lAACRZQAAr2gAALhoAAAYaQAAIWkAAFRpAABYaQAAmWsAAJ9rAACgawAA p2sAALdrAADEawAAxWsAAM1rAAA8bAAAQmwAAENsAABJbAAAcmwAAHhsAACDbAAAimwAAItsAACQ bAAAvGwAAL5sAAD2bAAA+WwAAP9sAAAEbQAAyG0AAM9tAADQbQAA120AAONtAADpbQAAEW8AABhv AAA0bwAAOG8AALZvAAC8bwAA528AAOxvAAD4bwAAA3AAAJFwAACYcAAAqnAAAK1wAAC7cAAAxXAA ALBxAAC5cQAAw3EAAM5xAABVcgAAW3IAAKhzAACvcwAAt3cAAMV3AABiegAAanoAAIR6AACLegAA 0noAAOB6AAARewAAF3sAAEp7AABQewAAhXwAAIl8AACOfAAAlnwAAJt8AAChfAAAuXwAAMN8AADQ fAAA1nwAAIuGAADbhwAABwAEAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAGwAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAHAAAAAAAGAQAADAEAAA4BAACBAQAA eAIAAH8CAADlAwAA5wMAAC4EAAAyBAAAdwQAAHwEAADCBAAAxAQAAEEFAABFBQAATQUAAFEFAADK BQAAzAUAAA8GAAAVBgAAVwYAAFwGAABADAAAQwwAAIQMAACNDAAAvw0AAMkNAAAJDgAACw4AAN0P AADfDwAAIRIAAE0SAACzEgAAthIAAP0SAAACEwAASBMAAE8TAACTEwAAmhMAAOcTAAAcFAAALBQA ADEUAABvFAAAdhQAAMYUAADJFAAADxUAABMVAABSFQAAWhUAAO8XAADzFwAANhgAAD8YAAB9GAAA ghgAAL8YAADIGAAAXBkAAGEZAACRGQAAmBkAAFQaAABcGgAANiUAAD8lAAB4JQAAhCUAADImAAA7 JgAAeiYAAIAmAADEJgAAyCYAABUnAAAfJwAAMCcAADonAABLJwAAUycAAJYnAACdJwAAzScAANcn AACiKAAAtigAAOkoAADxKAAALykAADYpAAD7KQAAAioAAEMqAABFKgAAhyoAAI4qAACrKwAAtCsA APIrAAD3KwAAMywAAD0sAABrLAAAcywAALQsAAC6LAAA/iwAAActAABILQAASy0AAJAtAACSLQAA 2i0AAOItAAD9LQAABS4AAEguAABKLgAAkS4AAJUuAADaLgAA3y4AACUvAAAnLwAAaC8AAHIvAACw LwAAtC8AAOkvAADzLwAANDAAAD0wAAB1MAAAgDAAALkwAADAMAAA2zAAAOUwAAAnMQAAKTEAAGwx AAByMQAAtDEAALkxAACqMgAArzIAAPEyAAD0MgAAfTMAAIEzAADEMwAAzTMAAAU0AAAONAAAiTQA AI40AADTNAAA3DQAAPM1AAD8NQAAdjYAAHw2AADANgAAxzYAAHY3AAB5NwAAvjcAAMI3AABGOAAA TjgAAI04AACYOAAA7TgAAPQ4AAA0OQAARjkAAAE6AAAHOgAAjToAAJU6AADUOgAA3DoAADY7AAA5 OwAAdjsAAIE7AAC/OwAAwzsAAAc8AAAKPAAAUDwAAFM8AADsPAAA8zwAAB0+AAAhPgAAZD4AAGc+ AACrPgAAtz4AADo/AAA8PwAAUT8AAGM/AACCPwAAhT8AAMo/AADUPwAAEEAAABVAAACHQAAAj0AA ABVBAAAcQQAAWUEAAGBBAAChQQAAp0EAAOhBAADrQQAATUIAAFRCAACSQgAAm0IAAKdDAACrQwAA z0UAANJFAAATRgAAHEYAAFFHAABbRwAAm0cAAJ1HAAANSgAAFEoAAFRKAABXSgAAnEoAAJ9KAADh SgAA60oAAMhLAADKSwAAD0wAABlMAACpTAAAs0wAAO1MAADzTAAAeU0AAIBNAAAeTgAAJU4AALBO AAC0TgAA904AAPxOAAA9TwAAQ08AAIVPAACJTwAAzU8AANZPAAAWUAAAGFAAAFhQAABhUAAAn1AA AKJQAADkUAAA6VAAAC1RAABMUQAAmVEAAJxRAABBUgAARFIAAMpSAADRUgAAgVMAAIdTAAAOVAAA F1QAAFhUAABdVAAAiFUAAItVAADOVQAA1lUAABNWAAAaVgAAa1YAAHVWAACxVgAAyFYAAD9XAABI VwAAh1cAAIxXAADRVwAA01cAAGFYAABlWAAAq1gAAK1YAADtWAAA9lgAAHZZAAB5WQAA7lkAAPFZ AACuWgAAr1oAAPhaAAAAWwAAa1sAAHZbAAB7WwAAglsAAMVbAADIWwAADVwAAB1cAAD5XAAA/FwA ADNeAAA1XgAAWF8AAFtfAACiXwAApF8AAORfAADsXwAAkWAAAJhgAABMYQAAT2EAAFRhAABYYQAA w2EAAMxhAAANYgAAEWIAAFdiAABYYgAA8WIAAARjAAAyYwAAO2MAAHJjAAB+YwAAvGMAAL5jAABD ZAAASGQAAKFkAACoZAAA6mQAAO5kAAAyZQAANGUAAKNlAACrZQAA42UAAO1lAAAqZgAALmYAALBn AADTZwAA+WcAAANoAADwaAAA92gAADRpAAA6aQAAfmkAAINpAADHaQAAymkAABBqAAARagAAWmoA AF1qAAC7agAAyWoAAPJtAAD7bQAAVHMAAFhzAABvcwAAd3MAAMtzAADOcwAAa3QAAHB0AADodAAA 83QAAEd4AABXeAAAGnkAACp5AABkeQAAZ3kAANJ6AADiegAA5X0AAOx9AAAtfgAAMX4AAHR+AAB5 fgAAu34AAL9+AAAFfwAAB38AAEp/AABPfwAArn8AALh/AADzfwAA+n8AAD2AAABBgAAAeoAAAIeA AAAqgQAANIEAAG+BAAB1gQAAtoEAALqBAADRgwAAE4QAAD2EAABAhAAARIUAAE2FAACKhQAAkIUA AP6FAAAPhgAAi4YAANuHAAAHADMABwAEAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcABwAAAAAAJwEAADcBAACLhgAA24cAAAcABAAHAAcAAAAAANuHAAA8AAAACAAAAAyREAAAAAEA AAAEAAAAAAACAAMAbSExB7bWoL8PABAAEQASAP8P/w//D/8P/w8AAChA9RS6w44c/w//D/8P/w// D/8P/w//D/8PAAA0dMlmBK1Gkf8P/w//D/8P/w//D/8P/w//DxAAAQAAAAMABwAAAAAAAAAAAQAA AAAAAAAAABAAAA+EAAARhAAAXoQAAGCEAAAHAEEAbgBuAGUAeAAgAAAAAQAAAAAAAQMAAAAAAAAA AAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAFoAQZehAAAYIQAAAMAAAAuAAEAAQAAAAAAAQMFAAAA AAAAAAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAHQAgZehAAAYIQAAAUAAAAuAAEALgACAAEAAAAA AAEDBQcAAAAAAAAAAAAAAAAAAAAYAAAPhAAAEYQAABXGBQAB0AIGXoQAAGCEAAAHAAAALgABAC4A AgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAEAAAZehAAAYIQA AAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAAABgAAA+EAAARhAAA FcYFAAEAAAZehAAAYIQAAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAA AAAAAAAAAAAYAAAPhAAAEYQAABXGBQABAAAGXoQAAGCEAAANAAAALgABAC4AAgAuAAMALgAEAC4A BQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAEAAAZehAAAYIQA AA8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAA ABgAAA+EAAARhAAAFcYFAAEAAAZehAAAYIQAABEAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAu AAcALgAIAAQAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCE YPpvKAABAAAAAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAF YIRg+m8oAAMAAAAuAAEAAwAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGg BQZehKAFYIRg+m8oAAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAMYAAAPhKAF EYRg+hXGBQABoAUGXoSgBWCEYPpvKAAHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAA AAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAAkAAAAuAAEALgACAC4AAwAuAAQA AQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAAsA AAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMYAAAPhKAFEYRg +hXGBQABoAUGXoSgBWCEYPpvKAANAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMF BwkLDQ8AAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAA8AAAAuAAEALgAC AC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+ECAcRhPj4 FcYFAAEIBwZehAgHYIT4+G8oABEAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEA AAAXEAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgUAUUoF AF5KBQBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhKAFEYSY /hXGBQABoAUGXoSgBWCEmP5PSgUAUUoFAF5KBQBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAA AAAAAABoAQAAAAAAABUYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAIdoAAAA AIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EQAsRhJj+FcYFAAFACwZehEAL YISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAA D4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBeSgUAbygAh2gAAAAAiEgAAAEAbwABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oGAFFKBgBv KACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhLATEYSY/hXGBQAB sBMGXoSwE2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAAGRgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAXkoFAG8oAIdoAAAAAIhIAAAB AG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9K BgBRSgYAbygAh2gAAAAAiEgAAAEAp/AGAAAAbSExBwAAAAAAAAAAAAAAAG0hMQcAAAAAAAAAAAAA AABtITEHAAAAAAAAAAAAAAAAbSExBwAAAAAAAAAAAAAAAChA9RQAAAAAAAAAAAAAAAA0dMlmAAAA AAAAAAAAAAAA//////////////////////////////////8DAAAAAAAAAAAA//8DAAAAAAAAABIA AwAJBAMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEJwAAAAQAAAAIAAAA5QAAAAAAAAAm AAAAxSQLAOZbIAAEcCIAMWUoAKxbKgD5Zy4AjlA/AMVXRwBdZk0AYyJQAJFwVQDvN1cAl3VfADws YwA3GnIA3EtyANJgegDTcoAAB3CBAA5IkACTCZEAmjaRADZekQDFK5UAKHSjAEI+pwCpEqkAzwCu AH1OsQDdE7kA7H3PAGki0AClXdYA+HDcAEoa3wAWd+MAN23qAKlY7wC0KfgA/0ABgAEAKwEAACsB AACAv8YBAQABACsBAAAAAAAAKwEAAAAAAAACEAAAAAAAAADahwAAwAAAEABAAAD//wIAAAAHAFUA bgBrAG4AbwB3AG4ADQBUAHIAZQB2AG8AcgAgAFcAaQBsAHMAbwBuAP//AgAIAAAAAAAAAAAAAAAA AAAAAAAAAAEA//8CAAAAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAcAAABHFpABAAACAgYD BQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBh AG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwA AAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAOwaQ AYYHAgEGAAMBAQEBAQMAAAAAAA4IEAAAAAAAAAABAAQAAAAAAFMAaQBtAFMAdQBuAAAAi1tTTwAA NSaQAQAAAgsGBAMFBAQCBId6ACEAAACACAAAAAAAAAD/AQEAAAAAAFQAYQBoAG8AbQBhAAAAPzWQ AQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUA dwAAADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBu AGcAcwAAACIABABxiIwYAPDQAgAAaAEAAAAAu3qoRjKEqGYAAAAABQBOAgAAFBQAAHdyAAABAEQA AAAEAAMQ9AAAABQUAAB3cgAAAQBEAAAA9AAAAAAAAAARJADwEAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAIB6AFtAC0AIGBMjQAAAAAAAAAAAAAAAAAAEeGAABHhgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAQz g1EA8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAAAAAKfD/DwEAAT8AAOQEAABx AwAA////f////38AAAAA////f////3////9/aSLQAP//EgAAAAAAAAAJAFMAZQBjAHQAaQBvAG4A IAAzAAAAAAAAAA0AVAByAGUAdgBvAHIAIABXAGkAbABzAG8AbgANAFQAcgBlAHYAbwByACAAVwBp AGwAcwBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAABgAAAAMAAAAAAAwAAQAMAAIADAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAA AAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAgAEAABEAAAABAAAAkAAAAAIA AACYAAAAAwAAAKwAAAAEAAAAuAAAAAUAAADQAAAABgAAANwAAAAHAAAA6AAAAAgAAAD8AAAACQAA ABQBAAASAAAAIAEAAAoAAAA8AQAADAAAAEgBAAANAAAAVAEAAA4AAABgAQAADwAAAGgBAAAQAAAA cAEAABMAAAB4AQAAAgAAAOQEAAAeAAAADAAAAFNlY3Rpb24gMwAAAB4AAAAEAAAAAAAAAB4AAAAQ AAAAVHJldm9yIFdpbHNvbgAAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAMAAAATm9ybWFs LmRvdAAAHgAAABAAAABUcmV2b3IgV2lsc29uAAAAHgAAAAQAAAA1AAAAHgAAABQAAABNaWNyb3Nv ZnQgV29yZCAxMC4wAEAAAAAAVAtsUgAAAEAAAAAAii1uUcDGAUAAAAAARFShS8HGAQMAAAABAAAA AwAAABQUAAADAAAAd3IAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAA AAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAPwAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUA AACIAAAABgAAAJAAAAARAAAAmAAAABcAAACgAAAACwAAAKgAAAAQAAAAsAAAABMAAAC4AAAAFgAA AMAAAAANAAAAyAAAAAwAAADeAAAAAgAAAOQEAAAeAAAAEAAAAE5vcnRlbCBOZXR3b3JrcwADAAAA 9AAAAAMAAABEAAAAAwAAAEeGAAADAAAAlBoKAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAA AAAAHhAAAAEAAAAKAAAAU2VjdGlvbiAzAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAH AAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAA ACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAA MgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABA AAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4A AABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAA AF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAA awAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAA/v///3gAAAB5 AAAAegAAAHsAAAB8AAAAfQAAAH4AAAD+////gAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcA AACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAA AJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAA pAAAAKUAAACmAAAApwAAAKgAAACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACvAAAAsAAAALEAAACy AAAAswAAALQAAAC1AAAAtgAAALcAAAC4AAAAuQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAA AADBAAAAwgAAAMMAAADEAAAAxQAAAMYAAADHAAAAyAAAAMkAAADKAAAAywAAAMwAAADNAAAAzgAA AM8AAADQAAAA0QAAANIAAADTAAAA1AAAANUAAADWAAAA1wAAANgAAADZAAAA2gAAANsAAADcAAAA 3QAAAN4AAADfAAAA4AAAAOEAAADiAAAA4wAAAOQAAADlAAAA5gAAAOcAAADoAAAA6QAAAOoAAADr AAAA/v///+0AAADuAAAA7wAAAPAAAADxAAAA8gAAAPMAAAD+////9QAAAPYAAAD3AAAA+AAAAPkA AAD6AAAA+wAAAP7////9/////f////8AAAD+////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIA AAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAQC2vvUvBxgECAQAAgAAAAAAAAABEAGEAdABhAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAEAAAAAAA ADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAfwAAAK/YAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAIuwAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOwAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUA bgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAA AP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9AAAAAAQAAAAAAAA AQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP3////+/////v////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////AQAAAP7///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAA AE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQu OAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADA AAAAAAAARgAAAAAAAAAAAAAAAPCM02BMwcYBCQEAAIADAAAAAAAARABhAHQAYQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAABAAAAAAAAAxAFQA YQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH8A AACv2AAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACLsAAAAAAAA////////////////CAEAAP3////9/////v////7////+ ////BwEAAP////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////+BAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkA AACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAA AJgAAACZAAAAmgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAClAAAA pgAAAKcAAACoAAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAAALMAAAC0 AAAAtQAAALYAAAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9AAAAvgAAAL8AAADAAAAAwQAAAMIA AADDAAAAxAAAAMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4AAADPAAAA0AAA ANEAAADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA3AAAAN0AAADeAAAA 3wAAAOAAAADhAAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADqAAAA6wAAAP7////t AAAA7gAAAO8AAADwAAAA8QAAAPIAAADzAAAA/v////////////////////////////////////// /////////f///////////////////wEAAAD+////AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AAoAAAALAAAADAAAAA0AAAD+//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////BAAAAAIAAAAUAAAAXwBBAGQASABvAGMAUgBlAHYAaQBlAHcA QwB5AGMAbABlAEkARAAAAAMAAAAOAAAAXwBFAG0AYQBpAGwAUwB1AGIAagBlAGMAdAAAAAQAAAAN AAAAXwBBAHUAdABoAG8AcgBFAG0AYQBpAGwAAAAAAAUAAAAYAAAAXwBBAHUAdABoAG8AcgBFAG0A YQBpAGwARABpAHMAcABsAGEAeQBOAGEAbQBlAAAAAgAAALAEAAATAAAACQgAAAMAAACRlpj0HwAA ABgAAABQAG8AbABsAGkAbgBnACAAZgBvAHIAIABuAGUAdwAgAFcARwAgAEkALQBEAHMAAAAfAAAA EwAAAFcASQBMAFMATwBOAFQAQABuAG8AcgB0AGUAbAAuAGMAbwBtAAAAAAAfAAAAHAAAAFcAaQBs AHMAbwBuACwAIABUAHIAZQB2AG8AcgAgACgASQBSAEUAMAA3ADoAUQA4ADQAMAApAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBu AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAOwAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBt AG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAPQCAAAAAAAAAQBDAG8AbQBw AE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIA AgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9z b2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAA AgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rkABAAD8AAAADAAAAAEAAABo AAAADwAAAHAAAAAFAAAAiAAAAAYAAACQAAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAA AAATAAAAuAAAABYAAADAAAAADQAAAMgAAAAMAAAA3gAAAAIAAADkBAAAHgAAABAAAABOb3J0ZWwg TmV0d29ya3MAAwAAAPQAAAADAAAARAAAAAMAAABHhgAAAwAAAJQaCgALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAALAAAAAAAAAB4QAAABAAAACgAAAFNlY3Rpb24gMwAMEAAAAgAAAB4AAAAGAAAAVGl0 bGUAAwAAAAEAAAC0AQAABwAAAAAAAABAAAAAAQAAAPQAAAAAAACA/AAAAAIAAAAEAQAAAwAAAAwB AAAEAAAARAEAAAUAAAB0AQAA ------_=_NextPart_001_01C6C14C.6374150F-- From owner-ccamp@ops.ietf.org Wed Aug 16 14:08:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDPp2-0007Mc-1i for ccamp-archive@ietf.org; Wed, 16 Aug 2006 14:08:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDPov-0007Tv-Gi for ccamp-archive@ietf.org; Wed, 16 Aug 2006 14:08:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDPiZ-00070b-G2 for ccamp-data@psg.com; Wed, 16 Aug 2006 18:02:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,FORGED_RCVD_HELO,SPF_PASS autolearn=no version=3.1.1 Received: from [213.46.243.15] (helo=amsfep14-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDPiX-00070B-FL for ccamp@ops.ietf.org; Wed, 16 Aug 2006 18:02:14 +0000 Received: from [192.168.17.5] (really [24.132.27.149]) by amsfep14-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20060816180156.KUKN13274.amsfep14-int.chello.nl@[192.168.17.5]>; Wed, 16 Aug 2006 20:01:56 +0200 Message-ID: <44E35D93.8000204@chello.nl> Date: Wed, 16 Aug 2006 20:01:55 +0200 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: Trevor Wilson Subject: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re: Polling for new WG I-Ds References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Hello Trevor, You wrote: > I have read the ID-draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > I have the following questions and comments: See my comments in-line [hvh] > Section 3.2: > > Is Fixed synonymous with no-LCAS ? [hvh] No, not necessarily, in this case the client signal will not change its bandwidth. LCAS can be used for resilience. > If so, then in the Fixed co-routed scenario, there can be no graceful > degradation in the event of a failure. [hvh] a mis-connection is also a failure > This is more applicable to the dynamic, diversely-routed scenario (and > in fact could apply to the dynamic co-routed scenario, although this is > far more unlikely). [hvh] see my previous comment > Regarding 'graceful degradation in the event of a failure': surely this > is a misnomer ? Graceful degradation can only be achieved if the VCG > capacity is hitlessly decreased. A full blown failure on any VCG member > will cause a hit to the traffic, albeit temporary. [hvh] agree > A hitless decrease > can in certain circumstances, be achieved by using a signal degrade to > trigger the LCAS remove operation. [hvh] how do you provision/achieve a signal degrade? > Suggested text for 3.2 (partial) > > Fixed, diversely routed: A fixed bandwidth VCG, transported over > at least two diversely routed subsets of member signals. In this > case, the subsets are link-disjoint over at least one link of the > route. The intent here is more efficient use of network resources > > (no unique route has the required bandwidth), (note > that differential delay may be a limiting factor). [hvh] I don't agree, LCAS can provide resilience, I agree that the degradation is not graceful > Dynamic, diversely routed: A dynamic VCAT group, transported over > at least two diversely routed subsets of member signals. The > intent here is dynamic resizing and resilience (but differential > delay may be a limiting factor). Graceful degradation is possible > in the event of a TSD (Trail Signal Degrade) on a VCG member(s) [hvh] graceful degradation is a feature of LCAS, it is not necessary to mention it here explicitly > Section 4 > > Typo on second line of last paragraph: VC4-7v should be VC-4-7v. [hvh] OK > Section 4.1.3 > > G.7042 section 6.4 addresses VCG capacity decrease (temporary removal > due to member failure) and section 6.5 addresses VCG capacity decrease > (permanent removal). Each of these has distinct meanings and I think > that this ID should make that distinction also, or at least be more > pedantic in the use of 'removal'. > > Perhaps (as far as GMPLS is concerned) there is only the need to address > the VCG capacity decrease (permanent removal), since the 'temporary > removal' is an autonomous action performed by the LCAS protocol and does > not require any management intervention. [hvh] the temporary removal description was in previous versions of this draft, because (as you mention) this draft concerns GMPLS it was removed to avoid confusion. > Suggested text for 4.1.3: - > > 4.1.3. Decreasing VCG capacity > > VCG capacity can be decreased in two ways > o Temporary removal of a VCG member(s) due to failure > o Planned permanent removal of a VCG member(s) which requires > management intervention > > 4.1.3.1 Temporary Removal of a VCG member > > This is an autonomous action performed by the LCAS protocol whenever a > failure occurs on an active VCG member(s). The relevant VCG member will > then be in the DNU state. > > There is no management intervention required to perform this operation. > > This member can then be permanently removed from the VCG. (4.1.3.2) > > 4.1.3.2 Planned permanent removal of a VCG member > > The procedure to remove a component signal is similar to that used to > > add components as described in Section 4.1.2. The LCAS in-band > signaling step is taken first to take the component out of the group > as the result of a remove command from the LCAS controller; the > permanently removed member will then be in the IDLE state. [hvh] mentioning only one of the LCAS states will create confusion and is irrelevant to GMPLS > LCAS signaling is described in [ITU-T-G.7042] > > In this case, the NVC value is decremented by 1 and the timeslot > identifier for the dropped component is removed from the ordered list > > in the Generalized Label. > > This permanent removal procedure is only applicable to > LCAS-capable-VCAT. [hvh] the paragraph replaced by the latter sentence contains more relevant detail and should be kept intact. > Best regards, > > Trevor > > Trevor Wilson > Nortel Networks Kind regards, Huub van Helvoort. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Wed Aug 16 18:38:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDU1w-0003rp-7L for ccamp-archive@ietf.org; Wed, 16 Aug 2006 18:38:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDU1t-0002YW-SV for ccamp-archive@ietf.org; Wed, 16 Aug 2006 18:38:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDTwG-0002Vd-I9 for ccamp-data@psg.com; Wed, 16 Aug 2006 22:32:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDTwF-0002VM-7F; Wed, 16 Aug 2006 22:32:39 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k7GMWao5022679; Thu, 17 Aug 2006 00:32:36 +0200 In-Reply-To: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> To: "Adrian Farrel" Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 17 Aug 2006 00:32:35 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/17/2006 00:32:35, Serialize complete at 08/17/2006 00:32:35 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 adrian - see in-line Adrian Farrel wrote: > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. - ok - > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt - guess it is v03.txt ? - > has been updated since the version discussed in Montreal. i am ok in investigating the MP->CP but i have two concerns that imho should deserve more specific attention to maintain consistency wrt to CP->MP section 2.2: if control is lost for an LSP (during CP failure) how can it be possible transfer that LSP from the CP -> MP ? section 4.4: why the document assumes that both MUST be supported ? in part. concerning the CP->MP if one does implement current GMPLS signaling restart/recovery why shall this be mandated ? in brief, the document shall take into account existing mechanisms and prevent overlaps (with existing GMPLS mechanisms) hence, it is strongly suggested to identify conditions when such CP->MP is required (and not an alternative to existing CP mechanisms) b/f progressing that part > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. informational imho - in its current version - not sure to understand why the PathErr/Notify can be processed by the head-end only (what about segment recovery and stitching case) - why only MBB is possible upon reception (pls use E2E recovery/Segment recovery capabilities as you address GMPLS networks) - compared to path-reopt, error description is identical for the TE link case which leads to the following point - if errors code/value are the same how to distinguish them (assuming that the query procedure described in path-reopt is used during the setup of that LSP) ? - comment is more for the path-reopt draft than yours but since there is an overlap ... it must be addressed in a way or another (note that when fully head-end driven operations look similar but there is a major difference role of timing and severity of the error code/value) - in case shutdown of a protected component link (of a bundle) is initiated why can't link protection be used ? > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian From aleucheyne@flexlease.com Thu Aug 17 08:11:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDgiq-0007jj-4s for ccamp-archive@megatron.ietf.org; Thu, 17 Aug 2006 08:11:40 -0400 Received: from [85.96.214.76] (helo=flexlease.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDgio-0004e1-HP for ccamp-archive@megatron.ietf.org; Thu, 17 Aug 2006 08:11:40 -0400 Message-ID: <000001c6c1f6$416ee4e0$96b6a8c0@nnc60> Reply-To: "Moirrey Chittenden" From: "Moirrey Chittenden" To: ccamp-archive@megatron.ietf.org Subject: Re: test uo Date: Thu, 17 Aug 2006 05:11:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C1BB.95127DE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6C1BB.95127DE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 It is common to have some problems with erecxtion,=20 Try VIfAGRA and forget about it http://www.xuterasedukin.com =20 =20 =20 Then when I look back I see that the two metal things have vanished. So I am beginning to feel like I am going around the mental bend. Therefore I would appreciate it if you would kindly, and quickly, tell ------=_NextPart_000_0001_01C6C1BB.95127DE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
It is common to have some problems with erecxtion,
Try VIfAGRA = and forget about it http://www.xuterasedukin.com

 

 

 

Then when I look back I = see that the two metal things have vanished.
So I am beginning to feel like I am going around the mental = bend.
Therefore I would appreciate it if you would kindly, and quickly, = tell

------=_NextPart_000_0001_01C6C1BB.95127DE0-- From owner-ccamp@ops.ietf.org Thu Aug 17 11:36:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDjuu-0001Jg-9Y for ccamp-archive@ietf.org; Thu, 17 Aug 2006 11:36:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDjup-0005Bt-OS for ccamp-archive@ietf.org; Thu, 17 Aug 2006 11:36:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDjp4-0000Ms-Ke for ccamp-data@psg.com; Thu, 17 Aug 2006 15:30:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDjp2-0000MV-SE for ccamp@ops.ietf.org; Thu, 17 Aug 2006 15:30:17 +0000 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7HFUBG26944; Thu, 17 Aug 2006 11:30:11 -0400 (EDT) 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 Subject: RE: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re: Polling for new WG I-Ds Date: Thu, 17 Aug 2006 16:30:09 +0100 Message-ID: In-Reply-To: <44E35D93.8000204@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re: Polling for new WG I-Ds Thread-Index: AcbBXhcjAtAmZXFgT4GJ+bcFEHDjmQAhJz2Q From: "Trevor Wilson" To: "Huub van Helvoort" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Hi Huub, Thanks for the clarifications, see in-line for responses. Trevor Wilson Nortel Networks Belfast Lab Tel: +44 2890 363701 ESN 751 3701 >This is the Way. This is Nortel.=20 > Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 Sent: 16 August 2006 19:02 To: ccamp@ops.ietf.org Cc: Wilson, Trevor (IRE07:Q840) Subject: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re: Polling for new WG I-Ds Hello Trevor, You wrote: > I have read the ID-draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > I have the following questions and comments: See my comments in-line [hvh] > Section 3.2: >=20 > Is Fixed synonymous with no-LCAS ? [hvh] No, not necessarily, in this case the client signal will not change its bandwidth. LCAS can be used for resilience. [tw] Accepted that this is possible. However I still think the reader could be forgiven for assuming that Fixed =3D non-LCAS-capable and = Dynamic =3D LCAS-capable; so perhaps this needs to be clarified in the text. > If so, then in the Fixed co-routed scenario, there can be no graceful=20 > degradation in the event of a failure. [tw] I have a typo here is should say Fixed diversely-routed instead of Fixed co-routed [hvh] a mis-connection is also a failure [tw] but a mis-connection won't cause a hit, since this will occur at set-up, but I agree that if LCAS is present then graceful degradation can be achieved in the event of a signal degrade. > This is more applicable to the dynamic, diversely-routed scenario (and > in fact could apply to the dynamic co-routed scenario, although this=20 > is far more unlikely). [hvh] see my previous comment > Regarding 'graceful degradation in the event of a failure': surely=20 > this is a misnomer ? Graceful degradation can only be achieved if the=20 > VCG capacity is hitlessly decreased. A full blown failure on any VCG=20 > member will cause a hit to the traffic, albeit temporary. [hvh] agree > A hitless decrease > can in certain circumstances, be achieved by using a signal degrade to > trigger the LCAS remove operation. [hvh] how do you provision/achieve a signal degrade? [tw] G.806 clause 10.1.1.2 shows "P-Xv_AI_TSD =3D P_AI[1.. XMR]_TSD" and "P-Xv/P-X-L_A_Sk_MI_TSDEnable" as inputs to the "LCAS-capable virtual concatenated path adaptation sink function P-Xv/P-X-L_A_Sk", and the text says "The MI_TSDEnable input controls whether the sink function uses AI_TSD[i] indications as contributors for signalling defective members back to the LCAS source function (MI_TSDEnable =3D true) or whether it ignores AI_TSD[i] indications altogether (MI_TSDEnable =3D false)." > Suggested text for 3.2 (partial) >=20 > Fixed, diversely routed: A fixed bandwidth VCG, transported over=20 > at least two diversely routed subsets of member signals. In this=20 > case, the subsets are link-disjoint over at least one link of the=20 > route. The intent here is more efficient use of network=20 > resources >=20 > (no unique route has the required bandwidth), (note=20 > that differential delay may be a limiting factor). [hvh] I don't agree, LCAS can provide resilience, I agree that the degradation is not graceful [tw] We are converging here (as usual); see my previous comment/suggestion > Dynamic, diversely routed: A dynamic VCAT group, transported over=20 > at least two diversely routed subsets of member signals. The=20 > intent here is dynamic resizing and resilience (but differential > delay may be a limiting factor). Graceful degradation is=20 > possible in the event of a TSD (Trail Signal Degrade) on a VCG member(s) [hvh] graceful degradation is a feature of LCAS, it is not necessary to mention it here explicitly [tw] It's equally (if not more) relevant to mention it here than in the fixed scenario. > Section 4 >=20 > Typo on second line of last paragraph: VC4-7v should be VC-4-7v. [hvh] OK > Section 4.1.3 >=20 > G.7042 section 6.4 addresses VCG capacity decrease (temporary removal=20 > due to member failure) and section 6.5 addresses VCG capacity decrease > (permanent removal). Each of these has distinct meanings and I think=20 > that this ID should make that distinction also, or at least be more=20 > pedantic in the use of 'removal'. >=20 > Perhaps (as far as GMPLS is concerned) there is only the need to=20 > address the VCG capacity decrease (permanent removal), since the=20 > 'temporary removal' is an autonomous action performed by the LCAS=20 > protocol and does not require any management intervention. [hvh] the temporary removal description was in previous versions of this draft, because (as you mention) this draft concerns GMPLS it was removed to avoid confusion. [tw] I'm all for avoiding confusion -- see next comment. > Suggested text for 4.1.3: - >=20 > 4.1.3. Decreasing VCG capacity >=20 > VCG capacity can be decreased in two ways > o Temporary removal of a VCG member(s) due to failure > o Planned permanent removal of a VCG member(s) which requires > management intervention >=20 > 4.1.3.1 Temporary Removal of a VCG member >=20 > This is an autonomous action performed by the LCAS protocol whenever a > failure occurs on an active VCG member(s). The relevant VCG member=20 > will then be in the DNU state. >=20 > There is no management intervention required to perform this=20 > operation. >=20 > This member can then be permanently removed from the VCG. (4.1.3.2) >=20 > 4.1.3.2 Planned permanent removal of a VCG member >=20 > The procedure to remove a component signal is similar to that used=20 > to >=20 > add components as described in Section 4.1.2. The LCAS in-band=20 > signaling step is taken first to take the component out of the=20 > group as the result of a remove command from the LCAS controller; the=20 > permanently removed member will then be in the IDLE state. [hvh] mentioning only one of the LCAS states will create confusion and is irrelevant to GMPLS [tw] OK so take out the mention of the DNU state (4.1.3.1) and IDLE (4.1.3.2). In fact perhaps 4.1.3.1 could be combined with 4.1.3.2 as follows: - 4.1.3 Permanent removal of a VCG member A VCG member can be permanently removed from the VCG either following a temporary removal (due to a failure) or as the result of a management command. The LCAS in-band signaling step is taken first to take the component out of the group, either the temporary removal or as the result of a management command. > LCAS signaling is described in [ITU-T-G.7042] >=20 > In this case, the NVC value is decremented by 1 and the timeslot=20 > identifier for the dropped component is removed from the ordered=20 > list >=20 > in the Generalized Label. >=20 > This permanent removal procedure is only applicable to=20 > LCAS-capable-VCAT. [hvh] the paragraph replaced by the latter sentence contains more relevant detail and should be kept intact. [tw] The introduction to section 4 states that it (section 4) is "in support of the LCAS procedure". So I don't quite see how the sentence that I deleted is relevant to LCAS since it deals with the "VCAT only" interface. =09 > Best regards, >=20 > Trevor >=20 > Trevor Wilson > Nortel Networks Kind regards, Huub van Helvoort. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://members.chello.nl/hhelvoort/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Thu Aug 17 14:47:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDmtl-0006cE-VJ for ccamp-archive@ietf.org; Thu, 17 Aug 2006 14:47:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDmth-0004QD-4z for ccamp-archive@ietf.org; Thu, 17 Aug 2006 14:47:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDmfW-000J0l-4f for ccamp-data@psg.com; Thu, 17 Aug 2006 18:32:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [216.82.245.131] (helo=mail146.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GDmfV-000J0W-4i for ccamp@ops.ietf.org; Thu, 17 Aug 2006 18:32:37 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-6.tower-146.messagelabs.com!1155839507!1524284!20 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 27471 invoked from network); 17 Aug 2006 18:32:35 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-6.tower-146.messagelabs.com with SMTP; 17 Aug 2006 18:32:35 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 44E128F50007A9A6; Thu, 17 Aug 2006 14:32:35 -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 Subject: RE: Updated version of draft-ietf-ccamp-gmpls-rsvp-te-call Date: Thu, 17 Aug 2006 13:32:34 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0C9C7165@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <056a01c6be20$21380c30$9b849ed9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated version of draft-ietf-ccamp-gmpls-rsvp-te-call Thread-Index: Aca+IFg/Talj/sjqTfasdTWKvum7QAECZ0BA From: "Brungard, Deborah A, ALABS" To: "Bill Fenner" , "Ross Callon" Cc: , "Adrian Farrel" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Bill and Ross, This draft has been through CCAMP WG last call and has been updated to my satisfaction. All changes were in response to LC comments and my nits. http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call- 01.txt Please take it on its next step to being an RFC. Thanks everyone, Deborah From julyumakel@impact-az.com Thu Aug 17 17:52:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDpnP-0003IS-Pa for ccamp-archive@megatron.ietf.org; Thu, 17 Aug 2006 17:52:59 -0400 Received: from [88.122.80.194] (helo=impact-az.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDpnN-0007b3-Q1 for ccamp-archive@megatron.ietf.org; Thu, 17 Aug 2006 17:52:59 -0400 Message-ID: <000001c6c247$743cb540$28b9a8c0@rel97> Reply-To: "Jaropelk Havener" From: "Jaropelk Havener" To: ccamp-archive@megatron.ietf.org Subject: Re: news iuge Date: Thu, 17 Aug 2006 14:52:37 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C20C.C7DDDD40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.4 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6C20C.C7DDDD40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Very good news! =20 VIAGfRA VAfLIUM CIfALIS and 200 other=20 directly from the manufactuerer http://www.okhituirunmde.com =20 =20 =20 The blade slashed out to slit my throat. CHAPTER 9 I jumped back to avoid the slash, stumbled over a mans legs, fell on ------=_NextPart_000_0001_01C6C20C.C7DDDD40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
Very good news!
 
VIAGfRA VAfLIUM CIfALIS and 200 other
directly from the = manufactuerer http://www.okhituirunmde.com

 

 

 

The blade slashed out to = slit my throat.
CHAPTER 9
I jumped back to avoid the slash, stumbled over a mans legs, fell = on

------=_NextPart_000_0001_01C6C20C.C7DDDD40-- From Ysaground@abs-structural.com Fri Aug 18 01:14:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDwgb-0002KY-MU; Fri, 18 Aug 2006 01:14:25 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDv7W-00085V-9T; Thu, 17 Aug 2006 23:34:06 -0400 Received: from [203.210.34.226] (helo=DSM) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GDv0E-0006re-0s; Thu, 17 Aug 2006 23:26:39 -0400 Message-ID: <7452C2D76753BAC@amige.com> To: bridge-mib-bounces@ietf.org From: "Kay Madison" Subject: Re: in cancel an portmanteau largo Date: Thu, 17 Aug 2006 20:29:31 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00CE_01C5071A.34B66EC0" X-Spam-Score: 4.5 (++++) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 This is a multi-part message in MIME format. ------=_NextPart_000_00CE_01C5071A.34B66EC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A0_01C5033D.96C32EA0" ------=_NextPart_001_00A0_01C5033D.96C32EA0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7Bit Exactly so, replied Traddles, all to be earned. Of course we to betray the confidence of Agnes, but for my uncertainty how to Mr. Littimer, after a moments reflection, that there is anything unchanged drawing-room. The books that Agnes and I had read ------=_NextPart_001_00A0_01C5033D.96C32EA0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7Bit
She had put her hand entreatingly on his arm, to stop him; and was
lonely waste, in my remembrance, to this hour. It is always night It is humble, said Mr. Micawber, - to quote a favourite
and carried into town on hucksters heads, intent on this first One day, when I went to the Commons as usual, I found Mr. Spenlow
sure. That would prevent it? Why, of course it would. Exactly. and the steam of boiling water, as Mr. Micawber did that afternoon.
radiance seemed to me to beam when he sat erect in Court among his train. It was, that Dora seemed by one consent to be regarded like
us, to break it down at once with a determined hand. seeing Mrs. Steerforth. As I felt bound to assist him in this, and
I expressed my regret for having innocently touched upon a theme to that; and softly played upon it with his hands, as if he were
be glad to hear from me of what improvement I thought the Commons last, today I find them put out for sale. I have only noticed them
Among the persons who are attracted to me in my rising fame and said, turning his head towards me, but looking at my feet instead
pen through what remains; and shes free when you wish. If she imagine what it was - to have this dread and trouble always on my
falling rain, or hear the wind, but I thought of his solitary it thus: Now employ me, on remunerative terms, and address,
would have been a happy fate to have been struck immortal with Forget-me-nots, and when the jeweller, to whom I took the measure,
where the little packet lay; all that troubles me is, to think Oh, I beg your pardon, Copperfield. said Traddles. She is a
and you understand it. Thats what I find so charming. I thought Mr. Dick would have fallen, insensible. My aunt being
Kings Bench at Westminster, in another cause of HEEP V. With this, we departed; leaving her standing by her elbow-chair, a
I had lost the clear arrangement of time and distance. Thus, if I when she took him; but she never loosed her hold till he was locked
beach and stored in the outhouse - as oars, nets, sails, cordage, earth - fell upon me like unmerited disgrace, in which I forced you
so vividly, that, in the intensity of his earnestness, he presented pulled at it as if she thought so. I hastened to put myself
------=_NextPart_001_00A0_01C5033D.96C32EA0-- ------=_NextPart_000_00CE_01C5071A.34B66EC0 Content-Type: image/gif; name="kinconsiderate" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhpwEiAfcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8AAAAP///wk9tYSgaage dsGnUqqcd7KTRTE3vRIvQ6OaifM/7LEdbPMu40q4lXMv3ZMam3uv6ZtCkns1o2s/mcGzKzS1pws4 ARgOHwAY9erVAzelldPeAP2UqVA3MjUhUyHV6B4AKHUVAZpkjRXW/mpl1tZcHdxVo14RmtagA5S1 hnZDlgb7d4VDuMAKacgSeIBy7X8bLZKCY7tV6ITP2nYPTtO8uLKNLH6KL8vtV4rXBzuNr2hrNXGr MHzC4pq9XibE7tXLZj2MoQl3iETYTG99K2zfyCrFs2IBLW9SPBMVq9g0k2HRi1sEXRS/OMYGzYyM 8LmR8Yk5ygJteiEof2EX+cAnhZJI77Im0hMAmzkZ9oSgn1OaYxZDvfOgP4MSgpFD9CmcwRKZA9Cd 4uv+TRJ6P/lMraY7ayq/UHoyJVUugfZlXhG4rvL26rJB42fEos25yveA8uZpvpPCnqvyKnNwRzh2 R2mU/SkoMMqd/olF7SGiNYlFfbGf+ImiJuWgK/GeKUEhAnU0U0GcGzqk+KCV/JkPo3mc5Bk0U7Gf Nd+CpqwOZa+eUTP7YauFfRX/Jrs+Lv0XErOoah3VUfu35yPvuZWeK27/KxRfBdkcQVmsGbfPCVYv HjXPV7VmkymyxrzUKq0RNZanL3XslWtYFw9zzlslpxPPaX1N26gxFSU2WVdF9/nl0gutzVZg5Q2W 0wr3ust2dfgvI81D9h2F86nX2Kx76o+jGI8FX74S9wVYc3O7mhPTdtEY2LfB2oJYXMndW/yJW69J d1uYZHz/SIiZSEBKl4JC9nPnt5Sk1FUXIYQ2ZYrD6FBvw4pquZZ4xY2+FIvBdJZyOZd0WZd2eZd4 cb3XdORnipD4iypYWoWGfbo2i8goi683Kcszb2IFgCtCYZM3jQd4fnOXgO4UctnEcS3HFWAYUM6I PHubc1RybaAAAP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAApwEiAQAI/wAXCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKhRofnyFUxqMKlTpgueQpXqVCDUo1izat3K8KpVpUvBhh3o1WtUsVzT ql0b9ClBs2cPXi2LNi7bu3jzznRLtq7dsV/f1oWrt7Dhwx2nioVLFSxVwH0RS55MeaLiyJAF/8XM ubLnz58bO/ZL+LJm0KhTh0Zr+jRkuplVy569FfZZqbf52t7Mm7bv38CDCx9OvLjx48iTK1/OvLnz 59CjS59Ovbr169iza9/Ovbv37+DDi/8fT768+fPo06tfz76oAAE837cn+b5+wfryB+YniH//Avv6 +fcffPz1F+CB9wEIoEAE9kcggw8OGKCCDsLn4IQNXgjhggYJaOCGHO6XH34HaSghhAjO95GID7KY YoosRsjhiTBmiGKJLfpn4400nujiiz/SKCCPQ/Yo5I5H8mhkjTd6GKGKGumIZJNP9jiij1aGmCOK RRIppJIjyoiklAUyqaSZCZaJIJkSOonQj/IN2SWUFXXp5pJsWthglmz6OGOaDH6ZJZgZVkkomkX+ qeaLi/opp6FJDmgnpHRONCmgj6pZKJFjfigppYJeOeionz4pJYk1euppo0se+mmHkML/qWirlVqa 45R+wqrphpz2SuacIh44ZZisStponKZuqdCfdxo7KrKAwopqm4bOWStEeSZ75rP6rVkhld6+2aKw rmYLpJiuthoko+aGS2q0mlZp7bUPBWmvvMr+1y247ua6raC8RvpsvqTeiyOjeCprcK/9LtosvRaZ WGqBBkpc7bAYv/uqvhOC6OS0Ex+LLqrfeiyutBSC/OuCxOqKJsQwjzRvTTPHbPNFNceU88082xof qD0HLfTQRBdt9NFIJ6300kw37fTTUEct9dTfFQCU1ZNhTTVIBXTttUJaOxS2S2MP9LXYEZWNNkFq m52Q11q3DfZBcm8NUd0F4W2Q3ibJ/82323dTNHbdbYeN9d9s0203RmpbfTbch5+9gOOQR9414JTH /bXkk0ueuUCQ7+0256FPnjjom8Nt+uVxi35655fDHjvgbKsue+2H04744gg13rrptAM/u9+go465 7sVj/jvxxidvePLOu9488NQHL/zphSsefO7Fcw897xNV/r331ZPPvPnQL4/9+r1vP/771cM/Ot3i l/993p6/fn3ig4NfUePsQ53tnoe72KGPessrHQGZZ78GEhB27uOf9o5HwYUcMHq1k57/0jbB/d1P fg6E3+88qD/y5S2CC9QfBu/nuA6S0ITta+AKu3fCDUoEgBUMYQQxmML0iTCA0uth5//SV7YLWs96 B8xeDoXYwvjZ8IYKfN3j8oc7ARrwhz604g45B0EZbs5srNMiGJuoQiSO0XCzO2MVbzfGLDrxiXTa HRznGDg62vGOeMyjHvfIxz768Y+ADKQgB0nIlgAAIYd0CAAWuUiINFIhjIwkJCUpkUQWciaMnEgk MykQTnbSkxSxJEFEOcqBkHIhpyxIIleJSlNW8pKYdGUoVSnLBVgylQ9JJS5v6UhF+rKTr4QlTEjJ SmDa0pa6LKUyealKT97ykcw85kGi+UhkmvKQ2GwkKI15zVMyU5vZlKYyhekSYnJzlbgUpzqlGc1a FpOXxeRmM6vJynp+8pzTHCcxQfn/TmzSkpzl/Oc3ITlOY1Lyn+yU5zHNmU9xUjKTA11nLR0q0GUa FKEAXQlDI4rIgiY0IRHdJ0MNEk9R2hOfu9RnRWX5ToxmVCXUZClBVapQhLYUmPGc6Uf9uVB3SlSe 7aToRT/6Upls86E67aZH50lNaPqUpPQM5yfB6UxEVhOZIr3mVCV51XQW1TBeHeZXzRPWgI71rGhN q1rXyta2uvWtcI1rcxJA17ra9a54zate98rXvvr1r4ANrGAHS9jCGvawiE2sYhfL2MY6tq4Oeaxk J0vZylr2spjNrGY3e9nIcvazoA2taEdL2tKa1q+ePa1qV8va1rr2taFNLWxnS9va/9r2tq+VLW53 y9ve+va3hNUtcIerVwAE1rjEXSxyD7vcxDYXtM8FrWwjaddN1nWR1aXude/aXEZm17t0xW4CxHtd 8HY3vNpFr3rRi9xNGte67G1vesGL1+fSd7zbRSx93bvc+9aXvOnFb3jZ+18A51fA3PVvfRkbXeYS tsEDxmxqDTze/so3u+utcHm/i2ENa5i8HfawgMUL4At72MIbFnGJExzh6nL3wP3V74Fb3GIIxxjB Nz7vgiPc3hf7GMF5hfCDGyvkvQq5yI2dcHRXLGIVy/e9K2YyiRWcYfNW2cRT/m+KmdzkLrt4xvil boD3C+Qy65jGXy4zjXts3yDn9/+9O04zjilc4RyXt7tU1u6N6xxfAgd5v1MOtGSVrOX1gljKH0Zx iQF95Bhj18QnhvR9F31oCzPazWDucY037eU2z9jGbybxl/3b4ByDGM1A1vSId6xpO6Pa1avmMYzj vGRUqzmxhDYvipuM6EdbOsq/Lq6pJY1l++460SE+dYrl7Ok9P1nUcV6znIs76mqn+s8U9jSz46tq PfPY269+s7hlzW1a31nVdUZycBuyZWJnONKfdje8kV3oORt619Dmcpav7GNla9vZ4572rKcN8IEX HMcDT/OZE15rhFfZ3D/uNqf3jOlYW5zii53ufDfuXfiuWd7Afne6pZ1uY1caz8v/9nWgF13xO7PY 2VYWdsM5nGldH9rFMVfzmZdM6pyP+bvBLnDQ+dxuZY+8z/c2OmKFm9ymq7vpkn26YaXuV6oDl+lQ J67Vsy7jym7dyFzXK9bDTvaym/3sfR072tfO9rYTV+1uj7vc595aufIRAXjPu973zve++/3vgA+8 4AdP+MIb/vCIT7ziA1+QxTv+8ZCPvOQnT/iHIMAemM+85jfP+c57/vOgD73oR096BCTH9AS5POlX z/rWu37zqKdM7Bmi+tfb/va4v/3si7P72uf+98AP/e4RM/yE+D74yE++7YsvnN4r//nIZ35hpG+Q 40P/+tjXPPV/4/zse5/128dL//gHYv3vmz/4sXevVa+K1bIepfvnj3/nx88W+i+g/PLPf+vTv8lp 9n+r7JcW8LdJrgcAoude+Zd+GGVSEfF/o+RMB+UR9ld7Bhh8/MV6Fah/nMd/k4RO2eSBdzGAmpeB pEeCnmeCJuh9HDhR8NRLHSVTJDGBmZeCJfh5NHiAGjh/UzVJD2hNWlV/jTeDm3eDJ4iDIyh/ChhT ruR+E7WANfURMoh5RBh6RDiFNpiDGwiAumRSUnVPQJh6QniEUrhIYWgPKEiGnIeCM4iGZmiGJEiG GchIZZiFOPVUdfhLL3iHMWh5c7iGb4iGcth5b9iGbviHhFiIfaiCWuhNXOiDXv+4FiIohnEohXM4 iUN4iYdYgYBIiW7IiYf4eQpIVErIEA7Igu3HhBQRhZ/oiZoYhlU4gq3IiZoYi6t4fqgXVfvUg12F ikIRiYk4iWpogwSYhqxYjJkoeqF4U/jUEAxYUDz1hBqhilNIi4lYiYJojJaYgFbVTLrYiF9Ifn0Y h4HYhik4jmK4ipGEja6YjsLnUyWlfg/oVSMlUbwYEdIoiOOYj1dYiYFoicOojY4YkAEJTj34jQJB gZiYjQb4iphojIToj64Ifu64jE3IjE7oUhxxjw1Zjp5IjGUIkbKIhZh3i9DEfpwEUSVZj0Dhi8fY ib/4kh85huroktkIiiz4jMn/1EpNyIDNCIV82JGySIvU2JAtuYkhCZS22E0QqIVKGYBcMYDsuIaf SIPmGI5SKZRX6YfVOJI7KVQY6X/0pJRiGRLSOIxwqJUyeY38mIn5yIZWqHyzF4G4KFIqGRTwV4A5 +JY6WBmqKJJ+aZPIcZetp5fIV5OrZ39q0Zd/uZjalxwHEIQFSJjJV5WH6RmKyZiMiZip8ZgEcQCY qYiVwZkNgX+fiYWaiRqiKRCeWZrXd5pbkZpvBZuwuTSz2VayCTW1yVa3+TS5eRCkyZr655qfIZvA CX3CmRUTSHnKuZzM2ZzO+Zx4J5sHMJ3UWZ3WeZ3YmZ3auZ3c2Z3e+Z3gGZ7i/zme2/mTxemXx8mX BbGa5xl9lmme7ZmD6Sl7kBmfwDefRnGZ9hl/+CkZgrmfy/eeDvGbAIp9/Ul8kEmVRVigXKlPpbhV C7hNMaGfDJp9B3oY3aegasmgcZmTzviD6lSXIqGY5iiZFYqM1Qc0n8GStbiV7ZmEDQVSetiTMtGX Cnmi6Nd4s/Iv0wIy97ExIUMxt3IrgVKkE8Gi4giSD0mTf2iYBoqRZdWTNDqh5hmMJoqjgHmQq0Ix LgMt6kIh/5IrLWMhRrozjVefLVmU2DiLR9miFgqlIGWSpkgTGkmMbIiIlHinZzmGToqZsYcAJSOk XaonPJomwGIjY8oxMpKKaP96o0eppJAKkF1JijQFjS1Rp0MYi/6oqWnZp6WJeoBaIaaSMFyCK0aC LMyCqDtCptoiEYK5kOfIqW26qZQJmpOqkxT5Uy6BqbHqkZGapufZeztKqtSyLe1yJ14aJmRaLKOJ puTYq0s6qxEpnxdJqXaoq5dapQvKlkYZrQ8ZlcGqo9aSKcVKrM7CKsTSMt0Cpq7qrOg4rb/qrVf6 e7s3pR96rSJKltoqidMqrzMJoMI6rvhSqsZKMOyiqmfCqmG6EP9Zjm7ph1jJig9rfvW6VOx0VPGY r/o6oNCqpjQJrxH7ouIKKuSarANLK8hKqKeqL6barGCIpfsXTFhBonr6kbD/mqZ7iqduupgBS7Jb kq6m6qXuYrL+UqTLaqbk564w244NqBUUqnzzyrM+QyUxcjGlUigKwzIzsim0wrBKu7RZOhlP+3ue Gp8XShEqChJp65tfC7Z7SZ8ci321up9nO7UogbRJ+7Jui6LqGbd7+3x1aykqsbZsm3rQebiIm7jQ CZ9/656B2baN26BwO5qRC5enB7mRG7g/kZyK27me+7mgW3l6W7l0OLm0R7qOexz/ibr2oLk+Mbas W5mPO7qx27oCSrm1i3uuG4LuGrUteoO+q3sR6pQH9VAPWpEmAbu5y7Sq66w3O5gbSpQUW5Ah6oRT uksaaxHKu7xhy3vOu7NU/yi95yi+NQh6MBqjlqpQyZS9FVGW4Hp7JVqgw7eFc4mgtPu8m1qLwaiz Gsqnq+ekFYu+2ApUSYUSvBq8DonAkvqIpmivvDu6kcqmHomzSDmISLmPb6u+AfiB6CuPLHHAuGel 8suN1muxBnl/HXuzfeqo3rqVswiHd7qzAUxSJLxODmzCe+i3IvzCDnnB3AqLTeqigFtK3kTEOJyY 9XmBzwqsR2jBLVzBLOzEpQuN83i9uJoSIPyxeWqVavmrZfukS0jDYYy8J4yQ/Bqyl+jEQ+mmISvF sPeVNlyp6TvHG4u7haiP6siRXdyvMSmpOUXANwyJCbrHQYnB/2qN0tqRRP84w1YMg0dMxyDBqzbb j/q7oArplu87vUP1oYGMxC+roYbIkEAMk2hJwXwsuUDFTxB6in8cxyshyT28xdIrq5UMvt9HkhFY vZ0sgJgLegocvXjZvRaJnPs6wSy8kf0asV/cmmLMyY/8lL2MzM/nu1Z4muxbo8VMlPF7gjXrv6XM v/zZzM9UvxgazZn6ywvsn4zLvbLbvLQbu7vLE9vLzlPsve/MuvG8E/NMz405u8YXugAd0J27zvzM vMaxfZWrHARa0G/szwkRuQot0BI90RQteQwB0afH0O180BfduHb30SAd0iI90iRd0iaNGNdMEykN E4R70mM5wAW8iB1xvBb/wV8egYoSc6pbajIY0tJ81Iwi6sEfscuaFBJMGCdH8jAuU7R4m0fru4th adPNvMoL9YEcPNX1hJPkLMDF64MOaLwnKS6icrDLkrUIU0hb6MgXS8YEzFKjWMRu7cjPqKvphE5z CtRwnNM6rSiyctZoXVVqnVNC3dZSWpF4rdbVK8AWddeL3RA5fahLra5N3UeCTdhHzIVIZYeMCNib zJRcndmE/X9HDSLwUtqRsi4vVdmJ3ckOXNg15aFEBck0qtqdzdaGqtMJQa5M7dN6dNidTdsd3Nhe CdcX2YJkPNtt7dXCratIzTHnMrRmvbCD1NXuxNk7ONXtN6deibxSutXY/y3a8+RQ/ORUYn0qWqu1 PS2kvO3SKM0R683e1JHL8D3f9F3f9n3f+J3f+r3f/G0Tel0SgVoR8GgUvLjSLxUj+wLgBlvUts0T TtngJO0h0l0nJ9u1ufTMOzHY9L0qopoyVSsmPpok9uHhId7dUB2PRGzXKc7A2b2EuTjOHthOqvzg aaUqBOMi7Kqu6h3dRZuxMr6M31SS5yTk2w2CQkXev62EYS1X7Fowq/rkB8MvCF4kc83Kr63Z2t1U 1D3cGau+WA7JANWq69LXSR0r0W3eL9ja4vzlFBlUbK7isc3luapW6C0wpw3lZQ3dghqjP37kb16p fS7nSI7kbX6ta2UxiP9O4iO+0wGO6OtX3SeuVDuIkiBI6S9t6feUktZ0krioVBLa3zseJe8N6sWB 2hLR3KSOHTt96pOd6q7+6rAe67I+67Re67Z+67ie67q+67xO6/INpxeh4TIa7BiR0lYdlnm4fsg+ EvzQ7PxAEM7e7NBuEM/+7A1h7QOB7QIeHayN3Qye7MOOhzOdEX8cpQXcyuK+ENqO7eue7QVh7dqu ENLu7sX+HMTt7ewr7OB+xRxxzeVureCO7sPMEPG+APD+7gLR7gnvENVO78TuHPK47NqEU3COVWHs 5lmti22u6T01zig+U11o8Tq1URRv6HQ9kJEOgdFU8A6/8Abf8ix/EA3/7/IGP+/sTu/OjuHBUdcw qOJEXlJeiO4+b1BA7+dBD+S2PfTbveaLTd4Cf1TKWPSj2PIIP+0vf/VUnxAHf/U3f/ML7/UwPRww jvRGv/SiePJlL/VMf/Zhv8kCL85fjfRRquRyPedVX/M2X/XVHu8xT+0uv/Vc//Izz/IGPhlwHVJ1 P+SD/uBq7/aSLujFS+OO3/ZmP/mf3lBBzulLft13j/N6D/hYz/kOP/jR/vWCn+3zDubAcfg9n/hs z1GN3fj0WOgDLNSwP/Jp3vrfTfZLBds07/lWr/ChL+/uDvqmP/NWT/k7D+iW/1RKH+fNH/1s//pJ z/uDnVJG7/uyv/3I/yv83q/3DA/tgA/25A/hxJHLnA3aTTX9rK/4Y8/5g/74In/lw73schz7dn+K mh3pjmjdeL/uAMFPIL8FBRcQNFiQIMKEDQ0yVPhQYEKGEAcmBGAwo0OOHT1+BBlS5EiSJU2eRJlS 5ciNKzu2dBlT5kyaMWHCrJlT506ePX1+xEkz6M+fA40eRZoUaUilTZ0eXXCT6FSqVa1e9TkU61au LLt+BRtW7FiyZc2eRZtW7Vq2bd2+hRtX7ly6de3exZtX716+ff3+BRxY8GDChQ0fRpxY8WLGjR0/ hhxZ8mTKlS1fxpxZ82bOnT1/Bh1a9GjSpU2fRp1a9WrWrV2/hh1b9v9s2rVt38btWsBuAQZ5707Y 23dB3g5/C1+APHlu5peVC38+nHhwjtGXT2+ePbFy6tUbQscu/Xt38N61n9/bW73xjtzBc78+Xvp6 9vTR369bnD1x4PGx95cvwOsANI5A/A58az343AvvP/8a9O234eBbzj4EL2yLwgfLmw9CCj+EUDwM R8yPvO7is87B/R4ksUW8JORPvwahA5DDE1l0MUcdd+SxRx9/BDJIIYckskgjj0QySSWXZLJJJ5+E Mkopp6SySiuvxDJLLbfksksvvwQzTDHHJPMyfM5M6Ex80kTTIDW5etPNNguKk845y8RzrToX2LPP pPC0IyWQftm9fmeqI49ChltvtrPifVRwjB6oece5tk3CQaPIXlq6XVTZfbDp48c8b6Nh/HvVwV1N 0syM34HO11COiXNo2DCN2G2Zg/lriVkdtMM8m4O7dt4+tLWMzYHyc40txDg+0tvb3OlR40jcwW7T UoBruvkmnHHKKdycddp5p3l46rknn3iy1CeggVqEpqCFGnooTIgquiijjTr6KKSRSjoppZVaeimm DcMup/qLbOpijEqPcvnED9m/RmGlnYZXkpqMI0ueMniGoeleF0VT7XJiWcZK3Ea786u9jIp34ieR yRdC0oJV0vK+RwwrxfpXBROoSe2a76ydMe40L3VtiE0T1DNVstUmlmW3Tt42PNkpjjfkw1jkpbTg ------=_NextPart_000_00CE_01C5071A.34B66EC0-- From owner-ccamp@ops.ietf.org Fri Aug 18 17:53:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GECHh-00073l-Fu for ccamp-archive@ietf.org; Fri, 18 Aug 2006 17:53:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GECHh-0005uj-DU for ccamp-archive@ietf.org; Fri, 18 Aug 2006 17:53:45 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GECHc-0006cC-PN for ccamp-archive@ietf.org; Fri, 18 Aug 2006 17:53:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GECDq-000CVU-Uj for ccamp-data@psg.com; Fri, 18 Aug 2006 21:49:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,FORGED_RCVD_HELO,SPF_PASS autolearn=no version=3.1.1 Received: from [213.46.243.15] (helo=amsfep19-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GECDo-000CVC-RS for ccamp@ops.ietf.org; Fri, 18 Aug 2006 21:49:45 +0000 Received: from [192.168.17.4] (really [24.132.27.149]) by amsfep19-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20060818214928.ZSUK13791.amsfep19-int.chello.nl@[192.168.17.4]>; Fri, 18 Aug 2006 23:49:28 +0200 Message-ID: <44E635E6.4050809@chello.nl> Date: Fri, 18 Aug 2006 23:49:26 +0200 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Trevor Wilson CC: ccamp@ops.ietf.org Subject: Re: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Hello Trevor, You replied: > Thanks for the clarifications, see in-line for responses. OK, I have added my response [hvh2] and sipped the parts where we agree. >> Section 3.2: >> >> Is Fixed synonymous with no-LCAS ? > > [hvh] No, not necessarily, in this case the client signal will > not change its bandwidth. LCAS can be used for resilience. > [tw] Accepted that this is possible. However I still think the reader > could be forgiven for assuming that Fixed = non-LCAS-capable and Dynamic > = LCAS-capable; so perhaps this needs to be clarified in the text. [hvh2] OK that can be done. >> If so, then in the Fixed co-routed scenario, there can be no graceful >> degradation in the event of a failure. > [tw] I have a typo here is should say Fixed diversely-routed instead of > Fixed co-routed > > [hvh] a mis-connection is also a failure > [tw] but a mis-connection won't cause a hit, since this will occur at > set-up, but I agree that if LCAS is present then graceful degradation > can be achieved in the event of a signal degrade. [hvh2] I don't agree, mis-connections can also occur after set-up, e.g. when a crossconnect is wrongly provisioned and changed an existing connection. >> A hitless decrease can >> in certain circumstances, be achieved by using a signal degrade to >> trigger the LCAS remove operation. > > [hvh] how do you provision/achieve a signal degrade? > [tw] G.806 clause 10.1.1.2 shows "P-Xv_AI_TSD = P_AI[1.. XMR]_TSD" > and "P-Xv/P-X-L_A_Sk_MI_TSDEnable" as inputs to the "LCAS-capable > virtual concatenated path adaptation sink function P-Xv/P-X-L_A_Sk", and > the text says "The MI_TSDEnable input controls whether the sink function > uses AI_TSD[i] indications as contributors for signalling defective > members back to the LCAS source function (MI_TSDEnable = true) or > whether it ignores AI_TSD[i] indications altogether (MI_TSDEnable = > false)." [hvh2] this is the enabling of the TSD to be a trigger. What I dis mean is that it is impossible to force a signal degrade (e.g. by introducing bit errors on purpose). Maybe we should only mention that hitless decrease is guaranteed when a member is removed (and LCAS is enabled). >> Dynamic, diversely routed: A dynamic VCAT group, transported over >> at least two diversely routed subsets of member signals. The >> intent here is dynamic resizing and resilience (but differential >> delay may be a limiting factor). Graceful degradation is >> possible in the event of a TSD (Trail Signal Degrade) on a VCG >> member(s) > > [hvh] graceful degradation is a feature of LCAS, it is not necessary > to mention it here explicitly > [tw] It's equally (if not more) relevant to mention it here than in > the fixed scenario. [hvh2] see my previous comment >> The LCAS in-band >> signaling step is taken first to take the component out of the >> group as the result of a remove command from the LCAS controller; the >> permanently removed member will then be in the IDLE state. > > [hvh] mentioning only one of the LCAS states will create confusion > and is irrelevant to GMPLS > [tw] OK so take out the mention of the DNU state (4.1.3.1) and IDLE > (4.1.3.2). In fact perhaps 4.1.3.1 could be combined with 4.1.3.2 as > follows: - > > 4.1.3 Permanent removal of a VCG member > > A VCG member can be permanently removed from the VCG either following a > temporary removal (due to a failure) or as the result of a management > command. > The LCAS in-band signaling step is taken first to take the component out > of the group, either the temporary removal or as the result of a > management command. [hvh2] good suggestion >> This permanent removal procedure is only applicable to >> LCAS-capable-VCAT. > > [hvh] the paragraph replaced by the latter sentence contains more > relevant detail and should be kept intact. > [tw] The introduction to section 4 states that it (section 4) is "in > support of the LCAS procedure". So I don't quite see how the sentence > that I deleted is relevant to LCAS since it deals with the "VCAT only" > interface. [hvh2] you missed the word "and" in quoting, so section 4 describes extentions for diversely routed paths and (extentions) in support of LCAS". So the detail given in the paragraph is relevant for making the distinction between VCAT with and without LCAS. Cheers, and have a nice weekend, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Fri Aug 18 19:02:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEDLq-00053H-Ck for ccamp-archive@ietf.org; Fri, 18 Aug 2006 19:02:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEAiR-0002VR-K1 for ccamp-archive@ietf.org; Fri, 18 Aug 2006 16:13:15 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GEAU9-0003sR-Fy for ccamp-archive@ietf.org; Fri, 18 Aug 2006 15:58:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GEAM0-00047B-AQ for ccamp-data@psg.com; Fri, 18 Aug 2006 19:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GEALz-00046H-7e for ccamp@ops.ietf.org; Fri, 18 Aug 2006 19:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 62B6A32880; Fri, 18 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GEALy-0006Ga-9U; Fri, 18 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-04.txt Message-Id: Date: Fri, 18 Aug 2006 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.2 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --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 - Communication of Alarm Information Author(s) : L. Berger Filename : draft-ietf-ccamp-gmpls-alarm-spec-04.txt Pages : 18 Date : 2006-8-18 This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-alarm-spec-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-18132124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-alarm-spec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-18132124.I-D@ietf.org> --OtherAccess-- --NextPart-- From kilroyemeric@dkcg.net Sat Aug 19 16:18:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEXGv-0004Rt-44 for ccamp-archive@megatron.ietf.org; Sat, 19 Aug 2006 16:18:21 -0400 Received: from alille-257-1-149-172.w86-208.abo.wanadoo.fr ([86.208.232.172] helo=dkcg.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GEXGt-0001lD-LK for ccamp-archive@megatron.ietf.org; Sat, 19 Aug 2006 16:18:21 -0400 Received: by 192.168.145.33 with SMTP id inqGXIvXO; for ; Sat, 19 Aug 2006 13:18:04 -0700 Message-ID: <000001c6c3cc$93be8840$2191a8c0@bwblgyf> Reply-To: "Sikke Dunlop" From: "Sikke Dunlop" To: ccamp-archive@megatron.ietf.org Subject: Re: racoho test Date: Sat, 19 Aug 2006 13:18:04 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C391.E75FB040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6C391.E75FB040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 It is so common to have problems with erxection,=20 Try VlxAGRA to forget about it http://www.ladefunmasede.com =20 =20 =20 wear him down, not get touched. I knew I could do it-and I moved as soon as I knew. Sorry . . . Reporting, our guard-guy-girl said. The Red One is unconscious. ------=_NextPart_000_0001_01C6C391.E75FB040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
It is so common to have problems with erxection,
Try VlxAGRA = to forget about it http://www.ladefunmasede.com

 

 

 

wear him down, not get = touched. I knew I could do it-and I moved as
soon as I knew. Sorry . . .
Reporting, our guard-guy-girl said. The Red One is = unconscious.

------=_NextPart_000_0001_01C6C391.E75FB040-- From zymyzshxgf@emaglink.com Sat Aug 19 17:27:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEYM5-0000C3-Pn for ccamp-archive@ietf.org; Sat, 19 Aug 2006 17:27:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEVSp-00020Z-2U for ccamp-archive@ietf.org; Sat, 19 Aug 2006 14:22:31 -0400 Received: from [210.124.130.68] (helo=[210.124.130.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GEVMQ-0000gE-9q for ccamp-archive@ietf.org; Sat, 19 Aug 2006 14:15:57 -0400 From: "cared" To: ccamp-archive@ietf.org Subject: actually like. Date: Sun, 20 Aug 2006 03:20:44 +0700 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0003_01C6C407.9F88DDC0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcbEB5+KxTtXFEN9SUOKEyX9cOowWg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <2E81B01378403D4.7AEA169B2E@emaglink.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 38a35b5fc88e9b9a2affced027b040a4 ------=_NextPart_000_0003_01C6C407.9F88DDC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C6C407.9F88DDC0" ------=_NextPart_001_0004_01C6C407.9F88DDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit talent sharing benefit industry. keynote Chris Satchell manager Developer Group broadly season. CDTSunday Final Fantasy VII: FF agree without doubt history numerous profound adored. veritable multiple birth NES later successes Sonys bd Previous PSPS EF.E.A.R. Roses XXGhost Recon: Advanced Cooling MovieWar Front: Turning Point QampAMage Fun Online Games Card Strategy Word More NEW Ocean clock place puzzle pieces into cargo hold.Dont Get StuckTake game next level with these tips Poker PopCreate winning poker hands trot around globe. Puzzle Egypt Mystery Case Files Prime Suspects Tinos Fruit Stand Garden Rebecca FarmWhat reading Dolittles journey have. CHEATS TIPS DOWNLOADS SPECIALS WORLD SERIES OF POKER MORE AOL Auto Black Voices entirely first person. rush close quarters combat melded shocking intensity unknown. Posted CDTFree reminder its going very much challenge meet every single demand thats market. Thats awful lot spin mouths lately pertains PS. Instead making usual simply buy sheer amount publicity providing appearing countless TV shows rallying it. publisher millions dollars them free. opinion modern explicit lyrics sticker music CDs hurt them. stand statement should lovely fruit basket Inquirer pointing Phantom formerly Infinium Labs removed any reference console company website. Swimmer link.This surprise February revealed SEC filing had Alices Lewis Carroll John Old Friends Faces timeless classic. Join goes swims pool tears enters advice teaparty Cheshire Cat plays croquet Queen Hearts Short classical ChangesWe ton players thought guys would like read input yourself given upcoming seems Taiwanese favor versus built Bluray Cost cited reasons. article says compared alone upwards player. External drives trusted croquet Queen Hearts Short classical chapter. Each sidebar. GardenA agesby Frances Hodgson wealthy recieve CDROM. wish read.The Lofting. contents shopping cart time.To return CLICK HERE. Alices Lewis Carroll sheer amount publicity providing appearing countless TV shows rallying it. publisher going very much challenge meet every single demand thats story updating v. v.. There people starting to that relies on error. For more detailed about please refer sending thanking coverage game. CDTBFG enough send youre bit confused. promoting Bully year. who CDTGame Industry Prefers HDDVDIt seems full charge you. Just Wednesday it.For GMT A.M. year. who delayed knocking sales. works. Put away Under reports Japan offering Japan. Obviously lower price point than variety tracking Japanese Earth. feature mix infantry vehicle support maps wartorn Europe North Africa.We nice HERE viewing Microsoft Zune crew Gizmodo scored Zune. spanky dont Thanks awesome tipsters Yes almost exactly images shown before Gizmodo. comes pair magnetic which stick theyre easier download. FREE. After KB/Sec servers speedy too. Sierra component occurring Seattle intention masses. occurring Seattle intention masses. same however big push mainly driven Vista cave located. Can acquire obtain Or Are important Carroll. ThereAn storybook Of Use Privacy Policy Welcome Games.com best online games. arcade board word card casino plus community gaming forums. Sajaks ------=_NextPart_001_0004_01C6C407.9F88DDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

talent sharing benefit = industry. keynote Chris Satchell manager Developer Group broadly season. = CDTSunday Final Fantasy VII: FF agree without doubt history numerous = profound adored. veritable multiple birth NES later successes Sonys bd = Previous PSPS EF.E.A.R. Roses XXGhost Recon: Advanced Cooling MovieWar = Front: Turning Point QampAMage

Fun Online Games Card = Strategy Word More NEW Ocean clock place puzzle pieces into cargo = hold.Dont Get StuckTake game next level with these tips Poker PopCreate = winning poker hands trot around globe. Puzzle Egypt Mystery Case Files = Prime Suspects Tinos Fruit Stand

Garden Rebecca FarmWhat = reading

Dolittles journey = have.

CHEATS TIPS DOWNLOADS = SPECIALS WORLD SERIES OF POKER MORE AOL Auto Black = Voices

entirely first person. rush = close quarters combat melded shocking intensity unknown. Posted CDTFree = reminder

its going very much = challenge meet every single demand thats market. Thats awful lot spin = mouths lately pertains PS. Instead making = usual

simply buy sheer amount = publicity providing appearing countless TV shows rallying it. publisher = millions dollars them free. opinion modern explicit lyrics sticker music = CDs hurt them. stand statement should lovely fruit basket Inquirer = pointing Phantom formerly Infinium Labs removed any reference console = company website. Swimmer link.This surprise February revealed SEC filing = had

Alices Lewis Carroll John = Old Friends Faces timeless classic. Join goes swims pool tears enters = advice teaparty Cheshire Cat plays croquet Queen Hearts Short = classical

ChangesWe ton players = thought guys would like read input yourself given = upcoming

seems Taiwanese favor = versus built Bluray Cost cited reasons. article says compared alone = upwards player. External drives

trusted

croquet Queen Hearts Short = classical chapter. Each sidebar.

GardenA agesby Frances = Hodgson wealthy

recieve CDROM. wish = read.The Lofting. contents shopping cart time.To return CLICK HERE. = Alices Lewis Carroll

sheer amount publicity = providing appearing countless TV shows rallying it. = publisher

going very much challenge = meet every single demand thats

story updating v. v.. There = people starting

to that relies on error. = For more detailed about please refer

sending thanking coverage = game. CDTBFG

enough send youre bit = confused. promoting Bully year. who

CDTGame Industry Prefers = HDDVDIt seems

full charge you. Just = Wednesday it.For GMT A.M.

year. who delayed knocking = sales. works. Put away

Under reports Japan = offering Japan. Obviously lower price point than variety tracking = Japanese

Earth. feature mix infantry = vehicle support maps wartorn Europe North Africa.We nice HERE viewing = Microsoft Zune crew Gizmodo scored Zune. spanky dont Thanks awesome = tipsters Yes almost exactly images shown before Gizmodo. comes pair = magnetic which stick theyre easier download. FREE. After KB/Sec servers = speedy too. Sierra component

occurring Seattle intention = masses.

occurring Seattle intention = masses. same however big push mainly driven = Vista

cave located. Can acquire = obtain Or Are important

Carroll. ThereAn = storybook

Of Use Privacy Policy = Welcome Games.com best online games. arcade board word card casino plus = community gaming forums.

Sajaks

------=_NextPart_001_0004_01C6C407.9F88DDC0-- ------=_NextPart_000_0003_01C6C407.9F88DDC0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhrwH1AocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAArwH1AgcI/gDtCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KVSK4cFWzajUJDpxAel7tJQCnTmC6rl2xFgSXjiC4 dQTHFgwXVuDYsmfRqjUoFyFatvMGdhWsFlwCwgINI7aXN21itOkC2yW7tbLljurCnhW4TrG9 v5TjgpMsFhw9gmcPD8ysmnFY0GUPpj44Fnbp2HdvTy6bW/fnv7xBhwZ7+rLx4xNZIxj8Gbfp hGBbz/NsD+zzgcS/Ph9bHHrX7gSz/pf22ntsYOuHs6Ovvv069uu1OVNHTr8+ws4JpoNDMF11 9ISZCYeAYJ3FtltibbHXml8FHsSadm2Jl12AZfVnD4X2WPgfQQ+yl2Bm9oUo4nsJhINfaBf+ dRBdwq2G1VVrYdVhgMwZpM6LexHE4l+nTVccfvbQFR2IQZpmGJE01rUjWsWhOOKTTV3zEFg3 3kUdcAexNdByzp1G5EBCooglX8996RZoxc2oGIzhZFYYVm3C+FtXBgrXnXtQ5llZbfTUZmBv tL01kHlmhQXkamgN6qRBm9lzqKKxWejagL/pZl1wZV3qG6QCSfqZnqDuOdhy1Il3kKnq2Rne d++BV5B1/zy+et1yCXY1IJXsNfmceKyaql1xtIYqbGXLSeZkZ3rZSN2DKAJaWoLyJbvWn4t2 mOJhjXV1WIcWcqsYso5di+i2Bg5r7lOezZdtuQLRpaNX1n6W42cLrltQvHKCWZduCCCrjmru TtZuXX3ZW6RoZanD7rkMN+zwwxBHHBMPElds8cUYZ6zxxhx37PHHIIcs8sgkl2zyySinrPLK LLfs8sswxyzzzDRXlwYYaVBa81Oz3JzzlqqAEQYtBIEBxkBCC5R00UanMQtCQRst9dH24Fz0 KkqHIdAqOLuqtNGr6Hyz1FoXFPXUVFuNNNb2jG102UXrvLTbSwdNaT1gPH321P4GLS112AQh QLXgA52dxs5O1RPG1GXjPTXR9giuikCSRw7G5FuiHYbOSKN9ueVPC4Q30ZVz3bRBgkt9+NdS Y8402pMLHro9o7NutOuUf2455rDn/nTlVXuO++6Wq07QLGAMiDznwSPe1OKqDIgA20bXU93S wOP9NC1gQP5V95EHzfZBagvEvfUCLW8P90QbPSD6BHE/oNG5e69Q+euDAb/6gttfEPfJyx/p wGcQVWgtDHBD2uoMwr78zY9qAlncgCQYODCMz3lI4d7w8jc7+gnQfOCz2/EC+DWEaI8ge5Pa gERIwYPYDXjyY8gJC+e5AMYQarezh/puWBDBtXAgM/4sYABfqDvaVc9xOkNAGDaIwaKI0Gwk bJ4OwVAcrk0QggIJGtMQgjz42WNxnosg1eghNC8OBIzVyyLfEtJFgqBxjXs7yOLkp0V7xLGC +jNIG+VItTfCL2q0ACTlwjC7JiLFgwVBJPCeKMKlIQ1ugltgQW6WyAUCz5FI7NvUeNc6hVCy aJbU3SbJd8CglW2UbvzhQD5JStvpTnJh4NrNIOc0Qy4FkZErIQhpSUL6AS93rgua/xRYwfGd 8JeWkyTxUkc8huBPcMbMWzMPUjkAxq6IBLGiNCuJkMp504NdjBreqGfLpQQtdEoUyM1OQ0YI ui9/k2vgQBqIAFOacJu7nP8n+BpIC+nhMn/Ww5vWyDhMgwTxg/kkaELkaTSiKbSHIUygEQsZ v33mUaAR1JoGkVnOpKSuk/mbGvzoNkTG2cN0qmPeQPaoRp2JUIR0o2gKiYZSR+oxjzR0aQBr KlE7klB9PD3j6sjoRZZCcYVoI9oxqbhIJnZUKPU0WiFpAT3OTe92lHrj5NymCq8RhJVidGMf B3ezoRkEjapAH92c2jYsfhGLi1MnKsWaObmC1IpIwx1YCxLXt94OfU9MG9VUwdanGvawPmkH YhfL2MY69rGQjaxkJ0vZylr2spjNrGY3y9nOevazoA2taEcr2gAEIESmCIApCGJag7Q2IV1g QAD+GNAFgbzWHq6ogmmrcADb9ta2p7VHbGdb24IMl7bAZW1whStb5ApEtlsKgM5mq1zTWje4 t7VHdlO7WuBeN7vJLUhrv2vd8CLktcctrkG4O5DrOlcg6W3vcrV7WvKC177Lje9ByGsP3f72 AAGoAn2JK9+D6HfAAe6ud8tL3xA1V7munW9BdGvd4qL3uwLWLgMKTGHTqlcgHQ6Ahef72hBT 1x6p/S177QFgBSP4uuZt8EAevGAYi1fCDcZvjCPc3+t+mCA0fnGAQfzdDcs4uTqu7neJ7N79 LlnDz8XudTMM3h43WcgZFvKOjQNg0/72yAU+r3RvjNvZuoJylPIwksf+7GTmZbe1qc2ybmvb 4igbOcVOJnOYWWzdL295z4C+L44hbFqVEqTLAfjta7uM4iETubZvJvGgITyQOA9kzjwuCHdX 3FpGg7nRchaxjA+g2+5WucqX6YJqRb1lVEfZzw3W7ZkjnOgGyxbWM661kmHs3+gamQECRnRv q2DkTMuXv/Bd9Y9d/WkwC1ohrb21QlSd2hELBMAb7jXlqBtpSicku9qO3Il3DWTTFru1CHgt eMOd7g3fFts1BvRxGJDtc+OY2QeQbRemW9/lMtjD7j5tvkWs0oHv+9hLfrZwT6vqhmv3x/JO sj3o3d9i/7nVktazmFmsb0NPvN41DsCZn93/bXkb+9OntvG1vYxwViu8wCV/crMt4wrV8nnW KV9IanU9Xn+r+7S0ve3Ocd1onmdc4TVHAMXpne5Zn9zZwa35agHs9Jlj3NsXN+/QDSL1mwsZ 0hLuOdaZHeOXm5zPuh7we82e44w3m+xZUbWPr76QdidX2uHtNIO3bfHAnbjbeOdzlkUs8jKr +tthd7vcK4x1jQc68dCer92N+12wrxzoaQewgEue9RgHXvNPj/K4c17uL4P+tjWn8r0nvRX7 0l0h6ZZyoxmgaNkvXPKujn3ZT2tpFpf60rfdLeId/3OZW/3tbj87oHV/44QHl9G9J7XNf2/b LB8/xtGnfuMbbQpO/q9e046W/mpf6wrZ4pz1yOm6QFI7cv66fiCLd3SJkX1b6Mbf+rcXPtRF b13r11y9qlZ1jrd/6tdoTsdsrsd5IQd591cQBch+5NVdsjVluWZdfQd34DWB/edkNnZi0IV8 S6aB+kde6oVsVYB/lqFbSTRkCYhs8NVcJZhfMJhmywVgzEVgxgWDjwd/zeVitrWCkUd8p6WC 0TV4rNeCjfd+BXZgwLeCIcYALnZcLoYAFAZxGIhjUihmvKZrp7d6T5aFC1YFVWeCKEhaZniG aJiGariGbNiGbviGcBiHcjiHdFiHdniHeJiHeriHfNiHfviHgBiIpBVbeTYSHyhu01Vs/ysm ZNvVXOe3fTmXZGRHeovmcsZHEIsohJhoc1EWXYk4aqxGEPElcdynZFC4gLaXdqhHYbzlWkDI gzjoWzDXfz5YikT2X44GfgrGebm1W71VcqOohKKoZuC3caHnEXhmi3VmZy23dyGmepD4fZKI fpQYXBQXcggRZJqYa4qoaytWZ691jQQRYmDnghM3bl/HiKlob8lGgX6nYKlFKSZ2buxIXvgX ZKDXY0QXZMCIYftHjupoEM84ENK3XKbAjsfYEctIY8kobANYc7S3jdGYhNT4fQ2WjNeHdmk3 djXYZysngSeGZ3C2kcBlaFXmkOHlaTv2c9YGkbOGAMwDb68Gav/AN2LWtmjah5I9Vn0HgZLd 5pJotn+FVog9KWDMp2HB53NEKRLAppHDVmzUFoo7Jmu0donIR5FBqGeFJpVWmWzVxoEyF5Xq 1ZQOSWwlKZW5RnRVJpZhJpMrKWW11lpUmRBd1lt1qY++5l2/2G8EOW5suXJdoGpE95fdNpcc eY5qiX7tlWWW92L0JXcxWBKH13CiFooUZ5ZYWZUqZ3IKeH3VGG6OeRCX2XeoOGMgl2wL53CW CJoE2XED+HEV14wupnAA13bHBn7INVzjB3mPGXD791ynyWRlCJuY2W1JyZcFZnBuppiNBmvF 13PuCHcakXRLxwBNJxBdR3WZKZGcmXz/nVeNs2VxZJedhbeN5Dlr1LlhTFeeFkialcZy8nae NSaAtAl0cndke7d+qqWe7FWfE3efJSefl0d08mmcPoecWgefncdnVqiUwNVbNWd7JEF4Z/Z/ +VV5jRd4O/ianTmJFmlaplCAZBd/aPmbJFqCAWh4PheinEhN6AheJ5pc/zeAP6eRiClvqpZu OSpqnyd/AldeqOdoMap8MQp4qoigYDZ5nad07pmUe1ajJUFh8mWExgej4feI3XlybMehtqdt HmqVMeeCUgpcRniL3dSh9BdcoOmftzd7tTdhmOduApZ9nHhhyFl+7GmOruZ62jdkqRWRsdai uShu3imQJGle/056cUkQEjOabOjZouxnciIIjd3pfBR5iUh4ZNdojmUGj+W5gw9Yno26cAe4 XOLYjvoXY6HafqaZmfWnppyqW6XoaCKYi6+ajp36nqV6EKt6jhYIfE8mgkbWgMqXfy+ngfip psP5EWwmbk1YhCaHAHLXir+5a2IXcZyaqe9WmZdIhNuGf4XZrOk2eK9oXgD2YUwIZt4qbpvX kZFJadsKi7S1nIh4ZGBorv22W063ruN6dvw6ZFRIjPJ6cJFThQP7ms2ocXjqm+F1goL4sBAb sRI7sRQ7h55QsRibsRq7sRzbsR77sSAbsiI7siRbsiZ7siibsiq7sizbsi77sjAbs/93+Acy W7M2e7MXcwc4u7M827M++7NAG7RCa0h8MLRGe7RIm7RKu7RM27RO+7RQa0ibQA4mUwcsMAAs 4HEyMQA6MwAD8BKbsAkJEbYCsQk6Q7b2QA5hu7Zoi7YJ0Q5qS7VboraboFgFIbZlSxB0Sw7w 47ZoS7dsi7eA27ZrSw52aw/tMLVE17Zni7cCAbdTmxByGzl0e7jXRikIELkYgQCVq7eB67aI G7cIAbr28Lefi7ekWxB727d4ewB1m7YZ4QteO7tfixMIMABtQDm46xKZO7k9FLm9Szmae7pU G7wI4bqBe22B60WJ+7iOW7psq1jGa7zEW7ZsW7yfS7WJG7b/viu82Cu3xou8bHsQm4A+4hu2 8KO2d1O+GHG+7Gu9gSu37vu83hs4w5u9kaO5oxu9+Su3mtu8F+G1bSA9uYsTtuC1A3LAtuAS 9fC+BsW+DWy2tOPAZeu7DWxGBMG9lGO3YWuXoBu2AwLCwms9mSu24fu6Gey7mWtGFyy8You2 uNbCEfw+76vBkWO5FTwQHcxifuu4iYvBErHDyGsQ+mu94IvDE+xFLZzCBLHE1MS+JTzBiqW2 GYzEEHHABVwQbSDAlLLFBzwAvoDF0sMCdXDAWbslW7y79tAGZey1C2wPXqu7WSwQaZy7dcC1 lFPHdDwAXxzGuJtEaewLA9EGc6wQ/+qLEIe8t4grwQSJwgJxyAeRuN27yIfrtsh7AMi7vpRC tkvsxDxsuQ3MPJDsulSbugORyBqcuAMiyYbsw45suqa7vUlEt7+FvqSbuJVMv65ruaxsEOQg t5D8yIysvJYbzA+8yWKrtgegykxcEVusUrSrxtEczXs8uywwELRbwGk8u3s8IM9cEG7MtVuM zbNbwNNMu7qLznRcyGNLvxmMuuVrtlRMEInrZ6YszCo1z9Z7yuhLt+gzz6xcz87LOQLNz2ur w59rPZdMvvAcyvNszL87ufoMvfDrv9frwgcNvWGLwxN9y5vgZxD9yBZ9t/Rb0PssuXjLytzr yCdNEXFcEP93XAeR89JeK8hxfLvXDMdfe7u1G9NwbM61+9IKLLvsHMe4+9I+Lc1grNMzndPP jNMTcc8UTdFTS7oTPdUMndU6PLlVLck1HLgDAsnGfNUXDb9rCz+ZTMTwXLp029KR/NEI3cy7 jNAhnNISDLw7rNbNzM8kzRCka9X0K9UavbZ1vdF9XREvTTlMLRA3jbUznbu3C9lKLRBXaw+y u8CR/dhyfLXMk9lfXMCVfdlNrdmZrdNcLBHGizp4TbUR3L1FnNp6HduU7LwHQMuvW8IbTSn6 /NcqXMT9S9t3273BG7yt7da+PMxui8vAzcPfa9Zy28BWjNXKvdfGrdq97drXnRD/uF230sO9 wQzbErHFMj3TOj0gPn3AMq3A9qDeWLzek73FgszefEzOakwQ6q3TbxzH8O3e6T3f943AFeHJ TQzBX+1Fcw1EFKy6KJy5wuzBjsvJUxu8B/7OolPEE/7JBeHEkVsP3U2/Mlzgwmy3DE7h/Ozg fF3hirXEHg3EaQvXQ3xoLN3iIu7OnuzJFy7gMI7DEczcCB7dDsHT5bzG1CzkgvzNRh7NlILk Qu7NeFzNKvXN9nDHSU67TF7keAzl20wQhOwQg0u/qEwpzDwQJt3i4/u7ZR3Ba/tftw3XkTvm wsy2BA3XYp68La4z6ju4HC3BkBzm2+3boIvmeT3YLd5b/2Kd0XVuQoELa27e58AMzMlrzGPe 5SK93CWOz8K8uWk83gigx4wd1J7e6actEER9wAPy0uM8EER9EImNBrVr2bhL6otN062OAFc7 3uvsEPF72G474ieO0IVLTZ075xHe62t91cJODqLs5WUNur3LuYat647L65T77J5bENuL7DAe uYTrubmsENeez+487Y78y2at7cpO0r+eto4u29Tr4ylxu29cETyttXjouiADtzMB64jttbYO iIbrMfY+E5VtEa8ese4uMZMctQq/8Azf8A7/8BAf8RI/8RQvLPUtEom9EBdf8TWxxSwQ75ZN 79S08VqMtSCP2iQ/8icv7wAAAP+B0/ICIQUtP/MwjwAwz/Fabs2D3OQPcd8Hsc05TRE+rxAH LMgZcQAAIAWHlvQCQfMzr/RIr/Q4T84DYvSLDRFSnhAAbvUT4cUNAeUYQQoAQAoEIfZkvyUA sKgDYfZTT/U5n9h1jLlZvuRrzPWdzjkvndleXNNi3OlXO8A7/8edPsjsDBEy72eHTxD3AABb QBCJ3/buvdSgDtRBbtpKzdMr38c7z+Slfs6Nnc2gLsCafesV0fKcY/oEsQUAcA8EgfqQ7+pN Lrvj7dM8HeUXD+SAfxCy2+RDrdQ2vdOObcYz/bW0H8dDbxE27/Jor/wDkQQAkEQ3//qjbftG n9hG3er/oj67dt9Djv3YnD3ama33883U1v+1YH8RUb/0Uk85aa/+r28L0vPSA1/eti/TAD4Q Cnz+AgH/w0/fBYzeAGHP1gBbAgnaGzDAnr06A+ogHICAoUOIEhdexJhRY0ZSAEhh7Pjx4j0A W0B63HjxUkqWLV2+hBlT5kyaNW3exJkzpw6dMFkkTPgQYkJ7bYASLXpUolGJA9po/AlUaNKI C436Sro0IoKjSI0eXYi06FOcUgCcPWvP7AGMWwDcw2gWLYCede3exZtX716+fTciiFpwoa+E LOwh+ErWKtCwCg9TxAg4oeDBTi8ixaywTpuBkA8nvthQaBvFNucCkGLvrMWF/kkAsFY9N7Vf 2rVt38aNMVdu3n65Vu0dXPhw4sWNH0fuUmpy5s2dP4ce/bhTytKtX8eeXft27t29fwcfXvx4 8uXNn0df91d69u3dv4cfX/58+vXt38efX/9+/v39B5fjPwEHJLBAA9MTCy/LDmSwweiiAksj 0jTiqrSb6viJBYm4qs4vt5KAjUIpRFrIrZJCXAiB2dJaiEXXAEiCxI3cagtGFFs87SITt2DN LJHuMUmKGx0kMqNPhgLKQquUHKhDmgjryiCsapOLmtk2IkkKthaS66wkKETpANQWEnPFuWRM saMxuUTrSozElI1NtL60Z4tWVDtsNhqL5DMlDi8c/mDKmxJqY8OnmKqtTARY1EhMk0C6c1G6 IluzzIVIMknMj+DUqEuRFGX0pI1IiZTFSemi8zCU+mT1ooFCnIyor1L8KiGLECO0sRQXdJXX yxyjqlBaJxs20IsmZKkjuELF6EUQM0LALbjiem2hkKxFqaMtmVXrnrWwXXbSjEwsiUJpW7Sn lS2ExAjGVt+tNbNcc0VSrKPIQhRRjPS9qMLGklwIwg2jXLIlsyTiNt04L3rxzjfXrBMAh91i 62B7OnKz3WrVqjbhLiG2p+GLMN5i2osSfrfBrp76jbKBnhItLLJiXrBJwpRMcKEmJ3rot8ZY Y4orw2JKa9GM2WxF0oxa/nG3Roc53vLb0wDYElpGiwb5Ii3t4RQjplO9dN1VlU6ZT38xGmgq gwpCiiuhfrKHMMEq/AnFBLVqCti2f5ry3iE3SstRwE8V9+TCQ6aa4Y0Dn2uLqjOyFEeuy22J 21BVtBPPyY8u+8Cd0T7oWGNtTUowWY39V8mkhOKqItdjRiDvn2ta7VuNVmP60ZIjftRwjSXC WOHek101NhUTh3ZDs3SHy63hvzwV2+E7Z/CqjPjNiiqgLOoKaNIpXBmixSJsqLDxgR3LpS6v lIL9uSwid2PfFZ+LrXPVR57js9if7eON4+8RwtL1KItRz0Fwy0jO9uYUsdzsVRe5GUtwBRnY /oFmIeUT1mF+ojZkSdA1bmpfv8yShMeZhV0ZMUtkTLQ1xP3NcKxBwAfjMpt7vIhH1DphnaYV PFVNz4A/tMlvXJgepg3ROlsAGxCVOJPl2EcKPtQOSYy4RCpihDr5gWJ2OFdFLnbRi+75wRfF OEYyltGMZ0RjGtW4Rja20Y1vhGMc5ThHOtbRjn3J2R316KCGuORsN4kXY/jiiynWZE+3y1GJ bLTHNnZGdaBzEhO74iu8YK8nCFAT5+DUJjlljZFmrFUkMdIQQeVkAEPDI/rq4qlRHW5zZPsk GtvgC0sW63sTJEvbKAlBzxQrlwRBii2iwgKyTHBKtTrWI2UiBW/l/69GZ+mdsmITyzXm8V+C RBK+qlLLC6LuV/S6l0Ei9BtBAqxgPVnNRj7Wv465kppk9ApjYoaQmVGkZgSJYEoQGBp7soxY s4tn7E5ZGbXZBZYoZEvXsLbFd3rxbADT5dsUIrddtaFuLBkoRuBG0bRZcaKQ8Vs3S2mXyFWO cJPLYkO7+LkEbjN0pxOUOTdCmILCdG0YgZJnvneRfeLlWhRSHuVq50yVipGbgeSeUkQHnI2Q sqXby55GneK9BEWogzmxnVrY+b5OMtRAuygqTqypQQYCy4FMzac+VRk36lQljwjoTL82iFPz pQ+d8guhPWoITRjKMKwqFaJvxvpXwjqnif56KR+9CrtY6FyRLxMsKGMlO1nKVtayl8VsZjW7 Wc521rOfBW1oRTta0pbWtKeN4xcekI8H5OYV79hIPmTL2i+85LUXucIV+PIF1r4CI7etzWxr i1p73MA8r5jtbG9zhXzANiPvSK5sdcsS5jrXHrndC29l29qFVLc20J0td4lbHuku5B3DDW4+ NnKKfJzCvLJtCXzTuxDfLkS+tGEvbO87XvGwd7oYkW+A2wtf2bJXvfZ4B3PzUd8rfMHA7r2u cjPiXXsgV7wKnq6CD6zg7jq4wBc5xWpZm+H/xvbAuJVwgeWr3f82+MEgFvEDShzhd0B3ugK2 74FtzF/oUPgiO/62Rz5uLNwgExm8EtawgIWskeh+uMjlffKQMxzdhRhYwtedcUaQu+CLzHbI sq1tdKec3CpTOSPR9S2Ql0xjNvPYOfsts3uhW1vw1rfOF+GtfrmL4wrnA70Aji6EeRvm4SIX vYbOcaKLrN8Tw2TLzkU0gmVb30Erms+yZTSTk6tb9srZz3FGbpbdfBw42yPPknYve9GrakBD ecdA5m19MQJrLttjtX0WdK3t0WlJ61bN6o30TFi7kFiXGb33he+r1wzfYL93yKZuLqrfq9po j7o5zB0udIucY9/yOs6AzgivvX1rjXg7yHtWL3PrS25ic1nc7aUvkWNyCtiCdyHsNv/3ij/9 bghv+dPh5vKWt11kWXvZ2s45cnmbDFsf+zjC9z31qZ/c6DazObrOJTObI15tW6+5u1egB0tE DOYcw7fhZt64dVcr6iTDe+F4xrSb/wCdBJO8zwM+8H5Lvdpjb/jEWxavop3d5yvkN97DHrh8 mTtrA+NW1D8WMYRv3lo4K7jn3W30O5p+Zi/Xd8tbj/fTD75GezOn7DgBr3XHzkbt2tw4bf/3 TeS99jbWPO7GsfufbSJkqdPd738HfOAFP3jCF97wh0f8XnSReMY33vGPh3zkJT95ylfe8oUt 5OU1v3nOd97znwd96EU/epckgPSnR33qVb961rfe9a+HvWj+7xB72tfe9rfHfe51v3ve9973 vwd+8IU/fOIXhx8ZOT4/lL/85Ldk+fZg/vOZf5HjQ5/60J/+Qp6/kepz//rI9z71lY+R7CN/ +9Enf/qLX5Pua1/97k9J+78Pf+vXv/r314j888+S7utf//UHwP6bv/lrvvCjv/WTCflrvwXk PwMMQPgrQAAcwP37v+aLQOvzvwO0vwmUwPGjQA5EQJdQwPeTQPDbPwKEwAc0wfgrQfezwPTL wBLEPw3swApUQRAMwQlkQBzUvhEUPw+0vwXcvh5kQRt8weuLQR8sPxJEPyTUwRxsQCYkQRYc wBncQAGkwvfLwCO8wRRUPytkwhj/3EAohAkfPMD/W8EOpD/8w0IH7MEhTMEZbMLvU0IarMH8 yz40JMM0VEMerEIt9EIw5MMuvEErjMA2RMQTxEBFFEQ9zME8DEMg/ME0ZEBDxL7zk0QUBEQv DEIFlMQd/MH7g0QIPL89NMVTRMXhiL5VZMVWdMVXhMVYlMVZpMVatEVZTMVc1MVd5MVe9MVf BMZgFMZhJMZi3KNxMMZkVMZlZMZmJBp3QhmUMY2TugnLkUaduMaXyEbzcKe62EbN8YuruR3A wYtvZI6EicZunEaNmAfaOZy0MEeaiMfBmQ91zAl7zAh8RKd8JJq70MfnQEe6yJG5wBFTQYvY OMiCREiB/yQcg0xIhJSc+dEYU5kmhzTIgkxIglxIhfSdRNpIebQczcnIh8xIdMETjYRIjJxI krRIkzxJhzSchhTIk0GXhqTJd4TJmKRGgkRJnYzJm0xJknxJlBzJqzHKf3SJgJymitxJhnzJ iJSci5RKaozKwmGWqWTKpYTHk7rIrHTKfPzKrYRKeQRLl5zJmgRKkQTHszxJmnTL6GmXtZRL cExLtTTLiBQXqrxLupxLtvRLfkRLkxTHvoRLuKzLv8xLbITGsGRMnszLphTLrJTMlgyVq+RK p4zMzGzMgzzKssTKanxIs+TJw2zLmUzMgXRLwRRMziTNtWRNwOxLnTTM1JzN2P88zZuER9ws ybfkTdUUyddsy5VESpZQys+0zPkRS83USsb0SqvEyapsTuiczOf8yY68zGpMzb2kTbk0zeD0 Tu20S8RsTcNky+30Tb5Ez8TkS/W0ybncTleyyr1kz8D0zvJET5wozutczqXcz+TUT+X0T89k zgA1TuaUTImczv1U0HF0Se0UT7Tsztukz/hUSwmtz/P8S/ckz96My/OUz/XMTu7kULsk0cIU 0Ql1T9AMTeVczq5UUI3UzK5sSf7kyI8kUKKEUZmEytBM0I9cUES6yomUz8Es0RrtSRPdSPbc TRutTB2lS6EE0hCdzySVUpZUT9G8UiQdzdV8zOFslXn/DA4vnSMKTQkxtSww5Q0zHVMeZVBn dNM3hdM4ldM5pdM6tdM7xdM81dM9bQ9D+Dw1NQ3heEeZEFNAJUdt/A5DJVSynIlBvU91tM9D bVDxUNRGFVTYRFRLtYt/rNTh6NRM5Qv4rJykBFVP7cyFnNHTLMq05NGi7FLnPNXgXFUfXVIm 7VKVpFWKTEkqnVSf3NUc3VAhtdVb5U4rrU4frVFcnc/2xNFb3cqjJFPHVEgYfUpqrUnOZFY2 9UbSNFELDdbf7FV+9NYOvVCtJNcMrUsHPdELvc1xvdI2Hde4fFd55dZ6RdF4bdN13cnWTFd2 zc5gtU/ntFcS9ddwxUbYPMvo/4nXV53NxcxNFH1Pa1VXJX1Y2tzS96zXhb1P8yxXaoVP4HzQ gv1OVE1RZNXYSaXYhtVXjkXSBo3Pk73XEN3Wcw3PlS1ZEKVZfF1XKb1Ld0VYTF3Zdn1LcbTH LLXZgB3YkA1ZlP3XpoXYecXXha1M8zTapoVZkf3Un5VQhR1Pqs1Xn3XZrhXXpMXZoCXbpZ1Q RzVb1VRbpV1brE3Rd4VZsH3SmIXXEVVZsq1bnfXHU+1WK31MIz1Wn0zZlTxWYg3Koa1Y5PTb 8dRVwOXZsvxVV5VZXu1YaCVMxO1Jk4XcJ9XV33xWx/1cZd1Vc9XNV0VOjpxXT4WOrMUOClXb TR0P1//FT3LtE9otx/qQVtu9K/LAXRX9XT4V3uEl3uI13uNF3uRV3uVl3uZ13uetx0W92eoM XoN1Wm0lWVHtx+3lXphI2HME2lFVWU4FzzEy09Vl2lAl1X4t08qVXu/ti0gFyEUdX03d2PTo 3IT1W4+kXJNlW4Z81tgFVoyc0cnNSduVX3gdyWSFSI9V3VlN0vYUVtPM1lhtVaFkVtxU1liV VXrtTczEVmusXtZV0p5lVbslWN9sWajl3cDkWhRG17C9X5alT94VWMA02mV13+4EUbqNVrzs WrolzvXVUo4NX++4WPJ0zNdU2CTu1QjFUJmVWya+VyceyMVFX5pVYUmtW1//ZVjbJE7WLEyQ Xc8j5VAdruJa5WJy5OFvxUk0dQ6KNWKcfWGvHdvv1dBDzWG27VcL/doW1uIivVsavlkMbl8I heGy/dk8hltoHFXx7WBGLl8kZt89duFETs/SjOJwdeOa9eGSJdMUVtcuxuFA7mRRlVugrGO3 TeVNrlC9tV58hGJBJuURzg1gbdjGDc/PDVxT7sh/bVKV/FsLhmDD/VVJXVbLvGFY7eX8ZWAq HeOKleALJtLShd1ZxV5cRWaLBeVsBo9Qvg9bpmT3vVTK2txwLpBzLg5xht52dud3hud4lud5 pud6tud7xud8pj3YBeRAtV8i9ucZpo3q7UbypZ18/63d6c1khD7iQy7VRw7o7HBkvSDoeyTn b3ZoiP7nvchipCza913fh0YOY0VVJw1KbI3gzI3SDT7gqhThsARd6hXjKtVcYrbJAPZVmcZc YybpN+7p1czVqa1QACZqsJTREP7YA+7fCTbSVI1pJm1qQwXbVY5NvLVZE8Zkfq1qXq7qch3H TwZnt2VjreZbpE1hHs7qmqXlH4bbRW5rE75arkbjkY3oE6XqROJn3pRJZmblzY3hKf1i7X1l ozZr2ZThtLbcvz5dHQVgtd5dWNbkFXbawWZXXr5Y8ERN1MRUS6bsi4bfnOXjGpZhfq7NyH1q SI3bDzZtr21bRX5U0OZSrf8l6z6mbcpG68sd1DYe5Q9N3Cde7dT2YCn25bnuZ+590Lu26i7G 41reWVAGbrU+Wr2W7bQmbfbFaq9+W7NG7re9Y+hu5c4uZIyFWLgW24mV7sOeRmIdZsQ13faG 1ZUe1meOYRt1WQ6W5sFR6v2d5sz1af4m7KjWbi7N0AFvVZZVbBUmY0SK6vLdTZIGYur94Ja+ DXY+aM9mXeMA59kt7ty18B+icHeE49oIcY725m8u8XI8cX1W8RVn8RZ38ReH8RiX8RmnceHg ghpv52/88JC+ZdktZ+xU7e6NZZPiaDsWacHeYXltVu0Yzk6Vh33sjazdcYb+59jlcZHucCBf aCz/p/Iy9eNJzoup0ekNhWDKRWNDLt2T3mlW1e/DPW1q1tyhLGrBleBpVVxtPlyhvlZbHfOx xGFs1uWn3mamhElVPeo5j0bwnvKWxWRUPuOhHVLrRWy5DmSgvmrn5k/O3tc/RmzrFnNRbmvU 3uqz1cavpOXoZuuCHurRFXEEv+8ptVxC/mJSNtyyNmzX7F8WPmwnZWs5z1u3Luz+3nLojvWu ZlDArm1QV2Vi13RXLm0+tvKBDu1Qv25ZF24bhuzprU1Yb23xJljO/u0o7vbdHm3z1mJRR3bR rtqxxmNHnVvePvaRXfRpF2syf3Rn921vn+91p/br/mFYz2OA5+TsrvRQ/5bsRvdzgPV34Bbq Ih7bpw3uMT7XSC1hinZ1ArfslnZqN5fvBPfrCbbpXP7WoN52jLfYN/Zirq71ID1jXld5Xef2 kLfmDl3hxhZmDH75yfb1wZ3yNOp5+Ph5gb5wKM+soG+PoDd6Lq9wHGf6pnf6p4f6qJf6qaf6 zvIBYuyBqtf6NE/TxfVGdQ7fBNZouvbHRmV1Ks9wk/poEvdSWW7oUh/xcSaOtCf6K89ytz6O Lxfy9xX1ML/7QtXypI9yoyZgZz3dnN5sB6fgbHzvaV3gJR/iPe/taH7gQ498Yy7Nm0ZprudZ XK58B0d7iyxgCmbpOt/sz+9zJh/rzv5kh4b5kf4f5O+c62hn7ROW/SBO8kUm2tPv6Idfa2Lf 2I/uVkhP5N4n9fF+XcLd4oXP4k2W2OZn5KrFeOFf7Mg2d/BeY2P/9Z1f4wEX72hWdSBtd+0P WrB/WSvW6uTfWng3eVJ9d0lfd4XnW99HWrS292m/fCOXZLIHWu/HaqoGCHsCB9oDQFCgQYQF FS5MuPChQocJAVBkePCgw4YYBxqUCDHjxZAiR5IsSbIjx4cTCaKMmBJkQZgaXTL0WBOmTYgz VX7sGfNiy50oh7LsaTPoRJAejxZNqRMpQqVOmVpsufKoVJozr04tunTjzaY8tULFavIs2rQs K0atuLIh25hup1LMKf63atu3cjPiXJtU79W6HAVbFKsyLlaJbKkSLtwW79O7g2/yBYq48U/J b//afZx3bMfGlfd+lly4Lt/FdAE7Vev6NezYpx3LlilTttrbuHe35g1bd2/fwYWjHQ2U+Enk ypeLRE279nHmJoFLL179LPXnvLNfJx2S+/bu4seTL2/+PPr06tezb+/+Pfz48ufTr2//Pv78 +vfz7+//P4D3mREggQUaeCCCCSq4IIMNOvgghBFKOCGFFVp4IYYZarghhx16+CGIIYo4Iokl mkiicTolp+Jr1FnlFXnA6cWcbi4O11x0YO0G3o6G2cfjf6nduCJ0yc0YVHfcAdlikSziiP6d b0vGJmV7VLJHmHOl0fQXXm5hiZiTZMW1FYx+dSnaYmimKWSWmG11mWKcYRTamKRlaVppa9Jp m56D1almXn0aJZiXcN52p2iHcemdZgSW1duLZYL2XVRGaudjjlz59BKnWoHV2WSbkiWqUDp+ NVtNRgV3aqmtPcoTq0eqql2slUY2qqT8OVdrV3K2mppqll467F45JfbqWJ9i+lGbhJq6UWfG FiuWpqUSumunt7o6Ka+V8ZrptNp262x/tdrFFVNU+SQjokQ++eyo3/al4rz0ZgtZtlnNCq6i +Dr2rb1bxttVvp5R6um/XRZspXrmQjpZugSv6+O5I9mYKmsOo/4q8arbamxvtB4/jDG8IuOq sMDWcoxsqCgnuzDM/mFLWYq+iutrioOyW6eZOscJlZ08K4bnaYZ6FjKoc1EGr5xJB6uoUnCm CpfRtgLdrp9xuir1uuSe6ChJKHytY5jpMWyYrGOrXfbac/J8pXBtkt023XXbfTfeeeu9N999 +/034IELPjjhhRt+OOKJK7444407/jjkkUs+OeWVW87gDJe3DR7DVl5cUo0HM4nb2+6m5Tmx OZ4+95C/QTllw9PB/bp8SrqGepPi4T4e58TZDrvZspuHpcFfqrZos8WXXujPXe/p0pr/Csoo o1ZFb5rxmRmvNb1PN72ox1wmVrR3zf42/ybOVfvpfPl6ch0o9xoBJqibyH3V7VouV4skjh/z L2TCDrUv4yQFMhmj2ACh1b+CtcqA4lKgpFiDK6HhC2gb+5/JqtWUGR3mZBK8DmqGMjO0mQxW qqOU/zZ2qxF+BmDqYozcHjYupWUtgQ2c4LbsBMFkhXBiNWSW1/R1w59FioOTKl/LwpWz5UhF iBdkIP+GhSwLVixm+hOVQ3xQwamRLYWsSmDEApjDj+GQNolyYMLMeC9pbdBf3JKYBTtWnftB kVp1rOKfwDiymu1Lj0/c1GZGRrKBeSqFNxyiH+voshzykIHKyoq0ArnHMh7xZWFRDvGwN6an NWpq2evYsf5auMm0sVCHNPPLucB0tOv1y3n/216eDEZCNTVth0PTJCcRBb4s8QFP8dNesAID yVMCUpaFWhaEzjYfZf5tidJhJn2guR9pwoeafLsTCK1ZTc1xs5ve/CY4wynOcZKznOY8JzrT WTkyqLOd7nwnPOMpz3nSs572vCc+8zk6ts3Rks90Y8+0icw9lg54rROdQKM00NwAlHcBApVD Eyq8MDnRfqDLVT9Xl7rg/XOjIdoVoFC5vkoeDS6rfJ+bAsk86j3lkyG0GS1lORs+gQl5L0nf L0H6vpFij2rxs973TjpMk+oUJ39KFPJ6+JOlKLV2JSTgrIwIPTEScoWeZKQKO/61v0QK0Yhm seEUKfpUO351XNHxliOP+EEBjvGAb0yZRJvEVMzMdS5EEWkRg9g9usqPi0mDFLm22sO60umB diymyiISw5LtKWcvVGQsrYjWImKVei+cmUq16tHyRPJdGLyrwgR7L7Heda0H66wJEfbFLpLQ r72yIqZQe8LHUlJdiY1MabeIVdoSTLT+rNJYx0oUqL7IizIkE2KVhTLf3rarrW3kIJuLwCsG V7amxW1ah+vaP6IxqtGl7DKvlselARRbm9ErLvnFLCyOsoUYC2n7aAo+LQGrteaTaaXG5zae nq+nP9ReSdMIyDha9owBliRmN1vPuFpMQgxez4P1qf/R4Tn4QRGWMIYzrOENc7jDHg7cDz4s 4hGTuMQmPjGKU6ziFbO4xS5+MYxjbDpBTvigtqJdXLPjzNuNRqK9m7COtykstAoPojO+KD/R w9bcWYehCr7dRBX6Lkw2ucpBfo+NZAUkIzfYybGzqWauJdT1JQ+bYf5iUXkKP/4i98yhqV5K WbnUT9K3laZs5X2fZOZM0rnOu7ye+eYbqUK+N2hCGy98QQrngpLOrStL5MRC1jX1xlGSdPHg TLPLse0yzdFhJRVCLQXVti4Sf6m7GIIre1yqpvaQccsaULUM2TAGzLaMbGwboVYVYOXSht19 NNOEO1ptefY7gd0tHBc7WGD+d7nBuU2ulnxay++CWsoge7S8HChpW2+RrVv19art/GsuCti0 ZBRwqJ/FWx86iYO2ltFFn81Gf2EQh/ploshs+2l7y5HbxcRjbbdL5J0EW7nPNbdk1ciivxK6 itDFLiVbl2XkzhuLXK1qRw+MJvLOVdv1+2lzxDtUnLUVgCKPGsPnjPJUni/P+VUl2lZONTVX L6BcM1ZhLVa/W0NsVXzFJclDWWEN7Tg8FLpwhoqeIKRHc+evPrrhzCzjqVO96la/OtazrvWt c73rXv862MMu9rGTvexmPzs9e7xQL1dZdA6dXY2nxPS4k84yYmVds+tOu/zYhkYW5SxwKVwf alb/dO9I7pHho3RzpeoyqIq+N39hSbSVbrCmeaIgx322UyQOUvLppTxL+5zeYsF0epJ3+Zij Lebk3aXx/635n2mYVDnv81XMJWUELV5VAlf6U55WN6dO9W3qeo9Un9U0uf14+4tXO/eS/tUD XXjpi6+bycKP12JfpqmmTstce9a9sm96re0HX7PSJiscO91r6SdfX5T14gjT5rZ9E7/b8T+s dfuYVdehv9VRVPtr3V3JXUrv6RsnHccBXR/B9d/DURdYjZclud9bSZcEBoywlRu7ORq9pd/u LRzeeZntdaBVBaDDsYzxWVz1/VUCml/vBZwIUtuSuVvMLJ8h1QvzVZfz/yHfw4UVt0kVdtzc e+2U93wQ0QDd5fUFHmXSEU4Znx2buC3akRSfoUFRnDkN96hUSOkXzhXh/YXeHUlhTP1XfR2h oOVckvlONK0d4j0ZvgUeG+6TicwdhA2e09lPHQKee0id332NHKKdH/4hIAaiIA4iIRaiIR4i IiaiIi4iIzaiIz4iJEaiJE4iJVaiJV4iJmaiODmDJnaiJ34iKIaiKI4iKZaiKZ4iKqaiKq4i K7aiK74iLMaiLM4iLU4io93YSfRhcUgJo91irjGZ9R2ewQ1UFKmOj9Gd3hlULvqgtZ2OjimJ Ls5R6PAfMCojPy2Z22WjNu5h4iUjNebdGVrjD/+GS/cVEOk9T5qIFBSK4filI+PR0qGwEpJQ 3s/hGfvsFxkqz1F5yWPIzZuFn6K5mWWU3j5qXE5loRPuUpsZo0u9I0qJXsgBk0S64y3ZlTnm 10QWEEXO2cvlz0ZmxmlN3y/2nRgBTA6+YKR1UQ2eJGnpoAKtVv1dVVld47K8X8JxGcRopE6+ nDlukvTA2pvlD0fyI0dazWBd5FltGrn1XfOUxZ7pFWHpHknxkamh5J3xHl4pEbgwXvldTRI1 G69NIK5FJegEJVGepfgg5VN+5VEZZU+a5S2FSkFJEElW1KCBVjFSX8lkII192sC1oHQZHGhN 1wKqCl4uUpehFnMhZln/ZmRHgiRazondGaVjFiVlEuVlIqVgPodXQRAdnYxegqa+qZBfsiRx pRXMOBxYdSVfrldSLlcHmqSxSaQS6VROSiZu0lcYBk1HOiQRgSXMUYsZxpzSoF4+xtfrIRFd adluBpMU1pDQ6SNQyRTkPaeBVdxyuhesJBpEQpgv1oZm1uIJrWGBfGejmacsalM0iid7tqd7 vid8xqd8zid91qd9AqIS3Kd+qg0vQlk4ZlyxJR5JkmeSuMvunN83ruePONmV4SEypqFH/RiB gtCRwSFORpmCDh7bCSOPUSeiPSQ/Nl5YCtXmgZ4oleiXnChN6eYoWd7onV5DoqXNGOONeB42 /ykkTqlfZD3h6MlPouEZRAZkO2aeFNEkanol+12b/9kSY0nl8jEgYPbkGkHWLwbmQBoYCrlk B4GbcYkmFRLfvGBnACImgQ3j6+HaVaJkKGFhSp3gmdQjDTIP/V2WEi7bUiqhlbIWZ0IlQVkn OW7J/ZElBv7bytTpjfZWBhHP51Sgat3RagAfXJUNVjImGtXp3CQpEW4ab8kaaB7cVmqaATLj oF0RNrYm9HVXDKIq9H2OYcXmmOalxgxfp+bfGFmgBGKqbokgG/3lpAlSvcypqbrRXd7gasak qY4aryJpvB2aTxqhcq4GsiYkfpWp7FFnb6FXQEGrOrZU7FVQ6RGpVP9WWxceKuctIUPSZZCi FDuyXEUyqzBFFtbgh9KVixp+o65A6BsKXh4+aHihp37oYTNO04/coZDt63Rk6H4mrMIuLMM2 rMM+LMRGrMROLMVWLOI0KID+Vuxso3caXZSRpzTNnb+mGzcijL6Co+7g6wdylMdyqDeGrIMm Y47t0I40FVLxEP20qPAVX5+A3lMa1RX6JscFKZBWzcfJWbvEnsiZ60iJ6LZO5zqu65rpY7Ym FTlU4fNYK2hY3rQR7IrIIIDtao1OH/7QWpk+kQI+yqbm5k366qDybMI1X9waEBLqYBPBoGe5 FdhyKbWFraqNznkNISrJX61qm6POaj3Cpsr/cGWgqGS1Ciq7qaqr6un88e2dPq7bmpIwHWCu ghfPcZ92PZZq8t+3yaYTrW1gLu1hYWBmTdVeNqkWBmgF5h9Mnu7cHqvlJpYGDce8eW63LdBh gtt/huSpVlJnFm5K8pvJbiAhiRbqfu5oleDbXmDxui2uEqqXNm/28lykrm4B9pVrpRzgEtOu thfWAhYfPSsxJWcWBmHgCuXHZSX5MqvPBWcYot4xVW501hx0amvJgRfRFk2qSSbkeWv5bp7A xuwxsuzwjmcsyiHABuzweK3LWqwFXzAGZ7AGbzAHZ6IWdDAIh7AIj7At+ueWPd2UkSwaNnB/ piyAqqeNcWyFxrCk/26oesFd2/GrfxqUQDHdhc0sDYMgHKLwDFNZvhoxd4bobsJe6iFnTu5j 1nIhGIrZ5N1UPz7qXjWt0PpM8WRx1LLo1E7ekFKtExOcz6LXGIsQGfOkzLke4CHNqzopLk4u AsqR8MZtlBIaqymfrpLaAm1vCB4SrXLglpqm/gHQbTGp98otvgmt2coxt5ZmHQ8qgvav8irp Dmon6+KtX2WfJSOS9lay/Z0erHEm86WvYuHpkYYPBb/arcZxFXPavtUtJcMqHp+g2GLcKy9p 9Xmgms7g8v4u/vFulr6gahYjLdvqsEXULcOk5Obp3dayHJctKIUby8RqH48bsWKzIFPvdf8x 5e0SLmDOanC93f0qqv/W2Sd/TzIb1T2qY6CRF2udMw2RMZv2lzwaW7VaFhYj2Nvsc3Mq5CTr 2hTKZeXNV6cuFRY/VL1ODsL+YQRrzkOTMEVXtEVfNEZntEZvNEd3tEd/9H7uGDNSDOc2tM4x Uw+v7P45sA23Xanm8HksiUybNEZVowsTy++gG0tb2YS2rJHqMIUGMUzL6w5DB8wqmVekqMuR q7ku9fLoMxgzLVR/sfQ4XvxyhrrC5S/Nc4qmaaPAcY/GVJk5tc5qsYxGdfCadX+drFdirwW2 mzCjbO7NdQzT393xapm0biFPKo0+ssNEy++tpCFXFqd2c1oz6YX/vrAP/WbKjehvso18uZJk hxzm6nT2YWWqMa7JAixe82CC/WopCTbN5HG5pq6z7G6aJnbJtvXz1SXyDuh4dqmrkaodR26l JVhhDlxDQRwvR+9m1/Y9Pi/zVi8Plt8CGlJMzzXCmTJiiSlI0jYdq+XtGhZeK25bZ7M1R3er QS/GLTaUfjdvF/fuIndMW6prLnF2wtlJxZbRCF08V/XJVa56gzLFdfFCe3K5Bm6OimvPhDUa 1+ZaR6dzoqtd1Sgat/KI6OJEH8hM/90RL5PjKHjg8MjI7mKF0yFIZ7iGbziHd7iHfziIh7iI jziJD7XsPKNGieyDMzeF5lhJE/FOO3gw/990CuuZUC8oq7Y0jYtjA7vOAt94Ucd4P0Vjjh8e g0EtbwpkSd02jnqk6CFkoFGknAbt9JRx09738TQxfJ3r7Nmo0UJx5EUzjLoXYGcMlLec+nAL OiJ4bvxenvbVtokkIX936w6wWEYu9xquHhV3QtMYC4ZmqwYzBfk1JA+rIbOfnav2Dttpb59S cb3mbxHuJqdWorvvdS9yKQureXVf9EY0u945o6Mp3ZZ0WBL6ccfrmi5MF06VpSm6EOMjBRr3 /2lzBF7qnw8wYygzXA/36pYkpAr1ci+m/pXzrx4umRQe7cIWCtb3bsvssPE5+M46nidf9N36 VXl3VWK6nv81oP+HZybrNbSfZlbRagjObiPJ9vd6rqvX2P0GmK6dLchlynDac+d1slpZpztL MYFfOZjZWeKmN25HMT2r37xHMv+ueramclP67xIn1z7HCE1XcDxZ04ILuQzLdYdEdJvjEwwv qDPaa4mHfMg/g8iXPC2ugcnDRwikPMu3vMu/PBNEoju+HaQTY5LNaxsW6Emzyxz/Z8V9bK9L PNDvqE1PNYYCOQpDcI2vHcYitRum6sW/rrVROI8Pe0axO9L/RvRQcRLjo9PiVVpmOT2Kn1ZH 273vLEGO+hqr3C7PnEvhF/51eToGqJL7I72HmhvX/dl6sUBi1oVP1HIncjHT93gLZer+Dva1 k23b6nFhiqZ5q6DcYqaYU/ttFqvVVDPeL/4EkuxQOeAKf/v8SVWgZq44D3ayHles7Rqf1hZ+ E/6xnvaQaNe7J/5LHv7WwFI8wq3CX/eVbTFxaTw1Bj6LQzd1I9sthzOcz/kNiv5Aizt0fWZL Pnr3CpDsE7cd2zKdF9wZ1pv2LfPnB/44k/doEpsk/3L1gz/fjm4e0xb0SzeoX3uzPumo6a5j aT64g3PEmVXcwNy9pStAny9A2AMgEMBAewcLIjyosGBChA0XOjQIUWDEhQoxEpR4kaLBihoj QqQIkiTHjyc1emw40eLDhBMdZvzIcqZIjDRR0oSJUyXOkiv+T3pEGdRlSJ4MW+aMORLow5A1 hQq9OJVqVatXsWbVupVrV69fwYYVO5bsVKllqZ5FK1bt2q1t3VaFG5duXbt38ebVK9Pu3L1m /1712zdwYcOHESdWvJhxY8ePIUeWPJlyZcuXMWfWvJlzZ8+fQYcWPZp0adOnUadWvZp1a9ev YceWPZt2bdu3cefWvZt3b9+/gQcXTjpq07KDhydX/voscq7Ol0eXXrkj05FJf0J1uXPndO/f LQ9USRRwRpjmyY/nC559+8BAx6s3iZ58RfXyobvXv/9rfIvyk7ovwPQG5M/AA8nyD6n18KPP vpYaHArBCSmUy6abrpOJKY42Mq/+u/UqDFHEEUks0cQTUUxRxRVZbNHFF2GMUcYZaazRxhtx zFHHHXns0ccfgQxSyCGJLNLII5FMUsklmWzSySehjFLKKams0sorscxSyy257NLLL8EMU8wx ySzTzDPRTPPLLNRs08034YxTzjnprNPOO/HMU8/9IIkkr3o06ZOdizKBBJJMBj2o0EMTPQhQ QS8y1NBMxllIFEkxPcjQhfrUFAFO/bSnU3suxXRTewq9qB5IKo100lYXejSSRlHFNNRxDqWn Kkg+1TRUe2SltVRTqTp11VZ5BTXWQGelapxCM+nVWFarCjbSXkX91VJTTz000lYXNVRbTV+d ylpVmaX+FVNKqwp31EggURUSUWqVNNR1YU01VmpdPRTWfafS11FqEZgXr1UxbdTURBceOGGH MaVXVG7pLViTgwqmd1WJMwbW4IlNlZgdSHT1WOKFCra1V4QlVThie3CdlKqNMf6YZUNdDtlc gxGI5GKTa5b4ZkgarQdee4Hu+eedHwbano6n4tbgY/dl+OWLUrZ35YYhxrlrQ0/m9OpL61lI X52H/njkkmnG2tRIsK217IXWHlhkovEytGx6Rl110FX99NvjeyHZe9SRE0U46kzkFZrakZNF 3B7JI2Xc7YtXXXohvgdFIFBkC7eH70ho8ZjWiT+d+yLIP6Vcb9FHrdwqyTP/gfsg1ifHe2LD f4VXk08RqJR224sNffTbDW1d910tR151XMsW3CrOn/6cXN7Fxj73xE+tmirKJZeebt0VfxoS zM+ninrP+c19efPRXxr6u0aG9dSR594Uf3Jztz9eUpMFu+Z57F/gw1up6DU/ssnrX4oiWZ/i dpD58a9+YnPeVOAVwW0ZbH4V5B8DrXIpekwQgBwMnQcnhjzNHUSEJFxd+06FQJiFrlrtK6Gp lKc6Z9EwhSi8Hwz/d6le8W2AudOh3TRluf1dRIgHIaLZHki8i5Cwe6z6GBRHh61L4SVQ2Irh /0Z2sS3m7mJdtKA9jtY0CfJwhiWbH7xGhoAxwmsq/i5EXvKqEihX2cOMHxzW/2AXiSMeBI68 GmMfUzhFNl4EXpeiVSHl+D9EnipQg2zk+y4yyf9BcoxVcWEaM3VDQGZylJvS5EFOiUZune6P UfPTAkW5EFB67Y4BnIoezygKP8WulnFL3126ZzFyYaps3ComIIUJspYFbJQA7FUTOxWJS91r XAJz2yKVVTPGBfOXV3PYIKM5zQ/Cj5lXwdS/wjkqbv6se/2y4R5rxk4/SZOX5ZRd0IZ5xUj9 qmDbRGY3/8lOrrkzbKrk28m8ucprDtJXKPOW4HDp0EWSLG+AlFzWWAW8c0rLonhrmx29RagA bopmkNOYPkVVRE6pFJ8s/sRb9y76S6r0c2f0Muk4KbdSqyBME4Xamk3BhlPdtTN1huqpLeG5 PaDd1CohHRisqJbMqkANgIOC6VA7+reP2VGqUxmWQ1f40Ymy1Hwnc2St1nhEp3IqL4XSFd/+ x7cGypUqboUdGHVH0301EI9hVOrEBpVTAtawgePrnDhr9dZTUW91Gm2m63RnV7jurLDIC5za sJooyXbPek/z08guW1AHKhavVjvdXl/YKMkxtioXRexmAQlb5CVKr5vD5PiWx9rZahOErcVb JD+rUNQaBnKSmpsd7eg+47pUdbCc4RHdFTpYKpCNyX2uVWImqWjV8nUzRFq9DNXA6dKwuN1d /4h1AViyJo53buXl4dDoJUKXatC9c2Mvdtno3CZmt57e1W6v6ovb5QKwudW11c4GyN9Q6ZeH 6OXvoT4lU6peN5MrrAs7fKc6azpwdhmW5SipuuGnxex3hPynie1Z12aKFGwlo5uHHSgpoRWq WRg88YvPN0gRf7hXHaNjzVYH42WF18Q9RunthPxj811lw0pWZYyDyswWTwXDOaZykkGsT3eJ lo1bRrFDT7ZjKItCvUjlpYg1YeE9rZnNbXbzm+EcZznPmc51tvOd8ZxnPe+Zz332858BzZn+ PgZXmXAxsNKFlVVFrVxi81dTxzWqP0qqoSGU2pBrrOLenmuc6tRuZf7xtTNGP1rU7mRXsbz4 K04nkm8tnVkzbelpUhfPif+b8KKZeOnzQktaA3xntlzKrR0aGl2QKrWjZz1hyGS3eUM7LRRV h1EImk9lNW1cPmXstF1R7GvPrpvTnB1PfKatoOQWabTfFrdCqc7c1y5rtxeCS33hSoMOZPfH OiZtKcb7f/NG6rrdmW1ggfKyUMVk26RWUGbvS432ZvjVBAsZPKrudcfzbW5/a731ddawqV2c x7Oy1t0Fcqrpy1z2SA7ux5GvnX8tn/satfH2QU61LH9sX7GqPWemTFOivWPNI4c3mRdWiDwX Vdhozjwblzh4RjzvIiMucrGlDuUW/3nHPf72P/QyJoMv9F9TcXUyKsZr7F7NLxupti2G9hZ5 X29XFAEMxN0qtYkCNPsQnWpFsfOwimHfFt6LKMMOyn2NwUsevcF+RcGHrux15FXMDO9Lv1P2 hRaeNB5zrcO0U6Xr43O7pibvzFpbrpOSGZ3qUunVXf4qoilsfcud/GRF6jD2nmRj6qksKWyl ElduDN0sMQn8ROkS2KgsZRBX/+GBmjiOh4x1R40GvSOzMPnMN6Qkj/+9wkVC+mEjfn9dWEnO 65qRzUTv6fntRUB+v3fClelkEJa/gL56UBGNHU3vL/J61nPDg07xOLtqoZIqmeoOmpYP21iu /gAp/xgHohbwAP+BjZ4IB6zGRxMEaV6Qynvsb54QiwG1zwI3xpYcUNOS6p7ezZX+79VoaJ0G RgGRjZZE5dAmQ6+u6rT8rWyoypFy8H3aBolMUNvMqYhqMAgZDet8in/E6oiSkMOuawcH5Qad xo5KKsqG0GHYIWV8Dq2uawp5RvFuC2GuMMqYEKSEEMQG66ms7QdLznKqEAqXUFMq4wqpbbTu SvsaxrU6BQ/HRbAEa/P+6ir8MLHqcKfeSbbIRXkuhnJqa+5oyr3wRg+Va5kUUeQgS7MoarIk itrqzREDK7OUCrhKLl5SBls4ke2Mr1V65g8jrg9/7XYciw4xsRQnkawiw11aJcCiZmniOubB tosXI+iPXsnAdAgY8euIcNH2jNFUNEwZCUztMk/tJMyE1iXCdNFgGGwYaWiCjtF8kCULozG+ spHxTGW7Zopf9OkbZ49pso3BflEYrcIWuWsFqxEcC6xs0qwy6oHGaKXKNGGQ6q6hwoXMoGjK xi/bYq/JvCkFkczKmGzFJkfIRsyoesXJJowi+8TM/CQgy8yX5inLwkbJCibIGPJaPKUq/jEC b0wjsWKktAgjRapaAoVfnKz2DtIhHUUfRbIf52ufZA+f7jHQgDIohXIoibIoo+QejDIplXIp mbIp4ywgAAA7 ------=_NextPart_000_0003_01C6C407.9F88DDC0-- From owner-ccamp@ops.ietf.org Sun Aug 20 23:25:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF0Pk-0002XF-28 for ccamp-archive@ietf.org; Sun, 20 Aug 2006 23:25:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF0Pg-000307-Gi for ccamp-archive@ietf.org; Sun, 20 Aug 2006 23:25:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF0MS-000GM1-2B for ccamp-data@psg.com; Mon, 21 Aug 2006 03:22:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF0MP-000GLT-DC for ccamp@ops.ietf.org; Mon, 21 Aug 2006 03:21:57 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Aug 2006 05:21:55 +0200 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR1a); id 1156130514810; Mon, 21 Aug 2006 05:21:54 +0200 Received: from ties.itu.ch (ties.itu.ch [156.106.192.33]) by mail6.itu.ch (8.13.7/8.13.7) with ESMTP id k7L3LqkA078275 for ; Mon, 21 Aug 2006 05:21:53 +0200 (MEST) Received: from localhost (tokaj.itu.ch [156.106.192.34]) by ties.itu.ch (8.13.7/8.13.6) with ESMTP id k7L3Lqi2031916 for ; Mon, 21 Aug 2006 05:21:52 +0200 (MET DST) Received: from 156.106.192.159 ( [156.106.192.159]) as user jingr@ties.itu.ch by gold.itu.ch with HTTP; Mon, 21 Aug 2006 05:21:52 +0200 Message-ID: <1156130512.44e926d060b39@gold.itu.ch> Date: Mon, 21 Aug 2006 05:21:52 +0200 From: ruiquan.jing@ties.itu.int To: ccamp@ops.ietf.org Subject: RE:Polling for new WG I-Ds MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 156.106.192.159 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.4 (mail6.itu.ch [156.106.192.22]); Mon, 21 Aug 2006 05:21:54 +0200 (MEST) X-OriginalArrivalTime: 21 Aug 2006 03:21:55.0591 (UTC) FILETIME=[F433B970:01C6C4D0] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Yes to ALL. Regards Jing Ruiquan China Telecom BRI ----- Original Message ----- From: "Adrian Farrel" To: Sent: Saturday, August 12, 2006 10:56 PM Subject: Polling for new WG I-Ds > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas- 04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs- 02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown- 04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > > > From owner-ccamp@ops.ietf.org Sun Aug 20 23:46:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF0kF-0000v7-ET for ccamp-archive@ietf.org; Sun, 20 Aug 2006 23:46:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEzM9-0000tB-LD for ccamp-archive@ietf.org; Sun, 20 Aug 2006 22:17:37 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GEzCR-00012Q-Kf for ccamp-archive@ietf.org; Sun, 20 Aug 2006 22:07:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GEz6I-0009Qx-G1 for ccamp-data@psg.com; Mon, 21 Aug 2006 02:01:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.53] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GEz6B-0009Q3-KN; Mon, 21 Aug 2006 02:01:12 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4B00IR7SEXVJ@szxga01-in.huawei.com>; Mon, 21 Aug 2006 10:04:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4B000FLSEXHO@szxga01-in.huawei.com>; Mon, 21 Aug 2006 10:04:09 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4B0079GSTX7V@szxml04-in.huawei.com>; Mon, 21 Aug 2006 10:13:11 +0800 (CST) Date: Mon, 21 Aug 2006 10:01:00 +0800 From: Dan Li Subject: Re: Polling for new WG I-Ds To: Dimitri.Papadimitriou@alcatel.be, Adrian Farrel Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Message-id: <004a01c6c4c5$a64fb200$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Hi Dimitri, Please see in line. Regards, Dan ----- Original Message ----- From: To: "Adrian Farrel" Cc: ; Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds > adrian - see in-line > > Adrian Farrel wrote: > > Hi, > > > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > > > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > > > has been updated by the authors to provide further details and > > clarification. > > - ok - > > > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > > - guess it is v03.txt ? - > > > has been updated since the version discussed in Montreal. > > i am ok in investigating the MP->CP but i have two concerns that imho > should deserve more specific attention to maintain consistency wrt to > CP->MP > > section 2.2: if control is lost for an LSP (during CP failure) how can it > be possible transfer that LSP from the CP -> MP ? [dan] Yes, there is a problem if we still want to use the control plane to do the CP->MP transfer. Unless the transfer is based on the predetermined policy, MP takes the control of the LSP resource directly (no signaling required), but this way should not be discussed in CCAMP. > > section 4.4: why the document assumes that both MUST be supported ? in > part. concerning the CP->MP if one does implement current GMPLS signaling > restart/recovery why shall this be mandated ? in brief, the document shall > take into account existing mechanisms and prevent overlaps (with existing > GMPLS mechanisms) > [dan] I think the CP->MP should not be the mandatory requirement. > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. > > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > > > has been updated as Zafar says in his previous email. > > informational imho - in its current version > > - not sure to understand why the PathErr/Notify can be processed by the > head-end only (what about segment recovery and stitching case) - why only > MBB is possible upon reception (pls use E2E recovery/Segment recovery > capabilities as you address GMPLS networks) > > - compared to path-reopt, error description is identical for the TE link > case which leads to the following point - if errors code/value are the > same how to distinguish them (assuming that the query procedure described > in path-reopt is used during the setup of that LSP) ? - comment is more > for the path-reopt draft than yours but since there is an overlap ... it > must be addressed in a way or another (note that when fully head-end > driven operations look similar but there is a major difference role of > timing and severity of the error code/value) > > - in case shutdown of a protected component link (of a bundle) is > initiated why can't link protection be used ? > > > Please send yes or no for these I-Ds. > > > > Reasons and opinions are also welcomed. > > > > Thanks, > > Adrian > > From owner-ccamp@ops.ietf.org Mon Aug 21 00:12:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF190-0000sh-Fb for ccamp-archive@ietf.org; Mon, 21 Aug 2006 00:12:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF18y-00031T-GV for ccamp-archive@ietf.org; Mon, 21 Aug 2006 00:12:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF15F-000KOd-IM for ccamp-data@psg.com; Mon, 21 Aug 2006 04:08:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_40, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,MIME_BASE64_NO_NAME,MIME_BASE64_TEXT autolearn=no version=3.1.1 Received: from [211.94.36.20] (helo=mail.chinaunicom.com.cn) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF15D-000KOJ-1C for ccamp@ops.ietf.org; Mon, 21 Aug 2006 04:08:15 +0000 Received: from Nwangjq ([211.94.36.208]) by mail.chinaunicom.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Aug 2006 12:07:04 +0800 Message-ID: <00ac01c6c4d7$42ac7910$4f1fc00a@Unicom.Local> From: "wjq" To: "IETF" Subject: =?gb2312?B?cmWjulBvbGxpbmcgZm9yIG5ldyBXRyBJLURz?= Date: Mon, 21 Aug 2006 12:07:04 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01C6C51A.50C38410" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 21 Aug 2006 04:07:04.0108 (UTC) FILETIME=[429A9EC0:01C6C4D7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C6C51A.50C38410 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpZZXMgdG8gQUxMLg0KDQpSZWdhcmRzDQoNCg0KDQoNClNpbmNlcmVseSBZb3Vycw0KV2FuZyBK aWFucXVhbg0KQXNzb2NpYXRlIFByb2Zlc3Nvcg0KRW5naW5lZXJpbmcgVGVjaG5vbG9neSBEaXZp c2lvbg0KTmV0d29ya3MgQ29uc3RydWN0aW9uIERlcGFydG1lbnQsDQpDaGluYSBVbml0ZWQsVGVs ZWNvbW11bmljYXRpb25zIENvcnBvcmF0aW9uLA0KTm8uMTMzQSxYaWRhbiBOb3J0aCBTdHJlZXQs WGljaGVuZyBEaXN0cmljdCxCZWlqaW5nLCAxMDAwMzIsQ2hpbmENClRlbDogICs4NiAxMCA2NjUw NTczOQ0KTW9iaWxlo7orODYgMTMzMzEwMTY2MDYNCkZheDogICAgKzg2IDEwIDY2NTA1ODQ0DQpF bWFpbDogIHdhbmdqcUBjaGluYXVuaWNvbS5jb20uY24NCg== ------=_NextPart_000_00A9_01C6C51A.50C38410 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI5NjMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBzaXplPTM+WWVzIHRvIA0KQUxMLjxCUj48QlI+ UmVnYXJkczwvRk9OVD48QlI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+U2lu Y2VyZWx5IFlvdXJzPEJSPldhbmcgSmlhbnF1YW48QlI+QXNzb2NpYXRlIA0KUHJvZmVzc29yPEJS PkVuZ2luZWVyaW5nIFRlY2hub2xvZ3kgRGl2aXNpb248QlI+TmV0d29ya3MgQ29uc3RydWN0aW9u IA0KRGVwYXJ0bWVudCw8QlI+Q2hpbmEgVW5pdGVkLFRlbGVjb21tdW5pY2F0aW9ucyBDb3Jwb3Jh dGlvbiw8QlI+Tm8uMTMzQSxYaWRhbiANCk5vcnRoIFN0cmVldCxYaWNoZW5nIERpc3RyaWN0LEJl aWppbmcsIDEwMDAzMixDaGluYTxCUj5UZWw6Jm5ic3A7ICs4NiAxMCANCjY2NTA1NzM5PEJSPk1v YmlsZaO6Kzg2IDEzMzMxMDE2NjA2PEJSPkZheDombmJzcDsmbmJzcDsmbmJzcDsgKzg2IDEwIA0K NjY1MDU4NDQ8QlI+RW1haWw6Jm5ic3A7IDxBIA0KaHJlZj0ibWFpbHRvOndhbmdqcUBjaGluYXVu aWNvbS5jb20uY24iPndhbmdqcUBjaGluYXVuaWNvbS5jb20uY248L0E+PEJSPjwvRk9OVD48L0RJ Vj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_00A9_01C6C51A.50C38410-- From owner-ccamp@ops.ietf.org Mon Aug 21 00:45:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF1f2-00039R-Cq for ccamp-archive@ietf.org; Mon, 21 Aug 2006 00:45:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF1ey-0003BV-TI for ccamp-archive@ietf.org; Mon, 21 Aug 2006 00:45:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF1a1-000N2h-Gv for ccamp-data@psg.com; Mon, 21 Aug 2006 04:40:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [192.26.91.6] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF1a0-000N25-CE for ccamp@ops.ietf.org; Mon, 21 Aug 2006 04:40:04 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id B39A8EC8CD for ; Mon, 21 Aug 2006 13:40:03 +0900 (JST) Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [2001:200:601:1a00::10]) by mandala.kddilabs.jp (Postfix) with ESMTP id 72033EC881 for ; Mon, 21 Aug 2006 13:40:03 +0900 (JST) Received: from [IPv6:2001:200:601:200:54b8:3503:bce9:108d] (unknown [IPv6:2001:200:601:200:54b8:3503:bce9:108d]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id 6DC451E0002 for ; Mon, 21 Aug 2006 13:40:03 +0900 (JST) Message-ID: <44E9392A.2090202@kddilabs.jp> Date: Mon, 21 Aug 2006 13:40:10 +0900 From: Kenji Kumaki User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds References: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> In-Reply-To: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi, Yes to all. Thanks, Kenji Adrian Farrel wrote: > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > > From owner-ccamp@ops.ietf.org Mon Aug 21 00:46:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF1gK-0003JH-Vj for ccamp-archive@ietf.org; Mon, 21 Aug 2006 00:46:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF1gJ-0003NP-N1 for ccamp-archive@ietf.org; Mon, 21 Aug 2006 00:46:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF1du-000NNs-7o for ccamp-data@psg.com; Mon, 21 Aug 2006 04:44:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [192.26.91.6] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF1dt-000NNh-Ks for ccamp@ops.ietf.org; Mon, 21 Aug 2006 04:44:05 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id DA410EC9D8; Mon, 21 Aug 2006 13:44:04 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id 936CDEC9D3; Mon, 21 Aug 2006 13:44:04 +0900 (JST) Received: from [IPv6:2001:200:601:1e02:0:5efe:ac13:570d] (unknown [IPv6:2001:200:601:1e02:0:5efe:ac13:570d]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 29E75578103; Mon, 21 Aug 2006 13:43:42 +0900 (JST) Message-ID: <44E93A1F.9070608@kddilabs.jp> Date: Mon, 21 Aug 2006 13:44:15 +0900 From: Tomohiro Otani User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds References: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> In-Reply-To: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi Adrian, I support the third draft to be a WG. Regards, tomo Adrian Farrel wrote: > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > > From owner-ccamp@ops.ietf.org Mon Aug 21 00:57:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF1qQ-0006QE-5I for ccamp-archive@ietf.org; Mon, 21 Aug 2006 00:57:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF1qN-0005vH-NB for ccamp-archive@ietf.org; Mon, 21 Aug 2006 00:57:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF1o6-000OUD-82 for ccamp-data@psg.com; Mon, 21 Aug 2006 04:54:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF1o5-000OTw-Dp; Mon, 21 Aug 2006 04:54:37 +0000 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Aug 2006 21:54:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,150,1154934000"; d="scan'208"; a="37125326:sNHT23694260" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7L4sa1V007516; Mon, 21 Aug 2006 00:54:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7L4sZuI015602; Mon, 21 Aug 2006 00:54:35 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 00:54:35 -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 Subject: RE: Polling for new WG I-Ds Date: Mon, 21 Aug 2006 00:54:33 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbBhBs3k4XBWtGvQXa/gCA1S1uQsADWKUAg From: "Zafar Ali \(zali\)" To: , "Adrian Farrel" Cc: , X-OriginalArrivalTime: 21 Aug 2006 04:54:35.0360 (UTC) FILETIME=[E6152600:01C6C4DD] DKIM-Signature: a=rsa-sha1; q=dns; l=1954; t=1156136076; x=1157000076; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20 |Subject:RE=3A=20Polling=20for=20new=20WG=20I-Ds |To:,=20=22Adrian=20Farrel=22=20; X=v=3Dcisco.com=3B=20h=3DMDv5AzaRucWmaA9nKW9vsoIzl6o=3D; b=n6D3EcQbG3hzEcLJZe500/SdDhkHFoHkqi9SB8mPnk/hoVnr2+2Q4NMm76txvKxWJrJeMH3P YzaN18ZWQBOdSf49fv02DzD/aC7EKWc0gu3MNYMAfFZUtZbt25I6BQ+i; Authentication-Results: rtp-dkim-2.cisco.com; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi Dimitri,=20 Please see my reply inline.=20 Thanks for your support for Graceful Shutdown ID.=20 Regards.. Zafar =20 =20 > =20 > >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace > ful-shutdown-04.txt=20 >=20 > > has been updated as Zafar says in his previous email. >=20 > informational imho - in its current version=20 >=20 > - not sure to understand why the PathErr/Notify can be=20 > processed by the=20 > head-end only (what about segment recovery and stitching=20 > case) - why only=20 > MBB is possible upon reception (pls use E2E recovery/Segment recovery=20 > capabilities as you address GMPLS networks) >=20 This is a good point and we can address these scenarios in the next version of the ID.=20 > - compared to path-reopt, error description is identical for=20 > the TE link=20 > case which leads to the following point - if errors=20 > code/value are the=20 > same how to distinguish them (assuming that the query=20 > procedure described=20 > in path-reopt is used during the setup of that LSP) ? -=20 > comment is more=20 > for the path-reopt draft than yours but since there is an=20 > overlap ...=20 In that case I will let authors of the path-reopt draft to reply/ comment on this point.=20 > it=20 > must be addressed in a way or another (note that when fully head-end=20 > driven operations look similar but there is a major=20 > difference role of=20 > timing and severity of the error code/value)=20 >=20 > - in case shutdown of a protected component link (of a bundle) is=20 > initiated why can't link protection be used ? >=20 I think this also comes under the category of scenario you mentioned above. We can address it and share the ID with you for further comments, before publishing.=20 =20 > > Please send yes or no for these I-Ds. > >=20 > > Reasons and opinions are also welcomed. > >=20 > > Thanks, > > Adrian=20 >=20 From owner-ccamp@ops.ietf.org Mon Aug 21 06:13:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF6ma-0006Hj-9j for ccamp-archive@ietf.org; Mon, 21 Aug 2006 06:13:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF4nF-0000MD-Eq for ccamp-archive@ietf.org; Mon, 21 Aug 2006 04:05:57 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF4Zj-000708-CQ for ccamp-archive@ietf.org; Mon, 21 Aug 2006 03:52:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF4Tz-000EMO-SM for ccamp-data@psg.com; Mon, 21 Aug 2006 07:46:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF4Ty-000EM7-E5 for ccamp@ops.ietf.org; Mon, 21 Aug 2006 07:46:02 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 09:45:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Mon, 21 Aug 2006 09:46:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: Aca+IJcHieTQ4dp1TaSw+8+Ktiy2ZQG1STIw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 21 Aug 2006 07:45:58.0420 (UTC) FILETIME=[D7439540:01C6C4F5] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi, Yes to all Regards, JL=20 > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel > Envoy=E9 : samedi 12 ao=FBt 2006 16:56 > =C0 : ccamp@ops.ietf.org > Objet : Polling for new WG I-Ds >=20 > Hi, >=20 > As discussed in Montreal, we need to poll for a couple of new=20 > WG drafts. >=20 > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpl > s-vcat-lcas-04.txt > has been updated by the authors to provide further details=20 > and clarification. >=20 > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-an > d-sc-reqs-02.txt > has been updated since the version discussed in Montreal. >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace > ful-shutdown-04.txt > has been updated as Zafar says in his previous email. >=20 >=20 > Please send yes or no for these I-Ds. >=20 > Reasons and opinions are also welcomed. >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 From orion@dm.mailpia.net Mon Aug 21 06:26:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF6zc-0001yO-4P for ccamp-archive@ietf.org; Mon, 21 Aug 2006 06:26:52 -0400 Received: from [125.187.32.164] (helo=m08.mailyes.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF6za-0003V4-EF for ccamp-archive@ietf.org; Mon, 21 Aug 2006 06:26:52 -0400 Received: (qmail 8267 invoked by uid 0); 21 Aug 2006 19:22:47 +0900 Message-ID: <20060821102247.8265.qmail@m08.mailyes.net> To: ccamp-archive Subject: =?ISO-2022-JP?B?GyRCOkdEYzduNWsbKEI0Mw==?= =?ISO-2022-JP?B?GyRCS3wxX0pdPlpDZiF5JWEhPCVrJV4lLCU4JXMheRsoQg==?= From: 777pachinkovillage Reply-to: delivery_rt Date: 2006-08-21 19:15:01 Content-type: text/plain; charset= ISO-2022-JP X-Mailer: NEXTism Mailer 1.0 X-Priority: 1 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Keywords: 20060821180957_cbrd Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 $B"#"#"#"#"#9b3[F|J'$$!#B(!"F|<}(B4$BK|1_0J>e"#"#"#"#"#(B $B(.(,(,(,(,(,(,(,!|Jg=8?M?t8BDj!|(,(,(,(,(,(,(,(/(B $B!!(B $B!!(B $B!!!!!!!!!!!!%W%l%$%9%?%C%U(B $B!!!!!!!!!!6HL33HBg$K$D$-6[5^BgJg=8(B!! $B(1(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(0(B $B!!!A2T$27n<}(B100$BK|1_0J>e(B!!$BL\;X$;%Q%A%s%38fEB!A!!!!(B $B!!!!!!!!!!"!5.J}$O:#$N@83h$KK~B-$G$9$+!)"!(B $B!!!!!!!!!!!!!!!!!!"-L4$r8=!$F$J$$$+$HG:$s(B $B$G$$$?$"$kF|9-9p$G%=%U%H%&%(!<%V$N$3$H$rCN$j!"(B $B:G=i$OH>?.H>5?$GLd$$9g$o$;$r$7$^$7$?!#$7$+$7!"%9(B $B%?%C%U$NJ}$N?F@Z$JBP1~!"$o$+$j$d$9$$@bL@$r$J46A[(B $B$G$9!#(B $B!!$=$l$+$i$OIi$1$k$3$H$bL5$/!"Bg9%$-$J%9%m%C%H$r(B $B$7$J$,$iCy6b$bCy$^$k$H$$$&KhF|$G$9!#$3$l$b%=%U%H(B $B%&%(!<%VMM$N$*$+$2$G$9!#$3$l$+$i$b59$7$/$*4j$$$7(B $B$^$9!#(B $B"!%=%U%H%&%(!<%V>pJs4IM}It!!>.NS$+$i(B $B!!E-LZ$5$s!"$$$D$b$J$,$i$*$a$G$H$&$4$6$$$^$9!#M_(B $B$7$,$C$F$$$?#B#M#W#7%7%j!<%:$G$9$,!"$b$7$+$7$F!"(B $B$=$m$=$mGc$($k$N$G$O(B?? $B"-i,i/?'$N?M@8$O$3$A$i"-(B http://softwave.fem.jp/ $B"#%7%c%$%K%s%0%9%?!<%W%l%$%9%?%C%U(B $B!!@h7n$N7n<}Nc(B $B#8#6K|(B $B2TF/F|?t#9F|(B $B!{?@F`@n8):_=;(B:$B#2#4:P!!6\Bt$5$s!JpJs4IM}It!!>>Eh$+$i(B $B!!6\Bt$5$s!"@h7n$b%8%c%s%8%c%s%P%j%P%j(B!!$B$*$a$G$H(B $B$&$4$6$$$^$9!##2?ML\$N$*;R$5$s$r?H$4$b$C$F$$$k$+(B $B$i%R%-$,6/$+$C$?$j$7$F(B!? --------------------$B1~Jg;q3J(B-------------------- $B"#CK=w(B $BG/Np(B $B7P83ITLd(B $B"#=i?4e5-$N%W%l%$%9%?%C%U$N3'$5$s$N(B $B$*@<$G$bH=$k$H$*$j!"0l@Z!"Fq$7$$$3$H$d!"0cK!@-$O(B $B$"$j$^$;$s!#$`$7$me?4!W(B $B$^$:$O"-$r%/%j%C%/!*!*(B http://softwave.fem.jp/ $B!!3t<02qM;{K\D.(B2-6-8 4$B3,(B $B!!!!!!!!!!!!!!!!!!!!(B0120-197-028 $B!!%a!<%k%^%,%8%s%,ITMW$JJ}$O$3$A$i$^$G(B $B!!(B info_wave1@yahoo.co.jp From owner-ccamp@ops.ietf.org Mon Aug 21 09:49:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFAA7-0004MZ-TB for ccamp-archive@ietf.org; Mon, 21 Aug 2006 09:49:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFAA5-0007ez-Rt for ccamp-archive@ietf.org; Mon, 21 Aug 2006 09:49:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF9zk-000O4q-KP for ccamp-data@psg.com; Mon, 21 Aug 2006 13:39:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,HTML_MESSAGE autolearn=no version=3.1.1 Received: from [209.191.85.52] (helo=web36801.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF9zj-000O45-LZ for ccamp@ops.ietf.org; Mon, 21 Aug 2006 13:39:11 +0000 Received: (qmail 31190 invoked by uid 60001); 21 Aug 2006 13:38:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xGDuj1sIgjd7deeABI3V19NjISB2B0ZvL9YqZBheWqKUvQExHq9zYMh45ProUGK9xdSQbJpwZFZBXxkN8PfAdHtXKZgXjZFGzXnf7sM5jGGlbdtgpxpjca+4TahN5CWxs6GJjfEjIy2TwnK8AD38urlPKFtYuHsHcDrw46BP1NQ= ; Message-ID: <20060821133853.31188.qmail@web36801.mail.mud.yahoo.com> Received: from [67.102.145.11] by web36801.mail.mud.yahoo.com via HTTP; Mon, 21 Aug 2006 06:38:52 PDT Date: Mon, 21 Aug 2006 06:38:52 -0700 (PDT) From: Igor Bryskin Subject: Re: Polling for new WG I-Ds To: Adrian Farrel Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org In-Reply-To: <004a01c6c4c5$a64fb200$d04c460a@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1570073915-1156167532=:30514" Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b --0-1570073915-1156167532=:30514 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Yes to all three. Igor ----- Original Message ----- From: To: "Adrian Farrel" Cc: ; Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds > adrian - see in-line > > Adrian Farrel wrote: > > Hi, > > > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > > > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > > > has been updated by the authors to provide further details and > > clarification. > > - ok - > > > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > > - guess it is v03.txt ? - > > > has been updated since the version discussed in Montreal. > > i am ok in investigating the MP->CP but i have two concerns that imho > should deserve more specific attention to maintain consistency wrt to > CP->MP > > section 2.2: if control is lost for an LSP (during CP failure) how can it > be possible transfer that LSP from the CP -> MP ? [dan] Yes, there is a problem if we still want to use the control plane to do the CP->MP transfer. Unless the transfer is based on the predetermined policy, MP takes the control of the LSP resource directly (no signaling required), but this way should not be discussed in CCAMP. > > section 4.4: why the document assumes that both MUST be supported ? in > part. concerning the CP->MP if one does implement current GMPLS signaling > restart/recovery why shall this be mandated ? in brief, the document shall > take into account existing mechanisms and prevent overlaps (with existing > GMPLS mechanisms) > [dan] I think the CP->MP should not be the mandatory requirement. > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. > > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > > > has been updated as Zafar says in his previous email. > > informational imho - in its current version > > - not sure to understand why the PathErr/Notify can be processed by the > head-end only (what about segment recovery and stitching case) - why only > MBB is possible upon reception (pls use E2E recovery/Segment recovery > capabilities as you address GMPLS networks) > > - compared to path-reopt, error description is identical for the TE link > case which leads to the following point - if errors code/value are the > same how to distinguish them (assuming that the query procedure described > in path-reopt is used during the setup of that LSP) ? - comment is more > for the path-reopt draft than yours but since there is an overlap ... it > must be addressed in a way or another (note that when fully head-end > driven operations look similar but there is a major difference role of > timing and severity of the error code/value) > > - in case shutdown of a protected component link (of a bundle) is > initiated why can't link protection be used ? > > > Please send yes or no for these I-Ds. > > > > Reasons and opinions are also welcomed. > > > > Thanks, > > Adrian > > --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --0-1570073915-1156167532=:30514 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
 
Yes to all three.
 
Igor
 
 
----- Original Message -----
From:
To: "Adrian Farrel"
Cc: ;
Sent: Thursday, August 17, 2006 6:32 AM
Subject: Re: Polling for new WG I-Ds


> adrian - see in-line
>
> Adrian Farrel wrote:
> > Hi,
> >
> > As discussed in Montreal, we need to poll for a couple of new WG drafts.
> >
> >
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt
>
> > has been updated by the authors to provide further details and
> > clarification.
>
> - ok -
>
> >
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt
>
> - guess it is v03.txt ? -
>
> > has been updated since the version discussed in Montreal.
>
> i am ok in investigating the MP->CP but i have two concerns that imho
> should deserve more specific attention to maintain consistency wrt to
> CP->MP
>
> section 2.2: if control is lost for an LSP (during CP failure) how can it
> be possible transfer that LSP from the CP -> MP ?

[dan] Yes, there is a problem if we still want to use the control plane to do the
CP->MP transfer. Unless the transfer is based on the predetermined policy, MP
takes the control of the LSP resource directly (no signaling required), but this way
should not be discussed in CCAMP.

>
> section 4.4: why the document assumes that both MUST be supported ? in
> part. concerning the CP->MP if one does implement current GMPLS signaling
> restart/recovery why shall this be mandated ? in brief, the document shall
> take into account existing mechanisms and prevent overlaps (with existing
> GMPLS mechanisms)
>
[dan] I think the CP->MP should not be the mandatory requirement.

> hence, it is strongly suggested to identify conditions when such CP->MP is
> required (and not an alternative to existing CP mechanisms) b/f
> progressing that part
>
[dan] In order to make the carriers' life easy, when we provide the MP->CP
conversion feature, the reverse procedure (CP->MP) may also is needed just
simply in case the carriers want to withdraw their previous decision, and
they also feel more comfortable with this "undo" function; In order to achieve
this, we should have the working control plane.

> >
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt
>
> > has been updated as Zafar says in his previous email.
>
> informational imho - in its current version
>
> - not sure to understand why the PathErr/Notify can be processed by the
> head-end only (what about segment recovery and stitching case) - why only
> MBB is possible upon reception (pls use E2E recovery/Segment recovery
> capabilities as you address GMPLS networks)
>
> - compared to path-reopt, error description is identical for the TE link
> case which leads to the following point - if errors code/value are the
> same how to distinguish them (assuming that the query procedure described
> in path-reopt is used during the setup of that LSP) ? - comment is more
> for the path-reopt draft than yours but since there is an overlap ... it
> must be addressed in a way or another (note that when fully head-end
> driven operations look similar but there is a major difference role of
> timing and severity of the error code/value)
>
> - in case shutdown of a protected component link (of a bundle) is
> initiated why can't link protection be used ?
>
> > Please send yes or no for these I-Ds.
> >
> > Reasons and opinions are also welcomed.
> >
> > Thanks,
> > Adrian
>
>


Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --0-1570073915-1156167532=:30514-- From owner-ccamp@ops.ietf.org Mon Aug 21 11:54:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFC6M-0001XV-Jc for ccamp-archive@ietf.org; Mon, 21 Aug 2006 11:54:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF9QW-0000BK-7n for ccamp-archive@ietf.org; Mon, 21 Aug 2006 09:02:48 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF9Ew-00072A-PB for ccamp-archive@ietf.org; Mon, 21 Aug 2006 08:50:52 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF8z7-000HHr-S1 for ccamp-data@psg.com; Mon, 21 Aug 2006 12:34:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [205.188.157.34] (helo=imo-d02.mx.aol.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GF8z6-000HHZ-R0 for ccamp@ops.ietf.org; Mon, 21 Aug 2006 12:34:29 +0000 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v38_r7.6.) id v.4e4.1751eab (22680); Mon, 21 Aug 2006 08:34:23 -0400 (EDT) Received: from [192.168.3.103] (c-24-128-205-249.hsd1.nh.comcast.net [24.128.205.249]) by air-in04.mx.aol.com (v112.5) with ESMTP id MAILININ41-589844e9a84e19; Mon, 21 Aug 2006 08:34:23 -0400 Message-ID: <44E9A84C.6050000@netscape.net> Date: Mon, 21 Aug 2006 08:34:20 -0400 From: Eric W Gray Reply-To: ewgray@GraIyMage.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds References: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> In-Reply-To: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 24.128.205.249 X-Mailer: Unknown (No Version) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Yes to all three... Adrian Farrel wrote: > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > > > > > From owner-ccamp@ops.ietf.org Mon Aug 21 12:42:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCqr-0001kX-7D for ccamp-archive@ietf.org; Mon, 21 Aug 2006 12:42:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCqn-0003Ss-RR for ccamp-archive@ietf.org; Mon, 21 Aug 2006 12:42:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFCkz-000HKD-7N for ccamp-data@psg.com; Mon, 21 Aug 2006 16:36:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFCky-000HJx-F5 for ccamp@ops.ietf.org; Mon, 21 Aug 2006 16:36:08 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 21 Aug 2006 09:36:08 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7LGa8fA011922; Mon, 21 Aug 2006 09:36:08 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7LGa7Yt001297; Mon, 21 Aug 2006 09:36:08 -0700 (PDT) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 09:36:07 -0700 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 Subject: RE: Polling for new WG I-Ds Date: Mon, 21 Aug 2006 09:36:06 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E0227D2F1@xmb-sjc-234.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: Aca+IFJ3uCg1j+NFSuqbntfhCmZqlAHH3F1g From: "Dean Cheng \(dcheng\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 21 Aug 2006 16:36:07.0486 (UTC) FILETIME=[E6F1DDE0:01C6C53F] DKIM-Signature: a=rsa-sha1; q=dns; l=979; t=1156178168; x=1157042168; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dcheng@cisco.com; z=From:=22Dean=20Cheng=20\(dcheng\)=22=20 |Subject:RE=3A=20Polling=20for=20new=20WG=20I-Ds; X=v=3Dcisco.com=3B=20h=3DaNdOPGR//yUM/3GHL7DzUEDWuxc=3D; b=thE8nNP45YqRrPP3wka459zxIfsIbUVlMd9slOpq/QQsDdBkQnd1QhxLQVt3yEqRk9qtp/OP qSXXqc7pTryIoCIWzGPMTGAIpsMTw/9cm3BeyD2v5OqzOga0NM1bvJfI; Authentication-Results: sj-dkim-4.cisco.com; header.From=dcheng@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Yes to all.=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Saturday, August 12, 2006 7:56 AM > To: ccamp@ops.ietf.org > Subject: Polling for new WG I-Ds >=20 > Hi, >=20 > As discussed in Montreal, we need to poll for a couple of new=20 > WG drafts. >=20 > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpl s-vcat-lcas-04.txt > has been updated by the authors to provide further details=20 > and clarification. >=20 > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-an d-sc-reqs-02.txt > has been updated since the version discussed in Montreal. >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace ful-shutdown-04.txt > has been updated as Zafar says in his previous email. >=20 >=20 > Please send yes or no for these I-Ds. >=20 > Reasons and opinions are also welcomed. >=20 > Thanks, > Adrian=20 >=20 >=20 From owner-ccamp@ops.ietf.org Tue Aug 22 07:06:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFU5P-0005aP-8J for ccamp-archive@ietf.org; Tue, 22 Aug 2006 07:06:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFSHq-0003ec-Dn for ccamp-archive@ietf.org; Tue, 22 Aug 2006 05:11:06 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFS5F-0001O7-HV for ccamp-archive@ietf.org; Tue, 22 Aug 2006 04:58:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFRyU-0005dg-KG for ccamp-data@psg.com; Tue, 22 Aug 2006 08:51:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFRyS-0005c8-PP for ccamp@ops.ietf.org; Tue, 22 Aug 2006 08:51:05 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GFRyQ-0006kx-00 for ccamp@ops.ietf.org; Tue, 22 Aug 2006 09:51:02 +0100 Received: from your029b8cecfe ([217.158.132.246] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 09:51:00 +0100 Message-ID: <0d6701c6c5c8$0f3a5510$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Subject: Fw: I-D ACTION:draft-andersson-rtg-gmpls-change-03.txt Date: Tue, 22 Aug 2006 09:49:54 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 22 Aug 2006 08:51:00.0989 (UTC) FILETIME=[17CA1AD0:01C6C5C8] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.9 (-) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 All, After much debate and discussion, the ADs and WG chairs have produced a new revision of the (G)MPLS change process draft. This should be read in conjunction with http://www.ietf.org/internet-drafts/draft-carpenter--protocol-extensions-01.txt To avoid cross-posting, please send any comments (which will be gratefully received) to the Routing Area discussion mailing list only. Thanks, Adrian ----- Original Message ----- From: To: Sent: Monday, August 21, 2006 11:50 PM Subject: I-D ACTION:draft-andersson-rtg-gmpls-change-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Change Process for Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) Protocols and Procedures > Author(s) : L. Andersson, A. Farrel > Filename : draft-andersson-rtg-gmpls-change-03.txt > Pages : 22 > Date : 2006-8-21 > > The issues surrounding the extensibility of IETF protocols have been > widely debated. These issues include when it is reasonable to > extend IETF protocols with little or no review, and when extensions > or variations need to be reviewed by the larger IETF community. > Experience with IETF protocols has shown that extensibility of > protocols without early IETF review can cause problems. > > The Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > suites of protocols have become popular for a number of applications > and deployment scenarios. One result of this popularity is a large > number of suggestions for modifications and extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls-change-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-andersson-rtg-gmpls-change-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-andersson-rtg-gmpls-change-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > From owner-ccamp@ops.ietf.org Tue Aug 22 20:41:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFgnx-0000Iz-54 for ccamp-archive@ietf.org; Tue, 22 Aug 2006 20:41:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFgns-00063d-Ky for ccamp-archive@ietf.org; Tue, 22 Aug 2006 20:41:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFgbw-000NPX-GI for ccamp-data@psg.com; Wed, 23 Aug 2006 00:28:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [192.26.91.6] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFgbq-000NPD-Bw for ccamp@ops.ietf.org; Wed, 23 Aug 2006 00:28:45 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id CBF31EC992; Wed, 23 Aug 2006 09:28:40 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id 80EEFEC98B; Wed, 23 Aug 2006 09:28:40 +0900 (JST) Received: from [IPv6:2001:200:601:1e02:0:5efe:ac13:5714] (unknown [IPv6:2001:200:601:1e02:0:5efe:ac13:5714]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 7552F578103; Wed, 23 Aug 2006 09:28:15 +0900 (JST) Message-ID: <44EBA14A.30802@kddilabs.jp> Date: Wed, 23 Aug 2006 09:28:58 +0900 From: Tomohiro Otani User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Tomohiro Otani Cc: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds References: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> <44E93A1F.9070608@kddilabs.jp> In-Reply-To: <44E93A1F.9070608@kddilabs.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hello, I also support the others. Regards, tomo Tomohiro Otani wrote: > Hi Adrian, > > I support the third draft to be a WG. > > Regards, > > tomo > > > Adrian Farrel wrote: >> Hi, >> >> As discussed in Montreal, we need to poll for a couple of new WG drafts. >> >> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt >> has been updated by the authors to provide further details and >> clarification. >> >> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt >> has been updated since the version discussed in Montreal. >> >> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt >> has been updated as Zafar says in his previous email. >> >> >> Please send yes or no for these I-Ds. >> >> Reasons and opinions are also welcomed. >> >> Thanks, >> Adrian >> >> >> > > > From ph@vitagames.com Wed Aug 23 00:55:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFkmR-0006WF-0x for ccamp-archive@ietf.org; Wed, 23 Aug 2006 00:55:55 -0400 Received: from [74.131.80.59] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFkaH-0004Hn-Ny for ccamp-archive@ietf.org; Wed, 23 Aug 2006 00:43:23 -0400 Message-ID: <000001c6c66f$3042ee00$0100007f@localhost> From: "Andrew Carter" To: Subject: Re: About OEM Software Date: Wed, 23 Aug 2006 00:43:28 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C66F.3042EE00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.1 (++++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 ------=_NextPart_000_0001_01C6C66F.3042EE00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable More than 200 software titles from world leading manufacturers =20 a.. MS Windows XP Professional with SP2 - $49.95=20 b.. Adobe Photoshop CS2 V 9.0 - $69.95=20 c.. Microsoft Office XP Professional - $49.95=20 d.. Adobe Acrobat 5.0 - $39.95 Visit our Website ------=_NextPart_000_0001_01C6C66F.3042EE00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 More than 200=20 software titles from world leading=20 manufacturers  
  • MS Windows XP Professional with SP2 - = $49.95
  • Adobe Photoshop CS2 V 9.0 - $69.95
  • Microsoft Office XP Professional - = $49.95
  • Adobe Acrobat 5.0 - $39.95
 
------=_NextPart_000_0001_01C6C66F.3042EE00-- From owner-ccamp@ops.ietf.org Wed Aug 23 04:08:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFnmS-0008Pn-Cg for ccamp-archive@ietf.org; Wed, 23 Aug 2006 04:08:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFnmF-0002Tz-5Q for ccamp-archive@ietf.org; Wed, 23 Aug 2006 04:08:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFneB-0009UT-U3 for ccamp-data@psg.com; Wed, 23 Aug 2006 07:59:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.54] (helo=szxga02-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFne5-0009U3-Nn for ccamp@ops.ietf.org; Wed, 23 Aug 2006 07:59:34 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4F008G8YUSM2@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Wed, 23 Aug 2006 16:13:40 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4F006UIYUS2O@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Wed, 23 Aug 2006 16:13:40 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4F0047WYLD6K@szxml04-in.huawei.com> for ccamp@ops.ietf.org; Wed, 23 Aug 2006 16:08:01 +0800 (CST) Date: Wed, 23 Aug 2006 15:55:49 +0800 From: Dan Li Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, To: xuhuiying@huawei.com, "Zafar Ali (zali)" , MEURIC Julien RD-CORE-LAN Cc: ccamp Message-id: <007901c6c689$8c828120$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <7DBAFEC6A76F3E42817DF1EBE64CB02603A53006@FTRDMEL2.rd.francetelecom.fr> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi, Thanks Julien and Zafar for your comments. I agree with Julien. This I-D just wants to provide a control plane tool to detect the inconsistent data channel status in the tranport plane. Actually I have received several private emails think this I-D addresses a real problem, but regarding the new LMP messages which are introduced in this I-D, some people pointed out that the already deployed channelstatus messages (id = 17, 18, 19 and 20) may be extended to carry also the timeslot information instead only data link. But I have a concern that the Fault Management Messages usually are triggered by fault detection, these messages should not be sent if no fault is detected. The confirmation of data channel status may need to be performed periodically or triggerd by user. I would like to hear from you guys, what's your comments? Not only the concerns raised above, but also other issues in this I-D. Regards, Dan ----- Original Message ----- From: "MEURIC Julien RD-CORE-LAN" To: "Zafar Ali (zali)" ; ; Cc: "ccamp" Sent: Tuesday, July 11, 2006 2:31 AM Subject: RE: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi Zafar. I don't really get you on this. I figure out you're referring to removing the connection states when RSVP refreshes are not received any more, aren't you? If so, I'm afraid this is not enough for transmission devices, where resources can be physically cross-connected even though there is no (or no longer) corresponding RSVP state. Therefore having a mechanism to avoid such discrepancies would be welcome. Regards, Julien P.S.: If you totally rely on a management plane, I agree this should be useless (e.g. the NMS should already know if a cross-connection deletion failed, cf. Diego's 2nd slides seen this morning). ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Dear Authors, RSVP refreshes do this job, so I am not sure motivation for this draft/ LMP extensions. n.b. The draft state, "Although such a situation can be resolved through the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], such a procedure is inefficient since it may require an additional signaling exchange for each LSP that is set up", so I assume that RSVP signaling is present (Although I did not understand the quoted statement from the ID). Even if RSVP is not present, e.g., optical core is completely controlled by a management entity, I would argue introduce presence of LMP. Thanks Regards... Zafar From brink@hopespromise.com Wed Aug 23 04:30:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFo88-0000FS-C5 for ccamp-archive@megatron.ietf.org; Wed, 23 Aug 2006 04:30:32 -0400 Received: from [58.50.135.80] (helo=hopespromise.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFo84-0007Gw-Q5 for ccamp-archive@megatron.ietf.org; Wed, 23 Aug 2006 04:30:32 -0400 Received: by 192.168.150.221 with SMTP id XQawKQc; for ; Wed, 23 Aug 2006 01:30:16 -0700 Message-ID: <000001c6c68e$5c245b20$dd96a8c0@ieyhywl> Reply-To: "Kaitlynn Vanriper" From: "Kaitlynn Vanriper" To: ccamp-archive@megatron.ietf.org Subject: Re: new ki Date: Wed, 23 Aug 2006 01:30:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C653.AFC7F420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6C653.AFC7F420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Not very good erecxction? You are welcome - http://basadefunkewaion.com =20 =20 =20 presence. Not the Chariots of Fire again? Floyd groaned. No. But something that sounds just as ominous. A Transport of ------=_NextPart_000_0001_01C6C653.AFC7F420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Not very good erecxction? You are welcome - http://basadefunkewaion.com

 

 

 

presence.
Not the Chariots of Fire again? Floyd groaned.
No. But something that sounds just as ominous. A Transport = of

------=_NextPart_000_0001_01C6C653.AFC7F420-- From owner-ccamp@ops.ietf.org Wed Aug 23 04:42:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFoJJ-0005ks-Ce for ccamp-archive@ietf.org; Wed, 23 Aug 2006 04:42:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFoJD-0000JB-E6 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 04:42:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFoBD-000CHN-4I for ccamp-data@psg.com; Wed, 23 Aug 2006 08:33:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFoBA-000CGa-6V; Wed, 23 Aug 2006 08:33:41 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7N8XFva019284; Wed, 23 Aug 2006 10:33:15 +0200 In-Reply-To: <004a01c6c4c5$a64fb200$d04c460a@china.huawei.com> To: Dan Li Cc: Adrian Farrel , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 23 Aug 2006 10:33:10 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/23/2006 10:33:13, Serialize complete at 08/23/2006 10:33:13 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd hi - see inline Dan Li Sent by: owner-ccamp@ops.ietf.org 21/08/2006 04:01 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Hi Dimitri, Please see in line. Regards, Dan ----- Original Message ----- From: To: "Adrian Farrel" Cc: ; Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds > adrian - see in-line > > Adrian Farrel wrote: > > Hi, > > > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > > > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > > > has been updated by the authors to provide further details and > > clarification. > > - ok - > > > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > > - guess it is v03.txt ? - > > > has been updated since the version discussed in Montreal. > > i am ok in investigating the MP->CP but i have two concerns that imho > should deserve more specific attention to maintain consistency wrt to > CP->MP > > section 2.2: if control is lost for an LSP (during CP failure) how can it > be possible transfer that LSP from the CP -> MP ? [dan] Yes, there is a problem if we still want to use the control plane to do the CP->MP transfer. Unless the transfer is based on the predetermined policy, MP takes the control of the LSP resource directly (no signaling required), but this way should not be discussed in CCAMP. [dp] ok so what's left for this doc ? concerning the MP-driven failover - imho nothing > section 4.4: why the document assumes that both MUST be supported ? in > part. concerning the CP->MP if one does implement current GMPLS signaling > restart/recovery why shall this be mandated ? in brief, the document shall > take into account existing mechanisms and prevent overlaps (with existing > GMPLS mechanisms) > [dan] I think the CP->MP should not be the mandatory requirement. [dp] this is what i thought > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > > > has been updated as Zafar says in his previous email. > > informational imho - in its current version > > - not sure to understand why the PathErr/Notify can be processed by the > head-end only (what about segment recovery and stitching case) - why only > MBB is possible upon reception (pls use E2E recovery/Segment recovery > capabilities as you address GMPLS networks) > > - compared to path-reopt, error description is identical for the TE link > case which leads to the following point - if errors code/value are the > same how to distinguish them (assuming that the query procedure described > in path-reopt is used during the setup of that LSP) ? - comment is more > for the path-reopt draft than yours but since there is an overlap ... it > must be addressed in a way or another (note that when fully head-end > driven operations look similar but there is a major difference role of > timing and severity of the error code/value) > > - in case shutdown of a protected component link (of a bundle) is > initiated why can't link protection be used ? > > > Please send yes or no for these I-Ds. > > > > Reasons and opinions are also welcomed. > > > > Thanks, > > Adrian > > From owner-ccamp@ops.ietf.org Wed Aug 23 05:24:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFoyY-0007kX-9t for ccamp-archive@ietf.org; Wed, 23 Aug 2006 05:24:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFoyS-0008GZ-03 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 05:24:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFoq4-000G2g-Pk for ccamp-data@psg.com; Wed, 23 Aug 2006 09:15:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFoq1-000G2A-82; Wed, 23 Aug 2006 09:15:53 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7N9FEpl020007; Wed, 23 Aug 2006 10:15:26 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: Re: Polling for new WG I-Ds To: "Dimitri.Papadimitriou" Cc: "Dan Li , "Adrian Farrel , "ccamp" , "owner-ccamp" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 23 Aug 2006 11:13:44 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 23/08/2006 10:15:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.8 (+) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hi Dimitri, some comments in line. Regards Diego Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 23/08/2006 10.33.10 Sent by: owner-ccamp@ops.ietf.org To: Dan Li cc: Adrian Farrel , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds hi - see inline Dan Li Sent by: owner-ccamp@ops.ietf.org 21/08/2006 04:01 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Hi Dimitri, Please see in line. Regards, Dan ----- Original Message ----- From: To: "Adrian Farrel" Cc: ; Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds [snipped] > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves [dc] I think they or some of them already did this. Looking at the pool seems that at least 4 carries voted yes to the ID. - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) [dc] Of course I think we should. [snipped] From owner-ccamp@ops.ietf.org Wed Aug 23 05:39:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpDB-0005EG-DM for ccamp-archive@ietf.org; Wed, 23 Aug 2006 05:39:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFpDA-0001TJ-0a for ccamp-archive@ietf.org; Wed, 23 Aug 2006 05:39:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFp6M-000HbH-3w for ccamp-data@psg.com; Wed, 23 Aug 2006 09:32:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFp6L-000Hb4-7u for ccamp@ops.ietf.org; Wed, 23 Aug 2006 09:32:45 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7N9Waje024652; Wed, 23 Aug 2006 10:32:36 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, To: "Dan Li Cc: "xuhuiying" , ""Zafar Ali (zali)" , "MEURIC Julien RD-CORE-LAN , "ccamp X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 23 Aug 2006 11:31:23 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 23/08/2006 10:32:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.8 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Hi Dan, first of all I think that the ID addresses a real problem. Regarding the bits and bytes I prefer to not implemet new messages but just updateds the existing ones that seems to fit to the problem. I think that having a timeslot that should be usable that is actually unusable is a failure from the control plane prespective. So I think that is correct to use the Fault Management Messages to convey information about unusable channles. Regards Diego Dan Li @ops.ietf.org on 23/08/2006 09.55.49 Sent by: owner-ccamp@ops.ietf.org To: xuhuiying@huawei.com, "Zafar Ali (zali)" , MEURIC Julien RD-CORE-LAN cc: ccamp Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi, Thanks Julien and Zafar for your comments. I agree with Julien. This I-D just wants to provide a control plane tool to detect the inconsistent data channel status in the tranport plane. Actually I have received several private emails think this I-D addresses a real problem, but regarding the new LMP messages which are introduced in this I-D, some people pointed out that the already deployed channelstatus messages (id = 17, 18, 19 and 20) may be extended to carry also the timeslot information instead only data link. But I have a concern that the Fault Management Messages usually are triggered by fault detection, these messages should not be sent if no fault is detected. The confirmation of data channel status may need to be performed periodically or triggerd by user. I would like to hear from you guys, what's your comments? Not only the concerns raised above, but also other issues in this I-D. Regards, Dan ----- Original Message ----- From: "MEURIC Julien RD-CORE-LAN" To: "Zafar Ali (zali)" ; ; Cc: "ccamp" Sent: Tuesday, July 11, 2006 2:31 AM Subject: RE: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi Zafar. I don't really get you on this. I figure out you're referring to removing the connection states when RSVP refreshes are not received any more, aren't you? If so, I'm afraid this is not enough for transmission devices, where resources can be physically cross-connected even though there is no (or no longer) corresponding RSVP state. Therefore having a mechanism to avoid such discrepancies would be welcome. Regards, Julien P.S.: If you totally rely on a management plane, I agree this should be useless (e.g. the NMS should already know if a cross-connection deletion failed, cf. Diego's 2nd slides seen this morning). ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Dear Authors, RSVP refreshes do this job, so I am not sure motivation for this draft/ LMP extensions. n.b. The draft state, "Although such a situation can be resolved through the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], such a procedure is inefficient since it may require an additional signaling exchange for each LSP that is set up", so I assume that RSVP signaling is present (Although I did not understand the quoted statement from the ID). Even if RSVP is not present, e.g., optical core is completely controlled by a management entity, I would argue introduce presence of LMP. Thanks Regards... Zafar From owner-ccamp@ops.ietf.org Wed Aug 23 08:58:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsJ1-0008Gt-1i for ccamp-archive@ietf.org; Wed, 23 Aug 2006 08:58:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsJ0-0006pq-Vk for ccamp-archive@ietf.org; Wed, 23 Aug 2006 08:58:03 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFsIw-0000jK-TG for ccamp-archive@ietf.org; Wed, 23 Aug 2006 08:58:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFs7Q-00082O-D6 for ccamp-data@psg.com; Wed, 23 Aug 2006 12:46:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFs7L-00081X-Aq; Wed, 23 Aug 2006 12:45:59 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7NCjiIX029747; Wed, 23 Aug 2006 14:45:44 +0200 In-Reply-To: <007901c6c689$8c828120$d04c460a@china.huawei.com> To: Dan Li Cc: ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 23 Aug 2006 14:45:41 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/23/2006 14:45:42, Serialize complete at 08/23/2006 14:45:42 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 just a brief remark i don't see why channel status verification can not be achieved with current mechanism described in section 12.7 of 4204 (and there is a need to come with a complete set of messages for this purpose) now i am even unclear how the problem you stated can occur "The channel status of a data link may become mismatched during the LSP deletion process. If the LSP deletion process is aborted in the middle of the process (perhaps because of a temporary control plane failure), the cross-connection at the upstream node may be removed while the downstream node still keeps its cross-connection." why do you think the notion of soft-state has been introduced ? once the cleanup timeout (set to K times the refresh timeout) interval is reached that then triggers a tear-down thanks, - d. Dan Li Sent by: owner-ccamp@ops.ietf.org 23/08/2006 09:55 To: xuhuiying@huawei.com, "Zafar Ali (zali)" , MEURIC Julien RD-CORE-LAN cc: ccamp Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi, Thanks Julien and Zafar for your comments. I agree with Julien. This I-D just wants to provide a control plane tool to detect the inconsistent data channel status in the tranport plane. Actually I have received several private emails think this I-D addresses a real problem, but regarding the new LMP messages which are introduced in this I-D, some people pointed out that the already deployed channelstatus messages (id = 17, 18, 19 and 20) may be extended to carry also the timeslot information instead only data link. But I have a concern that the Fault Management Messages usually are triggered by fault detection, these messages should not be sent if no fault is detected. The confirmation of data channel status may need to be performed periodically or triggerd by user. I would like to hear from you guys, what's your comments? Not only the concerns raised above, but also other issues in this I-D. Regards, Dan ----- Original Message ----- From: "MEURIC Julien RD-CORE-LAN" To: "Zafar Ali (zali)" ; ; Cc: "ccamp" Sent: Tuesday, July 11, 2006 2:31 AM Subject: RE: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi Zafar. I don't really get you on this. I figure out you're referring to removing the connection states when RSVP refreshes are not received any more, aren't you? If so, I'm afraid this is not enough for transmission devices, where resources can be physically cross-connected even though there is no (or no longer) corresponding RSVP state. Therefore having a mechanism to avoid such discrepancies would be welcome. Regards, Julien P.S.: If you totally rely on a management plane, I agree this should be useless (e.g. the NMS should already know if a cross-connection deletion failed, cf. Diego's 2nd slides seen this morning). ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Dear Authors, RSVP refreshes do this job, so I am not sure motivation for this draft/ LMP extensions. n.b. The draft state, "Although such a situation can be resolved through the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], such a procedure is inefficient since it may require an additional signaling exchange for each LSP that is set up", so I assume that RSVP signaling is present (Although I did not understand the quoted statement from the ID). Even if RSVP is not present, e.g., optical core is completely controlled by a management entity, I would argue introduce presence of LMP. Thanks Regards... Zafar From owner-ccamp@ops.ietf.org Wed Aug 23 10:25:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtfT-0006O9-Uf for ccamp-archive@ietf.org; Wed, 23 Aug 2006 10:25:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFtfS-0006tJ-3Z for ccamp-archive@ietf.org; Wed, 23 Aug 2006 10:25:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFtUM-000FWg-HM for ccamp-data@psg.com; Wed, 23 Aug 2006 14:13:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFtUK-000FVw-EV; Wed, 23 Aug 2006 14:13:49 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7NEDP4N003283; Wed, 23 Aug 2006 15:13:25 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: Re: Polling for new WG I-Ds To: "Dimitri.Papadimitriou" Cc: ""ccamp" , ""owner-ccamp" , "Adrian Farrel , "danli" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 23 Aug 2006 16:12:11 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 23/08/2006 15:13:23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.8 (+) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Hi Dimitri, in line. Regards Diego Dimitri.Papadimitriou@alcatel.be on 23/08/2006 15.51.23 To: "Diego Caviglia" cc: "ccamp" , "owner-ccamp" , Adrian Farrel , danli@huawei.com Subject: Re: Polling for new WG I-Ds hi diego - [snipped] > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves [dc] I think they or some of them already did this. Looking at the pool seems that at least 4 carries voted yes to the ID. [dp] not sure they express specific opinion on this aspect which is "shall we take care about how to step back from GMPLS ?" it may be the case but then the discussion has much fundamental impact than the discussion around this specific i-d [dc] I dont' think they said "we agree on moving this ID to WG" without having read the doc, the point in the ID (we already agreed that is not a mandatory requirement but only optional) is that should (or may or shall) be possible to move back to NMS a circuit that was provisioned by the CP. That is in the ID. I was just pointing out that some carriers have already expressed their opinion on the ID and thus on the CP->MP feature. This is in line with the Dan sentence. The sentence "shall we take care about how to step back from GMPLS?" was not in the intention of the ID. - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) [dc] Of course I think we should. [dp] if i well understand your conclusion putting both of your answers toghether it would mean that CCAMP should take care about how "removing" GMPLS CP ? [dc] No the point is that IMHO could be useful for carriers to have the possibility to move a CP created circuit to the NMS. May be this operation can be performed via CP. This does not means to remove the whole control plane. ... interesting opinion, it took 6 years for CCAMP to have something more or less workable now you and your co-authors are probably trying to init an item to disband this work, if this is the case i don't even understand how we are polling for this document on this list [dc] I don't think this is in the ID. If my previous answer suggested this is my fault. [snipped] From owner-ccamp@ops.ietf.org Wed Aug 23 10:50:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFu42-0006VK-37 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 10:50:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFu3z-0004l8-Ln for ccamp-archive@ietf.org; Wed, 23 Aug 2006 10:50:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFtx1-000I94-EF for ccamp-data@psg.com; Wed, 23 Aug 2006 14:43:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFtwy-000I8k-UF; Wed, 23 Aug 2006 14:43:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 10:43:23 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpA From: "Bryskin, Igor" To: "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Hi, I agree with Diego on this. One of the reasons why operators are so = nervous about using CP is CP's unpredictability (because of its dynamic = nature). I am sure they will be more confident if/when they know that = there is a way to undo everything or something that might go wrong with = migration to CP without breaking active services. Besides I can see at least one quite real application for CP->MP. = Imagine that an operator wants to perform some major software upgrade = with a new software version significantly incompatible with the previous = one. One way to perform such an upgrade: a) CP->MP; b) perform software upgrade on all controllers c) MP->CP Igor -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Diego Caviglia Sent: Wednesday, August 23, 2006 10:12 AM To: Dimitri.Papadimitriou Cc: " ccamp " cc: "ccamp" , "owner-ccamp" , Adrian Farrel , danli@huawei.com Subject: Re: Polling for new WG I-Ds hi diego - [snipped] > hence, it is strongly suggested to identify conditions when such = CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the = MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed = just simply in case the carriers want to withdraw their previous decision, = and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves [dc] I think they or some of them already did this. Looking at the pool seems that at least 4 carries voted yes to the ID. [dp] not sure they express specific opinion on this aspect which is = "shall we take care about how to step back from GMPLS ?" it may be the case but then the discussion has much fundamental impact than the discussion = around this specific i-d [dc] I dont' think they said "we agree on moving this ID to WG" without having read the doc, the point in the ID (we already agreed that is not = a mandatory requirement but only optional) is that should (or may or = shall) be possible to move back to NMS a circuit that was provisioned by the = CP. That is in the ID. I was just pointing out that some carriers have already expressed their opinion on the ID and thus on the CP->MP feature. This is in line with = the Dan sentence. The sentence "shall we take care about how to step back from GMPLS?" was not in the intention of the ID. - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) [dc] Of course I think we should. [dp] if i well understand your conclusion putting both of your answers toghether it would mean that CCAMP should take care about how "removing" GMPLS CP ? [dc] No the point is that IMHO could be useful for carriers to have the possibility to move a CP created circuit to the NMS. May be this = operation can be performed via CP. This does not means to remove the whole control plane. ... interesting opinion, it took 6 years for CCAMP to have something = more or less workable now you and your co-authors are probably trying to init an item to disband this work, if this is the case i don't even = understand how we are polling for this document on this list [dc] I don't think this is in the ID. If my previous answer suggested = this is my fault. [snipped] From owner-ccamp@ops.ietf.org Wed Aug 23 11:21:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuXr-00068v-8K for ccamp-archive@ietf.org; Wed, 23 Aug 2006 11:21:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFuXl-0002cO-UW for ccamp-archive@ietf.org; Wed, 23 Aug 2006 11:21:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFuQS-000Kbx-10 for ccamp-data@psg.com; Wed, 23 Aug 2006 15:13:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.64.48] (helo=slb-smtpout-01.ns.cs.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFuQN-000Kba-63; Wed, 23 Aug 2006 15:13:47 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7NFDIQl026868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Aug 2006 08:13:24 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7NFDcfX010105; Wed, 23 Aug 2006 08:13:40 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (xch-swbh-04.sw.nos.boeing.com [192.79.11.25]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7NFDHmc009083; Wed, 23 Aug 2006 08:13:20 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 08:12:42 -0700 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 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 08:12:41 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DCF8@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIA= From: "Drake, John E" To: "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" X-OriginalArrivalTime: 23 Aug 2006 15:12:42.0427 (UTC) FILETIME=[9485F8B0:01C6C6C6] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Snipped >=20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 From owner-ccamp@ops.ietf.org Wed Aug 23 11:42:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFurj-0006Fx-KJ for ccamp-archive@ietf.org; Wed, 23 Aug 2006 11:42:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFure-0005lQ-Bi for ccamp-archive@ietf.org; Wed, 23 Aug 2006 11:42:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFum0-000MCZ-3s for ccamp-data@psg.com; Wed, 23 Aug 2006 15:36:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [63.118.34.24] (helo=ripley.ciena.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFulq-000MAM-Ah; Wed, 23 Aug 2006 15:35:59 +0000 Received: from mdmail4.ciena.com (HELO mdmxm02.ciena.com) ([63.118.39.27]) by ripley.ciena.com with ESMTP; 23 Aug 2006 11:42:24 -0400 X-IronPort-AV: i="4.08,161,1154923200"; d="scan'208"; a="112957565:sNHT30650112" 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 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 11:35:21 -0400 Message-ID: <0901D1988E815341A0103206A834DA07F9B47B@mdmxm02.ciena.com> In-Reply-To: <626FC7C6A97381468FB872072AB5DDC8C2DCF8@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAMJUQA== From: "Ong, Lyndon" To: "Drake, John E" , "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 I agree with this. Besides, transitioning from CP->MP would=20 introduce its own risks.=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E Sent: Wednesday, August 23, 2006 8:13 AM To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " =20 > Besides I can see at least one quite real application for > CP->MP. Imagine that an operator wants to perform some major > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 From owner-ccamp@ops.ietf.org Wed Aug 23 11:49:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuz0-0001IV-N4 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 11:49:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFuyw-00073i-CM for ccamp-archive@ietf.org; Wed, 23 Aug 2006 11:49:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFusU-000MlV-7e for ccamp-data@psg.com; Wed, 23 Aug 2006 15:42:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [216.82.245.131] (helo=mail146.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFusS-000Mkn-8h; Wed, 23 Aug 2006 15:42:48 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-8.tower-146.messagelabs.com!1156347641!2093317!33 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15665 invoked from network); 23 Aug 2006 15:42:44 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-146.messagelabs.com with SMTP; 23 Aug 2006 15:42:44 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 44E128F500146BC5; Wed, 23 Aug 2006 11:42:44 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 10:42:43 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0CA60A0A@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <626FC7C6A97381468FB872072AB5DDC8C2DCF8@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AA== From: "Brungard, Deborah A, ALABS" To: "Drake, John E" , "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Agree with John, and control plane failures don't (should not/hope not) impact the data plane state. And before doing such a sw upgrade, I would not want to have to move hundreds/thousands of LSPs from CP->MP. I'm not sure myself on what is meant by CP->MP, need to discuss more. (chair hat off) Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E Sent: Wednesday, August 23, 2006 11:13 AM To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " =20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 From owner-ccamp@ops.ietf.org Wed Aug 23 12:07:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvGf-0001ML-Bf for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:07:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvGc-0001E0-AS for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:07:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFv4K-000Nsk-KO for ccamp-data@psg.com; Wed, 23 Aug 2006 15:55:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFv4G-000NrG-Fd; Wed, 23 Aug 2006 15:55:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 11:54:59 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwA== From: "Bryskin, Igor" To: "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 John. >=20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 You are right, we do. In theory such situations should not happen, = however, we all know that in practice there are always cases when = original (especially proprietary) protocol solutions are not thought = through enough, and it is impossible to maintain backward compatibility = between the software releases. That's why I am talking about *major* = upgrades. Furthermore, sometimes there is a need to actually downgrade = software, for instance, when one wants to add to the network some older = equipment. Again, the ability to do the CP->MP->CP trick would help Igor From owner-ccamp@ops.ietf.org Wed Aug 23 12:23:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvWF-0000RM-Uk for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:23:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvWC-0003uU-AL for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:23:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvNS-000PNK-1t for ccamp-data@psg.com; Wed, 23 Aug 2006 16:14:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [168.127.0.56] (helo=fncnmp03.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvNQ-000PN2-RS; Wed, 23 Aug 2006 16:14:49 +0000 Received: from unknown (HELO nova.tx.fnc.fujitsu.com) ([167.254.252.121]) by fncnmp03.fnc.fujitsu.com with ESMTP; 23 Aug 2006 11:14:48 -0500 X-IronPort-AV: i="4.08,161,1154926800"; d="scan'208"; a="48498788:sNHT20094020" Received: from miranda.tx.fnc.fujitsu.com (localhost [127.0.0.1]) by nova.tx.fnc.fujitsu.com (8.12.10+Sun/8.12.10) with ESMTP id k7NGEdmP005672; Wed, 23 Aug 2006 11:14:39 -0500 (CDT) Received: from [167.254.250.51] (tdd1979.tddeng00.fnts.com [167.254.250.51]) by miranda.tx.fnc.fujitsu.com (8.12.9+Sun/8.12.9) with ESMTP id k7NGEWUg021129; Wed, 23 Aug 2006 11:14:35 -0500 (CDT) Message-ID: <44EC7EE8.70402@us.fujitsu.com> Date: Wed, 23 Aug 2006 11:14:32 -0500 From: Snigdho Bardalai Organization: Fujitsu Network Communications User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: Dan Li , ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Hi Dimitri, Since a control-channel failure leads to RSVP hello failure the clean-up timeout event will not occur (due to auto-refresh). In case an intermediate or egress node initiates the deletion process and there is a temporary control-plane failure that disallows the delete request from reaching the ingress node, then there is a potential problem. Even though the intermediate or egress node initiates the force deletion process after the "no-response" timer expires the connection may get re-created once the control-plane recovers, because the ingress may continuously be transmitting Path messages. Even if the Path message contains the RECOVERY object, this will cause re-creation of the connection (Refer to RFC 3473 Section 9.5.2). One posible solution is to carry out a channel-status audit in order to detect such anamolies. Regards, Snigdho Dimitri.Papadimitriou@alcatel.be wrote: >just a brief remark > >i don't see why channel status verification can not be achieved with >current mechanism described in section 12.7 of 4204 (and there is a >need to come with a complete set of messages for this purpose) > >now i am even unclear how the problem you stated can occur > >"The channel status of a data link may become mismatched during the > LSP deletion process. If the LSP deletion process is aborted in the > middle of the process (perhaps because of a temporary control plane > failure), the cross-connection at the upstream node may be removed > while the downstream node still keeps its cross-connection." > >why do you think the notion of soft-state has been introduced ? once >the cleanup timeout (set to K times the refresh timeout) interval is >reached that then triggers a tear-down > >thanks, >- d. > > > > > > >Dan Li >Sent by: owner-ccamp@ops.ietf.org >23/08/2006 09:55 > > To: xuhuiying@huawei.com, "Zafar Ali (zali)" , >MEURIC Julien RD-CORE-LAN > cc: ccamp > Subject: Re: High level comment on >draft-li-ccamp-confirm-data-channel-status-00.txt, > > >Hi, > >Thanks Julien and Zafar for your comments. I agree with Julien. This I-D >just wants to provide a control plane tool to detect the inconsistent data >channel status in the tranport plane. > >Actually I have received several private emails think this I-D addresses a >real problem, but regarding the new LMP messages which are introduced in >this I-D, some people pointed out that the already deployed channelstatus >messages (id = 17, 18, 19 and 20) may be extended to carry also the >timeslot information instead only data link. But I have a concern that the >Fault Management Messages usually are triggered by fault detection, these >messages should not be sent if no fault is detected. The confirmation of >data channel status may need to be performed periodically or triggerd by >user. > >I would like to hear from you guys, what's your comments? Not only the >concerns raised above, but also other issues in this I-D. > >Regards, > >Dan > >----- Original Message ----- >From: "MEURIC Julien RD-CORE-LAN" >To: "Zafar Ali (zali)" ; ; > >Cc: "ccamp" >Sent: Tuesday, July 11, 2006 2:31 AM >Subject: RE: High level comment on >draft-li-ccamp-confirm-data-channel-status-00.txt, > > >Hi Zafar. > >I don't really get you on this. I figure out you're referring to >removing the connection states when RSVP refreshes are not received any >more, aren't you? If so, I'm afraid this is not enough for transmission >devices, where resources can be physically cross-connected even though >there is no (or no longer) corresponding RSVP state. Therefore having a >mechanism to avoid such discrepancies would be welcome. > >Regards, > >Julien > > >P.S.: If you totally rely on a management plane, I agree this should be >useless (e.g. the NMS should already know if a cross-connection deletion >failed, cf. Diego's 2nd slides seen this morning). > >________________________________ > > >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of Zafar Ali (zali) > >Dear Authors, > >RSVP refreshes do this job, so I am not sure motivation for this draft/ >LMP extensions. > >n.b. The draft state, "Although such a situation can be resolved through >the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], >such a procedure is inefficient since it may require an additional >signaling exchange for each LSP that is set up", so I assume that RSVP >signaling is present (Although I did not understand the quoted statement >from the ID). Even if RSVP is not present, e.g., optical core is >completely controlled by a management entity, I would argue introduce >presence of LMP. > >Thanks > >Regards... Zafar > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 23 12:24:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvWf-0000hY-VK for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:24:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvWa-00040S-3a for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:24:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvHx-000Ozz-DW for ccamp-data@psg.com; Wed, 23 Aug 2006 16:09:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.64.48] (helo=slb-smtpout-01.ns.cs.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvHw-000Ozd-O4; Wed, 23 Aug 2006 16:09:08 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7NG8jN8023737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Aug 2006 09:08:45 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7NG96VB001961; Wed, 23 Aug 2006 09:09:07 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (xch-swbh-04.sw.nos.boeing.com [192.79.11.25]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7NG8fY2000744; Wed, 23 Aug 2006 09:08:53 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 09:08:45 -0700 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 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 09:08:45 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DCFC@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwAABe1rw From: "Drake, John E" To: "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" X-OriginalArrivalTime: 23 Aug 2006 16:08:45.0882 (UTC) FILETIME=[694C79A0:01C6C6CE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 >=20 > JD: Except that we go to great pains to ensure that this=20 > situation never occurs.=20 >=20 > You are right, we do. In theory such situations should not=20 > happen, however, we all know that in practice there are=20 > always cases when original (especially proprietary) protocol=20 > solutions are not thought through enough, and it is=20 > impossible to maintain backward compatibility between the=20 > software releases. That's why I am talking about *major*=20 > upgrades. Furthermore, sometimes there is a need to actually=20 > downgrade software, for instance, when one wants to add to=20 > the network some older equipment. Why would anyone want to do this, especially without upgrading this equipments' software? > Again, the ability to do=20 > the CP->MP->CP trick would help Except that, as Lyndon and Deborah pointed out, the CP->MP->CP trick has perils of its own. From owner-ccamp@ops.ietf.org Wed Aug 23 12:24:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvWk-0000kP-FP for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:24:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFtWC-0003s3-AP for ccamp-archive@ietf.org; Wed, 23 Aug 2006 10:15:44 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFtHU-0002m4-6e for ccamp-archive@ietf.org; Wed, 23 Aug 2006 10:00:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFt9N-000Dbm-F0 for ccamp-data@psg.com; Wed, 23 Aug 2006 13:52:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFt9K-000DZY-Cg; Wed, 23 Aug 2006 13:52:06 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7NDpQUV012398; Wed, 23 Aug 2006 15:51:26 +0200 In-Reply-To: To: "Diego Caviglia" Cc: "ccamp" , "owner-ccamp" , Adrian Farrel , danli@huawei.com Subject: Re: Polling for new WG I-Ds MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 23 Aug 2006 15:51:23 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/23/2006 15:51:25, Serialize complete at 08/23/2006 15:51:25 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 hi diego - "Diego Caviglia" 23/08/2006 11:13 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Dan Li , "owner-ccamp" Subject: Re: Polling for new WG I-Ds Hi Dimitri, some comments in line. Regards Diego Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 23/08/2006 10.33.10 Sent by: owner-ccamp@ops.ietf.org To: Dan Li cc: Adrian Farrel , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds hi - see inline Dan Li Sent by: owner-ccamp@ops.ietf.org 21/08/2006 04:01 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Hi Dimitri, Please see in line. Regards, Dan ----- Original Message ----- From: To: "Adrian Farrel" Cc: ; Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds [snipped] > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves [dc] I think they or some of them already did this. Looking at the pool seems that at least 4 carries voted yes to the ID. [dp] not sure they express specific opinion on this aspect which is "shall we take care about how to step back from GMPLS ?" it may be the case but then the discussion has much fundamental impact than the discussion around this specific i-d - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) [dc] Of course I think we should. [dp] if i well understand your conclusion putting both of your answers toghether it would mean that CCAMP should take care about how "removing" GMPLS CP ? ... interesting opinion, it took 6 years for CCAMP to have something more or less workable now you and your co-authors are probably trying to init an item to disband this work, if this is the case i don't even understand how we are polling for this document on this list [snipped] From owner-ccamp@ops.ietf.org Wed Aug 23 12:24:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvWy-0001lu-Sw for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:24:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvWx-000498-KE for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:24:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvHo-000OyU-RP for ccamp-data@psg.com; Wed, 23 Aug 2006 16:09:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvHo-000OyA-3S; Wed, 23 Aug 2006 16:09:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 12:08:59 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCw From: "Bryskin, Igor" To: "Brungard, Deborah A, ALABS" , "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Deborah. (My hat off since I am talking to a lady) Have you been in a situation when you just performed a software upgrade = and a network operator tells you that your new release sucks and he = wants the network in the state of this morning prior to the upgrade? No? = Than you are lucky. Besides, what is the problem with moving "hundreds/thousands of LSPs = from CP->MP"?=20 Igor -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Wednesday, August 23, 2006 11:43 AM To: Drake, John E; Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " MP. I'm not sure myself on what is meant by CP->MP, need to discuss more. (chair hat off) Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E Sent: Wednesday, August 23, 2006 11:13 AM To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " =20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 From owner-ccamp@ops.ietf.org Wed Aug 23 12:26:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvYN-00027N-VF for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:26:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvYF-0004bP-LK for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:26:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvQW-000Pgl-2j for ccamp-data@psg.com; Wed, 23 Aug 2006 16:18:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvQT-000PgT-PV for ccamp@ops.ietf.org; Wed, 23 Aug 2006 16:17:57 +0000 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 17:17:56 +0100 Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.58]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Aug 2006 17:17:56 +0100 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 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 17:17:55 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAABz4MA= From: To: X-OriginalArrivalTime: 23 Aug 2006 16:17:56.0150 (UTC) FILETIME=[B148B560:01C6C6CF] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Igor, owner-ccamp@ops.ietf.org <> wrote: > Deborah. > (My hat off since I am talking to a lady) >=20 > Have you been in a situation when you just performed a > software upgrade and a network operator tells you that your > new release sucks and he wants the network in the state of > this morning prior to the upgrade? No? Than you are lucky. I'm not sure I understand the relevance of this. > Besides, what is the problem with moving "hundreds/thousands > of LSPs from CP->MP"? The operating tenet is "if it aint broke don't fix it" so it'd likely have to be a very good reason in order to make an operator move hundreds/thousands of LSPs from CP->MP or MP->CP. It'd also have to be something forseeable as I can't see operators moving their LSPs from CP->MP routinely when doing a software change. Ben =20 From owner-ccamp@ops.ietf.org Wed Aug 23 12:33:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvfA-0006Wh-Af for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:33:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvf9-0006Cy-25 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:33:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvZu-0000dJ-UN for ccamp-data@psg.com; Wed, 23 Aug 2006 16:27:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvZu-0000cw-8T; Wed, 23 Aug 2006 16:27:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 12:16:16 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwAABe1rwAABBhyA= From: "Bryskin, Igor" To: "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 >=20 > JD: Except that we go to great pains to ensure that this=20 > situation never occurs.=20 >=20 > You are right, we do. In theory such situations should not=20 > happen, however, we all know that in practice there are=20 > always cases when original (especially proprietary) protocol=20 > solutions are not thought through enough, and it is=20 > impossible to maintain backward compatibility between the=20 > software releases. That's why I am talking about *major*=20 > upgrades. Furthermore, sometimes there is a need to actually=20 > downgrade software, for instance, when one wants to add to=20 > the network some older equipment. Why would anyone want to do this, especially without upgrading this equipments' software? IB>> Because the new software was developed on the assumption that it = will work on the new hardware. Your customer, on the other hand, = purchased your old equipment and you want to protect his investment. > Again, the ability to do=20 > the CP->MP->CP trick would help Except that, as Lyndon and Deborah pointed out, the CP->MP->CP trick has perils of its own. IB>> Except that they were not specific what those perils are. Igor From owner-ccamp@ops.ietf.org Wed Aug 23 12:33:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvfZ-0006ZY-CT for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:33:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvfX-0006If-HF for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:33:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvZg-0000cg-4x for ccamp-data@psg.com; Wed, 23 Aug 2006 16:27:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.32.69] (helo=blv-smtpout-01.ns.cs.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvZd-0000cJ-DS; Wed, 23 Aug 2006 16:27:25 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7NGRGgV008628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Aug 2006 09:27:21 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7NGRCwx012238; Wed, 23 Aug 2006 09:27:15 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (xch-swbh-04.sw.nos.boeing.com [192.79.11.25]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7NGR6Am012026; Wed, 23 Aug 2006 09:27:06 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 09:27:06 -0700 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 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 09:27:05 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DCFF@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAADc6lA= From: "Drake, John E" To: "Bryskin, Igor" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" X-OriginalArrivalTime: 23 Aug 2006 16:27:06.0081 (UTC) FILETIME=[F9118510:01C6C6D0] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab >=20 > Have you been in a situation when you just performed a=20 > software upgrade and a network operator tells you that your=20 > new release sucks and he wants the network in the state of=20 > this morning prior to the upgrade? No? Than you are lucky. JD: This means reverting to the previous version of control plane software, not the CP->MP->CP detour. >=20 > Besides, what is the problem with moving "hundreds/thousands=20 > of LSPs from CP->MP"?=20 >=20 > Igor >=20 > -----Original Message----- > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > Sent: Wednesday, August 23, 2006 11:43 AM > To: Drake, John E; Bryskin, Igor; Diego Caviglia;=20 > Dimitri.Papadimitriou > Cc: " ccamp " Farrel Subject: RE: Polling for new WG I-Ds >=20 >=20 > Agree with John, and control plane failures don't (should=20 > not/hope not) impact the data plane state. And before doing=20 > such a sw upgrade, I would not want to have to move=20 > hundreds/thousands of LSPs from CP->MP. >=20 > I'm not sure myself on what is meant by CP->MP, need to discuss more. >=20 > (chair hat off) > Deborah=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E > Sent: Wednesday, August 23, 2006 11:13 AM > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou > Cc: " ccamp " Farrel Subject: RE: Polling for new WG I-Ds >=20 > Snipped >=20 > >=20 > > Besides I can see at least one quite real application for > > CP->MP. Imagine that an operator wants to perform some major > > software upgrade with a new software version significantly > > incompatible with the previous one. >=20 > JD: Except that we go to great pains to ensure that this=20 > situation never occurs.=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Aug 23 12:39:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvlf-00028t-J3 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:39:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvle-0007kp-46 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:39:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvh0-0001MB-NN for ccamp-data@psg.com; Wed, 23 Aug 2006 16:35:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.64.48] (helo=slb-smtpout-01.ns.cs.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvgw-0001LT-62; Wed, 23 Aug 2006 16:35:02 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7NGYZpZ019014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Aug 2006 09:34:35 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7NGYtdv029243; Wed, 23 Aug 2006 09:34:57 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (xch-swbh-04.sw.nos.boeing.com [192.79.11.25]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7NGYthc029236; Wed, 23 Aug 2006 09:34:55 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 09:34:55 -0700 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 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 09:34:55 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DD01@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwAABe1rwAABBhyAAAMHGUA== From: "Drake, John E" To: "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" X-OriginalArrivalTime: 23 Aug 2006 16:34:55.0941 (UTC) FILETIME=[11207750:01C6C6D2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Snipped > > Furthermore, sometimes there is a need to actually=20 > > downgrade software, for instance, when one wants to add to=20 > > the network some older equipment. >=20 > Why would anyone want to do this, especially without=20 > upgrading this equipments' software? >=20 > IB>> Because the new software was developed on the assumption that it=20 > IB>> will work on the new hardware. Your customer, on the other hand,=20 > IB>> purchased your old equipment and you want to protect his=20 > IB>> investment. This is not what you said initially. You said 'add to=20 the network some older equipment.' From owner-ccamp@ops.ietf.org Wed Aug 23 12:44:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvqO-00041q-Vg for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:44:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvqE-0008V3-NJ for ccamp-archive@ietf.org; Wed, 23 Aug 2006 12:44:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvlf-0001o2-U0 for ccamp-data@psg.com; Wed, 23 Aug 2006 16:39:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFvle-0001nk-03 for ccamp@ops.ietf.org; Wed, 23 Aug 2006 16:39:50 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GFvlu-0000AC-00 for ccamp@ops.ietf.org; Wed, 23 Aug 2006 17:40:06 +0100 Received: from your029b8cecfe ([217.158.132.141] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 17:39:45 +0100 Message-ID: <0f4401c6c6d2$b986aa40$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Diego Caviglia" , "Dan Li" Cc: "xuhuiying" , "Zafar Ali" , "MEURIC Julien RD-CORE-LAN" , References: Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Date: Wed, 23 Aug 2006 12:49:33 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 23 Aug 2006 16:39:46.0908 (UTC) FILETIME=[BE8E81C0:01C6C6D2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Hi all, The problem statement in this draft is clear, and it seems to me that this problem might arise in a real network depending on the way the network is managed. It is also clear to me that the current signaling protocols handle this type of problem , but that the process is not ideal. That is, LSPs would not necessarily fail to set up, but there might be some exchange of PathErr messages with Acceptable Label Set objects. Since the problem described in the draft is likely to be persistent, this signaling exchange would possibly be required on every LSP setup that uses the link in question. Functional, but not ideal. It would be good if you could add a short sub-section to section 2 to describe how the existing signaling protocols will handle the problem and why you believe that this is not adequate. Now, in general, we don't develop protocol extensions to optimise for error cases, so we have to be careful. If your proposals required continuous monitoring of available resources on each link, that would be a step to far. But if your proposal reflects a start-of-day cross-check followed (optionally) by updates triggered by operator intervention or infrequent timers, that is likely to be acceptable. With regard to the use of existing messages or the definition of new messages: there are architectural and implementation choices. Although we inevitably need to be driven by the implementations, I am not a fan of overloading messages. IMHO the Fault Management messages are currently triggered by a perceived fault: they are used to report and isolated faults. The new function is used to detect faults, not to report or isolate them. While I can see Diego's point that the objective is to find faults, the messages proposed by Dan do not report faults, they report information. Faults are only detected when the correlation between information at the two ends of the link is made. I think that if you wanted to go down the route suggested by Diego you would probably want to limit the information exchanged to only the data channels that are suspect, but I don't see how you can report the channels that are not available (because you might not know about them!) - it is only by hearing about the channels that your partner believes exist that you can deduce problems. In terms of implementation, it really doesn't seem to be very expensive either way. You might want to consider how backward compatibility works with the two options. It is pretty clear how to handle a new message type that is not supported. What will be the impact of adding new TLVs to existing messages? Cheers, Adrian ----- Original Message ----- From: "Diego Caviglia" To: "Dan Li Cc: "xuhuiying" ; "Zafar Ali (zali) ; "MEURIC Julien RD-CORE-LAN ; "ccamp Sent: Wednesday, August 23, 2006 10:31 AM Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, > > Hi Dan, > first of all I think that the ID addresses a real problem. > > Regarding the bits and bytes I prefer to not implemet new messages but > just > updateds the existing ones that seems to fit to the problem. > > I think that having a timeslot that should be usable that is actually > unusable is a failure from the control plane prespective. > > So I think that is correct to use the Fault Management Messages to convey > information about unusable channles. > > Regards > > Diego > > > > Dan Li @ops.ietf.org on 23/08/2006 09.55.49 > > Sent by: owner-ccamp@ops.ietf.org > > > To: xuhuiying@huawei.com, "Zafar Ali (zali)" , MEURIC > Julien RD-CORE-LAN > cc: ccamp > > Subject: Re: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > Hi, > > Thanks Julien and Zafar for your comments. I agree with Julien. This I-D > just wants to provide a control plane tool to detect the inconsistent data > channel status in the tranport plane. > > Actually I have received several private emails think this I-D addresses a > real problem, but regarding the new LMP messages which are introduced in > this I-D, some people pointed out that the already deployed channelstatus > messages (id = 17, 18, 19 and 20) may be extended to carry also the > timeslot information instead only data link. But I have a concern that the > Fault Management Messages usually are triggered by fault detection, these > messages should not be sent if no fault is detected. The confirmation of > data channel status may need to be performed periodically or triggerd by > user. > > I would like to hear from you guys, what's your comments? Not only the > concerns raised above, but also other issues in this I-D. > > Regards, > > Dan > > ----- Original Message ----- > From: "MEURIC Julien RD-CORE-LAN" > To: "Zafar Ali (zali)" ; ; > > Cc: "ccamp" > Sent: Tuesday, July 11, 2006 2:31 AM > Subject: RE: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi Zafar. > > I don't really get you on this. I figure out you're referring to > removing the connection states when RSVP refreshes are not received any > more, aren't you? If so, I'm afraid this is not enough for transmission > devices, where resources can be physically cross-connected even though > there is no (or no longer) corresponding RSVP state. Therefore having a > mechanism to avoid such discrepancies would be welcome. > > Regards, > > Julien > > > P.S.: If you totally rely on a management plane, I agree this should be > useless (e.g. the NMS should already know if a cross-connection deletion > failed, cf. Diego's 2nd slides seen this morning). > > ________________________________ > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Zafar Ali (zali) > > Dear Authors, > > RSVP refreshes do this job, so I am not sure motivation for this draft/ > LMP extensions. > > n.b. The draft state, "Although such a situation can be resolved through > the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], > such a procedure is inefficient since it may require an additional > signaling exchange for each LSP that is set up", so I assume that RSVP > signaling is present (Although I did not understand the quoted statement > from the ID). Even if RSVP is not present, e.g., optical core is > completely controlled by a management entity, I would argue introduce > presence of LMP. > > Thanks > > Regards... Zafar > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 23 13:54:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFww3-0004n5-Bm for ccamp-archive@ietf.org; Wed, 23 Aug 2006 13:54:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFww2-0007bh-2Q for ccamp-archive@ietf.org; Wed, 23 Aug 2006 13:54:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFwly-0007Ad-F0 for ccamp-data@psg.com; Wed, 23 Aug 2006 17:44:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFwlt-0007AK-Jg; Wed, 23 Aug 2006 17:44:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 13:44:07 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAADc6lAAAcILgA== From: "Bryskin, Igor" To: "Drake, John E" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 >=20 > Have you been in a situation when you just performed a=20 > software upgrade and a network operator tells you that your=20 > new release sucks and he wants the network in the state of=20 > this morning prior to the upgrade? No? Than you are lucky. JD: This means reverting to the previous version of control plane software, not the CP->MP->CP detour. IB>> I am talking about the situation when simple reverting is not = possible due to incompatibility of the new and old software releases. Furthermore, on more general note, if we decide that we need to be = capable of doing MP->CP, just from the simmetricity point of view it = makes a lot of sense to me to have CP->MP capability for debugging and = testing the MP->CP move (if for nothing else)=20 Igor >=20 > Besides, what is the problem with moving "hundreds/thousands=20 > of LSPs from CP->MP"?=20 >=20 > Igor >=20 > -----Original Message----- > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > Sent: Wednesday, August 23, 2006 11:43 AM > To: Drake, John E; Bryskin, Igor; Diego Caviglia;=20 > Dimitri.Papadimitriou > Cc: " ccamp " Farrel Subject: RE: Polling for new WG I-Ds >=20 >=20 > Agree with John, and control plane failures don't (should=20 > not/hope not) impact the data plane state. And before doing=20 > such a sw upgrade, I would not want to have to move=20 > hundreds/thousands of LSPs from CP->MP. >=20 > I'm not sure myself on what is meant by CP->MP, need to discuss more. >=20 > (chair hat off) > Deborah=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E > Sent: Wednesday, August 23, 2006 11:13 AM > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou > Cc: " ccamp " Farrel Subject: RE: Polling for new WG I-Ds >=20 > Snipped >=20 > >=20 > > Besides I can see at least one quite real application for > > CP->MP. Imagine that an operator wants to perform some major > > software upgrade with a new software version significantly > > incompatible with the previous one. >=20 > JD: Except that we go to great pains to ensure that this=20 > situation never occurs.=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Aug 23 14:06:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFx7x-0003mg-MC for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:06:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFx7w-0001Hi-0z for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:06:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFwzZ-0008zF-N5 for ccamp-data@psg.com; Wed, 23 Aug 2006 17:58:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFwzY-0008yd-4k for ccamp@ops.ietf.org; Wed, 23 Aug 2006 17:58:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 13:58:12 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAABz4MAAAzIykA== From: "Bryskin, Igor" To: , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Ben, > Deborah. > (My hat off since I am talking to a lady) >=20 > Have you been in a situation when you just performed a > software upgrade and a network operator tells you that your > new release sucks and he wants the network in the state of > this morning prior to the upgrade? No? Than you are lucky. I'm not sure I understand the relevance of this. IB>> Imagine the situation when a major software upgrade was performed = on all network controllers. The new software is significantly different = from the old release. After the upgrade a serious problem was = discovered. The operator wants to go back to the old software. Simple = software reversion is not possible. The operator does not want to loose = any of active services. So what do you do in this case? I say, do = CP->MP->CP > Besides, what is the problem with moving "hundreds/thousands > of LSPs from CP->MP"? The operating tenet is "if it aint broke don't fix it" so it'd likely have to be a very good reason in order to make an operator move hundreds/thousands of LSPs from CP->MP or MP->CP. It'd also have to be something forseeable as I can't see operators moving their LSPs from CP->MP routinely when doing a software change. IB>> From my remark above it should be obvious that I am not talking = about routine CP->MP procedures. I am talking about "Don't stand, do = something" kind of situation. Igor =20 From owner-ccamp@ops.ietf.org Wed Aug 23 14:35:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxZF-0003ov-TN for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:35:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFxZE-000608-Jd for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:35:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxBf-000AaO-HL for ccamp-data@psg.com; Wed, 23 Aug 2006 18:10:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-16.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, USER_IN_DEF_WHITELIST autolearn=no version=3.1.1 Received: from [128.9.160.116] (helo=nit.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxBc-000AZu-Jp for ccamp@ops.ietf.org; Wed, 23 Aug 2006 18:10:44 +0000 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k7NIAfmw030119; Wed, 23 Aug 2006 11:10:41 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k7NIAeF3030118; Wed, 23 Aug 2006 11:10:40 -0700 Date: Wed, 23 Aug 2006 11:10:40 -0700 Message-Id: <200608231810.k7NIAeF3030118@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4606 on Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 A new Request for Comments is now available in online RFC libraries. RFC 4606 Title: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control Author: E. Mannie, D. Papadimitriou Status: Standards Track Date: August 2006 Mailbox: eric.mannie@perceval.net, dimitri.papadimitriou@alcatel.be Pages: 25 Characters: 53492 Obsoletes: RFC3946 See-Also: I-D Tag: draft-ietf-ccamp-rfc3946bis-01.txt URL: http://www.rfc-editor.org/rfc/rfc4606.txt This document provides minor clarification to RFC 3946. This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when GMPLS signaling is used. [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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... From owner-ccamp@ops.ietf.org Wed Aug 23 14:49:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxnS-0003m7-Dy for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:49:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFxnQ-0002E1-0C for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:49:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxd0-000D0j-MU for ccamp-data@psg.com; Wed, 23 Aug 2006 18:39:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [216.82.245.131] (helo=mail146.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxcy-000D0Q-2q; Wed, 23 Aug 2006 18:39:00 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-10.tower-146.messagelabs.com!1156358175!630493!62 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2627 invoked from network); 23 Aug 2006 18:38:58 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-10.tower-146.messagelabs.com with SMTP; 23 Aug 2006 18:38:58 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 44E128F500152BB2; Wed, 23 Aug 2006 14:38:58 -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 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 13:38:57 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0CA60BBC@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAAVIZKA= From: "Brungard, Deborah A, ALABS" To: "Bryskin, Igor" , "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Hi Igor- comments below (as >db, chair hat off)=20 -----Original Message----- From: Bryskin, Igor [mailto:ibryskin@movaz.com]=20 Sent: Wednesday, August 23, 2006 12:09 PM To: Brungard, Deborah A, ALABS; Drake, John E; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " thanks;-) Have you been in a situation when you just performed a software upgrade and a network operator tells you that your new release sucks and he wants the network in the state of this morning prior to the upgrade? No? Than you are lucky. Db> that is totally different from this discussion, hopefully they know what a backup is (for your benefit), and also one does not necessarily want to use the backup since there could have been changes in the network since the backup was made, unless the network is static;-) Would stongly suggest you (and the operator) have done sufficient testing. Besides, what is the problem with moving "hundreds/thousands of LSPs from CP->MP"?=20 Db> Good joke;-) Igor -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Wednesday, August 23, 2006 11:43 AM To: Drake, John E; Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " MP. I'm not sure myself on what is meant by CP->MP, need to discuss more. (chair hat off) Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E Sent: Wednesday, August 23, 2006 11:13 AM To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " =20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 From owner-ccamp@ops.ietf.org Wed Aug 23 14:54:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxra-0007yP-PT for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:54:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFxrU-0004NR-EO for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:54:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxhf-000DPH-U3 for ccamp-data@psg.com; Wed, 23 Aug 2006 18:43:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxha-000DOw-LX for ccamp@ops.ietf.org; Wed, 23 Aug 2006 18:43:46 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GFxhS-0000Jo-00 for ccamp@ops.ietf.org; Wed, 23 Aug 2006 19:43:38 +0100 Received: from your029b8cecfe ([217.158.132.54] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 19:43:40 +0100 Message-ID: <0fbe01c6c6e4$0af04740$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Snigdho Bardalai" , Cc: "ccamp" , "Dan Li" , "MEURIC Julien RD-CORE-LAN" , References: Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Date: Wed, 23 Aug 2006 19:43:27 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 23 Aug 2006 18:43:40.0739 (UTC) FILETIME=[0D771930:01C6C6E4] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Dimitri, I think you are focusing in too closely on an example of how the problem can arise. The problem is simply that it is possible that the resources are not available in the same way at both ends of the link. The discussion then went down the path of how this might arise, and we have become stuck in a detailed example. Perhaps a better example would be the failure of a hardware component that is represents a label on the TE link, where the failure is known at the local node, but cannot be communicated to the remote node. But related to your specific discussion... > i am not sure to capture your point - let's say states are self-refreshed > for some time, if the signaling channel is not up before pre-negotiated > time - and you didn't fix this timer as being infinite - resources will be > released when the cleanup elapses So you are saying that there is a timer that can be set on the Hello such that if the Hello adjacency is not re-established in that time, all LSPs should be torn down. Yes. This is the Restart Cap object Restart Time. But you say if "you didn't fix this timer as being infinite". But actually let's think about how operators like to use this timer. Sure they can say, I expect the CP to restart after a fault in 10 minutes, but wht about hardware faults? The CPU running the CP could fry, that is likely to require a truck roll, and the user traffic must not be torn down just because of this fault. So the Restart Time is typically set quite large. You will hear many people say that the user traffic is absolute - it must never be torn down because of a CP failure - and these people set the Restart Timer to all-f. Now, once the time has been set large, we don't have automatic cleanup. So the cross-connects can get into a mess. > in case one requires larger maintenance > windows one provides such configuration beforehand But note that this is not planned maintenance. > mis-using one > mechanism and then require another to reconstruct consistent states is the > first point that needs to be clarified So, are you saying that my description, above, represents a mis-use? If so, how should I configure the Restart Time so that I can survive long CP outages? > (it is also important to clarify > that LMP does not "reserve resources" it just mediates data link states so > if the error needs to be corrected it will any interfere with the entity > that is making use of it Completely agree with this point. LMP can report problems, but cannot fix them. > what you are trying to achieve is detect mismatch but detect these mismach > is not a solution to the problem Agree completely. What you have suggested before is that prevention is sufficient. What I believe is that prevention of all cases is probably not possible, therefore detection and cure will be needed. Detection (you are right) is not the same as cure. But cure without detection is improbable. Note that cure is not necessarily the objective! There is a separate problem (sending Path with bad choice of label) that can be prevented after detection, without the need for cure. Cure probably reuqires operator intervention. > but more importantly what is the trigger > to the detection itself? in brief how does one either of these sides > knows it should start such "verification" process ... was it not at the > end the reason for possibility of maintaining the "available" link on > permanent verification state within LMP ? Understanding the trigger for the detection process is important. Section 4 of the I-D currently says: The data channel status confirmation related LMP messages are sent between adjacent nodes periodically or driven by some events and this is not enough. We would need to know some more about the "period" and the "events" to assess whether this is going to flood the control channel or not provide the information in a timely manner. For example, one could use the receipt of an Acceptable Label Set object (and some parsing thereof) as a trigger event. Cheers, Adrian From owner-ccamp@ops.ietf.org Wed Aug 23 15:47:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFyhP-0002sn-N5 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 15:47:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFyhJ-00015J-UW for ccamp-archive@ietf.org; Wed, 23 Aug 2006 15:47:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFyZZ-000HrO-CY for ccamp-data@psg.com; Wed, 23 Aug 2006 19:39:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.64.48] (helo=slb-smtpout-01.ns.cs.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFyZT-000Hqt-Mz; Wed, 23 Aug 2006 19:39:27 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7NJd4to008091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Aug 2006 12:39:04 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7NJdNIs029827; Wed, 23 Aug 2006 12:39:26 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (xch-swbh-04.sw.nos.boeing.com [192.79.11.25]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7NJdL7m029666; Wed, 23 Aug 2006 12:39:21 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 12:39:20 -0700 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 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 12:39:19 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DD04@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAADc6lAAAcILgAAEmuJg From: "Drake, John E" To: "Bryskin, Igor" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" X-OriginalArrivalTime: 23 Aug 2006 19:39:20.0121 (UTC) FILETIME=[D3E45A90:01C6C6EB] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 >=20 > JD: This means reverting to the previous version of control=20 > plane software, not the CP->MP->CP detour. >=20 > IB>> I am talking about the situation when simple reverting is not=20 > IB>> possible due to incompatibility of the new and old software=20 > IB>> releases. JD: This is the first time you have mentioned that you are assuming that this reversion is not possible. I think this is total nonsense for two reasons. 1) I don't believe technically that this reversion would ever *not* be possible. Otherwise, I don't see how the new software could have been incrementally deployed in the first place. 2) The operator would never deploy the new software unless had had verified that it could be backed out. Further, why would new CP->MP->old CP work when new CP->old CP would not work? >=20 > Furthermore, on more general note, if we decide that we need=20 > to be capable of doing MP->CP, just from the simmetricity=20 > point of view it makes a lot of sense to me to have CP->MP=20 > capability for debugging and testing the MP->CP move (if for=20 > nothing else)=20 >=20 > Igor >=20 > >=20 > > Besides, what is the problem with moving "hundreds/thousands > > of LSPs from CP->MP"?=20 > >=20 > > Igor > >=20 > > -----Original Message----- > > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > Sent: Wednesday, August 23, 2006 11:43 AM > > To: Drake, John E; Bryskin, Igor; Diego Caviglia; > > Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > >=20 > > Agree with John, and control plane failures don't (should > > not/hope not) impact the data plane state. And before doing=20 > > such a sw upgrade, I would not want to have to move=20 > > hundreds/thousands of LSPs from CP->MP. > >=20 > > I'm not sure myself on what is meant by CP->MP, need to=20 > discuss more. > >=20 > > (chair hat off) > > Deborah > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E > > Sent: Wednesday, August 23, 2006 11:13 AM > > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > > Snipped > >=20 > > >=20 > > > Besides I can see at least one quite real application for > > > CP->MP. Imagine that an operator wants to perform some major > > > software upgrade with a new software version significantly=20 > > > incompatible with the previous one. > >=20 > > JD: Except that we go to great pains to ensure that this > > situation never occurs.=20 > >=20 > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Wed Aug 23 16:32:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFzP7-0005er-Ma for ccamp-archive@ietf.org; Wed, 23 Aug 2006 16:32:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFxRN-0004IF-W1 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:27:02 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFxNs-0007wC-5g for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:23:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxDr-000AnM-AA for ccamp-data@psg.com; Wed, 23 Aug 2006 18:13:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME,SORTED_RECIPS autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxDo-000Amg-Dh; Wed, 23 Aug 2006 18:13:00 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7NICqM3013256; Wed, 23 Aug 2006 20:12:52 +0200 In-Reply-To: <44EC7EE8.70402@us.fujitsu.com> To: Snigdho Bardalai Cc: ccamp , Dan Li , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 23 Aug 2006 20:12:49 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/23/2006 20:12:51, Serialize complete at 08/23/2006 20:12:51 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.1 (--) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c hi - i am not sure to capture your point - let's say states are self-refreshed for some time, if the signaling channel is not up before pre-negotiated time - and you didn't fix this timer as being infinite - resources will be released when the cleanup elapses, in case one requires larger maintenance windows one provides such configuration beforehand => mis-using one mechanism and then require another to reconstruct consistent states is the first point that needs to be clarified (it is also important to clarify that LMP does not "reserve resources" it just mediates data link states so if the error needs to be corrected it will any interfere with the entituy that is making use of it what you are trying to achieve is detect mismatch but detect these mismach is not a solution to the problem but more importantly what is the trigger to the detection itself ? in brief how does one either of these sides knows it should start such "verification" process ... was it not at the end the reason for possibility of maintaining the "available" link on permanent verification state within LMP ? thanks, -d. Snigdho Bardalai 23/08/2006 18:14 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Dan Li , ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi Dimitri, Since a control-channel failure leads to RSVP hello failure the clean-up timeout event will not occur (due to auto-refresh). In case an intermediate or egress node initiates the deletion process and there is a temporary control-plane failure that disallows the delete request from reaching the ingress node, then there is a potential problem. Even though the intermediate or egress node initiates the force deletion process after the "no-response" timer expires the connection may get re-created once the control-plane recovers, because the ingress may continuously be transmitting Path messages. Even if the Path message contains the RECOVERY object, this will cause re-creation of the connection (Refer to RFC 3473 Section 9.5.2). One posible solution is to carry out a channel-status audit in order to detect such anamolies. Regards, Snigdho Dimitri.Papadimitriou@alcatel.be wrote: >just a brief remark > >i don't see why channel status verification can not be achieved with >current mechanism described in section 12.7 of 4204 (and there is a >need to come with a complete set of messages for this purpose) > >now i am even unclear how the problem you stated can occur > >"The channel status of a data link may become mismatched during the > LSP deletion process. If the LSP deletion process is aborted in the > middle of the process (perhaps because of a temporary control plane > failure), the cross-connection at the upstream node may be removed > while the downstream node still keeps its cross-connection." > >why do you think the notion of soft-state has been introduced ? once >the cleanup timeout (set to K times the refresh timeout) interval is >reached that then triggers a tear-down > >thanks, >- d. > > > > > > >Dan Li >Sent by: owner-ccamp@ops.ietf.org >23/08/2006 09:55 > > To: xuhuiying@huawei.com, "Zafar Ali (zali)" , >MEURIC Julien RD-CORE-LAN > cc: ccamp > Subject: Re: High level comment on >draft-li-ccamp-confirm-data-channel-status-00.txt, > > >Hi, > >Thanks Julien and Zafar for your comments. I agree with Julien. This I-D >just wants to provide a control plane tool to detect the inconsistent data >channel status in the tranport plane. > >Actually I have received several private emails think this I-D addresses a >real problem, but regarding the new LMP messages which are introduced in >this I-D, some people pointed out that the already deployed channelstatus >messages (id = 17, 18, 19 and 20) may be extended to carry also the >timeslot information instead only data link. But I have a concern that the >Fault Management Messages usually are triggered by fault detection, these >messages should not be sent if no fault is detected. The confirmation of >data channel status may need to be performed periodically or triggerd by >user. > >I would like to hear from you guys, what's your comments? Not only the >concerns raised above, but also other issues in this I-D. > >Regards, > >Dan > >----- Original Message ----- >From: "MEURIC Julien RD-CORE-LAN" >To: "Zafar Ali (zali)" ; ; > >Cc: "ccamp" >Sent: Tuesday, July 11, 2006 2:31 AM >Subject: RE: High level comment on >draft-li-ccamp-confirm-data-channel-status-00.txt, > > >Hi Zafar. > >I don't really get you on this. I figure out you're referring to >removing the connection states when RSVP refreshes are not received any >more, aren't you? If so, I'm afraid this is not enough for transmission >devices, where resources can be physically cross-connected even though >there is no (or no longer) corresponding RSVP state. Therefore having a >mechanism to avoid such discrepancies would be welcome. > >Regards, > >Julien > > >P.S.: If you totally rely on a management plane, I agree this should be >useless (e.g. the NMS should already know if a cross-connection deletion >failed, cf. Diego's 2nd slides seen this morning). > >________________________________ > > >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of Zafar Ali (zali) > >Dear Authors, > >RSVP refreshes do this job, so I am not sure motivation for this draft/ >LMP extensions. > >n.b. The draft state, "Although such a situation can be resolved through >the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], >such a procedure is inefficient since it may require an additional >signaling exchange for each LSP that is set up", so I assume that RSVP >signaling is present (Although I did not understand the quoted statement >from the ID). Even if RSVP is not present, e.g., optical core is >completely controlled by a management entity, I would argue introduce >presence of LMP. > >Thanks > >Regards... Zafar > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 23 16:44:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFza8-0004ZR-FF for ccamp-archive@ietf.org; Wed, 23 Aug 2006 16:44:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFxRv-0004OR-L9 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:27:35 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFxFC-0007ds-3U for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:14:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFx6r-000A9S-N0 for ccamp-data@psg.com; Wed, 23 Aug 2006 18:05:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFx6o-000A8o-46; Wed, 23 Aug 2006 18:05:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 14:05:41 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwAABe1rwAABBhyAAAMHGUAADCWqA From: "Bryskin, Igor" To: "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.9 (-) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Snipped > > Furthermore, sometimes there is a need to actually=20 > > downgrade software, for instance, when one wants to add to=20 > > the network some older equipment. >=20 > Why would anyone want to do this, especially without=20 > upgrading this equipments' software? >=20 > IB>> Because the new software was developed on the assumption that it=20 > IB>> will work on the new hardware. Your customer, on the other hand,=20 > IB>> purchased your old equipment and you want to protect his=20 > IB>> investment. This is not what you said initially. You said 'add to=20 the network some older equipment.' IB>> No, that's exactly what I meant. My customer purchased a ring of = new devices with new software. The customer also happens to have several = rings of older devices running older software. The customer wants to = interconnect the new rings with old ones. The customer does not mind to = downgrade the software on the new ring so that it will be compatible = with other rings. Igor From owner-ccamp@ops.ietf.org Wed Aug 23 16:56:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFzlv-0001ph-4e for ccamp-archive@ietf.org; Wed, 23 Aug 2006 16:56:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFxRO-0004IF-3D for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:27:02 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFxNn-0007w6-2K for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:23:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxI5-000BGV-QQ for ccamp-data@psg.com; Wed, 23 Aug 2006 18:17:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [192.240.0.2] (helo=fujitsu2.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxI3-000BGD-9V for ccamp@ops.ietf.org; Wed, 23 Aug 2006 18:17:23 +0000 Received: from fujitsu2.fujitsu.com (localhost [127.0.0.1]) by fujitsu2.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7NIHK4L019017; Wed, 23 Aug 2006 11:17:20 -0700 (PDT) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu2.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7NIHI2p018995; Wed, 23 Aug 2006 11:17:19 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7NIHFn8013625; Wed, 23 Aug 2006 11:17:15 -0700 (PDT) Received: from [133.164.59.59] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k7NIH8w21552; Wed, 23 Aug 2006 11:17:08 -0700 (PDT) Message-ID: <44EC9B9E.3030505@us.fujitsu.com> Date: Wed, 23 Aug 2006 11:17:02 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: benjamin.niven-jenkins@bt.com CC: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Ben, see inline. benjamin.niven-jenkins@bt.com wrote: > Igor, > > owner-ccamp@ops.ietf.org <> wrote: > >> Deborah. >> (My hat off since I am talking to a lady) >> >> Have you been in a situation when you just performed a >> software upgrade and a network operator tells you that your >> new release sucks and he wants the network in the state of >> this morning prior to the upgrade? No? Than you are lucky. >> > > I'm not sure I understand the relevance of this. > > >> Besides, what is the problem with moving "hundreds/thousands >> of LSPs from CP->MP"? >> > > The operating tenet is "if it aint broke don't fix it" so it'd likely > have to be a very good reason in order to make an operator move > hundreds/thousands of LSPs from CP->MP or MP->CP. I guess the jury is still out w/r to CP->MP as the discussion on the ML shows; but w/r to MP->CP, when an operator decides to deploy a CP, then control functions that resided in the MP should be delegated to that CP. There needs to be a migration strategy for that operation. > It'd also have to be > something forseeable as I can't see operators moving their LSPs from > CP->MP routinely when doing a software change. > I believe the authors were concerned about error handling and are not talking about this as a routine operation > Ben Richard. From owner-ccamp@ops.ietf.org Wed Aug 23 17:28:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0Ge-0004cg-Ce for ccamp-archive@ietf.org; Wed, 23 Aug 2006 17:28:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFyAo-0000B4-A2 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 15:13:58 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFxsC-0000bf-30 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 14:54:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxmE-000Doj-Fb for ccamp-data@psg.com; Wed, 23 Aug 2006 18:48:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFxmD-000DoO-12; Wed, 23 Aug 2006 18:48:33 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 14:48:31 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAAVIZKAAAGTkkA== From: "Bryskin, Igor" To: "Brungard, Deborah A, ALABS" , "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.1 (--) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Deborah, Have you been in a situation when you just performed a software upgrade and a network operator tells you that your new release sucks and he wants the network in the state of this morning prior to the upgrade? No? Than you are lucky. Db> that is totally different from this discussion, hopefully they know what a backup is (for your benefit), and also one does not necessarily want to use the backup since there could have been changes in the network since the backup was made, unless the network is static;-)=20 IB>> Exactly my point. If you can not or don't wnat to use backup, what = is the way out of this mess? Igor Would stongly suggest you (and the operator) have done sufficient testin Besides, what is the problem with moving "hundreds/thousands of LSPs from CP->MP"?=20 Db> Good joke;-) Igor -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Wednesday, August 23, 2006 11:43 AM To: Drake, John E; Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " MP. I'm not sure myself on what is meant by CP->MP, need to discuss more. (chair hat off) Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E Sent: Wednesday, August 23, 2006 11:13 AM To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " =20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 From owner-ccamp@ops.ietf.org Wed Aug 23 17:32:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0KX-0000JT-Ar for ccamp-archive@ietf.org; Wed, 23 Aug 2006 17:32:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG0KV-00010v-0T for ccamp-archive@ietf.org; Wed, 23 Aug 2006 17:32:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GG08n-000OY2-4I for ccamp-data@psg.com; Wed, 23 Aug 2006 21:20:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GG08h-000OVg-KB; Wed, 23 Aug 2006 21:19:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 17:06:31 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAADc6lAAAcILgAAEmuJgAAKhLdA= From: "Bryskin, Igor" To: "Drake, John E" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 >=20 > JD: This means reverting to the previous version of control=20 > plane software, not the CP->MP->CP detour. >=20 > IB>> I am talking about the situation when simple reverting is not=20 > IB>> possible due to incompatibility of the new and old software=20 > IB>> releases. JD: This is the first time you have mentioned that you are assuming that this reversion is not possible. I think this is total nonsense for two reasons. 1) I don't believe technically that this reversion would ever *not* be possible. Otherwise, I don't see how the new software could have been incrementally deployed in the first place. 2) The operator would never deploy the new software unless had had verified that it could be backed out. =20 IB>> Agree, I probably should have said *not feasible* instead of *not = possible*. Imagine that the new CP was run for 1 month before the = problem was encountered. Using backup of old CP would mean loosing all = services that were provisioned within this period. Likewise, if one made = the MP->CP move, worked for some time and then discovered a problem, = using old MP backups would mean loosing all services that were = dynamically created or modified. CP->MP move would solve the problem. Further, why would new CP->MP->old CP work when new CP->old CP would not work? IB>> Because you can not perform new CP->old CP conversion = simultameously on all nodes. Igor >=20 > Furthermore, on more general note, if we decide that we need=20 > to be capable of doing MP->CP, just from the simmetricity=20 > point of view it makes a lot of sense to me to have CP->MP=20 > capability for debugging and testing the MP->CP move (if for=20 > nothing else)=20 >=20 > Igor >=20 > >=20 > > Besides, what is the problem with moving "hundreds/thousands > > of LSPs from CP->MP"?=20 > >=20 > > Igor > >=20 > > -----Original Message----- > > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > Sent: Wednesday, August 23, 2006 11:43 AM > > To: Drake, John E; Bryskin, Igor; Diego Caviglia; > > Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > >=20 > > Agree with John, and control plane failures don't (should > > not/hope not) impact the data plane state. And before doing=20 > > such a sw upgrade, I would not want to have to move=20 > > hundreds/thousands of LSPs from CP->MP. > >=20 > > I'm not sure myself on what is meant by CP->MP, need to=20 > discuss more. > >=20 > > (chair hat off) > > Deborah > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E > > Sent: Wednesday, August 23, 2006 11:13 AM > > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > > Snipped > >=20 > > >=20 > > > Besides I can see at least one quite real application for > > > CP->MP. Imagine that an operator wants to perform some major > > > software upgrade with a new software version significantly=20 > > > incompatible with the previous one. > >=20 > > JD: Except that we go to great pains to ensure that this > > situation never occurs.=20 > >=20 > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Wed Aug 23 19:21:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG22j-0005Lg-7c for ccamp-archive@ietf.org; Wed, 23 Aug 2006 19:21:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFzOQ-0008Hf-EU for ccamp-archive@ietf.org; Wed, 23 Aug 2006 16:32:06 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFz08-0002zN-VJ for ccamp-archive@ietf.org; Wed, 23 Aug 2006 16:07:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFykU-000ItE-TF for ccamp-data@psg.com; Wed, 23 Aug 2006 19:50:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.96.56] (helo=stl-smtpout-01.ns.cs.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GFykT-000Iso-5i; Wed, 23 Aug 2006 19:50:49 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7NJofwa011086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Aug 2006 14:50:41 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7NJodNm013081; Wed, 23 Aug 2006 14:50:41 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (xch-swbh-04.sw.nos.boeing.com [192.79.11.25]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7NJoRR5012489; Wed, 23 Aug 2006 14:50:27 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 12:50:15 -0700 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 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 12:50:15 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DD05@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwAABe1rwAABBhyAAAMHGUAADCWqAAAOAwPA= From: "Drake, John E" To: "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" X-OriginalArrivalTime: 23 Aug 2006 19:50:15.0740 (UTC) FILETIME=[5AABDFC0:01C6C6ED] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d >=20 > > > Furthermore, sometimes there is a need to actually > > > downgrade software, for instance, when one wants to add to=20 > > > the network some older equipment. > >=20 > > Why would anyone want to do this, especially without > > upgrading this equipments' software? > >=20 > > IB>> Because the new software was developed on the=20 > assumption that it > > IB>> will work on the new hardware. Your customer, on the=20 > other hand,=20 > > IB>> purchased your old equipment and you want to protect his=20 > > IB>> investment. >=20 > This is not what you said initially. You said 'add to=20 > the network some older equipment.' >=20 > IB>> No, that's exactly what I meant. My customer purchased a ring of=20 > IB>> new devices with new software. The customer also happens to have=20 > IB>> several rings of older devices running older software.=20 > The customer=20 > IB>> wants to interconnect the new rings with old ones. The customer=20 > IB>> does not mind to downgrade the software on the new ring=20 > so that it=20 > IB>> will be compatible with other rings. As I said previously, the situation you are describing above is *not* the same as 'add to=20 the network some older equipment.' What you are describing is adding new equipment to an existing network, and there are many options for doing this, but going from CP->MP is not one of them. If the existing equipment was deployed with an MP and you didn't want to upgrade it to CP, you would just deploy the new equipment with MP from the beginning. =20 >=20 > Igor >=20 From owner-ccamp@ops.ietf.org Wed Aug 23 19:32:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2Cs-0001qA-4T for ccamp-archive@ietf.org; Wed, 23 Aug 2006 19:32:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG2Cl-00071M-K3 for ccamp-archive@ietf.org; Wed, 23 Aug 2006 19:32:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GG26J-00063p-Ho for ccamp-data@psg.com; Wed, 23 Aug 2006 23:25:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.32.69] (helo=blv-smtpout-01.ns.cs.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GG26D-00062S-Nf; Wed, 23 Aug 2006 23:25:29 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7NNOXOp018243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Aug 2006 16:24:38 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7NNOVl2029695; Wed, 23 Aug 2006 16:24:33 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (xch-swbh-04.sw.nos.boeing.com [192.79.11.25]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7NNOSrA029598; Wed, 23 Aug 2006 16:24:28 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 16:24:28 -0700 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 Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 16:24:27 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DD0C@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAADc6lAAAcILgAAEmuJgAAKhLdAABNoRkA== From: "Drake, John E" To: "Bryskin, Igor" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" X-OriginalArrivalTime: 23 Aug 2006 23:24:28.0626 (UTC) FILETIME=[4796A320:01C6C70B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 >=20 > JD: This means reverting to the previous version of control > plane software, not the CP->MP->CP detour. >=20 > IB>> I am talking about the situation when simple reverting is not > IB>> possible due to incompatibility of the new and old software=20 > IB>> releases. JD: This is the first time you have mentioned that you are assuming that this reversion is not possible. I think this is total nonsense for two reasons. 1) I don't believe technically that this reversion would ever *not* be possible. Otherwise, I don't see how the new software could have been incrementally deployed in the first place. 2) The operator would never deploy the new software unless had had verified that it could be backed out. =20 IB>> Agree, I probably should have said *not feasible* instead of *not=20 IB>> possible*. Imagine that the new CP was run for 1 month before the=20 IB>> problem was encountered. Using backup of old CP would mean loosing=20 IB>> all services that were provisioned within this period. JD: Let me guess. You are now making the further assumption that the databases of the old and new CPs are completely incompatible. As I indicated above, if incremental deployment and incremental roll back are not supported, the new CP will never be deployed. It's not like there is anything new here. IB>> Likewise, if=20 IB>> one made the MP->CP move, worked for some time and then discovered=20 IB>> a problem, using old MP backups would mean loosing all services=20 IB>> that were dynamically created or modified. JD: What are you talking about? We are discussing a CP update. IB>> CP->MP move would solve=20 IB>> the problem. JD: Completely unsupported assertion. Further, why would new CP->MP->old CP work when new CP->old CP would not work? IB>> Because you can not perform new CP->old CP conversion=20 IB>> simultameously on all nodes. JD: You cannot perform new CP->MP conversion simultaneously on all nodes either, and there is no reason to assume that simultaneous new CP->old CP conversion is required. Igor >=20 > Furthermore, on more general note, if we decide that we need > to be capable of doing MP->CP, just from the simmetricity=20 > point of view it makes a lot of sense to me to have CP->MP=20 > capability for debugging and testing the MP->CP move (if for=20 > nothing else)=20 >=20 > Igor >=20 > >=20 > > Besides, what is the problem with moving "hundreds/thousands of LSPs > > from CP->MP"? > >=20 > > Igor > >=20 > > -----Original Message----- > > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > Sent: Wednesday, August 23, 2006 11:43 AM > > To: Drake, John E; Bryskin, Igor; Diego Caviglia;=20 > > Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > >=20 > > Agree with John, and control plane failures don't (should not/hope=20 > > not) impact the data plane state. And before doing such a sw=20 > > upgrade, I would not want to have to move hundreds/thousands of LSPs > > from CP->MP. > >=20 > > I'm not sure myself on what is meant by CP->MP, need to > discuss more. > >=20 > > (chair hat off) > > Deborah > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of Drake, John E > > Sent: Wednesday, August 23, 2006 11:13 AM > > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > > Snipped > >=20 > > >=20 > > > Besides I can see at least one quite real application for > > > CP->MP. Imagine that an operator wants to perform some major > > > software upgrade with a new software version significantly > > > incompatible with the previous one. > >=20 > > JD: Except that we go to great pains to ensure that this situation=20 > > never occurs. > >=20 > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Thu Aug 24 02:39:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG8rk-0002jG-S3 for ccamp-archive@ietf.org; Thu, 24 Aug 2006 02:39:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG8rj-0004fX-DP for ccamp-archive@ietf.org; Thu, 24 Aug 2006 02:39:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GG8l4-000HD5-SY for ccamp-data@psg.com; Thu, 24 Aug 2006 06:32:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GG8l2-000HCg-Of; Thu, 24 Aug 2006 06:32:05 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4H00KMAP74XI@szxga03-in.huawei.com>; Thu, 24 Aug 2006 14:40:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4H005QDP73DO@szxga03-in.huawei.com>; Thu, 24 Aug 2006 14:40:16 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4H00BC5P9YXW@szxml04-in.huawei.com>; Thu, 24 Aug 2006 14:41:58 +0800 (CST) Date: Thu, 24 Aug 2006 14:29:47 +0800 From: Dan Li Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Message-id: <019001c6c746$b24bfb80$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Hi Dimitri, Please see in-line. Regards, Dan ----- Original Message ----- From: To: "Dan Li" Cc: "ccamp" ; "MEURIC Julien RD-CORE-LAN" ; ; ; "Zafar Ali (zali)" Sent: Wednesday, August 23, 2006 8:45 PM Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, > just a brief remark > > i don't see why channel status verification can not be achieved with > current mechanism described in section 12.7 of 4204 (and there is a > need to come with a complete set of messages for this purpose) > [dan] I agree that the LMP messages (17, 18, 19) can do the channel status verification with some extensions. My concern is that these messages are used for the fault management, but the inconsistent data channel status may be is not a failure, for example it may be configured on purpose. > now i am even unclear how the problem you stated can occur > > "The channel status of a data link may become mismatched during the > LSP deletion process. If the LSP deletion process is aborted in the > middle of the process (perhaps because of a temporary control plane > failure), the cross-connection at the upstream node may be removed > while the downstream node still keeps its cross-connection." > > why do you think the notion of soft-state has been introduced ? once > the cleanup timeout (set to K times the refresh timeout) interval is > reached that then triggers a tear-down > [dan] In optical transport networks, the control plane failure should not affect the traffic carried by the transport plane. So usually the cross-connect in the transport plane will not be removed when there is a failure in the control plane, that's why I stated the problem described in this I-D is real. > thanks, > - d. > > > > > > > Dan Li > Sent by: owner-ccamp@ops.ietf.org > 23/08/2006 09:55 > > To: xuhuiying@huawei.com, "Zafar Ali (zali)" , > MEURIC Julien RD-CORE-LAN > cc: ccamp > Subject: Re: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi, > > Thanks Julien and Zafar for your comments. I agree with Julien. This I-D > just wants to provide a control plane tool to detect the inconsistent data > channel status in the tranport plane. > > Actually I have received several private emails think this I-D addresses a > real problem, but regarding the new LMP messages which are introduced in > this I-D, some people pointed out that the already deployed channelstatus > messages (id = 17, 18, 19 and 20) may be extended to carry also the > timeslot information instead only data link. But I have a concern that the > Fault Management Messages usually are triggered by fault detection, these > messages should not be sent if no fault is detected. The confirmation of > data channel status may need to be performed periodically or triggerd by > user. > > I would like to hear from you guys, what's your comments? Not only the > concerns raised above, but also other issues in this I-D. > > Regards, > > Dan > > ----- Original Message ----- > From: "MEURIC Julien RD-CORE-LAN" > To: "Zafar Ali (zali)" ; ; > > Cc: "ccamp" > Sent: Tuesday, July 11, 2006 2:31 AM > Subject: RE: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi Zafar. > > I don't really get you on this. I figure out you're referring to > removing the connection states when RSVP refreshes are not received any > more, aren't you? If so, I'm afraid this is not enough for transmission > devices, where resources can be physically cross-connected even though > there is no (or no longer) corresponding RSVP state. Therefore having a > mechanism to avoid such discrepancies would be welcome. > > Regards, > > Julien > > > P.S.: If you totally rely on a management plane, I agree this should be > useless (e.g. the NMS should already know if a cross-connection deletion > failed, cf. Diego's 2nd slides seen this morning). > > ________________________________ > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Zafar Ali (zali) > > Dear Authors, > > RSVP refreshes do this job, so I am not sure motivation for this draft/ > LMP extensions. > > n.b. The draft state, "Although such a situation can be resolved through > the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], > such a procedure is inefficient since it may require an additional > signaling exchange for each LSP that is set up", so I assume that RSVP > signaling is present (Although I did not understand the quoted statement > from the ID). Even if RSVP is not present, e.g., optical core is > completely controlled by a management entity, I would argue introduce > presence of LMP. > > Thanks > > Regards... Zafar > > > > From jetmail999oooku@yahoo.com Thu Aug 24 03:11:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG9NR-0000RD-Ou for CCAMP-ARCHIVE@MEGATRON.IETF.ORG; Thu, 24 Aug 2006 03:11:45 -0400 Received: from [60.14.178.182] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG9NP-0001Hm-D2 for CCAMP-ARCHIVE@MEGATRON.IETF.ORG; Thu, 24 Aug 2006 03:11:45 -0400 Subject: =?iso-2022-jp?B?GyRCIVobKEI4LzMxGyRCJF4kRyRONHw0VjhCRGohKiFbGyhC?= From: =?gb2312?B?Q0FNUEFJR05fUFJFU0VOVCE=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C6C6E5.1753B4D0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C6C6E5.1753B4D0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCISEiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoISElVSVqITwlYSE8JWskSDhA JCgkUCEhISEhIU14TVE8VDdjQX1DZiROJTklXiVDJTclZSVhITwlayEqISEhISIoIigiKCIoIigi KCIoIigiKCIoIigiKCIoIigiKCIoIigbKEI4LzMxGyRCJF4kRyRONHw0VjhCRGokTiFaJTUlXiE8 NkMkLSUtJWMlcyVaITwlcyVXJWwlPCVzJUghKiFbPEI7XENmJEckOSEqQCdIcyQzJE41ITJxJEsj RyNFI1QkNyRGMjwkNSQkISohITB6JC1CMyQtIVobKEJUT1AbJEIlWiE8JTghISVqJUslZSE8JSIl a0NmISohWxsoQg0KVE9QGyRCJVohPCU4JWolSyVlITwlIiVrQ2YkS0lVJC0bKEINChskQiQqOCs2 bCQ3JCQ+bDlnJGI4ZjpCJCQkXiQ5JCwkNE47PjUyPCQ1JCQhIxsoQg0KGyRCISEbKEJodHRwOi8v c21hc2gtbWFpbC5uZXQvamltdQ0KGyRCIVokQSRKJF8kSyVVJWohPCVhITwlayRIJE8hKSFbRVBP PyQqJGgkU0F3PHU/LiEiTXhNUSROJDkkWSRGJHJMNU5BJEc5VCQoJGslNSE8JVMlOSROO3YkRyQ5 ISMhWiU5JV4lQyU3JWUlYSE8JWskSCRPISkhWyU5JV4lQyU3JWUhJiVhITwlayRPPCtNMyRLQy8k YiQsRVBPPyRHJC0lVSVqITwbKEIgGyRCJWEhPCVrJCwzWiQ3JGEkaxsoQiAbJEIlYSE8JWslPSVV JUgkRyQ5ISMkYiRBJG0kc0VQTz8kTzRKQzEkRyEiJG8kOiQrGyhCNRskQklDJEdFUE8/JEckLUE0 JEZMNU5BJEc7SCQoJF4kOSEjRXklYSE8JWskTzktOXA8fUZ+JEcxPzFEJDckRiQqJGokXiQ5JE4k RyEiQTQkRiROJTUhPCVTJTkkckw1TkEkR0RzNiEkNSQ7JEZEOiQkJEYkKiRqJF4kOSEjRVBPPyRO Ol0hIjhEP00+cEpzJHI1LTpcJDkka0ksTVckTzhmOkIkJCReJDskcyEjGyhCIBskQiQqPz0kNzl+ JF84ZSEiJDkkMCQ0TXhNUUQ6JDEkXiQ5ISNLXCUiJUklbCU5IUolVyVtJVAlJCVAITw3QExzIUsk RyRPO0hNUSQ3P0kkJD5sOWckTiVXJWklJCVZITwlSCEiTTckUyEiO0U7dhsoQiAbJEJNUSRIJDck RjtIJCRKLCQxJHIkOSRrJWEhPCVrJSIlSSVsJTkkNyRGOkdFLCRHJDkhIyVRJT0lMyVzJE8kYiRB JG0kcyROO3YhIjdIQlMkKyRpJE5NeE1RJGIyREc9JEckOSEjIVolOSVeJUMlNyVlJWEhPCVrJSIl SSVsJTkkcjpuQC4kOSRrJEskTyEpIVsbKEJodHRwOi8vc21hc2gtbWFpbC5uZXQvamltdSAbJEIk XiRHISMbKEI= ------=_NextPart_000_0006_01C6C6E5.1753B4D0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjgwMiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9 Mj4NCjxESVY+PEZPTlQgZmFjZT0iGyRCI00jUxsoQiAbJEIlNCU3JUMlLxsoQiIgc2l6ZT0zPg0K PERJVj48UFJFPjxUVD48Rk9OVCBjbGFzcz1sdGJwcmU+PC9GT05UPjwvVFQ+PC9QUkU+PC9ESVY+ DQo8RElWPjxQUkU+PFRUPhskQiEhIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKBso QjxCUj48L1RUPjxUVD4bJEIhISVVJWohPCVhITwlayRIOEAkKCRQISEbKEI8QlI+PC9UVD48VFQ+ GyRCISEhIU14TVE8VDdjQX1DZiROGyhCPC9UVD48VFQ+PEZPTlQgY29sb3I9IzAwODA4MD4bJEIl OSVeJUMlNyVlJWEhPCVrISohIRsoQjxCUj48L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDAwMD4bJEIh ISIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigiKCIoIigbKEI8L0ZPTlQ+PC9UVD48L1BSRT48 UFJFPjxUVD48Rk9OVCBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogI2ZmZmY2NiI+OC8zMRskQiRe JEckTjR8NFY4QkRqJE4hWiU1JV4hPDZDJC0lLSVjJXMlWiE8JXMlVyVsJTwlcyVIISohWxsoQjwv Rk9OVD48L1RUPjwvUFJFPjxQUkU+PFRUPjxGT05UIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiAj ZmZmZjY2Ij4bJEI8QjtcQ2YkRyQ5ISpAJ0hzJDMkTjUhMnEkSyNHI0UjVCQ3JEYyPCQ1JCQhKhso QjwvRk9OVD48L1RUPjxUVD48L1BSRT48L0RJVj4NCjxESVY+GyRCISEweiQtQjMkLSFaGyhCVE9Q GyRCJVohPCU4ISElaiVLJWUhPCUiJWtDZiEqIVsbKEI8L0RJVj4NCjxESVY+VE9QGyRCJVohPCU4 JWolSyVlITwlIiVrQ2YkS0lVJC0bKEI8L0RJVj4NCjxESVY+GyRCJCo4KzZsJDckJD5sOWckYjhm OkIkJCReJDkkLCQ0Tjs+NTI8JDUkJCEjGyhCPEJSPhskQiEhGyhCPEEgDQpocmVmPSJodHRwOi8v c21hc2gtbWFpbC5uZXQvamltdSI+aHR0cDovL3NtYXNoLW1haWwubmV0L2ppbXU8L0E+PC9UVD48 L0RJVj4NCjxESVY+PFBSRT48VFQ+GyRCIVokQSRKJF8kSxsoQjxGT05UIGNvbG9yPSNmZjAwMDA+ GyRCJVUlaiE8JWEhPCVrGyhCPC9GT05UPhskQiRIJE8hKSFbGyhCPC9UVD48L1BSRT48L0RJVj4N CjxESVY+PFBSRT48VFQ+GyRCRVBPPyQqJGgkU0F3PHU/LiEiTXhNUSROJDkkWSRGJHJMNU5BJEcb KEI8QlI+GyRCOVQkKCRrJTUhPCVTJTkkTjt2JEckOSEjGyhCPC9UVD48L1BSRT48L0RJVj4NCjxE SVY+PFBSRT48VFQ+GyRCIVobKEI8Rk9OVCBjb2xvcj0jZmYwMDAwPhskQiU5JV4lQyU3JWUlYSE8 JWsbKEI8L0ZPTlQ+GyRCJEgkTyEpIVsbKEI8L1RUPjwvUFJFPjwvRElWPg0KPERJVj48UFJFPjxU VD4bJEIlOSVeJUMlNyVlISYlYSE8JWskTzwrTTMkS0MvJGIkLEVQTz8kRyQtGyhCPEJSPhskQiVV JWohPBsoQiAbJEIlYSE8JWskLDNaJDckYSRrGyhCIBskQiVhITwlayU9JVUlSCRHJDkhIxsoQjxC Uj4bJEIkYiRBJG0kc0VQTz8kTzRKQzEkRyEiJG8kOiQrGyhCNRskQklDJEdFUE8/JEckLUE0JEYb KEI8L1RUPjxUVD4bJEJMNU5BJEc7SCQoJF4kOSEjGyhCPEJSPhskQkV5JWEhPCVrJE85LTlwPH1G fiRHMT8xRCQ3JEYkKiRqJF4kOSROJEchIkE0JEYkTiU1ITwlUyU5JHIbKEI8QlI+GyRCTDVOQSRH RHM2ISQ1JDskRkQ6JCQkRiQqJGokXiQ5ISMbKEI8L1RUPjwvUFJFPjwvRElWPg0KPERJVj48UFJF PjxUVD48L1RUPjxUVD4bJEJFUE8/JE46XSEiOEQ/TT5wSnMkcjUtOlwkOSRrSSxNVyRPOGY6QiQk JF4kOyRzISMbKEIgPEJSPhskQiQqPz0kNzl+JF84ZSEiJDkkMCQ0TXhNUUQ6JDEkXiQ5ISMbKEI8 QlI+GyRCS1wlIiVJJWwlOSFKJVclbSVQJSQlQCE8N0BMcyFLJEckTztITVEkNz9JJCQ+bDlnJE4b KEI8QlI+GyRCJVclaSUkJVkhPCVIISJNNyRTISI7RTt2GyhCIBskQk1RJEgkNyRGO0gkJEosJDEk ciQ5JGslYSE8JWsbKEI8QlI+GyRCJSIlSSVsJTkkNyRGOkdFLCRHJDkhIxsoQjxCUj4bJEIlUSU9 JTMlcyRPJGIkQSRtJHMkTjt2ISI3SEJTJCskaSROTXhNUSRiMkRHPSRHJDkhIxsoQjwvVFQ+PC9Q UkU+PC9ESVY+DQo8RElWPjxQUkU+PFRUPhskQiFaGyhCPEZPTlQgY29sb3I9I2ZmMDAwMD4bJEIl OSVeJUMlNyVlJWEhPCVrJSIlSSVsJTkbKEI8L0ZPTlQ+GyRCJHI6bkAuJDkkayRLJE8hKSFbGyhC PC9UVD48L1BSRT48L0RJVj4NCjxESVY+PFBSRT48VFQ+PEEgaHJlZj0iaHR0cDovL3NtYXNoLW1h aWwubmV0L2ppbXUiPmh0dHA6Ly9zbWFzaC1tYWlsLm5ldC9qaW11PC9BPiAbJEIkXiRHISMbKEI8 QlI+PC9UVD48L1BSRT48L0RJVj48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0006_01C6C6E5.1753B4D0-- From owner-ccamp@ops.ietf.org Thu Aug 24 03:15:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG9RH-0002TO-0W for ccamp-archive@ietf.org; Thu, 24 Aug 2006 03:15:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG9RE-0001vb-Nf for ccamp-archive@ietf.org; Thu, 24 Aug 2006 03:15:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GG9MU-000M4t-59 for ccamp-data@psg.com; Thu, 24 Aug 2006 07:10:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GG9MR-000M4O-MK for ccamp@ops.ietf.org; Thu, 24 Aug 2006 07:10:43 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7O7Af4J002955 for ; Thu, 24 Aug 2006 08:10:42 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Thu, 24 Aug 2006 09:09:15 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 24/08/2006 08:10:39 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a In my mind the CP->MP feature can be useful for mainly two purposes: 1) symmetricity with the companion feature (MP->CP) 2) a sort of "parachute" in case something went wrong with the CP (Igor made an example on this but another one could a foreseen problem with the signalling network, or may be the CP is not running well and its restoration time are not in line with the expectation, or there is a merge of two different networks organizations and the resulting one is not going to use -may be only at initial stage of merging process- the CP, ...) We (the authors of the ID) agreed with Dimitri that CP->MP is not a must and I have no problem to move it to should/shall/may state. Is this in the scope of CCAMP? I think it is because is CP related and imho having such parachute can increase the confidence of carriers in CP. I mean I prefer to take a plane if I know I have a parachute on board. However the focus of the ID is on MP->CP handover and if the community is strongly against of CP->MP even in the form of a should/shall/may requirement we can strip this out. Regards Diego From owner-ccamp@ops.ietf.org Thu Aug 24 04:01:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGA9s-0006rx-La for ccamp-archive@ietf.org; Thu, 24 Aug 2006 04:01:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGA9s-0008AU-5Z for ccamp-archive@ietf.org; Thu, 24 Aug 2006 04:01:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGA5r-0001Qz-Iz for ccamp-data@psg.com; Thu, 24 Aug 2006 07:57:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGA5q-0001QX-6z; Thu, 24 Aug 2006 07:57:38 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7O7vJrY032365; Thu, 24 Aug 2006 09:57:19 +0200 In-Reply-To: <019001c6c746$b24bfb80$d04c460a@china.huawei.com> To: Dan Li Cc: ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 24 Aug 2006 09:57:17 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/24/2006 09:57:17, Serialize complete at 08/24/2006 09:57:17 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd hi - [dan] In optical transport networks, the control plane failure should not affect the traffic carried by the transport plane. So usually the cross-connect in the transport plane will not be removed when there is a failure in the control plane, that's why I stated the problem described in this I-D is real. [dimitri] I think this has been worked out (see RFC 3473, and related) such as to prevent drawbacks of releasing resources while there is known period during which states can be re-build (using neighbors as helpers) [dimitri] The concern is if parameters are set such as to make behavior being equivalent to a hard state protocol the proposal you made is solving a corner case from a mis-use of the protocol mechanisms we have at hand [dimitri] I understand from Adrian's reply that the case we're dealing with is due restart/recovery timers that are set such as to support large period of CP outage - where one can not rely on cleanup [dimitri] I can accept this is a consequence of setting existing parameters - but my answer to this is "ok but why shall we have LMP intervening in this process if the operator wants to wait for very large periods" ... this leads to the (partial) conclusion that i can assume their can be cases where the data plane itself may introduce an inconsistency (would be interesting to have the viewpoint of "optical hardware expert" here) but i don't see how we can have cases where the control plane if correctly used and configured can be the instigator of such cases [dimitri] concerning the detection, the issue resulting from this is that the "available" side should - per 4204 - start an LMP verification ... pointing to 4204 "Therefore, to ensure proper verification of data link connectivity, it is required that, until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency). To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the IP payload, etc.) and, hence, different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages." which result in "when data links are de-allocated" they should re-enter that state ... the issue is that the BeginVerify does not exchange DATA LINK but LINK objects (there is no flags in the former) hence the only reply you would receive is "unwilling to verify" while ideally you should receive "unwilling to verify (allocated)" such as the other side can map it with local knowledge and detect the mismatch -d. Dan Li 24/08/2006 08:29 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi Dimitri, Please see in-line. Regards, Dan ----- Original Message ----- From: To: "Dan Li" Cc: "ccamp" ; "MEURIC Julien RD-CORE-LAN" ; ; ; "Zafar Ali (zali)" Sent: Wednesday, August 23, 2006 8:45 PM Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, > just a brief remark > > i don't see why channel status verification can not be achieved with > current mechanism described in section 12.7 of 4204 (and there is a > need to come with a complete set of messages for this purpose) > [dan] I agree that the LMP messages (17, 18, 19) can do the channel status verification with some extensions. My concern is that these messages are used for the fault management, but the inconsistent data channel status may be is not a failure, for example it may be configured on purpose. > now i am even unclear how the problem you stated can occur > > "The channel status of a data link may become mismatched during the > LSP deletion process. If the LSP deletion process is aborted in the > middle of the process (perhaps because of a temporary control plane > failure), the cross-connection at the upstream node may be removed > while the downstream node still keeps its cross-connection." > > why do you think the notion of soft-state has been introduced ? once > the cleanup timeout (set to K times the refresh timeout) interval is > reached that then triggers a tear-down > [dan] In optical transport networks, the control plane failure should not affect the traffic carried by the transport plane. So usually the cross-connect in the transport plane will not be removed when there is a failure in the control plane, that's why I stated the problem described in this I-D is real. > thanks, > - d. > > > > > > > Dan Li > Sent by: owner-ccamp@ops.ietf.org > 23/08/2006 09:55 > > To: xuhuiying@huawei.com, "Zafar Ali (zali)" , > MEURIC Julien RD-CORE-LAN > cc: ccamp > Subject: Re: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi, > > Thanks Julien and Zafar for your comments. I agree with Julien. This I-D > just wants to provide a control plane tool to detect the inconsistent data > channel status in the tranport plane. > > Actually I have received several private emails think this I-D addresses a > real problem, but regarding the new LMP messages which are introduced in > this I-D, some people pointed out that the already deployed channelstatus > messages (id = 17, 18, 19 and 20) may be extended to carry also the > timeslot information instead only data link. But I have a concern that the > Fault Management Messages usually are triggered by fault detection, these > messages should not be sent if no fault is detected. The confirmation of > data channel status may need to be performed periodically or triggerd by > user. > > I would like to hear from you guys, what's your comments? Not only the > concerns raised above, but also other issues in this I-D. > > Regards, > > Dan > > ----- Original Message ----- > From: "MEURIC Julien RD-CORE-LAN" > To: "Zafar Ali (zali)" ; ; > > Cc: "ccamp" > Sent: Tuesday, July 11, 2006 2:31 AM > Subject: RE: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi Zafar. > > I don't really get you on this. I figure out you're referring to > removing the connection states when RSVP refreshes are not received any > more, aren't you? If so, I'm afraid this is not enough for transmission > devices, where resources can be physically cross-connected even though > there is no (or no longer) corresponding RSVP state. Therefore having a > mechanism to avoid such discrepancies would be welcome. > > Regards, > > Julien > > > P.S.: If you totally rely on a management plane, I agree this should be > useless (e.g. the NMS should already know if a cross-connection deletion > failed, cf. Diego's 2nd slides seen this morning). > > ________________________________ > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Zafar Ali (zali) > > Dear Authors, > > RSVP refreshes do this job, so I am not sure motivation for this draft/ > LMP extensions. > > n.b. The draft state, "Although such a situation can be resolved through > the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], > such a procedure is inefficient since it may require an additional > signaling exchange for each LSP that is set up", so I assume that RSVP > signaling is present (Although I did not understand the quoted statement > from the ID). Even if RSVP is not present, e.g., optical core is > completely controlled by a management entity, I would argue introduce > presence of LMP. > > Thanks > > Regards... Zafar > > > > From owner-ccamp@ops.ietf.org Thu Aug 24 04:21:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGATA-00067P-LI for ccamp-archive@ietf.org; Thu, 24 Aug 2006 04:21:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGAT9-0002uo-CG for ccamp-archive@ietf.org; Thu, 24 Aug 2006 04:21:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGAQ8-0004bS-IL for ccamp-data@psg.com; Thu, 24 Aug 2006 08:18:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGAQ7-0004b2-Ld; Thu, 24 Aug 2006 08:18:36 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7O8IVKj016790; Thu, 24 Aug 2006 10:18:31 +0200 In-Reply-To: To: "Diego Caviglia" Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 24 Aug 2006 10:18:28 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/24/2006 10:18:29, Serialize complete at 08/24/2006 10:18:29 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 diego - using your metaphore - if the plane explodes/crashes you can have the nicer parachute it won't be of great help - meaning it is clear that is not this process/parachute that is going to increase confidence in CP if the problem is more fundamental and in part. not technical (confidence/trust/etc.) ps: operations are NOT symmetric (if you mean reflective since CP =/= distributed MP) "Diego Caviglia" Sent by: owner-ccamp@ops.ietf.org 24/08/2006 09:09 To: ccamp@ops.ietf.org cc: Subject: CP-->MP Issue (was RE: Polling for new WG I-Ds) In my mind the CP->MP feature can be useful for mainly two purposes: 1) symmetricity with the companion feature (MP->CP) 2) a sort of "parachute" in case something went wrong with the CP (Igor made an example on this but another one could a foreseen problem with the signalling network, or may be the CP is not running well and its restoration time are not in line with the expectation, or there is a merge of two different networks organizations and the resulting one is not going to use -may be only at initial stage of merging process- the CP, ...) We (the authors of the ID) agreed with Dimitri that CP->MP is not a must and I have no problem to move it to should/shall/may state. Is this in the scope of CCAMP? I think it is because is CP related and imho having such parachute can increase the confidence of carriers in CP. I mean I prefer to take a plane if I know I have a parachute on board. However the focus of the ID is on MP->CP handover and if the community is strongly against of CP->MP even in the form of a should/shall/may requirement we can strip this out. Regards Diego From owner-ccamp@ops.ietf.org Thu Aug 24 05:41:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGBi3-0001dM-QW for ccamp-archive@ietf.org; Thu, 24 Aug 2006 05:41:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGBi2-0006rM-Bb for ccamp-archive@ietf.org; Thu, 24 Aug 2006 05:41:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGBaW-000E9L-J6 for ccamp-data@psg.com; Thu, 24 Aug 2006 09:33:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGBaU-000E8u-Vy for ccamp@ops.ietf.org; Thu, 24 Aug 2006 09:33:23 +0000 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k7O9RB902035; Thu, 24 Aug 2006 05:27:12 -0400 (EDT) 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 Subject: RE: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas Date: Thu, 24 Aug 2006 10:33:13 +0100 Message-ID: In-Reply-To: <44E635E6.4050809@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas Thread-Index: AcbDEDTmeTIKi35STGuMN20t0qcUAgB+eo/A From: "Trevor Wilson" To: "Huub van Helvoort" Cc: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Huub, Sorry for the delay in replying to your e-mail. I think we're there. See in-line. [tw2] Trevor Trevor Wilson Nortel Networks Belfast Lab Tel: +44 2890 363701 ESN 751 3701 >This is the Way. This is Nortel. > Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 Sent: 18 August 2006 22:49 To: Wilson, Trevor (IRE07:Q840) Cc: ccamp@ops.ietf.org Subject: Re: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas Hello Trevor, You replied: > Thanks for the clarifications, see in-line for responses. OK, I have added my response [hvh2] and sipped the parts where we agree. >> Section 3.2: >> >> Is Fixed synonymous with no-LCAS ? >=20 > [hvh] No, not necessarily, in this case the client signal will > not change its bandwidth. LCAS can be used for resilience. > [tw] Accepted that this is possible. However I still think the reader > could be forgiven for assuming that Fixed =3D non-LCAS-capable and > Dynamic =3D LCAS-capable; so perhaps this needs to be clarified in the = > text. [hvh2] OK that can be done. [tw2] Look forward to seeing that. >> If so, then in the Fixed co-routed scenario, there can be no graceful >> degradation in the event of a failure. > [tw] I have a typo here is should say Fixed diversely-routed instead > of Fixed co-routed >=20 > [hvh] a mis-connection is also a failure > [tw] but a mis-connection won't cause a hit, since this will occur at > set-up, but I agree that if LCAS is present then graceful degradation > can be achieved in the event of a signal degrade. [hvh2] I don't agree, mis-connections can also occur after set-up, e.g. when a crossconnect is wrongly provisioned and changed an existing connection. [tw2] OK >> A hitless decrease can >> in certain circumstances, be achieved by using a signal degrade to >> trigger the LCAS remove operation. >=20 > [hvh] how do you provision/achieve a signal degrade? > [tw] G.806 clause 10.1.1.2 shows "P-Xv_AI_TSD =3D P_AI[1.. XMR]_TSD" > and "P-Xv/P-X-L_A_Sk_MI_TSDEnable" as inputs to the "LCAS-capable > virtual concatenated path adaptation sink function P-Xv/P-X-L_A_Sk",=20 > and the text says "The MI_TSDEnable input controls whether the sink=20 > function uses AI_TSD[i] indications as contributors for signalling=20 > defective members back to the LCAS source function (MI_TSDEnable =3D=20 > true) or whether it ignores AI_TSD[i] indications altogether=20 > (MI_TSDEnable =3D false)." [hvh2] this is the enabling of the TSD to be a trigger. What I dis mean is that it is impossible to force a signal degrade (e.g. by introducing bit errors on purpose). Maybe we should only mention that hitless decrease is guaranteed when a member is removed (and LCAS is enabled). [tw2] I'm getting a bit lost; this part of the discussion was about graceful degradation. With that in mind are you suggesting to remove any mention of graceful degrade. If so I agree. I look forward to seeing the final text. =20 >> Dynamic, diversely routed: A dynamic VCAT group, transported over at=20 >> least two diversely routed subsets of member signals. The intent=20 >> here is dynamic resizing and resilience (but differential delay may=20 >> be a limiting factor). Graceful degradation is possible in the event=20 >> of a TSD (Trail Signal Degrade) on a VCG >> member(s) >=20 > [hvh] graceful degradation is a feature of LCAS, it is not necessary > to mention it here explicitly > [tw] It's equally (if not more) relevant to mention it here than in > the fixed scenario. [hvh2] see my previous comment >> The LCAS in-band >> signaling step is taken first to take the component out of the >> group as the result of a remove command from the LCAS controller; the >> permanently removed member will then be in the IDLE state. >=20 > [hvh] mentioning only one of the LCAS states will create confusion > and is irrelevant to GMPLS > [tw] OK so take out the mention of the DNU state (4.1.3.1) and IDLE > (4.1.3.2). In fact perhaps 4.1.3.1 could be combined with 4.1.3.2 as > follows: - >=20 > 4.1.3 Permanent removal of a VCG member >=20 > A VCG member can be permanently removed from the VCG either following > a temporary removal (due to a failure) or as the result of a=20 > management command. The LCAS in-band signaling step is taken first to=20 > take the component out of the group, either the temporary removal or=20 > as the result of a management command. [hvh2] good suggestion >> This permanent removal procedure is only applicable to=20 >> LCAS-capable-VCAT. >=20 > [hvh] the paragraph replaced by the latter sentence contains more > relevant detail and should be kept intact. > [tw] The introduction to section 4 states that it (section 4) is "in > support of the LCAS procedure". So I don't quite see how the sentence > that I deleted is relevant to LCAS since it deals with the "VCAT only" > interface. =09 [hvh2] you missed the word "and" in quoting, so section 4 describes extentions for diversely routed paths and (extentions) in support of LCAS". So the detail given in the paragraph is relevant for making the distinction between VCAT with and without LCAS. [tw2] OK Cheers, and have a nice weekend, Huub. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://members.chello.nl/hhelvoort/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Thu Aug 24 08:25:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEGi-0000jC-6X for ccamp-archive@ietf.org; Thu, 24 Aug 2006 08:25:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGEGe-0006zZ-RQ for ccamp-archive@ietf.org; Thu, 24 Aug 2006 08:25:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGE7o-000Itk-Sb for ccamp-data@psg.com; Thu, 24 Aug 2006 12:15:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.246.11.148] (helo=esc71.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGE7o-000ItU-5C for ccamp@ops.ietf.org; Thu, 24 Aug 2006 12:15:56 +0000 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1GGE7h-0000iI-FC; Thu, 24 Aug 2006 08:15:49 -0400 Message-Id: <7.0.1.0.2.20060824075206.03488328@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 24 Aug 2006 08:15:50 -0400 To: "Diego Caviglia" From: Lou Berger Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: ccamp@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Diego, In my experience in talking about this feature with carriers is that some (but not all) will require such symmetric behavior. I think the other rational for this feature are irrelevant. Again, the sole reason I've seen for this requirement is that to deploy MP->CP some will require that there be support for CP->MP. I therefore think the definition of CP->MP *is* required. There are multiple options for meeting this requirement, but the solution must provide the "fallback" capability for services existing at the time of the initial MP->CP transition and those created after the transition. I think a SHOULD level requirement is sufficient for this capability, but I'd be interested if those representing carries on the list differ. Lou At 03:09 AM 8/24/2006, Diego Caviglia wrote: >In my mind the CP->MP feature can be useful for mainly two purposes: >1) symmetricity with the companion feature (MP->CP) >[...] > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a must >and I have no problem to move it to should/shall/may state. > >[...] >However the focus of the ID is on MP->CP handover and if the community is >strongly against of CP->MP even in the form of a should/shall/may >requirement we can strip this out. > >Regards > >Diego From owner-ccamp@ops.ietf.org Thu Aug 24 08:50:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEfV-0002zD-B9 for ccamp-archive@ietf.org; Thu, 24 Aug 2006 08:50:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGCB0-000276-IS for ccamp-archive@ietf.org; Thu, 24 Aug 2006 06:11:06 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGC0S-0006OF-7a for ccamp-archive@ietf.org; Thu, 24 Aug 2006 06:00:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGBvZ-000HeI-AD for ccamp-data@psg.com; Thu, 24 Aug 2006 09:55:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGBvX-000He3-Uw; Thu, 24 Aug 2006 09:55:08 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7O9t30S011107; Thu, 24 Aug 2006 10:55:04 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: "Dimitri.Papadimitriou" Cc: "ccamp" , "owner-ccamp" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Thu, 24 Aug 2006 11:53:36 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 24/08/2006 10:55:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Dimitri, it depends if you use the parachute before the plane explode :-)) More seriously do you still have problems with the procedure if we move it to a should/shall/may state? I think that this would be enough for who think is a good feture and wants to implement it and do not 'force' anyone that disagree to implement it. Regards Diego Dimitri.Papadimitriou@alcatel.be on 24/08/2006 10.18.28 To: "Diego Caviglia" cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds) diego - using your metaphore - if the plane explodes/crashes you can have the nicer parachute it won't be of great help - meaning it is clear that is not this process/parachute that is going to increase confidence in CP if the problem is more fundamental and in part. not technical (confidence/trust/etc.) ps: operations are NOT symmetric (if you mean reflective since CP =/= distributed MP) "Diego Caviglia" Sent by: owner-ccamp@ops.ietf.org 24/08/2006 09:09 To: ccamp@ops.ietf.org cc: Subject: CP-->MP Issue (was RE: Polling for new WG I-Ds) In my mind the CP->MP feature can be useful for mainly two purposes: 1) symmetricity with the companion feature (MP->CP) 2) a sort of "parachute" in case something went wrong with the CP (Igor made an example on this but another one could a foreseen problem with the signalling network, or may be the CP is not running well and its restoration time are not in line with the expectation, or there is a merge of two different networks organizations and the resulting one is not going to use -may be only at initial stage of merging process- the CP, ...) We (the authors of the ID) agreed with Dimitri that CP->MP is not a must and I have no problem to move it to should/shall/may state. Is this in the scope of CCAMP? I think it is because is CP related and imho having such parachute can increase the confidence of carriers in CP. I mean I prefer to take a plane if I know I have a parachute on board. However the focus of the ID is on MP->CP handover and if the community is strongly against of CP->MP even in the form of a should/shall/may requirement we can strip this out. Regards Diego From owner-ccamp@ops.ietf.org Thu Aug 24 09:37:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGFOR-0006hb-Gi for ccamp-archive@ietf.org; Thu, 24 Aug 2006 09:37:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGFOP-0004d3-MU for ccamp-archive@ietf.org; Thu, 24 Aug 2006 09:37:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGFGo-00098B-OO for ccamp-data@psg.com; Thu, 24 Aug 2006 13:29:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGFGm-00097o-9c; Thu, 24 Aug 2006 13:29:16 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4I00G688M3WS@szxga03-in.huawei.com>; Thu, 24 Aug 2006 21:39:39 +0800 (CST) Received: from dan ([219.134.232.41]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4I00GZ78LRCL@szxga03-in.huawei.com>; Thu, 24 Aug 2006 21:39:39 +0800 (CST) Date: Thu, 24 Aug 2006 09:29:01 -0400 From: Dan Li Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Message-id: <001301c6c781$4320f5e0$6501a8c0@dan> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 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: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Hi Dimitri, see in line. -Dan ----- Original Message ----- From: To: "Dan Li" Cc: "ccamp" ; "MEURIC Julien RD-CORE-LAN" ; ; ; "Zafar Ali (zali)" Sent: Thursday, August 24, 2006 3:57 AM Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, > hi - > > [dan] In optical transport networks, the control plane failure should not > affect the traffic carried by the transport plane. So usually the > cross-connect > in the transport plane will not be removed when there is a failure in the > control > plane, that's why I stated the problem described in this I-D is real. > > [dimitri] I think this has been worked out (see RFC 3473, and related) > such as to prevent drawbacks of releasing resources while there is known > period during which states can be re-build (using neighbors as helpers) > [dan] Sorry, maybe I didn't make it clear. What I mean was during the LSP deletion procedure, if one node just happen to be restarted when it receives the message to release the transport resource. This situation results in the inconsistent data channel status because of the large timer setting. Before the large timer to be expired, we can not use the inconsistent data channel. [dan] In order to ensure that the traffic carried by the transport plane is not affected due to the control plane failure, we have to set a large timer. But on the other hand, when we really want to release the transport resource, we hope the timer is small enough to ensure the resource can be released as soon as possible when there is a problem on the control plane. > [dimitri] The concern is if parameters are set such as to make behavior > being equivalent to a hard state protocol the proposal you made is solving > a corner case from a mis-use of the protocol mechanisms we have at hand > > [dimitri] I understand from Adrian's reply that the case we're dealing > with is due restart/recovery timers that are set such as to support large > period of CP outage - where one can not rely on cleanup > > [dimitri] I can accept this is a consequence of setting existing > parameters - but my answer to this is "ok but why shall we have LMP > intervening in this process if the operator wants to wait for very large > periods" ... this leads to the (partial) conclusion that i can assume > their can be cases where the data plane itself may introduce an > inconsistency (would be interesting to have the viewpoint of "optical > hardware expert" here) but i don't see how we can have cases where the > control plane if correctly used and configured can be the instigator of > such cases > > [dimitri] concerning the detection, the issue resulting from this is that > the "available" side should - per 4204 - start an LMP verification ... > pointing to 4204 "Therefore, to ensure proper verification of data link > connectivity, it is required that, until the data links are allocated for > user traffic, they must be opaque (i.e., lose their transparency). To > support various degrees of opaqueness (e.g., examining overhead bytes, > terminating the IP payload, etc.) and, hence, different mechanisms to > transport the Test messages, a Verify Transport Mechanism field is > included in the BeginVerify and BeginVerifyAck messages." which result in > "when data links are de-allocated" they should re-enter that state ... the > issue is that the BeginVerify does not exchange DATA LINK but LINK objects > (there is no flags in the former) hence the only reply you would receive > is "unwilling to verify" while ideally you should receive "unwilling to > verify (allocated)" such as the other side can map it with local knowledge > and detect the mismatch > [dan] This solution you have suggested sounds very interesting, I will look at it. > > -d. > > > > > > > Dan Li > 24/08/2006 08:29 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: ccamp , MEURIC Julien RD-CORE-LAN > , owner-ccamp@ops.ietf.org, > xuhuiying@huawei.com, "Zafar Ali (zali)" > Subject: Re: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi Dimitri, > > Please see in-line. > > Regards, > > Dan > > ----- Original Message ----- > From: > To: "Dan Li" > Cc: "ccamp" ; "MEURIC Julien RD-CORE-LAN" > ; ; > ; "Zafar Ali (zali)" > Sent: Wednesday, August 23, 2006 8:45 PM > Subject: Re: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > >> just a brief remark >> >> i don't see why channel status verification can not be achieved with >> current mechanism described in section 12.7 of 4204 (and there is a >> need to come with a complete set of messages for this purpose) >> > > [dan] I agree that the LMP messages (17, 18, 19) can do the channel status > verification with some extensions. My concern is that these messages are > used for the fault management, but the inconsistent data channel status > may > be is not a failure, for example it may be configured on purpose. > > >> now i am even unclear how the problem you stated can occur >> >> "The channel status of a data link may become mismatched during the >> LSP deletion process. If the LSP deletion process is aborted in the >> middle of the process (perhaps because of a temporary control plane >> failure), the cross-connection at the upstream node may be removed >> while the downstream node still keeps its cross-connection." >> >> why do you think the notion of soft-state has been introduced ? once >> the cleanup timeout (set to K times the refresh timeout) interval is >> reached that then triggers a tear-down >> > > [dan] In optical transport networks, the control plane failure should not > affect the traffic carried by the transport plane. So usually the > cross-connect > in the transport plane will not be removed when there is a failure in the > control > plane, that's why I stated the problem described in this I-D is real. > > >> thanks, >> - d. >> >> >> >> >> >> >> Dan Li >> Sent by: owner-ccamp@ops.ietf.org >> 23/08/2006 09:55 >> >> To: xuhuiying@huawei.com, "Zafar Ali (zali)" > , >> MEURIC Julien RD-CORE-LAN >> cc: ccamp >> Subject: Re: High level comment on >> draft-li-ccamp-confirm-data-channel-status-00.txt, >> >> >> Hi, >> >> Thanks Julien and Zafar for your comments. I agree with Julien. This I-D > >> just wants to provide a control plane tool to detect the inconsistent > data >> channel status in the tranport plane. >> >> Actually I have received several private emails think this I-D addresses > a >> real problem, but regarding the new LMP messages which are introduced in > >> this I-D, some people pointed out that the already deployed > channelstatus >> messages (id = 17, 18, 19 and 20) may be extended to carry also the >> timeslot information instead only data link. But I have a concern that > the >> Fault Management Messages usually are triggered by fault detection, > these >> messages should not be sent if no fault is detected. The confirmation of > >> data channel status may need to be performed periodically or triggerd by > >> user. >> >> I would like to hear from you guys, what's your comments? Not only the >> concerns raised above, but also other issues in this I-D. >> >> Regards, >> >> Dan >> >> ----- Original Message ----- >> From: "MEURIC Julien RD-CORE-LAN" >> To: "Zafar Ali (zali)" ; ; >> >> Cc: "ccamp" >> Sent: Tuesday, July 11, 2006 2:31 AM >> Subject: RE: High level comment on >> draft-li-ccamp-confirm-data-channel-status-00.txt, >> >> >> Hi Zafar. >> >> I don't really get you on this. I figure out you're referring to >> removing the connection states when RSVP refreshes are not received any >> more, aren't you? If so, I'm afraid this is not enough for transmission >> devices, where resources can be physically cross-connected even though >> there is no (or no longer) corresponding RSVP state. Therefore having a >> mechanism to avoid such discrepancies would be welcome. >> >> Regards, >> >> Julien >> >> >> P.S.: If you totally rely on a management plane, I agree this should be >> useless (e.g. the NMS should already know if a cross-connection deletion >> failed, cf. Diego's 2nd slides seen this morning). >> >> ________________________________ >> >> >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf Of Zafar Ali (zali) >> >> Dear Authors, >> >> RSVP refreshes do this job, so I am not sure motivation for this draft/ >> LMP extensions. >> >> n.b. The draft state, "Although such a situation can be resolved through >> the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], >> such a procedure is inefficient since it may require an additional >> signaling exchange for each LSP that is set up", so I assume that RSVP >> signaling is present (Although I did not understand the quoted statement >> from the ID). Even if RSVP is not present, e.g., optical core is >> completely controlled by a management entity, I would argue introduce >> presence of LMP. >> >> Thanks >> >> Regards... Zafar >> >> >> >> > > > From owner-ccamp@ops.ietf.org Thu Aug 24 11:07:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGnt-0007qA-Cn for ccamp-archive@ietf.org; Thu, 24 Aug 2006 11:07:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGGnt-0006YC-BF for ccamp-archive@ietf.org; Thu, 24 Aug 2006 11:07:33 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGGeP-0006MG-QA for ccamp-archive@ietf.org; Thu, 24 Aug 2006 10:57:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGGWW-000I9V-GV for ccamp-data@psg.com; Thu, 24 Aug 2006 14:49:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGGWV-000I9F-FO for ccamp@ops.ietf.org; Thu, 24 Aug 2006 14:49:35 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7OEnRB29169; Thu, 24 Aug 2006 10:49:27 -0400 (EDT) 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 Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Thu, 24 Aug 2006 10:48:48 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A34F9E6@zrtphxm2.corp.nortel.com> In-Reply-To: <7.0.1.0.2.20060824075206.03488328@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbHd+uhj2J3uqENTJagDDcfOJpoUQACBAMw From: "Don Fedyk" To: "Lou Berger" , "Diego Caviglia" Cc: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Lou and Diego, all Two points.=20 If we were to ask could you live without the CP->MP feature what response would we get versus asking if CP->MP is a soft requirement. The other point that baffles me is there is not one "standard" MP that I'm aware of so really we are talking many variations of MP to a standard CP. So how do you define a CP to variations of MPs? The document currently oversimplifies this aspect IMHO. Thanks, Don > -----Original Message----- >=20 > Diego, > In my experience in talking about this feature with=20 > carriers is that some (but not all) will require such=20 > symmetric behavior. I think the other rational for this=20 > feature are irrelevant. Again, the sole reason I've seen for=20 > this requirement is that to deploy MP->CP some will require=20 > that there be support for CP->MP. >=20 > I therefore think the definition of CP->MP *is* required. =20 > There are multiple options for meeting this requirement, but=20 > the solution must provide the "fallback" capability for=20 > services existing at the time of the initial MP->CP=20 > transition and those created after the transition. >=20 > I think a SHOULD level requirement is sufficient for this=20 > capability, but I'd be interested if those representing=20 > carries on the list differ. >=20 > Lou >=20 > At 03:09 AM 8/24/2006, Diego Caviglia wrote: >=20 >=20 > >In my mind the CP->MP feature can be useful for mainly two purposes: > >1) symmetricity with the companion feature (MP->CP) > >[...] > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a=20 > >must and I have no problem to move it to should/shall/may state. > > > >[...] > >However the focus of the ID is on MP->CP handover and if the=20 > community=20 > >is strongly against of CP->MP even in the form of a should/shall/may=20 > >requirement we can strip this out. > > > >Regards > > > >Diego >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Aug 24 11:33:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHCo-0004U8-3U for ccamp-archive@ietf.org; Thu, 24 Aug 2006 11:33:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHCm-00024E-Px for ccamp-archive@ietf.org; Thu, 24 Aug 2006 11:33:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGH5b-000MAx-0x for ccamp-data@psg.com; Thu, 24 Aug 2006 15:25:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGH5X-000MAC-2w for ccamp@ops.ietf.org; Thu, 24 Aug 2006 15:25:47 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7OFPSea027525; Thu, 24 Aug 2006 16:25:29 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: dwfedyk@nortel.com Cc: ""Lou Berger" , " X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Thu, 24 Aug 2006 17:24:00 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 24/08/2006 16:25:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi Don, in line. Regards "Don Fedyk" @ops.ietf.org on 24/08/2006 16.48.48 Sent by: owner-ccamp@ops.ietf.org To: "Lou Berger" , "Diego Caviglia" cc: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Lou and Diego, all Two points. If we were to ask could you live without the CP->MP feature what response would we get versus asking if CP->MP is a soft requirement. [dc] I think that the poll request from Adrian was trying to solve this point. The other point that baffles me is there is not one "standard" MP that I'm aware of so really we are talking many variations of MP to a standard CP. So how do you define a CP to variations of MPs? The document currently oversimplifies this aspect IMHO. [dc] This is not clear to me. Could you please clarify? Thanks, Don > -----Original Message----- > > Diego, > In my experience in talking about this feature with > carriers is that some (but not all) will require such > symmetric behavior. I think the other rational for this > feature are irrelevant. Again, the sole reason I've seen for > this requirement is that to deploy MP->CP some will require > that there be support for CP->MP. > > I therefore think the definition of CP->MP *is* required. > There are multiple options for meeting this requirement, but > the solution must provide the "fallback" capability for > services existing at the time of the initial MP->CP > transition and those created after the transition. > > I think a SHOULD level requirement is sufficient for this > capability, but I'd be interested if those representing > carries on the list differ. > > Lou > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > > > >In my mind the CP->MP feature can be useful for mainly two purposes: > >1) symmetricity with the companion feature (MP->CP) > >[...] > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a > >must and I have no problem to move it to should/shall/may state. > > > >[...] > >However the focus of the ID is on MP->CP handover and if the > community > >is strongly against of CP->MP even in the form of a should/shall/may > >requirement we can strip this out. > > > >Regards > > > >Diego > > > From owner-ccamp@ops.ietf.org Thu Aug 24 11:57:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHa6-0006XY-J1 for ccamp-archive@ietf.org; Thu, 24 Aug 2006 11:57:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHZz-0005iz-4t for ccamp-archive@ietf.org; Thu, 24 Aug 2006 11:57:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGHAL-000Mhw-3V for ccamp-data@psg.com; Thu, 24 Aug 2006 15:30:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.32.69] (helo=blv-smtpout-01.ns.cs.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGHAI-000Mgr-GN for ccamp@ops.ietf.org; Thu, 24 Aug 2006 15:30:42 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7OFUfOd009843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 24 Aug 2006 08:30:42 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7OFUehY028360 for ; Thu, 24 Aug 2006 08:30:41 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (xch-swbh-04.sw.nos.boeing.com [192.79.11.25]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7OFUX7r027886; Thu, 24 Aug 2006 08:30:34 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 08:30:30 -0700 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 Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Thu, 24 Aug 2006 08:30:30 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DD13@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbHd+uhj2J3uqENTJagDDcfOJpoUQACBAMwAARtlTA= From: "Drake, John E" To: "Don Fedyk" , "Lou Berger" , "Diego Caviglia" Cc: X-OriginalArrivalTime: 24 Aug 2006 15:30:30.0664 (UTC) FILETIME=[3BA7C080:01C6C792] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe >=20 > The other point that baffles me is there is not one=20 > "standard" MP that I'm aware of so really we are talking many=20 > variations of MP to a standard CP. So how do you define a CP=20 > to variations of MPs? The document currently oversimplifies=20 > this aspect IMHO. JD: If you go back to the original MPL(ambda)S proposal, this was one of the reasons given for building a standards based control plane. >=20 > Thanks, > Don >=20 > > -----Original Message----- > >=20 > > Diego, > > In my experience in talking about this feature with > > carriers is that some (but not all) will require such=20 > > symmetric behavior. I think the other rational for this=20 > > feature are irrelevant. Again, the sole reason I've seen for=20 > > this requirement is that to deploy MP->CP some will require=20 > > that there be support for CP->MP. > >=20 > > I therefore think the definition of CP->MP *is* required. > > There are multiple options for meeting this requirement, but=20 > > the solution must provide the "fallback" capability for=20 > > services existing at the time of the initial MP->CP=20 > > transition and those created after the transition. > >=20 > > I think a SHOULD level requirement is sufficient for this > > capability, but I'd be interested if those representing=20 > > carries on the list differ. > >=20 > > Lou > >=20 > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > >=20 > >=20 > > >In my mind the CP->MP feature can be useful for mainly two=20 > purposes: > > >1) symmetricity with the companion feature (MP->CP) > > >[...] > > > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a > > >must and I have no problem to move it to should/shall/may state. > > > > > >[...] > > >However the focus of the ID is on MP->CP handover and if the > > community > > >is strongly against of CP->MP even in the form of a=20 > should/shall/may > > >requirement we can strip this out. > > > > > >Regards > > > > > >Diego > >=20 > >=20 > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Aug 24 12:05:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHiB-0002r6-H3 for ccamp-archive@ietf.org; Thu, 24 Aug 2006 12:05:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHiA-0007EO-4n for ccamp-archive@ietf.org; Thu, 24 Aug 2006 12:05:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGHNp-000OR5-7i for ccamp-data@psg.com; Thu, 24 Aug 2006 15:44:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGHNo-000OQe-6J for ccamp@ops.ietf.org; Thu, 24 Aug 2006 15:44:40 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k7OFiVB07561; Thu, 24 Aug 2006 11:44:31 -0400 (EDT) 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 Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Thu, 24 Aug 2006 11:44:21 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A34FBB1@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbHkZMYvUOt8S3kSSqppXQr9TSzrgAAGkrg From: "Don Fedyk" To: "Diego Caviglia" Cc: "\"Lou Berger\" , " Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Hi Diego=20 In Line as well > -----Original Message----- > Hi Don, > in line. >=20 > Regards >=20 >=20 >=20 > "Don Fedyk" @ops.ietf.org on 24/08/2006 16.48.48 >=20 > Sent by: owner-ccamp@ops.ietf.org >=20 >=20 > To: "Lou Berger" , "Diego Caviglia" > > cc: >=20 > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 > Lou and Diego, all >=20 > Two points. >=20 > If we were to ask could you live without the CP->MP feature=20 > what response would we get versus asking if CP->MP is a soft=20 > requirement. > [dc] I think that the poll request from Adrian was trying to=20 > solve this point. >=20 > The other point that baffles me is there is not one=20 > "standard" MP that I'm aware of so really we are talking many=20 > variations of MP to a standard CP. So how do you define a CP=20 > to variations of MPs? The document currently oversimplifies=20 > this aspect IMHO. > [dc] This is not clear to me. Could you please clarify? [DF] Where do we find the standard MP representation of a Path? What MIBS etc. Many legacy systems have differnet MP representations of this and may use extra attributes or objects. It varies by which Optical or packet based system GMPLS is to control. When moving to GMPLS we can rationalize these objects to GMPLS objects but without generation/storage and possibily signaling of these MP objects the CP->MP mapping is incomplete. =20 Regards, Don =20 >=20 > Thanks, > Don >=20 > > -----Original Message----- > > > > Diego, > > In my experience in talking about this feature=20 > with carriers=20 > > is that some (but not all) will require such symmetric behavior. I=20 > > think the other rational for this feature are irrelevant. =20 > Again, the=20 > > sole reason I've seen for this requirement is that to deploy MP->CP=20 > > some will require that there be support for CP->MP. > > > > I therefore think the definition of CP->MP *is* required. > > There are multiple options for meeting this requirement, but the=20 > > solution must provide the "fallback" capability for=20 > services existing=20 > > at the time of the initial MP->CP transition and those=20 > created after=20 > > the transition. > > > > I think a SHOULD level requirement is sufficient for this=20 > capability,=20 > > but I'd be interested if those representing carries on the list=20 > > differ. > > > > Lou > > > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > > > > > > >In my mind the CP->MP feature can be useful for mainly two=20 > purposes: > > >1) symmetricity with the companion feature (MP->CP) > > >[...] > > > > > >We (the authors of the ID) agreed with Dimitri that CP->MP=20 > is not a=20 > > >must and I have no problem to move it to should/shall/may state. > > > > > >[...] > > >However the focus of the ID is on MP->CP handover and if the > > community > > >is strongly against of CP->MP even in the form of a=20 > should/shall/may=20 > > >requirement we can strip this out. > > > > > >Regards > > > > > >Diego > > > > > > >=20 >=20 >=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Aug 24 12:15:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHrn-0000xc-JY for ccamp-archive@ietf.org; Thu, 24 Aug 2006 12:15:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHri-00019T-AR for ccamp-archive@ietf.org; Thu, 24 Aug 2006 12:15:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGHmE-0001wC-E5 for ccamp-data@psg.com; Thu, 24 Aug 2006 16:09:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGHmC-0001vm-L4 for ccamp@ops.ietf.org; Thu, 24 Aug 2006 16:09:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Thu, 24 Aug 2006 12:09:36 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbHd+uhj2J3uqENTJagDDcfOJpoUQACBAMwAAVm5FA= From: "Bryskin, Igor" To: "Don Fedyk" , "Lou Berger" , "Diego Caviglia" Cc: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Don, > The other point that baffles me is there is not one "standard" MP that > I'm aware of so really we are talking many variations of MP to a > standard CP. So how do you define a CP to variations of MPs? The > document currently oversimplifies this aspect IMHO. I don't think we need to assume that MP is standard in the context of = CP->MP and MP->CP discussion. IMO it does not even have to be MP. We are = talking here about a capability of CP to acquire network resources and = build CP state for an LSP without actually re-programming crossconnects = (case MP->CP). Likewise, we are talking about capability of CP to = release resources and destroy CP state for an LSP without re-programming = crossconnects (case CP->MP). It is out of scope of those mechanisms how = MP (or any other plane) assumes or yields the ownership of resources of = the LSP whose ownership is transferred from/to CP.. Igor > -----Original Message----- >=20 > Diego, > In my experience in talking about this feature with=20 > carriers is that some (but not all) will require such=20 > symmetric behavior. I think the other rational for this=20 > feature are irrelevant. Again, the sole reason I've seen for=20 > this requirement is that to deploy MP->CP some will require=20 > that there be support for CP->MP. >=20 > I therefore think the definition of CP->MP *is* required. =20 > There are multiple options for meeting this requirement, but=20 > the solution must provide the "fallback" capability for=20 > services existing at the time of the initial MP->CP=20 > transition and those created after the transition. >=20 > I think a SHOULD level requirement is sufficient for this=20 > capability, but I'd be interested if those representing=20 > carries on the list differ. >=20 > Lou >=20 > At 03:09 AM 8/24/2006, Diego Caviglia wrote: >=20 >=20 > >In my mind the CP->MP feature can be useful for mainly two purposes: > >1) symmetricity with the companion feature (MP->CP) > >[...] > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a=20 > >must and I have no problem to move it to should/shall/may state. > > > >[...] > >However the focus of the ID is on MP->CP handover and if the=20 > community=20 > >is strongly against of CP->MP even in the form of a should/shall/may=20 > >requirement we can strip this out. > > > >Regards > > > >Diego >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Aug 24 13:09:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIhd-000367-Up for ccamp-archive@ietf.org; Thu, 24 Aug 2006 13:09:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGIha-0002nN-KK for ccamp-archive@ietf.org; Thu, 24 Aug 2006 13:09:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGIa7-0007rb-SE for ccamp-data@psg.com; Thu, 24 Aug 2006 17:01:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.246.11.148] (helo=esc71.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGIa7-0007rK-3R for ccamp@ops.ietf.org; Thu, 24 Aug 2006 17:01:27 +0000 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1GGIZt-0000ma-96; Thu, 24 Aug 2006 13:01:13 -0400 Message-Id: <7.0.1.0.2.20060824125929.03532ef0@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 24 Aug 2006 13:01:13 -0400 To: "Don Fedyk" From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: "Lou Berger" , "Diego Caviglia" , In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40A34F9E6@zrtphxm2.corp.nor tel.com> References: <7.0.1.0.2.20060824075206.03488328@labn.net> <34B3EAA5B3066A42914D28C5ECF5FEA40A34F9E6@zrtphxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 > >If we were to ask could you live without the CP->MP feature what >response would we get versus asking if CP->MP is a soft requirement. From the discussions I've had on this with carriers, for some it's a don't care, for others they won't deploy control plane without this capability. Lou At 10:48 AM 8/24/2006, Don Fedyk wrote: >Lou and Diego, all > >Two points. > >If we were to ask could you live without the CP->MP feature what >response would we get versus asking if CP->MP is a soft requirement. > >The other point that baffles me is there is not one "standard" MP that >I'm aware of so really we are talking many variations of MP to a >standard CP. So how do you define a CP to variations of MPs? The >document currently oversimplifies this aspect IMHO. > >Thanks, >Don > > > -----Original Message----- > > > > Diego, > > In my experience in talking about this feature with > > carriers is that some (but not all) will require such > > symmetric behavior. I think the other rational for this > > feature are irrelevant. Again, the sole reason I've seen for > > this requirement is that to deploy MP->CP some will require > > that there be support for CP->MP. > > > > I therefore think the definition of CP->MP *is* required. > > There are multiple options for meeting this requirement, but > > the solution must provide the "fallback" capability for > > services existing at the time of the initial MP->CP > > transition and those created after the transition. > > > > I think a SHOULD level requirement is sufficient for this > > capability, but I'd be interested if those representing > > carries on the list differ. > > > > Lou > > > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > > > > > > >In my mind the CP->MP feature can be useful for mainly two purposes: > > >1) symmetricity with the companion feature (MP->CP) > > >[...] > > > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a > > >must and I have no problem to move it to should/shall/may state. > > > > > >[...] > > >However the focus of the ID is on MP->CP handover and if the > > community > > >is strongly against of CP->MP even in the form of a should/shall/may > > >requirement we can strip this out. > > > > > >Regards > > > > > >Diego > > > > > > From owner-ccamp@ops.ietf.org Thu Aug 24 23:01:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGRx7-00077z-GK for ccamp-archive@ietf.org; Thu, 24 Aug 2006 23:01:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGRQ2-0007aM-It for ccamp-archive@ietf.org; Thu, 24 Aug 2006 22:27:38 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGRMn-00068C-DZ for ccamp-archive@ietf.org; Thu, 24 Aug 2006 22:24:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGR4q-000CGl-3H for ccamp-data@psg.com; Fri, 25 Aug 2006 02:05:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGR4o-000CGY-Mg for ccamp@ops.ietf.org; Fri, 25 Aug 2006 02:05:43 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4J008C47CHTO@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Fri, 25 Aug 2006 10:09:53 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4J00FUY7CHP6@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Fri, 25 Aug 2006 10:09:53 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4J00E3B71OPV@szxml03-in.huawei.com> for ccamp@ops.ietf.org; Fri, 25 Aug 2006 10:03:25 +0800 (CST) Date: Fri, 25 Aug 2006 09:59:23 +0800 From: Dan Li Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: ccamp Cc: "Li, Han" , "Fedyk, Don" , Papadimitriou Dimitri , Diego Caviglia , Igor Bryskin , "Farrel, Adrian" , Lou Berger , "Brungard, Deborah A, ALABS" , "Drake, John E" Message-id: <008301c6c7ea$165ce820$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi all, The main motivation for this work is MP->CP migration. Our objective is to be able to introduce a control plane into an existing network without disrupting user traffic. We understand that there are operators who would not want to perform this function. They might prefer to set up parallel LSPs using the CP and swap trafic to them before tearing down the MP LSPs, but we believe that this will not be possible in many busy networks. Other operators may prefer to have a network outage, but this will not be acceptable for all other operators. Therefore, in order to ensure interoperability between different vendors' equipment, we believe that a GMPLS process is required for this function. We fully expect it to be quite a simple process. Our main requirement for CP->MP migration is to handle "back-out" of the MP->CP migration process. If there is some problem, the operator would like to be able to return to how things were before hand (i.e. MP control), without disrupting user traffic. We regard this as highly desirable, but probably not a mandatory requirement. Modifying and tearing down LSPs after control plane failure is also a possible motivation, but the detailed requirements will need further examination. As has been pointed out, tear-down may be achieved relatively simply. But modification (for example, re-routing, increase in capacity, etc.) may be more complicated. Other uses of CP->MP migration are interesting, but are not our main motivation, but we would like to observe that if the features that meet our requirements can also be used for other purposes then that is OK. Obviously, from the discussions on the mailing list, our I-D does not currently present a sufficiently focused description of the motivation for this work. We welcome further discussion of the requirements to help us improve the draft. It would be helpful in your discussions if you could understand that we are describing the requirements. If it turns out that the requirements can be met without changing the protocols, then we are very happy. But if you believe that no changes to the protocols are needed, we still need to state the requirements. So perhaps our conversation should be about the functional requirements not about the solutions. Best regards, Dan Li From vides@pcstoforthood.com Fri Aug 25 00:48:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGTcH-0001kP-6E for ccamp-archive@ietf.org; Fri, 25 Aug 2006 00:48:25 -0400 Received: from [61.50.236.226] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GGTc5-000886-UJ for ccamp-archive@ietf.org; Fri, 25 Aug 2006 00:48:25 -0400 Message-ID: <000001c6c801$2e109900$0100007f@localhost> From: "Imogene Hill" To: Subject: Filed under your account via Invoice #93797 Date: Fri, 25 Aug 2006 12:48:05 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C6C801.2E109900" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 2c6813ed945e40b4b5bea39da243c669 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6C801.2E109900 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000E_01C6C801.2E109900" ------=_NextPart_001_000E_01C6C801.2E109900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return one copy of the invoice with this coversheet to OA within 5 calendar days of receipt. I have reviewed the attached invoice, approved the invoice for payment in the above stated amount, and ensured approval. ------=_NextPart_000_0001_01C6C801.2E109900 Content-Type: application/msword; name="Invoice93797.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Invoice93797.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKgAAAAAA AAAAEAAALAAAAAEAAAD+////AAAAACkAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcWAJBAAA+BK/AAAAAAAAEAAAAAAABgAA 2AgAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAAAAAJBBYALhAAABM6AQATOgEA2AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAJIEAAAAAAAAkgQAAJIEAAAAAAAAkgQAAAAAAACSBAAA AAAAAJIEAAAAAAAAkgQAABQAAAAAAAAAAAAAAMwEAAC0AAAACAcAAAAAAAAIBwAAAAAAAAgH AAAAAAAACAcAAAwAAAAUBwAADAAAAIAFAAAAAAAAegkAAOwAAAAsBwAAFgAAAEIHAAAAAAAA QgcAAAAAAABCBwAAAAAAAEIHAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAA+QgAAAIA AAD7CAAAAAAAAPsIAAAAAAAA+wgAAAAAAAD7CAAAAAAAAPsIAAAAAAAA+wgAACQAAABmCgAA aAIAAM4MAACGAAAAHwkAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgQAAAAAAAAdCAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAdCAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB8JAAAAAAAA AAAAAAAAAACSBAAAAAAAAJIEAAAAAAAAQgcAAAAAAAAAAAAAAAAAAEIHAADbAAAANAkAABYA AABpCAAAAAAAAGkIAAAAAAAAaQgAAAAAAAAdCAAAEAAAAJIEAAAAAAAAQgcAAAAAAACSBAAA AAAAAEIHAAAAAAAA+QgAAAAAAAAAAAAAAAAAAGkIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQgAAAAAAAD5CAAAAAAAAAAAAAAAAAAA aQgAAAAAAAAAAAAAAAAAAGkIAAAAAAAAkgQAAAAAAACSBAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaQgAAAAAAABCBwAA AAAAACAHAAAMAAAAEMujlT/AxgEAAAAAAAAAAAgHAAAAAAAALQgAABYAAABpCAAAAAAAAAAA AAAAAAAA7QgAAAwAAABKCQAAMAAAAHoJAAAAAAAAaQgAAAAAAABUDQAAAAAAAEMIAAAcAAAA VA0AAAAAAABpCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQNAAAAAAAAAAAAAAAAAACSBAAA AAAAAGkIAACEAAAAHQgAAAAAAAAdCAAAAAAAAGkIAAAAAAAAHQgAAAAAAAAdCAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAA HwkAAAAAAAAfCQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwgAAAoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAdCAAA AAAAAHoJAAAAAAAAHQgAAAAAAAAdCAAAAAAAAB0IAAAAAAAAHQgAAAAAAAAAAAAAAAAAAIAF AAAAAAAAgAUAAAAAAACABQAAZAEAAOQGAAAkAAAAgAUAAAAAAACABQAAAAAAAIAFAAAAAAAA 5AYAAAAAAACmBAAAFAAAALoEAAAOAAAAyAQAAAQAAACSBAAAAAAAAJIEAAAAAAAAkgQAAAAA AACSBAAAAAAAAJIEAAAAAAAAkgQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhvdCBTdW1tZXIgU3BlY2lhbHMhDQ1WaWFncmEgPSAk MyBwZXIgcGlsbCAoMTAwbWcpDQ1WaWFncmEgU29mdCA9ICQzLjY2IHBlciBwaWxsICgxMDBt ZykNDUNpYWxpcyA9ICQzLjc1IHBlciBwaWxsICgyMG1nKQ0NTGV2aXRyYSA9ICQ0LjkwIHBl ciBwaWxsICgyMG1nKQ0NE0hZUEVSTElOSyAiaHR0cDovL21lZHZlZHJ4LmNvbSIBFENsaWNr IEhlcmUgZm9yIG1vcmUgaW5mbyEVDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAADII AAAzCAAAmggAAJsIAACcCAAAuwgAALwIAAC9CAAA1ggAANcIAADYCAAA8+fz28q+qsqcyr4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGxVoBzlWABZoBzlWADBKEQA1 CIFDSjAAYUowACYCCIEDagAAAAAGCAEVaAc5VgAWaGEXEQA1CIFDSjAAVQgBYUowAAAXFWgH OVYAFmgHOVYANQiBQ0owAGFKMAAgA2oAAAAAFWgHOVYAFmgHOVYANQiBQ0owAFUIAWFKMAAA FxVoBzlWABZoBzlWADUIgUNKJABhSiQAFxVoBzlWABZoCCCoADUIgUNKKABhSigAFxVoBzlW ABZoBzlWADUIgUNKKABhSigAAAsABgAAFQgAABYIAAAzCAAANAgAAFkIAABaCAAAeQgAAHoI AACaCAAAmwgAANgIAADyAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADt AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAA AAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABAAAZ2QHOVYADQAAJmQMAQABUMYIAAAA/wwBAQBnZAc5VgAACwAGAADYCAAA /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABAQAAQEBLAAxkGgBH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAABew 0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACbAAAARAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLKgAAAGgAdAB0 AHAAOgAvAC8AbQBlAGQAdgBlAGQAcgB4AC4AYwBvAG0ALwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgISABIAAQCcAA8ABAAAAAAA AAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAQPH/AgBAAAwEAAAAAAAA AAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNICQR0SAkEAAAAAAAA AAAAAAAAAAAAAAAARABBQPL/oQBEAAwFAAAAAAAAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEA cgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaQDz/7MAUgAMBQAAAAAAAAAADABUAGEA YgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIA CwAAACgAawD0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAAAAAAAABqAJoA swDzAGoADAQAAN43PwAAAAoAVABhAGIAbABlACAARwByAGkAZAAAADcAOlYPABPWMAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAACAA8AAABIAJkA AQACAUgADAUAAAAzjQAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACABAAFABDShAA T0oDAFFKAwBeSgMAYUoQADYAVUCiABEBNgAMBAAAgBWBAAAACQBIAHkAcABlAHIAbABpAG4A awAAAAwAPioBQioCcGgAAP8AAAAAANgAAAAGAAAQAAAFAP////8BAAAABCEAAP//AQCgepkA AAAAAAAAAADYAAAAAAAAAAAAAAAAAAAAAAAVAAAAFgAAADMAAAA0AAAAWQAAAFoAAAB5AAAA egAAAJoAAACbAAAA2gAAAAT/AADAIQAA8fAEAAABAADAIQAA63QEAAABAADAIQAA63QEAAAB AADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA63QEAAABAADAIQAA 63QEAAABAADAIQAA63QEAAABAADAIQAA1AIEAAABAADAIQAAGlkFAAAAAAAVAAAAFgAAADMA AAA0AAAAWQAAAFoAAAB5AAAAegAAAJoAAACbAAAA2gAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAAAAAANoAAABLiAAwABAAAAAAAAABAAAAAAAAAAAAAAAEDp8H AAYAANgIAAAFAAAAAAYAANgIAAAGAAAAAAYAANgIAAAHAAAAmwAAALwAAADWAAAA2AAAABNY FP8VhA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP// AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAI AAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAE AAAAAQAAAAAAAADXAAAA2gAAAAQAAwAAAAAAwwAAAMcAAADaAAAABwA6AAcAAAAAADQAAAC9 AAAA1wAAANoAAAAFAAcABQAHAAAAAADaAAAABwAbAAAABAAAAAgAAADlAAAAAAAAABoAAABZ NgAArHABAGEXEQDyNCoAmHYvAFJ5OgDRXjwA3jc/AAc5VgCyPlcAvx5mAMRHZwDBW24AfRNy ALcscwAREnoAgBWBAERFgwAAM40ACCCoAOxOvAAnL8IACxXgAB4b4AA1fOwAwVH6AERG/gAA AAAA2gAAAAAAAAD/QAOAAQDXAAAA1wAAAJAkiAVdAV0B1wAAAAAAAADXAAAAAAAAAAIQAAAA AAAAANgAAABgAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA //8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAEAAAARxaQAQAAAgIGAwUEBQIDBId6 ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA NRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAA MyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADUm kAEAAAILBgQDBQQEAgSHegBhAAAAgAgAAAAAAAAA/wEBAAAAAABUAGEAaABvAG0AYQAAACIA BAAxCIgYAPDQAgAAaAEAAAAAMXioRjN4qEaCFaOGBQACAAAAIAAAALgAAAABAAEAAAAEAAMQ AQAAACAAAAC4AAAAAQABAAAAAQAAAAAAAAAhAwDwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBPjQAABEAGQBkAAAAGQAAANcAAADXAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgAAAAAAAAAAAAkzgxEA8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA SFgAAAAAKfD/DwEAAT8AAOQEAAD///9/////f////3////9/////f////3////9/3jc/AAAA AAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAEgBTAEEAVgBFACAAWQBPAFUAUgAgAEIA VQBTAEkATgBFAFMAUwAAAAAAAAAOAFcAaQBsAGwAaQBhAG0AIABFAHMAdABoAGUAcgAOAFcA aQBsAGwAaQBhAG0AIABFAHMAdABoAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEA AADghZ/y+U9oEKuRCAArJ7PZMAAAAJwBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAAC8AAAA BAAAAMgAAAAFAAAA4AAAAAYAAADsAAAABwAAAPgAAAAIAAAACAEAAAkAAAAgAQAAEgAAACwB AAAKAAAATAEAAAsAAABYAQAADAAAAGQBAAANAAAAcAEAAA4AAAB8AQAADwAAAIQBAAAQAAAA jAEAABMAAACUAQAAAgAAAOQEAAAeAAAAFAAAAFNBVkUgWU9VUiBCVVNJTkVTUwAAHgAAAAQA AAAAAAAAHgAAABAAAABXaWxsaWFtIEVzdGhlcgAAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAA HgAAAAgAAABOb3JtYWwAAB4AAAAQAAAAV2lsbGlhbSBFc3RoZXIAAB4AAAAEAAAANQAAAB4A AAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAACMhkcAAAAAQAAAAACUeJp/PsYB QAAAAAD+A0U/wMYBQAAAAACKiow/wMYBAwAAAAEAAAADAAAAIAAAAAMAAAC4AAAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1Zwu GxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuXAEAABgBAAAMAAAAAQAAAGgAAAAPAAAA cAAAAAUAAACYAAAABgAAAKAAAAARAAAAqAAAABcAAACwAAAACwAAALgAAAAQAAAAwAAAABMA AADIAAAAFgAAANAAAAANAAAA2AAAAAwAAAD3AAAAAgAAAOQEAAAeAAAAIAAAAFBob2VuaXgg TWFuYWdlbWVudCBDb3Jwb3JhdGlvbgAAAwAAAAEAAAADAAAAAQAAAAMAAADXAAAAAwAAAOYV CwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAEwAAAFNBVkUgWU9V UiBCVVNJTkVTUwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAACsAAAAAwAAAAAA AAAgAAAAAQAAADgAAAACAAAAQAAAAAEAAAACAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAA QQAAAGQAAAAGAAAAAwAAAAgAWwADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAFQAAAGgA dAB0AHAAOgAvAC8AbQBlAGQAdgBlAGQAcgB4AC4AYwBvAG0ALwAAAAAAHwAAAAEAAAAAABIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAD+////CgAAAAsA AAAMAAAADQAAAA4AAAAPAAAAEAAAAP7///8SAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAA /v///xoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAD+////IgAAACMAAAAkAAAAJQAAACYA AAAnAAAAKAAAAP7////9////KwAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQA cgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf// ////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAQPKaVP8DGAS0AAACAAAAA AAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACQAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAAABAAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAuEAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhAAAAABAAAAAAAAABAEMA bwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29mdCBPZmZp Y2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9Dmy cQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0001_01C6C801.2E109900-- From owner-ccamp@ops.ietf.org Fri Aug 25 02:59:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGVfN-0003qw-UK for ccamp-archive@ietf.org; Fri, 25 Aug 2006 02:59:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGVfN-0001wj-RU for ccamp-archive@ietf.org; Fri, 25 Aug 2006 02:59:45 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGVfN-0003Ln-7w for ccamp-archive@ietf.org; Fri, 25 Aug 2006 02:59:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGVXz-000KE8-5Y for ccamp-data@psg.com; Fri, 25 Aug 2006 06:52:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGVXy-000KDu-AW for ccamp@ops.ietf.org; Fri, 25 Aug 2006 06:52:06 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7P6pHKN000424; Fri, 25 Aug 2006 08:51:17 +0200 In-Reply-To: <008301c6c7ea$165ce820$d04c460a@china.huawei.com> To: Dan Li Cc: "Farrel, Adrian" , ccamp , "Brungard, Deborah A, ALABS" , Diego Caviglia , "Fedyk, Don" , Igor Bryskin , "Drake, John E" , Lou Berger , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 08:51:12 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 08:51:16, Serialize complete at 08/25/2006 08:51:16 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 hi - here below a couple of comments o) the first point and i think i mention this already is that at the end speaking about MP in the present context restricts applicability of the "migration", the purpose of this draft is to create a control plane state when the same resources are already in use by an entity external to the control plane - call this an "import" function o) the second when you write "Our main requirement for CP->MP migration is to handle "back-out" of the MP->CP migration process." is on itself confusing; what are you dealing with ? that the transition fails during its instantiation or that once LSP has a control plane state you want to move back where it used to belong - the former is a real issue that has never been discussed - the second is a non-issue (the other entity takes care to rapatriate the state in case, i don't think there is any need for an "export" function simple because we are not going to tell to which entity the LSP shall be brought back as we can have many of those) o) the third point is when you mention "Modifying and tearing down LSPs after control plane failure" i pointed already that a migration from CP to somewhere else is impossible if you don't get access to the CP iself in particular if it is under failure - doesn't seem to be understood by authors (yet) thanks, - d. Dan Li 25/08/2006 03:59 To: ccamp cc: "Li, Han" , "Fedyk, Don" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego Caviglia , Igor Bryskin , "Farrel, Adrian" , Lou Berger , "Brungard, Deborah A, ALABS" , "Drake, John E" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Hi all, The main motivation for this work is MP->CP migration. Our objective is to be able to introduce a control plane into an existing network without disrupting user traffic. We understand that there are operators who would not want to perform this function. They might prefer to set up parallel LSPs using the CP and swap trafic to them before tearing down the MP LSPs, but we believe that this will not be possible in many busy networks. Other operators may prefer to have a network outage, but this will not be acceptable for all other operators. Therefore, in order to ensure interoperability between different vendors' equipment, we believe that a GMPLS process is required for this function. We fully expect it to be quite a simple process. Our main requirement for CP->MP migration is to handle "back-out" of the MP->CP migration process. If there is some problem, the operator would like to be able to return to how things were before hand (i.e. MP control), without disrupting user traffic. We regard this as highly desirable, but probably not a mandatory requirement. Modifying and tearing down LSPs after control plane failure is also a possible motivation, but the detailed requirements will need further examination. As has been pointed out, tear-down may be achieved relatively simply. But modification (for example, re-routing, increase in capacity, etc.) may be more complicated. Other uses of CP->MP migration are interesting, but are not our main motivation, but we would like to observe that if the features that meet our requirements can also be used for other purposes then that is OK. Obviously, from the discussions on the mailing list, our I-D does not currently present a sufficiently focused description of the motivation for this work. We welcome further discussion of the requirements to help us improve the draft. It would be helpful in your discussions if you could understand that we are describing the requirements. If it turns out that the requirements can be met without changing the protocols, then we are very happy. But if you believe that no changes to the protocols are needed, we still need to state the requirements. So perhaps our conversation should be about the functional requirements not about the solutions. Best regards, Dan Li From owner-ccamp@ops.ietf.org Fri Aug 25 04:58:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGXVs-00036H-SL for ccamp-archive@ietf.org; Fri, 25 Aug 2006 04:58:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGXVs-0001y8-PJ for ccamp-archive@ietf.org; Fri, 25 Aug 2006 04:58:04 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGXRv-0006IN-KI for ccamp-archive@ietf.org; Fri, 25 Aug 2006 04:54:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGXMZ-00045b-GZ for ccamp-data@psg.com; Fri, 25 Aug 2006 08:48:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME,MIME_BASE64_TEXT,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGXMY-00045M-HQ; Fri, 25 Aug 2006 08:48:27 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7P8m90f021369; Fri, 25 Aug 2006 10:48:10 +0200 In-Reply-To: To: =?gb2312?B?wO7qzw==?= Cc: "'Adrian Farrel'" , ccamp@ops.ietf.org, "'Dan Li'" , owner-ccamp@ops.ietf.org Subject: Re: =?gb2312?B?tPC4tDogUG9sbGluZyBmb3IgbmV3IFdHIEktRHM=?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 10:48:03 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 10:48:08, Serialize complete at 08/25/2006 10:48:08 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 aGkgLSANCg0Kb24gcG9pbnQgMSkgYmVmb3JlIHRoaW5raW5nIGFib3V0IHVuZG8ncyAmIHJlZG8n cyB0aGUgZmlyc3QgaXNzdWUgaXMgdG8gDQpjb25zaWRlciB0aGF0IGR1cmluZyB0aGUgImltcG9y dCIgb2YgdGhlIGFsbG9jYXRlZCByZXNvdXJjZSAtPiBDUCBzdGF0ZSANCnlvdSBtYXkgaGF2ZSBh IGZhaWx1cmUgYXQgdGhhdCBwb2ludCBpbiB0aW1lIGluIHRoZSBwcm9jZXNzIC0NCg0Kb24gcG9p bnQgMikgaW4gY2FzZSBvZiBDUCBmYWlsdXJlIC0gaW5jbHVkaW5nIHVucmVzcG9uc2l2ZSBDUCBp bnN0YW5jZSAtIGkgDQpkb24ndCBzZWUgaG93IHlvdSBtYXkgdHJpZ2dlciB0aGUgQ1AgdG8gImV4 cG9ydCIgdGhhdCBzdGF0ZQ0KDQp0aGFua3MsDQotIGQuDQoNCg0KDQoNCg0KwO7qzyA8bGloYW5A Y2hpbmFtb2JpbGUuY29tPg0KMjUvMDgvMjAwNiAwMjo1Mw0KIA0KICAgICAgICBUbzogICAgIERp bWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwsICInRGFuIExpJyIgDQo8ZGFu bGlAaHVhd2VpLmNvbT4NCiAgICAgICAgY2M6ICAgICAiJ0FkcmlhbiBGYXJyZWwnIiA8YWRyaWFu QG9sZGRvZy5jby51az4sIA0KPGNjYW1wQG9wcy5pZXRmLm9yZz4sIDxvd25lci1jY2FtcEBvcHMu aWV0Zi5vcmc+DQogICAgICAgIFN1YmplY3Q6ICAgICAgICC08Li0OiBQb2xsaW5nIGZvciBuZXcg V0cgSS1Ecw0KDQoNCg0KSGksDQoNCkZyb20gb3VyIHBlcnNwZWN0aXZlLCB3ZSB0aGluayB0aGUg Zm9sbG93aW5nIHJlcXVpcmVtZW50cyBhcmUgYmV0dGVyIHRvIGJlDQpjb25zaWRlcmVkOg0KDQox KSBJbiBjYXNlIHRoZXJlIGlzIGEgcHJvYmxlbSBhZnRlciB3ZSBkbyBNUC0+Q1AgbW92ZW1lbnQs IHdlIHdvdWxkIGxpa2UgDQp0bw0KYmUgYWJsZSB0byByZXR1cm4gdG8gdGhlIHByZXZpb3VzIHN0 YXRlLiBTbyB0aGUgTVAtPkNQIHByb2NlZHVyZSBtdXN0IGJlDQplcXVpcHBlZCB3aXRoIGEgYmFj ay1vdXQgcHJvY2VkdXJlIHNvIHRoYXQgd2UgY2FuIHJldmVyc2UgdGhlIHByb2NlZHVyZS4NClRo aXMgInVuZG8iIGZ1bmN0aW9uIGFsbG93cyB0cmFuc2ZlciBvZiBjb250cm9sIGZyb20gQ1AtPk1Q Lg0KDQoyKSBJbiB0aGUgZXZlbnQgb2YgYSBDUCBmYWlsdXJlIChzdWNoIGFzIHRoZSBmYWlsdXJl IG9mIHRoZSBjb250cm9sIHBsYW5lIA0KYXQNCmEgbm9kZSksIHdlIG1heSB3aXNoIHRvIGNvbnRy b2wgdGhlIExTUCBhbmQgdGhpcyByZXF1aXJlcyB0aGF0IHRoZSBMU1AgaXMNCnRyYW5zZmVycmVk IGZyb20gdGhlIENQIHRvIHRoZSBNUC4NCg0KUmVnYXJkcywgDQoNCkxpaGFuDQoNCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCkxpIEhhbiwg UGguRC4NCg0KUiZELCBDSElOQSBNT0JJTEUgQ09NTVVOSUNBVElPTlMgQ09SUE9SQVRJT04NCg0K VGVsOiArODYgMTAgNjYwMDY2ODggZXh0LiAzMDkyDQoNCkZheDogKzg2IDEwIDYzNjAwMzQwDQoN Ck1PQklMRTogMTM1MDEwOTMzODUNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCg0KaGkgLSANCg0Kc2VlIGlubGluZQ0KDQoNCg0KDQoNCkRh biBMaSA8ZGFubGlAaHVhd2VpLmNvbT4NClNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9y Zw0KMjEvMDgvMjAwNiAwNDowMQ0KIA0KICAgICAgICBUbzogICAgIERpbWl0cmkgUEFQQURJTUlU UklPVS9CRS9BTENBVEVMQEFMQ0FURUwsIEFkcmlhbiBGYXJyZWwgDQo8YWRyaWFuQG9sZGRvZy5j by51az4NCiAgICAgICAgY2M6ICAgICBjY2FtcEBvcHMuaWV0Zi5vcmcsIG93bmVyLWNjYW1wQG9w cy5pZXRmLm9yZw0KICAgICAgICBTdWJqZWN0OiAgICAgICAgUmU6IFBvbGxpbmcgZm9yIG5ldyBX RyBJLURzDQoNCg0KSGkgRGltaXRyaSwNCg0KUGxlYXNlIHNlZSBpbiBsaW5lLg0KDQpSZWdhcmRz LA0KDQpEYW4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206IDxEaW1pdHJp LlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZT4NClRvOiAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBv bGRkb2cuY28udWs+DQpDYzogPGNjYW1wQG9wcy5pZXRmLm9yZz47IDxvd25lci1jY2FtcEBvcHMu aWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDE3LCAyMDA2IDY6MzIgQU0NClN1Ympl Y3Q6IFJlOiBQb2xsaW5nIGZvciBuZXcgV0cgSS1Ecw0KDQoNCj4gYWRyaWFuIC0gc2VlIGluLWxp bmUNCj4gDQo+IEFkcmlhbiBGYXJyZWwgd3JvdGU6DQo+ID4gSGksDQo+ID4gDQo+ID4gQXMgZGlz Y3Vzc2VkIGluIE1vbnRyZWFsLCB3ZSBuZWVkIHRvIHBvbGwgZm9yIGEgY291cGxlIG9mIG5ldyBX RyANCmRyYWZ0cy4NCj4gPiANCj4gPiANCj4gDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1iZXJuc3RlaW4tY2NhbXAtZ21wbHMtdmNhdC1sY2FzLTA0DQoNCi50eHQg DQoNCj4gDQo+ID4gaGFzIGJlZW4gdXBkYXRlZCBieSB0aGUgYXV0aG9ycyB0byBwcm92aWRlIGZ1 cnRoZXIgZGV0YWlscyBhbmQgDQo+ID4gY2xhcmlmaWNhdGlvbi4NCj4gDQo+IC0gb2sgLSANCj4g DQo+ID4gDQo+IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2F2 aWdsaWEtY2NhbXAtcGMtYW5kLXNjLXJlcXMtMDIudA0KDQp4dA0KDQo+IA0KPiAtIGd1ZXNzIGl0 IGlzIHYwMy50eHQgPyAtDQo+IA0KPiA+IGhhcyBiZWVuIHVwZGF0ZWQgc2luY2UgdGhlIHZlcnNp b24gZGlzY3Vzc2VkIGluIE1vbnRyZWFsLg0KPiANCj4gaSBhbSBvayBpbiBpbnZlc3RpZ2F0aW5n IHRoZSBNUC0+Q1AgYnV0IGkgaGF2ZSB0d28gY29uY2VybnMgdGhhdCBpbWhvIA0KPiBzaG91bGQg ZGVzZXJ2ZSBtb3JlIHNwZWNpZmljIGF0dGVudGlvbiB0byBtYWludGFpbiBjb25zaXN0ZW5jeSB3 cnQgdG8gDQo+IENQLT5NUA0KPiANCj4gc2VjdGlvbiAyLjI6IGlmIGNvbnRyb2wgaXMgbG9zdCBm b3IgYW4gTFNQIChkdXJpbmcgQ1AgZmFpbHVyZSkgaG93IGNhbiANCml0IA0KPiBiZSBwb3NzaWJs ZSB0cmFuc2ZlciB0aGF0IExTUCBmcm9tIHRoZSBDUCAtPiBNUCA/IA0KDQpbZGFuXSBZZXMsIHRo ZXJlIGlzIGEgcHJvYmxlbSBpZiB3ZSBzdGlsbCB3YW50IHRvIHVzZSB0aGUgY29udHJvbCBwbGFu ZSB0byANCg0KZG8gdGhlIA0KQ1AtPk1QIHRyYW5zZmVyLiBVbmxlc3MgdGhlIHRyYW5zZmVyIGlz IGJhc2VkIG9uIHRoZSBwcmVkZXRlcm1pbmVkIHBvbGljeSwgDQoNCk1QIA0KdGFrZXMgdGhlIGNv bnRyb2wgb2YgdGhlIExTUCByZXNvdXJjZSBkaXJlY3RseSAobm8gc2lnbmFsaW5nIHJlcXVpcmVk KSwgDQpidXQgdGhpcyB3YXkNCnNob3VsZCBub3QgYmUgZGlzY3Vzc2VkIGluIENDQU1QLg0KDQpb ZHBdIG9rIHNvIHdoYXQncyBsZWZ0IGZvciB0aGlzIGRvYyA/IGNvbmNlcm5pbmcgdGhlIE1QLWRy aXZlbiBmYWlsb3ZlciAtIA0KaW1obyBub3RoaW5nDQogDQo+IHNlY3Rpb24gNC40OiB3aHkgdGhl IGRvY3VtZW50IGFzc3VtZXMgdGhhdCBib3RoIE1VU1QgYmUgc3VwcG9ydGVkID8gaW4gDQo+IHBh cnQuIGNvbmNlcm5pbmcgdGhlIENQLT5NUCBpZiBvbmUgZG9lcyBpbXBsZW1lbnQgY3VycmVudCBH TVBMUyANCnNpZ25hbGluZyANCj4gcmVzdGFydC9yZWNvdmVyeSB3aHkgc2hhbGwgdGhpcyBiZSBt YW5kYXRlZCA/IGluIGJyaWVmLCB0aGUgZG9jdW1lbnQgDQpzaGFsbCANCj4gdGFrZSBpbnRvIGFj Y291bnQgZXhpc3RpbmcgbWVjaGFuaXNtcyBhbmQgcHJldmVudCBvdmVybGFwcyAod2l0aCANCmV4 aXN0aW5nIA0KPiBHTVBMUyBtZWNoYW5pc21zKQ0KPiANCltkYW5dIEkgdGhpbmsgdGhlIENQLT5N UCBzaG91bGQgbm90IGJlIHRoZSBtYW5kYXRvcnkgcmVxdWlyZW1lbnQuDQoNCltkcF0gdGhpcyBp cyB3aGF0IGkgdGhvdWdodA0KDQo+IGhlbmNlLCBpdCBpcyBzdHJvbmdseSBzdWdnZXN0ZWQgdG8g aWRlbnRpZnkgY29uZGl0aW9ucyB3aGVuIHN1Y2ggQ1AtPk1QIA0KaXMgDQo+IHJlcXVpcmVkIChh bmQgbm90IGFuIGFsdGVybmF0aXZlIHRvIGV4aXN0aW5nIENQIG1lY2hhbmlzbXMpIGIvZiANCj4g cHJvZ3Jlc3NpbmcgdGhhdCBwYXJ0DQo+IA0KW2Rhbl0gSW4gb3JkZXIgdG8gbWFrZSB0aGUgY2Fy cmllcnMnIGxpZmUgZWFzeSwgd2hlbiB3ZSBwcm92aWRlIHRoZSBNUC0+Q1ANCmNvbnZlcnNpb24g ZmVhdHVyZSwgdGhlIHJldmVyc2UgcHJvY2VkdXJlIChDUC0+TVApIG1heSBhbHNvIGlzIG5lZWRl ZCBqdXN0DQpzaW1wbHkgaW4gY2FzZSB0aGUgY2FycmllcnMgd2FudCB0byB3aXRoZHJhdyB0aGVp ciBwcmV2aW91cyBkZWNpc2lvbiwgYW5kDQp0aGV5IGFsc28gZmVlbCBtb3JlIGNvbWZvcnRhYmxl IHdpdGggdGhpcyAidW5kbyIgZnVuY3Rpb247IEluIG9yZGVyIHRvIA0KYWNoaWV2ZQ0KdGhpcywg d2Ugc2hvdWxkIGhhdmUgdGhlIHdvcmtpbmcgY29udHJvbCBwbGFuZS4gDQoNCltkcF0gY29uY2Vy bmluZyBDUC0+TVAgaW5wdXQgeW91IHByb3ZpZGVkIHdvdWxkIGJlIGhlbHBmdWwgdG8gaGF2ZSAN CmNhcnJpZXIncyANCnNwZWFraW5nIGZvciB0aGVtc2VsdmVzIC0gbm93IHRoZXJlIGlzIGluZGVl ZCBhIHNpZGUgcXVlc3Rpb24gc2hhbGwgQ0NBTVAgDQp0YWtlDQpjYXJlIGFib3V0IG9wZXJhdG9y cyB0aGF0IHdhbnQgdG8gc3RlcCBiYWNrIGZyb20gR01QTFMgb3IgbW9yZSBnZW5lcmFsbHkgDQph bnkNCmNvbnRyb2wgcGxhbmUgdGVjaG5vbG9neSAodXN1YWxseSBjb25jZXJuIGlzIGhvdyB0byBt b3ZlIGZvcndhcmQgbm90IA0KYmFja3dhcmQpDQoNCiANCj4gDQpodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hbGktY2NhbXAtbXBscy1ncmFjZWZ1bC1zaHV0ZG93bi0w DQoNCjQudHh0IA0KDQo+IA0KPiA+IGhhcyBiZWVuIHVwZGF0ZWQgYXMgWmFmYXIgc2F5cyBpbiBo aXMgcHJldmlvdXMgZW1haWwuDQo+IA0KPiBpbmZvcm1hdGlvbmFsIGltaG8gLSBpbiBpdHMgY3Vy cmVudCB2ZXJzaW9uIA0KPiANCj4gLSBub3Qgc3VyZSB0byB1bmRlcnN0YW5kIHdoeSB0aGUgUGF0 aEVyci9Ob3RpZnkgY2FuIGJlIHByb2Nlc3NlZCBieSB0aGUgDQo+IGhlYWQtZW5kIG9ubHkgKHdo YXQgYWJvdXQgc2VnbWVudCByZWNvdmVyeSBhbmQgc3RpdGNoaW5nIGNhc2UpIC0gd2h5IA0Kb25s eSANCj4gTUJCIGlzIHBvc3NpYmxlIHVwb24gcmVjZXB0aW9uIChwbHMgdXNlIEUyRSByZWNvdmVy eS9TZWdtZW50IHJlY292ZXJ5IA0KPiBjYXBhYmlsaXRpZXMgYXMgeW91IGFkZHJlc3MgR01QTFMg bmV0d29ya3MpDQo+IA0KPiAtIGNvbXBhcmVkIHRvIHBhdGgtcmVvcHQsIGVycm9yIGRlc2NyaXB0 aW9uIGlzIGlkZW50aWNhbCBmb3IgdGhlIFRFIGxpbmsgDQoNCg0KPiBjYXNlIHdoaWNoIGxlYWRz IHRvIHRoZSBmb2xsb3dpbmcgcG9pbnQgLSBpZiBlcnJvcnMgY29kZS92YWx1ZSBhcmUgdGhlIA0K PiBzYW1lIGhvdyB0byBkaXN0aW5ndWlzaCB0aGVtIChhc3N1bWluZyB0aGF0IHRoZSBxdWVyeSBw cm9jZWR1cmUgDQpkZXNjcmliZWQgDQo+IGluIHBhdGgtcmVvcHQgaXMgdXNlZCBkdXJpbmcgdGhl IHNldHVwIG9mIHRoYXQgTFNQKSA/IC0gY29tbWVudCBpcyBtb3JlIA0KPiBmb3IgdGhlIHBhdGgt cmVvcHQgZHJhZnQgdGhhbiB5b3VycyBidXQgc2luY2UgdGhlcmUgaXMgYW4gb3ZlcmxhcCAuLi4g aXQgDQoNCg0KPiBtdXN0IGJlIGFkZHJlc3NlZCBpbiBhIHdheSBvciBhbm90aGVyIChub3RlIHRo YXQgd2hlbiBmdWxseSBoZWFkLWVuZCANCj4gZHJpdmVuIG9wZXJhdGlvbnMgbG9vayBzaW1pbGFy IGJ1dCB0aGVyZSBpcyBhIG1ham9yIGRpZmZlcmVuY2Ugcm9sZSBvZiANCj4gdGltaW5nIGFuZCBz ZXZlcml0eSBvZiB0aGUgZXJyb3IgY29kZS92YWx1ZSkgDQo+IA0KPiAtIGluIGNhc2Ugc2h1dGRv d24gb2YgYSBwcm90ZWN0ZWQgY29tcG9uZW50IGxpbmsgKG9mIGEgYnVuZGxlKSBpcyANCj4gaW5p dGlhdGVkIHdoeSBjYW4ndCBsaW5rIHByb3RlY3Rpb24gYmUgdXNlZCA/DQo+IA0KPiA+IFBsZWFz ZSBzZW5kIHllcyBvciBubyBmb3IgdGhlc2UgSS1Ecy4NCj4gPiANCj4gPiBSZWFzb25zIGFuZCBv cGluaW9ucyBhcmUgYWxzbyB3ZWxjb21lZC4NCj4gPiANCj4gPiBUaGFua3MsDQo+ID4gQWRyaWFu IA0KPiANCj4gDQoNCg0KDQoNCg0KDQoNCg== From owner-ccamp@ops.ietf.org Fri Aug 25 06:24:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYrh-00052q-Kd for ccamp-archive@ietf.org; Fri, 25 Aug 2006 06:24:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGY5u-0007aC-M1 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 05:35:18 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGY10-0006yd-IP for ccamp-archive@ietf.org; Fri, 25 Aug 2006 05:30:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGXwv-0007Qn-T9 for ccamp-data@psg.com; Fri, 25 Aug 2006 09:26:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGXwv-0007QZ-3z for ccamp@ops.ietf.org; Fri, 25 Aug 2006 09:26:01 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7P9PpDZ017660; Fri, 25 Aug 2006 11:25:51 +0200 In-Reply-To: To: "Diego Caviglia" Cc: ibryskin@movaz.com, ccamp@ops.ietf.org, lberger@labn.net Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 11:25:46 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 11:25:50, Serialize complete at 08/25/2006 11:25:50 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 diego - i think this has been mentioned a couple of times - there is no need to make any assumption about MP whatsover in the context of CP capability we're discussing here - discussion deviated due to the context where the present i-d has been discussed this i-d shall just focus on an import functionality of an already allocated resource (without making assumption on its current owner) this turns out that there is no possibility to have a revertive behaviour as from CP -> X, as the former won't keep track of this origin the only thing this i-d could mention is that the previous owner Y may wish to provide from its own import functionality such as to allow CP -> Y transition thanks, - d. "Diego Caviglia" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 10:56 To: ibryskin@movaz.com cc: "Don Fedyk" , "Lou Berger" , "Diego Caviglia" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Igor, what you say is exactly what we had in mind thinking about the ID. Regards Diego "Bryskin, Igor" on 24/08/2006 18.09.36 To: "Don Fedyk" , "Lou Berger" , "Diego Caviglia" cc: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Don, > The other point that baffles me is there is not one "standard" MP that > I'm aware of so really we are talking many variations of MP to a > standard CP. So how do you define a CP to variations of MPs? The > document currently oversimplifies this aspect IMHO. I don't think we need to assume that MP is standard in the context of CP->MP and MP->CP discussion. IMO it does not even have to be MP. We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP.. Igor > -----Original Message----- > > Diego, > In my experience in talking about this feature with > carriers is that some (but not all) will require such > symmetric behavior. I think the other rational for this > feature are irrelevant. Again, the sole reason I've seen for > this requirement is that to deploy MP->CP some will require > that there be support for CP->MP. > > I therefore think the definition of CP->MP *is* required. > There are multiple options for meeting this requirement, but > the solution must provide the "fallback" capability for > services existing at the time of the initial MP->CP > transition and those created after the transition. > > I think a SHOULD level requirement is sufficient for this > capability, but I'd be interested if those representing > carries on the list differ. > > Lou > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > > > >In my mind the CP->MP feature can be useful for mainly two purposes: > >1) symmetricity with the companion feature (MP->CP) > >[...] > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a > >must and I have no problem to move it to should/shall/may state. > > > >[...] > >However the focus of the ID is on MP->CP handover and if the > community > >is strongly against of CP->MP even in the form of a should/shall/may > >requirement we can strip this out. > > > >Regards > > > >Diego > > > From owner-ccamp@ops.ietf.org Fri Aug 25 07:12:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGZbs-0003Sb-7O for ccamp-archive@ietf.org; Fri, 25 Aug 2006 07:12:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGXmL-0004jc-Ns for ccamp-archive@ietf.org; Fri, 25 Aug 2006 05:15:05 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGXaU-0006VZ-A3 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 05:02:52 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGXWM-0005CB-QA for ccamp-data@psg.com; Fri, 25 Aug 2006 08:58:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGXWL-0005Bp-RB for ccamp@ops.ietf.org; Fri, 25 Aug 2006 08:58:34 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7P8w4B7006912; Fri, 25 Aug 2006 09:58:05 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: ibryskin@movaz.com Cc: ""Don Fedyk" , ""Lou Berger" , ""Diego Caviglia" , " X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Fri, 25 Aug 2006 10:56:35 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 25/08/2006 09:58:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Igor, what you say is exactly what we had in mind thinking about the ID. Regards Diego "Bryskin, Igor" on 24/08/2006 18.09.36 To: "Don Fedyk" , "Lou Berger" , "Diego Caviglia" cc: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Don, > The other point that baffles me is there is not one "standard" MP that > I'm aware of so really we are talking many variations of MP to a > standard CP. So how do you define a CP to variations of MPs? The > document currently oversimplifies this aspect IMHO. I don't think we need to assume that MP is standard in the context of CP->MP and MP->CP discussion. IMO it does not even have to be MP. We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP.. Igor > -----Original Message----- > > Diego, > In my experience in talking about this feature with > carriers is that some (but not all) will require such > symmetric behavior. I think the other rational for this > feature are irrelevant. Again, the sole reason I've seen for > this requirement is that to deploy MP->CP some will require > that there be support for CP->MP. > > I therefore think the definition of CP->MP *is* required. > There are multiple options for meeting this requirement, but > the solution must provide the "fallback" capability for > services existing at the time of the initial MP->CP > transition and those created after the transition. > > I think a SHOULD level requirement is sufficient for this > capability, but I'd be interested if those representing > carries on the list differ. > > Lou > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > > > >In my mind the CP->MP feature can be useful for mainly two purposes: > >1) symmetricity with the companion feature (MP->CP) > >[...] > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a > >must and I have no problem to move it to should/shall/may state. > > > >[...] > >However the focus of the ID is on MP->CP handover and if the > community > >is strongly against of CP->MP even in the form of a should/shall/may > >requirement we can strip this out. > > > >Regards > > > >Diego > > > From owner-ccamp@ops.ietf.org Fri Aug 25 09:55:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGc9g-00019q-SY for ccamp-archive@ietf.org; Fri, 25 Aug 2006 09:55:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGc9f-0008Hc-DY for ccamp-archive@ietf.org; Fri, 25 Aug 2006 09:55:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGc1g-0005hA-CJ for ccamp-data@psg.com; Fri, 25 Aug 2006 13:47:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGc1f-0005gx-GS for ccamp@ops.ietf.org; Fri, 25 Aug 2006 13:47:11 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 09:47:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIEu+IUIQ+96hTQbqJkeo36FBC9wAN5EcA From: "Bryskin, Igor" To: , "Dan Li" Cc: "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Fedyk, Don" , "Drake, John E" , "Lou Berger" , "Li, Han" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Dimitri, My understanding of the MP->CP migration process failure and it's = "back-out" requirement is as follows: a) immediate failure of creating CP state for the services provisioned = by MP. This failure does not require CP->MP feature b) initial migration MP->CP succeeded, however, after some time (say, 1 = month) of provisioning via CP (and possibly creating many services = solely via CP), provider decides that CP is not good or mature enough = and wants go back to old-fashioned MP provisioning. I don't see how the = operator will not loose these new services without the CP->MP function. With all due respect the call on CP->MP function is provider's - not = yours/Alcatel, mine/Movaz or John's/ Boeing. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:51 AM To: Dan Li Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) hi - here below a couple of comments o) the first point and i think i mention this already is that at the end = speaking about MP in the present context restricts applicability of the=20 "migration", the purpose of this draft is to create a control plane = state=20 when the same resources are already in use by an entity external to the=20 control plane - call this an "import" function o) the second when you write "Our main requirement for CP->MP migration = is=20 to handle "back-out" of the MP->CP migration process." is on itself=20 confusing; what are you dealing with ? that the transition fails during=20 its instantiation or that once LSP has a control plane state you want to = move back where it used to belong - the former is a real issue that has=20 never been discussed - the second is a non-issue (the other entity takes = care to rapatriate the state in case, i don't think there is any need = for=20 an "export" function simple because we are not going to tell to which=20 entity the LSP shall be brought back as we can have many of those) o) the third point is when you mention "Modifying and tearing down LSPs=20 after control plane failure" i pointed already that a migration from CP = to=20 somewhere else is impossible if you don't get access to the CP iself in=20 particular if it is under failure - doesn't seem to be understood by=20 authors (yet) thanks, - d. Dan Li 25/08/2006 03:59 =20 To: ccamp cc: "Li, Han" , "Fedyk, Don"=20 , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego=20 Caviglia , Igor Bryskin = ,=20 "Farrel, Adrian" , Lou Berger ,=20 "Brungard, Deborah A, ALABS" , "Drake, John E"=20 Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Hi all, The main motivation for this work is MP->CP migration. Our objective is = to=20 be able to introduce a control plane into an existing network without=20 disrupting user traffic. We understand that there are operators who would not want to perform = this=20 function. They might prefer to set up parallel LSPs using the CP and = swap=20 trafic to them before tearing down the MP LSPs, but we believe that this = will not be possible in many busy networks. Other operators may prefer = to=20 have a network outage, but this will not be acceptable for all other=20 operators.=20 Therefore, in order to ensure interoperability between different = vendors'=20 equipment, we believe that a GMPLS process is required for this = function.=20 We=20 fully expect it to be quite a simple process. Our main requirement for CP->MP migration is to handle "back-out" of the = MP->CP migration process. If there is some problem, the operator would=20 like=20 to be able to return to how things were before hand (i.e. MP control),=20 without disrupting user traffic. We regard this as highly desirable, but = probably not a mandatory requirement. Modifying and tearing down LSPs after control plane failure is also a=20 possible motivation, but the detailed requirements will need further=20 examination. As has been pointed out, tear-down may be achieved = relatively=20 simply. But modification (for example, re-routing, increase in capacity, = etc.) may be more complicated. Other uses of CP->MP migration are interesting, but are not our main=20 motivation, but we would like to observe that if the features that meet=20 our=20 requirements can also be used for other purposes then that is OK. Obviously, from the discussions on the mailing list, our I-D does not=20 currently present a sufficiently focused description of the motivation = for=20 this work. We welcome further discussion of the requirements to help us=20 improve the draft. It would be helpful in your discussions if you could understand that we=20 are=20 describing the requirements. If it turns out that the requirements can = be=20 met without changing the protocols, then we are very happy. But if you=20 believe that no changes to the protocols are needed, we still need to=20 state=20 the requirements. So perhaps our conversation should be about the=20 functional=20 requirements not about the solutions. Best regards, Dan Li From owner-ccamp@ops.ietf.org Fri Aug 25 10:46:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGcx9-0002QZ-7e for ccamp-archive@ietf.org; Fri, 25 Aug 2006 10:46:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGcx7-0003Kb-R0 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 10:46:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGcrD-000BJc-UZ for ccamp-data@psg.com; Fri, 25 Aug 2006 14:40:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGcrD-000BJE-2S for ccamp@ops.ietf.org; Fri, 25 Aug 2006 14:40:27 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k7PEY0I03485; Fri, 25 Aug 2006 10:34:00 -0400 (EDT) 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 Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Fri, 25 Aug 2006 10:40:01 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A3AB60A@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIEu+IUIQ+96hTQbqJkeo36FBC9wAN5EcAAAGuI2A= From: "Don Fedyk" To: "Bryskin, Igor" , , "Dan Li" Cc: "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" , "Li, Han" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hi Igor > -----Original Message----- >=20 > Dimitri, >=20 > My understanding of the MP->CP migration process failure and=20 > it's "back-out" requirement is as follows: >=20 > a) immediate failure of creating CP state for the services=20 > provisioned by MP. This failure does not require CP->MP feature > b) initial migration MP->CP succeeded, however, after some=20 > time (say, 1 month) of provisioning via CP (and possibly=20 > creating many services solely via CP), provider decides that=20 > CP is not good or mature enough and wants go back to=20 > old-fashioned MP provisioning. I don't see how the operator=20 > will not loose these new services without the CP->MP function. I get the feeling we are grasping here. The providers usually have a staging and evaluation phase in a test bed before deploying a new feature like a control plane. If they decide they don't want it never goes live.=20 What is the difference between a MP based connection and CP based connection with a static ERO and no backup? I would think a better goal would be to make such a static version as good as a management plane version.=20 >=20 > With all due respect the call on CP->MP function is=20 > provider's - not yours/Alcatel, mine/Movaz or John's/ Boeing. So the providers should be writing the requirement document rather than us trying to reverse engineer the root of the problem. =20 I think there may be something here but I think even the requirements as stated assume too much of the solution. What is the real issue? Regards, Don=20 >=20 > Igor >=20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Friday, August 25, 2006 2:51 AM > To: Dan Li > Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego=20 > Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou=20 > Berger; Li, Han > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 >=20 > hi - here below a couple of comments >=20 > o) the first point and i think i mention this already is that=20 > at the end speaking about MP in the present context restricts=20 > applicability of the "migration", the purpose of this draft=20 > is to create a control plane state when the same resources=20 > are already in use by an entity external to the control plane=20 > - call this an "import" function >=20 > o) the second when you write "Our main requirement for CP->MP=20 > migration is to handle "back-out" of the MP->CP migration=20 > process." is on itself confusing; what are you dealing with ?=20 > that the transition fails during its instantiation or that=20 > once LSP has a control plane state you want to move back=20 > where it used to belong - the former is a real issue that has=20 > never been discussed - the second is a non-issue (the other=20 > entity takes care to rapatriate the state in case, i don't=20 > think there is any need for an "export" function simple=20 > because we are not going to tell to which entity the LSP=20 > shall be brought back as we can have many of those) >=20 > o) the third point is when you mention "Modifying and tearing=20 > down LSPs after control plane failure" i pointed already that=20 > a migration from CP to somewhere else is impossible if you=20 > don't get access to the CP iself in particular if it is under=20 > failure - doesn't seem to be understood by authors (yet) >=20 > thanks, > - d. >=20 >=20 From owner-ccamp@ops.ietf.org Fri Aug 25 10:56:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGd71-0000CB-Qu for ccamp-archive@ietf.org; Fri, 25 Aug 2006 10:56:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGd70-0006Ei-I2 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 10:56:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGd0V-000CJg-MM for ccamp-data@psg.com; Fri, 25 Aug 2006 14:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGd0V-000CJH-5A for ccamp@ops.ietf.org; Fri, 25 Aug 2006 14:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6097B32899; Fri, 25 Aug 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GGd0U-0000xv-9D; Fri, 25 Aug 2006 10:50:02 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Extensions to GMPLS RSVP Graceful Restart' to Proposed Standard (draft-ietf-ccamp-rsvp-restart-ext) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Fri, 25 Aug 2006 10:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Extensions to GMPLS RSVP Graceful Restart ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-05.txt From owner-ccamp@ops.ietf.org Fri Aug 25 11:16:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdPk-0000gO-Oo for ccamp-archive@ietf.org; Fri, 25 Aug 2006 11:16:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGdK0-0002IK-9H for ccamp-archive@ietf.org; Fri, 25 Aug 2006 11:10:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGdCX-000DhU-J2 for ccamp-data@psg.com; Fri, 25 Aug 2006 15:02:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGdCS-000Dh0-2x for ccamp@ops.ietf.org; Fri, 25 Aug 2006 15:02:24 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6770C328B4; Fri, 25 Aug 2006 15:02:23 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GGdCR-00016z-A3; Fri, 25 Aug 2006 11:02:23 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Exclude Routes - Extension to RSVP-TE' to Proposed Standard (draft-ietf-ccamp-rsvp-te-exclude-route) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Fri, 25 Aug 2006 11:02:23 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Exclude Routes - Extension to RSVP-TE ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.txt From owner-ccamp@ops.ietf.org Fri Aug 25 11:55:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGe1e-0006wG-BE for ccamp-archive@ietf.org; Fri, 25 Aug 2006 11:55:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGe1b-0001CM-S6 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 11:55:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGdwc-000I5x-9j for ccamp-data@psg.com; Fri, 25 Aug 2006 15:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGdwb-000I5M-98 for ccamp@ops.ietf.org; Fri, 25 Aug 2006 15:50:05 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PFnOQO011083; Fri, 25 Aug 2006 17:49:25 +0200 In-Reply-To: To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Fedyk, Don" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 17:49:17 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 17:49:24, Serialize complete at 08/25/2006 17:49:24 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 igor point a) i don't say that the CP import requires MP intervention - i just say this is the only case that requires specification from CCAMP perspective point b) then operators askes to his new fashioned MP to implement an import function - why shall CCAMP care about exporting CP states ? -d. "Bryskin, Igor" 25/08/2006 15:47 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" cc: "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Fedyk, Don" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, My understanding of the MP->CP migration process failure and it's "back-out" requirement is as follows: a) immediate failure of creating CP state for the services provisioned by MP. This failure does not require CP->MP feature b) initial migration MP->CP succeeded, however, after some time (say, 1 month) of provisioning via CP (and possibly creating many services solely via CP), provider decides that CP is not good or mature enough and wants go back to old-fashioned MP provisioning. I don't see how the operator will not loose these new services without the CP->MP function. With all due respect the call on CP->MP function is provider's - not yours/Alcatel, mine/Movaz or John's/ Boeing. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:51 AM To: Dan Li Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) hi - here below a couple of comments o) the first point and i think i mention this already is that at the end speaking about MP in the present context restricts applicability of the "migration", the purpose of this draft is to create a control plane state when the same resources are already in use by an entity external to the control plane - call this an "import" function o) the second when you write "Our main requirement for CP->MP migration is to handle "back-out" of the MP->CP migration process." is on itself confusing; what are you dealing with ? that the transition fails during its instantiation or that once LSP has a control plane state you want to move back where it used to belong - the former is a real issue that has never been discussed - the second is a non-issue (the other entity takes care to rapatriate the state in case, i don't think there is any need for an "export" function simple because we are not going to tell to which entity the LSP shall be brought back as we can have many of those) o) the third point is when you mention "Modifying and tearing down LSPs after control plane failure" i pointed already that a migration from CP to somewhere else is impossible if you don't get access to the CP iself in particular if it is under failure - doesn't seem to be understood by authors (yet) thanks, - d. Dan Li 25/08/2006 03:59 To: ccamp cc: "Li, Han" , "Fedyk, Don" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego Caviglia , Igor Bryskin , "Farrel, Adrian" , Lou Berger , "Brungard, Deborah A, ALABS" , "Drake, John E" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Hi all, The main motivation for this work is MP->CP migration. Our objective is to be able to introduce a control plane into an existing network without disrupting user traffic. We understand that there are operators who would not want to perform this function. They might prefer to set up parallel LSPs using the CP and swap trafic to them before tearing down the MP LSPs, but we believe that this will not be possible in many busy networks. Other operators may prefer to have a network outage, but this will not be acceptable for all other operators. Therefore, in order to ensure interoperability between different vendors' equipment, we believe that a GMPLS process is required for this function. We fully expect it to be quite a simple process. Our main requirement for CP->MP migration is to handle "back-out" of the MP->CP migration process. If there is some problem, the operator would like to be able to return to how things were before hand (i.e. MP control), without disrupting user traffic. We regard this as highly desirable, but probably not a mandatory requirement. Modifying and tearing down LSPs after control plane failure is also a possible motivation, but the detailed requirements will need further examination. As has been pointed out, tear-down may be achieved relatively simply. But modification (for example, re-routing, increase in capacity, etc.) may be more complicated. Other uses of CP->MP migration are interesting, but are not our main motivation, but we would like to observe that if the features that meet our requirements can also be used for other purposes then that is OK. Obviously, from the discussions on the mailing list, our I-D does not currently present a sufficiently focused description of the motivation for this work. We welcome further discussion of the requirements to help us improve the draft. It would be helpful in your discussions if you could understand that we are describing the requirements. If it turns out that the requirements can be met without changing the protocols, then we are very happy. But if you believe that no changes to the protocols are needed, we still need to state the requirements. So perhaps our conversation should be about the functional requirements not about the solutions. Best regards, Dan Li From owner-ccamp@ops.ietf.org Fri Aug 25 11:56:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGe2s-00089s-8L for ccamp-archive@ietf.org; Fri, 25 Aug 2006 11:56:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGe2p-0001JW-V1 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 11:56:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGdz8-000IMT-EA for ccamp-data@psg.com; Fri, 25 Aug 2006 15:52:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGdz7-000IMA-Nd for ccamp@ops.ietf.org; Fri, 25 Aug 2006 15:52:42 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PFpjVN012528; Fri, 25 Aug 2006 17:51:45 +0200 In-Reply-To: <7.0.1.0.2.20060825114514.046e3658@labn.net> To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 17:51:38 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 17:51:43, Serialize complete at 08/25/2006 17:51:43 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 lou - and why shall CCAMP provide a function to export states outside of its domain of competence thanks, - d. Lou Berger 25/08/2006 17:49 To: "Don Fedyk" cc: "Bryskin, Igor" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Don, At 10:40 AM 8/25/2006, Don Fedyk wrote: >I think there may be something here but I think even the requirements as >stated assume too much of the solution. What is the real issue? Per my previous e-mail: At 01:01 PM 8/24/2006, Lou Berger wrote: >At 10:48 AM 8/24/2006, Don Fedyk wrote: >>[...] >>If we were to ask could you live without the CP->MP feature what >>response would we get versus asking if CP->MP is a soft requirement. > > From the discussions I've had on this with carriers, for some it's > a don't care, for others they won't deploy control plane without > this capability. > >Lou AND At 08:15 AM 8/24/2006, Lou Berger wrote: >[...]I therefore think the definition of CP->MP *is* >required. There are multiple options for meeting this requirement, >but the solution must provide the "fallback" capability for services >existing at the time of the initial MP->CP transition and those >created after the transition. [...] I think a capability to remove LSP state while leaving forward state untouched will meet the requirements of those I've talked with. Lou >Regards, >Don From owner-ccamp@ops.ietf.org Fri Aug 25 11:57:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGe3m-00007w-5K for ccamp-archive@ietf.org; Fri, 25 Aug 2006 11:57:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGe3g-0001MQ-L2 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 11:57:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGdx7-000IAb-Ve for ccamp-data@psg.com; Fri, 25 Aug 2006 15:50:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.246.11.148] (helo=esc71.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGdx7-000IA3-4W for ccamp@ops.ietf.org; Fri, 25 Aug 2006 15:50:37 +0000 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1GGdwg-0004UF-Hu; Fri, 25 Aug 2006 11:50:10 -0400 Message-Id: <7.0.1.0.2.20060825114514.046e3658@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 11:49:26 -0400 To: "Don Fedyk" From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: "Bryskin, Igor" ,, "Dan Li" ,"Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" ,"Li, Han" In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40A3AB60A@zrtphxm2.corp.nor tel.com> References: <34B3EAA5B3066A42914D28C5ECF5FEA40A3AB60A@zrtphxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Don, At 10:40 AM 8/25/2006, Don Fedyk wrote: >I think there may be something here but I think even the requirements as >stated assume too much of the solution. What is the real issue? Per my previous e-mail: At 01:01 PM 8/24/2006, Lou Berger wrote: >At 10:48 AM 8/24/2006, Don Fedyk wrote: >>[...] >>If we were to ask could you live without the CP->MP feature what >>response would we get versus asking if CP->MP is a soft requirement. > > From the discussions I've had on this with carriers, for some it's > a don't care, for others they won't deploy control plane without > this capability. > >Lou AND At 08:15 AM 8/24/2006, Lou Berger wrote: >[...]I therefore think the definition of CP->MP *is* >required. There are multiple options for meeting this requirement, >but the solution must provide the "fallback" capability for services >existing at the time of the initial MP->CP transition and those >created after the transition. [...] I think a capability to remove LSP state while leaving forward state untouched will meet the requirements of those I've talked with. Lou >Regards, >Don From owner-ccamp@ops.ietf.org Fri Aug 25 12:29:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGeZ6-0001t0-Gb for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:29:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGeZ4-0004Fq-2a for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:29:52 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGeRI-000L6z-Kx for ccamp-data@psg.com; Fri, 25 Aug 2006 16:21:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGeRH-000L6l-Sx; Fri, 25 Aug 2006 16:21:48 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PGILPo026637; Fri, 25 Aug 2006 18:18:21 +0200 In-Reply-To: To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 18:18:13 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 18:18:19, Serialize complete at 08/25/2006 18:18:19 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 you are asking for something outside the scope of ccamp entity X wants to recuperate a CP state - just let it do - if so allowed then send a PathTear since there is no resource anymore associate to that state (but this does not require any specific documentation) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:06 To: "Lou Berger" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Agree with Lou. Can I also quote my own email? :=) "We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP." So I think we are talking about two relatively simple and very symmetrical CP functions. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, August 25, 2006 11:57 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 12:44:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGemm-0000e4-BT for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:44:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGemj-000692-TW for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:44:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGeii-000MV8-Bt for ccamp-data@psg.com; Fri, 25 Aug 2006 16:39:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGeif-000MUg-CO; Fri, 25 Aug 2006 16:39:45 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 12:39:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIYjsRcz+oOArsRyiT5jniBM/3fAAAaJVg From: "Bryskin, Igor" To: Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Approximate scenarios: a) MP->CP scenario: MP provides CP with complete ERO (including labels) CP signals SETUP with an IN-PLACE attribute, this causes provisioning = operations on each node without re-programming cross-connects MP releases resource ownership after the operation by some means b) CP->MP scenario: MP receives from CP complete RRO (including labels) MP assumes resource ownership operation by some means CP signals TEARDOWN with an IN-PLACE attribute, this causes release by = CP resources on each node without re-programming cross-connects Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 12:18 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) you are asking for something outside the scope of ccamp entity X wants to recuperate a CP state - just let it do - if so allowed then send a PathTear since there is no resource anymore associate to = that=20 state (but this does not require any specific documentation) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:06 =20 To: "Lou Berger" , Dimitri=20 PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Agree with Lou. Can I also quote my own email? :=3D) "We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to = release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how = MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP." So I think we are talking about two relatively simple and very = symmetrical=20 CP functions. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, August 25, 2006 11:57 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside = of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" = , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements = as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 12:57:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGf08-00009H-Dj for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:57:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGf08-000893-BQ for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:57:48 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGevU-0001DH-3f for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:53:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGesG-000Nh5-5J for ccamp-data@psg.com; Fri, 25 Aug 2006 16:49:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGesF-000Ngp-Ci; Fri, 25 Aug 2006 16:49:39 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PGmrWe003474; Fri, 25 Aug 2006 18:48:53 +0200 In-Reply-To: <7.0.1.0.2.20060825122626.03bf75b8@labn.net> To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , Lou Berger , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 18:48:47 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 18:48:52, Serialize complete at 08/25/2006 18:48:52 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 lou, like i replied to igor "entity X wants to recuperate a CP state - just let it do - if so allowed then send a PathTear since there is no resource anymore associate to that state (but this does not require any specific documentation)" we would deleting a path/resv state for which no resource are allocated - we did already that exercise - GR deletion. much thanks, -d. Lou Berger Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:32 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, Removing state should be a simple process of deleting local control plane state while not impacting the data plane state. Exporting, at least to me, implies a more complicated API or other information transaction processing, which is certainly not needed here. I think we're talking about a mechanism that should require a single "preserve data plane" bit in a PathTear message. Nothing more. Lou At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - isn't "remove" or "export" having the same meaning in the present >context ? > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 17:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Who said anything about exporting state? > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou - and why shall CCAMP provide a function to export states outside of > >its domain of competence > > > >thanks, > >- d. > > > > > > > > > >Lou Berger > >25/08/2006 17:49 > > > > To: "Don Fedyk" > > cc: "Bryskin, Igor" , Dimitri > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, > >Adrian" , "ccamp" , "Brungard, > >Deborah A, ALABS" , "Diego Caviglia" > >, "Drake, John E" , > >"Lou Berger" , "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > > > >Don, > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > >I think there may be something here but I think even the requirements >as > > >stated assume too much of the solution. What is the real issue? > > > >Per my previous e-mail: > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > >>[...] > > >>If we were to ask could you live without the CP->MP feature what > > >>response would we get versus asking if CP->MP is a soft requirement. > > > > > > From the discussions I've had on this with carriers, for some it's > > > a don't care, for others they won't deploy control plane without > > > this capability. > > > > > >Lou > > > >AND > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > >[...]I therefore think the definition of CP->MP *is* > > >required. There are multiple options for meeting this requirement, > > >but the solution must provide the "fallback" capability for services > > >existing at the time of the initial MP->CP transition and those > > >created after the transition. > >[...] > > > >I think a capability to remove LSP state while leaving forward state > >untouched will meet the requirements of those I've talked with. > > > >Lou > > > > >Regards, > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 13:00:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGf2i-0001hA-1U for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:00:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGdjr-0007wq-Qn for ccamp-archive@ietf.org; Fri, 25 Aug 2006 11:36:55 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGdYH-0007CA-GB for ccamp-archive@ietf.org; Fri, 25 Aug 2006 11:24:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGdUu-000FWk-6p for ccamp-data@psg.com; Fri, 25 Aug 2006 15:21:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGdUs-000FWM-Rr for ccamp@ops.ietf.org; Fri, 25 Aug 2006 15:21:26 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 11:21:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIEu+IUIQ+96hTQbqJkeo36FBC9wAN5EcAAAGuI2AAAXhSAA== From: "Bryskin, Igor" To: "Don Fedyk" , , "Dan Li" Cc: "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" , "Li, Han" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Hi Don, > My understanding of the MP->CP migration process failure and=20 > it's "back-out" requirement is as follows: >=20 > a) immediate failure of creating CP state for the services=20 > provisioned by MP. This failure does not require CP->MP feature > b) initial migration MP->CP succeeded, however, after some=20 > time (say, 1 month) of provisioning via CP (and possibly=20 > creating many services solely via CP), provider decides that=20 > CP is not good or mature enough and wants go back to=20 > old-fashioned MP provisioning. I don't see how the operator=20 > will not loose these new services without the CP->MP function. I get the feeling we are grasping here. The providers usually have a staging and evaluation phase in a test bed before deploying a new feature like a control plane. If they decide they don't want it never goes live.=20 IB>> One could argue that problems (and very serious ones) could be well = hidden and could be discovered at any time. Also running production = network is not the same as running test bed. Besides, to a large extent = it could be purely psychological issue: as Diego put it "I always need a = parachute when I try a new plane no matter how good is this plane: no = parachute - no deal" What is the difference between a MP based connection and CP based connection with a static ERO and no backup?=20 IB>> The difference is which plane owns the connection, meaning, what = tools operator uses to, say, modify or release the connection. It is not = about path computation, so whether ERO is static or not is irrelevant. I would think a better goal would be to make such a static version as good as a management plane version.=20 >=20 > With all due respect the call on CP->MP function is=20 > provider's - not yours/Alcatel, mine/Movaz or John's/ Boeing. So the providers should be writing the requirement document rather than us trying to reverse engineer the root of the problem. =20 I think there may be something here but I think even the requirements as stated assume too much of the solution. What is the real issue? IB>> The real issue (and I'd say the biggest GMPLS problem at the moment = and for some time already) is operator's nervousness deploying the GMPLS = and we need to do everything that could improve their comfort level and = confidence. Cheers, Igor Regards, Don=20 >=20 > Igor >=20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Friday, August 25, 2006 2:51 AM > To: Dan Li > Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego=20 > Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou=20 > Berger; Li, Han > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 >=20 > hi - here below a couple of comments >=20 > o) the first point and i think i mention this already is that=20 > at the end speaking about MP in the present context restricts=20 > applicability of the "migration", the purpose of this draft=20 > is to create a control plane state when the same resources=20 > are already in use by an entity external to the control plane=20 > - call this an "import" function >=20 > o) the second when you write "Our main requirement for CP->MP=20 > migration is to handle "back-out" of the MP->CP migration=20 > process." is on itself confusing; what are you dealing with ?=20 > that the transition fails during its instantiation or that=20 > once LSP has a control plane state you want to move back=20 > where it used to belong - the former is a real issue that has=20 > never been discussed - the second is a non-issue (the other=20 > entity takes care to rapatriate the state in case, i don't=20 > think there is any need for an "export" function simple=20 > because we are not going to tell to which entity the LSP=20 > shall be brought back as we can have many of those) >=20 > o) the third point is when you mention "Modifying and tearing=20 > down LSPs after control plane failure" i pointed already that=20 > a migration from CP to somewhere else is impossible if you=20 > don't get access to the CP iself in particular if it is under=20 > failure - doesn't seem to be understood by authors (yet) >=20 > thanks, > - d. >=20 >=20 From owner-ccamp@ops.ietf.org Fri Aug 25 13:06:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGf85-0005Xq-Af for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:06:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGf81-00014G-QJ for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:06:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGezu-000OXN-Jd for ccamp-data@psg.com; Fri, 25 Aug 2006 16:57:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.246.11.148] (helo=esc71.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGezt-000OX8-PT; Fri, 25 Aug 2006 16:57:33 +0000 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1GGeze-0006vg-4d; Fri, 25 Aug 2006 12:57:18 -0400 Message-Id: <7.0.1.0.2.20060825125519.0331b1e0@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 12:57:23 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" ,owner-ccamp@ops.ietf.org In-Reply-To: References: <7.0.1.0.2.20060825122626.03bf75b8@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Dimitri, huh, why would there be no resources, i.e., data plane state, associated with the LSP? If this were the case, I agree the whole discussion would be moot. Lou At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou, > >like i replied to igor > >"entity X wants to recuperate a CP state - just let it do - if so allowed > >then send a PathTear since there is no resource anymore associate to that >state (but this does not require any specific documentation)" > >we would deleting a path/resv state for which no resource are allocated - >we did already that exercise - GR deletion. > >much thanks, >-d. > > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 18:32 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > Removing state should be a simple process of deleting local >control plane state while not impacting the data plane >state. Exporting, at least to me, implies a more complicated API or >other information transaction processing, which is certainly not needed >here. > >I think we're talking about a mechanism that should require a single >"preserve data plane" bit in a PathTear message. Nothing more. > >Lou > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou - isn't "remove" or "export" having the same meaning in the present > >context ? > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 17:57 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Who said anything about exporting state? > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - and why shall CCAMP provide a function to export states outside >of > > >its domain of competence > > > > > >thanks, > > >- d. > > > > > > > > > > > > > > >Lou Berger > > >25/08/2006 17:49 > > > > > > To: "Don Fedyk" > > > cc: "Bryskin, Igor" , Dimitri > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, > > >Adrian" , "ccamp" , "Brungard, > > >Deborah A, ALABS" , "Diego Caviglia" > > >, "Drake, John E" >, > > >"Lou Berger" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > > > > >Don, > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > >I think there may be something here but I think even the requirements > >as > > > >stated assume too much of the solution. What is the real issue? > > > > > >Per my previous e-mail: > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > >>[...] > > > >>If we were to ask could you live without the CP->MP feature what > > > >>response would we get versus asking if CP->MP is a soft requirement. > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > a don't care, for others they won't deploy control plane without > > > > this capability. > > > > > > > >Lou > > > > > >AND > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > >[...]I therefore think the definition of CP->MP *is* > > > >required. There are multiple options for meeting this requirement, > > > >but the solution must provide the "fallback" capability for services > > > >existing at the time of the initial MP->CP transition and those > > > >created after the transition. > > >[...] > > > > > >I think a capability to remove LSP state while leaving forward state > > >untouched will meet the requirements of those I've talked with. > > > > > >Lou > > > > > > >Regards, > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 13:13:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfFn-0001ZM-Hz for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:13:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGeFl-0002iy-Oy for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:09:53 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGe6h-0008Py-BH for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:00:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGe3i-000Iqg-46 for ccamp-data@psg.com; Fri, 25 Aug 2006 15:57:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.246.11.148] (helo=esc71.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGe3h-000IqS-Gc for ccamp@ops.ietf.org; Fri, 25 Aug 2006 15:57:25 +0000 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1GGe3M-0007Ql-5u; Fri, 25 Aug 2006 11:57:04 -0400 Message-Id: <7.0.1.0.2.20060825115636.04eeaea0@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 11:57:08 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" In-Reply-To: References: <7.0.1.0.2.20060825114514.046e3658@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 13:44:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfev-0006SH-9z for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:39:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGfUM-0005Oy-1f for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:29:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGfRX-0001Cy-P0 for ccamp-data@psg.com; Fri, 25 Aug 2006 17:26:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.246.11.148] (helo=esc71.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGfRW-0001Ck-R8; Fri, 25 Aug 2006 17:26:07 +0000 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1GGfRE-0005Jh-7T; Fri, 25 Aug 2006 13:25:48 -0400 Message-Id: <7.0.1.0.2.20060825132455.04fcb008@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 13:25:41 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" ,owner-ccamp@ops.ietf.org In-Reply-To: References: <7.0.1.0.2.20060825125519.0331b1e0@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 13:44:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfjI-0008BD-Vv for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:44:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGfjH-0007a4-GR for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:44:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGffX-0002Uc-RQ for ccamp-data@psg.com; Fri, 25 Aug 2006 17:40:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGffW-0002UJ-Qd; Fri, 25 Aug 2006 17:40:35 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PHYofq014472; Fri, 25 Aug 2006 19:34:50 +0200 In-Reply-To: <7.0.1.0.2.20060825132455.04fcb008@labn.net> To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , Lou Berger , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 19:34:43 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 19:34:49, Serialize complete at 08/25/2006 19:34:49 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 lou - i mean that in case an LSP for whatever reason needs to be moved from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful deletion bit set in admin_status, then on each node the resource is associated to that entity (which is not a CP business) and then the control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 13:50:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfon-0003f6-Or for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:50:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGfG5-0002d2-B7 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:14:17 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGfA5-0001Sl-8M for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:08:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGf6T-000P4M-Fk for ccamp-data@psg.com; Fri, 25 Aug 2006 17:04:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGf6S-000P41-Gp; Fri, 25 Aug 2006 17:04:20 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PH3eAr007907; Fri, 25 Aug 2006 19:03:40 +0200 In-Reply-To: <7.0.1.0.2.20060825125519.0331b1e0@labn.net> To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , Lou Berger , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 19:03:32 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 19:03:38, Serialize complete at 08/25/2006 19:03:38 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc lou resource are present (data plane state remains) the operation we're discussing about is local and consist in associating that resource to another entity - you GR the path because you don't want to generate errors - but then that's it you just have to retrieve the CP state - d. Lou Berger 25/08/2006 18:57 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, huh, why would there be no resources, i.e., data plane state, associated with the LSP? If this were the case, I agree the whole discussion would be moot. Lou At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou, > >like i replied to igor > >"entity X wants to recuperate a CP state - just let it do - if so allowed > >then send a PathTear since there is no resource anymore associate to that >state (but this does not require any specific documentation)" > >we would deleting a path/resv state for which no resource are allocated - >we did already that exercise - GR deletion. > >much thanks, >-d. > > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 18:32 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > Removing state should be a simple process of deleting local >control plane state while not impacting the data plane >state. Exporting, at least to me, implies a more complicated API or >other information transaction processing, which is certainly not needed >here. > >I think we're talking about a mechanism that should require a single >"preserve data plane" bit in a PathTear message. Nothing more. > >Lou > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou - isn't "remove" or "export" having the same meaning in the present > >context ? > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 17:57 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Who said anything about exporting state? > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - and why shall CCAMP provide a function to export states outside >of > > >its domain of competence > > > > > >thanks, > > >- d. > > > > > > > > > > > > > > >Lou Berger > > >25/08/2006 17:49 > > > > > > To: "Don Fedyk" > > > cc: "Bryskin, Igor" , Dimitri > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, > > >Adrian" , "ccamp" , "Brungard, > > >Deborah A, ALABS" , "Diego Caviglia" > > >, "Drake, John E" >, > > >"Lou Berger" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > > > > >Don, > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > >I think there may be something here but I think even the requirements > >as > > > >stated assume too much of the solution. What is the real issue? > > > > > >Per my previous e-mail: > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > >>[...] > > > >>If we were to ask could you live without the CP->MP feature what > > > >>response would we get versus asking if CP->MP is a soft requirement. > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > a don't care, for others they won't deploy control plane without > > > > this capability. > > > > > > > >Lou > > > > > >AND > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > >[...]I therefore think the definition of CP->MP *is* > > > >required. There are multiple options for meeting this requirement, > > > >but the solution must provide the "fallback" capability for services > > > >existing at the time of the initial MP->CP transition and those > > > >created after the transition. > > >[...] > > > > > >I think a capability to remove LSP state while leaving forward state > > >untouched will meet the requirements of those I've talked with. > > > > > >Lou > > > > > > >Regards, > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 13:51:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfqG-0004Zq-Dr for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:51:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGekh-0005gM-9w for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:41:51 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGeeU-0000dx-BU for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:35:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGebU-000Lsl-G7 for ccamp-data@psg.com; Fri, 25 Aug 2006 16:32:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.246.11.148] (helo=esc71.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGebT-000LsV-NE; Fri, 25 Aug 2006 16:32:19 +0000 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1GGebE-0002xT-7n; Fri, 25 Aug 2006 12:32:04 -0400 Message-Id: <7.0.1.0.2.20060825122626.03bf75b8@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 12:32:06 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" ,owner-ccamp@ops.ietf.org In-Reply-To: References: <7.0.1.0.2.20060825115636.04eeaea0@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Dimitri, Removing state should be a simple process of deleting local control plane state while not impacting the data plane state. Exporting, at least to me, implies a more complicated API or other information transaction processing, which is certainly not needed here. I think we're talking about a mechanism that should require a single "preserve data plane" bit in a PathTear message. Nothing more. Lou At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - isn't "remove" or "export" having the same meaning in the present >context ? > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 17:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Who said anything about exporting state? > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou - and why shall CCAMP provide a function to export states outside of > >its domain of competence > > > >thanks, > >- d. > > > > > > > > > >Lou Berger > >25/08/2006 17:49 > > > > To: "Don Fedyk" > > cc: "Bryskin, Igor" , Dimitri > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, > >Adrian" , "ccamp" , "Brungard, > >Deborah A, ALABS" , "Diego Caviglia" > >, "Drake, John E" , > >"Lou Berger" , "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > > > >Don, > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > >I think there may be something here but I think even the requirements >as > > >stated assume too much of the solution. What is the real issue? > > > >Per my previous e-mail: > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > >>[...] > > >>If we were to ask could you live without the CP->MP feature what > > >>response would we get versus asking if CP->MP is a soft requirement. > > > > > > From the discussions I've had on this with carriers, for some it's > > > a don't care, for others they won't deploy control plane without > > > this capability. > > > > > >Lou > > > >AND > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > >[...]I therefore think the definition of CP->MP *is* > > >required. There are multiple options for meeting this requirement, > > >but the solution must provide the "fallback" capability for services > > >existing at the time of the initial MP->CP transition and those > > >created after the transition. > >[...] > > > >I think a capability to remove LSP state while leaving forward state > >untouched will meet the requirements of those I've talked with. > > > >Lou > > > > >Regards, > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 14:10:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGg81-0005eo-3U for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:10:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGel2-0005gM-WE for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:42:13 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGeMD-0000Ky-LG for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:16:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGeCh-000Jjr-45 for ccamp-data@psg.com; Fri, 25 Aug 2006 16:06:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGeCg-000Jjf-CQ for ccamp@ops.ietf.org; Fri, 25 Aug 2006 16:06:42 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 12:06:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIXzEgiOx/bjfcRUm1ZWU6eueqtgAALTag From: "Bryskin, Igor" To: "Lou Berger" , Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Li, Han" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Agree with Lou. Can I also quote my own email? :=3D) "We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to = release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how = MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP." So I think we are talking about two relatively simple and very = symmetrical CP functions. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, August 25, 2006 11:57 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside = of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" = , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements = as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 14:20:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgHr-0008Te-UG for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:20:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGeky-0005gM-6L for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:42:08 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGeQ7-0000PA-7P for ccamp-archive@ietf.org; Fri, 25 Aug 2006 12:20:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGeLk-000KW9-MA for ccamp-data@psg.com; Fri, 25 Aug 2006 16:16:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGeLj-000KVo-Vo; Fri, 25 Aug 2006 16:16:04 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PGEBGM024252; Fri, 25 Aug 2006 18:14:11 +0200 In-Reply-To: <7.0.1.0.2.20060825115636.04eeaea0@labn.net> To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , Lou Berger , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 18:14:04 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 18:14:10, Serialize complete at 08/25/2006 18:14:10 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 lou - isn't "remove" or "export" having the same meaning in the present context ? Lou Berger Sent by: owner-ccamp@ops.ietf.org 25/08/2006 17:57 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 14:23:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgL1-0001uc-Ab for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:23:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgL1-0007ZW-8u for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:23:27 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGg5M-0002un-1V for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:07:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGg1N-0004pj-To for ccamp-data@psg.com; Fri, 25 Aug 2006 18:03:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGg1M-0004pQ-Op; Fri, 25 Aug 2006 18:03:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 14:02:59 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIbYkdWY7SUqeAQiOvYqw7Gz4sfAAAnAog From: "Bryskin, Igor" To: , "Lou Berger" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in = Path and Modify messages and is meant for disabling alarms before you = starting LSP teardown. What we are talking about is nothing but a bit in PathTear message = instructing resource manager on each node not to break cross-connects = while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved=20 from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful=20 deletion bit set in admin_status, then on each node the resource is=20 associated to that entity (which is not a CP business) and then the=20 control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian"=20 , "ccamp" , "Dan Li"=20 , "Brungard, Deborah A, ALABS" ,=20 "Diego Caviglia" , "Don Fedyk"=20 , "Bryskin, Igor" , "Drake, John = E" , "Li, Han" ,=20 owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, I really don't understand your point. Can you = restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate=20 errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, = John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so=20 allowed > > > >then send a PathTear since there is no resource anymore associate to=20 that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are = allocated=20 - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake,=20 John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not = needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the=20 present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" = , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states=20 outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" = > > > > Subject: RE: CP-->MP Issue (was RE: Polling for = new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature = what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some=20 it's > > > > > a don't care, for others they won't deploy control plane = without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this=20 requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward=20 state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 14:28:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgQC-0006DM-TF for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:28:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGfG5-0002d2-Sm for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:14:17 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGf77-0001Ph-2H for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:05:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGf4A-000Orf-89 for ccamp-data@psg.com; Fri, 25 Aug 2006 17:01:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGf49-000OrQ-8D; Fri, 25 Aug 2006 17:01:57 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PH1Lbe006591; Fri, 25 Aug 2006 19:01:21 +0200 In-Reply-To: To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 19:01:14 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 19:01:19, Serialize complete at 08/25/2006 19:01:19 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 i totally disagree you constantly referring to the MP while CCAMP has NEVER linked control operations to MP operations - these MP operations assumptions are outside scope of CCAMP in part. we are going to enter into a discussion for which we won't get the bird out of the bush: addressing space between CP and MP it took us more or less 4 years to disambiguate the DP address space relationship with the CP and there is no reason to start an endless debate now with the MP -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:39 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Approximate scenarios: a) MP->CP scenario: MP provides CP with complete ERO (including labels) CP signals SETUP with an IN-PLACE attribute, this causes provisioning operations on each node without re-programming cross-connects MP releases resource ownership after the operation by some means b) CP->MP scenario: MP receives from CP complete RRO (including labels) MP assumes resource ownership operation by some means CP signals TEARDOWN with an IN-PLACE attribute, this causes release by CP resources on each node without re-programming cross-connects Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 12:18 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) you are asking for something outside the scope of ccamp entity X wants to recuperate a CP state - just let it do - if so allowed then send a PathTear since there is no resource anymore associate to that state (but this does not require any specific documentation) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:06 To: "Lou Berger" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Agree with Lou. Can I also quote my own email? :=) "We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP." So I think we are talking about two relatively simple and very symmetrical CP functions. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, August 25, 2006 11:57 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 14:34:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgVN-0008Ji-9f for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:34:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgVK-0000wT-N3 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:34:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgRU-00077T-Rs for ccamp-data@psg.com; Fri, 25 Aug 2006 18:30:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgRT-00076z-PG; Fri, 25 Aug 2006 18:30:08 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PITJ8v026589; Fri, 25 Aug 2006 20:29:19 +0200 In-Reply-To: To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 20:29:11 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 20:29:18, Serialize complete at 08/25/2006 20:29:18 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 igor but you don't need more than what's in RFC 3473 than disabling alarms during the move of the resource associated to the CP to another enitity and the send a pathtear to remove the control plane state (you don't need to involve the CP in moving the data plane resource on each node) -d. "Bryskin, Igor" 25/08/2006 20:02 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in Path and Modify messages and is meant for disabling alarms before you starting LSP teardown. What we are talking about is nothing but a bit in PathTear message instructing resource manager on each node not to break cross-connects while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful deletion bit set in admin_status, then on each node the resource is associated to that entity (which is not a CP business) and then the control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 14:40:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgbV-0001yS-Lr for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:40:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgbU-000217-2H for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:40:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgYj-0007vU-EX for ccamp-data@psg.com; Fri, 25 Aug 2006 18:37:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgYi-0007v6-5X; Fri, 25 Aug 2006 18:37:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 14:37:34 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIdHhzG6CMahZuSbivfVroZeq0gQAAGHUg From: "Bryskin, Igor" To: Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We = do graceful shutdown normally. We need another bit for this exceptional = release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor=20 but you don't need more than what's in RFC 3473 than disabling alarms=20 during the move of the resource associated to the CP to another enitity=20 and the send a pathtear to remove the control plane state (you don't = need=20 to involve the CP in moving the data plane resource on each node) -d. =20 "Bryskin, Igor" 25/08/2006 20:02 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger"=20 cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in = Path and Modify messages and is meant for disabling alarms before you=20 starting LSP teardown. What we are talking about is nothing but a bit in PathTear message=20 instructing resource manager on each node not to break cross-connects=20 while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved=20 from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful=20 deletion bit set in admin_status, then on each node the resource is=20 associated to that entity (which is not a CP business) and then the=20 control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian"=20 , "ccamp" , "Dan Li"=20 , "Brungard, Deborah A, ALABS" ,=20 "Diego Caviglia" , "Don Fedyk"=20 , "Bryskin, Igor" , "Drake, John = E" , "Li, Han" ,=20 owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, I really don't understand your point. Can you = restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate=20 errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, = John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so=20 allowed > > > >then send a PathTear since there is no resource anymore associate to=20 that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are = allocated=20 - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake,=20 John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not = needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the=20 present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" = , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states=20 outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" = > > > > Subject: RE: CP-->MP Issue (was RE: Polling for = new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature = what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some=20 it's > > > > > a don't care, for others they won't deploy control plane = without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this=20 requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward=20 state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 14:51:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgmH-0007zw-AS for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:51:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgmF-0004Lj-I5 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:51:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGghu-0008iP-Ri for ccamp-data@psg.com; Fri, 25 Aug 2006 18:47:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGght-0008i2-IT; Fri, 25 Aug 2006 18:47:06 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PIkK91030162; Fri, 25 Aug 2006 20:46:20 +0200 In-Reply-To: To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 20:46:13 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 20:46:19, Serialize complete at 08/25/2006 20:46:19 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b igor - but it is exactly what happens the resource reservation disappears from the control plane viewpoint (after which a pathtear is sent to remove the control plane state) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 20:37 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We do graceful shutdown normally. We need another bit for this exceptional release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor but you don't need more than what's in RFC 3473 than disabling alarms during the move of the resource associated to the CP to another enitity and the send a pathtear to remove the control plane state (you don't need to involve the CP in moving the data plane resource on each node) -d. "Bryskin, Igor" 25/08/2006 20:02 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in Path and Modify messages and is meant for disabling alarms before you starting LSP teardown. What we are talking about is nothing but a bit in PathTear message instructing resource manager on each node not to break cross-connects while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful deletion bit set in admin_status, then on each node the resource is associated to that entity (which is not a CP business) and then the control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 14:53:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgnk-000854-Om for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:53:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgL3-0007ZW-S2 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:23:29 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGfy3-0002m2-8u for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:59:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGfsR-0003sz-VR for ccamp-data@psg.com; Fri, 25 Aug 2006 17:53:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGfsP-0003sh-HD; Fri, 25 Aug 2006 17:53:55 +0000 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2006 13:53:53 -0400 X-IronPort-AV: i="4.08,169,1154923200"; d="scan'208"; a="98805775:sNHT39688856" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PHrqWI028499; Fri, 25 Aug 2006 13:53:52 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7PHrkuQ000615; Fri, 25 Aug 2006 13:53:50 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 13:53:49 -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 Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Fri, 25 Aug 2006 13:53:48 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIaD2eROz0I1iPSaqoZMHZXnKQlwABv0JQ From: "Zafar Ali \(zali\)" To: , "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , X-OriginalArrivalTime: 25 Aug 2006 17:53:49.0673 (UTC) FILETIME=[6B7A2590:01C6C86F] DKIM-Signature: a=rsa-sha1; q=dns; l=7461; t=1156528432; x=1157392432; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20 |Subject:RE=3A=20CP-->MP=20Issue=20(was=20RE=3A=20Polling=20for=20new=20WG=20I-Ds ) |To:,=20=22Bryskin,=20Igor=22=20; X=v=3Dcisco.com=3B=20h=3Dz6UyJTvl3VVlsfvqhIIjqjqqZdk=3D; b=ZWQgOtbuyHTmATj3zl2DjGcQhGNtoHwANb2p9cgJLuUmEasC1w/1halwoq29QJggO2ZaZjnD JdzvLqw+xD7r1gG1Z3ySspajR2/XL67LFyK1o7m6cXS6P9S6zipmpdtI; Authentication-Results: rtp-dkim-2.cisco.com; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > Dimitri.Papadimitriou@alcatel.be > Sent: Friday, August 25, 2006 1:01 PM > To: Bryskin, Igor > Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,=20 > ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger;=20 > Li, Han; owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 > i totally disagree you constantly referring to the MP while=20 > CCAMP has NEVER linked control operations to MP operations -=20 > these MP operations assumptions are outside scope of CCAMP=20 >=20 I agree with Dimitri. Also Don mentioned a good point that there is no standard MP. I am not sure why we should pursue this any further.=20 Thanks Regards.. Zafar=20 > in part. we are going to enter into a discussion for which we=20 > won't get the bird out of the bush: addressing space between=20 > CP and MP it took us more or less 4 years to disambiguate the=20 > DP address space relationship with the CP and there is no=20 > reason to start an endless debate now with the MP >=20 > -d. >=20 > =20 >=20 >=20 >=20 >=20 >=20 > "Bryskin, Igor" > Sent by: owner-ccamp@ops.ietf.org > 25/08/2006 18:39 > =20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Farrel, Adrian" , "ccamp"=20 > , "Dan Li" , "Brungard,=20 > Deborah A, ALABS" , "Diego Caviglia"=20 > , "Don Fedyk"=20 > , "Drake, John E"=20 > , "Lou Berger" ,=20 > "Li, Han"=20 > , > Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 > I-Ds) >=20 >=20 >=20 > Approximate scenarios: >=20 > a) MP->CP scenario: >=20 > MP provides CP with complete ERO (including labels) CP=20 > signals SETUP with an IN-PLACE attribute, this causes=20 > provisioning operations on each node without re-programming=20 > cross-connects MP releases resource ownership after the=20 > operation by some means >=20 > b) CP->MP scenario: >=20 > MP receives from CP complete RRO (including labels) MP=20 > assumes resource ownership operation by some means CP signals=20 > TEARDOWN with an IN-PLACE attribute, this causes release by=20 > CP resources on each node without re-programming cross-connects >=20 > Igor >=20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Friday, August 25, 2006 12:18 PM > To: Bryskin, Igor > Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,=20 > ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger;=20 > Li, Han; owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 >=20 > you are asking for something outside the scope of ccamp >=20 > entity X wants to recuperate a CP state - just let it do - if=20 > so allowed >=20 > then send a PathTear since there is no resource anymore=20 > associate to that state (but this does not require any=20 > specific documentation) >=20 > -d. >=20 >=20 >=20 >=20 >=20 > "Bryskin, Igor" > Sent by: owner-ccamp@ops.ietf.org > 25/08/2006 18:06 > =20 > To: "Lou Berger" , Dimitri=20 > PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Farrel, Adrian" , "ccamp"=20 > , "Dan Li" , "Brungard,=20 > Deborah A, ALABS" , "Diego Caviglia"=20 > ,=20 >=20 > "Don Fedyk" , "Drake, John E"=20 > , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 > I-Ds) >=20 >=20 > Agree with Lou. >=20 > Can I also quote my own email? :=3D) >=20 > "We are > talking here about a capability of CP to acquire network=20 > resources and build CP state for an LSP without actually=20 > re-programming crossconnects (case MP->CP). Likewise, we are=20 > talking about capability of CP to release resources and=20 > destroy CP state for an LSP without re-programming=20 > crossconnects (case CP->MP). It is out of scope of those=20 > mechanisms how MP (or any other plane) assumes or yields the=20 > ownership of resources of the LSP whose ownership is=20 > transferred from/to CP." >=20 > So I think we are talking about two relatively simple and=20 > very symmetrical=20 >=20 > CP functions. >=20 > Igor >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 25, 2006 11:57 AM > To: Dimitri.Papadimitriou@alcatel.be > Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard,=20 > Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor;=20 > Drake, John E; Li, Han > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 >=20 > Who said anything about exporting state? >=20 > At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > >lou - and why shall CCAMP provide a function to export=20 > states outside=20 > >of its domain of competence > > > >thanks, > >- d. > > > > > > > > > >Lou Berger > >25/08/2006 17:49 > > > > To: "Don Fedyk" > > cc: "Bryskin, Igor" , Dimitri > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li"=20 > , "Farrel,=20 > >Adrian" , "ccamp" ,=20 > "Brungard,=20 > >Deborah A, ALABS" , "Diego Caviglia" > >, "Drake, John E"=20 > >, "Lou Berger" ,=20 > "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling=20 > for new WG > >I-Ds) > > > > > > > >Don, > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > >I think there may be something here but I think even the=20 > requirements > as > > >stated assume too much of the solution. What is the real issue? > > > >Per my previous e-mail: > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > >>[...] > > >>If we were to ask could you live without the CP->MP feature what=20 > > >>response would we get versus asking if CP->MP is a soft=20 > requirement. > > > > > > From the discussions I've had on this with carriers, for=20 > some it's a=20 > > > don't care, for others they won't deploy control plane=20 > without this=20 > > > capability. > > > > > >Lou > > > >AND > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > >[...]I therefore think the definition of CP->MP *is*=20 > required. There=20 > > >are multiple options for meeting this requirement, but the=20 > solution=20 > > >must provide the "fallback" capability for services=20 > existing at the=20 > > >time of the initial MP->CP transition and those created after the=20 > > >transition. > >[...] > > > >I think a capability to remove LSP state while leaving forward state=20 > >untouched will meet the requirements of those I've talked with. > > > >Lou > > > > >Regards, > > >Don >=20 >=20 >=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Aug 25 14:54:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgpP-0008Gx-3p for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:54:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgpO-0004l2-Fi for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:54:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgmn-0009EG-CU for ccamp-data@psg.com; Fri, 25 Aug 2006 18:52:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgmm-0009Dy-2b; Fri, 25 Aug 2006 18:52:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 14:52:07 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIdtYcBaYBrR92TrCbBdoAqkz2HwAACfGw From: "Bryskin, Igor" To: Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Dimitri, No, it is not. D-bit was designed for a normal release. In normal = release CP is responsible for breaking cross-connects (for example to = avoid mis-connections during subsequent setups). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:46 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor - but it is exactly what happens the resource reservation = disappears=20 from the control plane viewpoint (after which a pathtear is sent to = remove=20 the control plane state) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 20:37 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We = do=20 graceful shutdown normally. We need another bit for this exceptional=20 release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor=20 but you don't need more than what's in RFC 3473 than disabling alarms=20 during the move of the resource associated to the CP to another enitity=20 and the send a pathtear to remove the control plane state (you don't = need=20 to involve the CP in moving the data plane resource on each node) -d. =20 "Bryskin, Igor" 25/08/2006 20:02 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger"=20 cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in = Path and Modify messages and is meant for disabling alarms before you=20 starting LSP teardown. What we are talking about is nothing but a bit in PathTear message=20 instructing resource manager on each node not to break cross-connects=20 while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved=20 from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful=20 deletion bit set in admin_status, then on each node the resource is=20 associated to that entity (which is not a CP business) and then the=20 control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian"=20 , "ccamp" , "Dan Li"=20 , "Brungard, Deborah A, ALABS" ,=20 "Diego Caviglia" , "Don Fedyk"=20 , "Bryskin, Igor" , "Drake, John = E" , "Li, Han" ,=20 owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, I really don't understand your point. Can you = restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate=20 errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, = John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so=20 allowed > > > >then send a PathTear since there is no resource anymore associate to=20 that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are = allocated=20 - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake,=20 John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not = needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the=20 present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" = , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states=20 outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" = > > > > Subject: RE: CP-->MP Issue (was RE: Polling for = new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature = what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some=20 it's > > > > > a don't care, for others they won't deploy control plane = without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this=20 requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward=20 state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 15:01:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgw1-00043Y-TR for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:01:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgvy-0005Pa-BE for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:01:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgsL-0009wf-4Z for ccamp-data@psg.com; Fri, 25 Aug 2006 18:57:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.246.11.148] (helo=esc71.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgsJ-0009wM-Jh; Fri, 25 Aug 2006 18:57:51 +0000 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1GGgs1-0003CR-Qx; Fri, 25 Aug 2006 14:57:34 -0400 Message-Id: <7.0.1.0.2.20060825145610.040bae68@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 14:57:37 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" ,owner-ccamp@ops.ietf.org In-Reply-To: References: <7.0.1.0.2.20060825132455.04fcb008@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Dimitri, I agree that all is needed is a single bit. Unfortunately, the bits you mention are used for other purposes. (i.e., alarm free LSP deletion.) Lou At 01:34 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - i mean that in case an LSP for whatever reason needs to be moved >from the control plane to another place > >this is already covered in RFC 3473 - the LSP is signaled with graceful >deletion bit set in admin_status, then on each node the resource is >associated to that entity (which is not a CP business) and then the >control plane state is removed > >hope this clarifies, >-d. > > > > >Lou Berger >25/08/2006 19:25 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > I really don't understand your point. Can you restate/rephrase? > >Lou > >At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou > > > >resource are present (data plane state remains) the operation we're > >discussing about is local and consist in associating that resource to > >another entity - you GR the path because you don't want to generate >errors > >- but then that's it you just have to retrieve the CP state > > > >- d. > > > > > > > > > >Lou Berger > >25/08/2006 18:57 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > > >huh, why would there be no resources, i.e., data plane state, > >associated with the LSP? If this were the case, I agree the whole > >discussion would be moot. > > > >Lou > > > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou, > > > > > >like i replied to igor > > > > > >"entity X wants to recuperate a CP state - just let it do - if so >allowed > > > > > >then send a PathTear since there is no resource anymore associate to >that > > >state (but this does not require any specific documentation)" > > > > > >we would deleting a path/resv state for which no resource are allocated >- > > >we did already that exercise - GR deletion. > > > > > >much thanks, > > >-d. > > > > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 18:32 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" , > > >owner-ccamp@ops.ietf.org > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Dimitri, > > > Removing state should be a simple process of deleting local > > >control plane state while not impacting the data plane > > >state. Exporting, at least to me, implies a more complicated API or > > >other information transaction processing, which is certainly not needed > > >here. > > > > > >I think we're talking about a mechanism that should require a single > > >"preserve data plane" bit in a PathTear message. Nothing more. > > > > > >Lou > > > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - isn't "remove" or "export" having the same meaning in the >present > > > >context ? > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >Sent by: owner-ccamp@ops.ietf.org > > > >25/08/2006 17:57 > > > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > > cc: Lou Berger , "Farrel, Adrian" > > > >, "ccamp" , "Dan Li" > > > >, "Brungard, Deborah A, ALABS" , > > > >"Diego Caviglia" , "Don Fedyk" > > > >, "Bryskin, Igor" , "Drake, > >John > > > >E" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > >Who said anything about exporting state? > > > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > > > >lou - and why shall CCAMP provide a function to export states >outside > > >of > > > > >its domain of competence > > > > > > > > > >thanks, > > > > >- d. > > > > > > > > > > > > > > > > > > > > > > > > >Lou Berger > > > > >25/08/2006 17:49 > > > > > > > > > > To: "Don Fedyk" > > > > > cc: "Bryskin, Igor" , Dimitri > > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , > >"Farrel, > > > > >Adrian" , "ccamp" , > >"Brungard, > > > > >Deborah A, ALABS" , "Diego Caviglia" > > > > >, "Drake, John E" > > >, > > > > >"Lou Berger" , "Li, Han" > > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new > >WG > > > > >I-Ds) > > > > > > > > > > > > > > > > > > > >Don, > > > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > > >I think there may be something here but I think even the > >requirements > > > >as > > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > > > >Per my previous e-mail: > > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > > >>[...] > > > > > >>If we were to ask could you live without the CP->MP feature what > > > > > >>response would we get versus asking if CP->MP is a soft > >requirement. > > > > > > > > > > > > From the discussions I've had on this with carriers, for some >it's > > > > > > a don't care, for others they won't deploy control plane without > > > > > > this capability. > > > > > > > > > > > >Lou > > > > > > > > > >AND > > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > > >[...]I therefore think the definition of CP->MP *is* > > > > > >required. There are multiple options for meeting this >requirement, > > > > > >but the solution must provide the "fallback" capability for > >services > > > > > >existing at the time of the initial MP->CP transition and those > > > > > >created after the transition. > > > > >[...] > > > > > > > > > >I think a capability to remove LSP state while leaving forward >state > > > > >untouched will meet the requirements of those I've talked with. > > > > > > > > > >Lou > > > > > > > > > > >Regards, > > > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 15:05:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgze-0005p8-PM for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:05:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgzd-00062Z-DC for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:05:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgx0-000APY-O8 for ccamp-data@psg.com; Fri, 25 Aug 2006 19:02:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.246.11.148] (helo=esc71.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgwz-000APK-Vu; Fri, 25 Aug 2006 19:02:42 +0000 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1GGgwk-0006eR-TN; Fri, 25 Aug 2006 15:02:27 -0400 Message-Id: <7.0.1.0.2.20060825145814.041b1e60@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 15:02:30 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue - non-issue Cc: "Ong, Lyndon" ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Lou Berger" ,"Li, Han" , owner-ccamp@ops.ietf.org In-Reply-To: References: <0901D1988E815341A0103206A834DA07F9B658@mdmxm02.ciena.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Dimitri, not sure about past discussions, but you're characterization of (at least) my position is just plain wrong. I don't think this has anything to do with "unreliable control plane operations". As I said before, the requirement for this comes from the need to have a symmetric operation to gain acceptance by some carriers. From your previous mail, it sounds like you think this capability already exists. Given this, what's your objection here? Lou At 01:47 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >i agree on this CCAMP has/is building a self-consistent set of mechanisms >(from the start CCAMP considered that the MP has not being fallback >whatsover of the CP operations and in particular not linking any of its >operations to a particular MP) > >all what i am hearing from igor and co. is just penalizing the work of >this group achieved since 6 years without technical justification *** >there is no need for MP intervention in order to obtain CP operations >resiliency/reliability *** second time we have such discussion (look back >on the archive around end-october 2005, nov.2005 you will see there that >the same people already pushed forward the idea of unreliable control >plane operations - if someone's implementation is unstable/unreliable it >is not up to CCAMP to solve such issue and certainly not by interfering >with the MP) > >ps: add also add CP GR restart (from intermediate and source node) > >-d. > > > > >"Ong, Lyndon" >25/08/2006 19:22 > > To: "Brungard, Deborah A, ALABS" , "Farrel, >Adrian" > cc: "ccamp" , "Dan Li" , >"Diego Caviglia" , "Don Fedyk" >, "Drake, John E" , "Lou >Berger" , "Li, Han" , >, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, >"Bryskin, Igor" > Subject: RE: CP-->MP Issue - non-issue > > >Hi Folks, > >Just a bit worried that this discussion may be causing the impression >that >control plane is somehow unstable and requires some kind of special >backup! > >Deborah and other carrier representatives can attest that control plane >(although not necessarily standard GMPLS) has been deployed and in >operation >in a number of carrier networks for some years without experiencing any >major failures. There are already methods in use for ensuring the >reliability >of the control plane such as redundant control processors, non-volatile >storage of control plane data, software verification and testing, etc. > >I don't believe it was the intention of GMPLS work to require some kind >of >fallback to central management system control, hopefully everyone agrees >on this! > >Cheers, > >Lyndon From owner-ccamp@ops.ietf.org Fri Aug 25 15:09:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGh3F-0007ff-3P for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:09:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGh3D-0006Le-Ec for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:09:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgzT-000Acs-HR for ccamp-data@psg.com; Fri, 25 Aug 2006 19:05:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGgzS-000AcP-68; Fri, 25 Aug 2006 19:05:14 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PJ3pjB002188; Fri, 25 Aug 2006 21:03:51 +0200 In-Reply-To: To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 21:03:44 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 21:03:50, Serialize complete at 08/25/2006 21:03:50 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 igor you are hanging on "breaking cross-connection" ... what i am telling to you is that there is no action required from the CP viewpoint beside preventing any error/alarm and removing the control plane state (for a data plane state that doesn't exist anymore from the CP perspective) there is no difference from the presence or absence of cross-connection ... otherwise we would have already a PathTear error of some kind. you have in mind to involve the CP signaling in this move - which is totally beyond scope - -d. "Bryskin, Igor" 25/08/2006 20:52 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, No, it is not. D-bit was designed for a normal release. In normal release CP is responsible for breaking cross-connects (for example to avoid mis-connections during subsequent setups). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:46 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor - but it is exactly what happens the resource reservation disappears from the control plane viewpoint (after which a pathtear is sent to remove the control plane state) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 20:37 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We do graceful shutdown normally. We need another bit for this exceptional release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor but you don't need more than what's in RFC 3473 than disabling alarms during the move of the resource associated to the CP to another enitity and the send a pathtear to remove the control plane state (you don't need to involve the CP in moving the data plane resource on each node) -d. "Bryskin, Igor" 25/08/2006 20:02 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in Path and Modify messages and is meant for disabling alarms before you starting LSP teardown. What we are talking about is nothing but a bit in PathTear message instructing resource manager on each node not to break cross-connects while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful deletion bit set in admin_status, then on each node the resource is associated to that entity (which is not a CP business) and then the control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 15:12:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGh6S-0008OV-Jn for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:12:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGh6Q-0006z7-5g for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:12:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGh3Q-000B3j-Qf for ccamp-data@psg.com; Fri, 25 Aug 2006 19:09:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGh3Q-000B3P-0p; Fri, 25 Aug 2006 19:09:20 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PJ8UNq003544; Fri, 25 Aug 2006 21:08:30 +0200 In-Reply-To: <7.0.1.0.2.20060825145814.041b1e60@labn.net> To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Lou Berger" , "Li, Han" , "Ong, Lyndon" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue - non-issue MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 21:08:23 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 21:08:29, Serialize complete at 08/25/2006 21:08:29 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 lou > Given this, what's your objection here? that the move that we're discussing is not due to issues of CP resiliency/reliability/capability/or anything else equivalent i have pointed this to authors since the initial e-mail that started all this thread - hence, i can think of reason to allow for such move - but not at all for the reasons expressed since so far -d. Lou Berger Sent by: owner-ccamp@ops.ietf.org 25/08/2006 21:02 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Ong, Lyndon" , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue - non-issue Dimitri, not sure about past discussions, but you're characterization of (at least) my position is just plain wrong. I don't think this has anything to do with "unreliable control plane operations". As I said before, the requirement for this comes from the need to have a symmetric operation to gain acceptance by some carriers. From your previous mail, it sounds like you think this capability already exists. Given this, what's your objection here? Lou At 01:47 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >i agree on this CCAMP has/is building a self-consistent set of mechanisms >(from the start CCAMP considered that the MP has not being fallback >whatsover of the CP operations and in particular not linking any of its >operations to a particular MP) > >all what i am hearing from igor and co. is just penalizing the work of >this group achieved since 6 years without technical justification *** >there is no need for MP intervention in order to obtain CP operations >resiliency/reliability *** second time we have such discussion (look back >on the archive around end-october 2005, nov.2005 you will see there that >the same people already pushed forward the idea of unreliable control >plane operations - if someone's implementation is unstable/unreliable it >is not up to CCAMP to solve such issue and certainly not by interfering >with the MP) > >ps: add also add CP GR restart (from intermediate and source node) > >-d. > > > > >"Ong, Lyndon" >25/08/2006 19:22 > > To: "Brungard, Deborah A, ALABS" , "Farrel, >Adrian" > cc: "ccamp" , "Dan Li" , >"Diego Caviglia" , "Don Fedyk" >, "Drake, John E" , "Lou >Berger" , "Li, Han" , >, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, >"Bryskin, Igor" > Subject: RE: CP-->MP Issue - non-issue > > >Hi Folks, > >Just a bit worried that this discussion may be causing the impression >that >control plane is somehow unstable and requires some kind of special >backup! > >Deborah and other carrier representatives can attest that control plane >(although not necessarily standard GMPLS) has been deployed and in >operation >in a number of carrier networks for some years without experiencing any >major failures. There are already methods in use for ensuring the >reliability >of the control plane such as redundant control processors, non-volatile >storage of control plane data, software verification and testing, etc. > >I don't believe it was the intention of GMPLS work to require some kind >of >fallback to central management system control, hopefully everyone agrees >on this! > >Cheers, > >Lyndon From owner-ccamp@ops.ietf.org Fri Aug 25 15:18:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGhC6-0003Bd-Hr for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:18:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGhC5-0008He-4d for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:18:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGh8f-000BZl-SH for ccamp-data@psg.com; Fri, 25 Aug 2006 19:14:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [216.246.11.148] (helo=esc71.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGh8f-000BZU-1e; Fri, 25 Aug 2006 19:14:45 +0000 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1GGh8N-0007XD-4D; Fri, 25 Aug 2006 15:14:30 -0400 Message-Id: <7.0.1.0.2.20060825151128.03363868@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 15:14:31 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue - non-issue Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" ,"Ong, Lyndon" , owner-ccamp@ops.ietf.org In-Reply-To: References: <7.0.1.0.2.20060825145814.041b1e60@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Dimitri, See below. At 03:08 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > > > Given this, what's your objection here? > >that the move that we're discussing is not due to issues of CP >resiliency/reliability/capability/or anything else equivalent Assuming I understand what you're saying (i.e., that there is no motivation to have this feature due to failings/limitations of the control plane) then I agree 100%. >i have pointed this to authors since the initial e-mail that started all >this thread - hence, i can think of reason to allow for such move - but >not at all for the reasons expressed since so far okay, I'll bite. What are the reasons/justifications for this that you belive in? Lou >-d. > > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 21:02 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Ong, Lyndon" , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Lou Berger" , "Li, Han" >, owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue - non-issue > > >Dimitri, > not sure about past discussions, but you're characterization >of (at least) my position is just plain wrong. I don't think this >has anything to do with "unreliable control plane operations". As I >said before, the requirement for this comes from the need to have a >symmetric operation to gain acceptance by some carriers. > > From your previous mail, it sounds like you think this capability >already exists. Given this, what's your objection here? > >Lou > >At 01:47 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >i agree on this CCAMP has/is building a self-consistent set of mechanisms > >(from the start CCAMP considered that the MP has not being fallback > >whatsover of the CP operations and in particular not linking any of its > >operations to a particular MP) > > > >all what i am hearing from igor and co. is just penalizing the work of > >this group achieved since 6 years without technical justification *** > >there is no need for MP intervention in order to obtain CP operations > >resiliency/reliability *** second time we have such discussion (look back > >on the archive around end-october 2005, nov.2005 you will see there that > >the same people already pushed forward the idea of unreliable control > >plane operations - if someone's implementation is unstable/unreliable it > >is not up to CCAMP to solve such issue and certainly not by interfering > >with the MP) > > > >ps: add also add CP GR restart (from intermediate and source node) > > > >-d. > > > > > > > > > >"Ong, Lyndon" > >25/08/2006 19:22 > > > > To: "Brungard, Deborah A, ALABS" , >"Farrel, > >Adrian" > > cc: "ccamp" , "Dan Li" >, > >"Diego Caviglia" , "Don Fedyk" > >, "Drake, John E" , "Lou > >Berger" , "Li, Han" , > >, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, > >"Bryskin, Igor" > > Subject: RE: CP-->MP Issue - non-issue > > > > > >Hi Folks, > > > >Just a bit worried that this discussion may be causing the impression > >that > >control plane is somehow unstable and requires some kind of special > >backup! > > > >Deborah and other carrier representatives can attest that control plane > >(although not necessarily standard GMPLS) has been deployed and in > >operation > >in a number of carrier networks for some years without experiencing any > >major failures. There are already methods in use for ensuring the > >reliability > >of the control plane such as redundant control processors, non-volatile > >storage of control plane data, software verification and testing, etc. > > > >I don't believe it was the intention of GMPLS work to require some kind > >of > >fallback to central management system control, hopefully everyone agrees > >on this! > > > >Cheers, > > > >Lyndon From owner-ccamp@ops.ietf.org Fri Aug 25 15:20:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGhEL-0004J7-7f for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:20:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGhEJ-0000XH-He for ccamp-archive@ietf.org; Fri, 25 Aug 2006 15:20:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGhAg-000Bli-FC for ccamp-data@psg.com; Fri, 25 Aug 2006 19:16:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.240] (helo=atlntex01.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGhAf-000BlR-6s; Fri, 25 Aug 2006 19:16:49 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 15:16:48 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIeV9ht4ICTDERQxO0h4glD/8EuAAAHIPA From: "Bryskin, Igor" To: Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 Dimitri, We do need an action from CP: we need a way to signal differently normal = graceful shutdown and "removal CP state only" shutdown, We cannot overload or change semantics of the "D" bit at this point. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 3:04 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor you are hanging on "breaking cross-connection" ... what i am telling to=20 you is that there is no action required from the CP viewpoint beside=20 preventing any error/alarm and removing the control plane state (for a=20 data plane state that doesn't exist anymore from the CP perspective) = there=20 is no difference from the presence or absence of cross-connection ...=20 otherwise we would have already a PathTear error of some kind. you have in mind to involve the CP signaling in this move - which is=20 totally beyond scope -=20 -d.=20 "Bryskin, Igor" 25/08/2006 20:52 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, No, it is not. D-bit was designed for a normal release. In normal = release=20 CP is responsible for breaking cross-connects (for example to avoid=20 mis-connections during subsequent setups). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:46 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor - but it is exactly what happens the resource reservation = disappears=20 from the control plane viewpoint (after which a pathtear is sent to = remove=20 the control plane state) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 20:37 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We = do=20 graceful shutdown normally. We need another bit for this exceptional=20 release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor=20 but you don't need more than what's in RFC 3473 than disabling alarms=20 during the move of the resource associated to the CP to another enitity=20 and the send a pathtear to remove the control plane state (you don't = need=20 to involve the CP in moving the data plane resource on each node) -d. =20 "Bryskin, Igor" 25/08/2006 20:02 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger"=20 cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in = Path and Modify messages and is meant for disabling alarms before you=20 starting LSP teardown. What we are talking about is nothing but a bit in PathTear message=20 instructing resource manager on each node not to break cross-connects=20 while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved=20 from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful=20 deletion bit set in admin_status, then on each node the resource is=20 associated to that entity (which is not a CP business) and then the=20 control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian"=20 , "ccamp" , "Dan Li"=20 , "Brungard, Deborah A, ALABS" ,=20 "Diego Caviglia" , "Don Fedyk"=20 , "Bryskin, Igor" , "Drake, John = E" , "Li, Han" ,=20 owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, I really don't understand your point. Can you = restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate=20 errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, = John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so=20 allowed > > > >then send a PathTear since there is no resource anymore associate to=20 that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are = allocated=20 - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake,=20 John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not = needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the=20 present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" = , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states=20 outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" = > > > > Subject: RE: CP-->MP Issue (was RE: Polling for = new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature = what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some=20 it's > > > > > a don't care, for others they won't deploy control plane = without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this=20 requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward=20 state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don From owner-ccamp@ops.ietf.org Fri Aug 25 16:06:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGhwn-0004hJ-Et for ccamp-archive@ietf.org; Fri, 25 Aug 2006 16:06:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGhwm-0008Ea-0j for ccamp-archive@ietf.org; Fri, 25 Aug 2006 16:06:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGhrt-000Fck-UP for ccamp-data@psg.com; Fri, 25 Aug 2006 20:01:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGhrt-000FcT-2c; Fri, 25 Aug 2006 20:01:29 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PK0LbH012161; Fri, 25 Aug 2006 22:00:21 +0200 In-Reply-To: <7.0.1.0.2.20060825151128.03363868@labn.net> To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , Lou Berger , "Li, Han" , "Ong, Lyndon" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue - non-issue MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 22:00:14 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 22:00:25, Serialize complete at 08/25/2006 22:00:25 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 lou - one justification i was thinking of is the move of a connection outside CP control for off-line testing between specific segments (nodes interconnected by "passive" equipment for inst.) thanks, - dimitri. Lou Berger 25/08/2006 21:14 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , "Ong, Lyndon" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue - non-issue Dimitri, See below. At 03:08 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > > > Given this, what's your objection here? > >that the move that we're discussing is not due to issues of CP >resiliency/reliability/capability/or anything else equivalent Assuming I understand what you're saying (i.e., that there is no motivation to have this feature due to failings/limitations of the control plane) then I agree 100%. >i have pointed this to authors since the initial e-mail that started all >this thread - hence, i can think of reason to allow for such move - but >not at all for the reasons expressed since so far okay, I'll bite. What are the reasons/justifications for this that you belive in? Lou >-d. > > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 21:02 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Ong, Lyndon" , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Lou Berger" , "Li, Han" >, owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue - non-issue > > >Dimitri, > not sure about past discussions, but you're characterization >of (at least) my position is just plain wrong. I don't think this >has anything to do with "unreliable control plane operations". As I >said before, the requirement for this comes from the need to have a >symmetric operation to gain acceptance by some carriers. > > From your previous mail, it sounds like you think this capability >already exists. Given this, what's your objection here? > >Lou > >At 01:47 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >i agree on this CCAMP has/is building a self-consistent set of mechanisms > >(from the start CCAMP considered that the MP has not being fallback > >whatsover of the CP operations and in particular not linking any of its > >operations to a particular MP) > > > >all what i am hearing from igor and co. is just penalizing the work of > >this group achieved since 6 years without technical justification *** > >there is no need for MP intervention in order to obtain CP operations > >resiliency/reliability *** second time we have such discussion (look back > >on the archive around end-october 2005, nov.2005 you will see there that > >the same people already pushed forward the idea of unreliable control > >plane operations - if someone's implementation is unstable/unreliable it > >is not up to CCAMP to solve such issue and certainly not by interfering > >with the MP) > > > >ps: add also add CP GR restart (from intermediate and source node) > > > >-d. > > > > > > > > > >"Ong, Lyndon" > >25/08/2006 19:22 > > > > To: "Brungard, Deborah A, ALABS" , >"Farrel, > >Adrian" > > cc: "ccamp" , "Dan Li" >, > >"Diego Caviglia" , "Don Fedyk" > >, "Drake, John E" , "Lou > >Berger" , "Li, Han" , > >, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, > >"Bryskin, Igor" > > Subject: RE: CP-->MP Issue - non-issue > > > > > >Hi Folks, > > > >Just a bit worried that this discussion may be causing the impression > >that > >control plane is somehow unstable and requires some kind of special > >backup! > > > >Deborah and other carrier representatives can attest that control plane > >(although not necessarily standard GMPLS) has been deployed and in > >operation > >in a number of carrier networks for some years without experiencing any > >major failures. There are already methods in use for ensuring the > >reliability > >of the control plane such as redundant control processors, non-volatile > >storage of control plane data, software verification and testing, etc. > > > >I don't believe it was the intention of GMPLS work to require some kind > >of > >fallback to central management system control, hopefully everyone agrees > >on this! > > > >Cheers, > > > >Lyndon From owner-ccamp@ops.ietf.org Fri Aug 25 17:20:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGj6k-0001wh-7x for ccamp-archive@ietf.org; Fri, 25 Aug 2006 17:20:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgL7-0007VT-5U for ccamp-archive@ietf.org; Fri, 25 Aug 2006 14:23:33 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGfsw-0002g7-Nb for ccamp-archive@ietf.org; Fri, 25 Aug 2006 13:54:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGfmr-0003EP-E9 for ccamp-data@psg.com; Fri, 25 Aug 2006 17:48:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGfmq-0003Dr-MC; Fri, 25 Aug 2006 17:48:09 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PHlMWr017054; Fri, 25 Aug 2006 19:47:22 +0200 In-Reply-To: <0901D1988E815341A0103206A834DA07F9B658@mdmxm02.ciena.com> To: "Ong, Lyndon" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue - non-issue MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 19:47:15 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 19:47:21, Serialize complete at 08/25/2006 19:47:21 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe i agree on this CCAMP has/is building a self-consistent set of mechanisms (from the start CCAMP considered that the MP has not being fallback whatsover of the CP operations and in particular not linking any of its operations to a particular MP) all what i am hearing from igor and co. is just penalizing the work of this group achieved since 6 years without technical justification *** there is no need for MP intervention in order to obtain CP operations resiliency/reliability *** second time we have such discussion (look back on the archive around end-october 2005, nov.2005 you will see there that the same people already pushed forward the idea of unreliable control plane operations - if someone's implementation is unstable/unreliable it is not up to CCAMP to solve such issue and certainly not by interfering with the MP) ps: add also add CP GR restart (from intermediate and source node) -d. "Ong, Lyndon" 25/08/2006 19:22 To: "Brungard, Deborah A, ALABS" , "Farrel, Adrian" cc: "ccamp" , "Dan Li" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Bryskin, Igor" Subject: RE: CP-->MP Issue - non-issue Hi Folks, Just a bit worried that this discussion may be causing the impression that control plane is somehow unstable and requires some kind of special backup! Deborah and other carrier representatives can attest that control plane (although not necessarily standard GMPLS) has been deployed and in operation in a number of carrier networks for some years without experiencing any major failures. There are already methods in use for ensuring the reliability of the control plane such as redundant control processors, non-volatile storage of control plane data, software verification and testing, etc. I don't believe it was the intention of GMPLS work to require some kind of fallback to central management system control, hopefully everyone agrees on this! Cheers, Lyndon From owner-ccamp@ops.ietf.org Fri Aug 25 18:09:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGjrl-0000dq-83 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 18:09:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGiwl-0007r6-77 for ccamp-archive@ietf.org; Fri, 25 Aug 2006 17:10:35 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGi2O-0006Ep-0T for ccamp-archive@ietf.org; Fri, 25 Aug 2006 16:12:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGhxc-000GNg-84 for ccamp-data@psg.com; Fri, 25 Aug 2006 20:07:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GGhxa-000GNH-OT; Fri, 25 Aug 2006 20:07:23 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7PK3FA0013415; Fri, 25 Aug 2006 22:03:15 +0200 In-Reply-To: To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 22:03:07 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/25/2006 22:03:14, Serialize complete at 08/25/2006 22:03:14 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 igor - but these bits don't change semantic - you remove the state (you send the action anyway) the fact the data plane actually commits this action or not does not prevent forwarding passing through PathTear anyway thanks, - d. "Bryskin, Igor" 25/08/2006 21:16 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, We do need an action from CP: we need a way to signal differently normal graceful shutdown and "removal CP state only" shutdown, We cannot overload or change semantics of the "D" bit at this point. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 3:04 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor you are hanging on "breaking cross-connection" ... what i am telling to you is that there is no action required from the CP viewpoint beside preventing any error/alarm and removing the control plane state (for a data plane state that doesn't exist anymore from the CP perspective) there is no difference from the presence or absence of cross-connection ... otherwise we would have already a PathTear error of some kind. you have in mind to involve the CP signaling in this move - which is totally beyond scope - -d. "Bryskin, Igor" 25/08/2006 20:52 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, No, it is not. D-bit was designed for a normal release. In normal release CP is responsible for breaking cross-connects (for example to avoid mis-connections during subsequent setups). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:46 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor - but it is exactly what happens the resource reservation disappears from the control plane viewpoint (after which a pathtear is sent to remove the control plane state) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 20:37 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We do graceful shutdown normally. We need another bit for this exceptional release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor but you don't need more than what's in RFC 3473 than disabling alarms during the move of the resource associated to the CP to another enitity and the send a pathtear to remove the control plane state (you don't need to involve the CP in moving the data plane resource on each node) -d. "Bryskin, Igor" 25/08/2006 20:02 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in Path and Modify messages and is meant for disabling alarms before you starting LSP teardown. What we are talking about is nothing but a bit in PathTear message instructing resource manager on each node not to break cross-connects while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful deletion bit set in admin_status, then on each node the resource is associated to that entity (which is not a CP business) and then the control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don From apache@19greenavi.info Fri Aug 25 20:28:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGm2k-0001gK-Ex for ccamp-archive@ietf.org; Fri, 25 Aug 2006 20:28:58 -0400 Received: from [203.82.20.153] (helo=19greenavi.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGm2i-0006D0-WE for ccamp-archive@ietf.org; Fri, 25 Aug 2006 20:28:58 -0400 Received: by 19greenavi.info (Postfix, from userid 48) id 30D47A7DB1; Fri, 25 Aug 2006 20:28:45 -0400 (EDT) From: reiko@19greenavi.info Subject: =?ISO-2022-JP?B?GyRCIVo9UDJxJCQkTjdoRGpIRyJ2NDBBNEw1GyhC?= =?ISO-2022-JP?B?GyRCTkElNSUkJUgkTiQ0MEZGYiFbGyhC?= To: ccamp-archive@ietf.org Message-Id: <20060826002845.30D47A7DB1@19greenavi.info> Date: Fri, 25 Aug 2006 20:28:45 -0400 (EDT) X-Spam-Score: 3.1 (+++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 :*.$B!y!#(Bo:$B!y(B';*$B!#(B:*.$B!y!#(Bo:$B!y(B';**.$B!y!#(Bo:$B!y(B';*$B!#(B $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!ZL5NA=P2q$$;vL36ID>1D!y8xG'?d>)%5%$%H![(B $B!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B :$B!y(B';*$B!#(B:*.$B!y!#(Bo:$B!y(B';*$B!#(B:*.$B!y!#(Bo:$B!y(B';*$B!#(B:*.$B!y(B $B(#(!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!($(B $B(""#("CK("=w("L5("NA("%5("%/("%i("0l("@Z("%J("%7(""#("(B $B(&(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(%(B $B(#(!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!($(B $B(""#("=w("@-("2q("0w("O"("Mm("@h("8r("49("5A("L3(""#("(B $B(&(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(%(B $B"(=w@-2q0w$O@52q0wEPO?$N:]!"I,$:CK@-2q0w$H$NO"Mm@h8r49$,5AL3IU$1$i$l$F$^$9!#(B $B!!!!!!(Bhttp://19greenavi.info/kimi2/?a26 $B(#(!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!($(B $B(""#("%5("%/("%i("0-("FA("6H("Z$H$5$;$FD:$-$^$9!#(B $B"(CK=w2q0wF1;N$,?.Mj$H0B?4$N2<$4MxMQD:$/$?$a$K=w@-2q0wMM$O$46(NO$/$@$5$$!#(B $B!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B $B(#(!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!($(B $B(""#("0B("?4("$N("=P("2q("$$("%@("%V("%k("J](">c(""#("(B $B(&(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(%(B $B"(#1#0#0!s%@%V%kJ]>c!*-`O"Mm@h8r49!u=i4i9g$o$;-a(B $B!!!!!!(Bhttp://19greenavi.info/kimi2/?a26 $B!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B $B$4ITMW$NJ}$O(B info99@ok.kz [0826][m11] From apache@19greenavi.info Sat Aug 26 02:14:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGrQg-0004IM-7S for ccamp-archive@ietf.org; Sat, 26 Aug 2006 02:14:02 -0400 Received: from [203.82.21.102] (helo=19greenavi.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGrQe-0001hE-DU for ccamp-archive@ietf.org; Sat, 26 Aug 2006 02:14:02 -0400 Received: by 19greenavi.info (Postfix, from userid 48) id 77DA3A7EB2; Sat, 26 Aug 2006 02:09:02 -0400 (EDT) From: reiko@19greenavi.info Subject: =?ISO-2022-JP?B?GyRCIVo9UDJxJCQkTjdoRGpIRyJ2NDBBNEw1GyhC?= =?ISO-2022-JP?B?GyRCTkElNSUkJUgkTiQ0MEZGYiFbGyhC?= To: ccamp-archive@ietf.org Message-Id: <20060826060902.77DA3A7EB2@19greenavi.info> Date: Sat, 26 Aug 2006 02:09:02 -0400 (EDT) X-Spam-Score: 3.1 (+++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 :*.$B!y!#(Bo:$B!y(B';*$B!#(B:*.$B!y!#(Bo:$B!y(B';**.$B!y!#(Bo:$B!y(B';*$B!#(B $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B!ZL5NA=P2q$$;vL36ID>1D!y8xG'?d>)%5%$%H![(B $B!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B :$B!y(B';*$B!#(B:*.$B!y!#(Bo:$B!y(B';*$B!#(B:*.$B!y!#(Bo:$B!y(B';*$B!#(B:*.$B!y(B $B(#(!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!($(B $B(""#("CK("=w("L5("NA("%5("%/("%i("0l("@Z("%J("%7(""#("(B $B(&(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(%(B $B(#(!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!($(B $B(""#("=w("@-("2q("0w("O"("Mm("@h("8r("49("5A("L3(""#("(B $B(&(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(%(B $B"(=w@-2q0w$O@52q0wEPO?$N:]!"I,$:CK@-2q0w$H$NO"Mm@h8r49$,5AL3IU$1$i$l$F$^$9!#(B $B!!!!!!(Bhttp://19greenavi.info/kimi2/?a26 $B(#(!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!($(B $B(""#("%5("%/("%i("0-("FA("6H("Z$H$5$;$FD:$-$^$9!#(B $B"(CK=w2q0wF1;N$,?.Mj$H0B?4$N2<$4MxMQD:$/$?$a$K=w@-2q0wMM$O$46(NO$/$@$5$$!#(B $B!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B $B(#(!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!(((!($(B $B(""#("0B("?4("$N("=P("2q("$$("%@("%V("%k("J](">c(""#("(B $B(&(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(*(!(%(B $B"(#1#0#0!s%@%V%kJ]>c!*-`O"Mm@h8r49!u=i4i9g$o$;-a(B $B!!!!!!(Bhttp://19greenavi.info/kimi2/?a26 $B!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B $B$4ITMW$NJ}$O(B info99@ok.kz [0826][m11] From owner-ccamp@ops.ietf.org Mon Aug 28 02:51:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHayK-0003bI-5e for ccamp-archive@ietf.org; Mon, 28 Aug 2006 02:51:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHayH-0007Pt-SS for ccamp-archive@ietf.org; Mon, 28 Aug 2006 02:51:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GHard-0004kr-Gc for ccamp-data@psg.com; Mon, 28 Aug 2006 06:44:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GHarc-0004kf-Mw for ccamp@ops.ietf.org; Mon, 28 Aug 2006 06:44:53 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7S6ifsE007827; Mon, 28 Aug 2006 07:44:42 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: "Lou Berger Cc: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Mon, 28 Aug 2006 08:42:13 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 28/08/2006 07:44:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Lou, Lou Berger on 25/08/2006 17.49.26 To: "Don Fedyk" cc: "Bryskin, Igor" , , "Dan Li" , "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Don, At 10:40 AM 8/25/2006, Don Fedyk wrote: >I think there may be something here but I think even the requirements as >stated assume too much of the solution. What is the real issue? Per my previous e-mail: At 01:01 PM 8/24/2006, Lou Berger wrote: >At 10:48 AM 8/24/2006, Don Fedyk wrote: >>[...] >>If we were to ask could you live without the CP->MP feature what >>response would we get versus asking if CP->MP is a soft requirement. > > From the discussions I've had on this with carriers, for some it's > a don't care, for others they won't deploy control plane without > this capability. > >Lou AND At 08:15 AM 8/24/2006, Lou Berger wrote: >[...]I therefore think the definition of CP->MP *is* >required. There are multiple options for meeting this requirement, >but the solution must provide the "fallback" capability for services >existing at the time of the initial MP->CP transition and those >created after the transition. [...] I think a capability to remove LSP state while leaving forward state untouched will meet the requirements of those I've talked with. [dc] This is exactly what we have in mind. Lou >Regards, >Don From owner-ccamp@ops.ietf.org Mon Aug 28 02:53:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHb0R-0004UN-0U for ccamp-archive@ietf.org; Mon, 28 Aug 2006 02:53:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHb0Q-0007zu-JQ for ccamp-archive@ietf.org; Mon, 28 Aug 2006 02:53:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GHaxS-0005b5-ED for ccamp-data@psg.com; Mon, 28 Aug 2006 06:50:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GHaxR-0005ar-Gk for ccamp@ops.ietf.org; Mon, 28 Aug 2006 06:50:53 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7S6oiIR009365; Mon, 28 Aug 2006 07:50:48 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: "Lou Berger Cc: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Mon, 28 Aug 2006 08:48:43 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 28/08/2006 07:50:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Lou, you are right the first version of the ID (that was about the protocol solution) used a bit in the Administrative Obj in order to inform the TNE to not remove the data plane state but just the control plane. As you said is a very little and very simple modification. Regards Diego Lou Berger on 25/08/2006 18.32.06 To: Dimitri.Papadimitriou@alcatel.be cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, Removing state should be a simple process of deleting local control plane state while not impacting the data plane state. Exporting, at least to me, implies a more complicated API or other information transaction processing, which is certainly not needed here. I think we're talking about a mechanism that should require a single "preserve data plane" bit in a PathTear message. Nothing more. Lou At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - isn't "remove" or "export" having the same meaning in the present >context ? > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 17:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Who said anything about exporting state? > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou - and why shall CCAMP provide a function to export states outside of > >its domain of competence > > > >thanks, > >- d. > > > > > > > > > >Lou Berger > >25/08/2006 17:49 > > > > To: "Don Fedyk" > > cc: "Bryskin, Igor" , Dimitri > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, > >Adrian" , "ccamp" , "Brungard, > >Deborah A, ALABS" , "Diego Caviglia" > >, "Drake, John E" , > >"Lou Berger" , "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > > > >Don, > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > >I think there may be something here but I think even the requirements >as > > >stated assume too much of the solution. What is the real issue? > > > >Per my previous e-mail: > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > >>[...] > > >>If we were to ask could you live without the CP->MP feature what > > >>response would we get versus asking if CP->MP is a soft requirement. > > > > > > From the discussions I've had on this with carriers, for some it's > > > a don't care, for others they won't deploy control plane without > > > this capability. > > > > > >Lou > > > >AND > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > >[...]I therefore think the definition of CP->MP *is* > > >required. There are multiple options for meeting this requirement, > > >but the solution must provide the "fallback" capability for services > > >existing at the time of the initial MP->CP transition and those > > >created after the transition. > >[...] > > > >I think a capability to remove LSP state while leaving forward state > >untouched will meet the requirements of those I've talked with. > > > >Lou > > > > >Regards, > > >Don From commodoro@alyson.com Mon Aug 28 03:11:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHbH4-00039n-LG for ccamp-archive@megatron.ietf.org; Mon, 28 Aug 2006 03:11:10 -0400 Received: from host-87-74-12-51.bulldogdsl.com ([87.74.12.51] helo=alyson.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHbH3-0001qF-7q for ccamp-archive@megatron.ietf.org; Mon, 28 Aug 2006 03:11:10 -0400 Received: by 192.168.248.102 with SMTP id ngcIcxJ; for ; Mon, 28 Aug 2006 00:10:44 -0700 Message-ID: <000001c6ca71$1416edc0$66f8a8c0@syraal> Reply-To: "Cosimo Sano" From: "Cosimo Sano" To: ccamp-archive@megatron.ietf.org Subject: Re: RXcuwo Date: Mon, 28 Aug 2006 00:10:44 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CA36.67BA5FB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6CA36.67BA5FB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Go i od news for you. =20 PH a ARMAC h Y d b irect h ly from the ma z nu i facture r r, E q conom g ize u z p to 6 z 0 % w l ith us http://yunhetunahdesunter.com , b=20 , p=20 , g=20 Going to have to be. The discards may be great operators but I will dream about their sounds for years. In my nightmares. So take the survivors aside, tell them about me and the assignment. Ill meet them ------=_NextPart_000_0001_01C6CA36.67BA5FB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
Go i od news for you.
 
PH a ARMAC h Y d b irect h ly from the ma z nu i facture r r,
E q conom g ize u z p to 6 z 0 % w l ith us http://yunhetunahdesunter.com<= /DIV>

, b

, p

, g

Going to have to be. The discards = may be great operators but I will
dream about their sounds for years. In my nightmares. So take = the
survivors aside, tell them about me and the assignment. Ill meet = them

------=_NextPart_000_0001_01C6CA36.67BA5FB0-- From owner-ccamp@ops.ietf.org Mon Aug 28 05:20:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHdHy-0000bQ-Tk for ccamp-archive@ietf.org; Mon, 28 Aug 2006 05:20:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHbgv-0005ji-CO for ccamp-archive@ietf.org; Mon, 28 Aug 2006 03:37:53 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHbgt-0001Oa-Lg for ccamp-archive@ietf.org; Mon, 28 Aug 2006 03:37:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GHbbe-000A1n-FB for ccamp-data@psg.com; Mon, 28 Aug 2006 07:32:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GHbbd-000A1Y-Ah for ccamp@ops.ietf.org; Mon, 28 Aug 2006 07:32:25 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7S7WMjP018924; Mon, 28 Aug 2006 08:32:22 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: "Dimitri.Papadimitriou" Cc: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Mon, 28 Aug 2006 09:30:54 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 28/08/2006 08:32:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Dimitri, from my point of view the possibility to specify link components and labels in ERO foreseen the existence of a MP that knows that information so I can say that there are CP opertarion linked to MP. Regards Diego Dimitri.Papadimitriou@alcatel.be on 25/08/2006 19.01.14 To: "Bryskin, Igor" cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) i totally disagree you constantly referring to the MP while CCAMP has NEVER linked control operations to MP operations - these MP operations assumptions are outside scope of CCAMP in part. we are going to enter into a discussion for which we won't get the bird out of the bush: addressing space between CP and MP it took us more or less 4 years to disambiguate the DP address space relationship with the CP and there is no reason to start an endless debate now with the MP -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:39 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Approximate scenarios: a) MP->CP scenario: MP provides CP with complete ERO (including labels) CP signals SETUP with an IN-PLACE attribute, this causes provisioning operations on each node without re-programming cross-connects MP releases resource ownership after the operation by some means b) CP->MP scenario: MP receives from CP complete RRO (including labels) MP assumes resource ownership operation by some means CP signals TEARDOWN with an IN-PLACE attribute, this causes release by CP resources on each node without re-programming cross-connects Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 12:18 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) you are asking for something outside the scope of ccamp entity X wants to recuperate a CP state - just let it do - if so allowed then send a PathTear since there is no resource anymore associate to that state (but this does not require any specific documentation) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:06 To: "Lou Berger" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Agree with Lou. Can I also quote my own email? :=) "We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP." So I think we are talking about two relatively simple and very symmetrical CP functions. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, August 25, 2006 11:57 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don From owner-ccamp@ops.ietf.org Mon Aug 28 05:20:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHdIX-0001Pa-ND for ccamp-archive@ietf.org; Mon, 28 Aug 2006 05:20:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHbRD-0003MC-T1 for ccamp-archive@ietf.org; Mon, 28 Aug 2006 03:21:39 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHayC-0000ES-E1 for ccamp-archive@ietf.org; Mon, 28 Aug 2006 02:51:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GHatV-0004ve-A6 for ccamp-data@psg.com; Mon, 28 Aug 2006 06:46:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GHatU-0004vT-Cp for ccamp@ops.ietf.org; Mon, 28 Aug 2006 06:46:48 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060614/8.12.11) with ESMTP id k7S6kgJX008860; Mon, 28 Aug 2006 07:46:44 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: "Dimitri.Papadimitriou" Cc: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Mon, 28 Aug 2006 08:45:16 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 28/08/2006 07:46:38 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Dimitri, removing the control plane state of a crossconnection without touching the data plane imho is in the scope of CCAMP. Also because, but this is in the scope of a solution document, can be done via Control Plane. Regards Diego Dimitri.Papadimitriou@alcatel.be on 25/08/2006 17.51.38 To: Lou Berger cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - and why shall CCAMP provide a function to export states outside of its domain of competence thanks, - d. Lou Berger 25/08/2006 17:49 To: "Don Fedyk" cc: "Bryskin, Igor" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Don, At 10:40 AM 8/25/2006, Don Fedyk wrote: >I think there may be something here but I think even the requirements as >stated assume too much of the solution. What is the real issue? Per my previous e-mail: At 01:01 PM 8/24/2006, Lou Berger wrote: >At 10:48 AM 8/24/2006, Don Fedyk wrote: >>[...] >>If we were to ask could you live without the CP->MP feature what >>response would we get versus asking if CP->MP is a soft requirement. > > From the discussions I've had on this with carriers, for some it's > a don't care, for others they won't deploy control plane without > this capability. > >Lou AND At 08:15 AM 8/24/2006, Lou Berger wrote: >[...]I therefore think the definition of CP->MP *is* >required. There are multiple options for meeting this requirement, >but the solution must provide the "fallback" capability for services >existing at the time of the initial MP->CP transition and those >created after the transition. [...] I think a capability to remove LSP state while leaving forward state untouched will meet the requirements of those I've talked with. Lou >Regards, >Don From nwdut@rima-tde.net Mon Aug 28 08:02:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHfoh-0005Ai-0P for ccamp-archive@ietf.org; Mon, 28 Aug 2006 08:02:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHeNU-0003q9-Uc for ccamp-archive@ietf.org; Mon, 28 Aug 2006 06:30:01 -0400 Received: from 181.red-83-32-222.dynamicip.rima-tde.net ([83.32.222.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHeEf-0006yM-0e for ccamp-archive@ietf.org; Mon, 28 Aug 2006 06:20:57 -0400 Message-ID: <001201c6ca8b$9be2e140$b5de2053@OCAA> From: "Freya girls" To: ccamp-archive@ietf.org Subject: confess commit. Date: Mon, 28 Aug 2006 12:20:39 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C6CA9C.5F6BB140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 ------=_NextPart_000_000E_01C6CA9C.5F6BB140 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C6CA9C.5F6BB140" ------=_NextPart_001_000F_01C6CA9C.5F6BB140 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Melissa Melissas Run Recording heart Hollywood Whats SearchAll products = Shopping Build Advertise us. Current InHelp improve Scooter totally blown created fun poker players tour glimpse SUN CASINO dreamHOW fancy living Cardiff DAVE = JONES said: still Hair umpire Darrell during winters Ashes WRESTLING = REVIEW Hogan steals fans Eddie Guerreros wife Spin doc STRAUSS repair = crickets image pleaLEWIS HAMILTON urged McLaren bosses noseSEAN LONG = award Challenge final Rangers STEVEN NAISMITHS stopped wasteful LEDLEY = Paul Parry Brum LARSSON banned Sean Davis tribute Derby JAMIE CURETON = Tigers TEN turned showed human Huddfield Helens landed FOOTBALL LATEST = Petrov KO REDKNAPP gratuite flute piano guitare saxophone rire horoscope tarot auteur fille = oeil msnclin oeilclin .msn plusmsn Maje litead .mp litekazaa clone = romnorton recette sims msnmp gratuitmp mesenger messager film mpmusique = skype winmx hotmail zone alarmzone lire studio beta ltlt Home Who = Lawrence former Reagan advisor columnist host Company. Links Support = Troops Drudge John Batchelor Weekly Standard Mickey Kaus Luskin Times = Chicago Boyz Cafe Hayek Scott Rasmussen IBD Best Web Club Growth Belmont agreed. Brits response Kassam rocket attacks Sderot measured Kim Howells = Britains Minister Middle East told Jerusalem Post appeals rein IDF. = threeday visit region hinted Wednesday financial Authority withheld = seriously tackling still Hair umpire Darrell during winters Ashes WRESTLING REVIEW Hogan = steals fans Eddie Guerreros wife Spin doc STRAUSS repair crickets image = pleaLEWIS HAMILTON urged McLaren bosses noseSEAN LONG award Challenge = final Rangers STEVEN NAISMITHS stopped wasteful LEDLEY Paul Parry Brum = LARSSON banned Sean Davis tribute Derby JAMIE CURETON Tigers TEN turned = showed human Huddfield Helens landed FOOTBALL LATEST Petrov KO REDKNAPP = admitted pursuit Eurosport The best of live: football tennis rugby athletics cycling Lost = your password Create ca bf derby draw Athletic Bilbao and Real Sociedad = drew the opening day Basque derby. Athletics Aduriz opened scoring = before equaliser from Aranburu gt Relive actionLa Makelele manager Jose = Mourinho has blasted FIFA rules forcing row Woods won his fourth PGA = Tour title with gripping OpenTwo horse raceThe US begins today world af = Cup Juve out cup Marseille back top Cassano Italy fold Keane agrees = termsMore OpenMens Time say goodbye Memorable moments brush. then source cost tax credit treated favorably bill Somebody From = Breton minister majors windfall profits unless fuel petrol pump increase = renewable energy. exclude putting situation Mr Thursday night. hope = added. case shape form. figure hurt. Glassman facts angry wants quick = relief says Business Week. Thats hardly surprise. Over past regular = bottled water hurts consumers economy whole. however worst approach = Senate: slap WPT resulting revenue. Like imposes severance private = collects royalties lands. adopted revenues sources DesiMTV ChiMTV KMTV MTVURGEif useExp testMode //var coordVal expif = ColeWhen Feat. Keyshia ColeDir: Little XFrom Pictures Summit quotStep = Upquot Jive Records NeYoSexy Pussycat Chili Justin MTVHits Gwen Stefani = Kelly ------=_NextPart_001_000F_01C6CA9C.5F6BB140 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Melissa Melissas Run Recording heart = Hollywood Whats SearchAll products Shopping Build Advertise us. Current = InHelp improve
Scooter
totally blown created fun
3D""
poker players tour glimpse SUN CASINO dreamHOW fancy living = Cardiff DAVE JONES said: still Hair umpire Darrell during winters Ashes = WRESTLING REVIEW Hogan steals fans Eddie Guerreros wife Spin doc STRAUSS = repair crickets image pleaLEWIS HAMILTON urged McLaren bosses noseSEAN = LONG award Challenge final Rangers STEVEN NAISMITHS stopped wasteful = LEDLEY Paul Parry Brum LARSSON banned Sean Davis tribute Derby JAMIE = CURETON Tigers TEN turned showed human Huddfield Helens landed FOOTBALL = LATEST Petrov KO REDKNAPP
gratuite flute piano guitare saxophone rire horoscope tarot = auteur fille oeil msnclin oeilclin .msn plusmsn Maje litead .mp = litekazaa clone romnorton recette sims msnmp gratuitmp mesenger messager = film mpmusique skype winmx hotmail zone alarmzone lire studio beta ltlt = Home Who Lawrence former Reagan advisor columnist host Company. Links = Support Troops Drudge John Batchelor Weekly Standard Mickey Kaus Luskin = Times Chicago Boyz Cafe Hayek Scott Rasmussen IBD Best Web Club Growth = Belmont
agreed. Brits response Kassam rocket attacks Sderot measured = Kim Howells Britains Minister Middle East told Jerusalem Post appeals = rein IDF. threeday visit region hinted Wednesday financial Authority = withheld seriously tackling
still Hair umpire Darrell during winters Ashes WRESTLING REVIEW = Hogan steals fans Eddie Guerreros wife Spin doc STRAUSS repair crickets = image pleaLEWIS HAMILTON urged McLaren bosses noseSEAN LONG award = Challenge final Rangers STEVEN NAISMITHS stopped wasteful LEDLEY Paul = Parry Brum LARSSON banned Sean Davis tribute Derby JAMIE CURETON Tigers = TEN turned showed human Huddfield Helens landed FOOTBALL LATEST Petrov = KO REDKNAPP admitted pursuit
Eurosport The best of live: football tennis rugby athletics = cycling Lost your password Create ca bf derby draw Athletic Bilbao and = Real Sociedad drew the opening day Basque derby. Athletics Aduriz opened = scoring before equaliser from Aranburu gt Relive actionLa Makelele = manager Jose Mourinho has blasted FIFA rules forcing row Woods won his = fourth PGA Tour title with gripping OpenTwo horse raceThe US begins = today world af Cup Juve out cup Marseille back top Cassano Italy fold = Keane agrees termsMore OpenMens Time say goodbye Memorable = moments
brush. then source cost tax credit treated favorably bill = Somebody From Breton minister majors windfall profits unless fuel petrol = pump increase renewable energy. exclude putting situation Mr Thursday = night. hope added. case shape form. figure hurt. Glassman facts angry = wants quick relief says Business Week. Thats hardly surprise. Over past = regular bottled water hurts consumers economy whole. however worst = approach Senate: slap WPT resulting revenue. Like imposes severance = private collects royalties lands. adopted revenues sources
DesiMTV ChiMTV KMTV MTVURGEif useExp testMode //var coordVal = expif ColeWhen Feat. Keyshia ColeDir: Little XFrom Pictures Summit = quotStep Upquot Jive Records NeYoSexy Pussycat Chili Justin MTVHits Gwen = Stefani Kelly
------=_NextPart_001_000F_01C6CA9C.5F6BB140-- ------=_NextPart_000_000E_01C6CA9C.5F6BB140 Content-Type: image/gif; name="writing.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c6ca8b$9be2e140$b5de2053@OCAA> R0lGODlhvAE4AYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAASAAAALAAAAAC8ATgBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqnUhgqdOnUKNKnUq1qtWrWLNq3cq1K0YpXsOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26NLTWBNeItQV74OvauM3e3msh9+XdvoNzBd52iXDQ xI8rp5q8MI7l0KNLn069uvXr2LNr3869u/fv4MP+T28mvjz0JubTq1+PeoRA2ezjg4Qvv/5G +vbzW8Svv39E/v4FyBCAAhZ4EIEGJqjgggw26FQdDjoIYX1dRLjQhBYmiGGGBW7I4Ycghiji iCSWaOKJKKaoImPprOjiizDGKOOMI51B44045qjjat7s6OOPQAYp5JBEFmnkkUgmqeSSTDbp 5JNQRmlTKFJWaeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy26SZhfbxZWZz5VVEinXJK 1geeefbp55+ADilBoIQWauihiCaq6KKMNuroo5k9A+mklJalT6WYZqrpppx+R0SnoIYq6qik lmrqqaimqmqAOqzq6qv/sMYq66y01mrrrQy+gOuuvIbJjJNv+PZrr1sNS+yxyCar7LLMNuus eXY8K+201FY7Uj7WZqttZWZs6+234IYr7rhLLkPuueimq+667Lbr7rvwviuKStjGa++9+Oar 77789uvvvwAHLPDABA/5SMGwtiodHjGxki/DCJMEccQiTUwxSBZf7FHGGnPE8al6pPVxx/CK QXJEOZys8sost7zlIS4HF23MF9kxM80V2YyzRTrvTNHNPgctNEN/DP1Q0UY3hPSRtB23dNIK Pb0VGVAzRPVdk2h6ddUJbc31QV7rG3ZJY389UNlmp6322my37fbbcMct99z5tkD33Xjnrffe V3z37fffgAcu+OBOIkH44YgnrnhjPyzu+OOQRy755JRXbvnlmGeu+eaZI8L556CH7hl5cN2S k4fy1SD66qy37vrrsMcO8Aay137REZLbYPvuvPfuu9ABAQAh+QQAFQAAACwAAAAAvAE4AQcI /gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXL lzBjypxJs6bNmzhz6tzJs6fPn0CDCj1IaShBLEaTKl3KtKnTp1CjSp1KtSpDeFazaq26Y6vX r2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhw21xIV7MuLHj x5AjS55MuTLiNZYza178a7Pnz6BDix5NurTp06ijMmBYLbXr17Bjy55Nu7bt27hz697Nu7fv 38CDCx9OvLjx48iTI06mvLnz59CjS59Ovbr169iza9/Ovbv37+DD/osfT768+fPo06tfz769 +/fw48ufT7++/fv48+vfz7+///8ABijggAQWaOCBCCao4IIMNujggxBGKOGEbOFD4YUYZqjh hqaZweGHIIYo4ogklihSPiamqOKKflHBom4uvphbjDLeRmONtd2Io2w67hhbjz6+BmSQqQ1J 5JFIJqnkkm8hxeSTUEYp5ZRUVmnllVhmqaVvFyzVwGgsyNfllpmNSWZlZp6p5ppstunmm3DG KeecdNKF1XaD5KmnnnX26eefgAYq6KAuGUAoYIYe+leiijbqKG2hPMpXpJLmRWmleF2KKU9O burpp6CGKuqoVPpA6qmowqVYqqy26uqr/7DGKuustNZq66245qrrrrz26uuvwAYr7LDEvrdC scgmq+x8xdxnyrJMPbsrAVlJC21S1l47VLbasrQJRdx2+1O400Ui7rnopqvuuuy26+678MYr 76akzGvvvfjmq+++/Pbr778AqytIwAQXbLBOjB6s8MKZIcLwwxBHLPHEFFds8cUYZ6zxxhx3 7PHHIIeslj8il2zyySinrPLKLB+IQ8swxyxzYaoAK8rMN8uc88w89+xzg+M4VwSFQWNqzM9I J42RAEo37fTTUEctdVR+TG311VhnrfXWNcojnqmnfvNzngznIRLZPKM9s9rWyaDgIFzHLffc dNdt991456333jZ8d3RO34LRIy4QbzUDuKcoHq74lNYs7vjjkEcu+eSUU/ZH5ZhnzrHDmnfu +eegZ0cHz6OfFxAAIfkEAIvDAAAsAAAAALwBOAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qc SLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rc6RCDT58Cfwol OPSf0KJFBx4t+JMohoVInxp8CtSp0aNVrzbVulTp1qBYFX69OhUr1bBg0XrtmlZq27E848rd mJVs3btuvZa1qnctX7Fu4Rola7XuX7xM81ZFjHCsYcKJ/4JtnLfvZMiY52reHBEx48uSQWPO CpR05YOmDZ+N/Hi04sqMP7MOfLq17MyWJS9+zbm3b6inRd/GbRow5NaRg2olCno36uC5H5fm /fx47eC3kUu/7vq39++iD/7D5p4cd2HaDEmnVdpcqln3SaNzL07Zetmw9EOvHbrdPvj/vWnH Vm7h+VfdZcgd5tdg/iU4YHezxVeec+U5JWGBBfanFoAcyiVghuSJl5BZGE5oIYN2oZcedSAS 5iBa/e1l3ocVTkZhhzjy5JmKBBLHYoqzrciehejlp9uPEBpJ4HQyThhijcLB12OOVM6045FN yndekMANeeKCGCqpGnXDjenjgeHRWOGN5lXp5ktdmclVjRLGOR5XgiGF5nL7RZUndo7dGdp0 S72X2XAlzrkkdG826uijkEYq6aSUdkhOpZhmqummnHbq6aeghipqXCmMqpEbpqaq6qoUocrq q/+wxkqQq7LWamuotN6q666V5srrqNtsc1CwBAVL7EDHFiSsscYOm+w/zz5bbLTCTjtts9BW i6y2zFbbLbbXUsvsQt0qC65A44arbUa+/irqudl6u+6x8EKbrbXX4ovuuvlua+6+1kpLL7fz 8usvwPce7KzCAx+crLSnursqvNhSu6/ACSMMsMUZ//swvw37K/CyBev7r8glI2TxyiVDLPHL 5GZMcscbx1sszR93HLJBxOYcsMEabwy0wuTOTHTROhstdLowNz1swvLSfK+83OJMsNUuC310 z0OPfDHEWfNMdb0Kcf3z2UE7rXbUbBvc87beWq2x1ypfLffHZutbrsn+Ce0sdd1B56310WrD bPfUbi+br9IIfwvy0PGm6/Xkjy9MuLmH/4050YIjznfhLx/uN72YM+530oCj7XDLlXOc9smc Uy027J6j/Dno7nYdtcNim7577KmvznDKPvt8+escgw30zsz/jrvhwUd+8+zf8u067TIzDbe4 3Cded/WRG/8109pLH+7z6KdfNuTqt19pLQCG7f789Ndv//3456///vz37///AAygAAdIwAIa 8IAITKACF8jABjrwgTgagknAAAYIWrBWFAQQKC7IQZFksIMgNBUFKxjCEoKKhAoUhglXGBMJ sPCFCrEFDGdIwxra8IY4zKEOd8hDWzmhhz3+hERFhPgSIorEiBaBBBJttYUmNpEiT4SiE6N4 EipSESNT/MgSKbLFh3QxJV8cokHC6EWMHENTV9wCS65YRTWChI01IeNC5FgSOmLEjnP8VRoH 4kSBTFGNffzHEwdpxT8epJCC5GMUCelGQaaxkIwkpB+z6EhHNjKQBVkkICHZSIcQUYlbBOVB QKlEgZDSlAP5pCj/ocpSspKVroSlK4UYylnKMpWnJAgtbdnKT6bylbKc5SppOcZhrvJWcExk JTU5yWUyE5EG4aQfmxlISSrTjdZUpDYRWc1NTjOT2NRkGZLZEGLmUZfoRKI5X6lOdqbTiOtk Jxl3+ct26hKesET/ZT332c5+hhKdwNyVJjvpzGYWlJuXJKhBKxlNb1JToQ8F5zYTytCCIoSZ EZ1IPBGyxH4C1Jwe9eg+R5qQeJq0ICINKDBBqtKTdtGeeEwVNA2JUUkiVJsNxekk+zhTTjpU p9kMajghilGLSkSVozymPlFJSl6asqnuJKk8T/lFqqYToL8kKUxX2tJglvKlH9UjRZ8Zzoje dKEEgSZDhZpWh2ZzoWxVa0VxetajYnWpHb3qGLmK0q6mNKt9Zapel0rYdW7Vl38lLGD5KtCx lrWm3jwrJtsK1MeONaNvrWhcLztXg9YVrSW9a0Dz+tSu4vWqf3XpKKVqWNIKtrCAba1f/leb 1ZjK1JCWtCZZNTvUzsK1kzSlqCUV2U1IrpWSPVVoFpNbVobs8qVKfSpIlarOYUq3l/C0blK/ +lHu3lO718VqK1cKXpQe07b8IycI0csR9gKxoZNloXs1Mt/32ve++M2vfvfL3/76t76aArBz nTtfAX/KwLDaqBZb4sKOGDiMcmQvPiECYQd7xL12xCOCA3yrB4dWIRJe7EU2LOKdaFhVuXyu YFUc3mIKM7vEZHEwt/vi8J73xrVEbCyh+k4YI3bGtyRvR0WZYpXOWMa5RO2Le7niIAM5ybg0 JpOti2QouxPH3tUnkYkcVSNLyp/8zOdrFVthMI/ZyPbUKmu9/rzXHZsWl2t2c5vZrOV30lbM XUYznn0JW2Gumc1pHjM+6XnmvLo5tXou7WgzhegYDzbRq220aAPd5UE/mqOzFbGkS3zlDyc2 to82dFj7vNiTAnrSi27yn+Mcakh/+sutdnQ9eVziFP941bA9MqibilQXq1bTsb6rVfE86jOL t8fRNbWPs+zPIu+1tlw+7a/JnOlCKzrVxnbTGe6cZ0e/GtikRrSwFz3hPAd2160et7jJLVrG mhvUUp1zbWtd6lM/W9DYlvWYZyFqVtcb2++GNaunDenThhnXozVsvt/s6mrHktSrtjS9q33u dVsb4Ar/M1hLK3F2p/Th3U64yOdN/21OO8rZTYZpdFtMVadCG+TSFXLGZR5zX5s22lHecXnF bNWVJ9yWHFX2yk3Nc/Cq/OEwj/awPd7djQp9ujFGutPb3UASX7h9Vjc5SbJ+PyvH8XleT6LP 6+jfspv97GhPO4dsoPa255DrJoG7J8/9EQ/QvTdyr9QpcMRrBZdz7GS/+oAvvRG7U10lfKZw XPL+KkqXMyZwz/DdPWJ4xRbRrmhvds7v/d0p81LnOk78kHPM5KnaWMjULn2Rcdxir/p6vEcG PYxdPNXSY1rLVJY9jVm+5XnW/Lugqy7C/6lmppbb+MW3fMmRX+drx1vffe74bA3vWj2Xm+Dj xrinoz98uv7PvMyDd1qgiW75j3f/sJNffsgB/nxzbxridq9+v9kd738fH/wQvzi48a38bHMe ZuPnVdWXf9I3ZWFVS//HazdXajinajmXZeR1XRAof6cnbTwGczyHV7RWTJ03gQxXcN/nadCF ge4SgJCwBB+mbuimZujHbQWXa9fXflPnfYRHaeYXgxUWaQY3YMeXfy9ofv33gT2oKjtQRvXm eBSIg4NFdDm4f+sXg8YGfRT3fiCXXfR3hR84UvdXfs1nbVsFggvnZTaodbwSgEBmc0+2a0m2 dOznZJ3HcuJlUg0YVbYGdMbnY1Emht61dBNWh7Q3cmt4b6rXdNcnZaJHcj22e/8mVF+MByCN iHkmtl8Fliph5xKPmBGX6HaauImc2Ime+Img6HaZiCkx1YijGIr/l4KlSIYgkYlNGH6tyHec toqPVz8nBolv8ornFBKnGHiYGEAXyHo952SGSHOm93o113I/hmWGpntXJmXLZ2lY9lpex2Kw 14dU9ns2Bno7eId5+Ix7yGVVpnpDd4zm1Yuy6G9qCG4FuGc0uIT81I73FGdD6H7r6IWJh2bS V2l+lY/Hlnqa1oOEhoXyxI7/Nmtah44c8n7ShmpYSH5CuHAEl4Tp1lf/JGtU6JBRSI3weGcC mW1jmGZTN4baV5GpGCvNZkwriHt2OJHvyIcHp38+SH7/bJhy0ceHG5hpqyeBciiIL3dr2ceG +/h0opeTEHmGtvJtjDVth2hxDieRU0iD67aPnZaPClaPR5hqLDV5rtVxQJmV+jeSHYmVMtmG KAlnZtiOfaiOrqZwSvhxFBlx9ReGXniQ4QZvFBeNybdx+CaS1jeWdrl+eNlh4VhjaHlzN2aM SFiYIfh0+jiN+liBFWd/5VWNzhaIm/dzPsmS9UhrNcmYtYeHilaNWViJMxR56ccZttWLfNle qEhgJMhF5QgetHgSVbVgr5mburmbvNmbvvmb/cV1sYmLQSh4EaGQI4acaZd1zClvI4FhdHZE XNR/yolfzemaqYmbx7kZEQaK/9aIbEE2jl/Je1Xoh7EXeikneznmjRKIht8ZdaJ5joapjCum nvLplg2IkawXRGp5jyGXdMUWmI0pje7oeAhZlmZWlfIooFB5aO3GZyF4oEqJQxlZl3P5hdm3 l7PlkpjmlJLGoQz6libZfBHKf/6nQxX6n1DVmv6ImMw2cFEpnzEKljY5a1Z2dI05o4jol1oV jO+Vothnb11IozkaZh7KlnFZoydKgA06onxVovx4ezwEl1DJlvYniG65klW5hF3pcEm6pd3H cRrKlMQHlIVYkkN6Q0cXpaGZmVV1XttFczi4k2tKei6qh3YIppwZpwbYkHX6bN83XnJomNGZ KgAAAP+g4gLPiRLVWRALsADbaZwLdKhgB3jtZak5YZoahakcUQNqg6jAGaplpwuiWqqOYgQ4 8Qemuqqs2qqu+qqwGquyOqu0Wqu2equ4mqu6uqu82qu++qvAGqzCOqzEKqsVgHaWUKzKuqyl OgADABHOGirRuhIBUK3VehPXOhABkBPO2q0FMa0CAa4DEa3d+qzi+qz/UK7oShDqaq7qahDn uq7pGq7l+q3ymq71iq/1mq/tSq/sSq/eCq/r2q/+WrAVQbAIm6/2GrD6Oq0Jy7Dj+q74GrEG exLZKhDbWhPWqq04ca4RC64QG7AOC7ITO64HAbIDK68Ky7Du+q8Am7IuW7L/BRuv+mqyHmuv FTuyFHuwKguzOYuzNquyOyuz88quMKuzFWsSF/sPGWut2eq027qxTBu1Syu112q1TZux2nqx Wou1Gyu1U8u1WosRN9uwH4uu/Iq2JFu2Rju08YqyA0u0KYuyMUuzcuuuccu2Mkuz70qucKu2 RTu0e+uz4eqvHlu2dGuybWu4Lbu4FZEGEbG0GNu1VDu5lou1GHu5T1u5U1sQnNu0mmu5nbu5 opsR4rqzDtuwjZu6rHuvJ0u4idu6hXu6Mwu4r7u4fFuyjYsQiVu7H8u4jHu6dju4t0u7tGuw x+u2eOu6yRsSktu5oQu9V0u5nsu5o5u1nnu51Su9/9hLuh4xsrabujWru2hruOTruoOrsORb uBOrtiwbvuh7tzlrruarugIruEhLvDp7vMPbu7dbs+CLv+qLvHj7vxY7tqU7vaKrwAvstNDL vc/bvZP7tdh7vQ78vT6LtHHru0VLrsR7v8CLu+XbviCswfFrt7lLwkCrvCLMwv3Kvz3LwglB t72bvMIrsQNMtCVRtQ/MwKQrttzbw1kbwVv7uUYcvSFBw+1KvyU8wgBMuI6bv0vMxADctlMs twI8v4HrrTEcxV1cw7ubtFpMwDFLxmCsuElrvGGswyTBw0DsvQx8vUgMxAZBuUcMx9ZbwaZ7 tDGMvhr8u/4rw+tLsXMbuP/t28dCO8YpXMWC+8EcrL9568dd7MgdvLt+K8hfvMaDLMZtfMFh i8ea68lQK8RbexBju7kU3MATTL0b8cJ9XLxcLMI5TMmXTMiynL/n278ii8O3LMln+7YfnLa8 K7Hz+74vC77G/MuEzLwZHL9x8bwQAc2v2byyQs07Ic0Ogc0WpAIxYc2s4s3eEQHMOs7kXM7m fF+lcM6lCxLaTBDtrM6QMsrr3BDaLM8S8c7z3Morm7b8DM7w7BDuYMqnnM8Lgc08fM8InBD4 LBGHm8i0/M/OO9DybM8O7L2lzLE/XNEZbcegrBENXbdQ7MwQfRHQTMdyXMoRnNAZrcqY+8Z6 TLb/zDzMjTzS7CzKrHzSq4wQE929FRzHPm29HBHAAVzM/kzTFmHRLu3O+IzKPc3TKE29Cx0R SizIK2zUGnHKepzURZzQTKvUOR3EOP3TDxzUfIzJjmvVGYHVCQzVak3EF03KQazVJx3VDDHV ZMy+nIzWFWHPYbvKHA3WSg22cL3RYLvTBM2z/ey/xKzX4EHXjC1Ajv3Ykj3ZlF3Zln3ZvxnZ mZIP+YDZR83X2QzUac3VIsHZHWHaAoHaGqHa/8DZrs0RrG0Qsc2bmj3WHFHbFTHbF6Hauj0R rt3ZqQ3crS3cGNHbwR2qb1zEW63A08vRJc3UL/0Rs/3bA/HawU3c123a/9rN2ta93dhNELwt 3NPd3eQ93MD92+cd3sj9110d1pXb0jfNsYBt2x4R26i93ak93PldEOGd3vvt3cd9EOod4NVN 3Pfd2eWt3wHu38Bp0l6d1HJt0NFNEvbt39z93QWe4QR+3AMu2+L94fxt4BYO4gpe4hvemw4+ yhDO1m+93IcdEhVO3eZd4Bje4Qf+2h0e4hpu4iaO3ghO4hdO4pl90ysduhGOwB19EhWOEBfu 4TuO3/qd4+At5Eu+4wR+4E4OQBlAJSZd5Kms1YIN1lVL2htR5a195lF+4iWu3lgu5U8u5BvO 22vO4GiO5Q0e36N8Cl+ex0NM3xRt0SDh49lN4/+ELuBQruDoPeceLuOJvujpbedz/uhWPqt7 R9Jk7tkwU+kTAdqYrjaa3ukE9OmgPuoIoQWkfuqonuqqvuomYQis/uqf4uqwPuu0Xuu2fuu4 nuu6vuu83uu+/uuuitvAnilQe+n0Tc+cbukiAQHMzuwG0ezQLhDQ7uy9HtW4LewKbewWQe3/ wO0HQe3e7uvtXOzKPd8t3tej69dDvO4TXhHcHu4E8e4QMOyfzNV07NTHftDNzedirtYaIe8J Ie/NTu8WzO8P3u7PDddz3e7/Pu/S7vDPDvEFAe+8ntIXvdPSPOapvNb1zvAZAfDfLvHxLvI6 NAUvY/HRy9Q6zcpijcT/584RID/xJD8QFO8mVqCb/u7VfY3UZH7vBr/x7T3mGwHyMd/tI68S jwDPyb7z7P7yLa7iWG3EGv/iEzHtNA/x4W71BK/sH4HtW+8dXh/YYf/1ZF/2JqQMZp/2ar/2 HbT0t23vbs/xJ0EEdE/3A2H3I1H3dS/ZBx3RAu30gE8SeC8QRED4hZ/3h/8Pg4/Wbszi7/3V ze3X27vOXsvcVOvcHq8Qi1/4es/5nG/4e6/4np/4nZ/4hn/3no/6on/644zyBf/JcZ3kOt/D qhzKc5z5CbH4qg/6qX/6oW/3g6/7wd/7q4/3ul+srt/ysX/xcO/JOn/kCl8Rnb/7q8/6xU/6 /8Qv/NNf/ddv/cua/Abf8YMN97Zt2Lcf/Rhh/NhP/cC//sNfEO///qJ//Mgv0Swu928N6My/ /6QM/RZh+gBBhMi/fwIJFhxI0KDCgQsRPmR4MGJEhwsFOpSYUeNGjh09fgQZUuRIkiVNnkSZ UiXIAAEkumxJsCVMlzJr/ospE+fNnDkz+uxZM+jBmEBp2hR6k2TCiRWZOoX40CLGqAanPmW6 UutWrl29fgUb1uRMo0eNvpxpkyhPn2rXIi27U67btENPXsR4MSpCvVUT6qWK12lDrGINH0ac WPFixo29tnVskqpSkFQjX8acWfNmzl/JUu6sUbBG0B4th0adWvVq1v6tOZd2HVv2bNq1bZOE fVv3bt69ff8GHlz4cOLFjR9Hnlz5cubNnT+HHl36dOrVrV/Hnl274kfbvX8HH178eOwzyJ9H n9JBevaacbSHHz8xMPn17d/Hn1//R337/f8H0L4SAiSwQAMPRDBBBRdksEEHH4QwQgknpLBC C2vjJ0MN/8lQog415IcgEEPUaEQRTeQQxRQ3TPGgDj0kkUMXQwSxRRg7GpHGGD9E8UUYa1yR xSB9nBFIImM8sUQSc0zSxSGRbLLJF4m8MDQfj1wySw8zOnJGL73sckoobWRRzCjP5BLKK3UE U00kefySyhvb3DHNN+Gk08k1f9xRSxurRP5tzzj9FDHNLaPE8k8Z8TR0RSkJRXPOG81MkspE Lx3zy0qvtDNLRlsUkk1NgSQTUkA5E/TRSCVtVNFPT5RTShlLRTPWVUPtU1FXRd0UxzsXXZLL IUH9VVReaf2TVFtPvWxNJpMllc9fz3zVUV95FNTSTGHFNddeWf0UWyGppbFSYa0Nt1xQd1WV W02Z3SxVZFvdKFVMlVy2RmVNzTfTbst0c9Jit2VXSzWd/NbcdROdl114UfW23WkRRjRiYres 1t19ayVYTjw9DrhNgX2dtMhzDb3UZEyf1fXhzuSldOJCR7U43IYlZVhbknE+luOR2623WJMP RVloWKEl991lXf5eDGYdxRy3SIa5dZbSlpHW2ESWqea12me/VnFrrmeuNeixZ910Y5pZZbpt t9+GO26556a7brvvxjtvvfdmzhO+/0bPb8AhPhRsinUu1UiLke7ySUTfTVZkpe+M1nHLpaUc 18YEX06cBkMt2FOfL5Zc15g5vRfdkAF2OEh6W5264qSvNozzwTMDPXXW50wX69JzH/ho00Un vWLEzZ59coeXDsv22yMzNvRCTXVdeo7DDFb3WRFXt/eG+1Ue3GOtXsz55xszePkNK3fX+uEP XnhafaPOGuoeIQU/+aRzJlgs889vmrn4Jy6OOM137ZvZh9RHQHw9DX9+ih3sZOa+m68p5n8A REyfxucpBxawZl0LGKeONsAONrB6Kwtbxz5IL+9h5oIYNIwGWycvCf5seLIa4cRoyDPlTS1/ rZOd+iLzQhiGRX4qOiALU0i/PR0xWjtc2/50qELMNRBLaitiFrW4RS4ipwddBGMYxThGMpbR jGdEYxrVuEY2ttGNb4RjHOU4RzrW0Y53xGMe9bhHPvaxjWvwYyAFOUhCFtKQh0RkIhW5SEY2 0pGPhGQkwxIQACH5BAAVAAAALAAAAAC8ATgBBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEix osWLGDNq3BhxBcePIEOKHEmypMmTKFOqXMmypUuT6l7KnEmzps2bOHPq3Mmzp8+fQP9tCUrU YJ+iSJMqXcq0qdOnUKNKnUq1qtWrJhVg3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3NDnAnUu3 rt27ePPq3cu3r9+/gAMLHrwUGuGUhg8rXsy4sePHkCNLnjyZBeXLmDNr3sy5s+fPoEOLHk26 tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMrX868OW17zqNLn069 uvXr2LNr385d54Pu4Ff+fg9P/mEPiuPLqw+Zfr17je3fy68Yf759iA/q39/Pv7///wA6BkuA BBZo4IEIJojXNAr65E6DEEYoIXCOTGjhhRhmqOGGHAbWQocghijiiCSWaOKJKKao4oostuji izDGKOOMNNZo440izoHjjjz26OOPQAYp5HIEDGnkSPwcqeSSTDbp5JNQRinllFRWaeWVHx2B JWpHaLllaV1+CaaXYooWZpmjkYnmmq35shM1bE5IT5x01kmUGXZ+hmeeM1li1p58cgZooJoN Sihmhh7a4QuKNuroo5C61EGklFZq6aXJEYHpps15wumnoIZ6KB+iAsbHqZQVQyiqpfrFaqv/ sMYq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BGK+20aOlBbbMCXKvt ttx26+2SwHwr7oQ6jGvuueimq+667Cq2zz7txvtYCPLWa++9+Oar7755YjEYJPzqBHDANw1M sE0GH6zwwgw37PDDFRkA8cQUjwRdxRhnrPHGHHfs8ceotQGySCKPDFLJJnOEskNTpLzQygu1 7PLLDck8M80K2XwzzjtfBHPPE/2McQlAF40XFUZXhHTSEy3NdEROP/1Q1FJXnZEaVmddln5a d+3112CHLfbYZJdt9tlop6322my3LRM7LInh9txVGUP33XjnrffeVXz37fffgAcu+G7aDG74 4YiPm0fijDfu+OOQRy755JWuktE6lGce3Q+ad+7556CHLrqUuoy+5Cimp646Y92s7vrrsMcu ++y012777bjnrvvuvPdeY0AAOw== ------=_NextPart_000_000E_01C6CA9C.5F6BB140-- From hhenikg@familyjools.com Tue Aug 29 07:15:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI1ZQ-0002Ad-U5 for ccamp-archive@ietf.org; Tue, 29 Aug 2006 07:15:52 -0400 Received: from [60.16.100.76] (helo=[60.16.100.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI1ZP-0005HE-Bx for ccamp-archive@ietf.org; Tue, 29 Aug 2006 07:15:52 -0400 Message-ID: <000b01c6cb5c$7e33edc0$4c64103c@2853406ba42e4cc> From: "Little Monster" To: ccamp-archive@ietf.org Subject: MAXimum minotaur body Date: Tue, 29 Aug 2006 19:15:54 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6CB9F.8C572DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd ------=_NextPart_000_0007_01C6CB9F.8C572DC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6CB9F.8C572DC0" ------=_NextPart_001_0008_01C6CB9F.8C572DC0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable JamesB Oceans amOceans Teatons awful made anyone Mr.A wasteland Teenage = Wasteland Ilan Tenth Pishio Zack pmwill were to... Reggie books Farkas pmJosh Wasteland Ilan Tenth Pishio Zack pmwill uncanny Thursday alternate Told issues. travel road enough yourself. Vargas weary clerk = changed ancient alien artifact. SciFi Clark at: Panda Johnson. Random = Gibberish randomly RUNG. Named Cat: extra cynicism shiftyeye Reasoned = Cognition answers rkolter pmrkolter Render Strips Bugs rendered Den = Whitton. batty ambatty Road Nowhere contains: action mystery parallel = YarpsDat Rogues ClwydRhan Reinder Dijkhuis cocreator Orbit Rules better. = Since ME learning process. Saints Tarin amWhite Sanity Caughell. Dutch = Schwarz Kreuz Rhiannon kaiserin pmFenris Scrolling Blackout college = conspire sneaky tricks pranks newcomers campus. Fennec amFennec SDXF = Executive Force Jops Seaside silus Engine Funnies amTim Bertozzi Sunshine Disaster James Kochalka Devlin amJames True Loves love = Jason Turner Manien Bothma Billy Dogma Dean Haspiels pmKel Norse Elf = Lives Jon Lewis Stefan Gruber. amSebbo Gimbley Phil Elliott PhilE = amPhilE Josh Neufelds Odyssey Winton Woral Graham Annables weekly = GrahamA Bean af cartoon epic McAndrew Stuv HEADBOY pmHEADBOY new = anthology mostly women edited Lea later year amBo Lindbergh All Undone = updating every Tuesday Arcana Jayne Lisa Jontes available May Wayside = Leigh Dragoon. ldragoon pmMarilyn Camera Obscura Anne Moloney. spinooti = Chasing Rainbows Rainbows. Svetlana Seaside silus Engine Funnies amTim Second Hand twists sehad MasterB = amMasterB unreality Mondango pmderekjt Series Fortunate aspects Events. = Rourkie pmRourkie Service superhero story. amlead Sethopia Dominguez = Kellett pmDave Sinister Listen secret promise Closer whisper words hear = WHAT IS WRONG WITH YOU Litter Today. Holgersen Smithson Garritys Moores = Smithson. amA.G. Hopkins Snuffly sockbunny minimal internet. word. ziam = amBarock Songbirds gals chill yaoish mutants market politics leaves stain Joystick Parodies lazy heroes face = Wolven Zer amWolven Kat Mouse: Hire Mouse. Keeper kick Keeper. Wasslara = amRedwing Kels Nonsense semi Weird nice amKel kimbly Sias. Ryansias = Kismet Layla Lawlor amLayla estonian Zildre pmZildre Kris Lachowski kris = lachowski pmkris Rat. Questions Concerns welcome. Bring karlcomic Weeks = LAST WEEKS NEWS satire R. Fishbone. amtem Notes Vineyland Lauren Forbez = Clarence Cuasay Like Episode Of. Completed dead suggest listings pmderikb OhNoRobot search. possible GMT = Hours Who users posted total usersThe zooworms Online Iain Hamps column pmlead sharp Gavin Spielman publisher behind = Comix. those emerging novels. CityComix pmKiss category broken down = following easier browsing: pmDOOM Print Saucy Goose Press nesting = comics. Trisha pmEdward Grug III Manga Mail Join bit fun Graphix = publish. Xbuilder amJohn Northern Michigan zine Rasch pmThe Barz Squid = Works coop print members. offer free visitors try least offering quarter = but weve than late. Various creators content. pmSquid Ablaze Media Chew = cud Tozzer. Bill Duncan. D. Jun pmlosttoy sift Caleb Sevciks Sep which Jeff Crowther = Whatever Hernandez pmbangoe Space Devil Scott Mills Apr amCharles Punish = Dead cf By Toby Craig. Read latest ------=_NextPart_001_0008_01C6CB9F.8C572DC0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
JamesB Oceans amOceans Teatons awful = made anyone Mr.A wasteland Teenage Wasteland Ilan Tenth Pishio Zack = pmwill
were to... Reggie books Farkas = pmJosh
Wasteland Ilan Tenth Pishio Zack pmwill = uncanny Thursday
3D""
alternate Told issues. travel road enough yourself. Vargas = weary clerk changed ancient alien artifact. SciFi Clark at: Panda = Johnson. Random Gibberish randomly RUNG. Named Cat: extra cynicism = shiftyeye Reasoned Cognition answers rkolter pmrkolter Render Strips = Bugs rendered Den Whitton. batty ambatty Road Nowhere contains: action = mystery parallel YarpsDat Rogues ClwydRhan Reinder Dijkhuis cocreator = Orbit Rules better. Since ME learning process. Saints Tarin amWhite = Sanity Caughell. Dutch Schwarz Kreuz Rhiannon kaiserin pmFenris = Scrolling Blackout college conspire sneaky tricks pranks newcomers = campus. Fennec amFennec SDXF Executive Force Jops Seaside silus Engine = Funnies amTim
Bertozzi Sunshine Disaster James Kochalka Devlin amJames True = Loves love Jason Turner Manien Bothma Billy Dogma Dean Haspiels pmKel = Norse Elf Lives Jon Lewis Stefan Gruber. amSebbo Gimbley Phil Elliott = PhilE amPhilE Josh Neufelds Odyssey Winton Woral Graham Annables weekly = GrahamA Bean af cartoon epic McAndrew Stuv HEADBOY pmHEADBOY new = anthology mostly women edited Lea later year amBo Lindbergh All Undone = updating every Tuesday Arcana Jayne Lisa Jontes available May Wayside = Leigh Dragoon. ldragoon pmMarilyn Camera Obscura Anne Moloney. spinooti = Chasing Rainbows Rainbows. Svetlana
Seaside silus Engine Funnies amTim Second Hand twists sehad = MasterB amMasterB unreality Mondango pmderekjt Series Fortunate aspects = Events. Rourkie pmRourkie Service superhero story. amlead Sethopia = Dominguez Kellett pmDave Sinister Listen secret promise Closer whisper = words hear WHAT IS WRONG WITH YOU Litter Today. Holgersen Smithson = Garritys Moores Smithson. amA.G. Hopkins Snuffly sockbunny minimal = internet. word. ziam amBarock Songbirds gals chill yaoish
mutants market politics leaves stain Joystick Parodies lazy = heroes face Wolven Zer amWolven Kat Mouse: Hire Mouse. Keeper kick = Keeper. Wasslara amRedwing Kels Nonsense semi Weird nice amKel kimbly = Sias. Ryansias Kismet Layla Lawlor amLayla estonian Zildre pmZildre Kris = Lachowski kris lachowski pmkris Rat. Questions Concerns welcome. Bring = karlcomic Weeks LAST WEEKS NEWS satire R. Fishbone. amtem Notes = Vineyland Lauren Forbez Clarence Cuasay Like Episode Of.
Completed dead suggest listings pmderikb OhNoRobot search. = possible GMT Hours Who users posted total usersThe zooworms
Online Iain Hamps column pmlead sharp Gavin Spielman publisher = behind Comix. those emerging novels. CityComix pmKiss category broken = down following easier browsing: pmDOOM Print Saucy Goose Press nesting = comics. Trisha pmEdward Grug III Manga Mail Join bit fun Graphix = publish. Xbuilder amJohn Northern Michigan zine Rasch pmThe Barz Squid = Works coop print members. offer free visitors try least offering quarter = but weve than late. Various creators content. pmSquid Ablaze Media Chew = cud Tozzer.
Bill Duncan. D. Jun pmlosttoy sift Caleb Sevciks Sep which Jeff = Crowther Whatever Hernandez pmbangoe Space Devil Scott Mills Apr = amCharles Punish Dead cf By Toby Craig. Read latest
------=_NextPart_001_0008_01C6CB9F.8C572DC0-- ------=_NextPart_000_0007_01C6CB9F.8C572DC0 Content-Type: image/gif; name="make.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6cb5c$7e33edc0$4c64103c@2853406ba42e4cc> R0lGODlh7AFIAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAANAAAALAAAAADsAUgCBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNqRRpmq9evYMOKHUu2rNmz aNOqXSszBtu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk1aKavSqFOrXs26tevXsGPLtotltu3bWrvh3s27t+/fwIMLH068uPHj yJMrX868ufPn0KNLn069uvXr2K1SyM69u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBZoIFmgHKjgggw26OCDEEYo4YQUerRIhRhmqOGGLqnCoXoefphe iCKaR2KJ5J2Iongqrhheiy56B2OM3M1II3Y23qjjjjz2+BMPPgYp5JBEFmnkkUgmqeSSTDbp JI+cPCnllFRWaeWVWN5nTJZcdunll2CGKeZTgYxp5plopqnmmmxOJkKbcMYp52vCzNlanXau hmeeqe3JZ2l+/jlaoIKGRmihnwlzKKKdLcroo5BGKumklFZq6aWYZqrpppx26umnoIYq6qik lmrqqajCBE6qmsnD6qv/sMYq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvs s9BGK+201FZr7bXYZqvttrd1wu1U3n4rVbjiPkVuuU2di+5S6q77UCg5tevuUfLOa++9+Oar 77789uvvvwAHLPDABBds8MEIJ6zwwgw37PDDEEcs8cQUV2zxxRhnrPHGHHfs8ccghyzyyCSD pkPJKKescrLQrOzyyzDHLPPMNNds880456wzfyns7PPPQJOUQ9BEF200cmgcrfTSTDft9NNQ Ry311CF98XAqVAN3T8rlZO3112CHLfZDpYxt9tlop6322my37fbbcMct99x012333Xjnrffe /nz37fffgAcu+OCEF2744Ygn/jIDijfu+OOQRy755JRXbvnlmGeu+eacd+7556CHLvropJde VBNLo6606kezbrTrpvuXiWuUxG777bjnrvvubqfB++/ABy/88MQXb/zxyN/qTvLMN+/883J7 wrT0S1OvtPVHY2+09kVzD/334Icv/vjkE2RL+XShgv76IqvRtPtMw7+0/EqrQf/R97Ov//78 9+//rCtoWgCZNsClraCASkPg0RRotAMK8H8QjKAEJ0jBClowWh0QWBSww4sLevCDnMoGCEdI whKa8IQoTKEKV8jCFn5FCS6MoQxnSMMa2vCGOMyhDnfIwx768IdAogyiEIdIxCJ26QpGNNUO mrZEpjVxaU9UWhSPNkWjVbFoVyTaDrKYxC56MTXeKN6FvkjGMppxKjCYUiXOiC9EROsObIzj pHQjxzra8Y54zKMe98jHPvrxj4AMpCAHSchCGvKQiEykIhfJyEY6cnRAYloklzZJpfGgko+U lQIyyclOevKToAylKEcZFmmQ8pQ4xCQqV8nKVrrylUEkBixneaWAAAAh+QQADwAAACwAAAAA 7AFIAgcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhT qlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1iz at3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3DjKqUkt67du3jz6t3Lt6/fv4ADCx5MuLDhw4gT K17MuLHjx5AjS55MubLly5gza97MubPnz6BDix5NurTp06hTq17NurXr17Bjy55Nu7bt27hz 697Nu7fv38CDCx9OvLjx48iTK1/OvLnz59CjS59Ovbr169iza9/Ovbv37+A1/u6j2Cy8eYzj z6s/mX69+/fw48ufT7++/fv48+vfz7+///8ABijggAQWaOCBCCao4IIMNujggxBGKOGEltVC 4YUYZmifHhp26OGHIIYo4ogklmjiiSimqOKKLLbo4oswxkgfODLWaOONOOZIXCY69ujjj0AG KeSQRBZppI8JHIlbkkrexmSTtT0J5WxSThlblVa+hmWWXHbp5ZdghinmmGSW6RgyZqapZmwY rOnmm3DGKeecdNZpp3v13Knnnny+9kmfgAYq6KCEFmrooYgmquiijDbq6KOQRirppJRWauml DSWD6aacdmoXLZ6GKuqopJZq6qmopqrqqqy26uqr/7DGKuusMVVDK18u3KrrrryaNEqvwAYr 7LDEsuZLscgmq+yyzDbr7LPQRivttNRWa+212Gar7bbcduvtt+CGK+645JZrbn35nKvuuuy2 6+67A9LF7C7w1mvvvfjmyx8V+vbrr3z4/CvwwAQXbPDBCCes8MIMN+zwwwx9A7FG30g88cUY RxhHxhx37PHHIIcs8shSSUHyySinrPLKLCt2Scsf8QHzzDTXbPPNOIO0Rs489+xzgH38LPTQ RBdt9NFIJ6300kw37fTTUEct9dQeBzJqDnVZXbPWNHM9s9cwg92y2CyTvbLZVKet9tpst+32 23DHLffcdNdt991456333v58970nN34HLvjghBdu+OGIE65I4ow37vjjkEcu+eSUV2755Zhn rvnmnHfu+eeg4zZB6KSXbvrpqKeu+uqdpcD662vJDPvstNdu++24526wDrp7h3XLOQT/u8rC 92788Q0ts60fyDfv/PPQRy/99NTra0z12DuYRvbcd+/99+CHL/745Jdv/vnop6/++uy37/77 8Mcv//z0L2pK/fjnr//+/Pfv//8ADKAAB0jAAhrwgAhMoAIPhIMFOvCBpWuCc05gMwpW8GYW hKAGN8jBDnrwgw+sBAhHSMKekOFmJ7RZCmtGhhWW8IUwjKEMZ0jDGlonXTXDYQ5vpkOa9XBm P2mEWRBtSMQiGvGISEyiEpfIxCY68YlQjKIUp0jFKloxNsxgxhW3yMUuevGLYAyjGMdIxg/5 oIxo9Jk50LLGNLrxjRdbARznSMc62vGOeMxj2gigxz56JQB+nJ8jAknIQhoSQtM4pCKrFRAA IfkEAIHDAAAsAAAAAOwBSAIHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGj x48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmwVIrBwwwqJNgT586d/4LGlQg0Z8FiQ4VanTp wJ5HhR41OnWpUqtFEyJ1ClRp1KdVwWb9inWrzbNo06r9mJUq06tAuVKVa3au1ad0d5rd+rZv XKR13fqNS1iuYbCFnQJmurax48eQeY5tCxcxX72Dk0oFnPcwX8R25y5GCHcv486gNSeGmjmy 69ewY2Iu+rP2adZ/W4PG3FTxZtUHR1vWbdc28NSXgzNOLjy28+fQRW7+zdW0YdaVCf/ePn1y W9Siw/4CN96VtvjDgnkPzx69vfv3EN/upj48N/rdosOHVo58Oe/AxdG3n2+S8ZcagQDCp+CC Cp4WHln61XdfdWJVOKB//dl3X1S4JVbdbQ5ehyF5DJZoYnshdrifigQOWJyFd11YWHMtoscc iMclV+CBKiZ44o9AopWieg/2dZWOYuk142JHVnZZkx7e6NVUSAZmGpQHBqnlllxO5EuXYIYp 5pglfUnmmWimqaZCZq7p5ptwbtlmnHTWaedzc96p55581pRnn4AGKihJfw5q6KGIepnooow2 mlChjkYq6aSUVmrppZhmuqggmnbqqactfCrqqFvuYeoepDo0TaqspoVqq/+wxirrrLTWauut uOaq66689urrr8AGK+ywxLpUwbHI/nPsQMsim6yyzgrk7LIFUSttBdciZC20zGIL7bPWUjvt tdFWW+632x40LrnhnotusfC22y23BG2Lrbzd4psuu/Nmay+93P6brUHe+lvwvszWe+/BC/eL MLzB4htwwQNLCzDA54pLcb4Mz/uvvAJfrG3DFS/UbMcgbwzxsBKfbC7BFGtcsbsOe5syzB6r XPLIGOusLskT50zzyr62vHC569pr89Ic/zzwzd/2zG7MPtfcr8lMG5zz1UQX3bHWCbls9cUP yyw11CJLHTbVQ+M8M9Bip921rkaLTDXZR68r97T+yaIdd7MKc/0yzwopvTXYcs+Na93p3q3v 3TuX/DfclCsbeOSYv+321ZOrrTivSoObNNJ6G4656aWP/iy6kJureutTa7x66qt/bvudD9+u u6ZV7+7778AHL/zwxBdv/PHIJ6/88sw37/zz0Ecv/fTUV2/99dhnr/323APrRvfghy/++OSX b/756Kev/vrst+/++/DHL//89Ndv//3456///vz37///AAygAAdIwAIa8IAITKACF8jABloP EpCACATfNME6beKCFzxLBgeyiZVA8IMFqaBARDiQCX4wgiSM4D9OqEKCsBCFLDRIClu4whGe MIQ0XOENdXjDHb7Qhi7+tCEIZdjCHwLxiBUxohJ3iMMh8rCCS3RiCWOowyki8U0bFEgHa4JB DqokhVMUoRSHCEUxVrGEBxFjEWnIRCfCMIhCXCMcz3jEGfIQjWDE4RXLaMUkslGOe9QjHtnY RzrW0IVy5OMV3ZTFf2wRgxuEZAe76MhJNpKSGcTkI7fIwSxyUpNdpGQlPclJheTxiWFUoQ9V acZTIrKQM1RjEQ25RjXO0Y60hOEsXUlHO8bQhLJk5SEL2UtAjhCIYDylLdH4SmS+sZlYLKUW P2nJaVpTk1q8ZiSrWcmCcPOR2rRmN7cpzoWQsI9QfOIz08nOHKbRmMts5zHPWUdhvrOZvjz/ 4zMRssx6htGZzjwnLot5T3rSE4kHhaUu3ZnQMzWynJncZDjLOdFxSpQgEpVmRMW50W5KkJX2 TOcd9alKZJLUncVkIkmPWUWQxtOeRMTnHw9pwjgy1JgrReg69wlNgi5SkCAsI06pCE1gorSh ZHqoRy3KUW56VJJL3aZSMzrNUF40opCMyEvryMycCnOfB7WlQENqUqCGFKW53CMKy9pTn/pT p+rkKTH7iVSxwhOtY12lQdHq0FI6taPkJOVT/7rJqXbym4itqETs+sOjklWIbi0qTF9YU8jO lLI8HSpMW/rPP45DsjJVqCFHq1bRdhWudJ0lMUkLTEFGE6NRTSxT/ifa0dgehJqJJedsHUnR hNj1lY7lqmVxatqcsjWowL0sIUub1loOc7T9NO5v5xnc4uaxtQCFK0v9uVfmwgmqVdVtYME7 ytoK1iB+LSxgrypKpfLzl5ctKHLRSVTQWjGf9CXjTNUpWaGSUaZSVKhKgwrIVb53wH90o0v9 G12iYte+SGWUex8y4etFmE8XTlSFG7LhB/IVwx924PCwIeISY28XJr4filNsvA5jRKkr9qY0 WSwr8rpYxgohb0QeGmMca7WNetVvgGmcpkv2liEVNrJEGtljHz8kmcuNbIgdBQv5GRm8NrZq b6+c0axis71ZHWxDoHzLoRKZkTO2rWJr/ttJ9Ha5qaOs6HrHfNP3rvbMaAZzm9csShljc7bj bbNgbwzgk85VpXhGM0SpudQ4I1m9cN6teZ3qkOlGtq2JFlN6Fy3o9Lp30+WN9KRtS2jRpva0 Gc70j0B93t26Opt7VnOg5SxbcybyrqiesqqBpGNQknLOfr4ko8UsSdyKN83vDHKDEb3rUZW6 2dt7NrSnTe1qW/va2M52/aT9nFSTydsoAffzir1kSmeE2zb1bYLDOlldxzXdkJ0jEZltZ9dO RNypVCR1zapd8KG70RxBd3TjmOuYXlrdrm2tGev902Qj0t0M/2hyd5lDRQ482ozG7WG1jNWN f1qqurX1nRsO/11cG/WeoMXuh32py3m7FN4nt6lzjVtaN5b8rSS/3q/BKelqfnnYsBVzrE1J 3JHfHLX6zjfS9Un0iS9yoW9kbHaZ3tLNNpfpe112+FqNUcL2XM23veiPjc5ugxP04snNL0uH zPLVgnTqD457xXdq78rWNOua3TrQy+v1UXM9vGKXOMm7a3ZL1xWsDJ16zYmr2qrf99b59a/Z OcvZsh9a77GeNVMHvXehC7zoT8eryUH/+Dt/de5pf7p8Sw93uqOy7msdLsojjvHMvznOfi+s jB0h9CPPPukDLTzkVc966BZ/8W5ffesNrW/LH/fBPQ1+7SmK5Y2OGvczznLgia5gmf7Htc4w r6/S4X3akTZRv8k3OBVfutPuJ/u/jweyfRP475ccXk/43kj+6adj1zR0/1wCgBchgNpWgAZ4 gAiYgArIPfW3gHPjYuhGbgGHbAwhft7HXw64JX2GEPXXgAnxeaaHejmXgfBhbh6ncb3XdX52 TYAHaXzne8I3eQdHggqyfZzGW4CWZkqGVX3HXipYgUW3fqRHg+0xbF7WecDmZCrYasAGgiMo d0RYIsWWfUYYZmHmZl2nZZwmgU5IWqnnhVFYgjqYcew1Yed1fa8GcJU2hI43gmEYHR9XVb2X ZFUoa+ZFfRQIYbG3fG8ohcimhVn2gZ7GZoDYZ38GhO7nYP/01odr4oGCyIjC4ohZKImQWImW eImYmImauImcWCz99xEfd4Uc2HkdkQ+maIoDgYojcYqn2IkaoWQhEYcwOIulmA8EYYv/oIoi oYu66IoVwWWdxluZFF7apF4atXe+5nOWZGwhpxC9aIusCI3QKBDRSI3SiIu5WI23iI2oyIvS aI2+OIpYWIzLmFvHFnaZF2kWdXspmBC9mIrc2IremI242I3xWBDzmI/1iI3h+IP+iIaa14wn iI6kRoZD5xDamI3wuJDgqI8MCY+sCI4NuY/9OI7/6HUtaIfo+FDVF4y0ZhGqOI8SqZAOOZIj aY8MGZEVqYQ9aHtOJpDqeI4f+Xf/DMGPIXmPJ/mNE/mQOamQEqmSKzl0iIWRUaWRFimTnOeR h+iM29iTPVmSrdiUO0mPPBmUgHdYX7dxN+hoQmmMWHl9hYiQQEmVz6iSIimP/EiPUUmWOGmV YUKJH/GOESGXbrlqoigTCUkRdFmXfNmXfvmXgBmYgjmYo+IDhHmYiJmYirmYjNmYjpkRAPCY kjmZlFmZlnmZmJmZmrmZxMN7E2EKnBmaojmapFmac3MKptkqqJmaqbKarPmasBmbsjmbtFmb tnmbuPkp/GAQu2kRvRkRu/mbDiGcIEGcCGGcacEPyDkpyqmcErGcC9Gc0kkSvwmdD9GcF2Gd BCGd0Bmc/7yZnbyJncf5D8QpnOZJnt+Jng2hndopEOVZEO0Jn8WZnu7ZKOd5EvGpEfl5nRiR n/c5nvLpmwFanwfhndt5oANhoAU6nNG5ngNKoDBhnNVpn8fpnOSJneLpneJ5oRv6oAaaoRya oBa6odNZou4JoiRqoQganCo6nRU6oh0Koeh5nh/qots5oiF6ojGKnC6qoAlan70ZpDnKojCq oj8Knziaojg6oNWJojqqnj2ao1IqokV6n+aJoi0aozoapBmKoUb6HOypnmKqoRP6nx4qoRf6 o8vpoxDqoyyqpgnBpXDqoDL6nnMKpDOKoAvaomLap37apxqanh96onM6oUd6qP/fyac0Sp9C qqaNiqeOeqceKqOQWqdpWql+aqeVaqjQ0aTvyamBKqlrqqcHuqh7yqiAmqrdaan+iajlGaVw 6qZxqqqkuqWs+qdC2qimyqmZOqumiqlteqvCiqls6qqUeqnG+qu9SqoKyqvOYacmGqyyaqbM eqPOaaWeWqxlWqoryqPD2qCWWq2LKqtIeq3ciqiJyp15Kp/bSqtjqq61yqHTqq7emq3mKqLE mqrIaqy4Cqj0eq6UqqnrOqbt8al3uq3KOqqH2q7Dqq2iqq/H+qgDC64Q+62BSq0MO7HW6bA8 2qTJGqyzqqfTSp8Ai6bs6q7hyq8m66wou6wfC7LR8av/zRqrJauwMEuum9qv+WqmKwuw6Aqz Ljuw5tqsmjqyhCqu3OqtInuuvCqwBJuwfyq0PounUIuuVoqqLUuuEouyLPusPYqhC6uxT2qz /nqvQJqlVYqvXLqkZyuhZgulIFqga+u2Spqna4urYHukeWut2QqsAfuyl2qjVJq28Cqvxxqw cTuktqqqX7q4OkugsAq5JDq4iwuqfbKfubkngpu5B7EPnPu5oBu6olttABCZaVK6XGK6CKG6 C8G6F+G6BhGZsCsSs7u6EFG7XYK6BVG6vGu6uisQstu7rCu8vju8DKG7xAu8qou8vau8qPu7 /xC8zRu900u9vBu7yzsQz3u9/8nrvNdLvcqrvbiLFsYbuwnhuwQhu9oLvBoxvtH7vifhvumr EK6rvmQCveArvta7vr/LvOkrvevbusWrv/0bvPObv9/7vvgLvQYcwPq7vwg8wOGbv/87wfjr GOW7u+fLvvzLwfCLEe5rvyYhvw7cECQMJAs8vADMvgzcwOGbwCG8vDJMwdt7wMybvSk8vwy8 u8Urwf5rwbNbwy3svzBcvf97w0i8wsd7xN5rux6swB/8xDxcvxwsvTKMviJcv8hbxdZ7xeKb wlncxV8Mv83bwyz8wSfsGjlMwAhMweDbwgqMvvQ7wy88wxfcxlu8xhV8vlgMxBMcwQexvXD8 xkRMx/8P/Mc1DMhL7MDZG8gl7MIl7MRcDMVnfMZhzMhkXMmUvMkZjMaebLw4rMFbLMXuocdv /MJunMiofMplzL1X/L0F7L10PMBWnMRffMetHMtdXMDVK8g8XMcEbMh/TMMN/MOte8Ce7MhP DMmkfMs6DMWhbMma7MHqW82fXMaP3MicTMOf3MSgXCKm/LyoDMfkvMp8fMiqfME/TMtujL3u PMVW/MCq3M51PMSuHMyHPMyxvM4knMHarMHLvMnNnMzSHMah3MfIbM3WPM0EzcaabMfdHM0M /R7hnMXzfNEWHcPo7MLiLM9yvL8LXMEqjL2CPMsSTM+ETMy/DMzDnMp27MP//ZzQAUzFAf3R mSzTOC3RCx3F1NzT3fzQjqzTz3zQHYzMC1LRaJzOJ33KzivAG63SI93GTR3SDt3SiBzVuozL xXzSHN3VLH3VinzHJA3To5zQsDzTkSzGOT3TeZzWEJzMjVzEQ+zM03vWYtzDIjzQ7dG9fC3S wnvEdm3V79y9u3zLeB3FJW3Lsry6htzKfl3XXH3YKl3YQKzY/EwSadzQI5HZzsHZkyLWYgLa uesQ/4zZQeLZn43aDCLao9vaDWQIrh3bsv07rJ0oaRzTYaLaem3UJuwSug0otWvEx/wQfw0S pX27te3Eda3MY83Ti3y8cl3LTTzHbk3aFYHbxD0A/799uwCNKUE8wpvdvtft08zN25yN3W59 3Oe828M9Eejd2yFSEttdJ7C8wyQ91Vgc3eZbyfXNy02N3/bb315sw3ItyQdt152s1m/d3/9t 0wOt3rYrxwhexf07xdOt4P/N1gN+19qt385MyYEd4Awu0IEi0dXN39IM1N2tzj9tvv7c4nlt w0W9wT1t0M4d4jCu2Q7u3Mtc2wH+0wjN2zN+yfut4kO+zf+Mwx9t40Kd3PQ94xruzVxs46Sc 5NzLvyrc0TV+5Li85fT74QY9vmHuylcu2GZsxs2c5TIu3Qrdzlqs5UR+4XEs4BHdE3Eu1FMO 1H8932di4jVd1H2M5zid4//mnNdNzsg07edFTsVEHeFQztNa3N0Crd4hnOIdbNGPzOWZ/ucy 3ejbjMnajNBUfuJ8oug5LuFIntahfuSaDuqsLsVLDukrLsqA7uh6/ug3DdeYXOQGfsmlneSt jtiZfuiWfuevvurEjiiBDc9Snsm+nsC73uxzDuZE3OBY/uZwXdZo/cxGvtwUvuG+3OO8HOrQ 3usZHtcVzuzoDsbl6+HYvO5ZbtPQDu/WXix8/hr3rib5jhIJ7jzlnrqNsu/yTdWzXfAGf/AI L0BOzt7PIfCNse8CTwopke+o7fCM4tkx/hEWz+MMLxNiTtwc0e/kS+o3XvISsfG2ffLQgbso 3xH/9w7xQj7y7B3cvA7ysjLiY6zW1VzgzA7B9zznrwzYOb/zaK7m/q3g7n7DxCzZ//7tQk/G R+/z487Ebz30dF7vQG/12N7LSn/tT7/g9pzzd33tLY/CuH7oo/7i3B7or37qOz7pk9z2qY7i c0/itL7onw7lgk7QNJ/saS/sAU3eLMwp3D7oE33qwV72J6LoaH/N867hPw7Nbe/3Qt/u3/7s cF7YqL7nuK7DsHvgdD7uxi74Y3/rpj/pRrzqpV/4u+7Ys875p6/4JsL4mj7qr1/rkm/kiE/e hp7nsd/ikxzjpo7onS7r1Cz8m97QlL/8Mc/3wD/Rgm7fJE75hkL7t/73/65O9zs9+nWP7DLe /bsP4r+f4J3s6ca+96rv5eCf7Mqf/Xaf8ehf/ONP8ney7EN/6dn++aGf5/T+4T6/xwABQCCA fwT/HTSYEOHAggcbFmQIUeBChQ8TTnxosaJDghE5RrxoUGJHjBI/llxI0eHJjhwzhmT5UqXJ lRBljkzp0qZOjRM9UhTpcWDIlghrHkWaVOlSpk2dPoUaVerUlSKp1rRq9epWqFq5Yu36VexY smXNSvV6Vu1atm2d/twKN63bqHDLzk2Kl+5evn2b2vUbWPBgwoUNH0acWPFixo0dP4YcWfJk ypUtX8acWfNmzp09fwYdWvRo0nmV6i2Ncirq0/5IUbOeDJup7NK1BRe9ihd3bsq0W1fN+Bvs 0qw8E+sWq3e3beZ7fR9F3hz417Ssq8+e/pxudK7WpX9nSxJmVZ8uh0LvOfO8SvFBf64vKpRh fIzztYKsH7xie6P476uXb6OGsqovQNcKhEk19srrbyad9kPQvZb8Owk8C8MKyrXpBjSOw+Ia BDFE3D4ccKMRdwJuvw0zVE1FFm/SD6wXQ0RRphmDixFEAXO0EUaLROzRPJ6Wu7DI1tyDLkMg 5+OQpRNLetK4G6fUj8kfhxRSRg+FlBAlomw8j0DyrGwSRxLj688nJXUcqbgJ2wQzSzgVNPIq Uz5bTkEGy/xvt/+MSv4pSkAHPXFJLFXEksYG31y0QzkFldLHIM1c8crq/PxxrjfzHJJRHHOq M1Q5HeVTUk8ndRPVSteEdEYBWf30phdhfVTVD01U9UpCLTXtz1IrzbXRXR8UNdSLaKoQKJy0 pAkk8/JTcj1lq+ySWjR5bFZDQF0d70H7oMwvUWe3hTLZcXeUT1w9O/0y250oHLRYeTcjsa55 LdPuXn33xarFuujkl7F8Aya4YIMPRjhhhRdmuGGH9xXnYYknprhiiy/GbODONI4VvQ3RwtAs jrHja+SnAO7LV4yHIvKx61YTLmYNVbb3ZGxXosXm8IjrGGSYwypZZpMDXlOzfLmT2bSPa/5+ 6+af1/IuOedSFhrj4ZZF1lwE3zVw2aL5azbCmLKGd+xZp9Ua3Ba3LtOks6Ul1t0cIWzX7bAl PI3J8VzEGm69ASQpSa++BZzulQ+NFPFMO2w1xVoNVXRYHqMsFD0qE98y0RIlZxPIuBtPddfX nrV821K//kh007WN97qz450YVpY/dtXzMInt89Hblxxcc1t/jelyUGfHVHXR1XRS0U3nJF3E MJUb9fblhYexdjPf+5rMCeGOXXGPjVeIymgppT5YL30XH/jfYbcpd80rd7/33E+t3tNLlQZ+ +tMxl311zgP1Hv0s1r/Wrcp06fvf/oynvjPxr0eVW1+sKAes/P4NB36swxXqLhi3AHIwfI+T nPUaWLoF2u9itLILvFwUoA06jlzq8ZaaBtcttEkPbcqKFvbw1jau7aloYKrX+8TmLrYJRXB+ GtfiyHW+1oULXTpMHU7g4yCruUU7Q6uizo5zmywW7IpdDNoWU4YyMJbRjGdEYxrVuEY2ttGN b4RjHOU4R9KQMTBY5BlvutM0suDxL6xjX7+0qLCWUcyPY0pW1np2F0DGzE1GJFUCrzaqQKql ZTSb5B9HxjHAPK2PPBwg1GqFuu00En8xGl8kJfW9TC7yLC9TpStbycVKMk1kskRY2WC4xMhB bm6FS2SWzlVEtdWrUJciENjuliIvdf9NkUncW3q8RsVlto0+ezOQMrnHuL5BC3AwpCHfCrmw G3WQRZoqoQsReL0Feo6BLtQVqWhFSVD+cJzuFNYofSS7+RmQRo1rJOjkd6gdrW55hqTn+IhS SAJWKXni8+Hudse8Aj6rXIK8Wg73lNAYBu6IzivPl2blN+9xaUw+RBFAWXm6iUoxgAPVH0Ij p1DYwTJYTfIVBE11032qM5JMjCBH3QnUDz7wd+hsZz4pRSgT/pCb5axeVO+Tqph2b6bvE2oH cafPmiJOeBAMXTwn2VAilRWEk8NqU01a0UmtNZ1uPeb3MgjCC/YOWAJ0WBIRKaVwnbRbcrHo sFK413axDWv+03qk2pIkK/xkZ4TPm+FFcdgTsNGQWuy75i5LVFTKBpKF5jppTqC5rgPiko6n VaNvDola1raWKp1MmmtlO1va1ta2t8VtbnW7W9721rd+OZooD7PavG2RuA0DKm6Da8m2wIY2 nFzMPRFzXJ/dkllxSeNyXzldoOnRuAxbrV1zK60UynCH1/yrXNamWLeFr2tTxWZOD1tNRfZr hwYFp32DebfI1lCF3WwmezPL328iVk+GxSkxFatN2JLzrCNs3jqRmk5xPpV29LwpWTWpLc7i FZTXbaCEFYjWc7IVUvAEK0eLN+IRU/c753zPXbVnUZSG1pyl1SgSH1oh6nWpPbr+sU/ptve3 0NJpoiHmaubemaYZ7/ifM55dSZVKvOa1OJS9JDFdl4rWGy9unanDZIa5SbKXUJWHK0aSVims zx5TkpRqPrE/HRdEVqm1lg7GJ5KHKmYTB+mDX06ynCEcVwpuea4QznKfRazSCOq5gm2+Kpp7 ymiJkffAxyST14pp38c6MZ8i3SuyLq3MJt43suKRK2jhi2pOm6qvhfXmEpN5XsK+WrT+sazc hFnEwP5qm7d1MWSGFuytbMK61TXtzipD7BPakTkmY/Zwna3fpY0x2nGZ9m+1vW1uH6wT3QZ3 uP+hCHGX29znbu0jBpNtdLebjtd2d7wrLW9607Zszqz/d76zqGF469vfL37o8/498MN1dbEE R/jDNMzBhDfcYMlMWywdPnGKV9ziF1dMOjC+cY533OMfB3nIRZ5GOYxc3+xeDcqTg0Xk1aTk aPEocmmZxzqS+UIsi/kr07wdluf8IC//V41KtnNlS813e3SqJJub7NfavN+FAVd4iN7cngv9 5zC3Os85E0RGVjLppVw6zY0U9c8KLnlSFDjXtNZZQUKxfcVs+XlK3snGjvpYZY/oQntYIFFn m9QJpjWP27tfcZpXv5bub98niOrssVfx6T3fr0UjYI+uLU1RjPqtRRuoIAu9sRoJW0oDx/e+ euvtGH373VXvxGNxHsykL+jM/vj6P0nzraJ/Rp+aE328PXfZyhqU+MZ2HvepkgfzREfegUUP quEVn+xIIn7W2+7z57/e9Qev/vVPHzITwyfTIoSTSU3YZyY308lrdjONfwzEGuOzjsP/ceIz n3nXw1303Jt/2rd/epxTEyijLz7tM6+W+7/mW778k40UMzhrEiYs0595kiri4BTfO7P0kzPO 0Sm6MIIxiqL9K67868A2+TwCRJnsI8GYSz5NCcAURL0T9Lw04zsBREEx2TDyYzHws6etwkDd CzRAEy/QSbKwerqh60AStKAZNEDjW779kywDhD3rG7xyab3j88ADhL4S0zwrhML2Yb4jwZzH Y6dr/8m1VGo/AOKlUHuvJmtCwXI876uWs3q/IqwbNLQ0OmQ+4pm1g9s7JIzCugEMPLS6KOs/ A/MrHtO7JWwwOBpCkzuOReQtR2REw1C5SKTESrTES8TETNTETeTETkS22PKuOws78CiJa6i2 UwJF2xg2SPQiPrI56pilVfIuViS2HxwkCbKlYxvFVBTFOXIuVzS6n+rF7mLFMCo0sePFlcqM qElGXzQsN8RAJjKczJE8JPLDEjQ8/4PGwfO/GKI2xDM7ssnGZxqmccym9WKUNByyN0QsaXIp XtKl/4I4yrM1POOpFsoO3nG/EBQxDHowC1OijrmkILzAEOqpTwsqW7Q1Y//is81pNC7LqCrD LxSTxVZ8qymiwTn7vZ+aNUpLK5KSNV6JMstRSPUrSKkCSSV7Ev0rSd4bnoasqx4MQYO0K7qJ q2JcNt/jLH7ckn4kIUOryIaKSBz8ozsMtJMUSgMCNDMUtE4BM5iMQF9ip7TymA6TFaaTF347 ujHTFYD6k7mynYjMM66yyi3bPQWsJ917HSvLKnw0s7Hcsy8Tr6jMR7bEynl5RlxjHNIqM1yZ JhnzS0gyPo36qHecRvK5NDaUvwNhLPkCtTNMlyKrtWjKMRuDOAMjpmcirKoMSQhMrdDwI+h6 tu0qurtcxjfCyT0ai0R8xcmbxLwhLsCSjtT0xNr/tM3bxM3c1M3d5M19oc1chDcLKBKWcxmK W8NUK65QJE0MU02BCb7VbM4E/DqaGx1lPMbXYk3sGkYLOU6xzIvf5EqAG4tAuMXqks7n9E5U vLPpLE/hIhgx9KZvqckFUTVp0kvLpDEdQcdvgpayizgPeS/7ZJD7JEdM+zvFQyRw9Cki6ipa u5aa2hp5PMhv3CwH5U9gurmArLyjQxSrjLWfdLTF88cFtTNswUKIAtGgciBEgycKSjEP9Z/O ccgJfKs4mVCCorCB8iXwVLYS9cwOLb84O7KmfJsRlSiEfDPzaashRdEWjJ69JMCPjDEA/Ruz KqG5/KqWolE4W1Iog8Pm/8C93rOWAVWeJ4XLjRxIyAnTJatRlQJCplqscnoz5JOyreonW5TK swzPLW1TJfVJ8eRCMWVI27vBf9xRJSNSHDPUPv2qh5SnJXWgSGXTGku6hWNIQTVLrozJuCRI 7jy+V0FLnIJMb3xHawkeZ7EsNxRDX1OvaPIvUCU9zWK1RIJGeyKctiNVpxS1RwWtELq31tMr gfyvVy21u5NVcKMuPNIugoM2kwuv1wxHTxq4ZjUMY+jNa8XWbNXWbeXWbvXWTzIl95RWZNS2 a1NWbANG07QqpStMiozFG0LPTH3XivwXaHXFgRnJcS1K5prXTyTGngkzM2JR4bAp6xTF58rF 9P9suqmBxWDsLoaFzoVVpYBFriE6LPkkPPGzm/byl3Bcycorx0yiEAlN0vpU0AGzEgJVxmzi q1QNWXplUvaoJQL1G1S9UBV62e6BtAwbQUhlK69qQBYzUS27vBt1ySalyPIZmxad0xUFMfyZ IOZ82qZdSAyLWnUVlZi1wfXTyZT6QtUhSv1Mriz9PnltVDn10n3ErM4r0x0U250cSreSvuBZ 1E21Ji/NV0LqVJqEWvMJVbAN2qu91Aq6MEw6Wy3706Wps7ad0PEbp/QJq1TbWbul3A+zR0Zb OPRDpfA0qs4R3AvD1DBzzK491FTS1OuEwLUsWcity9E908rVStNNmCH/nS9K3U/G2qwE2sbH dC/WC7D0ujV0+U5eI1ZTDVRoglC9nFKMalWb/FpNG1CUOrXGzMPLwl208914/Vb11FfJwNdb RJqEVc6Z216J1c7L+F5ghJ7uNV/yLd/3hd/4lV+HwYP5td/79c32hToe/cRzhbramLZo49/i 3E7u3VdJhE5mXM4CPmB+vc4EXmADDlf2FN+Dib0Kbs116zpyBVftzeAN3koQjlgO5l4Kfli9 vUwFXVp8U2GcncHE+0/C7EkEoy+zidDCyi+yOSB84xUCE0cGW0x4rCa2vc9WpSbZHFle0ykb YlCsxZMQbdzrSlTFKUtWcp1RquJBO8ZVVd13/+GwQ/2cqUXOSZXRRyutPG0rK1bSoqVaHb1g UuxIqEQ7ydXSwA2/pTXeB22VlGxawzQUKuvCnhSzdExbF73jOwa+AlyhQq7Ti/XbsnXdyfIw Utyp162fgtQzuM09wepKnsKqLoNRmok8lZw0UoYqupylRF4quD3lVo6URi3cuAVc6QJT/8Hc RU1IO+5jg+RbMY0qUP7jrOJk9zPdOKPLx4qnTYXRq2LmzQ3dVoJlE67lUT1DdZGhVnOQYT1M PK5e680hbRxD5d3h7O1L5JRhF1VD58vVXk0PYPU0+zS9zWxXd4zBYEUma/RL/PVgkRvg28xO SuxnfRbogSbogjbog/9GaEA9X864A3ttTqyMwYTOGHpVz+dQrU+aS/K96GEMaIOW5mpzsdA0 WGNkuo+W6P/1MnNcyN9l53XkZhru0P5M4Q89YoMSMISczCGmUnY8aeta00Ub42C25Ntr0E/h J0c64/2p4jWeUU/uaampKqAWS4wEY15uFFDD0w8jqU2BLCOswKHSWvV5agg+qIdsSSW65R0s awFKylKmn/hhXHx01LHe4CxWUaZO60ruZCtNY70GS1F1KljeyBil6/OFkMa0YcC0VPXSRnah D9opPTyun8DzWo9tWdFJgJB04sLGk3sJtsweac5+MYeevL0A7foS7dRW7dVm7dZ27deG7dj/ VriOlkSf29+7eNaHVkX+Je1wlaXezg1AjEOsq7+qC24J7IrcNs/Y0G2KBjsH7tdipD+8nKG5 JW7sRO6TUW6moe2FJmz3FWGJk+4r5GkbxjVWu+a1G8EVNLIIAcBA9L76AkRT6zx0PEQlDL3i rpb0XoTZUOlV69VXIdXMii/5G+W0ua+c5sYYvh7Iq111zOF/vu66m8I7vELN69nUuz7Li2zW sz7L47wKbz4PN7/2lkPmlcHQC7BAHlEyBj9zEvDJNWoozkEq3lrP65VC88kNZWDtPvGItnAo fMIudEEgr8KZrD4QZ8LqZvEorUb4Q70Uz74kJDMYIyrmeWvKGpE//23lOC6fTL7xjGbJFaVd PpG87oDyQeTHC1c7BHTB+eqhA0lz6mNz+F5ztkVtKgdx4V7yGplugmVOqCrrMg5DqNRRoKxx 8AlzNYZTqvXODBSZOU9OJ3RnLexzODc/xtRCJX9z/AZBltb0JRRyJJxyUafOur1Kz6pTH0VK W84VAfdcQ8bSV3ZaTmVXdKX0vfR0kJVy1TvxOCXyLOS/ALz0XafCEr8fKt9wkCX1jPQ7A51q ybKp0ZpGWy0oGT7n83pnY4psYELeFS49vZLwoEvCX1PVSk89FuLDrKNhKgqyKC1AUzfEQpxj dndv7KtVPmTJ7vZoTuJ32Y4jhwZugCf4gv83+INH+IRX+HoLL/+W4Jz0jIG3IqcT12acdA22 +M2Orn1uYGjmeH+dxbSs+OhsDIr9WQkM4EO22j/8eLEr2LoMS9Aw6RP2+B7XX+X896AmYKS+ 1xr0wuhueZ5/1xi/dfT9b4/1zwJbEMej21FFb5pelZCq0KmH1191aXCOr42tdndsR1cFPMir 3l3+rMVc3ohLWaevaQTvW7nVeO6q0bnu68y9Ry92SX9cS1N+3n9qyDUW3no8WjbbWzmGKLyV 8z4VKx4fWqXToIymF4JiiHpQZFTPaq69yCajqL7tYrtscBTkWS4l5Ly7chTS0MtHZgCPfOVh 4hznVPTqy7EN4Un+Y3yjaWREr3VZx/y9NXnWhftBY3VcXX3Nb8ozFtJIncBE59N7clNBVluI nLC3DHrFkHsub0vJx30zvTFM2Vm3/lLNL+ZfNnyzllQ89UG2F2PyE2zmX8DQuZWIh3YK1Wx2 Hsx1xszHDN6T17QZlvr39/YPdVnKpvvWB4h/AP4RFAhgYEGDBwkiZLiwYEOEBx9OhFjR4kOG CTVCdBixYkOMHDMq/CgxIcWOHgeGvIhRIsyUG02eHKlyI86cOnfy7OnzJ9CgQoWGHNqzqNGg SJMybTp0qVOcQpRGrWr1alKoOiNi7er161etTsVedQn2rFGyaHOqXev2rUCgXOHSrWv+N6ed u3r38u3r9y/gwIIHEy5s+DDixIoXM27s+DHkyJInU65s+TLmzD/b3izLWXPgz5tB0xVN2rLY oizLbgV50+VEpLF9mm69tDbbzlRFZnX4uiVIswZnkrS9mqNClMJxZsSN/DR03Ue73p6pcu7c 57RZ567qXPd3mL/BdyaZvftr5DU3n38a/fFy1xpne4xb0v7F1e3zm8+9fn551o20EH8xDVcf SishmF9c9CWXnIH3LSigg8uph59N9gWIoYYZStegdseNVhODHML2HmQtJQggiy2KON96Krb4 4XGqaaiaTCCmx+JJUMV4Y0c52sgVkeTZCCRZRZrIm4wkUij+oHX/4Vecfy4uKRuKjDl4IJJB KqnjbCoeqeOKzBlpoU3iqRdmmtV1uZKI2MlHZpwKHvnlVtctGeWKTpYJJZRjPmdWjyXpB2Jx 32UJV3vDffkRnZGKGWiH2u0Y5HZkOkoeh1x6WGeZj74pKaZ9lroTdg3GNmSCq75Y6YdA/gnr k68eCqmliw7WKKmDkoonrMDmKmOnqEoHKpi+mmols706W+edp4Y4HrHMNnkpjaGayROkqU7r oa67EtpccBTJxOZ9gjJpHHjNsfsbriX2mCiB10WYXUzi3WtvvSLJKWWn/cJorrvwzqpgiORS ue2BJw6Ib7gRp5WYohLLZVfFu1r+vDFRFHM8VDUd17Vwih+bfDLKKau8Msstu/wyzDHLPDPN Ndt8M840Z8yUrTu/XG1Y6OXqlc85k7Yqrds5d2isQvtl0mFAY/Xqt3lOx1vTQelgNHTtAbIb zx1+VvRYPxYmNXVOK1qw2FzDTBPW/j4onJNML6hwfUVGqJzZDLIq60t3swQ1gkzCNi7exPWd 0r3yJiohpcoWCPe/gT94udsaX3jepBfqiWjbnp9KpNmbj+7pnqFXWqOVSY5KLLJ8Tmtrl5wD finQ0J7e6ulkZ5725lu6S9Okt6qOdLrpEa8tmOjyLTDsdrYZHFtzxk463X4HXqP1qhJ6u+hN di9q8gP+E+j771ZBnJrdPoJuN/jkR4peoasbe7uodVevrfyjRs46gHQXwDw1CmK9O2DrpGWR 9GnudVUy4I7gt77dze94uEtawPhXqvqpzoG2axbgJihA0PmqgNgaIQo9uCH0MdA9nsseifYW QU0BB24NmxPmCie2HDEsPpPbU4GY0z3IQc6HbEteviQkwwoWjm7Se1gSlRjEy7GwhVZcSxWv iEGrabGLlEGTF3lGsuplMYxmPCMa06jGNbKxjW58IxzjKMc50rGOdrwjHvOoxz3ysY9+/CMg AynIQRKykIY8JCITqchFMrKRjnwkJCMpyUlSspKWvCQmM6nJTXKyk578JCj+QynKUZKylKY8 JSpTqcpVsrKVrnwlLGMpy1nSspa2vCUuc6nLXfKyl778JTCDKcxhErOYxjwmHQ+hzEMQZJnO TAgzCxJNaW7Emcv8xzSbic1sMtOa3XwmTqwpzWs2k5zV5OY0wblNZY5TneUkpzq9Cc15UvOa 7KTmO7NZznnKk5v0jCcyz+JPfPKTntjcyUDr6U99HpSgDtUmPtMZTnRCFKISbahOFhrRjGL0 og29p0UNus96hlOk3fxnQMHC0IceNKErrShGtXlSmZZUpDG9aUtZOtOTMnSmH+WJRkOaE59G c6BExWk1O4rUov50qSn9yktx6lOaItSmPCVpUq3+mtWCwpSqV03qRaMa06MiNadU3ahExWrW taKUqU59qlfceVOPdrWmXd2pTMWpz70+s6frXClep5pXkMoTmuCMpziVus2aupWoIBXqNw/r 1XbSFa5x1epde5LQs34Vsw/1q1uzek/BmrWyWy0tSxUr2NB2NrM0BaxSYVtWy1Zls3/dq2a1 mlapnnauJTVtUZkK2o1WFatNPSc8Ycpatvr2tRlN50tDS9uobNa2trVrRaXLTr/qFLvL7e1x jytd76oWu2sNq2GVe9rtctSg150udc2pXpPmFrkO3a5e5VrXv94XvNAlLD8TS1nt3na1Y13n WP/72AQX+LOGBTB8Iyz/4QlTuMIWvjCGndIG+EIjwx7OSYc/LGKChHjEHIOnfPNpT7Dml7AC Bu9d8ZteexZ2wC5esGv5O19tlvjF6MRxgQ2MYiAftsZy7atN82nS97qzyUD+JIGHqlu7jlfK sv0nRZtb3P72NsrVLbFTPRpV6wo1xwemb46vzNXFdpe4ZVarJqssZQdzN7wE6QJY59zWySZ5 vebFLXeF20wwh5mgY8asnFO7Y+O6uc/nVWxq67xfTybaz2s29KQv3ebAmlnPvJ2yaPncZ6K+ IdNktjOMF31WRjv6qJVVc6dBqeAtB7nBiNUvcBn70/Gq9bp81auucwqNnkrWoileb2FnPdEF /vtaqoemMmS3umJpwznOnkYzq8Vb30+jlM283ja3Mxvo2Jq3vLM9c6MVvejh5vna2X03bjWN alHCmsvZRi9QcR3s0cba0p5ddXajOex6J9a09i6zo9f922DDuOCsBjTDSxll8sob3+11cKgz rm4zSzq8p+5yu2d76okrHNvxfiud02vp95JyyM8WN7AVeuQu95W9LGa5To+t5ZmPGuQsJ7PL h5piYjN72vtF8qWJfGucm7jpTn861KMu9alTvepWvzoez4H1WtL4xehuqc03ruOxPzayNf+m ps1edKQPlt/LVvB/2RzwJyPWqv28edBvS/F0w/fk/m6q38tt1OqK/zao2e65x8M98eB2u66D bzWo6Ut4l4o9pYHfs7nV3fGc0jXerg65uwGf9oV3+/NAXbjBv87ccJMb05mG6+XR+m4tCx71 B9/1w88d3c7THuCNbT2tnTtpoNfevb5l+lNjH9LvRlMXpq797zH+e0B73ci8v7yBRX9eZpM+ 0UAveHIbH/hqI1P5j7b48/0L/ObuFuLBH+eAY5395Wa/u7v1tPur6nmMVz6g5pd72fWb45Ee W+2f8B1epCGc/LEfvPUeu62eqpEW6H0Uz/Vf+aUaxwngADZaADaet/Ed4lWZpC2ecpHcfGXZ n/Gd4dkZ8k2XfInVyXUdfunc0t1XdYUdAP/e2NDFHMDpnZKpWDsxGBC+nQ1eXBCqWHCNFkBh 2+ttnRM+4RmpARRalhROIVxVoRVmoRZmzhNsoRd+IWPEoDmNX4C51xgy4dfVX4JVn/Up3Q52 IBhihph54M6NFMKRnN+t4Po1YR7uHeXFoRyqoAM2YA9O39HxWQyy3t7xXyE2ISA6BlmNXtLt oejJmaCx4L2BW8flHwg+omQ02/gZIGkZ4lvhVa1BGh8mWTYtACcqoCdOBij6nPGNImcVmqi9 GQaq2iCO2ytaRiwiGqbRoh0+WQ5KXwUa4SZO4Lz14mP04ewZnxASXsIloiSmIhqiWwsyY2MQ 3a/hnxCOnQZSY+5BiR03Ct0bZqM2pqM6riM7tqM7viM8xqM8ziM9clIf1CM+5qM+7iM/9qM/ /iNABmR0aJ1AFqRBHiRCJqRCLqRRBAQAOw== ------=_NextPart_000_0007_01C6CB9F.8C572DC0-- From owner-ccamp@ops.ietf.org Tue Aug 29 08:32:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI2lO-0005OD-LN for ccamp-archive@ietf.org; Tue, 29 Aug 2006 08:32:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI2lM-0003s3-9L for ccamp-archive@ietf.org; Tue, 29 Aug 2006 08:32:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GI2dI-000AQr-83 for ccamp-data@psg.com; Tue, 29 Aug 2006 12:23:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12 autolearn=no version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GI2dH-000AQc-SX for ccamp@ops.ietf.org; Tue, 29 Aug 2006 12:23:55 +0000 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 Aug 2006 05:23:47 -0700 X-IronPort-AV: i="4.08,180,1154934000"; d="scan'208"; a="315304182:sNHT12988642272" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7TCNkJa015099; Tue, 29 Aug 2006 05:23:46 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7TCNj6Y010254; Tue, 29 Aug 2006 05:23:45 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 05:23:45 -0700 Received: from [10.21.145.148] ([10.21.145.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 05:23:45 -0700 Message-ID: <44F3AB01.3060503@cisco.com> Date: Mon, 28 Aug 2006 22:48:33 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: OSPF List CC: ccamp@ops.ietf.org, David Ward Subject: Re: [OSPF] draft-ietf-ccamp-automesh-01.txt References: <44DCA819.4000802@cisco.com> In-Reply-To: <44DCA819.4000802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2006 12:23:45.0574 (UTC) FILETIME=[F8F77460:01C6CB65] DKIM-Signature: a=rsa-sha1; q=dns; l=872; t=1156854226; x=1157718226; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20draft-ietf-ccamp-automesh-01.txt; X=v=3Dcisco.com=3B=20h=3D8j11J++E6Pa/BZ2WZ4YQIfLMMcE=3D; b=BQ1OSD5KkSK8uRYQCLRyJhHGqlqLiH+PMl+AYiX2RFkz1vQrQf4DsMJa2s5VPyQp4xt+ujMs xnL7oMKL2EuExLjnXnjwoV9B0w7KoseXwEatm4pxB1G0Xim7iK0cauuE; Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d The OSPF WG last call has ended. Thanks, Acee Acee Lindem wrote: > The above draft makes use of the OSPF capabilities LSA. It is my > understanding that it has been last called in the ccamp WG. We are > now last calling it in the OSPF and ISIS WGs. > > The last call will start today (August 11, 2006) and end at 12:00 AM > on August 26th, 2006. Please copy this list and the document editors > (JP Vasseur and JL Leroux) with your comments. You can also copy the > ccamp list if you are subscribed (I believe the list is closed though > I'm not sure since I am subscribed). > > Here is a link for you convenience: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-01.txt > > Thanks, > Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > From owner-ccamp@ops.ietf.org Tue Aug 29 18:28:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIC4o-0001ef-Pw for ccamp-archive@ietf.org; Tue, 29 Aug 2006 18:28:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIC4m-0001BJ-BK for ccamp-archive@ietf.org; Tue, 29 Aug 2006 18:28:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GIByD-0009KY-C4 for ccamp-data@psg.com; Tue, 29 Aug 2006 22:22:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GIByC-0009KF-Cq for ccamp@ops.ietf.org; Tue, 29 Aug 2006 22:22:08 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7TMLlDN017749; Tue, 29 Aug 2006 15:21:47 -0700 (PDT) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu0.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7TMLer0017720; Tue, 29 Aug 2006 15:21:45 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.7/8.13.7) with ESMTP id k7TMLcsB013110; Tue, 29 Aug 2006 15:21:39 -0700 (PDT) Received: from [133.164.59.194] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k7TMLRw14711; Tue, 29 Aug 2006 15:21:31 -0700 (PDT) Message-ID: <44F4BDE0.1090204@us.fujitsu.com> Date: Tue, 29 Aug 2006 15:21:20 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ccamp , mpls@ietf.org Subject: call for papers: 1st IEEE International Workshop on Bandwidth on Demand (BoD 2006) Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Apologies for possibly receiving multiple copies of this CFP. Call for Papers 1st IEEE International Workshop on Bandwidth on Demand (BoD 2006) http://www.csg.unizh.ch/events/bod06/ In conjunction with IEEE GLOBECOM 2006 http://www.ieee-globecom.org/2006/ November 27, 2006 San Francisco, California, USA Scope Electronic marketplaces for trading bandwidth have emerged since the late 1990’s, but were seriously hit by the economic downturn in 2001. The promise of instant bandwidth availability had led to the development of market mechanisms that companies used to trade bandwidth just as other commodities. However, those trading markets all but disappeared with the bursting of the telecom bubble. Driven by the recent technical advances in telecommunications and the new potentials of emerging peer-to-peer (P2P) and next generation networks (NGN), the goal of this workshop is to take a fresh and innovative look at the concept of bandwidth on demand (BOD). Recent advances in the Internet-based communications domain, in which the support of Quality-of-Service and diverse application services become possible, require in many cases short-termed bandwidth assignments for, e.g., large sporting events or cultural open air activities. In addition, the support of bandwidth trading in a fully decentralized and secured manner, e.g., based on P2P schemes, shows further advantages in terms of reliability and scalability for large-scale systems. Topics of Interest The workshop seeks original papers in the following four areas that serve as basis for bandwidth on demand: * Economic studies and modeling of market and business models in carrier and service provider networks o Game theoretical bandwidth-on-demand models o Cost and revenue models o Bandwidth-on-demand business models o Market liquidity aspects * Technical design of scalable, reliable, and cost-effective bandwidth trading infrastructures, including market mechanisms as a way to increase efficiencies o Scalable market mechanisms o Secure and reliable market infrastructures o Bandwidth trading mechanisms o IP-based and decentralized trading mechanisms o P2P trading infrastructures, distributed markets o P2P auctions * Legislative and regulatory issues related to the Telecom Act and in comparison to other commodities markets such as the electric grid o Telecom legislation o Telecom regulation o Commodities markets * Industrial developments of new technologies that facilitate or create impediments to bandwidth on demand o Network management aspects o Technical improvements in transport and data networks Paper Submissions Papers are solicited as full papers (in English), of no more than 8 single-spaced pages, each of which will be subject to a full review process. Submissions must be in PDF and will be handled using the JEMS system. Please refer to http://www.csg.unizh.ch/events/bod06/ for further submission instructions or contact bod06@ifi.unizh.ch for additional information. Those papers accepted will be published in proceedings with an ISBN number. Important Dates * Paper registration deadline: September 14, 2006 * Extended submission deadline: September 21, 2006 * Notification of acceptance: October 15, 2006 * Final versions of papers due: October 31, 2006 * Workshop date: November 27, 2006 Committees General Co-chairs * Takeo Hamada, Fujitsu Laboratories of America, USA * Burkhard Stiller, University of Zurich and ETH Zurich, Switzerland * Jean Walrand, UC Berkeley, USA PC Co-chairs * Richard Rabbat, Fujitsu Laboratories of America, USA * David Hausheer, University of Zurich, Switzerland Technical Program Committee * Panayotis Antoniadis, LIP6, France * Greg Bernstein, Grotto Networking, USA * Georg Carle, University of Tuebingen, Germany * Costas Courcoubetis, AUEB, Greece * György Dán, KTH, Sweden * Vasilios Darlagiannis, EPFL, Switzerland * Zoran Despotovic, DoCoMo Euro-Labs Muenchen, Germany * Chris Edwards, Lancaster University, UK * Adrian Farrel: Old Dog Consulting / IETF CCAMP Working Group Chair * Oliver Heckmann, TU Darmstadt, Germany * Rahul Jain, UC Berkeley, USA * Charis Kaskiris, UC Berkeley, USA * Dave Marples, Telcordia, USA * Michael Menth, University of Wuerzburg, Germany * Huw Oliver, Bristol, Research Consultant, UK * Lyndon Ong, Ciena, USA * Aiko Pras, University of Twente, The Netherlands * Giancarlo Ruffo, University of Torino, Italy * Vik Saxena, Comcast, USA * Vishal Sharma, Metanoia, Inc, USA * Kohei Shiomoto, NTT Labs, Japan From cormacolower@bordertradeservices.com Wed Aug 30 05:22:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIMHY-0007wT-4o for ccamp-archive@megatron.ietf.org; Wed, 30 Aug 2006 05:22:48 -0400 Received: from [222.132.16.189] (helo=bordertradeservices.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIMHW-0006Ou-DB for ccamp-archive@megatron.ietf.org; Wed, 30 Aug 2006 05:22:48 -0400 Received: by 192.168.110.171 with SMTP id hxAWWDt; for ; Wed, 30 Aug 2006 02:22:05 -0700 Message-ID: <000001c6cc15$c2a0b790$ab6ea8c0@jxmsvi> Reply-To: "Kishori Cairo" From: "Kishori Cairo" To: ccamp-archive@megatron.ietf.org Subject: Re: eeRXky Date: Wed, 30 Aug 2006 02:22:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CBDB.1641DF90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6CBDB.1641DF90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Go p od news for you. =20 P x HARMAC o Y di u rect e ly from the ma e nu f factur s er, E g conom j ize up t f o 6 k 0 % w p ith us http://monotionyterdin.com , i=20 , x=20 , r=20 Thank you, Fido said emerging from the undergrowth with a jagged bit of metal in its jaws. Just follow me if you want to see the remains. ------=_NextPart_000_0001_01C6CBDB.1641DF90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
Go p = od news for you.
 
P x = HARMAC o = Y di u = rect e = ly from the ma e nu f factur s er,
E g = conom j = ize up t f = o 6 k = 0 % w p = ith us http://monotionyterdin.com
<= P>, i =

, x =

, r =

Thank you, Fido said emerging from the undergrowth with = a jagged
bit of metal in its jaws. Just follow me if you want to see = the
remains.

------=_NextPart_000_0001_01C6CBDB.1641DF90-- From harish@bart.worldwidehost.com Wed Aug 30 11:56:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISQX-0006jL-No for ccamp-archive@ietf.org; Wed, 30 Aug 2006 11:56:29 -0400 Received: from bart.worldwidehost.com ([216.21.7.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISQW-00080m-C7 for ccamp-archive@ietf.org; Wed, 30 Aug 2006 11:56:29 -0400 Received: (from harish@localhost) by bart.worldwidehost.com (8.9.3/8.9.3) id LAA14489 for ccamp-archive@ietf.org; Wed, 30 Aug 2006 11:56:20 -0400 Date: Wed, 30 Aug 2006 11:56:20 -0400 To: ccamp-archive@ietf.org Subject: Your Flagstar User Agreement Message-ID: <1156953379.124034.qmail@flastar.com> From: "Flagstar Information" Content-Type: text/html X-Spam-Score: 4.5 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Flagstar Corp.

Dear Flagstar Corp Client,

This is your official notification from Flagstar Corp that the service(s) listed below
will be deactivated and deleted of not renewed immediately. Previous notifications have
been sent to the Billing Contact assigned to this account. As the Primary Contact, you
must renew the service(s) listed below or will be deactivated and deleted.

Renew Now your Flagstar Corp Bill Pay and Services.


If you are not enrolled at Web Banking, please enter your SSN as Username,
and account number as Password.

SERVICE: Flagstar Corp with Bill Pay
EXPIRATION: August 18, 2006

Thank you sincerely,

Anthony Lamoureux
Customer Service

=========================================
IMPORTANT CUSTOMER SUPPORT INFORMATION
=========================================
Document Reference: (84295618).
© 2006 Flagstar Corp, All Rights Reserved. Member FDIC, Equal Housing Lender.
*Please do not reply to this message. For any inquires, contact Customer Service. From owner-ccamp@ops.ietf.org Wed Aug 30 15:57:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWBh-0002hM-AI for ccamp-archive@ietf.org; Wed, 30 Aug 2006 15:57:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWBf-0000YO-Vj for ccamp-archive@ietf.org; Wed, 30 Aug 2006 15:57:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GIW4c-00039P-Fy for ccamp-data@psg.com; Wed, 30 Aug 2006 19:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GIW4b-00038p-QE for ccamp@ops.ietf.org; Wed, 30 Aug 2006 19:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3971E3290D; Wed, 30 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GIW4Y-0003hM-3h; Wed, 30 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Message-Id: Date: Wed, 30 Aug 2006 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --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 Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) Author(s) : J. Vasseur Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Pages : 21 Date : 2006-8-30 This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-30143516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-30143516.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Aug 30 15:57:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWBi-0002hn-Sn for ccamp-archive@ietf.org; Wed, 30 Aug 2006 15:57:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWBh-0000YZ-HU for ccamp-archive@ietf.org; Wed, 30 Aug 2006 15:57:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GIW4b-00038r-H8 for ccamp-data@psg.com; Wed, 30 Aug 2006 19:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.24.138] (helo=ns3.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GIW4Z-00037n-KA for ccamp@ops.ietf.org; Wed, 30 Aug 2006 19:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8D20017628; Wed, 30 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GIW4Y-0003hP-4U; Wed, 30 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Message-Id: Date: Wed, 30 Aug 2006 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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 Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Pages : 21 Date : 2006-8-30 This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-30143531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-30143531.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Aug 31 10:47:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInpj-0001nE-Vl for ccamp-archive@ietf.org; Thu, 31 Aug 2006 10:47:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIlcG-0006rN-5X for ccamp-archive@ietf.org; Thu, 31 Aug 2006 08:25:52 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIksR-0003pA-W6 for ccamp-archive@ietf.org; Thu, 31 Aug 2006 07:38:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GIklA-000MHn-BD for ccamp-data@psg.com; Thu, 31 Aug 2006 11:31:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GIkl8-000MHT-V1 for ccamp@ops.ietf.org; Thu, 31 Aug 2006 11:30:59 +0000 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 31 Aug 2006 07:30:39 -0400 X-IronPort-AV: i="4.08,193,1154923200"; d="scan'208,217"; a="99957294:sNHT52638580424" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7VBUaOE030166 for ; Thu, 31 Aug 2006 07:30:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7VBUadM024984 for ; Thu, 31 Aug 2006 07:30:36 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 07:30:36 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 07:30:35 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: ccamp@ops.ietf.org Message-Id: <606BAE85-3B96-4EBF-A5EE-9EFA32509597@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-43-475489015 References: From: JP Vasseur Subject: Fwd: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Date: Thu, 31 Aug 2006 07:30:31 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 31 Aug 2006 11:30:35.0192 (UTC) FILETIME=[E02D4B80:01C6CCF0] DKIM-Signature: a=rsa-sha1; q=dns; l=19321; t=1157023836; x=1157887836; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Fwd=3A=20I-D=20ACTION=3Adraft-ietf-ccamp-inter-domain-pd-path-comp-03.tx t=20 |To:ccamp@ops.ietf.org; X=v=3Dcisco.com=3B=20h=3DppafsOedZh8Ukv6Ogz/S//MXSrA=3D; b=MC6miY7qCsVamHI/xtA4CcJcBUypUFvMM0OM1oBTEoWbQ25+vz+k34xmUeTPaknn1dyairBt CGAMS+5TI+MlKjSWAwr5O0alv49J3vQq/cm5wdlZwMY6b9209sfhNHnW; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec --Apple-Mail-43-475489015 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed simple refresh. No change. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: August 30, 2006 3:50:02 PM EDT > To: i-d-announce@ietf.org > Cc: ccamp@ops.ietf.org > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement > Plane Working Group of the IETF. > > Title : A Per-domain path computation method for establishing > Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) > Author(s) : J. Vasseur > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt > Pages : 21 > Date : 2006-8-30 > > This document specifies a per-domain path computation technique for > establishing inter-domain Traffic Engineering (TE) Multiprotocol > Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched > Paths (LSPs). In this document a domain refers to a collection of > network elements within a common sphere of address management or path > computational responsibility such as IGP areas and Autonomous > Systems. Per-domain computation applies where the full path of an > inter-domain TE LSP cannot be or is not determined at the ingress > node of the TE LSP, and is not signaled across domain boundaries. > This is most likely to arise owing to TE visibility limitations. The > signaling message indicates the destination and nodes up to the next > domain boundary. It may also indicate further domain boundaries or > domain identifiers. The path through each domain, possibly including > the choice of exit point from the domain, must be determined within > the domain. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain- > pd-path-comp-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path- > comp-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-8-30143516.I-D@ietf.org> --Apple-Mail-43-475489015 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 simple refresh. No = change.

JP.

Begin = forwarded message:

Date: August 30, 2006 3:50:02 PM = EDT
To: i-d-announce@ietf.orgSubject: = I-D = ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt=A0

A New = Internet-Draft is available from the on-line Internet-Drafts=A0
This draft is a work item of the = Common Control and Measurement Plane Working Group of the = IETF.

Title : A Per-domain path computation = method for establishing Inter-domain Traffic Engineering (TE) Label = Switched Paths (LSPs)
= Author(s) = : J. Vasseur
= Filename = : draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
Pages : 21
Date : = 2006-8-30

=

This = document specifies a per-domain path computation technique for
establishing inter-domain Traffic Engineering (TE) = Multiprotocol
Label Switching (MPLS) and = Generalized MPLS (GMPLS) Label Switched
Paths = (LSPs).=A0 In this document = a domain refers to a collection of
network = elements within a common sphere of address management or path
computational responsibility such as IGP areas and = Autonomous
Systems.=A0 Per-domain computation = applies where the full path of an
inter-domain = TE LSP cannot be or is not determined at the ingress
node of the TE LSP, and is not signaled across = domain boundaries.
This is most likely to = arise owing to TE visibility limitations.=A0 The
signaling message indicates the destination and = nodes up to the next
domain boundary.=A0 It may also indicate further = domain boundaries or
domain identifiers.=A0 The path through each domain, = possibly including
the choice of exit point = from the domain, must be determined within
the = domain.

A URL for this Internet-Draft is:

To remove yourself from the I-D = Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".

A list = of Internet-Drafts directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".
=


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

= --Apple-Mail-43-475489015-- From ffmgj@flcities.com Thu Aug 31 11:39:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIodU-0005OO-BC for ccamp-archive@ietf.org; Thu, 31 Aug 2006 11:39:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GInPB-0001ZV-3e for ccamp-archive@ietf.org; Thu, 31 Aug 2006 10:20:29 -0400 Received: from [200.32.92.3] (helo=[200.32.92.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GInFz-0000eJ-Cq for ccamp-archive@ietf.org; Thu, 31 Aug 2006 10:11:04 -0400 Message-ID: <000d01c6cd42$626416a0$035c20c8@Claudio> From: "until declined" To: ccamp-archive@ietf.org Subject: legendary reign years ago. Date: Thu, 31 Aug 2006 23:14:02 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6CD53.25ECE6A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.5 (+) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f ------=_NextPart_000_0009_01C6CD53.25ECE6A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6CD53.25ECE6A0" ------=_NextPart_001_000A_01C6CD53.25ECE6A0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable admire effort few projects target various genres focus making genre. = generic programs betray collect Find once noting issue finance schools roads bridges levee repairs housing opined: = down payment borrowed panacea predicted being. Sen. Tom certain GOP = nominee protected rightwing backlash earlier supported proposals voted = Snow: former Fox News brash opinions used label W. somewhat likely brief = oncamera Friday. CBS Mike Wallace turns becomes emeritus month retire. = incoming White House press secretary interview until declined Wallaces = requests About News: Bill OReilly worst five among coveted audience news = viewers Is Headline Week: Gore Might Yet Join Street Journal. months = opening Truth touched buzz reprise ultimate Angry EyeLogin Stuff Sports Path: Stuff: Sports: Main Isp Animals = Business Computers Education Teaching Fonts Food Drink Graphics Health = Beauty Home Legal Music Programs Ringtones Tickets Newest Additions = Other Resources Copyright Rights Reserved NOTICE: collect Find Privacy = Policy Editor: Paul Grimes Fisheries Oceans president Honorable Geoff Regan animal right firm = believer together try change others.As mistake beliefs woman. tried = fight herself. pick calling cab night binge drinking homeless children = feed whole week price single glass whisky. Her response thingsAm = Honestly no. displayed Daily prizes allocated for: Awards Sites. Batch Cheats. forum = Chat. Where Start Below inolved designing Everyones Design site: = advantage Freeolas hosting directory receive website promotion pages = youll also AND extra popular enough youre great traffic Visit Games = Cheats: computer Browse nearly formats Xbox PS Sony PSP Nintendo DS = classic formats. Theres cost higher winning. already then Enter site. = huge indepth solutions wanting share knowledge example. told would wouldnt their feelings give whether have sex year = two ago laugh your mock you. But done strike anger reason really meant = stroke sadly. come whenmy sympathy others will turn into apathy ignore = maybe that there is point getting sense about them and anything. Wouldnt = erasing part of ourselves want matter what. cherish good times just like = bad learn from them. After think better way know jackshit myself. Well = course girls withshort hair but never went oneIt seems every day finding = something new Learning was evil too slap face. always though could hurt = leastdont care elses happiness if for didnt mean much me. Sex example. = told would wouldnt their feelings politic playing. Masons ass. burn closing smaller fear takes took pains = regrets breaking taking One step grain sand brand healthy cellat away. = time. gives up.A happened does bothering being wrong becamethe wisest = guy started missing When home before better. kiss goodbye too. There = touch ------=_NextPart_001_000A_01C6CD53.25ECE6A0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
admire effort few projects target = various genres focus making genre. generic programs betray
collect Find
once
3D""
noting issue finance schools roads bridges levee repairs = housing opined: down payment borrowed panacea predicted being. Sen. Tom = certain GOP nominee protected rightwing backlash earlier supported = proposals voted Snow: former Fox News brash opinions used label W. = somewhat likely brief oncamera Friday. CBS Mike Wallace turns becomes = emeritus month retire. incoming White House press secretary interview = until declined Wallaces requests About News: Bill OReilly worst five = among coveted audience news viewers Is Headline Week: Gore Might Yet = Join Street Journal. months opening Truth touched buzz reprise = ultimate
Angry EyeLogin Stuff Sports Path: Stuff: Sports: Main Isp = Animals Business Computers Education Teaching Fonts Food Drink Graphics = Health Beauty Home Legal Music Programs Ringtones Tickets Newest = Additions Other Resources Copyright Rights Reserved NOTICE: collect Find = Privacy Policy Editor: Paul Grimes
Fisheries Oceans president Honorable Geoff Regan animal right = firm believer together try change others.As mistake beliefs woman. tried = fight herself. pick calling cab night binge drinking homeless children = feed whole week price single glass whisky. Her response thingsAm = Honestly no.
displayed Daily prizes allocated for: Awards Sites. Batch = Cheats. forum Chat. Where Start Below inolved designing Everyones Design = site: advantage Freeolas hosting directory receive website promotion = pages youll also AND extra popular enough youre great traffic Visit = Games Cheats: computer Browse nearly formats Xbox PS Sony PSP Nintendo = DS classic formats. Theres cost higher winning. already then Enter site. = huge indepth solutions wanting share knowledge
example. told would wouldnt their feelings give whether have = sex year two ago laugh your mock you. But done strike anger reason = really meant stroke sadly. come whenmy sympathy others will turn into = apathy ignore maybe
that there is point getting sense about them and anything. = Wouldnt erasing part of ourselves want matter what. cherish good times = just like bad learn from them. After think better way know jackshit = myself. Well course girls withshort hair but never went oneIt seems = every day finding something new Learning was evil too slap face. always = though could hurt leastdont care elses happiness if for didnt mean much = me. Sex example. told would wouldnt their feelings
politic playing. Masons ass. burn closing smaller fear takes = took pains regrets breaking taking One step grain sand brand healthy = cellat away. time. gives up.A happened does bothering being wrong = becamethe wisest guy started missing When home before better. kiss = goodbye too. There touch
------=_NextPart_001_000A_01C6CD53.25ECE6A0-- ------=_NextPart_000_0009_01C6CD53.25ECE6A0 Content-Type: image/gif; name="Nintendo.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6cd42$626416a0$035c20c8@Claudio> R0lGODlhsAEYA4cAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAZAAAALAAAAACwARgDBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWEDi5q3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868ufPn0KNLn069uvXr2A2LyJ59O/fr3r/+ix9PvrxweObTq1/PXjmn9vDjy59Pv779 +/jz69//1wr//wAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycghiji iCSWaOKJKKao4oostujiizDGKOOMNNZo44045qjjjjz26OOPnB0D5JBEFmnkkUgmqeSSTDbp 5JNQRillijVMaeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy26eabcMYp55x0AqdKnXjm qeeefPbp55+ABirooIQWauihiCaq6KKMNuroo5BGKumklFZq6aWYTtlCpkblwemnoIYq6qik lmrqqaimWiYfqrbq6qv/sMYq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvs s9BGK+201Fbr5DjWZqvtttyeBEG34IYrbqwZIFvusecam26x6xLbrk9dYLXFiO/+FG+f9QJ1 r575BrVvnf0K1cW/cQY8rmXlIJvwsQsf7PDDEEcs8cT2sUHxxanNQtg8ynKcrMfIgnysyBiX bPLJKKes8sost+zyyzDHLPPMNNccWxA257zbJjr37PPPQAct9NBEF2300Ug/qIOySyfbdNJQ Ry311FQPl1HVWGet9dZcd+3112CHLbbNUSRbNrJnH5u2sWuPve0Kbsct99x012333Xjnrffe /nz37fffgAcu+OCEF2744YgnrvjijDfu+ONGIQH55JRXbvnlmGeu+eacd+7556CHLvropJdu +umou4Zz6qy37vrrsMcu++wUPqCs7cnijqzux/JO++/ABy/88MQXD6gRxif/Gj3KN+/889BH L/301FcP6h+mS5Gs9tZ37/334Icv/nWAjG/++einr/767Lfv/vvwDwt3/PTXr/MY9uev//78 9+///wAMoAAHSMACGvCACEygAhfIwAaahFUVupoDJ0jBygWjghjMYEj6ocEOKhB7HgyhCEdI whKqaA0mTKEKVygSbLHwhTCMoQxnSLfy0fCGOMyhDnfIw9hgoYdAywyiEIdIxCIa8YhITKIS l8jEJjrxiVCMYmfAIcUqWvGKWMyiFrfIxS568YtgJJ0FwkjGMprxjGhMoxrXyMY2uvGN6QkA HOdIxzra8Y54zKMeASeHPfrxj4AMpCAHSchCGvKQiEykIhHij0U68pGQjKQkJ0nJSlrykpgs 4TYyyclOevKTkaQFKEdJylKSKAam9BEGUsnKVrrylbCMpSxneT5+OAuFtMylLsPyhV368pfA DKYwh3kZGxLzmMhMpjKXycwT+aGZ0IwmzQICACH5BAAQAAAALAAAAACwARgDBwj+AP8JHEiw oMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmz ps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2 rNmzaNOqXcu2J7m2cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiGtWSMy48cXFjiNLbgh5 suXLAytj3hxZM+fPiD2DHj1YNOnTfk2jXp1XNevXsGPLnk27tu3buHPr3s27t+/fwIMLH068 uPHjyJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/vFIB7AOzZv4cf Xz39+vjz69/Pv7///wAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycg hihifmmMaOKJKKaoIkgOrOjiizDGKOOMNNYYXT825qgjUrns6OOPQAYp5JBEFmnkkUgmqeSS TDbp5JNQRinllFRWaeWVWGap5ZZcdunll2CG+aQCYpZp5plopqnmmmy26eabcMYp55x01mnn nXjmqeeeUD7B55+ABirooIQWauihiCaq6KKMNuroo5BG6qYGklZq6aWYZqrpppx26umnoIYq 6qik1uRCqaimSicDqrbq6qv/sMYq66y01mrrrbfSg2tJuu46Uq++hgRssB8NS2xHxh67UbLK ZsQspq/k9CxpjjRr7bXYZqvttg22wu234IYr7rjklmvuueimq66Mhazr7rvwxgunCfIeRG+9 Bd2L70D67vtPv/sCjK8JAvtr8MEIJ6zwwgw37PDDEEcs8cQUV2zxxRhnrPHGTJrB8ccghyzy yCSXbPLJKKes8sost+zyyzDHLPPMNCe6Qc04LzdIzjz37PPPQAct9NBEF00TjkZrJUjSTDft 9NNQRy311FRXbfXVWF/ZRYBGZO3112CHLfbYZJdt9tlop6322my37fbbcMct99x012333Xjn rffe/hmWwfffgAcu+OCEF2744Ygnrvjio2HB+OOQRy755DNPMJsxlDNKgsGb+9u5iBTo9vmI oR9cusGn+5v6vqvjS0Hrmccu++y012777Y+SgfvuvPfu++/ABy/88MQXb/zxyCev/PLMN+/8 89BHL/301N9+TfXYZ6/99ut5wv334Icv/vjkl2/++einr/767Lfv/vvwxy///PTXb//9+Oev P4i87O///90pAABHlocBGvCACEygAhfIwAY6MDoeeKAEJ9iqERjMgv7C4L40iC8O1suDFAyh CEMShBGa8IR3wRwKV8jCFrrwhTCMoQxnSMMa2vCGOPxSBwy2Q3/1cF8/9syhEIdIxCJ6BAZG BBkXksjEJjrxiY2aFhSnmJ7RUfGK+4EdFrcoMWe0KhAw8aLBxOgvMu7LjFxMoxopMow1KucA boyjHOdIxzra8Y54zGPQmqHHPvrxj4AMpCAHSchCGvKQiEykIhfJyEY68pGQjKQkJ0nJSlpS cOG4pCY3yclOevKToAylKEdJylKa8pSoTKUqV8nKVrrylbCMpSxnScta2vKWuMylLnfJy176 8pfAFBAsgknMYhrzmMhMpjKXycxmOjNPZ3imNKdJzWrm6RfWzOZ2sKnNbnrzm+AMpzjHSc7p LK2c6EynOtfJTgNSoZ3w9E1AAAAh+QQADQAAACwAAAAAsAEYAwcI/gD/CRxIsKDBgwgTKlzI sKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkS5OqlzJsqXLlzBjypxJs6ZNiUpu6tzJ s6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DD6glLtqzZs2jTql3L tq3bt3Djyp1Lt65dsNfu6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLHjx5AjS55MubLly5gza97M ubPnz6BDix5NurTp06hTq17NurXr17Bjy55Nu7bt27hz697Nu7fv38CDCx9OvLjx48iTK1/O vLnz59CjS59Ovbr169iza9/Ovbv37+DD/osfT768+fPo04P9od46+/bUf7y3LAm+/fv48+vf z7+///+OpQTggAQWaOCBCCao4IIMNujggxBGKOGEFFZo4YUYZqjhhhx26OGHIIYo4ogklmji iSimqOKKLLbo4oswxijjjCpmQeONOOao44489ujjj0AGKeSQRBZp5JFIJqnkkkw2edkbTkYp 5ZRUVmnllVhmqeWWCGLC5ZdghinmmGSWaSZFe5yp5ppstunmlXO8KeecdNZp55145qnnnnz2 6eefxHkBaFSCDvqUF4UaquiijDbqqHFHPJpUpJIaRWmlRV2KqVCabhpUp576BGqoPY1K6qmo pqrqqqy26uqr/7DGKuustNZq66245qrrrrz26uuvwMq4TrDEFmvsVV8cq+yyzDbr7LPQRivt tNRWa+212Gar7bbcdtsVHt4mBG64CI1LrkHmnqvuuuy26+678MYr77y5eUDvvfjmq+++QU3C 778AByzwwAQXbPDBCCes8MIMN+zwwxBHLLG0Q0xs8cUYZ6zxxhx37PHHIIcs8sgkl2yyvs+c rPLKLLfscqpxvizzzDTXbPPNOOes88489+zzz0AHLfTQRBdt9NFIJ6300kw37fTTUEct9dRU V2311VhnrfXWXHft9ddghy322GSXbfbZaKet9tpst+3223DHLffcdNedoTx2E4tK3v589+33 34AHLvjghBdu+OGIJ6744ow37rhcAzwuojqSV265f1K4m3m7m6/ZyledXy766KSXbvrpqKeu +uqs73xC67DHLvvstL9dSe245667aSnsDqY58ALvrvDtEs+u8esi7/vyzDfv/PPQRy/99NRX b/312Gev/fbcJwhC9+CHL/745JdvvnqRnK/++kVB4K777cLPrvzr0q+u/aaV0CH+5PLP/v/A uQAASzeGARrwgAhMoAIXyMAGOvCBEIygBCdIwQpakGg7uCDLSKDBDnrwgyAMoQhHSMISmrB2 ajihClfIwgRSo4V9SwAMZ0jDGtrweaK4oQ53yMMe+vCHQOAMohD/kY8hGvGISEyiEpfIxCY6 8YlQjKIUpTOKKVoRKoloVyKyyC4udlGLXlRXGMV4xTKa8YxoTKMayaOCNbrxjXBcDN7iSMc6 2vGOeMyjHvfIxz768Y+ADKQgB0nIQhrykIhMZFisoMhGOrKP8HikJCdJyUpa8pKYzKQmN8nJ Tnryk6AMpShHScpSmvKUhjQAKlfJyla68pWm4QNi/gDLWtrylrjMpS53ycte+vKXOhMGMIdJ zGIa0yRpWJq92rVMZrqrmeyCprqkeS5qVvOZF0nTMbfJzW4C0xfeHGRAAAAh+QQAmt8AACwA AAAAsAEYAwcI/gD/CRxIsKDBgwgTKlxoEAnDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJ kygNlkrJsqXLlzBjypxJs6ZNhuBy6hSosydBcAN75vw5FGjQojt3/vPJc2hTo0uRShVKFarS qFWNJsV69edRrU5vih1LtmxEp2itHiXatG3UgmmDug17FepctXTf6sUqdy/QuHrDuh1s16zh w4hrAha8tjHgpXDB8hwcuDJby4zpasVcOK9fu4I9Jx5NunTJxX+9ar5bmO3WvZwhR+Yr2art yW9rf51NGHZR08CDC8co9Cvoz5m7rn0denNug1JlM/2M+zdXoqt7N5c9vLv375fj/oKu+7e1 8uepfTvnOzu1bsLrlVrHDt84b/D485tGDddx+b6w+dfYXJfxlt2AaIXXmYAEUsaYfhBGKBZ/ k90WmGQB3qUggBleiKCHuGlYIYaPWUiZhCim+BJVT1XFlU9bnSeifU95BR2JWU3XVXnF8dii ZjyC9aCKRBZp5JFIJqnkkkw26eSTUEYp5ZRUVmnllVhmqeWWXHbp5ZdghinmmGSWaeaZ3n2g 5poCrfnBP27GqeZAcrbJppxv2jknQXfyOaebcOK5Z6CD0oknn4b+KeigdRIqqKOLJirpm4cW BKiekuoZ6aORTgppnpZmyqZBoAI6KqFwOooqqpRWiumr/4ESueespaYaq6125nqrrYXuqmuv tNJ5K7CgIjqsoX4Kqyuuw+bJ6K7O1npqqdEuW2yzmTJbbaqMbsvrtsFimyyybR5U6LO/egsu pb8q2y25KYaL7rLjhvutpdfOm2654sJr7rW+zjouqevi626+xwZM78DHCkzwwPYWDK21xZ5b 68Pwensvv/r2CjG1skqsLcDiokssviTn2me/CxuM6Lv5sutysBU7q/LBGxsMsMUcy+wyxdbu u2rG0tbMrLDv9vzvwSR7TG/S8V46sb+JQq2xr5ouvbK9LTPMLbXEeiy1qsiCffGfXY/9tM2x Nl1znEGTXTXRSBvdNLRnu62s3P5dD31uyEKPvHS/Vzs9dNncBt73wlIrmuzOrSIuedt7j0qr 45DXmy3DSZscOcpAZ+313HFf/vnRp2L9sbFRB240xhEH/SzIsNM++8Wckxtxyo6n/frehF/t r8O+rz5177juzm/Ad7seusnDp4x3kvLirnrJeatcLde627698H+7rm6946+NtPGxkw+80zw7 j73Q87YfqvvvK808qctPH/XY/Kf+qZ+mWxS7/Nc9TQlQbZe606EOODcBEu1R67NcowAINtaR zlQSNB2rVjVBBWoQgGRDYOoadzi1+U2CaEqhClfIwha68IUwjKEMZ0jDGtrwhjjMoQ53yEPh wKGHQP4MohCHCCEBGPGISDTiP5J4RIE0UQAEQaITlQjFg1TRilRcYhKnyMQuXvGJBfliE8PI xIF0UYte5OIS0bhFLopRigh5oxy9WMU0unGMbDRjGw0CRj1C8Y9nROMaiejEKRZSiYbUYiIR qcdFXjGKj4SkIydZxzoqcpKNzCQfK/nFRA6SkYA0ZCULeUlQjnKTkkzlGhGZxVKq8pSm9GQm Y6lIWJYykoRk5CVv6clIsrKTqAwmKX8pS10S04yq3CUZD2nJXZ5Sk480ZjRhiUtl6lKZvNRk Mq1JzWUi05rJBCUhvdlLalbzludcJS6viUlpppKdzNTmO0U5S3qqUZjcxP9kFJ3pyz/OcppY HGQ+sylPWZJTkOPEZyBNyU6GVjOUB/UjQLV5TD7yM47NbGUtJQrJa7rzn/BUpzzhmMeIupGi nHyoShPiUTwmdKAEvedIG+pSg4pSjOF8JhlpGcw3NhKn6/xoMUcJT5K2VKBU7GdAcfpPbKIT okZVaTqDKNRjMrWeBr2qTWup1Y8WtamkXGROt9nViVJynWAVqSSPis+BJlWYFRUqUqcKxKp2 E5tW9WVBxZlNufK0mX2dqFlhCtXBErSiYc2rM2Na1KCW06Zx1alX6cpDOEoxjYDsZxZr+sSa lvSyZfwsHi2bVDpK1KVmPWNmO6pZOSJUkHSMbWf+U7rToDr0tRxlrW6ZSdmX+va3wA2ucIdL 3OIa97jITa5yl8vc5jr3udCNrnSnS93qWve62M2udrfL3e5697vgDa94x0ve8pr3vOhNr3rX y972uve98I2vfOdL3/ra9774za+KpMDff0ghJvz9r0AC3BICC3ggByYwggPMYAX7t78D7u+B H9zgCk94wAtOMIQNXJALU9i/FLYwhEOc4RJ/2MMgjvCICeJgijA4ww0uMYpPzGIJh/jFNIax hA2M47JseMYocTCQRfLjGtdYwwL+cYIXHGEWNxnERWayiVMc5SdL2cYPxvCIqyzkJ68Yw16e cJKHrJAojxnMVTZylsP+TOUkr/nLRd4ygn0sZpn8d8MsWbGY94xkL7/Zyinu8J4Brec/rznQ h070oK+86Du7+dAXTrOcEx0RPS+a0AYptKLVbOVInxnPTh7Ll1Ws4h3f2MQxPnGdszzmVpua 1IAu84wdDWMon7nNuF6IpTsN6Sa3OtOQBvKuFf1oLLdYysQmcY8VnGpCX5rSbM60sPmMkDjf Wdqi9vCrTc1tWlvb1x0G97a9Te5YJ2TUWl6yjc0Mbmhju9ZOnjSWSTznLU9bzcP+NLyRne9P l5vVnE42svGNYnTHusc6LvW7bzLqcbP63x9+eLvnDOuId/vUE1Gyq+t9bXbDWuMLl/i++3z/ 5JHfm9H4nnLFg01wXzua2dp+9rDPvXGQmzviAxd5zmnScFpL/OK2dvnOG/3mchv8IfYG859h 7meU33zXkzZ006WeZkG3/Mopd/bAzQxxc89c4DR3OtgDDWdPaz3bHC/6z43u76Eb2eFAvzXS b61hNNP90Z2We8A9LnW1U73uSgc7l6/+dS63HdTornrZKZ50lo/925RuvLt5LmQlP7zZIsa5 p1ed+R2/fOeytryFL595iitc2iCv8I01/XlV29vSNqc3zqk8e2fDnsetR/i+T2/yI2+ez+q2 9utf7nMIHb3M+SUzmJQvnOMf5NrJTyHzg6N7XU9fv9jPvva3z/3u/nv/++APf3c5XOmjkx8i xxb09Q0SgPb/IwAEaT/85y//+gtE/u8XP5MGzxCDV73/ZOZ8CeF+7wd/92eA7oeACFiAB6h/ SxJ1zOd/SyYRzieAB0GA99eAA2GAGtiBHOiAR9JiL1Z5/kZtMqZ6sVd5N4cQGBh/H1gQLYh/ ILh/Knhx+oZ6dXd4bOd3FtiBLjiAL2h/N7QL3MV0QMd7qNduNriDk7cQBGh/TyiDDMh+LTiD RAJ4S/h2kcZvObiDDkcRGBiFG/iBMTiGVhiCd7d2uLZ4jqeGWeh3ECGGGhiDZKiAZ2gkred6 jJaHthZp1KBqykZyI7h+BViFQniAYViI/3cIQ4S4iOEFfY74Xj0YiZRYiZZ4iZiYiZq4iZx4 XrjHhyqXcZNYcqB4EelHggU3iMpXfaJoeSu3hb5nfY1YcuiXfrSIbbPIQvz3fLm4grIWbRnx apxmi3K3inrnYt+2bWTHiwA4iiH3i004eaDGQ3zHjKZIiKzXi1r4bicXddX2bBRodXFHe9Z4 br44d+gIeivojTrkeW2GZMRHchYHc7/2dXuIapKnc3todnlXfbdHbq4Gj0KnjG4WcxiHg2wn j+54bFC3bJ8njM6oiw/phjr4cxQ5cU/nhSLXkNyIcJLXdcm2bj43bzH2hh0HZVanj4znbRcJ cC65dW2ndhMYjf8ztG59GHcA6Y46Z4QpKY4AWWqzVnw5N3NyJoxaJ5JMx4xviJJMiXINx2RI 6Xk2d4qNNpI3SHbaiCZct41qSIoj2Yagh5NCqZQGGW5cmHZsOJCRJ2wtyXiIJpOwCJV6t3iu CJNCB5YB145pGHTJWJAXmY/8NpAd95UhWXxx1pNFOZZw6HF0KZibpmUpaZT09oWEyW3QZniL CXg0WZPFOHyqOI/wGI+mp341V5cqSIupl3gCKXukOYyxN3skGGqjuXp5mGoQ+Xqkpnq8iJuj p3T/R15ZaWdhR0izll6Q2HzfSETHOZvlFZGjwYp62YnSOZ3UWZ3WeZ3YmZ1kYou1J4v/zVZg Erhy2oki0DmKdLcR2DiWRhic42kWx6iO1ucR6Rl5XNmeKdJzrshjIUePUpl7+gmAxAZ59kme uPhv8+aacMmEv1mg2yiZA5ofqRhsV5mXSdltSVl+hamSDwoe1EaQmtmTQSehBzefHOmgG+od ureU4XmX09h0C+qTf8mexEUEvvWdQHmQqeiZqmiaJrqbYSaPJyol7KmbQdpDy2kRq1ak1Cij rKmkTvqkUBqlUjqlVFql0nV+JUGk0MgRTJqXocedVpqcm2mKkcmWY1qLIWGe7xmm5fiW8lmm 5ggSzimna8qmIJqb8ViSGrdxTsefnxiaTWiYIlaboqen3Sl8/5d3pg+qmjKZqJBXdkm3lS1p fnDpckbnkpYpmZhnlW4apYyKmRj3hXKJmml4hF/KogEJmqMqmoTHqV0qnZ/amSMKh3cZoltZ l8j3o2L3cckojaX6oVUqb5wabTHJhjjJZge6jlDZkZApksSKd8+Kl8Eqgp1Hj3hKqAu5oyjY m6qZp5/Iq78WiKGopZhnp/ihpbUInTxnrucqm5XmrjZxpOzafGDqnXTWJAcwr/q6r/zar/76 rwAbsAI7sARbsAZ7sAibsAq7sAzbsA77sBAbsTdUDxJbsRZ7sRibsRprsPzQsf/ADwTRsSAL sh8rsiIrECYbsh6rsiSLsgVxsiU7sv8mS7IpOxAwa7Mr67Ivm7M1G7M5axAti7Ite7I8W7RG K7Qyi7ND67Eym7I3i7Q+y7RL27Q127PqtbQ2i7M6S7Mfm7Uqu7MvC7Req7NdO7Rg+7UhexBm O7ZrK7Zhy7ZpS7ZdK7dtO7d2u7Jr+7MlC7d2O7dcW7Zjm15B67dvG7iDm7ZmG7Qj+7aD27gJ sbguq7h9u7VuW7dZ27hty7NyS7lsm7eMK7aJG7hCK7qS+16Hu7luK7qXu7qs27pea7mtC7mR W7m0i7qAi7hkC7l/G7ele7u7+7mzG7yEG7yOG7eqO16Ky7Qsa7xa+7m/+7yna7V6S7jPu7m/ u7VPy7va67n/1zu8uUu8CNGzXLu74iu8qDu951W8xXu8kzu+dPu0svu6qUu50Ku33fu3p+uz 2yu/90u3/Gu73uu+d/u9t8u++Ute6lu4AJzA5Gu813vADEzA/ju5wxu9Dty8d9u/fZu5D3y+ 4OvBo8u8Ioxevdu7E9y+fLvBKbzBlpu5hiu8Jay6MbzCdVvDLyzBkuvC/mvCKgzA5mW1+ru8 SIu5+Cu1NGvEUDuzVLuzRdy0SUzEU4vBMEu0mhuzhpu94lvFUDvESOy3RkzFNWy0sLuxZFzG ZnzGaJzGaqzGC7DGYxIFBNHGbmwmcjzHZFLHdpzHerzHfNzHfvzHgBzIgjzIhFzI/4Z8yIic yIq8yIzcyI78yJAcyZIMXCUwyZZ8yZicyZq8yZzsEr/QyaAcyqLMJABQyv8AABRhygaRBAlR yq7syimhyhbxyiFByx0BywZBy7Z8EbKsELCMyrXcy7+lysL8EMUsEKx8EMBMzCaxzMDMy8+c ygtxzBlBzbIczdDMEMSMzb48EdRMSL3MzRmRzAjxzSAhzrOMzsY8zeqczcq8zCxxzRHRzu8s XMeMy6+Mytusz7ucz7n8zP6Mz/28zwPxy/nszAh9zcJsyv4sELhcELpczAtN0Aw90An9z6cM 0fus0Nhs0A9d0BPNzwJd0QnNzw790CNtzjIk0SZ9yia9zf8n7dIyfc/RTNIyPdMvjdMzHdM6 DdMVndEE4dM5Xc8/HdQ13dJF/dMMHdMhfdQ3rdQtDdJMzc22DNVP/dLO3NNYfdVArUMbfdJZ ndRhjdXkLNVmDdZT7dJHHdVcLdY4TdVjfdPlvNVG/c9xrdV1PdFy3dBWrdc6/c4ibdVvLdR4 zdf0PEMK7dBtjdR3/dF1fdaMfdXwXNQ8Ldhi3dFxbc6CDdkZTdh4LdV+DdN5TddmTdmKndag fdepXdiYHUSE/dpZ3dPs/NhuvdR9rc+VTddKLde5Ldt6bdqSHdmwDdTAndjMzNoajdqljdR/ ndRpfdunrdI1ZNEBHdgHrdYNbdT/X43dEU3dUX3QIo3W163d3c3V2q3WGl3dKV3eFM3RgY3e 6O3R6V3eBQ3f8G3R9w3VlJ3S1zXe+SXd81XT2AfgAe7Y9rXLo5zgCr7gDN7g4NXdh00S/p3K 8i0RBA7SJB3haA3WmA3QHD3fNq2J8kwToq3Ms33aFq7hj83bxuzhrQ3doc3Wl3jcJB7bJu7L AI0SiZ3iKJ7cMN7af52JS33e3I3hdr3h1Y3Rks3h9k3bSM7eBF3kyZ3bLq7kCI7cxd3Y7Z3f FU4TWIBcCF7bpL3TYs7ihr3YLL7TzR3ema3aHG7Qsj3l2Y3lMn7mtb3m8T3g313VWx3OHo7m MS7lH+7j/29O5avt2ZBd5QZu5k7941Oe6GEt6AidfaL922Nu3G0u53U+2eK845D+3G6+15y+ 4Ste34fe50Be2qLO05+uX5ge3aju28K96aid6Ur+1JUN6KH+6rYN10wN6shd6p9t3rEt4/UF 4Vwe35Ve5cpu3/6N0hnu60aO3Vwe3sru4u8N3nAd4ktO6o5N3VLe1fy96A5u6rFc7huh4une 1ehOGhfe7vAe7/I+7/Re7/Z+7/ie7/q+7/y+sZ6QIrHQ7wI/8ARf8O9lDwaf8Aq/8Azf8A7/ 8BAf8RI/8RRf8RZ/8Rif8Rq/8Rzf8R7/8SB/QzIQ8hcx8iRfESYfEXZw8v+Q8v8sHxEun/FX oBEx//IMUfM2rxA4n/M83/M+//NAz65XTu3eru12zexNDth8HuK/zN3uPd5NL97nDeFG7/QX ru7pPe2ArfXfrs5dTuHt/M1sbtNRjxGabezdwdKsjtK9vdxcP81tP+LL7u1rT+w23vadXew2 jtvrXBE5nuO5XN9/b+rSDc/VHPhBXc7mDvgCfvjdzO7f4de5ftw77ueKTeP1bPeEz/ijTtyp vveaDutxT9XaDPnSDPitLO6qb/omjvWKD9Gwj/goPvixz8twz/rDIfm4ruaV79Sej/urbt6e D+SRruZJT+5v/fua7/upr+WavfrNL/jSr9Jqv+akT+T/i9744t7pcz3aZD7p0Z38wqH7lM/3 ve/kxn/r2T3iRL/7Qx7mHz30ya/3fm753cz4xP347X/jtJ/3PR74AAHg38B/AgsOBCBQIUGD DAk6PBjxoUSJDRdObDgR4UODFxMetLgxYkeNJU2eRJlSpcaPHDO2tAgzJsKXJGlmxDizYMeQ LnmK3PkTZ9CcQz8u/LlTKU2KR53yTGgzqUmjKHuCdBgyKtGRDLd2vQoUok2MHCF2NVvy68aj Ii+iJTl05Vy6dVlqrSlWplemfJsqfLp06V63fmG67Hv2cGLEgve2FOyX6li2KclCZllZM1ax mQunfYuzp1S1aSuepUgZNOXR/kAx24UdWyVhwn/7Yq6dl6rO3LeT6oYM2Ddjw7x/j5Z7k2tU 5mSDOm18U2ZM6lafAsaudK102ltfFvWKPa7o7VKhf23uXPZ69uGZuw9vNv3d4LitP8e9Njt+ ++mRBufqLt/m88+75OgKC8H2FmRQQdgSbHCyCCeksMLYDrQww/YwRPC1uTjUMETL7IIwQw9F RDFF9kBUsUXTXIQxRhlnpLFGG2/EMUcdd+SxRx9/BDJIIYckskgjj0QySSWXZLJJJ5+EMkop p6SySiuvxDJLLbfkcjYQT3RNvRXzA1PClfwTkUW1yhyxOdQkA49NEvUz0M0Ad1OuLjVz6tLB Ec+k/vCyNyMkrcI9rZLtKg7lKhTQk1rTLK7OSpvUURL7/NDSPwktq8VDH2TwU70G7bTUSs30 7EVT91wM1EujNFC7WB177b3AmJpuMKFuzbO8NXEV7jyoquJLOFmHU25W9IytFdg8V80q2PGg zQ2q21LD9k01kSpWWsf4PPbOJrWKlFvOvitM0qw+c6vR01Krrl3t5PWIUjiFwrbe05DjrNS2 xPwLwHn7Ne3fSNlVjE4IWTRXXXNJxRdgJcltCyzvOqtY38MKRW/dgjEGbTGO5bU3TI6tFc1j uIhrDUN0VxvpQNJs7Zix717OtqaUdf3XowRr1vdJSFuGWb6D00UaLZZV/vt45JUJTvWzRuvd ud+p/d2sZGJn7pRrbVWFtKmiH2Ua4bBGlnhigVHe773EaB6QP/H0W9Na8LgTlkA7fYpP7ufg W5aoZcWLM+9Rn+XvbzKTbfsxRRfvW9y6TZYaZ7+vwxRIUS0sEcvNM9cU9HE/51xOK0kXveTU V2e9dddfhz12Hl+RvXbbb8c9d9135713338HPnjhhyc+RdMHU1GnC49HPkTUH3zexrmhs8xt 4xccXPKJM6Xx87Sj3l51HxeV2lJGexQ02yW3rdF7V5lMLnoU2VfVzPN5rEp+GT2cqj5vp6NO xByXPV0FDHHLYdaxagO4XSmQWQqLF+a+1a0C/obLfw+0YAO3c6+yLFA6xZkKsDDoLQRGBoHk EVAGjZIrB3LKaGI72bm6hivVOAwuL1MPv2IYNKXFbGARA5nVrjU2BYYMhkc7zw17CC3E8HBf CIMXEt8ixIG5ZlJTNA8Vk+bDim2oWW672NNCWL53hcZirbJiFMmItg36b42V84wZ37WcGcbs ZMcRGVuAdiqxrcZ6VgRj5MrVqo3V8GP5MpnX+phGdyUKZOjS2BbrmL4jQq1qOTSkGHMGM6ep K45lzOTObAiWrIkya0/T2gzjpzIyHhI1nnRX2BQTRDkeTpPYU9gJp0ezP54QcdXhpbgI2Lc6 FUhWOhtWrIw5H771/6o7e1PmLo9ppzo5MDvCamYueYUfYg5rVYHJVfYgVx7MVZNXdhOnsX50 Ni51zk+Ww5E716O/4qlNZ+1kXvXuib98+qme/wRoQAU6UIIW1KAHRWhCFbpQhjbUobW7x0Ml OlHg9TNU5MFo5DY4pvHFT38kNGH1PmTRkJoqUfyj54RS6qKVaup+QpTnq9CHNZXaElF8JCL3 TLqiNKpPeuuLkW6apjJ6trRBlwyUTcmGU1L5s6kXSpVRsQfUat0NnPiqH1LJpRcSOu6YxQFJ XsIJ0gKysFcVvFXeYlkfq1awm/97IB555qxsjtOtb3WWBMsqLeURqYtQA6UMQ/rSJ24Ghf4G 42LDlMioh1GNUoi9pGJ7OErnjDJhgmWaxiTLLjn+VZZhwiwp6RXJsZDWp5prVwiJ9rdNRm2r WixfIEVLuIqYkmJTpGNoQRnIlGXMbHpsVrraCMjYppa4rQzsIWlry04ad2UoNJJlcTjL+rX2 uLB97iRF+0pVZjKUS1xtdDL7W8AyUn2CQhsSiUreJe42lW+cLWeJ5Ve1ohRn1azrMzVaK2ya E6T+LVyAxIQmvX71nI/FGzkFaeD9ODOA0SznNceaXz5B2KoTPqfeMCbVPnFYdB4+6KdADLoR d7jEBN0onii6Yha32MUvhnGMZTxjGtfYxjfGcY51vOMZMU/E/f4kqSM75KYge+rE4BrT5uZ7 Iw4X+adLdRXDnmoiRzVypvvbEFM3xeTkhQ9VegKzlpPq1CMLOahZnmqOTlxmPFHvMWGNGzZZ 68sqdsyDboZrExu3ZTgPloX9pVNeG9xntop3mi3MMA3x2hg887WFcwbjfzSIzkbTlb+WdrJK g2VEwaYPsnX0YcE2S0Mb3he54Ps0a0r7w8P5Fl5Y9OlhF6vYLFLXlJ3mLKlpqejEUvG1QJRQ qp9snssE0LyhLtqAWTPcsPbs1ZVjk219ZWv47hGwxGZZcElb6ppR2yeKAnUMtRtYWF5X3MQ8 2rDVm+5j43a8iJSkH0HNSTHb9r23pP8saLs7R/Cuu9Qm/Wxvd11cBCstvbkeGneze9rkAZrI cRVhMcdpVhF+NT5p3TDjzno3wQ2aztEUsIbzVd8VuvE6IDc5f+12cYhDWOIZ/bjDu9W45brH 5ZmLafBELDx28riZAk3xr4ZHTjb73OhHR3rSlb50pjfd6U+XEiugPnWqV52iRffSVKmn05uW tOvESWHrgh4qq4f5tIf6HtmheqqcO+lLYjZ72c3usjCD2H1snzKU3s65h2p4VkgW9F7VSUf9 CjqPFH60shaoVsLvE4MXnnTiG1hCyRse8pA3DqErnUGev1Fi9jbkSz27a6dtMYuRtGx8a6vG eVXWsHmF/en+VZ9E2bMekwRXrbl1Tby12ZHmgvthIZcG7Udu+0UJt+QZb2ba2yv/+N997h6R GVtrI9X2wiUkIckNdt5Z/7xXbKV9lIvKd7ve25482CqT23z0Kxzf8Ub/rXHbyICHfty/zrXO 8bvPb4e72yjtOMWRP2NaNL+7qm26IUfLjwBsoz+rL2tiwLGCKwkzoWF6Fm0CIAZjG4Hpnbar Kbkbnx0bu9IBwY7CuhJEwRRUwRVkwRZ0wReEwRiUwRmkwRq0wRvEwRzUwR3kwR70wR8EwiAU wiEkwiI0wiNEwiRUwiVkwnJgwid8CCeEwimUwpNIgCkcwirEwiXUwi30wi8EQyH/uYIwJMMy NMMzRMM0VMM1ZMM2dMM3hMM4lMM5pMM6tMM7xMM81MM95MM+5L1iCpK0WrOWGsHugZPoOJ69 ERBmOsSfow9CiTaZ6TgJc7cj4cAr646GC5SHCUFUoZ9Y66myaS+SUTuwsR9vg7uOSkUsAzz4 8cAegzKGoy4EU7+qOcWjQrV7e62805z5A6B4QbyHCzA00UCzasCV869cujy5QblflJxIa7aI ozRBChyiU55hAhBmczBukjNnAziKc7++aqpMmx8F86qta70RGjzOQ6v/CDyxQrThkDNSe7z+ 4ry/q6HOShrH6iP6c6/Zg6L8SzhIcqKtqZTpOqWz60Va/6lGsmKrczys40AWnkFAlQu5d3S8 evyfbuKOTzK41xsPVyM4TgqjyrK2zAibaUGnD8qqgFyk+pucdZJIPQuXt1HHCtRIZCk0alw+ Z8LIYZzJrcvJYMu/SoK1fmzEWGIvKCq3OWqu74MvJnLK6kq79pkJkckz2rvJS8vEdiS0PqPH dJRHh6y8vcK0IQpG8ZtEmhOqkduVZFocfFTGwDE4ZrLGZzrK/aKtdewlNQPEdNozhtS4Yzy5 AiFGC7RJu9Qbj5tLALsgajqRE6yu21EyXnzDQnQeyfQyndJMP/TMzwTN0BTN0STN0jTN0wQe MYCxMuENSJw+/Aq5jcJMXBoxUf+BnPeBIAjipt0sCkrkyUVZOa6rKOFMM3Cbyp6CpNlIM/GR KTNbRVd6yo/kt/U7P+V8zut8nU/ExcmspaKURcvks8l0qvfBzp95vqgKxVUyT1apyi+rHbgJ tAkTvDuxQPX8mum8SsMxyzuzvPnULwd0K1GCOPQ8z4PUzYR8vZyajNDIylckMVUjGNMKNfPr N0/smhQLLzHaNNEzvrJKtjI6ysjSrVBcJOuiJFC8z++ULMeyRdvxrVrbNu2zvhYtUJeUtyGS rVqrTtYaGhkNJTT6x1t0PxNNz1i0Rf4jGVsJPvBcHX5crXw7xM/iN++rRQ6q0BPdvuvDtQSF Umqju1n/DCLpNE+lQr6uuz2EpExj+8/FtB7GCs5fssgD+iXJkMBD4xuQm8QINJx08hvGcbQS FaY4hUy6gVOY05622rjc+86E6kzr5L3cORAHcChyTJNGFRrKRM1M1dRN5dRO9dRPBdVQRZ++ /DruO9Ss06fpWbBHqdP9iUT6WlA59aLmNLS7Y1Wv8zLCCs9RNNNN8TRe/NX2yUU1K9V1aU+0 c6FiFTJL3U7rclTx9FVl7U6Gyx8uAzgd+VKUXNRVLKpn5altHRJ+0dOzCi5EU1WwpMpLfLU3 BUAVesQSQsd1ldW0NFevFMRV1RpvojyZk0ewkg91nEYC6j0EjC5ma01FEjVW/6tLZ12vAlW2 5Gw9heusTWtJXjU92Cui2vMa+nnK06M1UkTQF/1Q5DG/0kuSkkPOZyPKhUsuqrxWVMws6RtS 5KNRK3PYagOuTipJBcnR1Dq4vYwj+cPR8YI5hD3ZcSssVnq/txFFVMRSKYXJ7kRIf4xKXcTZ 5CO/qmw/k124+SNQ77qapL0lXA1XlVPAq4oMPkWjA0TZxJHV+owwCiRUgZ1HxfwgvnRAvpI5 PB2csWtM45BbdYJN3vTTNqU032RGIK0n7exAIbFV1mFWt2Pc7nPck4pcVxXVzNXczeVcIzyD zt1BSgDd0YWVE5RNKWNJ4tyRcm3EVrwPU107so1d2P9dHtn1opqLSUtkUi3bO+PkzClBXWU1 UirjO+y8qeAFVrRcWd19zr0r1le83DHb1Z36Oqmy3t2tstCRRQ+M3iHTI7C7VztdNHIdo78C K0CjSEa7xoBdoYwdULz93gh0LpbsmbcEUAqilUOzM+javN7bz7h0xzylOGWC13WExd0zNU6b 0agaNatZG4oFtql9IRBtLZ+ZvbyMWPU6U1772clKyC4dPYDsYIVN2HfTratcNfM9YOdjNHQL U2XDPoErrY4F2YjzyTL9V026NcMAyX28PwiVoT/SUTgL2+lLT+mrvq/9P6V12lNb4fajN+mE WfOqUn/zPLKBWF/Du+3bYfv/0+CBo6SbCVkSDVYPfiHL2dqApNlZUj8xtVEYQVsFGxBoRLyZ s7htTLBp4iU51iU3WstJOjkBBtw7JjCiw2PKCaZv4x/jQluWm6u1PMCarLjLiWSWO1xJrjEH Jc/oIl3poVThddxP7uRRJuVSNuVTRuVUVmU6FGUvQVzmnBNYvd2TUt1kHSk9QR1y1OXund00 AdPxLFVeBteC62Xq1V5Y7tVYNF7sRWZgPtouI9Fa/jJhfp7oyVZadU9HveZl5uZuHuZRlUhD ZseVFUd+9Sr6HOChrFXCQd9AqyI6CzwP1cg8g7RqoUDKI9+4yWH/NNRCi9f3fbxAfUsPPWCI ndoG/zYaCeWiNWrgE21KXU012pOi8auwEIVSHapQj0GvMea19grh1Pu3hW4iCnZSitYsYbWj UxpIv8UKfYW+nt3gVrNhRwTI+JKtKdbQYoOPLF3kZMEa6KI2cui2fHSYaWPnk7xY56PQolZc OE63cjVaIa1iqi3IIhVbUbzo9HtZj/bhwlrg8mLZ60rRjhBqNX5qiCmledsuhF3qX27UPTZQ tsktmipUvo1jOT5dw8UoYJKmuq3IdJ5A+GTfPb40ARxofKy4CLtToF0wPwawwcSwDKTGxRZm b45BTZ4QcoC6VobB2cwQzV5lFwPt0Gax0SbtiTLt05ao1Fbt1nbt1axNzv9G1XXCpdLxOGx2 5U0cox5Du/YMRGZ+XsuOuyu53m8uzg/sHMwu5ul9ZuNWZudeTs+hMqwzqiVzJefB7ZPdmPJ1 5zsu4JpsZHnOSHTOSvUV3wEaS588IAJG37A7X3bl7mW862WcYT8dy9s2S4G2tLKsXASeNwzG PTXiIayK4ukaYkWirAQPYnbT2O3qIJLErkocuAml2GOb4GD9DZyKYOWK0RG9MhYmauX1WSJ+ cB7NPnrTKqYk1BgGJJkFHDK923dONhcXcEMVSO9qWS6d4Y3ejY01ac/zbJR28BuF2glvYRzP YqgmvyjK0KuOv7HpYrTYBwIFPS1lSgtXSrNOyTD/9boRbrcrLpK77mdoykibLXO4ATw3tTmL 3DxB9k1BdOk8za2zidtxVWT6iKA6RUe4bbA1fZzevDm8Mkz9BF6nNpT56WxoXVzZvtVNLMfK Lii1fO1Jp/RKt/RLx/RM1/RGRzPphWOG8TBGd3TehnQVm9ctaeNST9bJ9XRDVOY1E24NET3g zm4hp2st4V5fttZphuZwHYgwgE5Ex59tpMvwxcmwpMnCVmRJs6bt7r/49ef2dVfzNmCI3Mn9 A0Z4ZqB0/GetjDxD40YF/F+DAPaU3WnxDmf8FtYtV6IFD7aqlnGZrjPVk/Ha0/Gg9XCsMuh/ 7FB477nFYrfV06FKTE4Y/z1psij344RQfQd46JZ16uTRaLkzrNS2DQPqjRbJmMY28U1U8KJ4 I0ZKJQ0ZkfROhQXcrx7bOQVb+kWYcvddFp+sJB52dk9xJrLZrIXxLM1xLyf4AIe+a83QLo5p RDLZVP9ypJRYC0cul3drlc553zayPperZPSzQV32tNVNbAQtuYxsvQZ0xltz+O4qxy48IYbv sDfxe6JbhxTnQt5ATFbGn8P2t4/XSKd15m7uD1d17Fa6IMflvc9tmQR8ExH1TTf8w0f8xFf8 xWf8Gzxd8/H7JiPEC/r0kQLG2/x6A7bKWZ0nuM9Oc/9dYn1u8klQvrdM/AP9Agdl6bVmtRt8 lv76Wm/F1uAWzto0ZiyeRXmiUUVf9ejufIeXEj6HdllLoXaOq/y0V80r1FNHY3eu3/Rue/yu pZfPxcKL52i/q/3NtgDUOKy3U5N0V2/MX9t1da727wt/YJNv6Aqf0JQveS7vapEVaaGt4Nyf MuJX4w1tNU68LH8ncjMGCAD/BA78V/CgwYMABDI0SHChwoQFCUaUaPEixowaN16k+LBjwo8L IUpsGNIhyY8VVZIs6fDlwJQhPY6E6RIhxZMWc8JkWLMiSplAe77kadOjTpwbebIUelPkz6g9 mer02bLoTJFFf25daZPoxJ1BH6a0apQj2rRqkSJMqhWjyrBe55oEGf6R5cm4X8G2BXr2bdWb gfvGvUqUrdK9Yp/OZSwXbOHFdzWyfVt3ceW9eKm2jXxWLejQGaMahljT9FXSNEeijskaNeuS rWHHbu0a5U6yTGMrvh3Ut+rbtmcKzlp2ddakyX/Tjinbp3PVtbkSP23V7ljrsDFn5+3auvDj 3ZeLLm/+PPr0idWzN/+5/VL48ufTr2//Pv78+pca3i+f+n79+TcggQUaeCCCCSq4IIMNOvgg hBFKOCGFFVp4IYYZarghhx16+CGIIYo4IoklmngiiimquGJ577Ho3osxyjghgKJxJaBvzrlk m4twcXRjS9TViBaApQFJk1g82kgkjhk2+f5fkMFpZuFl7em1ZF1/+bhlj+ch9eVg2I0mV3+Z ielYfV1WiNhaS/qlVJYXVsmemj8SBpdRn12ZJpxVaRlfTj2SdWaY9D1JpXJp1ZnojnkNxeAA Pi6q6GzAQWekZGeSdphuuKV2qZ59frVbp7nlFWpxlnL6W3SBgrpldcOVNZGeeb5G66u30irb rqrmVip3kOEZpae8ttrqbK8GWJ2f0XUUaHyD4fXYoJyZxqWjU6JpK259KQYtXVhNdaezsB42 arF2ShunZcwaK2xnhW4bbGBNcWnStfZeuyxf0+a5nrn+nguvtNiBqW2Y/8ZJKLgCU8sXwZmS KSWSw5ra766Rkf4L3FiC7YlxvYzxZqvD+EaMn5nhOsqmmCWL29jJgC2cqMZYzcxovCovfOW0 DOvVs7dDWVvwUdo6LNnHiCmdc5VDh+uyftqxCt6nyG1Vpm6vTddplNMZB6x0z7L6HHlK13ic 1lKH9zV0HbeMNng6Gje3lH5d13XH4pGdo3I3Snwk399pl+ytlTo5I50yTkqowYhL7DjkkQe4 +OOjHbrikJJrvjnnnXv+Oeihiz466aWbfjrqqau+Ouutu/467LHLPjvttWf0iO25677iI7jv /jvwIfoePPHFX9i78ckrD+Hwyzv/PIHIQz899fc1Xz322Wu/Pffde/89+OFb+IT45f6bfz76 6au/Pvvtu/8+/PHLPz/99dt/P/75678///37/z8AAyjAARKwgAZ0XD8OqMAFMrCBDnwgBCM4 OzBIsIIWvCAGM6jBDXKQV7TJnOUoN5/hJEeEY7NP5kiIwstRBm80W0tp1GPCd8GHhWIjjoR4 xDLKdCtBKpxVi3qoLnPdUGw2hJHcbJQrmbVpYwuaIQ+RiDOA+UeHQUzigX64Q0UJMVpEvJgR oaiuI5oqWeJalJbEaCU+SbE3VETQvqiWNrMsZ46yglvgflQ1HZqlOb/6jqW24zYmxS2QgqQb 4ARXRmWZ7C96a5Sn2jYrilVrUDuy5HaMFKRuZdJqfuIaEP47qcZhIWmSOjKjKVEpybtNyjtm LNckXaUQRi4Ri/w5lhULyclaHitWvWwIMJHWm8tUyl5kekowjegYky2zme2C5JtWArQRZmmV OCQcEHFJy+y0KJanxFcl9ya3TRWubZTS5je5aaw7hvM5yjomZx6lSGGNLFt1HNcyZZK1YJUK nHFMUsLcdrAVLrKH3sRUJNGZTjel847XNOfUoJJQX8IQnaGs1UStKaB2hsxj33LLwEDaMJB1 dGnYOiYn0fQyjcXTllAq6DjDKRRiqXKXXdGjTR2aU2gdtJ28vGVNF7qbhOaSVBMtGslOKDU5 hoeVWRvcH/3oKqM29WdoKyGxvv55HTdaqUhzHI/atoYsQ0aUSIEc61HK6cnBOZVtgiIcWfOo taqKtYtCqtzm6jTKNo5ur3g1kF/hB8IuDoiMkAvsyxSE2A6qz7CMfSyBxADZyVK2spYNkRMu q9nNcrZ6o3TKFG/5RxSCcbQ5amkRvUjQFoLGa6WFKU4Tlx/Hhk6vf22ivNgYtIEmM2i3JZCg cJu0aNkWVpSrgG5hV9zQ4parhsIZb1E6xCdON4qVc9HHvli0Bi0WsHF7ZVaJOlVn4a2TZc3m eFXF1ILWFaIcO9kgMdnHXwKpV4qcabUyVqZ7gS0zh0QmKOXrKyymklv4HCyEfkbUydhlX27h KcF2Rv9MozULl9jqmYPP+EJyKZguyRxqu4CGSYg9uLfMhFd2d0Y0fSYWMycWGUidZLXNbKqZ HmVOhBPTFJ5t10xpZGbKRMW0Ic+SidJscI395RTAZIqJO6YnD1O2TzjV+J6A3Ft+nfugkXrl XzaO8TM9U7BpspRoDQ5ozh6GVGemdcxjSnOXSdok/2YLyG0ek5QRNicuD/dNW8yhdJiqS8FB VJBb81pYsZnI4MgxhkUea9XK9jfx1BOsuoooHQndR0On6qz17U6lk6g2oYpybb8amSbnekJE afl03UXPcq3bpT83F7idph6CXR0hBNsw16sODW3R0gzRtrqzxj727FiB7GX+M7vZzn42tKMt bcW+2qUyrJhxq/1by9Xwzed87VHT8073tFLbKdqrtrsLLrPSiLnmZhyqApvd1v423ShC92xJ y9xbc9fdgNWuPMVdbNX6dt8y7FBPL9VQa3blSDNer4BlutV8cVOq2WSvJReuUFfqU76yrCnI M05Vv82yWDTNtFUXGtP0ehXbscoqXDW0mQcfmeIq62ichSZErVQmxBp+ZhilW3J9PaqUKl3w 0MeV4Q6rmGl71nDRP8xgpw25wwPL8ruhtEkwS+UuXX+6msM8tSSZeM1h+SdUcERjvUFtv5AB LYrjLk2m63gqheGpnTkMyNpQGF24GqrXZzpwB1H/xaROaxoOYQzlqX80mgfDMIOjyOS2txjM MJM75UW80qv7Hc08fgyR0RzSM4P+8hiC+MTNW+rduvC0c00bvRjdnCeLNdIxh/1XVf1yZBVa 0WwVtO73DrdNu3fuum80pmUpV0+uHKvjNt2frAuirL8xf9Sf0UbnHOx+A3f7jfX+tMMv/vGT v/zmPz/6069+821fhOBnUmFRa3CAVzSI16/g4kxI6/9Ebf4FJ/gVAeCchF/+eYn/CVy+DZz7 HVx1lZ6zdQ0f7RIvcZxEEdiiQZxBXdx5sRx9BZ1FkUp+OdwqbVX5+ZzQsZTUeUwK4tzM6RzQ 6RjipcsAmtzPnZSDNRLU/90f/p1GDWLZinlZ4A2Nj3kYMd1VzPzghfFghq1YnUXe4DHbSE0e yDDZjc2gkYmdFDZO0ZnZn8RgvGGMCR7gfbABA4VNezXa7y0SqFCV663GoZ0VlpGQKHkH2XCa b1GSGwrfiK2fbkFRcOUVH36Ir7XQewzivb1fICaiirSDImIQIzai99jBfnACRzwiJHaPJDKI JV7i9mSigmwiJ2qPHXgigoBiKGYPKRqIKZ6iAq0iKxaQK74iAcWiLNaiLd4iLuaiLu4iL/ai L/4iMAajMA4jMRajMW5IKhyjMi4jMzajMz4jND7bBkQjNVZjKPKBNWajNm4jN3bjiEyBN4aj OP+OIzmWoznGSACk4z8EgESkIzu+ozvGo0G44zq2Iz2uozqy40XQIzzGoz/+I0D+Y0LcIz6+ oz3KY0Ei5DwOpD8ypD4SZEA6pD4e5D0GJEQK5EBaBD8m5EUiJEYCZDtKJEdiZEE6ZD2a5Dxa JD+uZD+epDqezku+JD6mpEs+5EzeJEPSJE7m5E3KZEw+JFAu5E9OJFEGpT3qpE/yJFIWZUY2 ZUwu5T4aZVLKpE6e5E7+ZFVOZE9KpVFaJVUm5VISJU9SZUkuJE7CY1ZuZVWSzleupVZ+pVge 5Vlq5FuupVLe5VM+5VXSJVRGpVyqpVnyJV5qJWCSpWESplvGJVmOJVf/2mViBmZPRuZehqRe HiZSpuVOjs5iZuZflqVfeqZg8iVhLiZcmmU+OqZcYmVd+iRT0iRiPuZdFqZB2uVpZiRrjuZs pmZjzuRqMiVumuZsbqZTBmdu8mZtEiRqgs5mCmdmKqRSOidqQidpvqVN8mZypiRctiVrPmdx dmZpUiR40iZyoqVIYidiNqR5hqdQFqVl1qR7akRQAmVpbmR6NmXpDCV5KuRytidKMmY+dud0 piZK4udRbid1bidsYsR3iudZ5qZlHuh5quZnqqZvqud/Cih2hmVdZqh15qRB4mZc3mdrIqhb xqZeNueIvmaAjqVumih5NidjDiZ8UmdnGqeL/9rmaLJoX05ofLamfWJlg0ImkMJojPLoj76m iGZlV17lksqmkc6lY34nje5oX05lkfLnZxZpi84lhdrmlXbllALpkDoomErlXw6pkIKploop koaOdI4nRIJmQtYjcoYnSM5ped5pmh7mf6pkP+ppfdIln0Zon/qpof4pneJnR1YkS6rkSBYq oEKooFImSY6pZzLnOWaqpm4qp3aqp34qqIaqqI5qfdKneUbkoXokSYakoLKnc6bqbaInnoKn fnbknDKqrHplrj5qQ0ZkSRJqolZqnf7qrQ6rqQamrU6qpB5k7bApq+ZliuLojkaogv7mpUqo ZL7nbp5ptE7rmcroZP9C65cyaIdW5pI6K2RqKZOG6JqWKWe6jqVmaZCiKJXK641e67m26YLS K5Wiq7WGJmACLILG63N6Z5hu6Il6p8ImbLge7Lu2zlBuxIJiq5OqKGe2pzzm55RWq8GGJpoa aG16KKWqK7jKJpIOK5NuqWhmhHC+aHwCbMle5+rEKstCKK66qnqOLMyKq8bWaMe6KHpObEuC aG+WJ8dKJKMabc6mLMkGKsxKK3BaZXRu7MNCLIgerZK6podWaFSuKIue5sfqK9XyZ9iKLIAW Z60+rNCK58nuq5Sq6Iv6bKCyp2Bm7NjazonuJ7cyKIlq5L0m6npua9W67b+WbdMaZoy27Mb/ iqmJxuzbHq3Xsmq28mvAVq3soKvAdivgBuyG8uuFamu+zmjdUmvWei7pHmm9Jqi/Wuu+Vi5Y 9i1mjqjPjmno0k7GymmpNqqf8uptzmqqGudHouybTmehKm291uqf2i3Rpieq4m5LGi904qny Eqp8PqrkLu2bkqr2bi/3dq/3fi/4hq/4jm8GNSrv4myr+iqzLiu+wirSQqqsqm/07q5FzqrR Cuuu+m7vnipIoqr6EuuqHmn14m73WCqaqi1xpivtKqlYmmnERi0Ee+VlVm5avm6PPinnsmsG s6sDa+5urm7mDqflYg/jUrDiym1bMm1+/uwKQymmEu7ThmyXsrDm/4bw5sLt3rrwtrpryV6w +PQp6D5tgqJwmGotuL6sDkvtz/Itsybuv2awEbNwFC9xvLJp4TYwjZ4u+ACx4CIwEWOtZIas ChuxBZ9wzNrvuh7w42qovJqrEidm0CpmnaZtBWexEBfwhwax3DKtEEtpf44xh1rwGw/xg04q uR5xtGpx3uotd8Zu3Aayj2av357PAnMpB1NtbMLm2BbxmsosDM/uvBbsGlPwEX9xIycxWEKx ru4xJfPwDH9ylnrwEk9uFWuw6cbyKt+yKpMo614yGA+sHFfpDp8xpnKPFbtv7iruoP4x+kZq ngbw8FKvQMov/rpqrBprsqar9JrvNnNxWf/ibzdjMvmOMzmXszmfMzqnszqvMzuL6ADrLxAz LzjPbfHiarFOr+RSczV3LTa3LjWmciUrMUAPdOmmMueGchJLcBg3qevycDYKcidj6HpGsJMK tJkidOTa8CEbbjE3oww7rAIDKBkv7tD6JX3yMuW2MSYDs8o+NJmq7PI+awI38rG65nFWakpr NOUa7iD/8yZj5tbmM0+D7RsTtUNL8i+vdA0btEvTsH16q7qO8uieso8O7k/nsD9vI8ZGssdW Z0H3cs2WbrZmNbmu6Ch3NDNGc6uutTMbLykLM/wiKho77VwHsP2idTvntV7vNV/3tV//NWAH tmAPNmEXtmEfNmIaJ7ZiLzZjN7ZjPzZkR7ZkTzZlV7ZlX7YGBQQAOw== ------=_NextPart_000_0009_01C6CD53.25ECE6A0-- From owner-ccamp@ops.ietf.org Thu Aug 31 15:57:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsf5-0000XK-Az for ccamp-archive@ietf.org; Thu, 31 Aug 2006 15:57:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIsf3-0004Ra-U9 for ccamp-archive@ietf.org; Thu, 31 Aug 2006 15:57:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GIsYA-000JNn-1x for ccamp-data@psg.com; Thu, 31 Aug 2006 19:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GIsY7-000JMd-8B for ccamp@ops.ietf.org; Thu, 31 Aug 2006 19:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9043E328DF; Thu, 31 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GIsY6-0007iM-FK; Thu, 31 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-06.txt Message-Id: Date: Thu, 31 Aug 2006 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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 Inter-Domain Multiprotocol Label Switching Traffic Engineering Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-inter-domain-framework-06.txt Pages : 21 Date : 2006-8-31 This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-framework-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-31111424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-31111424.I-D@ietf.org> --OtherAccess-- --NextPart-- From apache@19redgirl.info Thu Aug 31 23:09:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIzPO-0004rp-59 for ccamp-archive@ietf.org; Thu, 31 Aug 2006 23:09:30 -0400 Received: from [203.82.17.228] (helo=19redgirl.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIzPM-0003p9-Kx for ccamp-archive@ietf.org; Thu, 31 Aug 2006 23:09:30 -0400 Received: by 19redgirl.info (Postfix, from userid 48) id 14FC6207BE9; Thu, 31 Aug 2006 21:16:49 -0400 (EDT) From: info@19redgirl.info Subject: =?ISO-2022-JP?B?GyRCIXk6I0Z8JCskaSM5N24heT0pTFxBMCF5GyhC?= To: ccamp-archive@ietf.org Message-Id: <20060901011649.14FC6207BE9@19redgirl.info> Date: Thu, 31 Aug 2006 21:16:49 -0400 (EDT) X-Spam-Score: 2.4 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da $BJQ$o$j$P$($N$J$$F|>o$K$&$s$6$j$7$F$^$;$s$+!)(B $B$H$-$K$O<+M3$K0&$r5a$a$F$b$$$$$s$8$c$J$$$+$J!)(B $B$J$+$K$O%d%j$?$/$F$?$^$i$J$$%(%m%(%m$J=w@-$b$$$k$+$i$M!#(B $B$=$s$J?M$?$A$,$I$s$I$s=8$^$C$F$/$k$N$,$3$N%5%$%H(B $B$4MxMQ$,40A4L5NA$J$N$G$9$4$/;H$$$d$9$/$FBg?M5$!#(B $B%W%m%U$J$s$+$K$b$H$F$b8@$($J$$$h$&$JFbMF$,!D(B $B<+M3$K0&$r5a$a$k?M$?$A$N%5%$%H$G$9!#(B $B;H$$J} Date: Thu, 31 Aug 2006 15:50:02 -0400 --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 Inter-Domain Multiprotocol Label Switching Traffic Engineering Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-inter-domain-framework-06.txt Pages : 21 Date : 2006-8-31 This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-framework-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-31111424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-31111424.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 31 Aug 2006 11:32:49 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) To: ccamp@ops.ietf.org Message-Id: <606BAE85-3B96-4EBF-A5EE-9EFA32509597@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-43-475489015 From: JP Vasseur Subject: Fwd: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Date: Thu, 31 Aug 2006 07:30:31 -0400 DKIM-Signature: a=rsa-sha1; q=dns; l=19321; t=1157023836; x=1157887836; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Fwd=3A=20I-D=20ACTION=3Adraft-ietf-ccamp-inter-domain-pd-path-comp-03.tx t=20 |To:ccamp@ops.ietf.org; X=v=3Dcisco.com=3B=20h=3DppafsOedZh8Ukv6Ogz/S//MXSrA=3D; b=MC6miY7qCsVamHI/xtA4CcJcBUypUFvMM0OM1oBTEoWbQ25+vz+k34xmUeTPaknn1dyairBt CGAMS+5TI+MlKjSWAwr5O0alv49J3vQq/cm5wdlZwMY6b9209sfhNHnW; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); --Apple-Mail-43-475489015 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed simple refresh. No change. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: August 30, 2006 3:50:02 PM EDT > To: i-d-announce@ietf.org > Cc: ccamp@ops.ietf.org > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement > Plane Working Group of the IETF. > > Title : A Per-domain path computation method for establishing > Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) > Author(s) : J. Vasseur > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt > Pages : 21 > Date : 2006-8-30 > > This document specifies a per-domain path computation technique for > establishing inter-domain Traffic Engineering (TE) Multiprotocol > Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched > Paths (LSPs). In this document a domain refers to a collection of > network elements within a common sphere of address management or path > computational responsibility such as IGP areas and Autonomous > Systems. Per-domain computation applies where the full path of an > inter-domain TE LSP cannot be or is not determined at the ingress > node of the TE LSP, and is not signaled across domain boundaries. > This is most likely to arise owing to TE visibility limitations. The > signaling message indicates the destination and nodes up to the next > domain boundary. It may also indicate further domain boundaries or > domain identifiers. The path through each domain, possibly including > the choice of exit point from the domain, must be determined within > the domain. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain- > pd-path-comp-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path- > comp-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-8-30143516.I-D@ietf.org> --Apple-Mail-43-475489015 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 simple refresh. No = change.

JP.

Begin = forwarded message:

Date: August 30, 2006 3:50:02 PM = EDT
To: i-d-announce@ietf.orgSubject: = I-D = ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt=A0

A New = Internet-Draft is available from the on-line Internet-Drafts=A0
This draft is a work item of the = Common Control and Measurement Plane Working Group of the = IETF.

Title : A Per-domain path computation = method for establishing Inter-domain Traffic Engineering (TE) Label = Switched Paths (LSPs)
= Author(s) = : J. Vasseur
= Filename = : draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt
Pages : 21
Date : = 2006-8-30

=

This = document specifies a per-domain path computation technique for
establishing inter-domain Traffic Engineering (TE) = Multiprotocol
Label Switching (MPLS) and = Generalized MPLS (GMPLS) Label Switched
Paths = (LSPs).=A0 In this document = a domain refers to a collection of
network = elements within a common sphere of address management or path
computational responsibility such as IGP areas and = Autonomous
Systems.=A0 Per-domain computation = applies where the full path of an
inter-domain = TE LSP cannot be or is not determined at the ingress
node of the TE LSP, and is not signaled across = domain boundaries.
This is most likely to = arise owing to TE visibility limitations.=A0 The
signaling message indicates the destination and = nodes up to the next
domain boundary.=A0 It may also indicate further = domain boundaries or
domain identifiers.=A0 The path through each domain, = possibly including
the choice of exit point = from the domain, must be determined within
the = domain.

A URL for this Internet-Draft is:

To remove yourself from the I-D = Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".

A list = of Internet-Drafts directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt".
=


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

= --Apple-Mail-43-475489015-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Aug 2006 19:52:33 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Message-Id: Date: Wed, 30 Aug 2006 15:50:02 -0400 --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 Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Pages : 21 Date : 2006-8-30 This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-30143531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-30143531.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Aug 2006 19:52:25 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Message-Id: Date: Wed, 30 Aug 2006 15:50:02 -0400 --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 Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) Author(s) : J. Vasseur Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt Pages : 21 Date : 2006-8-30 This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-30143516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-30143516.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Aug 2006 22:23:20 +0000 Message-ID: <44F4BDE0.1090204@us.fujitsu.com> Date: Tue, 29 Aug 2006 15:21:20 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ccamp , mpls@ietf.org Subject: call for papers: 1st IEEE International Workshop on Bandwidth on Demand (BoD 2006) Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Apologies for possibly receiving multiple copies of this CFP. Call for Papers 1st IEEE International Workshop on Bandwidth on Demand (BoD 2006) http://www.csg.unizh.ch/events/bod06/ In conjunction with IEEE GLOBECOM 2006 http://www.ieee-globecom.org/2006/ November 27, 2006 San Francisco, California, USA Scope Electronic marketplaces for trading bandwidth have emerged since the late 1990’s, but were seriously hit by the economic downturn in 2001. The promise of instant bandwidth availability had led to the development of market mechanisms that companies used to trade bandwidth just as other commodities. However, those trading markets all but disappeared with the bursting of the telecom bubble. Driven by the recent technical advances in telecommunications and the new potentials of emerging peer-to-peer (P2P) and next generation networks (NGN), the goal of this workshop is to take a fresh and innovative look at the concept of bandwidth on demand (BOD). Recent advances in the Internet-based communications domain, in which the support of Quality-of-Service and diverse application services become possible, require in many cases short-termed bandwidth assignments for, e.g., large sporting events or cultural open air activities. In addition, the support of bandwidth trading in a fully decentralized and secured manner, e.g., based on P2P schemes, shows further advantages in terms of reliability and scalability for large-scale systems. Topics of Interest The workshop seeks original papers in the following four areas that serve as basis for bandwidth on demand: * Economic studies and modeling of market and business models in carrier and service provider networks o Game theoretical bandwidth-on-demand models o Cost and revenue models o Bandwidth-on-demand business models o Market liquidity aspects * Technical design of scalable, reliable, and cost-effective bandwidth trading infrastructures, including market mechanisms as a way to increase efficiencies o Scalable market mechanisms o Secure and reliable market infrastructures o Bandwidth trading mechanisms o IP-based and decentralized trading mechanisms o P2P trading infrastructures, distributed markets o P2P auctions * Legislative and regulatory issues related to the Telecom Act and in comparison to other commodities markets such as the electric grid o Telecom legislation o Telecom regulation o Commodities markets * Industrial developments of new technologies that facilitate or create impediments to bandwidth on demand o Network management aspects o Technical improvements in transport and data networks Paper Submissions Papers are solicited as full papers (in English), of no more than 8 single-spaced pages, each of which will be subject to a full review process. Submissions must be in PDF and will be handled using the JEMS system. Please refer to http://www.csg.unizh.ch/events/bod06/ for further submission instructions or contact bod06@ifi.unizh.ch for additional information. Those papers accepted will be published in proceedings with an ISBN number. Important Dates * Paper registration deadline: September 14, 2006 * Extended submission deadline: September 21, 2006 * Notification of acceptance: October 15, 2006 * Final versions of papers due: October 31, 2006 * Workshop date: November 27, 2006 Committees General Co-chairs * Takeo Hamada, Fujitsu Laboratories of America, USA * Burkhard Stiller, University of Zurich and ETH Zurich, Switzerland * Jean Walrand, UC Berkeley, USA PC Co-chairs * Richard Rabbat, Fujitsu Laboratories of America, USA * David Hausheer, University of Zurich, Switzerland Technical Program Committee * Panayotis Antoniadis, LIP6, France * Greg Bernstein, Grotto Networking, USA * Georg Carle, University of Tuebingen, Germany * Costas Courcoubetis, AUEB, Greece * György Dán, KTH, Sweden * Vasilios Darlagiannis, EPFL, Switzerland * Zoran Despotovic, DoCoMo Euro-Labs Muenchen, Germany * Chris Edwards, Lancaster University, UK * Adrian Farrel: Old Dog Consulting / IETF CCAMP Working Group Chair * Oliver Heckmann, TU Darmstadt, Germany * Rahul Jain, UC Berkeley, USA * Charis Kaskiris, UC Berkeley, USA * Dave Marples, Telcordia, USA * Michael Menth, University of Wuerzburg, Germany * Huw Oliver, Bristol, Research Consultant, UK * Lyndon Ong, Ciena, USA * Aiko Pras, University of Twente, The Netherlands * Giancarlo Ruffo, University of Torino, Italy * Vik Saxena, Comcast, USA * Vishal Sharma, Metanoia, Inc, USA * Kohei Shiomoto, NTT Labs, Japan Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Aug 2006 12:25:48 +0000 Message-ID: <44F3AB01.3060503@cisco.com> Date: Mon, 28 Aug 2006 22:48:33 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: OSPF List CC: ccamp@ops.ietf.org, David Ward Subject: Re: [OSPF] draft-ietf-ccamp-automesh-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=872; t=1156854226; x=1157718226; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20draft-ietf-ccamp-automesh-01.txt; X=v=3Dcisco.com=3B=20h=3D8j11J++E6Pa/BZ2WZ4YQIfLMMcE=3D; b=BQ1OSD5KkSK8uRYQCLRyJhHGqlqLiH+PMl+AYiX2RFkz1vQrQf4DsMJa2s5VPyQp4xt+ujMs xnL7oMKL2EuExLjnXnjwoV9B0w7KoseXwEatm4pxB1G0Xim7iK0cauuE; Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); The OSPF WG last call has ended. Thanks, Acee Acee Lindem wrote: > The above draft makes use of the OSPF capabilities LSA. It is my > understanding that it has been last called in the ccamp WG. We are > now last calling it in the OSPF and ISIS WGs. > > The last call will start today (August 11, 2006) and end at 12:00 AM > on August 26th, 2006. Please copy this list and the document editors > (JP Vasseur and JL Leroux) with your comments. You can also copy the > ccamp list if you are subscribed (I believe the list is closed though > I'm not sure since I am subscribed). > > Here is a link for you convenience: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-01.txt > > Thanks, > Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Aug 2006 07:32:47 +0000 Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: "Dimitri.Papadimitriou" Cc: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Mon, 28 Aug 2006 09:30:54 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Dimitri, from my point of view the possibility to specify link components and labels in ERO foreseen the existence of a MP that knows that information so I can say that there are CP opertarion linked to MP. Regards Diego Dimitri.Papadimitriou@alcatel.be on 25/08/2006 19.01.14 To: "Bryskin, Igor" cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) i totally disagree you constantly referring to the MP while CCAMP has NEVER linked control operations to MP operations - these MP operations assumptions are outside scope of CCAMP in part. we are going to enter into a discussion for which we won't get the bird out of the bush: addressing space between CP and MP it took us more or less 4 years to disambiguate the DP address space relationship with the CP and there is no reason to start an endless debate now with the MP -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:39 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Approximate scenarios: a) MP->CP scenario: MP provides CP with complete ERO (including labels) CP signals SETUP with an IN-PLACE attribute, this causes provisioning operations on each node without re-programming cross-connects MP releases resource ownership after the operation by some means b) CP->MP scenario: MP receives from CP complete RRO (including labels) MP assumes resource ownership operation by some means CP signals TEARDOWN with an IN-PLACE attribute, this causes release by CP resources on each node without re-programming cross-connects Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 12:18 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) you are asking for something outside the scope of ccamp entity X wants to recuperate a CP state - just let it do - if so allowed then send a PathTear since there is no resource anymore associate to that state (but this does not require any specific documentation) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:06 To: "Lou Berger" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Agree with Lou. Can I also quote my own email? :=) "We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP." So I think we are talking about two relatively simple and very symmetrical CP functions. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, August 25, 2006 11:57 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Aug 2006 06:50:59 +0000 Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: "Lou Berger Cc: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Mon, 28 Aug 2006 08:48:43 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Lou, you are right the first version of the ID (that was about the protocol solution) used a bit in the Administrative Obj in order to inform the TNE to not remove the data plane state but just the control plane. As you said is a very little and very simple modification. Regards Diego Lou Berger on 25/08/2006 18.32.06 To: Dimitri.Papadimitriou@alcatel.be cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, Removing state should be a simple process of deleting local control plane state while not impacting the data plane state. Exporting, at least to me, implies a more complicated API or other information transaction processing, which is certainly not needed here. I think we're talking about a mechanism that should require a single "preserve data plane" bit in a PathTear message. Nothing more. Lou At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - isn't "remove" or "export" having the same meaning in the present >context ? > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 17:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Who said anything about exporting state? > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou - and why shall CCAMP provide a function to export states outside of > >its domain of competence > > > >thanks, > >- d. > > > > > > > > > >Lou Berger > >25/08/2006 17:49 > > > > To: "Don Fedyk" > > cc: "Bryskin, Igor" , Dimitri > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, > >Adrian" , "ccamp" , "Brungard, > >Deborah A, ALABS" , "Diego Caviglia" > >, "Drake, John E" , > >"Lou Berger" , "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > > > >Don, > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > >I think there may be something here but I think even the requirements >as > > >stated assume too much of the solution. What is the real issue? > > > >Per my previous e-mail: > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > >>[...] > > >>If we were to ask could you live without the CP->MP feature what > > >>response would we get versus asking if CP->MP is a soft requirement. > > > > > > From the discussions I've had on this with carriers, for some it's > > > a don't care, for others they won't deploy control plane without > > > this capability. > > > > > >Lou > > > >AND > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > >[...]I therefore think the definition of CP->MP *is* > > >required. There are multiple options for meeting this requirement, > > >but the solution must provide the "fallback" capability for services > > >existing at the time of the initial MP->CP transition and those > > >created after the transition. > >[...] > > > >I think a capability to remove LSP state while leaving forward state > >untouched will meet the requirements of those I've talked with. > > > >Lou > > > > >Regards, > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Aug 2006 06:46:51 +0000 Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: "Dimitri.Papadimitriou" Cc: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Mon, 28 Aug 2006 08:45:16 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Dimitri, removing the control plane state of a crossconnection without touching the data plane imho is in the scope of CCAMP. Also because, but this is in the scope of a solution document, can be done via Control Plane. Regards Diego Dimitri.Papadimitriou@alcatel.be on 25/08/2006 17.51.38 To: Lou Berger cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - and why shall CCAMP provide a function to export states outside of its domain of competence thanks, - d. Lou Berger 25/08/2006 17:49 To: "Don Fedyk" cc: "Bryskin, Igor" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Don, At 10:40 AM 8/25/2006, Don Fedyk wrote: >I think there may be something here but I think even the requirements as >stated assume too much of the solution. What is the real issue? Per my previous e-mail: At 01:01 PM 8/24/2006, Lou Berger wrote: >At 10:48 AM 8/24/2006, Don Fedyk wrote: >>[...] >>If we were to ask could you live without the CP->MP feature what >>response would we get versus asking if CP->MP is a soft requirement. > > From the discussions I've had on this with carriers, for some it's > a don't care, for others they won't deploy control plane without > this capability. > >Lou AND At 08:15 AM 8/24/2006, Lou Berger wrote: >[...]I therefore think the definition of CP->MP *is* >required. There are multiple options for meeting this requirement, >but the solution must provide the "fallback" capability for services >existing at the time of the initial MP->CP transition and those >created after the transition. [...] I think a capability to remove LSP state while leaving forward state untouched will meet the requirements of those I've talked with. Lou >Regards, >Don Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Aug 2006 06:46:43 +0000 Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: "Lou Berger Cc: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Mon, 28 Aug 2006 08:42:13 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Lou, Lou Berger on 25/08/2006 17.49.26 To: "Don Fedyk" cc: "Bryskin, Igor" , , "Dan Li" , "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Don, At 10:40 AM 8/25/2006, Don Fedyk wrote: >I think there may be something here but I think even the requirements as >stated assume too much of the solution. What is the real issue? Per my previous e-mail: At 01:01 PM 8/24/2006, Lou Berger wrote: >At 10:48 AM 8/24/2006, Don Fedyk wrote: >>[...] >>If we were to ask could you live without the CP->MP feature what >>response would we get versus asking if CP->MP is a soft requirement. > > From the discussions I've had on this with carriers, for some it's > a don't care, for others they won't deploy control plane without > this capability. > >Lou AND At 08:15 AM 8/24/2006, Lou Berger wrote: >[...]I therefore think the definition of CP->MP *is* >required. There are multiple options for meeting this requirement, >but the solution must provide the "fallback" capability for services >existing at the time of the initial MP->CP transition and those >created after the transition. [...] I think a capability to remove LSP state while leaving forward state untouched will meet the requirements of those I've talked with. [dc] This is exactly what we have in mind. Lou >Regards, >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 20:07:52 +0000 To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 22:03:07 +0200 Content-Type: text/plain; charset="US-ASCII" igor - but these bits don't change semantic - you remove the state (you send the action anyway) the fact the data plane actually commits this action or not does not prevent forwarding passing through PathTear anyway thanks, - d. "Bryskin, Igor" 25/08/2006 21:16 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, We do need an action from CP: we need a way to signal differently normal graceful shutdown and "removal CP state only" shutdown, We cannot overload or change semantics of the "D" bit at this point. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 3:04 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor you are hanging on "breaking cross-connection" ... what i am telling to you is that there is no action required from the CP viewpoint beside preventing any error/alarm and removing the control plane state (for a data plane state that doesn't exist anymore from the CP perspective) there is no difference from the presence or absence of cross-connection ... otherwise we would have already a PathTear error of some kind. you have in mind to involve the CP signaling in this move - which is totally beyond scope - -d. "Bryskin, Igor" 25/08/2006 20:52 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, No, it is not. D-bit was designed for a normal release. In normal release CP is responsible for breaking cross-connects (for example to avoid mis-connections during subsequent setups). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:46 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor - but it is exactly what happens the resource reservation disappears from the control plane viewpoint (after which a pathtear is sent to remove the control plane state) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 20:37 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We do graceful shutdown normally. We need another bit for this exceptional release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor but you don't need more than what's in RFC 3473 than disabling alarms during the move of the resource associated to the CP to another enitity and the send a pathtear to remove the control plane state (you don't need to involve the CP in moving the data plane resource on each node) -d. "Bryskin, Igor" 25/08/2006 20:02 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in Path and Modify messages and is meant for disabling alarms before you starting LSP teardown. What we are talking about is nothing but a bit in PathTear message instructing resource manager on each node not to break cross-connects while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful deletion bit set in admin_status, then on each node the resource is associated to that entity (which is not a CP business) and then the control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 20:02:03 +0000 To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , Lou Berger , "Li, Han" , "Ong, Lyndon" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue - non-issue MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 22:00:14 +0200 Content-Type: text/plain; charset="US-ASCII" lou - one justification i was thinking of is the move of a connection outside CP control for off-line testing between specific segments (nodes interconnected by "passive" equipment for inst.) thanks, - dimitri. Lou Berger 25/08/2006 21:14 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , "Ong, Lyndon" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue - non-issue Dimitri, See below. At 03:08 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > > > Given this, what's your objection here? > >that the move that we're discussing is not due to issues of CP >resiliency/reliability/capability/or anything else equivalent Assuming I understand what you're saying (i.e., that there is no motivation to have this feature due to failings/limitations of the control plane) then I agree 100%. >i have pointed this to authors since the initial e-mail that started all >this thread - hence, i can think of reason to allow for such move - but >not at all for the reasons expressed since so far okay, I'll bite. What are the reasons/justifications for this that you belive in? Lou >-d. > > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 21:02 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Ong, Lyndon" , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Lou Berger" , "Li, Han" >, owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue - non-issue > > >Dimitri, > not sure about past discussions, but you're characterization >of (at least) my position is just plain wrong. I don't think this >has anything to do with "unreliable control plane operations". As I >said before, the requirement for this comes from the need to have a >symmetric operation to gain acceptance by some carriers. > > From your previous mail, it sounds like you think this capability >already exists. Given this, what's your objection here? > >Lou > >At 01:47 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >i agree on this CCAMP has/is building a self-consistent set of mechanisms > >(from the start CCAMP considered that the MP has not being fallback > >whatsover of the CP operations and in particular not linking any of its > >operations to a particular MP) > > > >all what i am hearing from igor and co. is just penalizing the work of > >this group achieved since 6 years without technical justification *** > >there is no need for MP intervention in order to obtain CP operations > >resiliency/reliability *** second time we have such discussion (look back > >on the archive around end-october 2005, nov.2005 you will see there that > >the same people already pushed forward the idea of unreliable control > >plane operations - if someone's implementation is unstable/unreliable it > >is not up to CCAMP to solve such issue and certainly not by interfering > >with the MP) > > > >ps: add also add CP GR restart (from intermediate and source node) > > > >-d. > > > > > > > > > >"Ong, Lyndon" > >25/08/2006 19:22 > > > > To: "Brungard, Deborah A, ALABS" , >"Farrel, > >Adrian" > > cc: "ccamp" , "Dan Li" >, > >"Diego Caviglia" , "Don Fedyk" > >, "Drake, John E" , "Lou > >Berger" , "Li, Han" , > >, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, > >"Bryskin, Igor" > > Subject: RE: CP-->MP Issue - non-issue > > > > > >Hi Folks, > > > >Just a bit worried that this discussion may be causing the impression > >that > >control plane is somehow unstable and requires some kind of special > >backup! > > > >Deborah and other carrier representatives can attest that control plane > >(although not necessarily standard GMPLS) has been deployed and in > >operation > >in a number of carrier networks for some years without experiencing any > >major failures. There are already methods in use for ensuring the > >reliability > >of the control plane such as redundant control processors, non-volatile > >storage of control plane data, software verification and testing, etc. > > > >I don't believe it was the intention of GMPLS work to require some kind > >of > >fallback to central management system control, hopefully everyone agrees > >on this! > > > >Cheers, > > > >Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 19:16:54 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 15:16:48 -0400 Message-ID: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIeV9ht4ICTDERQxO0h4glD/8EuAAAHIPA From: "Bryskin, Igor" To: Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Dimitri, We do need an action from CP: we need a way to signal differently normal = graceful shutdown and "removal CP state only" shutdown, We cannot overload or change semantics of the "D" bit at this point. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 3:04 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor you are hanging on "breaking cross-connection" ... what i am telling to=20 you is that there is no action required from the CP viewpoint beside=20 preventing any error/alarm and removing the control plane state (for a=20 data plane state that doesn't exist anymore from the CP perspective) = there=20 is no difference from the presence or absence of cross-connection ...=20 otherwise we would have already a PathTear error of some kind. you have in mind to involve the CP signaling in this move - which is=20 totally beyond scope -=20 -d.=20 "Bryskin, Igor" 25/08/2006 20:52 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, No, it is not. D-bit was designed for a normal release. In normal = release=20 CP is responsible for breaking cross-connects (for example to avoid=20 mis-connections during subsequent setups). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:46 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor - but it is exactly what happens the resource reservation = disappears=20 from the control plane viewpoint (after which a pathtear is sent to = remove=20 the control plane state) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 20:37 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We = do=20 graceful shutdown normally. We need another bit for this exceptional=20 release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor=20 but you don't need more than what's in RFC 3473 than disabling alarms=20 during the move of the resource associated to the CP to another enitity=20 and the send a pathtear to remove the control plane state (you don't = need=20 to involve the CP in moving the data plane resource on each node) -d. =20 "Bryskin, Igor" 25/08/2006 20:02 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger"=20 cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in = Path and Modify messages and is meant for disabling alarms before you=20 starting LSP teardown. What we are talking about is nothing but a bit in PathTear message=20 instructing resource manager on each node not to break cross-connects=20 while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved=20 from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful=20 deletion bit set in admin_status, then on each node the resource is=20 associated to that entity (which is not a CP business) and then the=20 control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian"=20 , "ccamp" , "Dan Li"=20 , "Brungard, Deborah A, ALABS" ,=20 "Diego Caviglia" , "Don Fedyk"=20 , "Bryskin, Igor" , "Drake, John = E" , "Li, Han" ,=20 owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, I really don't understand your point. Can you = restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate=20 errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, = John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so=20 allowed > > > >then send a PathTear since there is no resource anymore associate to=20 that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are = allocated=20 - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake,=20 John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not = needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the=20 present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" = , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states=20 outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" = > > > > Subject: RE: CP-->MP Issue (was RE: Polling for = new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature = what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some=20 it's > > > > > a don't care, for others they won't deploy control plane = without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this=20 requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward=20 state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 19:14:54 +0000 Message-Id: <7.0.1.0.2.20060825151128.03363868@labn.net> Date: Fri, 25 Aug 2006 15:14:31 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue - non-issue Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" ,"Ong, Lyndon" , owner-ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Dimitri, See below. At 03:08 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > > > Given this, what's your objection here? > >that the move that we're discussing is not due to issues of CP >resiliency/reliability/capability/or anything else equivalent Assuming I understand what you're saying (i.e., that there is no motivation to have this feature due to failings/limitations of the control plane) then I agree 100%. >i have pointed this to authors since the initial e-mail that started all >this thread - hence, i can think of reason to allow for such move - but >not at all for the reasons expressed since so far okay, I'll bite. What are the reasons/justifications for this that you belive in? Lou >-d. > > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 21:02 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Ong, Lyndon" , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Lou Berger" , "Li, Han" >, owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue - non-issue > > >Dimitri, > not sure about past discussions, but you're characterization >of (at least) my position is just plain wrong. I don't think this >has anything to do with "unreliable control plane operations". As I >said before, the requirement for this comes from the need to have a >symmetric operation to gain acceptance by some carriers. > > From your previous mail, it sounds like you think this capability >already exists. Given this, what's your objection here? > >Lou > >At 01:47 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >i agree on this CCAMP has/is building a self-consistent set of mechanisms > >(from the start CCAMP considered that the MP has not being fallback > >whatsover of the CP operations and in particular not linking any of its > >operations to a particular MP) > > > >all what i am hearing from igor and co. is just penalizing the work of > >this group achieved since 6 years without technical justification *** > >there is no need for MP intervention in order to obtain CP operations > >resiliency/reliability *** second time we have such discussion (look back > >on the archive around end-october 2005, nov.2005 you will see there that > >the same people already pushed forward the idea of unreliable control > >plane operations - if someone's implementation is unstable/unreliable it > >is not up to CCAMP to solve such issue and certainly not by interfering > >with the MP) > > > >ps: add also add CP GR restart (from intermediate and source node) > > > >-d. > > > > > > > > > >"Ong, Lyndon" > >25/08/2006 19:22 > > > > To: "Brungard, Deborah A, ALABS" , >"Farrel, > >Adrian" > > cc: "ccamp" , "Dan Li" >, > >"Diego Caviglia" , "Don Fedyk" > >, "Drake, John E" , "Lou > >Berger" , "Li, Han" , > >, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, > >"Bryskin, Igor" > > Subject: RE: CP-->MP Issue - non-issue > > > > > >Hi Folks, > > > >Just a bit worried that this discussion may be causing the impression > >that > >control plane is somehow unstable and requires some kind of special > >backup! > > > >Deborah and other carrier representatives can attest that control plane > >(although not necessarily standard GMPLS) has been deployed and in > >operation > >in a number of carrier networks for some years without experiencing any > >major failures. There are already methods in use for ensuring the > >reliability > >of the control plane such as redundant control processors, non-volatile > >storage of control plane data, software verification and testing, etc. > > > >I don't believe it was the intention of GMPLS work to require some kind > >of > >fallback to central management system control, hopefully everyone agrees > >on this! > > > >Cheers, > > > >Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 19:09:29 +0000 To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Lou Berger" , "Li, Han" , "Ong, Lyndon" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue - non-issue MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 21:08:23 +0200 Content-Type: text/plain; charset="US-ASCII" lou > Given this, what's your objection here? that the move that we're discussing is not due to issues of CP resiliency/reliability/capability/or anything else equivalent i have pointed this to authors since the initial e-mail that started all this thread - hence, i can think of reason to allow for such move - but not at all for the reasons expressed since so far -d. Lou Berger Sent by: owner-ccamp@ops.ietf.org 25/08/2006 21:02 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Ong, Lyndon" , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue - non-issue Dimitri, not sure about past discussions, but you're characterization of (at least) my position is just plain wrong. I don't think this has anything to do with "unreliable control plane operations". As I said before, the requirement for this comes from the need to have a symmetric operation to gain acceptance by some carriers. From your previous mail, it sounds like you think this capability already exists. Given this, what's your objection here? Lou At 01:47 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >i agree on this CCAMP has/is building a self-consistent set of mechanisms >(from the start CCAMP considered that the MP has not being fallback >whatsover of the CP operations and in particular not linking any of its >operations to a particular MP) > >all what i am hearing from igor and co. is just penalizing the work of >this group achieved since 6 years without technical justification *** >there is no need for MP intervention in order to obtain CP operations >resiliency/reliability *** second time we have such discussion (look back >on the archive around end-october 2005, nov.2005 you will see there that >the same people already pushed forward the idea of unreliable control >plane operations - if someone's implementation is unstable/unreliable it >is not up to CCAMP to solve such issue and certainly not by interfering >with the MP) > >ps: add also add CP GR restart (from intermediate and source node) > >-d. > > > > >"Ong, Lyndon" >25/08/2006 19:22 > > To: "Brungard, Deborah A, ALABS" , "Farrel, >Adrian" > cc: "ccamp" , "Dan Li" , >"Diego Caviglia" , "Don Fedyk" >, "Drake, John E" , "Lou >Berger" , "Li, Han" , >, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, >"Bryskin, Igor" > Subject: RE: CP-->MP Issue - non-issue > > >Hi Folks, > >Just a bit worried that this discussion may be causing the impression >that >control plane is somehow unstable and requires some kind of special >backup! > >Deborah and other carrier representatives can attest that control plane >(although not necessarily standard GMPLS) has been deployed and in >operation >in a number of carrier networks for some years without experiencing any >major failures. There are already methods in use for ensuring the >reliability >of the control plane such as redundant control processors, non-volatile >storage of control plane data, software verification and testing, etc. > >I don't believe it was the intention of GMPLS work to require some kind >of >fallback to central management system control, hopefully everyone agrees >on this! > >Cheers, > >Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 19:05:40 +0000 To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 21:03:44 +0200 Content-Type: text/plain; charset="US-ASCII" igor you are hanging on "breaking cross-connection" ... what i am telling to you is that there is no action required from the CP viewpoint beside preventing any error/alarm and removing the control plane state (for a data plane state that doesn't exist anymore from the CP perspective) there is no difference from the presence or absence of cross-connection ... otherwise we would have already a PathTear error of some kind. you have in mind to involve the CP signaling in this move - which is totally beyond scope - -d. "Bryskin, Igor" 25/08/2006 20:52 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, No, it is not. D-bit was designed for a normal release. In normal release CP is responsible for breaking cross-connects (for example to avoid mis-connections during subsequent setups). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:46 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor - but it is exactly what happens the resource reservation disappears from the control plane viewpoint (after which a pathtear is sent to remove the control plane state) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 20:37 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We do graceful shutdown normally. We need another bit for this exceptional release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor but you don't need more than what's in RFC 3473 than disabling alarms during the move of the resource associated to the CP to another enitity and the send a pathtear to remove the control plane state (you don't need to involve the CP in moving the data plane resource on each node) -d. "Bryskin, Igor" 25/08/2006 20:02 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in Path and Modify messages and is meant for disabling alarms before you starting LSP teardown. What we are talking about is nothing but a bit in PathTear message instructing resource manager on each node not to break cross-connects while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful deletion bit set in admin_status, then on each node the resource is associated to that entity (which is not a CP business) and then the control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 19:02:52 +0000 Message-Id: <7.0.1.0.2.20060825145814.041b1e60@labn.net> Date: Fri, 25 Aug 2006 15:02:30 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue - non-issue Cc: "Ong, Lyndon" ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Lou Berger" ,"Li, Han" , owner-ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Dimitri, not sure about past discussions, but you're characterization of (at least) my position is just plain wrong. I don't think this has anything to do with "unreliable control plane operations". As I said before, the requirement for this comes from the need to have a symmetric operation to gain acceptance by some carriers. From your previous mail, it sounds like you think this capability already exists. Given this, what's your objection here? Lou At 01:47 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >i agree on this CCAMP has/is building a self-consistent set of mechanisms >(from the start CCAMP considered that the MP has not being fallback >whatsover of the CP operations and in particular not linking any of its >operations to a particular MP) > >all what i am hearing from igor and co. is just penalizing the work of >this group achieved since 6 years without technical justification *** >there is no need for MP intervention in order to obtain CP operations >resiliency/reliability *** second time we have such discussion (look back >on the archive around end-october 2005, nov.2005 you will see there that >the same people already pushed forward the idea of unreliable control >plane operations - if someone's implementation is unstable/unreliable it >is not up to CCAMP to solve such issue and certainly not by interfering >with the MP) > >ps: add also add CP GR restart (from intermediate and source node) > >-d. > > > > >"Ong, Lyndon" >25/08/2006 19:22 > > To: "Brungard, Deborah A, ALABS" , "Farrel, >Adrian" > cc: "ccamp" , "Dan Li" , >"Diego Caviglia" , "Don Fedyk" >, "Drake, John E" , "Lou >Berger" , "Li, Han" , >, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, >"Bryskin, Igor" > Subject: RE: CP-->MP Issue - non-issue > > >Hi Folks, > >Just a bit worried that this discussion may be causing the impression >that >control plane is somehow unstable and requires some kind of special >backup! > >Deborah and other carrier representatives can attest that control plane >(although not necessarily standard GMPLS) has been deployed and in >operation >in a number of carrier networks for some years without experiencing any >major failures. There are already methods in use for ensuring the >reliability >of the control plane such as redundant control processors, non-volatile >storage of control plane data, software verification and testing, etc. > >I don't believe it was the intention of GMPLS work to require some kind >of >fallback to central management system control, hopefully everyone agrees >on this! > >Cheers, > >Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 18:58:10 +0000 Message-Id: <7.0.1.0.2.20060825145610.040bae68@labn.net> Date: Fri, 25 Aug 2006 14:57:37 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" ,owner-ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Dimitri, I agree that all is needed is a single bit. Unfortunately, the bits you mention are used for other purposes. (i.e., alarm free LSP deletion.) Lou At 01:34 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - i mean that in case an LSP for whatever reason needs to be moved >from the control plane to another place > >this is already covered in RFC 3473 - the LSP is signaled with graceful >deletion bit set in admin_status, then on each node the resource is >associated to that entity (which is not a CP business) and then the >control plane state is removed > >hope this clarifies, >-d. > > > > >Lou Berger >25/08/2006 19:25 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > I really don't understand your point. Can you restate/rephrase? > >Lou > >At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou > > > >resource are present (data plane state remains) the operation we're > >discussing about is local and consist in associating that resource to > >another entity - you GR the path because you don't want to generate >errors > >- but then that's it you just have to retrieve the CP state > > > >- d. > > > > > > > > > >Lou Berger > >25/08/2006 18:57 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > > >huh, why would there be no resources, i.e., data plane state, > >associated with the LSP? If this were the case, I agree the whole > >discussion would be moot. > > > >Lou > > > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou, > > > > > >like i replied to igor > > > > > >"entity X wants to recuperate a CP state - just let it do - if so >allowed > > > > > >then send a PathTear since there is no resource anymore associate to >that > > >state (but this does not require any specific documentation)" > > > > > >we would deleting a path/resv state for which no resource are allocated >- > > >we did already that exercise - GR deletion. > > > > > >much thanks, > > >-d. > > > > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 18:32 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" , > > >owner-ccamp@ops.ietf.org > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Dimitri, > > > Removing state should be a simple process of deleting local > > >control plane state while not impacting the data plane > > >state. Exporting, at least to me, implies a more complicated API or > > >other information transaction processing, which is certainly not needed > > >here. > > > > > >I think we're talking about a mechanism that should require a single > > >"preserve data plane" bit in a PathTear message. Nothing more. > > > > > >Lou > > > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - isn't "remove" or "export" having the same meaning in the >present > > > >context ? > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >Sent by: owner-ccamp@ops.ietf.org > > > >25/08/2006 17:57 > > > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > > cc: Lou Berger , "Farrel, Adrian" > > > >, "ccamp" , "Dan Li" > > > >, "Brungard, Deborah A, ALABS" , > > > >"Diego Caviglia" , "Don Fedyk" > > > >, "Bryskin, Igor" , "Drake, > >John > > > >E" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > >Who said anything about exporting state? > > > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > > > >lou - and why shall CCAMP provide a function to export states >outside > > >of > > > > >its domain of competence > > > > > > > > > >thanks, > > > > >- d. > > > > > > > > > > > > > > > > > > > > > > > > >Lou Berger > > > > >25/08/2006 17:49 > > > > > > > > > > To: "Don Fedyk" > > > > > cc: "Bryskin, Igor" , Dimitri > > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , > >"Farrel, > > > > >Adrian" , "ccamp" , > >"Brungard, > > > > >Deborah A, ALABS" , "Diego Caviglia" > > > > >, "Drake, John E" > > >, > > > > >"Lou Berger" , "Li, Han" > > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new > >WG > > > > >I-Ds) > > > > > > > > > > > > > > > > > > > >Don, > > > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > > >I think there may be something here but I think even the > >requirements > > > >as > > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > > > >Per my previous e-mail: > > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > > >>[...] > > > > > >>If we were to ask could you live without the CP->MP feature what > > > > > >>response would we get versus asking if CP->MP is a soft > >requirement. > > > > > > > > > > > > From the discussions I've had on this with carriers, for some >it's > > > > > > a don't care, for others they won't deploy control plane without > > > > > > this capability. > > > > > > > > > > > >Lou > > > > > > > > > >AND > > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > > >[...]I therefore think the definition of CP->MP *is* > > > > > >required. There are multiple options for meeting this >requirement, > > > > > >but the solution must provide the "fallback" capability for > >services > > > > > >existing at the time of the initial MP->CP transition and those > > > > > >created after the transition. > > > > >[...] > > > > > > > > > >I think a capability to remove LSP state while leaving forward >state > > > > >untouched will meet the requirements of those I've talked with. > > > > > > > > > >Lou > > > > > > > > > > >Regards, > > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 18:52:15 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 14:52:07 -0400 Message-ID: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIdtYcBaYBrR92TrCbBdoAqkz2HwAACfGw From: "Bryskin, Igor" To: Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Dimitri, No, it is not. D-bit was designed for a normal release. In normal = release CP is responsible for breaking cross-connects (for example to = avoid mis-connections during subsequent setups). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:46 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor - but it is exactly what happens the resource reservation = disappears=20 from the control plane viewpoint (after which a pathtear is sent to = remove=20 the control plane state) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 20:37 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We = do=20 graceful shutdown normally. We need another bit for this exceptional=20 release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor=20 but you don't need more than what's in RFC 3473 than disabling alarms=20 during the move of the resource associated to the CP to another enitity=20 and the send a pathtear to remove the control plane state (you don't = need=20 to involve the CP in moving the data plane resource on each node) -d. =20 "Bryskin, Igor" 25/08/2006 20:02 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger"=20 cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in = Path and Modify messages and is meant for disabling alarms before you=20 starting LSP teardown. What we are talking about is nothing but a bit in PathTear message=20 instructing resource manager on each node not to break cross-connects=20 while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved=20 from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful=20 deletion bit set in admin_status, then on each node the resource is=20 associated to that entity (which is not a CP business) and then the=20 control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian"=20 , "ccamp" , "Dan Li"=20 , "Brungard, Deborah A, ALABS" ,=20 "Diego Caviglia" , "Don Fedyk"=20 , "Bryskin, Igor" , "Drake, John = E" , "Li, Han" ,=20 owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, I really don't understand your point. Can you = restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate=20 errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, = John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so=20 allowed > > > >then send a PathTear since there is no resource anymore associate to=20 that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are = allocated=20 - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake,=20 John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not = needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the=20 present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" = , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states=20 outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" = > > > > Subject: RE: CP-->MP Issue (was RE: Polling for = new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature = what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some=20 it's > > > > > a don't care, for others they won't deploy control plane = without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this=20 requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward=20 state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 18:47:24 +0000 To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 20:46:13 +0200 Content-Type: text/plain; charset="US-ASCII" igor - but it is exactly what happens the resource reservation disappears from the control plane viewpoint (after which a pathtear is sent to remove the control plane state) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 20:37 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We do graceful shutdown normally. We need another bit for this exceptional release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor but you don't need more than what's in RFC 3473 than disabling alarms during the move of the resource associated to the CP to another enitity and the send a pathtear to remove the control plane state (you don't need to involve the CP in moving the data plane resource on each node) -d. "Bryskin, Igor" 25/08/2006 20:02 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in Path and Modify messages and is meant for disabling alarms before you starting LSP teardown. What we are talking about is nothing but a bit in PathTear message instructing resource manager on each node not to break cross-connects while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful deletion bit set in admin_status, then on each node the resource is associated to that entity (which is not a CP business) and then the control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 18:37:44 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 14:37:34 -0400 Message-ID: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIdHhzG6CMahZuSbivfVroZeq0gQAAGHUg From: "Bryskin, Igor" To: Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Dimitri, We use D-bit for graceful shutdown. D-bit means prepare for delete. We = do graceful shutdown normally. We need another bit for this exceptional = release (without breaking cross-connects). Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:29 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) igor=20 but you don't need more than what's in RFC 3473 than disabling alarms=20 during the move of the resource associated to the CP to another enitity=20 and the send a pathtear to remove the control plane state (you don't = need=20 to involve the CP in moving the data plane resource on each node) -d. =20 "Bryskin, Igor" 25/08/2006 20:02 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger"=20 cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Lou Berger" , "Li, Han"=20 , Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in = Path and Modify messages and is meant for disabling alarms before you=20 starting LSP teardown. What we are talking about is nothing but a bit in PathTear message=20 instructing resource manager on each node not to break cross-connects=20 while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved=20 from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful=20 deletion bit set in admin_status, then on each node the resource is=20 associated to that entity (which is not a CP business) and then the=20 control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian"=20 , "ccamp" , "Dan Li"=20 , "Brungard, Deborah A, ALABS" ,=20 "Diego Caviglia" , "Don Fedyk"=20 , "Bryskin, Igor" , "Drake, John = E" , "Li, Han" ,=20 owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, I really don't understand your point. Can you = restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate=20 errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, = John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so=20 allowed > > > >then send a PathTear since there is no resource anymore associate to=20 that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are = allocated=20 - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake,=20 John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not = needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the=20 present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" = , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states=20 outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" = > > > > Subject: RE: CP-->MP Issue (was RE: Polling for = new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature = what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some=20 it's > > > > > a don't care, for others they won't deploy control plane = without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this=20 requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward=20 state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 18:30:30 +0000 To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 20:29:11 +0200 Content-Type: text/plain; charset="US-ASCII" igor but you don't need more than what's in RFC 3473 than disabling alarms during the move of the resource associated to the CP to another enitity and the send a pathtear to remove the control plane state (you don't need to involve the CP in moving the data plane resource on each node) -d. "Bryskin, Igor" 25/08/2006 20:02 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Lou Berger" cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in Path and Modify messages and is meant for disabling alarms before you starting LSP teardown. What we are talking about is nothing but a bit in PathTear message instructing resource manager on each node not to break cross-connects while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful deletion bit set in admin_status, then on each node the resource is associated to that entity (which is not a CP business) and then the control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 18:03:38 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 14:02:59 -0400 Message-ID: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIbYkdWY7SUqeAQiOvYqw7Gz4sfAAAnAog From: "Bryskin, Igor" To: , "Lou Berger" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Dimitri, graceful deletion bit set in admin_status you mentioned about is sent in = Path and Modify messages and is meant for disabling alarms before you = starting LSP teardown. What we are talking about is nothing but a bit in PathTear message = instructing resource manager on each node not to break cross-connects = while LSP resources are removed. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 1:35 PM To: Lou Berger Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) lou - i mean that in case an LSP for whatever reason needs to be moved=20 from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful=20 deletion bit set in admin_status, then on each node the resource is=20 associated to that entity (which is not a CP business) and then the=20 control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian"=20 , "ccamp" , "Dan Li"=20 , "Brungard, Deborah A, ALABS" ,=20 "Diego Caviglia" , "Don Fedyk"=20 , "Bryskin, Igor" , "Drake, John = E" , "Li, Han" ,=20 owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Dimitri, I really don't understand your point. Can you = restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate=20 errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, = John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so=20 allowed > > > >then send a PathTear since there is no resource anymore associate to=20 that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are = allocated=20 - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake,=20 John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not = needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the=20 present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" = , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new = WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states=20 outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" = > > > > Subject: RE: CP-->MP Issue (was RE: Polling for = new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature = what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some=20 it's > > > > > a don't care, for others they won't deploy control plane = without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this=20 requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward=20 state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 17:54:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Fri, 25 Aug 2006 13:53:48 -0400 Message-ID: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIaD2eROz0I1iPSaqoZMHZXnKQlwABv0JQ From: "Zafar Ali \(zali\)" To: , "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , DKIM-Signature: a=rsa-sha1; q=dns; l=7461; t=1156528432; x=1157392432; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20 |Subject:RE=3A=20CP-->MP=20Issue=20(was=20RE=3A=20Polling=20for=20new=20WG=20I-Ds ) |To:,=20=22Bryskin,=20Igor=22=20; X=v=3Dcisco.com=3B=20h=3Dz6UyJTvl3VVlsfvqhIIjqjqqZdk=3D; b=ZWQgOtbuyHTmATj3zl2DjGcQhGNtoHwANb2p9cgJLuUmEasC1w/1halwoq29QJggO2ZaZjnD JdzvLqw+xD7r1gG1Z3ySspajR2/XL67LFyK1o7m6cXS6P9S6zipmpdtI; Authentication-Results: rtp-dkim-2.cisco.com; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com verified; ); > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > Dimitri.Papadimitriou@alcatel.be > Sent: Friday, August 25, 2006 1:01 PM > To: Bryskin, Igor > Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,=20 > ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger;=20 > Li, Han; owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 > i totally disagree you constantly referring to the MP while=20 > CCAMP has NEVER linked control operations to MP operations -=20 > these MP operations assumptions are outside scope of CCAMP=20 >=20 I agree with Dimitri. Also Don mentioned a good point that there is no standard MP. I am not sure why we should pursue this any further.=20 Thanks Regards.. Zafar=20 > in part. we are going to enter into a discussion for which we=20 > won't get the bird out of the bush: addressing space between=20 > CP and MP it took us more or less 4 years to disambiguate the=20 > DP address space relationship with the CP and there is no=20 > reason to start an endless debate now with the MP >=20 > -d. >=20 > =20 >=20 >=20 >=20 >=20 >=20 > "Bryskin, Igor" > Sent by: owner-ccamp@ops.ietf.org > 25/08/2006 18:39 > =20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Farrel, Adrian" , "ccamp"=20 > , "Dan Li" , "Brungard,=20 > Deborah A, ALABS" , "Diego Caviglia"=20 > , "Don Fedyk"=20 > , "Drake, John E"=20 > , "Lou Berger" ,=20 > "Li, Han"=20 > , > Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 > I-Ds) >=20 >=20 >=20 > Approximate scenarios: >=20 > a) MP->CP scenario: >=20 > MP provides CP with complete ERO (including labels) CP=20 > signals SETUP with an IN-PLACE attribute, this causes=20 > provisioning operations on each node without re-programming=20 > cross-connects MP releases resource ownership after the=20 > operation by some means >=20 > b) CP->MP scenario: >=20 > MP receives from CP complete RRO (including labels) MP=20 > assumes resource ownership operation by some means CP signals=20 > TEARDOWN with an IN-PLACE attribute, this causes release by=20 > CP resources on each node without re-programming cross-connects >=20 > Igor >=20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Friday, August 25, 2006 12:18 PM > To: Bryskin, Igor > Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A,=20 > ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger;=20 > Li, Han; owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 >=20 > you are asking for something outside the scope of ccamp >=20 > entity X wants to recuperate a CP state - just let it do - if=20 > so allowed >=20 > then send a PathTear since there is no resource anymore=20 > associate to that state (but this does not require any=20 > specific documentation) >=20 > -d. >=20 >=20 >=20 >=20 >=20 > "Bryskin, Igor" > Sent by: owner-ccamp@ops.ietf.org > 25/08/2006 18:06 > =20 > To: "Lou Berger" , Dimitri=20 > PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Farrel, Adrian" , "ccamp"=20 > , "Dan Li" , "Brungard,=20 > Deborah A, ALABS" , "Diego Caviglia"=20 > ,=20 >=20 > "Don Fedyk" , "Drake, John E"=20 > , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 > I-Ds) >=20 >=20 > Agree with Lou. >=20 > Can I also quote my own email? :=3D) >=20 > "We are > talking here about a capability of CP to acquire network=20 > resources and build CP state for an LSP without actually=20 > re-programming crossconnects (case MP->CP). Likewise, we are=20 > talking about capability of CP to release resources and=20 > destroy CP state for an LSP without re-programming=20 > crossconnects (case CP->MP). It is out of scope of those=20 > mechanisms how MP (or any other plane) assumes or yields the=20 > ownership of resources of the LSP whose ownership is=20 > transferred from/to CP." >=20 > So I think we are talking about two relatively simple and=20 > very symmetrical=20 >=20 > CP functions. >=20 > Igor >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 25, 2006 11:57 AM > To: Dimitri.Papadimitriou@alcatel.be > Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard,=20 > Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor;=20 > Drake, John E; Li, Han > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 >=20 > Who said anything about exporting state? >=20 > At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > >lou - and why shall CCAMP provide a function to export=20 > states outside=20 > >of its domain of competence > > > >thanks, > >- d. > > > > > > > > > >Lou Berger > >25/08/2006 17:49 > > > > To: "Don Fedyk" > > cc: "Bryskin, Igor" , Dimitri > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li"=20 > , "Farrel,=20 > >Adrian" , "ccamp" ,=20 > "Brungard,=20 > >Deborah A, ALABS" , "Diego Caviglia" > >, "Drake, John E"=20 > >, "Lou Berger" ,=20 > "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling=20 > for new WG > >I-Ds) > > > > > > > >Don, > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > >I think there may be something here but I think even the=20 > requirements > as > > >stated assume too much of the solution. What is the real issue? > > > >Per my previous e-mail: > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > >>[...] > > >>If we were to ask could you live without the CP->MP feature what=20 > > >>response would we get versus asking if CP->MP is a soft=20 > requirement. > > > > > > From the discussions I've had on this with carriers, for=20 > some it's a=20 > > > don't care, for others they won't deploy control plane=20 > without this=20 > > > capability. > > > > > >Lou > > > >AND > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > >[...]I therefore think the definition of CP->MP *is*=20 > required. There=20 > > >are multiple options for meeting this requirement, but the=20 > solution=20 > > >must provide the "fallback" capability for services=20 > existing at the=20 > > >time of the initial MP->CP transition and those created after the=20 > > >transition. > >[...] > > > >I think a capability to remove LSP state while leaving forward state=20 > >untouched will meet the requirements of those I've talked with. > > > >Lou > > > > >Regards, > > >Don >=20 >=20 >=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 17:48:22 +0000 To: "Ong, Lyndon" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue - non-issue MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 19:47:15 +0200 Content-Type: text/plain; charset="US-ASCII" i agree on this CCAMP has/is building a self-consistent set of mechanisms (from the start CCAMP considered that the MP has not being fallback whatsover of the CP operations and in particular not linking any of its operations to a particular MP) all what i am hearing from igor and co. is just penalizing the work of this group achieved since 6 years without technical justification *** there is no need for MP intervention in order to obtain CP operations resiliency/reliability *** second time we have such discussion (look back on the archive around end-october 2005, nov.2005 you will see there that the same people already pushed forward the idea of unreliable control plane operations - if someone's implementation is unstable/unreliable it is not up to CCAMP to solve such issue and certainly not by interfering with the MP) ps: add also add CP GR restart (from intermediate and source node) -d. "Ong, Lyndon" 25/08/2006 19:22 To: "Brungard, Deborah A, ALABS" , "Farrel, Adrian" cc: "ccamp" , "Dan Li" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Bryskin, Igor" Subject: RE: CP-->MP Issue - non-issue Hi Folks, Just a bit worried that this discussion may be causing the impression that control plane is somehow unstable and requires some kind of special backup! Deborah and other carrier representatives can attest that control plane (although not necessarily standard GMPLS) has been deployed and in operation in a number of carrier networks for some years without experiencing any major failures. There are already methods in use for ensuring the reliability of the control plane such as redundant control processors, non-volatile storage of control plane data, software verification and testing, etc. I don't believe it was the intention of GMPLS work to require some kind of fallback to central management system control, hopefully everyone agrees on this! Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 17:40:54 +0000 To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , Lou Berger , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 19:34:43 +0200 Content-Type: text/plain; charset="US-ASCII" lou - i mean that in case an LSP for whatever reason needs to be moved from the control plane to another place this is already covered in RFC 3473 - the LSP is signaled with graceful deletion bit set in admin_status, then on each node the resource is associated to that entity (which is not a CP business) and then the control plane state is removed hope this clarifies, -d. Lou Berger 25/08/2006 19:25 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 17:26:24 +0000 Message-Id: <7.0.1.0.2.20060825132455.04fcb008@labn.net> Date: Fri, 25 Aug 2006 13:25:41 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" ,owner-ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Dimitri, I really don't understand your point. Can you restate/rephrase? Lou At 01:03 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou > >resource are present (data plane state remains) the operation we're >discussing about is local and consist in associating that resource to >another entity - you GR the path because you don't want to generate errors >- but then that's it you just have to retrieve the CP state > >- d. > > > > >Lou Berger >25/08/2006 18:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > >huh, why would there be no resources, i.e., data plane state, >associated with the LSP? If this were the case, I agree the whole >discussion would be moot. > >Lou > >At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou, > > > >like i replied to igor > > > >"entity X wants to recuperate a CP state - just let it do - if so allowed > > > >then send a PathTear since there is no resource anymore associate to that > >state (but this does not require any specific documentation)" > > > >we would deleting a path/resv state for which no resource are allocated - > >we did already that exercise - GR deletion. > > > >much thanks, > >-d. > > > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 18:32 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" , > >owner-ccamp@ops.ietf.org > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Dimitri, > > Removing state should be a simple process of deleting local > >control plane state while not impacting the data plane > >state. Exporting, at least to me, implies a more complicated API or > >other information transaction processing, which is certainly not needed > >here. > > > >I think we're talking about a mechanism that should require a single > >"preserve data plane" bit in a PathTear message. Nothing more. > > > >Lou > > > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - isn't "remove" or "export" having the same meaning in the present > > >context ? > > > > > > > > > > > > > > >Lou Berger > > >Sent by: owner-ccamp@ops.ietf.org > > >25/08/2006 17:57 > > > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > > cc: Lou Berger , "Farrel, Adrian" > > >, "ccamp" , "Dan Li" > > >, "Brungard, Deborah A, ALABS" , > > >"Diego Caviglia" , "Don Fedyk" > > >, "Bryskin, Igor" , "Drake, >John > > >E" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > >Who said anything about exporting state? > > > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > > > >lou - and why shall CCAMP provide a function to export states outside > >of > > > >its domain of competence > > > > > > > >thanks, > > > >- d. > > > > > > > > > > > > > > > > > > > >Lou Berger > > > >25/08/2006 17:49 > > > > > > > > To: "Don Fedyk" > > > > cc: "Bryskin, Igor" , Dimitri > > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , >"Farrel, > > > >Adrian" , "ccamp" , >"Brungard, > > > >Deborah A, ALABS" , "Diego Caviglia" > > > >, "Drake, John E" > >, > > > >"Lou Berger" , "Li, Han" > > > > Subject: RE: CP-->MP Issue (was RE: Polling for new >WG > > > >I-Ds) > > > > > > > > > > > > > > > >Don, > > > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > > >I think there may be something here but I think even the >requirements > > >as > > > > >stated assume too much of the solution. What is the real issue? > > > > > > > >Per my previous e-mail: > > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > > >>[...] > > > > >>If we were to ask could you live without the CP->MP feature what > > > > >>response would we get versus asking if CP->MP is a soft >requirement. > > > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > > a don't care, for others they won't deploy control plane without > > > > > this capability. > > > > > > > > > >Lou > > > > > > > >AND > > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > > >[...]I therefore think the definition of CP->MP *is* > > > > >required. There are multiple options for meeting this requirement, > > > > >but the solution must provide the "fallback" capability for >services > > > > >existing at the time of the initial MP->CP transition and those > > > > >created after the transition. > > > >[...] > > > > > > > >I think a capability to remove LSP state while leaving forward state > > > >untouched will meet the requirements of those I've talked with. > > > > > > > >Lou > > > > > > > > >Regards, > > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 17:04:27 +0000 To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , Lou Berger , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 19:03:32 +0200 Content-Type: text/plain; charset="US-ASCII" lou resource are present (data plane state remains) the operation we're discussing about is local and consist in associating that resource to another entity - you GR the path because you don't want to generate errors - but then that's it you just have to retrieve the CP state - d. Lou Berger 25/08/2006 18:57 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, huh, why would there be no resources, i.e., data plane state, associated with the LSP? If this were the case, I agree the whole discussion would be moot. Lou At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou, > >like i replied to igor > >"entity X wants to recuperate a CP state - just let it do - if so allowed > >then send a PathTear since there is no resource anymore associate to that >state (but this does not require any specific documentation)" > >we would deleting a path/resv state for which no resource are allocated - >we did already that exercise - GR deletion. > >much thanks, >-d. > > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 18:32 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > Removing state should be a simple process of deleting local >control plane state while not impacting the data plane >state. Exporting, at least to me, implies a more complicated API or >other information transaction processing, which is certainly not needed >here. > >I think we're talking about a mechanism that should require a single >"preserve data plane" bit in a PathTear message. Nothing more. > >Lou > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou - isn't "remove" or "export" having the same meaning in the present > >context ? > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 17:57 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Who said anything about exporting state? > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - and why shall CCAMP provide a function to export states outside >of > > >its domain of competence > > > > > >thanks, > > >- d. > > > > > > > > > > > > > > >Lou Berger > > >25/08/2006 17:49 > > > > > > To: "Don Fedyk" > > > cc: "Bryskin, Igor" , Dimitri > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, > > >Adrian" , "ccamp" , "Brungard, > > >Deborah A, ALABS" , "Diego Caviglia" > > >, "Drake, John E" >, > > >"Lou Berger" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > > > > >Don, > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > >I think there may be something here but I think even the requirements > >as > > > >stated assume too much of the solution. What is the real issue? > > > > > >Per my previous e-mail: > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > >>[...] > > > >>If we were to ask could you live without the CP->MP feature what > > > >>response would we get versus asking if CP->MP is a soft requirement. > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > a don't care, for others they won't deploy control plane without > > > > this capability. > > > > > > > >Lou > > > > > >AND > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > >[...]I therefore think the definition of CP->MP *is* > > > >required. There are multiple options for meeting this requirement, > > > >but the solution must provide the "fallback" capability for services > > > >existing at the time of the initial MP->CP transition and those > > > >created after the transition. > > >[...] > > > > > >I think a capability to remove LSP state while leaving forward state > > >untouched will meet the requirements of those I've talked with. > > > > > >Lou > > > > > > >Regards, > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 17:02:07 +0000 To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 19:01:14 +0200 Content-Type: text/plain; charset="US-ASCII" i totally disagree you constantly referring to the MP while CCAMP has NEVER linked control operations to MP operations - these MP operations assumptions are outside scope of CCAMP in part. we are going to enter into a discussion for which we won't get the bird out of the bush: addressing space between CP and MP it took us more or less 4 years to disambiguate the DP address space relationship with the CP and there is no reason to start an endless debate now with the MP -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:39 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Approximate scenarios: a) MP->CP scenario: MP provides CP with complete ERO (including labels) CP signals SETUP with an IN-PLACE attribute, this causes provisioning operations on each node without re-programming cross-connects MP releases resource ownership after the operation by some means b) CP->MP scenario: MP receives from CP complete RRO (including labels) MP assumes resource ownership operation by some means CP signals TEARDOWN with an IN-PLACE attribute, this causes release by CP resources on each node without re-programming cross-connects Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 12:18 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) you are asking for something outside the scope of ccamp entity X wants to recuperate a CP state - just let it do - if so allowed then send a PathTear since there is no resource anymore associate to that state (but this does not require any specific documentation) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:06 To: "Lou Berger" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Agree with Lou. Can I also quote my own email? :=) "We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP." So I think we are talking about two relatively simple and very symmetrical CP functions. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, August 25, 2006 11:57 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 16:58:02 +0000 Message-Id: <7.0.1.0.2.20060825125519.0331b1e0@labn.net> Date: Fri, 25 Aug 2006 12:57:23 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" ,owner-ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Dimitri, huh, why would there be no resources, i.e., data plane state, associated with the LSP? If this were the case, I agree the whole discussion would be moot. Lou At 12:48 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou, > >like i replied to igor > >"entity X wants to recuperate a CP state - just let it do - if so allowed > >then send a PathTear since there is no resource anymore associate to that >state (but this does not require any specific documentation)" > >we would deleting a path/resv state for which no resource are allocated - >we did already that exercise - GR deletion. > >much thanks, >-d. > > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 18:32 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" , >owner-ccamp@ops.ietf.org > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Dimitri, > Removing state should be a simple process of deleting local >control plane state while not impacting the data plane >state. Exporting, at least to me, implies a more complicated API or >other information transaction processing, which is certainly not needed >here. > >I think we're talking about a mechanism that should require a single >"preserve data plane" bit in a PathTear message. Nothing more. > >Lou > >At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou - isn't "remove" or "export" having the same meaning in the present > >context ? > > > > > > > > > >Lou Berger > >Sent by: owner-ccamp@ops.ietf.org > >25/08/2006 17:57 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: Lou Berger , "Farrel, Adrian" > >, "ccamp" , "Dan Li" > >, "Brungard, Deborah A, ALABS" , > >"Diego Caviglia" , "Don Fedyk" > >, "Bryskin, Igor" , "Drake, John > >E" , "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > >Who said anything about exporting state? > > > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > > > >lou - and why shall CCAMP provide a function to export states outside >of > > >its domain of competence > > > > > >thanks, > > >- d. > > > > > > > > > > > > > > >Lou Berger > > >25/08/2006 17:49 > > > > > > To: "Don Fedyk" > > > cc: "Bryskin, Igor" , Dimitri > > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, > > >Adrian" , "ccamp" , "Brungard, > > >Deborah A, ALABS" , "Diego Caviglia" > > >, "Drake, John E" >, > > >"Lou Berger" , "Li, Han" > > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > > >I-Ds) > > > > > > > > > > > >Don, > > > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > > >I think there may be something here but I think even the requirements > >as > > > >stated assume too much of the solution. What is the real issue? > > > > > >Per my previous e-mail: > > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > > >>[...] > > > >>If we were to ask could you live without the CP->MP feature what > > > >>response would we get versus asking if CP->MP is a soft requirement. > > > > > > > > From the discussions I've had on this with carriers, for some it's > > > > a don't care, for others they won't deploy control plane without > > > > this capability. > > > > > > > >Lou > > > > > >AND > > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > > >[...]I therefore think the definition of CP->MP *is* > > > >required. There are multiple options for meeting this requirement, > > > >but the solution must provide the "fallback" capability for services > > > >existing at the time of the initial MP->CP transition and those > > > >created after the transition. > > >[...] > > > > > >I think a capability to remove LSP state while leaving forward state > > >untouched will meet the requirements of those I've talked with. > > > > > >Lou > > > > > > >Regards, > > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 16:49:57 +0000 To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , Lou Berger , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 18:48:47 +0200 Content-Type: text/plain; charset="US-ASCII" lou, like i replied to igor "entity X wants to recuperate a CP state - just let it do - if so allowed then send a PathTear since there is no resource anymore associate to that state (but this does not require any specific documentation)" we would deleting a path/resv state for which no resource are allocated - we did already that exercise - GR deletion. much thanks, -d. Lou Berger Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:32 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, Removing state should be a simple process of deleting local control plane state while not impacting the data plane state. Exporting, at least to me, implies a more complicated API or other information transaction processing, which is certainly not needed here. I think we're talking about a mechanism that should require a single "preserve data plane" bit in a PathTear message. Nothing more. Lou At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - isn't "remove" or "export" having the same meaning in the present >context ? > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 17:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Who said anything about exporting state? > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou - and why shall CCAMP provide a function to export states outside of > >its domain of competence > > > >thanks, > >- d. > > > > > > > > > >Lou Berger > >25/08/2006 17:49 > > > > To: "Don Fedyk" > > cc: "Bryskin, Igor" , Dimitri > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, > >Adrian" , "ccamp" , "Brungard, > >Deborah A, ALABS" , "Diego Caviglia" > >, "Drake, John E" , > >"Lou Berger" , "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > > > >Don, > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > >I think there may be something here but I think even the requirements >as > > >stated assume too much of the solution. What is the real issue? > > > >Per my previous e-mail: > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > >>[...] > > >>If we were to ask could you live without the CP->MP feature what > > >>response would we get versus asking if CP->MP is a soft requirement. > > > > > > From the discussions I've had on this with carriers, for some it's > > > a don't care, for others they won't deploy control plane without > > > this capability. > > > > > >Lou > > > >AND > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > >[...]I therefore think the definition of CP->MP *is* > > >required. There are multiple options for meeting this requirement, > > >but the solution must provide the "fallback" capability for services > > >existing at the time of the initial MP->CP transition and those > > >created after the transition. > >[...] > > > >I think a capability to remove LSP state while leaving forward state > >untouched will meet the requirements of those I've talked with. > > > >Lou > > > > >Regards, > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 16:40:00 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 12:39:44 -0400 Message-ID: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIYjsRcz+oOArsRyiT5jniBM/3fAAAaJVg From: "Bryskin, Igor" To: Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , Approximate scenarios: a) MP->CP scenario: MP provides CP with complete ERO (including labels) CP signals SETUP with an IN-PLACE attribute, this causes provisioning = operations on each node without re-programming cross-connects MP releases resource ownership after the operation by some means b) CP->MP scenario: MP receives from CP complete RRO (including labels) MP assumes resource ownership operation by some means CP signals TEARDOWN with an IN-PLACE attribute, this causes release by = CP resources on each node without re-programming cross-connects Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 12:18 PM To: Bryskin, Igor Cc: Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Drake, John E; Lou Berger; Li, Han; owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) you are asking for something outside the scope of ccamp entity X wants to recuperate a CP state - just let it do - if so allowed then send a PathTear since there is no resource anymore associate to = that=20 state (but this does not require any specific documentation) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:06 =20 To: "Lou Berger" , Dimitri=20 PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp"=20 , "Dan Li" , "Brungard, Deborah A, = ALABS" , "Diego Caviglia" = ,=20 "Don Fedyk" , "Drake, John E"=20 , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Agree with Lou. Can I also quote my own email? :=3D) "We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to = release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how = MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP." So I think we are talking about two relatively simple and very = symmetrical=20 CP functions. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, August 25, 2006 11:57 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside = of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" = , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements = as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 16:32:32 +0000 Message-Id: <7.0.1.0.2.20060825122626.03bf75b8@labn.net> Date: Fri, 25 Aug 2006 12:32:06 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" ,owner-ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Dimitri, Removing state should be a simple process of deleting local control plane state while not impacting the data plane state. Exporting, at least to me, implies a more complicated API or other information transaction processing, which is certainly not needed here. I think we're talking about a mechanism that should require a single "preserve data plane" bit in a PathTear message. Nothing more. Lou At 12:14 PM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - isn't "remove" or "export" having the same meaning in the present >context ? > > > > >Lou Berger >Sent by: owner-ccamp@ops.ietf.org >25/08/2006 17:57 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Lou Berger , "Farrel, Adrian" >, "ccamp" , "Dan Li" >, "Brungard, Deborah A, ALABS" , >"Diego Caviglia" , "Don Fedyk" >, "Bryskin, Igor" , "Drake, John >E" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > >Who said anything about exporting state? > >At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: > > >lou - and why shall CCAMP provide a function to export states outside of > >its domain of competence > > > >thanks, > >- d. > > > > > > > > > >Lou Berger > >25/08/2006 17:49 > > > > To: "Don Fedyk" > > cc: "Bryskin, Igor" , Dimitri > >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, > >Adrian" , "ccamp" , "Brungard, > >Deborah A, ALABS" , "Diego Caviglia" > >, "Drake, John E" , > >"Lou Berger" , "Li, Han" > > Subject: RE: CP-->MP Issue (was RE: Polling for new WG > >I-Ds) > > > > > > > >Don, > > > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > > >I think there may be something here but I think even the requirements >as > > >stated assume too much of the solution. What is the real issue? > > > >Per my previous e-mail: > >At 01:01 PM 8/24/2006, Lou Berger wrote: > > > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > > >>[...] > > >>If we were to ask could you live without the CP->MP feature what > > >>response would we get versus asking if CP->MP is a soft requirement. > > > > > > From the discussions I've had on this with carriers, for some it's > > > a don't care, for others they won't deploy control plane without > > > this capability. > > > > > >Lou > > > >AND > >At 08:15 AM 8/24/2006, Lou Berger wrote: > > >[...]I therefore think the definition of CP->MP *is* > > >required. There are multiple options for meeting this requirement, > > >but the solution must provide the "fallback" capability for services > > >existing at the time of the initial MP->CP transition and those > > >created after the transition. > >[...] > > > >I think a capability to remove LSP state while leaving forward state > >untouched will meet the requirements of those I've talked with. > > > >Lou > > > > >Regards, > > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 16:22:03 +0000 To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Lou Berger" , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 18:18:13 +0200 Content-Type: text/plain; charset="US-ASCII" you are asking for something outside the scope of ccamp entity X wants to recuperate a CP state - just let it do - if so allowed then send a PathTear since there is no resource anymore associate to that state (but this does not require any specific documentation) -d. "Bryskin, Igor" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 18:06 To: "Lou Berger" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Agree with Lou. Can I also quote my own email? :=) "We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP." So I think we are talking about two relatively simple and very symmetrical CP functions. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, August 25, 2006 11:57 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 16:16:10 +0000 To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , Lou Berger , "Li, Han" , owner-ccamp@ops.ietf.org Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 18:14:04 +0200 Content-Type: text/plain; charset="US-ASCII" lou - isn't "remove" or "export" having the same meaning in the present context ? Lou Berger Sent by: owner-ccamp@ops.ietf.org 25/08/2006 17:57 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Lou Berger , "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 16:06:58 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 12:06:41 -0400 Message-ID: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIXzEgiOx/bjfcRUm1ZWU6eueqtgAALTag From: "Bryskin, Igor" To: "Lou Berger" , Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Drake, John E" , "Li, Han" Agree with Lou. Can I also quote my own email? :=3D) "We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to = release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how = MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP." So I think we are talking about two relatively simple and very = symmetrical CP functions. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, August 25, 2006 11:57 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Lou Berger; Farrel, Adrian; ccamp; Dan Li; Brungard, Deborah A, ALABS; Diego Caviglia; Don Fedyk; Bryskin, Igor; Drake, John E; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside = of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" = , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements = as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 15:57:32 +0000 Message-Id: <7.0.1.0.2.20060825115636.04eeaea0@labn.net> Date: Fri, 25 Aug 2006 11:57:08 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: Lou Berger ,"Farrel, Adrian" , "ccamp" ,"Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" ,"Bryskin, Igor" , "Drake, John E" , "Li, Han" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Who said anything about exporting state? At 11:51 AM 8/25/2006, Dimitri.Papadimitriou@alcatel.be wrote: >lou - and why shall CCAMP provide a function to export states outside of >its domain of competence > >thanks, >- d. > > > > >Lou Berger >25/08/2006 17:49 > > To: "Don Fedyk" > cc: "Bryskin, Igor" , Dimitri >PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, >Adrian" , "ccamp" , "Brungard, >Deborah A, ALABS" , "Diego Caviglia" >, "Drake, John E" , >"Lou Berger" , "Li, Han" > Subject: RE: CP-->MP Issue (was RE: Polling for new WG >I-Ds) > > > >Don, > >At 10:40 AM 8/25/2006, Don Fedyk wrote: > >I think there may be something here but I think even the requirements as > >stated assume too much of the solution. What is the real issue? > >Per my previous e-mail: >At 01:01 PM 8/24/2006, Lou Berger wrote: > > >At 10:48 AM 8/24/2006, Don Fedyk wrote: > >>[...] > >>If we were to ask could you live without the CP->MP feature what > >>response would we get versus asking if CP->MP is a soft requirement. > > > > From the discussions I've had on this with carriers, for some it's > > a don't care, for others they won't deploy control plane without > > this capability. > > > >Lou > >AND >At 08:15 AM 8/24/2006, Lou Berger wrote: > >[...]I therefore think the definition of CP->MP *is* > >required. There are multiple options for meeting this requirement, > >but the solution must provide the "fallback" capability for services > >existing at the time of the initial MP->CP transition and those > >created after the transition. >[...] > >I think a capability to remove LSP state while leaving forward state >untouched will meet the requirements of those I've talked with. > >Lou > > >Regards, > >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 15:53:01 +0000 To: Lou Berger Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Don Fedyk" , "Bryskin, Igor" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 17:51:38 +0200 Content-Type: text/plain; charset="US-ASCII" lou - and why shall CCAMP provide a function to export states outside of its domain of competence thanks, - d. Lou Berger 25/08/2006 17:49 To: "Don Fedyk" cc: "Bryskin, Igor" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" , "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Don, At 10:40 AM 8/25/2006, Don Fedyk wrote: >I think there may be something here but I think even the requirements as >stated assume too much of the solution. What is the real issue? Per my previous e-mail: At 01:01 PM 8/24/2006, Lou Berger wrote: >At 10:48 AM 8/24/2006, Don Fedyk wrote: >>[...] >>If we were to ask could you live without the CP->MP feature what >>response would we get versus asking if CP->MP is a soft requirement. > > From the discussions I've had on this with carriers, for some it's > a don't care, for others they won't deploy control plane without > this capability. > >Lou AND At 08:15 AM 8/24/2006, Lou Berger wrote: >[...]I therefore think the definition of CP->MP *is* >required. There are multiple options for meeting this requirement, >but the solution must provide the "fallback" capability for services >existing at the time of the initial MP->CP transition and those >created after the transition. [...] I think a capability to remove LSP state while leaving forward state untouched will meet the requirements of those I've talked with. Lou >Regards, >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 15:51:15 +0000 To: "Bryskin, Igor" Cc: "Farrel, Adrian" , "ccamp" , "Dan Li" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Fedyk, Don" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 17:49:17 +0200 Content-Type: text/plain; charset="US-ASCII" igor point a) i don't say that the CP import requires MP intervention - i just say this is the only case that requires specification from CCAMP perspective point b) then operators askes to his new fashioned MP to implement an import function - why shall CCAMP care about exporting CP states ? -d. "Bryskin, Igor" 25/08/2006 15:47 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Dan Li" cc: "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Fedyk, Don" , "Drake, John E" , "Lou Berger" , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Dimitri, My understanding of the MP->CP migration process failure and it's "back-out" requirement is as follows: a) immediate failure of creating CP state for the services provisioned by MP. This failure does not require CP->MP feature b) initial migration MP->CP succeeded, however, after some time (say, 1 month) of provisioning via CP (and possibly creating many services solely via CP), provider decides that CP is not good or mature enough and wants go back to old-fashioned MP provisioning. I don't see how the operator will not loose these new services without the CP->MP function. With all due respect the call on CP->MP function is provider's - not yours/Alcatel, mine/Movaz or John's/ Boeing. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:51 AM To: Dan Li Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) hi - here below a couple of comments o) the first point and i think i mention this already is that at the end speaking about MP in the present context restricts applicability of the "migration", the purpose of this draft is to create a control plane state when the same resources are already in use by an entity external to the control plane - call this an "import" function o) the second when you write "Our main requirement for CP->MP migration is to handle "back-out" of the MP->CP migration process." is on itself confusing; what are you dealing with ? that the transition fails during its instantiation or that once LSP has a control plane state you want to move back where it used to belong - the former is a real issue that has never been discussed - the second is a non-issue (the other entity takes care to rapatriate the state in case, i don't think there is any need for an "export" function simple because we are not going to tell to which entity the LSP shall be brought back as we can have many of those) o) the third point is when you mention "Modifying and tearing down LSPs after control plane failure" i pointed already that a migration from CP to somewhere else is impossible if you don't get access to the CP iself in particular if it is under failure - doesn't seem to be understood by authors (yet) thanks, - d. Dan Li 25/08/2006 03:59 To: ccamp cc: "Li, Han" , "Fedyk, Don" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego Caviglia , Igor Bryskin , "Farrel, Adrian" , Lou Berger , "Brungard, Deborah A, ALABS" , "Drake, John E" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Hi all, The main motivation for this work is MP->CP migration. Our objective is to be able to introduce a control plane into an existing network without disrupting user traffic. We understand that there are operators who would not want to perform this function. They might prefer to set up parallel LSPs using the CP and swap trafic to them before tearing down the MP LSPs, but we believe that this will not be possible in many busy networks. Other operators may prefer to have a network outage, but this will not be acceptable for all other operators. Therefore, in order to ensure interoperability between different vendors' equipment, we believe that a GMPLS process is required for this function. We fully expect it to be quite a simple process. Our main requirement for CP->MP migration is to handle "back-out" of the MP->CP migration process. If there is some problem, the operator would like to be able to return to how things were before hand (i.e. MP control), without disrupting user traffic. We regard this as highly desirable, but probably not a mandatory requirement. Modifying and tearing down LSPs after control plane failure is also a possible motivation, but the detailed requirements will need further examination. As has been pointed out, tear-down may be achieved relatively simply. But modification (for example, re-routing, increase in capacity, etc.) may be more complicated. Other uses of CP->MP migration are interesting, but are not our main motivation, but we would like to observe that if the features that meet our requirements can also be used for other purposes then that is OK. Obviously, from the discussions on the mailing list, our I-D does not currently present a sufficiently focused description of the motivation for this work. We welcome further discussion of the requirements to help us improve the draft. It would be helpful in your discussions if you could understand that we are describing the requirements. If it turns out that the requirements can be met without changing the protocols, then we are very happy. But if you believe that no changes to the protocols are needed, we still need to state the requirements. So perhaps our conversation should be about the functional requirements not about the solutions. Best regards, Dan Li Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 15:51:07 +0000 Message-Id: <7.0.1.0.2.20060825114514.046e3658@labn.net> Date: Fri, 25 Aug 2006 11:49:26 -0400 To: "Don Fedyk" From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: "Bryskin, Igor" ,, "Dan Li" ,"Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" ,"Li, Han" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Don, At 10:40 AM 8/25/2006, Don Fedyk wrote: >I think there may be something here but I think even the requirements as >stated assume too much of the solution. What is the real issue? Per my previous e-mail: At 01:01 PM 8/24/2006, Lou Berger wrote: >At 10:48 AM 8/24/2006, Don Fedyk wrote: >>[...] >>If we were to ask could you live without the CP->MP feature what >>response would we get versus asking if CP->MP is a soft requirement. > > From the discussions I've had on this with carriers, for some it's > a don't care, for others they won't deploy control plane without > this capability. > >Lou AND At 08:15 AM 8/24/2006, Lou Berger wrote: >[...]I therefore think the definition of CP->MP *is* >required. There are multiple options for meeting this requirement, >but the solution must provide the "fallback" capability for services >existing at the time of the initial MP->CP transition and those >created after the transition. [...] I think a capability to remove LSP state while leaving forward state untouched will meet the requirements of those I've talked with. Lou >Regards, >Don Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 15:21:45 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 11:21:26 -0400 Message-ID: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIEu+IUIQ+96hTQbqJkeo36FBC9wAN5EcAAAGuI2AAAXhSAA== From: "Bryskin, Igor" To: "Don Fedyk" , , "Dan Li" Cc: "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" , "Li, Han" Hi Don, > My understanding of the MP->CP migration process failure and=20 > it's "back-out" requirement is as follows: >=20 > a) immediate failure of creating CP state for the services=20 > provisioned by MP. This failure does not require CP->MP feature > b) initial migration MP->CP succeeded, however, after some=20 > time (say, 1 month) of provisioning via CP (and possibly=20 > creating many services solely via CP), provider decides that=20 > CP is not good or mature enough and wants go back to=20 > old-fashioned MP provisioning. I don't see how the operator=20 > will not loose these new services without the CP->MP function. I get the feeling we are grasping here. The providers usually have a staging and evaluation phase in a test bed before deploying a new feature like a control plane. If they decide they don't want it never goes live.=20 IB>> One could argue that problems (and very serious ones) could be well = hidden and could be discovered at any time. Also running production = network is not the same as running test bed. Besides, to a large extent = it could be purely psychological issue: as Diego put it "I always need a = parachute when I try a new plane no matter how good is this plane: no = parachute - no deal" What is the difference between a MP based connection and CP based connection with a static ERO and no backup?=20 IB>> The difference is which plane owns the connection, meaning, what = tools operator uses to, say, modify or release the connection. It is not = about path computation, so whether ERO is static or not is irrelevant. I would think a better goal would be to make such a static version as good as a management plane version.=20 >=20 > With all due respect the call on CP->MP function is=20 > provider's - not yours/Alcatel, mine/Movaz or John's/ Boeing. So the providers should be writing the requirement document rather than us trying to reverse engineer the root of the problem. =20 I think there may be something here but I think even the requirements as stated assume too much of the solution. What is the real issue? IB>> The real issue (and I'd say the biggest GMPLS problem at the moment = and for some time already) is operator's nervousness deploying the GMPLS = and we need to do everything that could improve their comfort level and = confidence. Cheers, Igor Regards, Don=20 >=20 > Igor >=20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Friday, August 25, 2006 2:51 AM > To: Dan Li > Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego=20 > Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou=20 > Berger; Li, Han > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 >=20 > hi - here below a couple of comments >=20 > o) the first point and i think i mention this already is that=20 > at the end speaking about MP in the present context restricts=20 > applicability of the "migration", the purpose of this draft=20 > is to create a control plane state when the same resources=20 > are already in use by an entity external to the control plane=20 > - call this an "import" function >=20 > o) the second when you write "Our main requirement for CP->MP=20 > migration is to handle "back-out" of the MP->CP migration=20 > process." is on itself confusing; what are you dealing with ?=20 > that the transition fails during its instantiation or that=20 > once LSP has a control plane state you want to move back=20 > where it used to belong - the former is a real issue that has=20 > never been discussed - the second is a non-issue (the other=20 > entity takes care to rapatriate the state in case, i don't=20 > think there is any need for an "export" function simple=20 > because we are not going to tell to which entity the LSP=20 > shall be brought back as we can have many of those) >=20 > o) the third point is when you mention "Modifying and tearing=20 > down LSPs after control plane failure" i pointed already that=20 > a migration from CP to somewhere else is impossible if you=20 > don't get access to the CP iself in particular if it is under=20 > failure - doesn't seem to be understood by authors (yet) >=20 > thanks, > - d. >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 15:02:46 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'Exclude Routes - Extension to RSVP-TE' to Proposed Standard (draft-ietf-ccamp-rsvp-te-exclude-route) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Fri, 25 Aug 2006 11:02:23 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Exclude Routes - Extension to RSVP-TE ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.txt Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 14:50:34 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'Extensions to GMPLS RSVP Graceful Restart' to Proposed Standard (draft-ietf-ccamp-rsvp-restart-ext) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Fri, 25 Aug 2006 10:50:02 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Extensions to GMPLS RSVP Graceful Restart ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-05.txt Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 14:40:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Fri, 25 Aug 2006 10:40:01 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A3AB60A@zrtphxm2.corp.nortel.com> Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIEu+IUIQ+96hTQbqJkeo36FBC9wAN5EcAAAGuI2A= From: "Don Fedyk" To: "Bryskin, Igor" , , "Dan Li" Cc: "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Drake, John E" , "Lou Berger" , "Li, Han" Hi Igor > -----Original Message----- >=20 > Dimitri, >=20 > My understanding of the MP->CP migration process failure and=20 > it's "back-out" requirement is as follows: >=20 > a) immediate failure of creating CP state for the services=20 > provisioned by MP. This failure does not require CP->MP feature > b) initial migration MP->CP succeeded, however, after some=20 > time (say, 1 month) of provisioning via CP (and possibly=20 > creating many services solely via CP), provider decides that=20 > CP is not good or mature enough and wants go back to=20 > old-fashioned MP provisioning. I don't see how the operator=20 > will not loose these new services without the CP->MP function. I get the feeling we are grasping here. The providers usually have a staging and evaluation phase in a test bed before deploying a new feature like a control plane. If they decide they don't want it never goes live.=20 What is the difference between a MP based connection and CP based connection with a static ERO and no backup? I would think a better goal would be to make such a static version as good as a management plane version.=20 >=20 > With all due respect the call on CP->MP function is=20 > provider's - not yours/Alcatel, mine/Movaz or John's/ Boeing. So the providers should be writing the requirement document rather than us trying to reverse engineer the root of the problem. =20 I think there may be something here but I think even the requirements as stated assume too much of the solution. What is the real issue? Regards, Don=20 >=20 > Igor >=20 > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Friday, August 25, 2006 2:51 AM > To: Dan Li > Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego=20 > Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou=20 > Berger; Li, Han > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 >=20 > hi - here below a couple of comments >=20 > o) the first point and i think i mention this already is that=20 > at the end speaking about MP in the present context restricts=20 > applicability of the "migration", the purpose of this draft=20 > is to create a control plane state when the same resources=20 > are already in use by an entity external to the control plane=20 > - call this an "import" function >=20 > o) the second when you write "Our main requirement for CP->MP=20 > migration is to handle "back-out" of the MP->CP migration=20 > process." is on itself confusing; what are you dealing with ?=20 > that the transition fails during its instantiation or that=20 > once LSP has a control plane state you want to move back=20 > where it used to belong - the former is a real issue that has=20 > never been discussed - the second is a non-issue (the other=20 > entity takes care to rapatriate the state in case, i don't=20 > think there is any need for an "export" function simple=20 > because we are not going to tell to which entity the LSP=20 > shall be brought back as we can have many of those) >=20 > o) the third point is when you mention "Modifying and tearing=20 > down LSPs after control plane failure" i pointed already that=20 > a migration from CP to somewhere else is impossible if you=20 > don't get access to the CP iself in particular if it is under=20 > failure - doesn't seem to be understood by authors (yet) >=20 > thanks, > - d. >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 13:48:13 +0000 content-class: urn:content-classes:message Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 09:47:06 -0400 Message-ID: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbIEu+IUIQ+96hTQbqJkeo36FBC9wAN5EcA From: "Bryskin, Igor" To: , "Dan Li" Cc: "Farrel, Adrian" , "ccamp" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Fedyk, Don" , "Drake, John E" , "Lou Berger" , "Li, Han" Dimitri, My understanding of the MP->CP migration process failure and it's = "back-out" requirement is as follows: a) immediate failure of creating CP state for the services provisioned = by MP. This failure does not require CP->MP feature b) initial migration MP->CP succeeded, however, after some time (say, 1 = month) of provisioning via CP (and possibly creating many services = solely via CP), provider decides that CP is not good or mature enough = and wants go back to old-fashioned MP provisioning. I don't see how the = operator will not loose these new services without the CP->MP function. With all due respect the call on CP->MP function is provider's - not = yours/Alcatel, mine/Movaz or John's/ Boeing. Igor -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Friday, August 25, 2006 2:51 AM To: Dan Li Cc: Farrel, Adrian; ccamp; Brungard, Deborah A, ALABS; Diego Caviglia; Fedyk, Don; Bryskin, Igor; Drake, John E; Lou Berger; Li, Han Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) hi - here below a couple of comments o) the first point and i think i mention this already is that at the end = speaking about MP in the present context restricts applicability of the=20 "migration", the purpose of this draft is to create a control plane = state=20 when the same resources are already in use by an entity external to the=20 control plane - call this an "import" function o) the second when you write "Our main requirement for CP->MP migration = is=20 to handle "back-out" of the MP->CP migration process." is on itself=20 confusing; what are you dealing with ? that the transition fails during=20 its instantiation or that once LSP has a control plane state you want to = move back where it used to belong - the former is a real issue that has=20 never been discussed - the second is a non-issue (the other entity takes = care to rapatriate the state in case, i don't think there is any need = for=20 an "export" function simple because we are not going to tell to which=20 entity the LSP shall be brought back as we can have many of those) o) the third point is when you mention "Modifying and tearing down LSPs=20 after control plane failure" i pointed already that a migration from CP = to=20 somewhere else is impossible if you don't get access to the CP iself in=20 particular if it is under failure - doesn't seem to be understood by=20 authors (yet) thanks, - d. Dan Li 25/08/2006 03:59 =20 To: ccamp cc: "Li, Han" , "Fedyk, Don"=20 , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego=20 Caviglia , Igor Bryskin = ,=20 "Farrel, Adrian" , Lou Berger ,=20 "Brungard, Deborah A, ALABS" , "Drake, John E"=20 Subject: RE: CP-->MP Issue (was RE: Polling for new WG=20 I-Ds) Hi all, The main motivation for this work is MP->CP migration. Our objective is = to=20 be able to introduce a control plane into an existing network without=20 disrupting user traffic. We understand that there are operators who would not want to perform = this=20 function. They might prefer to set up parallel LSPs using the CP and = swap=20 trafic to them before tearing down the MP LSPs, but we believe that this = will not be possible in many busy networks. Other operators may prefer = to=20 have a network outage, but this will not be acceptable for all other=20 operators.=20 Therefore, in order to ensure interoperability between different = vendors'=20 equipment, we believe that a GMPLS process is required for this = function.=20 We=20 fully expect it to be quite a simple process. Our main requirement for CP->MP migration is to handle "back-out" of the = MP->CP migration process. If there is some problem, the operator would=20 like=20 to be able to return to how things were before hand (i.e. MP control),=20 without disrupting user traffic. We regard this as highly desirable, but = probably not a mandatory requirement. Modifying and tearing down LSPs after control plane failure is also a=20 possible motivation, but the detailed requirements will need further=20 examination. As has been pointed out, tear-down may be achieved = relatively=20 simply. But modification (for example, re-routing, increase in capacity, = etc.) may be more complicated. Other uses of CP->MP migration are interesting, but are not our main=20 motivation, but we would like to observe that if the features that meet=20 our=20 requirements can also be used for other purposes then that is OK. Obviously, from the discussions on the mailing list, our I-D does not=20 currently present a sufficiently focused description of the motivation = for=20 this work. We welcome further discussion of the requirements to help us=20 improve the draft. It would be helpful in your discussions if you could understand that we=20 are=20 describing the requirements. If it turns out that the requirements can = be=20 met without changing the protocols, then we are very happy. But if you=20 believe that no changes to the protocols are needed, we still need to=20 state=20 the requirements. So perhaps our conversation should be about the=20 functional=20 requirements not about the solutions. Best regards, Dan Li Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 09:26:29 +0000 To: "Diego Caviglia" Cc: ibryskin@movaz.com, ccamp@ops.ietf.org, lberger@labn.net Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 11:25:46 +0200 Content-Type: text/plain; charset="US-ASCII" diego - i think this has been mentioned a couple of times - there is no need to make any assumption about MP whatsover in the context of CP capability we're discussing here - discussion deviated due to the context where the present i-d has been discussed this i-d shall just focus on an import functionality of an already allocated resource (without making assumption on its current owner) this turns out that there is no possibility to have a revertive behaviour as from CP -> X, as the former won't keep track of this origin the only thing this i-d could mention is that the previous owner Y may wish to provide from its own import functionality such as to allow CP -> Y transition thanks, - d. "Diego Caviglia" Sent by: owner-ccamp@ops.ietf.org 25/08/2006 10:56 To: ibryskin@movaz.com cc: "Don Fedyk" , "Lou Berger" , "Diego Caviglia" , Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Igor, what you say is exactly what we had in mind thinking about the ID. Regards Diego "Bryskin, Igor" on 24/08/2006 18.09.36 To: "Don Fedyk" , "Lou Berger" , "Diego Caviglia" cc: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Don, > The other point that baffles me is there is not one "standard" MP that > I'm aware of so really we are talking many variations of MP to a > standard CP. So how do you define a CP to variations of MPs? The > document currently oversimplifies this aspect IMHO. I don't think we need to assume that MP is standard in the context of CP->MP and MP->CP discussion. IMO it does not even have to be MP. We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP.. Igor > -----Original Message----- > > Diego, > In my experience in talking about this feature with > carriers is that some (but not all) will require such > symmetric behavior. I think the other rational for this > feature are irrelevant. Again, the sole reason I've seen for > this requirement is that to deploy MP->CP some will require > that there be support for CP->MP. > > I therefore think the definition of CP->MP *is* required. > There are multiple options for meeting this requirement, but > the solution must provide the "fallback" capability for > services existing at the time of the initial MP->CP > transition and those created after the transition. > > I think a SHOULD level requirement is sufficient for this > capability, but I'd be interested if those representing > carries on the list differ. > > Lou > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > > > >In my mind the CP->MP feature can be useful for mainly two purposes: > >1) symmetricity with the companion feature (MP->CP) > >[...] > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a > >must and I have no problem to move it to should/shall/may state. > > > >[...] > >However the focus of the ID is on MP->CP handover and if the > community > >is strongly against of CP->MP even in the form of a should/shall/may > >requirement we can strip this out. > > > >Regards > > > >Diego > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 08:58:49 +0000 Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: ibryskin@movaz.com Cc: ""Don Fedyk" , ""Lou Berger" , ""Diego Caviglia" , " Message-ID: From: "Diego Caviglia" Date: Fri, 25 Aug 2006 10:56:35 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Igor, what you say is exactly what we had in mind thinking about the ID. Regards Diego "Bryskin, Igor" on 24/08/2006 18.09.36 To: "Don Fedyk" , "Lou Berger" , "Diego Caviglia" cc: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Don, > The other point that baffles me is there is not one "standard" MP that > I'm aware of so really we are talking many variations of MP to a > standard CP. So how do you define a CP to variations of MPs? The > document currently oversimplifies this aspect IMHO. I don't think we need to assume that MP is standard in the context of CP->MP and MP->CP discussion. IMO it does not even have to be MP. We are talking here about a capability of CP to acquire network resources and build CP state for an LSP without actually re-programming crossconnects (case MP->CP). Likewise, we are talking about capability of CP to release resources and destroy CP state for an LSP without re-programming crossconnects (case CP->MP). It is out of scope of those mechanisms how MP (or any other plane) assumes or yields the ownership of resources of the LSP whose ownership is transferred from/to CP.. Igor > -----Original Message----- > > Diego, > In my experience in talking about this feature with > carriers is that some (but not all) will require such > symmetric behavior. I think the other rational for this > feature are irrelevant. Again, the sole reason I've seen for > this requirement is that to deploy MP->CP some will require > that there be support for CP->MP. > > I therefore think the definition of CP->MP *is* required. > There are multiple options for meeting this requirement, but > the solution must provide the "fallback" capability for > services existing at the time of the initial MP->CP > transition and those created after the transition. > > I think a SHOULD level requirement is sufficient for this > capability, but I'd be interested if those representing > carries on the list differ. > > Lou > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > > > >In my mind the CP->MP feature can be useful for mainly two purposes: > >1) symmetricity with the companion feature (MP->CP) > >[...] > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a > >must and I have no problem to move it to should/shall/may state. > > > >[...] > >However the focus of the ID is on MP->CP handover and if the > community > >is strongly against of CP->MP even in the form of a should/shall/may > >requirement we can strip this out. > > > >Regards > > > >Diego > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 08:49:10 +0000 To: =?gb2312?B?wO7qzw==?= Cc: "'Adrian Farrel'" , ccamp@ops.ietf.org, "'Dan Li'" , owner-ccamp@ops.ietf.org Subject: Re: =?gb2312?B?tPC4tDogUG9sbGluZyBmb3IgbmV3IFdHIEktRHM=?= MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 10:48:03 +0200 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGkgLSANCg0Kb24gcG9pbnQgMSkgYmVmb3JlIHRoaW5raW5nIGFib3V0IHVuZG8ncyAmIHJlZG8n cyB0aGUgZmlyc3QgaXNzdWUgaXMgdG8gDQpjb25zaWRlciB0aGF0IGR1cmluZyB0aGUgImltcG9y dCIgb2YgdGhlIGFsbG9jYXRlZCByZXNvdXJjZSAtPiBDUCBzdGF0ZSANCnlvdSBtYXkgaGF2ZSBh IGZhaWx1cmUgYXQgdGhhdCBwb2ludCBpbiB0aW1lIGluIHRoZSBwcm9jZXNzIC0NCg0Kb24gcG9p bnQgMikgaW4gY2FzZSBvZiBDUCBmYWlsdXJlIC0gaW5jbHVkaW5nIHVucmVzcG9uc2l2ZSBDUCBp bnN0YW5jZSAtIGkgDQpkb24ndCBzZWUgaG93IHlvdSBtYXkgdHJpZ2dlciB0aGUgQ1AgdG8gImV4 cG9ydCIgdGhhdCBzdGF0ZQ0KDQp0aGFua3MsDQotIGQuDQoNCg0KDQoNCg0KwO7qzyA8bGloYW5A Y2hpbmFtb2JpbGUuY29tPg0KMjUvMDgvMjAwNiAwMjo1Mw0KIA0KICAgICAgICBUbzogICAgIERp bWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwsICInRGFuIExpJyIgDQo8ZGFu bGlAaHVhd2VpLmNvbT4NCiAgICAgICAgY2M6ICAgICAiJ0FkcmlhbiBGYXJyZWwnIiA8YWRyaWFu QG9sZGRvZy5jby51az4sIA0KPGNjYW1wQG9wcy5pZXRmLm9yZz4sIDxvd25lci1jY2FtcEBvcHMu aWV0Zi5vcmc+DQogICAgICAgIFN1YmplY3Q6ICAgICAgICC08Li0OiBQb2xsaW5nIGZvciBuZXcg V0cgSS1Ecw0KDQoNCg0KSGksDQoNCkZyb20gb3VyIHBlcnNwZWN0aXZlLCB3ZSB0aGluayB0aGUg Zm9sbG93aW5nIHJlcXVpcmVtZW50cyBhcmUgYmV0dGVyIHRvIGJlDQpjb25zaWRlcmVkOg0KDQox KSBJbiBjYXNlIHRoZXJlIGlzIGEgcHJvYmxlbSBhZnRlciB3ZSBkbyBNUC0+Q1AgbW92ZW1lbnQs IHdlIHdvdWxkIGxpa2UgDQp0bw0KYmUgYWJsZSB0byByZXR1cm4gdG8gdGhlIHByZXZpb3VzIHN0 YXRlLiBTbyB0aGUgTVAtPkNQIHByb2NlZHVyZSBtdXN0IGJlDQplcXVpcHBlZCB3aXRoIGEgYmFj ay1vdXQgcHJvY2VkdXJlIHNvIHRoYXQgd2UgY2FuIHJldmVyc2UgdGhlIHByb2NlZHVyZS4NClRo aXMgInVuZG8iIGZ1bmN0aW9uIGFsbG93cyB0cmFuc2ZlciBvZiBjb250cm9sIGZyb20gQ1AtPk1Q Lg0KDQoyKSBJbiB0aGUgZXZlbnQgb2YgYSBDUCBmYWlsdXJlIChzdWNoIGFzIHRoZSBmYWlsdXJl IG9mIHRoZSBjb250cm9sIHBsYW5lIA0KYXQNCmEgbm9kZSksIHdlIG1heSB3aXNoIHRvIGNvbnRy b2wgdGhlIExTUCBhbmQgdGhpcyByZXF1aXJlcyB0aGF0IHRoZSBMU1AgaXMNCnRyYW5zZmVycmVk IGZyb20gdGhlIENQIHRvIHRoZSBNUC4NCg0KUmVnYXJkcywgDQoNCkxpaGFuDQoNCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCkxpIEhhbiwg UGguRC4NCg0KUiZELCBDSElOQSBNT0JJTEUgQ09NTVVOSUNBVElPTlMgQ09SUE9SQVRJT04NCg0K VGVsOiArODYgMTAgNjYwMDY2ODggZXh0LiAzMDkyDQoNCkZheDogKzg2IDEwIDYzNjAwMzQwDQoN Ck1PQklMRTogMTM1MDEwOTMzODUNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCg0KaGkgLSANCg0Kc2VlIGlubGluZQ0KDQoNCg0KDQoNCkRh biBMaSA8ZGFubGlAaHVhd2VpLmNvbT4NClNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9y Zw0KMjEvMDgvMjAwNiAwNDowMQ0KIA0KICAgICAgICBUbzogICAgIERpbWl0cmkgUEFQQURJTUlU UklPVS9CRS9BTENBVEVMQEFMQ0FURUwsIEFkcmlhbiBGYXJyZWwgDQo8YWRyaWFuQG9sZGRvZy5j by51az4NCiAgICAgICAgY2M6ICAgICBjY2FtcEBvcHMuaWV0Zi5vcmcsIG93bmVyLWNjYW1wQG9w cy5pZXRmLm9yZw0KICAgICAgICBTdWJqZWN0OiAgICAgICAgUmU6IFBvbGxpbmcgZm9yIG5ldyBX RyBJLURzDQoNCg0KSGkgRGltaXRyaSwNCg0KUGxlYXNlIHNlZSBpbiBsaW5lLg0KDQpSZWdhcmRz LA0KDQpEYW4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206IDxEaW1pdHJp LlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZT4NClRvOiAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBv bGRkb2cuY28udWs+DQpDYzogPGNjYW1wQG9wcy5pZXRmLm9yZz47IDxvd25lci1jY2FtcEBvcHMu aWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDE3LCAyMDA2IDY6MzIgQU0NClN1Ympl Y3Q6IFJlOiBQb2xsaW5nIGZvciBuZXcgV0cgSS1Ecw0KDQoNCj4gYWRyaWFuIC0gc2VlIGluLWxp bmUNCj4gDQo+IEFkcmlhbiBGYXJyZWwgd3JvdGU6DQo+ID4gSGksDQo+ID4gDQo+ID4gQXMgZGlz Y3Vzc2VkIGluIE1vbnRyZWFsLCB3ZSBuZWVkIHRvIHBvbGwgZm9yIGEgY291cGxlIG9mIG5ldyBX RyANCmRyYWZ0cy4NCj4gPiANCj4gPiANCj4gDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1iZXJuc3RlaW4tY2NhbXAtZ21wbHMtdmNhdC1sY2FzLTA0DQoNCi50eHQg DQoNCj4gDQo+ID4gaGFzIGJlZW4gdXBkYXRlZCBieSB0aGUgYXV0aG9ycyB0byBwcm92aWRlIGZ1 cnRoZXIgZGV0YWlscyBhbmQgDQo+ID4gY2xhcmlmaWNhdGlvbi4NCj4gDQo+IC0gb2sgLSANCj4g DQo+ID4gDQo+IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2F2 aWdsaWEtY2NhbXAtcGMtYW5kLXNjLXJlcXMtMDIudA0KDQp4dA0KDQo+IA0KPiAtIGd1ZXNzIGl0 IGlzIHYwMy50eHQgPyAtDQo+IA0KPiA+IGhhcyBiZWVuIHVwZGF0ZWQgc2luY2UgdGhlIHZlcnNp b24gZGlzY3Vzc2VkIGluIE1vbnRyZWFsLg0KPiANCj4gaSBhbSBvayBpbiBpbnZlc3RpZ2F0aW5n IHRoZSBNUC0+Q1AgYnV0IGkgaGF2ZSB0d28gY29uY2VybnMgdGhhdCBpbWhvIA0KPiBzaG91bGQg ZGVzZXJ2ZSBtb3JlIHNwZWNpZmljIGF0dGVudGlvbiB0byBtYWludGFpbiBjb25zaXN0ZW5jeSB3 cnQgdG8gDQo+IENQLT5NUA0KPiANCj4gc2VjdGlvbiAyLjI6IGlmIGNvbnRyb2wgaXMgbG9zdCBm b3IgYW4gTFNQIChkdXJpbmcgQ1AgZmFpbHVyZSkgaG93IGNhbiANCml0IA0KPiBiZSBwb3NzaWJs ZSB0cmFuc2ZlciB0aGF0IExTUCBmcm9tIHRoZSBDUCAtPiBNUCA/IA0KDQpbZGFuXSBZZXMsIHRo ZXJlIGlzIGEgcHJvYmxlbSBpZiB3ZSBzdGlsbCB3YW50IHRvIHVzZSB0aGUgY29udHJvbCBwbGFu ZSB0byANCg0KZG8gdGhlIA0KQ1AtPk1QIHRyYW5zZmVyLiBVbmxlc3MgdGhlIHRyYW5zZmVyIGlz IGJhc2VkIG9uIHRoZSBwcmVkZXRlcm1pbmVkIHBvbGljeSwgDQoNCk1QIA0KdGFrZXMgdGhlIGNv bnRyb2wgb2YgdGhlIExTUCByZXNvdXJjZSBkaXJlY3RseSAobm8gc2lnbmFsaW5nIHJlcXVpcmVk KSwgDQpidXQgdGhpcyB3YXkNCnNob3VsZCBub3QgYmUgZGlzY3Vzc2VkIGluIENDQU1QLg0KDQpb ZHBdIG9rIHNvIHdoYXQncyBsZWZ0IGZvciB0aGlzIGRvYyA/IGNvbmNlcm5pbmcgdGhlIE1QLWRy aXZlbiBmYWlsb3ZlciAtIA0KaW1obyBub3RoaW5nDQogDQo+IHNlY3Rpb24gNC40OiB3aHkgdGhl IGRvY3VtZW50IGFzc3VtZXMgdGhhdCBib3RoIE1VU1QgYmUgc3VwcG9ydGVkID8gaW4gDQo+IHBh cnQuIGNvbmNlcm5pbmcgdGhlIENQLT5NUCBpZiBvbmUgZG9lcyBpbXBsZW1lbnQgY3VycmVudCBH TVBMUyANCnNpZ25hbGluZyANCj4gcmVzdGFydC9yZWNvdmVyeSB3aHkgc2hhbGwgdGhpcyBiZSBt YW5kYXRlZCA/IGluIGJyaWVmLCB0aGUgZG9jdW1lbnQgDQpzaGFsbCANCj4gdGFrZSBpbnRvIGFj Y291bnQgZXhpc3RpbmcgbWVjaGFuaXNtcyBhbmQgcHJldmVudCBvdmVybGFwcyAod2l0aCANCmV4 aXN0aW5nIA0KPiBHTVBMUyBtZWNoYW5pc21zKQ0KPiANCltkYW5dIEkgdGhpbmsgdGhlIENQLT5N UCBzaG91bGQgbm90IGJlIHRoZSBtYW5kYXRvcnkgcmVxdWlyZW1lbnQuDQoNCltkcF0gdGhpcyBp cyB3aGF0IGkgdGhvdWdodA0KDQo+IGhlbmNlLCBpdCBpcyBzdHJvbmdseSBzdWdnZXN0ZWQgdG8g aWRlbnRpZnkgY29uZGl0aW9ucyB3aGVuIHN1Y2ggQ1AtPk1QIA0KaXMgDQo+IHJlcXVpcmVkIChh bmQgbm90IGFuIGFsdGVybmF0aXZlIHRvIGV4aXN0aW5nIENQIG1lY2hhbmlzbXMpIGIvZiANCj4g cHJvZ3Jlc3NpbmcgdGhhdCBwYXJ0DQo+IA0KW2Rhbl0gSW4gb3JkZXIgdG8gbWFrZSB0aGUgY2Fy cmllcnMnIGxpZmUgZWFzeSwgd2hlbiB3ZSBwcm92aWRlIHRoZSBNUC0+Q1ANCmNvbnZlcnNpb24g ZmVhdHVyZSwgdGhlIHJldmVyc2UgcHJvY2VkdXJlIChDUC0+TVApIG1heSBhbHNvIGlzIG5lZWRl ZCBqdXN0DQpzaW1wbHkgaW4gY2FzZSB0aGUgY2FycmllcnMgd2FudCB0byB3aXRoZHJhdyB0aGVp ciBwcmV2aW91cyBkZWNpc2lvbiwgYW5kDQp0aGV5IGFsc28gZmVlbCBtb3JlIGNvbWZvcnRhYmxl IHdpdGggdGhpcyAidW5kbyIgZnVuY3Rpb247IEluIG9yZGVyIHRvIA0KYWNoaWV2ZQ0KdGhpcywg d2Ugc2hvdWxkIGhhdmUgdGhlIHdvcmtpbmcgY29udHJvbCBwbGFuZS4gDQoNCltkcF0gY29uY2Vy bmluZyBDUC0+TVAgaW5wdXQgeW91IHByb3ZpZGVkIHdvdWxkIGJlIGhlbHBmdWwgdG8gaGF2ZSAN CmNhcnJpZXIncyANCnNwZWFraW5nIGZvciB0aGVtc2VsdmVzIC0gbm93IHRoZXJlIGlzIGluZGVl ZCBhIHNpZGUgcXVlc3Rpb24gc2hhbGwgQ0NBTVAgDQp0YWtlDQpjYXJlIGFib3V0IG9wZXJhdG9y cyB0aGF0IHdhbnQgdG8gc3RlcCBiYWNrIGZyb20gR01QTFMgb3IgbW9yZSBnZW5lcmFsbHkgDQph bnkNCmNvbnRyb2wgcGxhbmUgdGVjaG5vbG9neSAodXN1YWxseSBjb25jZXJuIGlzIGhvdyB0byBt b3ZlIGZvcndhcmQgbm90IA0KYmFja3dhcmQpDQoNCiANCj4gDQpodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hbGktY2NhbXAtbXBscy1ncmFjZWZ1bC1zaHV0ZG93bi0w DQoNCjQudHh0IA0KDQo+IA0KPiA+IGhhcyBiZWVuIHVwZGF0ZWQgYXMgWmFmYXIgc2F5cyBpbiBo aXMgcHJldmlvdXMgZW1haWwuDQo+IA0KPiBpbmZvcm1hdGlvbmFsIGltaG8gLSBpbiBpdHMgY3Vy cmVudCB2ZXJzaW9uIA0KPiANCj4gLSBub3Qgc3VyZSB0byB1bmRlcnN0YW5kIHdoeSB0aGUgUGF0 aEVyci9Ob3RpZnkgY2FuIGJlIHByb2Nlc3NlZCBieSB0aGUgDQo+IGhlYWQtZW5kIG9ubHkgKHdo YXQgYWJvdXQgc2VnbWVudCByZWNvdmVyeSBhbmQgc3RpdGNoaW5nIGNhc2UpIC0gd2h5IA0Kb25s eSANCj4gTUJCIGlzIHBvc3NpYmxlIHVwb24gcmVjZXB0aW9uIChwbHMgdXNlIEUyRSByZWNvdmVy eS9TZWdtZW50IHJlY292ZXJ5IA0KPiBjYXBhYmlsaXRpZXMgYXMgeW91IGFkZHJlc3MgR01QTFMg bmV0d29ya3MpDQo+IA0KPiAtIGNvbXBhcmVkIHRvIHBhdGgtcmVvcHQsIGVycm9yIGRlc2NyaXB0 aW9uIGlzIGlkZW50aWNhbCBmb3IgdGhlIFRFIGxpbmsgDQoNCg0KPiBjYXNlIHdoaWNoIGxlYWRz IHRvIHRoZSBmb2xsb3dpbmcgcG9pbnQgLSBpZiBlcnJvcnMgY29kZS92YWx1ZSBhcmUgdGhlIA0K PiBzYW1lIGhvdyB0byBkaXN0aW5ndWlzaCB0aGVtIChhc3N1bWluZyB0aGF0IHRoZSBxdWVyeSBw cm9jZWR1cmUgDQpkZXNjcmliZWQgDQo+IGluIHBhdGgtcmVvcHQgaXMgdXNlZCBkdXJpbmcgdGhl IHNldHVwIG9mIHRoYXQgTFNQKSA/IC0gY29tbWVudCBpcyBtb3JlIA0KPiBmb3IgdGhlIHBhdGgt cmVvcHQgZHJhZnQgdGhhbiB5b3VycyBidXQgc2luY2UgdGhlcmUgaXMgYW4gb3ZlcmxhcCAuLi4g aXQgDQoNCg0KPiBtdXN0IGJlIGFkZHJlc3NlZCBpbiBhIHdheSBvciBhbm90aGVyIChub3RlIHRo YXQgd2hlbiBmdWxseSBoZWFkLWVuZCANCj4gZHJpdmVuIG9wZXJhdGlvbnMgbG9vayBzaW1pbGFy IGJ1dCB0aGVyZSBpcyBhIG1ham9yIGRpZmZlcmVuY2Ugcm9sZSBvZiANCj4gdGltaW5nIGFuZCBz ZXZlcml0eSBvZiB0aGUgZXJyb3IgY29kZS92YWx1ZSkgDQo+IA0KPiAtIGluIGNhc2Ugc2h1dGRv d24gb2YgYSBwcm90ZWN0ZWQgY29tcG9uZW50IGxpbmsgKG9mIGEgYnVuZGxlKSBpcyANCj4gaW5p dGlhdGVkIHdoeSBjYW4ndCBsaW5rIHByb3RlY3Rpb24gYmUgdXNlZCA/DQo+IA0KPiA+IFBsZWFz ZSBzZW5kIHllcyBvciBubyBmb3IgdGhlc2UgSS1Ecy4NCj4gPiANCj4gPiBSZWFzb25zIGFuZCBv cGluaW9ucyBhcmUgYWxzbyB3ZWxjb21lZC4NCj4gPiANCj4gPiBUaGFua3MsDQo+ID4gQWRyaWFu IA0KPiANCj4gDQoNCg0KDQoNCg0KDQoNCg== Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 06:53:22 +0000 To: Dan Li Cc: "Farrel, Adrian" , ccamp , "Brungard, Deborah A, ALABS" , Diego Caviglia , "Fedyk, Don" , Igor Bryskin , "Drake, John E" , Lou Berger , "Li, Han" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 25 Aug 2006 08:51:12 +0200 Content-Type: text/plain; charset="US-ASCII" hi - here below a couple of comments o) the first point and i think i mention this already is that at the end speaking about MP in the present context restricts applicability of the "migration", the purpose of this draft is to create a control plane state when the same resources are already in use by an entity external to the control plane - call this an "import" function o) the second when you write "Our main requirement for CP->MP migration is to handle "back-out" of the MP->CP migration process." is on itself confusing; what are you dealing with ? that the transition fails during its instantiation or that once LSP has a control plane state you want to move back where it used to belong - the former is a real issue that has never been discussed - the second is a non-issue (the other entity takes care to rapatriate the state in case, i don't think there is any need for an "export" function simple because we are not going to tell to which entity the LSP shall be brought back as we can have many of those) o) the third point is when you mention "Modifying and tearing down LSPs after control plane failure" i pointed already that a migration from CP to somewhere else is impossible if you don't get access to the CP iself in particular if it is under failure - doesn't seem to be understood by authors (yet) thanks, - d. Dan Li 25/08/2006 03:59 To: ccamp cc: "Li, Han" , "Fedyk, Don" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Diego Caviglia , Igor Bryskin , "Farrel, Adrian" , Lou Berger , "Brungard, Deborah A, ALABS" , "Drake, John E" Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Hi all, The main motivation for this work is MP->CP migration. Our objective is to be able to introduce a control plane into an existing network without disrupting user traffic. We understand that there are operators who would not want to perform this function. They might prefer to set up parallel LSPs using the CP and swap trafic to them before tearing down the MP LSPs, but we believe that this will not be possible in many busy networks. Other operators may prefer to have a network outage, but this will not be acceptable for all other operators. Therefore, in order to ensure interoperability between different vendors' equipment, we believe that a GMPLS process is required for this function. We fully expect it to be quite a simple process. Our main requirement for CP->MP migration is to handle "back-out" of the MP->CP migration process. If there is some problem, the operator would like to be able to return to how things were before hand (i.e. MP control), without disrupting user traffic. We regard this as highly desirable, but probably not a mandatory requirement. Modifying and tearing down LSPs after control plane failure is also a possible motivation, but the detailed requirements will need further examination. As has been pointed out, tear-down may be achieved relatively simply. But modification (for example, re-routing, increase in capacity, etc.) may be more complicated. Other uses of CP->MP migration are interesting, but are not our main motivation, but we would like to observe that if the features that meet our requirements can also be used for other purposes then that is OK. Obviously, from the discussions on the mailing list, our I-D does not currently present a sufficiently focused description of the motivation for this work. We welcome further discussion of the requirements to help us improve the draft. It would be helpful in your discussions if you could understand that we are describing the requirements. If it turns out that the requirements can be met without changing the protocols, then we are very happy. But if you believe that no changes to the protocols are needed, we still need to state the requirements. So perhaps our conversation should be about the functional requirements not about the solutions. Best regards, Dan Li Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Aug 2006 02:07:02 +0000 Date: Fri, 25 Aug 2006 09:59:23 +0800 From: Dan Li Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: ccamp Cc: "Li, Han" , "Fedyk, Don" , Papadimitriou Dimitri , Diego Caviglia , Igor Bryskin , "Farrel, Adrian" , Lou Berger , "Brungard, Deborah A, ALABS" , "Drake, John E" Message-id: <008301c6c7ea$165ce820$d04c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT Hi all, The main motivation for this work is MP->CP migration. Our objective is to be able to introduce a control plane into an existing network without disrupting user traffic. We understand that there are operators who would not want to perform this function. They might prefer to set up parallel LSPs using the CP and swap trafic to them before tearing down the MP LSPs, but we believe that this will not be possible in many busy networks. Other operators may prefer to have a network outage, but this will not be acceptable for all other operators. Therefore, in order to ensure interoperability between different vendors' equipment, we believe that a GMPLS process is required for this function. We fully expect it to be quite a simple process. Our main requirement for CP->MP migration is to handle "back-out" of the MP->CP migration process. If there is some problem, the operator would like to be able to return to how things were before hand (i.e. MP control), without disrupting user traffic. We regard this as highly desirable, but probably not a mandatory requirement. Modifying and tearing down LSPs after control plane failure is also a possible motivation, but the detailed requirements will need further examination. As has been pointed out, tear-down may be achieved relatively simply. But modification (for example, re-routing, increase in capacity, etc.) may be more complicated. Other uses of CP->MP migration are interesting, but are not our main motivation, but we would like to observe that if the features that meet our requirements can also be used for other purposes then that is OK. Obviously, from the discussions on the mailing list, our I-D does not currently present a sufficiently focused description of the motivation for this work. We welcome further discussion of the requirements to help us improve the draft. It would be helpful in your discussions if you could understand that we are describing the requirements. If it turns out that the requirements can be met without changing the protocols, then we are very happy. But if you believe that no changes to the protocols are needed, we still need to state the requirements. So perhaps our conversation should be about the functional requirements not about the solutions. Best regards, Dan Li Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 17:02:04 +0000 Message-Id: <7.0.1.0.2.20060824125929.03532ef0@labn.net> Date: Thu, 24 Aug 2006 13:01:13 -0400 To: "Don Fedyk" From: Lou Berger Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: "Lou Berger" , "Diego Caviglia" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed > >If we were to ask could you live without the CP->MP feature what >response would we get versus asking if CP->MP is a soft requirement. From the discussions I've had on this with carriers, for some it's a don't care, for others they won't deploy control plane without this capability. Lou At 10:48 AM 8/24/2006, Don Fedyk wrote: >Lou and Diego, all > >Two points. > >If we were to ask could you live without the CP->MP feature what >response would we get versus asking if CP->MP is a soft requirement. > >The other point that baffles me is there is not one "standard" MP that >I'm aware of so really we are talking many variations of MP to a >standard CP. So how do you define a CP to variations of MPs? The >document currently oversimplifies this aspect IMHO. > >Thanks, >Don > > > -----Original Message----- > > > > Diego, > > In my experience in talking about this feature with > > carriers is that some (but not all) will require such > > symmetric behavior. I think the other rational for this > > feature are irrelevant. Again, the sole reason I've seen for > > this requirement is that to deploy MP->CP some will require > > that there be support for CP->MP. > > > > I therefore think the definition of CP->MP *is* required. > > There are multiple options for meeting this requirement, but > > the solution must provide the "fallback" capability for > > services existing at the time of the initial MP->CP > > transition and those created after the transition. > > > > I think a SHOULD level requirement is sufficient for this > > capability, but I'd be interested if those representing > > carries on the list differ. > > > > Lou > > > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > > > > > > >In my mind the CP->MP feature can be useful for mainly two purposes: > > >1) symmetricity with the companion feature (MP->CP) > > >[...] > > > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a > > >must and I have no problem to move it to should/shall/may state. > > > > > >[...] > > >However the focus of the ID is on MP->CP handover and if the > > community > > >is strongly against of CP->MP even in the form of a should/shall/may > > >requirement we can strip this out. > > > > > >Regards > > > > > >Diego > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 16:10:36 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Thu, 24 Aug 2006 12:09:36 -0400 Message-ID: Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbHd+uhj2J3uqENTJagDDcfOJpoUQACBAMwAAVm5FA= From: "Bryskin, Igor" To: "Don Fedyk" , "Lou Berger" , "Diego Caviglia" Cc: Don, > The other point that baffles me is there is not one "standard" MP that > I'm aware of so really we are talking many variations of MP to a > standard CP. So how do you define a CP to variations of MPs? The > document currently oversimplifies this aspect IMHO. I don't think we need to assume that MP is standard in the context of = CP->MP and MP->CP discussion. IMO it does not even have to be MP. We are = talking here about a capability of CP to acquire network resources and = build CP state for an LSP without actually re-programming crossconnects = (case MP->CP). Likewise, we are talking about capability of CP to = release resources and destroy CP state for an LSP without re-programming = crossconnects (case CP->MP). It is out of scope of those mechanisms how = MP (or any other plane) assumes or yields the ownership of resources of = the LSP whose ownership is transferred from/to CP.. Igor > -----Original Message----- >=20 > Diego, > In my experience in talking about this feature with=20 > carriers is that some (but not all) will require such=20 > symmetric behavior. I think the other rational for this=20 > feature are irrelevant. Again, the sole reason I've seen for=20 > this requirement is that to deploy MP->CP some will require=20 > that there be support for CP->MP. >=20 > I therefore think the definition of CP->MP *is* required. =20 > There are multiple options for meeting this requirement, but=20 > the solution must provide the "fallback" capability for=20 > services existing at the time of the initial MP->CP=20 > transition and those created after the transition. >=20 > I think a SHOULD level requirement is sufficient for this=20 > capability, but I'd be interested if those representing=20 > carries on the list differ. >=20 > Lou >=20 > At 03:09 AM 8/24/2006, Diego Caviglia wrote: >=20 >=20 > >In my mind the CP->MP feature can be useful for mainly two purposes: > >1) symmetricity with the companion feature (MP->CP) > >[...] > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a=20 > >must and I have no problem to move it to should/shall/may state. > > > >[...] > >However the focus of the ID is on MP->CP handover and if the=20 > community=20 > >is strongly against of CP->MP even in the form of a should/shall/may=20 > >requirement we can strip this out. > > > >Regards > > > >Diego >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 15:44:56 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Thu, 24 Aug 2006 11:44:21 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A34FBB1@zrtphxm2.corp.nortel.com> Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbHkZMYvUOt8S3kSSqppXQr9TSzrgAAGkrg From: "Don Fedyk" To: "Diego Caviglia" Cc: "\"Lou Berger\" , " Hi Diego=20 In Line as well > -----Original Message----- > Hi Don, > in line. >=20 > Regards >=20 >=20 >=20 > "Don Fedyk" @ops.ietf.org on 24/08/2006 16.48.48 >=20 > Sent by: owner-ccamp@ops.ietf.org >=20 >=20 > To: "Lou Berger" , "Diego Caviglia" > > cc: >=20 > Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) >=20 > Lou and Diego, all >=20 > Two points. >=20 > If we were to ask could you live without the CP->MP feature=20 > what response would we get versus asking if CP->MP is a soft=20 > requirement. > [dc] I think that the poll request from Adrian was trying to=20 > solve this point. >=20 > The other point that baffles me is there is not one=20 > "standard" MP that I'm aware of so really we are talking many=20 > variations of MP to a standard CP. So how do you define a CP=20 > to variations of MPs? The document currently oversimplifies=20 > this aspect IMHO. > [dc] This is not clear to me. Could you please clarify? [DF] Where do we find the standard MP representation of a Path? What MIBS etc. Many legacy systems have differnet MP representations of this and may use extra attributes or objects. It varies by which Optical or packet based system GMPLS is to control. When moving to GMPLS we can rationalize these objects to GMPLS objects but without generation/storage and possibily signaling of these MP objects the CP->MP mapping is incomplete. =20 Regards, Don =20 >=20 > Thanks, > Don >=20 > > -----Original Message----- > > > > Diego, > > In my experience in talking about this feature=20 > with carriers=20 > > is that some (but not all) will require such symmetric behavior. I=20 > > think the other rational for this feature are irrelevant. =20 > Again, the=20 > > sole reason I've seen for this requirement is that to deploy MP->CP=20 > > some will require that there be support for CP->MP. > > > > I therefore think the definition of CP->MP *is* required. > > There are multiple options for meeting this requirement, but the=20 > > solution must provide the "fallback" capability for=20 > services existing=20 > > at the time of the initial MP->CP transition and those=20 > created after=20 > > the transition. > > > > I think a SHOULD level requirement is sufficient for this=20 > capability,=20 > > but I'd be interested if those representing carries on the list=20 > > differ. > > > > Lou > > > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > > > > > > >In my mind the CP->MP feature can be useful for mainly two=20 > purposes: > > >1) symmetricity with the companion feature (MP->CP) > > >[...] > > > > > >We (the authors of the ID) agreed with Dimitri that CP->MP=20 > is not a=20 > > >must and I have no problem to move it to should/shall/may state. > > > > > >[...] > > >However the focus of the ID is on MP->CP handover and if the > > community > > >is strongly against of CP->MP even in the form of a=20 > should/shall/may=20 > > >requirement we can strip this out. > > > > > >Regards > > > > > >Diego > > > > > > >=20 >=20 >=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 15:30:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Thu, 24 Aug 2006 08:30:30 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DD13@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbHd+uhj2J3uqENTJagDDcfOJpoUQACBAMwAARtlTA= From: "Drake, John E" To: "Don Fedyk" , "Lou Berger" , "Diego Caviglia" Cc: >=20 > The other point that baffles me is there is not one=20 > "standard" MP that I'm aware of so really we are talking many=20 > variations of MP to a standard CP. So how do you define a CP=20 > to variations of MPs? The document currently oversimplifies=20 > this aspect IMHO. JD: If you go back to the original MPL(ambda)S proposal, this was one of the reasons given for building a standards based control plane. >=20 > Thanks, > Don >=20 > > -----Original Message----- > >=20 > > Diego, > > In my experience in talking about this feature with > > carriers is that some (but not all) will require such=20 > > symmetric behavior. I think the other rational for this=20 > > feature are irrelevant. Again, the sole reason I've seen for=20 > > this requirement is that to deploy MP->CP some will require=20 > > that there be support for CP->MP. > >=20 > > I therefore think the definition of CP->MP *is* required. > > There are multiple options for meeting this requirement, but=20 > > the solution must provide the "fallback" capability for=20 > > services existing at the time of the initial MP->CP=20 > > transition and those created after the transition. > >=20 > > I think a SHOULD level requirement is sufficient for this > > capability, but I'd be interested if those representing=20 > > carries on the list differ. > >=20 > > Lou > >=20 > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > >=20 > >=20 > > >In my mind the CP->MP feature can be useful for mainly two=20 > purposes: > > >1) symmetricity with the companion feature (MP->CP) > > >[...] > > > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a > > >must and I have no problem to move it to should/shall/may state. > > > > > >[...] > > >However the focus of the ID is on MP->CP handover and if the > > community > > >is strongly against of CP->MP even in the form of a=20 > should/shall/may > > >requirement we can strip this out. > > > > > >Regards > > > > > >Diego > >=20 > >=20 > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 15:26:13 +0000 Sensitivity: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: dwfedyk@nortel.com Cc: ""Lou Berger" , " Message-ID: From: "Diego Caviglia" Date: Thu, 24 Aug 2006 17:24:00 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Don, in line. Regards "Don Fedyk" @ops.ietf.org on 24/08/2006 16.48.48 Sent by: owner-ccamp@ops.ietf.org To: "Lou Berger" , "Diego Caviglia" cc: Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Lou and Diego, all Two points. If we were to ask could you live without the CP->MP feature what response would we get versus asking if CP->MP is a soft requirement. [dc] I think that the poll request from Adrian was trying to solve this point. The other point that baffles me is there is not one "standard" MP that I'm aware of so really we are talking many variations of MP to a standard CP. So how do you define a CP to variations of MPs? The document currently oversimplifies this aspect IMHO. [dc] This is not clear to me. Could you please clarify? Thanks, Don > -----Original Message----- > > Diego, > In my experience in talking about this feature with > carriers is that some (but not all) will require such > symmetric behavior. I think the other rational for this > feature are irrelevant. Again, the sole reason I've seen for > this requirement is that to deploy MP->CP some will require > that there be support for CP->MP. > > I therefore think the definition of CP->MP *is* required. > There are multiple options for meeting this requirement, but > the solution must provide the "fallback" capability for > services existing at the time of the initial MP->CP > transition and those created after the transition. > > I think a SHOULD level requirement is sufficient for this > capability, but I'd be interested if those representing > carries on the list differ. > > Lou > > At 03:09 AM 8/24/2006, Diego Caviglia wrote: > > > >In my mind the CP->MP feature can be useful for mainly two purposes: > >1) symmetricity with the companion feature (MP->CP) > >[...] > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a > >must and I have no problem to move it to should/shall/may state. > > > >[...] > >However the focus of the ID is on MP->CP handover and if the > community > >is strongly against of CP->MP even in the form of a should/shall/may > >requirement we can strip this out. > > > >Regards > > > >Diego > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 14:50:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CP-->MP Issue (was RE: Polling for new WG I-Ds) Date: Thu, 24 Aug 2006 10:48:48 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40A34F9E6@zrtphxm2.corp.nortel.com> Thread-Topic: CP-->MP Issue (was RE: Polling for new WG I-Ds) Thread-Index: AcbHd+uhj2J3uqENTJagDDcfOJpoUQACBAMw From: "Don Fedyk" To: "Lou Berger" , "Diego Caviglia" Cc: Lou and Diego, all Two points.=20 If we were to ask could you live without the CP->MP feature what response would we get versus asking if CP->MP is a soft requirement. The other point that baffles me is there is not one "standard" MP that I'm aware of so really we are talking many variations of MP to a standard CP. So how do you define a CP to variations of MPs? The document currently oversimplifies this aspect IMHO. Thanks, Don > -----Original Message----- >=20 > Diego, > In my experience in talking about this feature with=20 > carriers is that some (but not all) will require such=20 > symmetric behavior. I think the other rational for this=20 > feature are irrelevant. Again, the sole reason I've seen for=20 > this requirement is that to deploy MP->CP some will require=20 > that there be support for CP->MP. >=20 > I therefore think the definition of CP->MP *is* required. =20 > There are multiple options for meeting this requirement, but=20 > the solution must provide the "fallback" capability for=20 > services existing at the time of the initial MP->CP=20 > transition and those created after the transition. >=20 > I think a SHOULD level requirement is sufficient for this=20 > capability, but I'd be interested if those representing=20 > carries on the list differ. >=20 > Lou >=20 > At 03:09 AM 8/24/2006, Diego Caviglia wrote: >=20 >=20 > >In my mind the CP->MP feature can be useful for mainly two purposes: > >1) symmetricity with the companion feature (MP->CP) > >[...] > > > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a=20 > >must and I have no problem to move it to should/shall/may state. > > > >[...] > >However the focus of the ID is on MP->CP handover and if the=20 > community=20 > >is strongly against of CP->MP even in the form of a should/shall/may=20 > >requirement we can strip this out. > > > >Regards > > > >Diego >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 13:30:09 +0000 Date: Thu, 24 Aug 2006 09:29:01 -0400 From: Dan Li Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Message-id: <001301c6c781$4320f5e0$6501a8c0@dan> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT Hi Dimitri, see in line. -Dan ----- Original Message ----- From: To: "Dan Li" Cc: "ccamp" ; "MEURIC Julien RD-CORE-LAN" ; ; ; "Zafar Ali (zali)" Sent: Thursday, August 24, 2006 3:57 AM Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, > hi - > > [dan] In optical transport networks, the control plane failure should not > affect the traffic carried by the transport plane. So usually the > cross-connect > in the transport plane will not be removed when there is a failure in the > control > plane, that's why I stated the problem described in this I-D is real. > > [dimitri] I think this has been worked out (see RFC 3473, and related) > such as to prevent drawbacks of releasing resources while there is known > period during which states can be re-build (using neighbors as helpers) > [dan] Sorry, maybe I didn't make it clear. What I mean was during the LSP deletion procedure, if one node just happen to be restarted when it receives the message to release the transport resource. This situation results in the inconsistent data channel status because of the large timer setting. Before the large timer to be expired, we can not use the inconsistent data channel. [dan] In order to ensure that the traffic carried by the transport plane is not affected due to the control plane failure, we have to set a large timer. But on the other hand, when we really want to release the transport resource, we hope the timer is small enough to ensure the resource can be released as soon as possible when there is a problem on the control plane. > [dimitri] The concern is if parameters are set such as to make behavior > being equivalent to a hard state protocol the proposal you made is solving > a corner case from a mis-use of the protocol mechanisms we have at hand > > [dimitri] I understand from Adrian's reply that the case we're dealing > with is due restart/recovery timers that are set such as to support large > period of CP outage - where one can not rely on cleanup > > [dimitri] I can accept this is a consequence of setting existing > parameters - but my answer to this is "ok but why shall we have LMP > intervening in this process if the operator wants to wait for very large > periods" ... this leads to the (partial) conclusion that i can assume > their can be cases where the data plane itself may introduce an > inconsistency (would be interesting to have the viewpoint of "optical > hardware expert" here) but i don't see how we can have cases where the > control plane if correctly used and configured can be the instigator of > such cases > > [dimitri] concerning the detection, the issue resulting from this is that > the "available" side should - per 4204 - start an LMP verification ... > pointing to 4204 "Therefore, to ensure proper verification of data link > connectivity, it is required that, until the data links are allocated for > user traffic, they must be opaque (i.e., lose their transparency). To > support various degrees of opaqueness (e.g., examining overhead bytes, > terminating the IP payload, etc.) and, hence, different mechanisms to > transport the Test messages, a Verify Transport Mechanism field is > included in the BeginVerify and BeginVerifyAck messages." which result in > "when data links are de-allocated" they should re-enter that state ... the > issue is that the BeginVerify does not exchange DATA LINK but LINK objects > (there is no flags in the former) hence the only reply you would receive > is "unwilling to verify" while ideally you should receive "unwilling to > verify (allocated)" such as the other side can map it with local knowledge > and detect the mismatch > [dan] This solution you have suggested sounds very interesting, I will look at it. > > -d. > > > > > > > Dan Li > 24/08/2006 08:29 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: ccamp , MEURIC Julien RD-CORE-LAN > , owner-ccamp@ops.ietf.org, > xuhuiying@huawei.com, "Zafar Ali (zali)" > Subject: Re: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi Dimitri, > > Please see in-line. > > Regards, > > Dan > > ----- Original Message ----- > From: > To: "Dan Li" > Cc: "ccamp" ; "MEURIC Julien RD-CORE-LAN" > ; ; > ; "Zafar Ali (zali)" > Sent: Wednesday, August 23, 2006 8:45 PM > Subject: Re: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > >> just a brief remark >> >> i don't see why channel status verification can not be achieved with >> current mechanism described in section 12.7 of 4204 (and there is a >> need to come with a complete set of messages for this purpose) >> > > [dan] I agree that the LMP messages (17, 18, 19) can do the channel status > verification with some extensions. My concern is that these messages are > used for the fault management, but the inconsistent data channel status > may > be is not a failure, for example it may be configured on purpose. > > >> now i am even unclear how the problem you stated can occur >> >> "The channel status of a data link may become mismatched during the >> LSP deletion process. If the LSP deletion process is aborted in the >> middle of the process (perhaps because of a temporary control plane >> failure), the cross-connection at the upstream node may be removed >> while the downstream node still keeps its cross-connection." >> >> why do you think the notion of soft-state has been introduced ? once >> the cleanup timeout (set to K times the refresh timeout) interval is >> reached that then triggers a tear-down >> > > [dan] In optical transport networks, the control plane failure should not > affect the traffic carried by the transport plane. So usually the > cross-connect > in the transport plane will not be removed when there is a failure in the > control > plane, that's why I stated the problem described in this I-D is real. > > >> thanks, >> - d. >> >> >> >> >> >> >> Dan Li >> Sent by: owner-ccamp@ops.ietf.org >> 23/08/2006 09:55 >> >> To: xuhuiying@huawei.com, "Zafar Ali (zali)" > , >> MEURIC Julien RD-CORE-LAN >> cc: ccamp >> Subject: Re: High level comment on >> draft-li-ccamp-confirm-data-channel-status-00.txt, >> >> >> Hi, >> >> Thanks Julien and Zafar for your comments. I agree with Julien. This I-D > >> just wants to provide a control plane tool to detect the inconsistent > data >> channel status in the tranport plane. >> >> Actually I have received several private emails think this I-D addresses > a >> real problem, but regarding the new LMP messages which are introduced in > >> this I-D, some people pointed out that the already deployed > channelstatus >> messages (id = 17, 18, 19 and 20) may be extended to carry also the >> timeslot information instead only data link. But I have a concern that > the >> Fault Management Messages usually are triggered by fault detection, > these >> messages should not be sent if no fault is detected. The confirmation of > >> data channel status may need to be performed periodically or triggerd by > >> user. >> >> I would like to hear from you guys, what's your comments? Not only the >> concerns raised above, but also other issues in this I-D. >> >> Regards, >> >> Dan >> >> ----- Original Message ----- >> From: "MEURIC Julien RD-CORE-LAN" >> To: "Zafar Ali (zali)" ; ; >> >> Cc: "ccamp" >> Sent: Tuesday, July 11, 2006 2:31 AM >> Subject: RE: High level comment on >> draft-li-ccamp-confirm-data-channel-status-00.txt, >> >> >> Hi Zafar. >> >> I don't really get you on this. I figure out you're referring to >> removing the connection states when RSVP refreshes are not received any >> more, aren't you? If so, I'm afraid this is not enough for transmission >> devices, where resources can be physically cross-connected even though >> there is no (or no longer) corresponding RSVP state. Therefore having a >> mechanism to avoid such discrepancies would be welcome. >> >> Regards, >> >> Julien >> >> >> P.S.: If you totally rely on a management plane, I agree this should be >> useless (e.g. the NMS should already know if a cross-connection deletion >> failed, cf. Diego's 2nd slides seen this morning). >> >> ________________________________ >> >> >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf Of Zafar Ali (zali) >> >> Dear Authors, >> >> RSVP refreshes do this job, so I am not sure motivation for this draft/ >> LMP extensions. >> >> n.b. The draft state, "Although such a situation can be resolved through >> the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], >> such a procedure is inefficient since it may require an additional >> signaling exchange for each LSP that is set up", so I assume that RSVP >> signaling is present (Although I did not understand the quoted statement >> from the ID). Even if RSVP is not present, e.g., optical core is >> completely controlled by a management entity, I would argue introduce >> presence of LMP. >> >> Thanks >> >> Regards... Zafar >> >> >> >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 12:17:03 +0000 Message-Id: <7.0.1.0.2.20060824075206.03488328@labn.net> Date: Thu, 24 Aug 2006 08:15:50 -0400 To: "Diego Caviglia" From: Lou Berger Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds) Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Diego, In my experience in talking about this feature with carriers is that some (but not all) will require such symmetric behavior. I think the other rational for this feature are irrelevant. Again, the sole reason I've seen for this requirement is that to deploy MP->CP some will require that there be support for CP->MP. I therefore think the definition of CP->MP *is* required. There are multiple options for meeting this requirement, but the solution must provide the "fallback" capability for services existing at the time of the initial MP->CP transition and those created after the transition. I think a SHOULD level requirement is sufficient for this capability, but I'd be interested if those representing carries on the list differ. Lou At 03:09 AM 8/24/2006, Diego Caviglia wrote: >In my mind the CP->MP feature can be useful for mainly two purposes: >1) symmetricity with the companion feature (MP->CP) >[...] > >We (the authors of the ID) agreed with Dimitri that CP->MP is not a must >and I have no problem to move it to should/shall/may state. > >[...] >However the focus of the ID is on MP->CP handover and if the community is >strongly against of CP->MP even in the form of a should/shall/may >requirement we can strip this out. > >Regards > >Diego Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 09:55:24 +0000 Sensitivity: Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: "Dimitri.Papadimitriou" Cc: "ccamp" , "owner-ccamp" Message-ID: From: "Diego Caviglia" Date: Thu, 24 Aug 2006 11:53:36 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Dimitri, it depends if you use the parachute before the plane explode :-)) More seriously do you still have problems with the procedure if we move it to a should/shall/may state? I think that this would be enough for who think is a good feture and wants to implement it and do not 'force' anyone that disagree to implement it. Regards Diego Dimitri.Papadimitriou@alcatel.be on 24/08/2006 10.18.28 To: "Diego Caviglia" cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds) diego - using your metaphore - if the plane explodes/crashes you can have the nicer parachute it won't be of great help - meaning it is clear that is not this process/parachute that is going to increase confidence in CP if the problem is more fundamental and in part. not technical (confidence/trust/etc.) ps: operations are NOT symmetric (if you mean reflective since CP =/= distributed MP) "Diego Caviglia" Sent by: owner-ccamp@ops.ietf.org 24/08/2006 09:09 To: ccamp@ops.ietf.org cc: Subject: CP-->MP Issue (was RE: Polling for new WG I-Ds) In my mind the CP->MP feature can be useful for mainly two purposes: 1) symmetricity with the companion feature (MP->CP) 2) a sort of "parachute" in case something went wrong with the CP (Igor made an example on this but another one could a foreseen problem with the signalling network, or may be the CP is not running well and its restoration time are not in line with the expectation, or there is a merge of two different networks organizations and the resulting one is not going to use -may be only at initial stage of merging process- the CP, ...) We (the authors of the ID) agreed with Dimitri that CP->MP is not a must and I have no problem to move it to should/shall/may state. Is this in the scope of CCAMP? I think it is because is CP related and imho having such parachute can increase the confidence of carriers in CP. I mean I prefer to take a plane if I know I have a parachute on board. However the focus of the ID is on MP->CP handover and if the community is strongly against of CP->MP even in the form of a should/shall/may requirement we can strip this out. Regards Diego Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 09:35:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas Date: Thu, 24 Aug 2006 10:33:13 +0100 Message-ID: Thread-Topic: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas Thread-Index: AcbDEDTmeTIKi35STGuMN20t0qcUAgB+eo/A From: "Trevor Wilson" To: "Huub van Helvoort" Cc: Huub, Sorry for the delay in replying to your e-mail. I think we're there. See in-line. [tw2] Trevor Trevor Wilson Nortel Networks Belfast Lab Tel: +44 2890 363701 ESN 751 3701 >This is the Way. This is Nortel. > Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 Sent: 18 August 2006 22:49 To: Wilson, Trevor (IRE07:Q840) Cc: ccamp@ops.ietf.org Subject: Re: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas Hello Trevor, You replied: > Thanks for the clarifications, see in-line for responses. OK, I have added my response [hvh2] and sipped the parts where we agree. >> Section 3.2: >> >> Is Fixed synonymous with no-LCAS ? >=20 > [hvh] No, not necessarily, in this case the client signal will > not change its bandwidth. LCAS can be used for resilience. > [tw] Accepted that this is possible. However I still think the reader > could be forgiven for assuming that Fixed =3D non-LCAS-capable and > Dynamic =3D LCAS-capable; so perhaps this needs to be clarified in the = > text. [hvh2] OK that can be done. [tw2] Look forward to seeing that. >> If so, then in the Fixed co-routed scenario, there can be no graceful >> degradation in the event of a failure. > [tw] I have a typo here is should say Fixed diversely-routed instead > of Fixed co-routed >=20 > [hvh] a mis-connection is also a failure > [tw] but a mis-connection won't cause a hit, since this will occur at > set-up, but I agree that if LCAS is present then graceful degradation > can be achieved in the event of a signal degrade. [hvh2] I don't agree, mis-connections can also occur after set-up, e.g. when a crossconnect is wrongly provisioned and changed an existing connection. [tw2] OK >> A hitless decrease can >> in certain circumstances, be achieved by using a signal degrade to >> trigger the LCAS remove operation. >=20 > [hvh] how do you provision/achieve a signal degrade? > [tw] G.806 clause 10.1.1.2 shows "P-Xv_AI_TSD =3D P_AI[1.. XMR]_TSD" > and "P-Xv/P-X-L_A_Sk_MI_TSDEnable" as inputs to the "LCAS-capable > virtual concatenated path adaptation sink function P-Xv/P-X-L_A_Sk",=20 > and the text says "The MI_TSDEnable input controls whether the sink=20 > function uses AI_TSD[i] indications as contributors for signalling=20 > defective members back to the LCAS source function (MI_TSDEnable =3D=20 > true) or whether it ignores AI_TSD[i] indications altogether=20 > (MI_TSDEnable =3D false)." [hvh2] this is the enabling of the TSD to be a trigger. What I dis mean is that it is impossible to force a signal degrade (e.g. by introducing bit errors on purpose). Maybe we should only mention that hitless decrease is guaranteed when a member is removed (and LCAS is enabled). [tw2] I'm getting a bit lost; this part of the discussion was about graceful degradation. With that in mind are you suggesting to remove any mention of graceful degrade. If so I agree. I look forward to seeing the final text. =20 >> Dynamic, diversely routed: A dynamic VCAT group, transported over at=20 >> least two diversely routed subsets of member signals. The intent=20 >> here is dynamic resizing and resilience (but differential delay may=20 >> be a limiting factor). Graceful degradation is possible in the event=20 >> of a TSD (Trail Signal Degrade) on a VCG >> member(s) >=20 > [hvh] graceful degradation is a feature of LCAS, it is not necessary > to mention it here explicitly > [tw] It's equally (if not more) relevant to mention it here than in > the fixed scenario. [hvh2] see my previous comment >> The LCAS in-band >> signaling step is taken first to take the component out of the >> group as the result of a remove command from the LCAS controller; the >> permanently removed member will then be in the IDLE state. >=20 > [hvh] mentioning only one of the LCAS states will create confusion > and is irrelevant to GMPLS > [tw] OK so take out the mention of the DNU state (4.1.3.1) and IDLE > (4.1.3.2). In fact perhaps 4.1.3.1 could be combined with 4.1.3.2 as > follows: - >=20 > 4.1.3 Permanent removal of a VCG member >=20 > A VCG member can be permanently removed from the VCG either following > a temporary removal (due to a failure) or as the result of a=20 > management command. The LCAS in-band signaling step is taken first to=20 > take the component out of the group, either the temporary removal or=20 > as the result of a management command. [hvh2] good suggestion >> This permanent removal procedure is only applicable to=20 >> LCAS-capable-VCAT. >=20 > [hvh] the paragraph replaced by the latter sentence contains more > relevant detail and should be kept intact. > [tw] The introduction to section 4 states that it (section 4) is "in > support of the LCAS procedure". So I don't quite see how the sentence > that I deleted is relevant to LCAS since it deals with the "VCAT only" > interface. =09 [hvh2] you missed the word "and" in quoting, so section 4 describes extentions for diversely routed paths and (extentions) in support of LCAS". So the detail given in the paragraph is relevant for making the distinction between VCAT with and without LCAS. [tw2] OK Cheers, and have a nice weekend, Huub. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://members.chello.nl/hhelvoort/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 08:18:52 +0000 To: "Diego Caviglia" Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: CP-->MP Issue (was RE: Polling for new WG I-Ds) MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 24 Aug 2006 10:18:28 +0200 Content-Type: text/plain; charset="US-ASCII" diego - using your metaphore - if the plane explodes/crashes you can have the nicer parachute it won't be of great help - meaning it is clear that is not this process/parachute that is going to increase confidence in CP if the problem is more fundamental and in part. not technical (confidence/trust/etc.) ps: operations are NOT symmetric (if you mean reflective since CP =/= distributed MP) "Diego Caviglia" Sent by: owner-ccamp@ops.ietf.org 24/08/2006 09:09 To: ccamp@ops.ietf.org cc: Subject: CP-->MP Issue (was RE: Polling for new WG I-Ds) In my mind the CP->MP feature can be useful for mainly two purposes: 1) symmetricity with the companion feature (MP->CP) 2) a sort of "parachute" in case something went wrong with the CP (Igor made an example on this but another one could a foreseen problem with the signalling network, or may be the CP is not running well and its restoration time are not in line with the expectation, or there is a merge of two different networks organizations and the resulting one is not going to use -may be only at initial stage of merging process- the CP, ...) We (the authors of the ID) agreed with Dimitri that CP->MP is not a must and I have no problem to move it to should/shall/may state. Is this in the scope of CCAMP? I think it is because is CP related and imho having such parachute can increase the confidence of carriers in CP. I mean I prefer to take a plane if I know I have a parachute on board. However the focus of the ID is on MP->CP handover and if the community is strongly against of CP->MP even in the form of a should/shall/may requirement we can strip this out. Regards Diego Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 07:58:23 +0000 To: Dan Li Cc: ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 24 Aug 2006 09:57:17 +0200 Content-Type: text/plain; charset="US-ASCII" hi - [dan] In optical transport networks, the control plane failure should not affect the traffic carried by the transport plane. So usually the cross-connect in the transport plane will not be removed when there is a failure in the control plane, that's why I stated the problem described in this I-D is real. [dimitri] I think this has been worked out (see RFC 3473, and related) such as to prevent drawbacks of releasing resources while there is known period during which states can be re-build (using neighbors as helpers) [dimitri] The concern is if parameters are set such as to make behavior being equivalent to a hard state protocol the proposal you made is solving a corner case from a mis-use of the protocol mechanisms we have at hand [dimitri] I understand from Adrian's reply that the case we're dealing with is due restart/recovery timers that are set such as to support large period of CP outage - where one can not rely on cleanup [dimitri] I can accept this is a consequence of setting existing parameters - but my answer to this is "ok but why shall we have LMP intervening in this process if the operator wants to wait for very large periods" ... this leads to the (partial) conclusion that i can assume their can be cases where the data plane itself may introduce an inconsistency (would be interesting to have the viewpoint of "optical hardware expert" here) but i don't see how we can have cases where the control plane if correctly used and configured can be the instigator of such cases [dimitri] concerning the detection, the issue resulting from this is that the "available" side should - per 4204 - start an LMP verification ... pointing to 4204 "Therefore, to ensure proper verification of data link connectivity, it is required that, until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency). To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the IP payload, etc.) and, hence, different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages." which result in "when data links are de-allocated" they should re-enter that state ... the issue is that the BeginVerify does not exchange DATA LINK but LINK objects (there is no flags in the former) hence the only reply you would receive is "unwilling to verify" while ideally you should receive "unwilling to verify (allocated)" such as the other side can map it with local knowledge and detect the mismatch -d. Dan Li 24/08/2006 08:29 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi Dimitri, Please see in-line. Regards, Dan ----- Original Message ----- From: To: "Dan Li" Cc: "ccamp" ; "MEURIC Julien RD-CORE-LAN" ; ; ; "Zafar Ali (zali)" Sent: Wednesday, August 23, 2006 8:45 PM Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, > just a brief remark > > i don't see why channel status verification can not be achieved with > current mechanism described in section 12.7 of 4204 (and there is a > need to come with a complete set of messages for this purpose) > [dan] I agree that the LMP messages (17, 18, 19) can do the channel status verification with some extensions. My concern is that these messages are used for the fault management, but the inconsistent data channel status may be is not a failure, for example it may be configured on purpose. > now i am even unclear how the problem you stated can occur > > "The channel status of a data link may become mismatched during the > LSP deletion process. If the LSP deletion process is aborted in the > middle of the process (perhaps because of a temporary control plane > failure), the cross-connection at the upstream node may be removed > while the downstream node still keeps its cross-connection." > > why do you think the notion of soft-state has been introduced ? once > the cleanup timeout (set to K times the refresh timeout) interval is > reached that then triggers a tear-down > [dan] In optical transport networks, the control plane failure should not affect the traffic carried by the transport plane. So usually the cross-connect in the transport plane will not be removed when there is a failure in the control plane, that's why I stated the problem described in this I-D is real. > thanks, > - d. > > > > > > > Dan Li > Sent by: owner-ccamp@ops.ietf.org > 23/08/2006 09:55 > > To: xuhuiying@huawei.com, "Zafar Ali (zali)" , > MEURIC Julien RD-CORE-LAN > cc: ccamp > Subject: Re: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi, > > Thanks Julien and Zafar for your comments. I agree with Julien. This I-D > just wants to provide a control plane tool to detect the inconsistent data > channel status in the tranport plane. > > Actually I have received several private emails think this I-D addresses a > real problem, but regarding the new LMP messages which are introduced in > this I-D, some people pointed out that the already deployed channelstatus > messages (id = 17, 18, 19 and 20) may be extended to carry also the > timeslot information instead only data link. But I have a concern that the > Fault Management Messages usually are triggered by fault detection, these > messages should not be sent if no fault is detected. The confirmation of > data channel status may need to be performed periodically or triggerd by > user. > > I would like to hear from you guys, what's your comments? Not only the > concerns raised above, but also other issues in this I-D. > > Regards, > > Dan > > ----- Original Message ----- > From: "MEURIC Julien RD-CORE-LAN" > To: "Zafar Ali (zali)" ; ; > > Cc: "ccamp" > Sent: Tuesday, July 11, 2006 2:31 AM > Subject: RE: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi Zafar. > > I don't really get you on this. I figure out you're referring to > removing the connection states when RSVP refreshes are not received any > more, aren't you? If so, I'm afraid this is not enough for transmission > devices, where resources can be physically cross-connected even though > there is no (or no longer) corresponding RSVP state. Therefore having a > mechanism to avoid such discrepancies would be welcome. > > Regards, > > Julien > > > P.S.: If you totally rely on a management plane, I agree this should be > useless (e.g. the NMS should already know if a cross-connection deletion > failed, cf. Diego's 2nd slides seen this morning). > > ________________________________ > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Zafar Ali (zali) > > Dear Authors, > > RSVP refreshes do this job, so I am not sure motivation for this draft/ > LMP extensions. > > n.b. The draft state, "Although such a situation can be resolved through > the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], > such a procedure is inefficient since it may require an additional > signaling exchange for each LSP that is set up", so I assume that RSVP > signaling is present (Although I did not understand the quoted statement > from the ID). Even if RSVP is not present, e.g., optical core is > completely controlled by a management entity, I would argue introduce > presence of LMP. > > Thanks > > Regards... Zafar > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 07:11:16 +0000 Sensitivity: Subject: CP-->MP Issue (was RE: Polling for new WG I-Ds) To: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Thu, 24 Aug 2006 09:09:15 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii In my mind the CP->MP feature can be useful for mainly two purposes: 1) symmetricity with the companion feature (MP->CP) 2) a sort of "parachute" in case something went wrong with the CP (Igor made an example on this but another one could a foreseen problem with the signalling network, or may be the CP is not running well and its restoration time are not in line with the expectation, or there is a merge of two different networks organizations and the resulting one is not going to use -may be only at initial stage of merging process- the CP, ...) We (the authors of the ID) agreed with Dimitri that CP->MP is not a must and I have no problem to move it to should/shall/may state. Is this in the scope of CCAMP? I think it is because is CP related and imho having such parachute can increase the confidence of carriers in CP. I mean I prefer to take a plane if I know I have a parachute on board. However the focus of the ID is on MP->CP handover and if the community is strongly against of CP->MP even in the form of a should/shall/may requirement we can strip this out. Regards Diego Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Aug 2006 06:33:30 +0000 Date: Thu, 24 Aug 2006 14:29:47 +0800 From: Dan Li Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Message-id: <019001c6c746$b24bfb80$d04c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Dimitri, Please see in-line. Regards, Dan ----- Original Message ----- From: To: "Dan Li" Cc: "ccamp" ; "MEURIC Julien RD-CORE-LAN" ; ; ; "Zafar Ali (zali)" Sent: Wednesday, August 23, 2006 8:45 PM Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, > just a brief remark > > i don't see why channel status verification can not be achieved with > current mechanism described in section 12.7 of 4204 (and there is a > need to come with a complete set of messages for this purpose) > [dan] I agree that the LMP messages (17, 18, 19) can do the channel status verification with some extensions. My concern is that these messages are used for the fault management, but the inconsistent data channel status may be is not a failure, for example it may be configured on purpose. > now i am even unclear how the problem you stated can occur > > "The channel status of a data link may become mismatched during the > LSP deletion process. If the LSP deletion process is aborted in the > middle of the process (perhaps because of a temporary control plane > failure), the cross-connection at the upstream node may be removed > while the downstream node still keeps its cross-connection." > > why do you think the notion of soft-state has been introduced ? once > the cleanup timeout (set to K times the refresh timeout) interval is > reached that then triggers a tear-down > [dan] In optical transport networks, the control plane failure should not affect the traffic carried by the transport plane. So usually the cross-connect in the transport plane will not be removed when there is a failure in the control plane, that's why I stated the problem described in this I-D is real. > thanks, > - d. > > > > > > > Dan Li > Sent by: owner-ccamp@ops.ietf.org > 23/08/2006 09:55 > > To: xuhuiying@huawei.com, "Zafar Ali (zali)" , > MEURIC Julien RD-CORE-LAN > cc: ccamp > Subject: Re: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi, > > Thanks Julien and Zafar for your comments. I agree with Julien. This I-D > just wants to provide a control plane tool to detect the inconsistent data > channel status in the tranport plane. > > Actually I have received several private emails think this I-D addresses a > real problem, but regarding the new LMP messages which are introduced in > this I-D, some people pointed out that the already deployed channelstatus > messages (id = 17, 18, 19 and 20) may be extended to carry also the > timeslot information instead only data link. But I have a concern that the > Fault Management Messages usually are triggered by fault detection, these > messages should not be sent if no fault is detected. The confirmation of > data channel status may need to be performed periodically or triggerd by > user. > > I would like to hear from you guys, what's your comments? Not only the > concerns raised above, but also other issues in this I-D. > > Regards, > > Dan > > ----- Original Message ----- > From: "MEURIC Julien RD-CORE-LAN" > To: "Zafar Ali (zali)" ; ; > > Cc: "ccamp" > Sent: Tuesday, July 11, 2006 2:31 AM > Subject: RE: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi Zafar. > > I don't really get you on this. I figure out you're referring to > removing the connection states when RSVP refreshes are not received any > more, aren't you? If so, I'm afraid this is not enough for transmission > devices, where resources can be physically cross-connected even though > there is no (or no longer) corresponding RSVP state. Therefore having a > mechanism to avoid such discrepancies would be welcome. > > Regards, > > Julien > > > P.S.: If you totally rely on a management plane, I agree this should be > useless (e.g. the NMS should already know if a cross-connection deletion > failed, cf. Diego's 2nd slides seen this morning). > > ________________________________ > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Zafar Ali (zali) > > Dear Authors, > > RSVP refreshes do this job, so I am not sure motivation for this draft/ > LMP extensions. > > n.b. The draft state, "Although such a situation can be resolved through > the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], > such a procedure is inefficient since it may require an additional > signaling exchange for each LSP that is set up", so I assume that RSVP > signaling is present (Although I did not understand the quoted statement > from the ID). Even if RSVP is not present, e.g., optical core is > completely controlled by a management entity, I would argue introduce > presence of LMP. > > Thanks > > Regards... Zafar > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 23:26:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 16:24:27 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DD0C@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAADc6lAAAcILgAAEmuJgAAKhLdAABNoRkA== From: "Drake, John E" To: "Bryskin, Igor" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" >=20 > JD: This means reverting to the previous version of control > plane software, not the CP->MP->CP detour. >=20 > IB>> I am talking about the situation when simple reverting is not > IB>> possible due to incompatibility of the new and old software=20 > IB>> releases. JD: This is the first time you have mentioned that you are assuming that this reversion is not possible. I think this is total nonsense for two reasons. 1) I don't believe technically that this reversion would ever *not* be possible. Otherwise, I don't see how the new software could have been incrementally deployed in the first place. 2) The operator would never deploy the new software unless had had verified that it could be backed out. =20 IB>> Agree, I probably should have said *not feasible* instead of *not=20 IB>> possible*. Imagine that the new CP was run for 1 month before the=20 IB>> problem was encountered. Using backup of old CP would mean loosing=20 IB>> all services that were provisioned within this period. JD: Let me guess. You are now making the further assumption that the databases of the old and new CPs are completely incompatible. As I indicated above, if incremental deployment and incremental roll back are not supported, the new CP will never be deployed. It's not like there is anything new here. IB>> Likewise, if=20 IB>> one made the MP->CP move, worked for some time and then discovered=20 IB>> a problem, using old MP backups would mean loosing all services=20 IB>> that were dynamically created or modified. JD: What are you talking about? We are discussing a CP update. IB>> CP->MP move would solve=20 IB>> the problem. JD: Completely unsupported assertion. Further, why would new CP->MP->old CP work when new CP->old CP would not work? IB>> Because you can not perform new CP->old CP conversion=20 IB>> simultameously on all nodes. JD: You cannot perform new CP->MP conversion simultaneously on all nodes either, and there is no reason to assume that simultaneous new CP->old CP conversion is required. Igor >=20 > Furthermore, on more general note, if we decide that we need > to be capable of doing MP->CP, just from the simmetricity=20 > point of view it makes a lot of sense to me to have CP->MP=20 > capability for debugging and testing the MP->CP move (if for=20 > nothing else)=20 >=20 > Igor >=20 > >=20 > > Besides, what is the problem with moving "hundreds/thousands of LSPs > > from CP->MP"? > >=20 > > Igor > >=20 > > -----Original Message----- > > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > Sent: Wednesday, August 23, 2006 11:43 AM > > To: Drake, John E; Bryskin, Igor; Diego Caviglia;=20 > > Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > >=20 > > Agree with John, and control plane failures don't (should not/hope=20 > > not) impact the data plane state. And before doing such a sw=20 > > upgrade, I would not want to have to move hundreds/thousands of LSPs > > from CP->MP. > >=20 > > I'm not sure myself on what is meant by CP->MP, need to > discuss more. > >=20 > > (chair hat off) > > Deborah > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of Drake, John E > > Sent: Wednesday, August 23, 2006 11:13 AM > > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > > Snipped > >=20 > > >=20 > > > Besides I can see at least one quite real application for > > > CP->MP. Imagine that an operator wants to perform some major > > > software upgrade with a new software version significantly > > > incompatible with the previous one. > >=20 > > JD: Except that we go to great pains to ensure that this situation=20 > > never occurs. > >=20 > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 21:20:53 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 17:06:31 -0400 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAADc6lAAAcILgAAEmuJgAAKhLdA= From: "Bryskin, Igor" To: "Drake, John E" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" >=20 > JD: This means reverting to the previous version of control=20 > plane software, not the CP->MP->CP detour. >=20 > IB>> I am talking about the situation when simple reverting is not=20 > IB>> possible due to incompatibility of the new and old software=20 > IB>> releases. JD: This is the first time you have mentioned that you are assuming that this reversion is not possible. I think this is total nonsense for two reasons. 1) I don't believe technically that this reversion would ever *not* be possible. Otherwise, I don't see how the new software could have been incrementally deployed in the first place. 2) The operator would never deploy the new software unless had had verified that it could be backed out. =20 IB>> Agree, I probably should have said *not feasible* instead of *not = possible*. Imagine that the new CP was run for 1 month before the = problem was encountered. Using backup of old CP would mean loosing all = services that were provisioned within this period. Likewise, if one made = the MP->CP move, worked for some time and then discovered a problem, = using old MP backups would mean loosing all services that were = dynamically created or modified. CP->MP move would solve the problem. Further, why would new CP->MP->old CP work when new CP->old CP would not work? IB>> Because you can not perform new CP->old CP conversion = simultameously on all nodes. Igor >=20 > Furthermore, on more general note, if we decide that we need=20 > to be capable of doing MP->CP, just from the simmetricity=20 > point of view it makes a lot of sense to me to have CP->MP=20 > capability for debugging and testing the MP->CP move (if for=20 > nothing else)=20 >=20 > Igor >=20 > >=20 > > Besides, what is the problem with moving "hundreds/thousands > > of LSPs from CP->MP"?=20 > >=20 > > Igor > >=20 > > -----Original Message----- > > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > Sent: Wednesday, August 23, 2006 11:43 AM > > To: Drake, John E; Bryskin, Igor; Diego Caviglia; > > Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > >=20 > > Agree with John, and control plane failures don't (should > > not/hope not) impact the data plane state. And before doing=20 > > such a sw upgrade, I would not want to have to move=20 > > hundreds/thousands of LSPs from CP->MP. > >=20 > > I'm not sure myself on what is meant by CP->MP, need to=20 > discuss more. > >=20 > > (chair hat off) > > Deborah > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E > > Sent: Wednesday, August 23, 2006 11:13 AM > > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > > Snipped > >=20 > > >=20 > > > Besides I can see at least one quite real application for > > > CP->MP. Imagine that an operator wants to perform some major > > > software upgrade with a new software version significantly=20 > > > incompatible with the previous one. > >=20 > > JD: Except that we go to great pains to ensure that this > > situation never occurs.=20 > >=20 > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 19:52:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 12:50:15 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DD05@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwAABe1rwAABBhyAAAMHGUAADCWqAAAOAwPA= From: "Drake, John E" To: "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" >=20 > > > Furthermore, sometimes there is a need to actually > > > downgrade software, for instance, when one wants to add to=20 > > > the network some older equipment. > >=20 > > Why would anyone want to do this, especially without > > upgrading this equipments' software? > >=20 > > IB>> Because the new software was developed on the=20 > assumption that it > > IB>> will work on the new hardware. Your customer, on the=20 > other hand,=20 > > IB>> purchased your old equipment and you want to protect his=20 > > IB>> investment. >=20 > This is not what you said initially. You said 'add to=20 > the network some older equipment.' >=20 > IB>> No, that's exactly what I meant. My customer purchased a ring of=20 > IB>> new devices with new software. The customer also happens to have=20 > IB>> several rings of older devices running older software.=20 > The customer=20 > IB>> wants to interconnect the new rings with old ones. The customer=20 > IB>> does not mind to downgrade the software on the new ring=20 > so that it=20 > IB>> will be compatible with other rings. As I said previously, the situation you are describing above is *not* the same as 'add to=20 the network some older equipment.' What you are describing is adding new equipment to an existing network, and there are many options for doing this, but going from CP->MP is not one of them. If the existing equipment was deployed with an MP and you didn't want to upgrade it to CP, you would just deploy the new equipment with MP from the beginning. =20 >=20 > Igor >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 19:40:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 12:39:19 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DD04@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAADc6lAAAcILgAAEmuJg From: "Drake, John E" To: "Bryskin, Igor" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" >=20 > JD: This means reverting to the previous version of control=20 > plane software, not the CP->MP->CP detour. >=20 > IB>> I am talking about the situation when simple reverting is not=20 > IB>> possible due to incompatibility of the new and old software=20 > IB>> releases. JD: This is the first time you have mentioned that you are assuming that this reversion is not possible. I think this is total nonsense for two reasons. 1) I don't believe technically that this reversion would ever *not* be possible. Otherwise, I don't see how the new software could have been incrementally deployed in the first place. 2) The operator would never deploy the new software unless had had verified that it could be backed out. Further, why would new CP->MP->old CP work when new CP->old CP would not work? >=20 > Furthermore, on more general note, if we decide that we need=20 > to be capable of doing MP->CP, just from the simmetricity=20 > point of view it makes a lot of sense to me to have CP->MP=20 > capability for debugging and testing the MP->CP move (if for=20 > nothing else)=20 >=20 > Igor >=20 > >=20 > > Besides, what is the problem with moving "hundreds/thousands > > of LSPs from CP->MP"?=20 > >=20 > > Igor > >=20 > > -----Original Message----- > > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > Sent: Wednesday, August 23, 2006 11:43 AM > > To: Drake, John E; Bryskin, Igor; Diego Caviglia; > > Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > >=20 > > Agree with John, and control plane failures don't (should > > not/hope not) impact the data plane state. And before doing=20 > > such a sw upgrade, I would not want to have to move=20 > > hundreds/thousands of LSPs from CP->MP. > >=20 > > I'm not sure myself on what is meant by CP->MP, need to=20 > discuss more. > >=20 > > (chair hat off) > > Deborah > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E > > Sent: Wednesday, August 23, 2006 11:13 AM > > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou > > Cc: " ccamp " > Farrel > Subject: RE: Polling for new WG I-Ds > >=20 > > Snipped > >=20 > > >=20 > > > Besides I can see at least one quite real application for > > > CP->MP. Imagine that an operator wants to perform some major > > > software upgrade with a new software version significantly=20 > > > incompatible with the previous one. > >=20 > > JD: Except that we go to great pains to ensure that this > > situation never occurs.=20 > >=20 > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 18:49:58 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 14:48:31 -0400 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAAVIZKAAAGTkkA== From: "Bryskin, Igor" To: "Brungard, Deborah A, ALABS" , "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Deborah, Have you been in a situation when you just performed a software upgrade and a network operator tells you that your new release sucks and he wants the network in the state of this morning prior to the upgrade? No? Than you are lucky. Db> that is totally different from this discussion, hopefully they know what a backup is (for your benefit), and also one does not necessarily want to use the backup since there could have been changes in the network since the backup was made, unless the network is static;-)=20 IB>> Exactly my point. If you can not or don't wnat to use backup, what = is the way out of this mess? Igor Would stongly suggest you (and the operator) have done sufficient testin Besides, what is the problem with moving "hundreds/thousands of LSPs from CP->MP"?=20 Db> Good joke;-) Igor -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Wednesday, August 23, 2006 11:43 AM To: Drake, John E; Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " MP. I'm not sure myself on what is meant by CP->MP, need to discuss more. (chair hat off) Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E Sent: Wednesday, August 23, 2006 11:13 AM To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " =20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 18:43:55 +0000 Message-ID: <0fbe01c6c6e4$0af04740$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Snigdho Bardalai" , Cc: "ccamp" , "Dan Li" , "MEURIC Julien RD-CORE-LAN" , Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Date: Wed, 23 Aug 2006 19:43:27 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Dimitri, I think you are focusing in too closely on an example of how the problem can arise. The problem is simply that it is possible that the resources are not available in the same way at both ends of the link. The discussion then went down the path of how this might arise, and we have become stuck in a detailed example. Perhaps a better example would be the failure of a hardware component that is represents a label on the TE link, where the failure is known at the local node, but cannot be communicated to the remote node. But related to your specific discussion... > i am not sure to capture your point - let's say states are self-refreshed > for some time, if the signaling channel is not up before pre-negotiated > time - and you didn't fix this timer as being infinite - resources will be > released when the cleanup elapses So you are saying that there is a timer that can be set on the Hello such that if the Hello adjacency is not re-established in that time, all LSPs should be torn down. Yes. This is the Restart Cap object Restart Time. But you say if "you didn't fix this timer as being infinite". But actually let's think about how operators like to use this timer. Sure they can say, I expect the CP to restart after a fault in 10 minutes, but wht about hardware faults? The CPU running the CP could fry, that is likely to require a truck roll, and the user traffic must not be torn down just because of this fault. So the Restart Time is typically set quite large. You will hear many people say that the user traffic is absolute - it must never be torn down because of a CP failure - and these people set the Restart Timer to all-f. Now, once the time has been set large, we don't have automatic cleanup. So the cross-connects can get into a mess. > in case one requires larger maintenance > windows one provides such configuration beforehand But note that this is not planned maintenance. > mis-using one > mechanism and then require another to reconstruct consistent states is the > first point that needs to be clarified So, are you saying that my description, above, represents a mis-use? If so, how should I configure the Restart Time so that I can survive long CP outages? > (it is also important to clarify > that LMP does not "reserve resources" it just mediates data link states so > if the error needs to be corrected it will any interfere with the entity > that is making use of it Completely agree with this point. LMP can report problems, but cannot fix them. > what you are trying to achieve is detect mismatch but detect these mismach > is not a solution to the problem Agree completely. What you have suggested before is that prevention is sufficient. What I believe is that prevention of all cases is probably not possible, therefore detection and cure will be needed. Detection (you are right) is not the same as cure. But cure without detection is improbable. Note that cure is not necessarily the objective! There is a separate problem (sending Path with bad choice of label) that can be prevented after detection, without the need for cure. Cure probably reuqires operator intervention. > but more importantly what is the trigger > to the detection itself? in brief how does one either of these sides > knows it should start such "verification" process ... was it not at the > end the reason for possibility of maintaining the "available" link on > permanent verification state within LMP ? Understanding the trigger for the detection process is important. Section 4 of the I-D currently says: The data channel status confirmation related LMP messages are sent between adjacent nodes periodically or driven by some events and this is not enough. We would need to know some more about the "period" and the "events" to assess whether this is going to flood the control channel or not provide the information in a timely manner. For example, one could use the receipt of an Acceptable Label Set object (and some parsing thereof) as a trigger event. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 18:39:36 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 13:38:57 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0CA60BBC@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAAVIZKA= From: "Brungard, Deborah A, ALABS" To: "Bryskin, Igor" , "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Hi Igor- comments below (as >db, chair hat off)=20 -----Original Message----- From: Bryskin, Igor [mailto:ibryskin@movaz.com]=20 Sent: Wednesday, August 23, 2006 12:09 PM To: Brungard, Deborah A, ALABS; Drake, John E; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " thanks;-) Have you been in a situation when you just performed a software upgrade and a network operator tells you that your new release sucks and he wants the network in the state of this morning prior to the upgrade? No? Than you are lucky. Db> that is totally different from this discussion, hopefully they know what a backup is (for your benefit), and also one does not necessarily want to use the backup since there could have been changes in the network since the backup was made, unless the network is static;-) Would stongly suggest you (and the operator) have done sufficient testing. Besides, what is the problem with moving "hundreds/thousands of LSPs from CP->MP"?=20 Db> Good joke;-) Igor -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Wednesday, August 23, 2006 11:43 AM To: Drake, John E; Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " MP. I'm not sure myself on what is meant by CP->MP, need to discuss more. (chair hat off) Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E Sent: Wednesday, August 23, 2006 11:13 AM To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " =20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 18:17:43 +0000 Message-ID: <44EC9B9E.3030505@us.fujitsu.com> Date: Wed, 23 Aug 2006 11:17:02 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: benjamin.niven-jenkins@bt.com CC: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ben, see inline. benjamin.niven-jenkins@bt.com wrote: > Igor, > > owner-ccamp@ops.ietf.org <> wrote: > >> Deborah. >> (My hat off since I am talking to a lady) >> >> Have you been in a situation when you just performed a >> software upgrade and a network operator tells you that your >> new release sucks and he wants the network in the state of >> this morning prior to the upgrade? No? Than you are lucky. >> > > I'm not sure I understand the relevance of this. > > >> Besides, what is the problem with moving "hundreds/thousands >> of LSPs from CP->MP"? >> > > The operating tenet is "if it aint broke don't fix it" so it'd likely > have to be a very good reason in order to make an operator move > hundreds/thousands of LSPs from CP->MP or MP->CP. I guess the jury is still out w/r to CP->MP as the discussion on the ML shows; but w/r to MP->CP, when an operator decides to deploy a CP, then control functions that resided in the MP should be delegated to that CP. There needs to be a migration strategy for that operation. > It'd also have to be > something forseeable as I can't see operators moving their LSPs from > CP->MP routinely when doing a software change. > I believe the authors were concerned about error handling and are not talking about this as a routine operation > Ben Richard. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 18:13:13 +0000 To: Snigdho Bardalai Cc: ccamp , Dan Li , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 23 Aug 2006 20:12:49 +0200 Content-Type: text/plain; charset="US-ASCII" hi - i am not sure to capture your point - let's say states are self-refreshed for some time, if the signaling channel is not up before pre-negotiated time - and you didn't fix this timer as being infinite - resources will be released when the cleanup elapses, in case one requires larger maintenance windows one provides such configuration beforehand => mis-using one mechanism and then require another to reconstruct consistent states is the first point that needs to be clarified (it is also important to clarify that LMP does not "reserve resources" it just mediates data link states so if the error needs to be corrected it will any interfere with the entituy that is making use of it what you are trying to achieve is detect mismatch but detect these mismach is not a solution to the problem but more importantly what is the trigger to the detection itself ? in brief how does one either of these sides knows it should start such "verification" process ... was it not at the end the reason for possibility of maintaining the "available" link on permanent verification state within LMP ? thanks, -d. Snigdho Bardalai 23/08/2006 18:14 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Dan Li , ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi Dimitri, Since a control-channel failure leads to RSVP hello failure the clean-up timeout event will not occur (due to auto-refresh). In case an intermediate or egress node initiates the deletion process and there is a temporary control-plane failure that disallows the delete request from reaching the ingress node, then there is a potential problem. Even though the intermediate or egress node initiates the force deletion process after the "no-response" timer expires the connection may get re-created once the control-plane recovers, because the ingress may continuously be transmitting Path messages. Even if the Path message contains the RECOVERY object, this will cause re-creation of the connection (Refer to RFC 3473 Section 9.5.2). One posible solution is to carry out a channel-status audit in order to detect such anamolies. Regards, Snigdho Dimitri.Papadimitriou@alcatel.be wrote: >just a brief remark > >i don't see why channel status verification can not be achieved with >current mechanism described in section 12.7 of 4204 (and there is a >need to come with a complete set of messages for this purpose) > >now i am even unclear how the problem you stated can occur > >"The channel status of a data link may become mismatched during the > LSP deletion process. If the LSP deletion process is aborted in the > middle of the process (perhaps because of a temporary control plane > failure), the cross-connection at the upstream node may be removed > while the downstream node still keeps its cross-connection." > >why do you think the notion of soft-state has been introduced ? once >the cleanup timeout (set to K times the refresh timeout) interval is >reached that then triggers a tear-down > >thanks, >- d. > > > > > > >Dan Li >Sent by: owner-ccamp@ops.ietf.org >23/08/2006 09:55 > > To: xuhuiying@huawei.com, "Zafar Ali (zali)" , >MEURIC Julien RD-CORE-LAN > cc: ccamp > Subject: Re: High level comment on >draft-li-ccamp-confirm-data-channel-status-00.txt, > > >Hi, > >Thanks Julien and Zafar for your comments. I agree with Julien. This I-D >just wants to provide a control plane tool to detect the inconsistent data >channel status in the tranport plane. > >Actually I have received several private emails think this I-D addresses a >real problem, but regarding the new LMP messages which are introduced in >this I-D, some people pointed out that the already deployed channelstatus >messages (id = 17, 18, 19 and 20) may be extended to carry also the >timeslot information instead only data link. But I have a concern that the >Fault Management Messages usually are triggered by fault detection, these >messages should not be sent if no fault is detected. The confirmation of >data channel status may need to be performed periodically or triggerd by >user. > >I would like to hear from you guys, what's your comments? Not only the >concerns raised above, but also other issues in this I-D. > >Regards, > >Dan > >----- Original Message ----- >From: "MEURIC Julien RD-CORE-LAN" >To: "Zafar Ali (zali)" ; ; > >Cc: "ccamp" >Sent: Tuesday, July 11, 2006 2:31 AM >Subject: RE: High level comment on >draft-li-ccamp-confirm-data-channel-status-00.txt, > > >Hi Zafar. > >I don't really get you on this. I figure out you're referring to >removing the connection states when RSVP refreshes are not received any >more, aren't you? If so, I'm afraid this is not enough for transmission >devices, where resources can be physically cross-connected even though >there is no (or no longer) corresponding RSVP state. Therefore having a >mechanism to avoid such discrepancies would be welcome. > >Regards, > >Julien > > >P.S.: If you totally rely on a management plane, I agree this should be >useless (e.g. the NMS should already know if a cross-connection deletion >failed, cf. Diego's 2nd slides seen this morning). > >________________________________ > > >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of Zafar Ali (zali) > >Dear Authors, > >RSVP refreshes do this job, so I am not sure motivation for this draft/ >LMP extensions. > >n.b. The draft state, "Although such a situation can be resolved through >the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], >such a procedure is inefficient since it may require an additional >signaling exchange for each LSP that is set up", so I assume that RSVP >signaling is present (Although I did not understand the quoted statement >from the ID). Even if RSVP is not present, e.g., optical core is >completely controlled by a management entity, I would argue introduce >presence of LMP. > >Thanks > >Regards... Zafar > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 18:11:27 +0000 Date: Wed, 23 Aug 2006 11:10:40 -0700 Message-Id: <200608231810.k7NIAeF3030118@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4606 on Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4606 Title: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control Author: E. Mannie, D. Papadimitriou Status: Standards Track Date: August 2006 Mailbox: eric.mannie@perceval.net, dimitri.papadimitriou@alcatel.be Pages: 25 Characters: 53492 Obsoletes: RFC3946 See-Also: I-D Tag: draft-ietf-ccamp-rfc3946bis-01.txt URL: http://www.rfc-editor.org/rfc/rfc4606.txt This document provides minor clarification to RFC 3946. This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when GMPLS signaling is used. [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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 18:06:10 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 14:05:41 -0400 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwAABe1rwAABBhyAAAMHGUAADCWqA From: "Bryskin, Igor" To: "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Snipped > > Furthermore, sometimes there is a need to actually=20 > > downgrade software, for instance, when one wants to add to=20 > > the network some older equipment. >=20 > Why would anyone want to do this, especially without=20 > upgrading this equipments' software? >=20 > IB>> Because the new software was developed on the assumption that it=20 > IB>> will work on the new hardware. Your customer, on the other hand,=20 > IB>> purchased your old equipment and you want to protect his=20 > IB>> investment. This is not what you said initially. You said 'add to=20 the network some older equipment.' IB>> No, that's exactly what I meant. My customer purchased a ring of = new devices with new software. The customer also happens to have several = rings of older devices running older software. The customer wants to = interconnect the new rings with old ones. The customer does not mind to = downgrade the software on the new ring so that it will be compatible = with other rings. Igor Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 17:59:06 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 13:58:12 -0400 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAABz4MAAAzIykA== From: "Bryskin, Igor" To: , Ben, > Deborah. > (My hat off since I am talking to a lady) >=20 > Have you been in a situation when you just performed a > software upgrade and a network operator tells you that your > new release sucks and he wants the network in the state of > this morning prior to the upgrade? No? Than you are lucky. I'm not sure I understand the relevance of this. IB>> Imagine the situation when a major software upgrade was performed = on all network controllers. The new software is significantly different = from the old release. After the upgrade a serious problem was = discovered. The operator wants to go back to the old software. Simple = software reversion is not possible. The operator does not want to loose = any of active services. So what do you do in this case? I say, do = CP->MP->CP > Besides, what is the problem with moving "hundreds/thousands > of LSPs from CP->MP"? The operating tenet is "if it aint broke don't fix it" so it'd likely have to be a very good reason in order to make an operator move hundreds/thousands of LSPs from CP->MP or MP->CP. It'd also have to be something forseeable as I can't see operators moving their LSPs from CP->MP routinely when doing a software change. IB>> From my remark above it should be obvious that I am not talking = about routine CP->MP procedures. I am talking about "Don't stand, do = something" kind of situation. Igor =20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 17:46:42 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 13:44:07 -0400 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAADc6lAAAcILgA== From: "Bryskin, Igor" To: "Drake, John E" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" >=20 > Have you been in a situation when you just performed a=20 > software upgrade and a network operator tells you that your=20 > new release sucks and he wants the network in the state of=20 > this morning prior to the upgrade? No? Than you are lucky. JD: This means reverting to the previous version of control plane software, not the CP->MP->CP detour. IB>> I am talking about the situation when simple reverting is not = possible due to incompatibility of the new and old software releases. Furthermore, on more general note, if we decide that we need to be = capable of doing MP->CP, just from the simmetricity point of view it = makes a lot of sense to me to have CP->MP capability for debugging and = testing the MP->CP move (if for nothing else)=20 Igor >=20 > Besides, what is the problem with moving "hundreds/thousands=20 > of LSPs from CP->MP"?=20 >=20 > Igor >=20 > -----Original Message----- > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > Sent: Wednesday, August 23, 2006 11:43 AM > To: Drake, John E; Bryskin, Igor; Diego Caviglia;=20 > Dimitri.Papadimitriou > Cc: " ccamp " Farrel Subject: RE: Polling for new WG I-Ds >=20 >=20 > Agree with John, and control plane failures don't (should=20 > not/hope not) impact the data plane state. And before doing=20 > such a sw upgrade, I would not want to have to move=20 > hundreds/thousands of LSPs from CP->MP. >=20 > I'm not sure myself on what is meant by CP->MP, need to discuss more. >=20 > (chair hat off) > Deborah=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E > Sent: Wednesday, August 23, 2006 11:13 AM > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou > Cc: " ccamp " Farrel Subject: RE: Polling for new WG I-Ds >=20 > Snipped >=20 > >=20 > > Besides I can see at least one quite real application for > > CP->MP. Imagine that an operator wants to perform some major > > software upgrade with a new software version significantly > > incompatible with the previous one. >=20 > JD: Except that we go to great pains to ensure that this=20 > situation never occurs.=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 16:40:09 +0000 Message-ID: <0f4401c6c6d2$b986aa40$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Diego Caviglia" , "Dan Li" Cc: "xuhuiying" , "Zafar Ali" , "MEURIC Julien RD-CORE-LAN" , Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Date: Wed, 23 Aug 2006 12:49:33 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi all, The problem statement in this draft is clear, and it seems to me that this problem might arise in a real network depending on the way the network is managed. It is also clear to me that the current signaling protocols handle this type of problem , but that the process is not ideal. That is, LSPs would not necessarily fail to set up, but there might be some exchange of PathErr messages with Acceptable Label Set objects. Since the problem described in the draft is likely to be persistent, this signaling exchange would possibly be required on every LSP setup that uses the link in question. Functional, but not ideal. It would be good if you could add a short sub-section to section 2 to describe how the existing signaling protocols will handle the problem and why you believe that this is not adequate. Now, in general, we don't develop protocol extensions to optimise for error cases, so we have to be careful. If your proposals required continuous monitoring of available resources on each link, that would be a step to far. But if your proposal reflects a start-of-day cross-check followed (optionally) by updates triggered by operator intervention or infrequent timers, that is likely to be acceptable. With regard to the use of existing messages or the definition of new messages: there are architectural and implementation choices. Although we inevitably need to be driven by the implementations, I am not a fan of overloading messages. IMHO the Fault Management messages are currently triggered by a perceived fault: they are used to report and isolated faults. The new function is used to detect faults, not to report or isolate them. While I can see Diego's point that the objective is to find faults, the messages proposed by Dan do not report faults, they report information. Faults are only detected when the correlation between information at the two ends of the link is made. I think that if you wanted to go down the route suggested by Diego you would probably want to limit the information exchanged to only the data channels that are suspect, but I don't see how you can report the channels that are not available (because you might not know about them!) - it is only by hearing about the channels that your partner believes exist that you can deduce problems. In terms of implementation, it really doesn't seem to be very expensive either way. You might want to consider how backward compatibility works with the two options. It is pretty clear how to handle a new message type that is not supported. What will be the impact of adding new TLVs to existing messages? Cheers, Adrian ----- Original Message ----- From: "Diego Caviglia" To: "Dan Li Cc: "xuhuiying" ; "Zafar Ali (zali) ; "MEURIC Julien RD-CORE-LAN ; "ccamp Sent: Wednesday, August 23, 2006 10:31 AM Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, > > Hi Dan, > first of all I think that the ID addresses a real problem. > > Regarding the bits and bytes I prefer to not implemet new messages but > just > updateds the existing ones that seems to fit to the problem. > > I think that having a timeslot that should be usable that is actually > unusable is a failure from the control plane prespective. > > So I think that is correct to use the Fault Management Messages to convey > information about unusable channles. > > Regards > > Diego > > > > Dan Li @ops.ietf.org on 23/08/2006 09.55.49 > > Sent by: owner-ccamp@ops.ietf.org > > > To: xuhuiying@huawei.com, "Zafar Ali (zali)" , MEURIC > Julien RD-CORE-LAN > cc: ccamp > > Subject: Re: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > Hi, > > Thanks Julien and Zafar for your comments. I agree with Julien. This I-D > just wants to provide a control plane tool to detect the inconsistent data > channel status in the tranport plane. > > Actually I have received several private emails think this I-D addresses a > real problem, but regarding the new LMP messages which are introduced in > this I-D, some people pointed out that the already deployed channelstatus > messages (id = 17, 18, 19 and 20) may be extended to carry also the > timeslot information instead only data link. But I have a concern that the > Fault Management Messages usually are triggered by fault detection, these > messages should not be sent if no fault is detected. The confirmation of > data channel status may need to be performed periodically or triggerd by > user. > > I would like to hear from you guys, what's your comments? Not only the > concerns raised above, but also other issues in this I-D. > > Regards, > > Dan > > ----- Original Message ----- > From: "MEURIC Julien RD-CORE-LAN" > To: "Zafar Ali (zali)" ; ; > > Cc: "ccamp" > Sent: Tuesday, July 11, 2006 2:31 AM > Subject: RE: High level comment on > draft-li-ccamp-confirm-data-channel-status-00.txt, > > > Hi Zafar. > > I don't really get you on this. I figure out you're referring to > removing the connection states when RSVP refreshes are not received any > more, aren't you? If so, I'm afraid this is not enough for transmission > devices, where resources can be physically cross-connected even though > there is no (or no longer) corresponding RSVP state. Therefore having a > mechanism to avoid such discrepancies would be welcome. > > Regards, > > Julien > > > P.S.: If you totally rely on a management plane, I agree this should be > useless (e.g. the NMS should already know if a cross-connection deletion > failed, cf. Diego's 2nd slides seen this morning). > > ________________________________ > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Zafar Ali (zali) > > Dear Authors, > > RSVP refreshes do this job, so I am not sure motivation for this draft/ > LMP extensions. > > n.b. The draft state, "Although such a situation can be resolved through > the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], > such a procedure is inefficient since it may require an additional > signaling exchange for each LSP that is set up", so I assume that RSVP > signaling is present (Although I did not understand the quoted statement > from the ID). Even if RSVP is not present, e.g., optical core is > completely controlled by a management entity, I would argue introduce > presence of LMP. > > Thanks > > Regards... Zafar > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 16:35:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 09:34:55 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DD01@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwAABe1rwAABBhyAAAMHGUA== From: "Drake, John E" To: "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Snipped > > Furthermore, sometimes there is a need to actually=20 > > downgrade software, for instance, when one wants to add to=20 > > the network some older equipment. >=20 > Why would anyone want to do this, especially without=20 > upgrading this equipments' software? >=20 > IB>> Because the new software was developed on the assumption that it=20 > IB>> will work on the new hardware. Your customer, on the other hand,=20 > IB>> purchased your old equipment and you want to protect his=20 > IB>> investment. This is not what you said initially. You said 'add to=20 the network some older equipment.' Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 16:28:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 09:27:05 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DCFF@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAADc6lA= From: "Drake, John E" To: "Bryskin, Igor" , "Brungard, Deborah A, ALABS" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" >=20 > Have you been in a situation when you just performed a=20 > software upgrade and a network operator tells you that your=20 > new release sucks and he wants the network in the state of=20 > this morning prior to the upgrade? No? Than you are lucky. JD: This means reverting to the previous version of control plane software, not the CP->MP->CP detour. >=20 > Besides, what is the problem with moving "hundreds/thousands=20 > of LSPs from CP->MP"?=20 >=20 > Igor >=20 > -----Original Message----- > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > Sent: Wednesday, August 23, 2006 11:43 AM > To: Drake, John E; Bryskin, Igor; Diego Caviglia;=20 > Dimitri.Papadimitriou > Cc: " ccamp " Farrel Subject: RE: Polling for new WG I-Ds >=20 >=20 > Agree with John, and control plane failures don't (should=20 > not/hope not) impact the data plane state. And before doing=20 > such a sw upgrade, I would not want to have to move=20 > hundreds/thousands of LSPs from CP->MP. >=20 > I'm not sure myself on what is meant by CP->MP, need to discuss more. >=20 > (chair hat off) > Deborah=20 >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E > Sent: Wednesday, August 23, 2006 11:13 AM > To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou > Cc: " ccamp " Farrel Subject: RE: Polling for new WG I-Ds >=20 > Snipped >=20 > >=20 > > Besides I can see at least one quite real application for > > CP->MP. Imagine that an operator wants to perform some major > > software upgrade with a new software version significantly > > incompatible with the previous one. >=20 > JD: Except that we go to great pains to ensure that this=20 > situation never occurs.=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 16:28:01 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 12:16:16 -0400 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwAABe1rwAABBhyA= From: "Bryskin, Igor" To: "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" >=20 > JD: Except that we go to great pains to ensure that this=20 > situation never occurs.=20 >=20 > You are right, we do. In theory such situations should not=20 > happen, however, we all know that in practice there are=20 > always cases when original (especially proprietary) protocol=20 > solutions are not thought through enough, and it is=20 > impossible to maintain backward compatibility between the=20 > software releases. That's why I am talking about *major*=20 > upgrades. Furthermore, sometimes there is a need to actually=20 > downgrade software, for instance, when one wants to add to=20 > the network some older equipment. Why would anyone want to do this, especially without upgrading this equipments' software? IB>> Because the new software was developed on the assumption that it = will work on the new hardware. Your customer, on the other hand, = purchased your old equipment and you want to protect his investment. > Again, the ability to do=20 > the CP->MP->CP trick would help Except that, as Lyndon and Deborah pointed out, the CP->MP->CP trick has perils of its own. IB>> Except that they were not specific what those perils are. Igor Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 16:18:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 17:17:55 +0100 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCwAABz4MA= From: To: Igor, owner-ccamp@ops.ietf.org <> wrote: > Deborah. > (My hat off since I am talking to a lady) >=20 > Have you been in a situation when you just performed a > software upgrade and a network operator tells you that your > new release sucks and he wants the network in the state of > this morning prior to the upgrade? No? Than you are lucky. I'm not sure I understand the relevance of this. > Besides, what is the problem with moving "hundreds/thousands > of LSPs from CP->MP"? The operating tenet is "if it aint broke don't fix it" so it'd likely have to be a very good reason in order to make an operator move hundreds/thousands of LSPs from CP->MP or MP->CP. It'd also have to be something forseeable as I can't see operators moving their LSPs from CP->MP routinely when doing a software change. Ben =20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 16:15:49 +0000 Message-ID: <44EC7EE8.70402@us.fujitsu.com> Date: Wed, 23 Aug 2006 11:14:32 -0500 From: Snigdho Bardalai Organization: Fujitsu Network Communications User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512 MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: Dan Li , ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Dimitri, Since a control-channel failure leads to RSVP hello failure the clean-up timeout event will not occur (due to auto-refresh). In case an intermediate or egress node initiates the deletion process and there is a temporary control-plane failure that disallows the delete request from reaching the ingress node, then there is a potential problem. Even though the intermediate or egress node initiates the force deletion process after the "no-response" timer expires the connection may get re-created once the control-plane recovers, because the ingress may continuously be transmitting Path messages. Even if the Path message contains the RECOVERY object, this will cause re-creation of the connection (Refer to RFC 3473 Section 9.5.2). One posible solution is to carry out a channel-status audit in order to detect such anamolies. Regards, Snigdho Dimitri.Papadimitriou@alcatel.be wrote: >just a brief remark > >i don't see why channel status verification can not be achieved with >current mechanism described in section 12.7 of 4204 (and there is a >need to come with a complete set of messages for this purpose) > >now i am even unclear how the problem you stated can occur > >"The channel status of a data link may become mismatched during the > LSP deletion process. If the LSP deletion process is aborted in the > middle of the process (perhaps because of a temporary control plane > failure), the cross-connection at the upstream node may be removed > while the downstream node still keeps its cross-connection." > >why do you think the notion of soft-state has been introduced ? once >the cleanup timeout (set to K times the refresh timeout) interval is >reached that then triggers a tear-down > >thanks, >- d. > > > > > > >Dan Li >Sent by: owner-ccamp@ops.ietf.org >23/08/2006 09:55 > > To: xuhuiying@huawei.com, "Zafar Ali (zali)" , >MEURIC Julien RD-CORE-LAN > cc: ccamp > Subject: Re: High level comment on >draft-li-ccamp-confirm-data-channel-status-00.txt, > > >Hi, > >Thanks Julien and Zafar for your comments. I agree with Julien. This I-D >just wants to provide a control plane tool to detect the inconsistent data >channel status in the tranport plane. > >Actually I have received several private emails think this I-D addresses a >real problem, but regarding the new LMP messages which are introduced in >this I-D, some people pointed out that the already deployed channelstatus >messages (id = 17, 18, 19 and 20) may be extended to carry also the >timeslot information instead only data link. But I have a concern that the >Fault Management Messages usually are triggered by fault detection, these >messages should not be sent if no fault is detected. The confirmation of >data channel status may need to be performed periodically or triggerd by >user. > >I would like to hear from you guys, what's your comments? Not only the >concerns raised above, but also other issues in this I-D. > >Regards, > >Dan > >----- Original Message ----- >From: "MEURIC Julien RD-CORE-LAN" >To: "Zafar Ali (zali)" ; ; > >Cc: "ccamp" >Sent: Tuesday, July 11, 2006 2:31 AM >Subject: RE: High level comment on >draft-li-ccamp-confirm-data-channel-status-00.txt, > > >Hi Zafar. > >I don't really get you on this. I figure out you're referring to >removing the connection states when RSVP refreshes are not received any >more, aren't you? If so, I'm afraid this is not enough for transmission >devices, where resources can be physically cross-connected even though >there is no (or no longer) corresponding RSVP state. Therefore having a >mechanism to avoid such discrepancies would be welcome. > >Regards, > >Julien > > >P.S.: If you totally rely on a management plane, I agree this should be >useless (e.g. the NMS should already know if a cross-connection deletion >failed, cf. Diego's 2nd slides seen this morning). > >________________________________ > > >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of Zafar Ali (zali) > >Dear Authors, > >RSVP refreshes do this job, so I am not sure motivation for this draft/ >LMP extensions. > >n.b. The draft state, "Although such a situation can be resolved through >the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], >such a procedure is inefficient since it may require an additional >signaling exchange for each LSP that is set up", so I assume that RSVP >signaling is present (Although I did not understand the quoted statement >from the ID). Even if RSVP is not present, e.g., optical core is >completely controlled by a management entity, I would argue introduce >presence of LMP. > >Thanks > >Regards... Zafar > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 16:09:36 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 12:08:59 -0400 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AAABGTCw From: "Bryskin, Igor" To: "Brungard, Deborah A, ALABS" , "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Deborah. (My hat off since I am talking to a lady) Have you been in a situation when you just performed a software upgrade = and a network operator tells you that your new release sucks and he = wants the network in the state of this morning prior to the upgrade? No? = Than you are lucky. Besides, what is the problem with moving "hundreds/thousands of LSPs = from CP->MP"?=20 Igor -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Wednesday, August 23, 2006 11:43 AM To: Drake, John E; Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " MP. I'm not sure myself on what is meant by CP->MP, need to discuss more. (chair hat off) Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E Sent: Wednesday, August 23, 2006 11:13 AM To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " =20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 16:09:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 09:08:45 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DCFC@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwAABe1rw From: "Drake, John E" To: "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" >=20 > JD: Except that we go to great pains to ensure that this=20 > situation never occurs.=20 >=20 > You are right, we do. In theory such situations should not=20 > happen, however, we all know that in practice there are=20 > always cases when original (especially proprietary) protocol=20 > solutions are not thought through enough, and it is=20 > impossible to maintain backward compatibility between the=20 > software releases. That's why I am talking about *major*=20 > upgrades. Furthermore, sometimes there is a need to actually=20 > downgrade software, for instance, when one wants to add to=20 > the network some older equipment. Why would anyone want to do this, especially without upgrading this equipments' software? > Again, the ability to do=20 > the CP->MP->CP trick would help Except that, as Lyndon and Deborah pointed out, the CP->MP->CP trick has perils of its own. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 15:55:44 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 11:54:59 -0400 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAGsrwA== From: "Bryskin, Igor" To: "Drake, John E" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" John. >=20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 You are right, we do. In theory such situations should not happen, = however, we all know that in practice there are always cases when = original (especially proprietary) protocol solutions are not thought = through enough, and it is impossible to maintain backward compatibility = between the software releases. That's why I am talking about *major* = upgrades. Furthermore, sometimes there is a need to actually downgrade = software, for instance, when one wants to add to the network some older = equipment. Again, the ability to do the CP->MP->CP trick would help Igor Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 15:42:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 10:42:43 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0CA60A0A@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAK8+AA== From: "Brungard, Deborah A, ALABS" To: "Drake, John E" , "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Agree with John, and control plane failures don't (should not/hope not) impact the data plane state. And before doing such a sw upgrade, I would not want to have to move hundreds/thousands of LSPs from CP->MP. I'm not sure myself on what is meant by CP->MP, need to discuss more. (chair hat off) Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E Sent: Wednesday, August 23, 2006 11:13 AM To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " =20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 15:36:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 11:35:21 -0400 Message-ID: <0901D1988E815341A0103206A834DA07F9B47B@mdmxm02.ciena.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIAAAMJUQA== From: "Ong, Lyndon" To: "Drake, John E" , "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" I agree with this. Besides, transitioning from CP->MP would=20 introduce its own risks.=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E Sent: Wednesday, August 23, 2006 8:13 AM To: Bryskin, Igor; Diego Caviglia; Dimitri.Papadimitriou Cc: " ccamp " =20 > Besides I can see at least one quite real application for > CP->MP. Imagine that an operator wants to perform some major > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 15:15:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 08:12:41 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DCF8@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpAAAFOBIA= From: "Drake, John E" To: "Bryskin, Igor" , "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Snipped >=20 > Besides I can see at least one quite real application for=20 > CP->MP. Imagine that an operator wants to perform some major=20 > software upgrade with a new software version significantly=20 > incompatible with the previous one. JD: Except that we go to great pains to ensure that this situation never occurs.=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 14:43:57 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Wed, 23 Aug 2006 10:43:23 -0400 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbGwEAhStJu0uUdQ1eUzMWN4ZsN7wAAKMpA From: "Bryskin, Igor" To: "Diego Caviglia" , "Dimitri.Papadimitriou" Cc: "\" ccamp \" , "\" owner-ccamp \" , "Adrian Farrel , "danli" Hi, I agree with Diego on this. One of the reasons why operators are so = nervous about using CP is CP's unpredictability (because of its dynamic = nature). I am sure they will be more confident if/when they know that = there is a way to undo everything or something that might go wrong with = migration to CP without breaking active services. Besides I can see at least one quite real application for CP->MP. = Imagine that an operator wants to perform some major software upgrade = with a new software version significantly incompatible with the previous = one. One way to perform such an upgrade: a) CP->MP; b) perform software upgrade on all controllers c) MP->CP Igor -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Diego Caviglia Sent: Wednesday, August 23, 2006 10:12 AM To: Dimitri.Papadimitriou Cc: " ccamp " cc: "ccamp" , "owner-ccamp" , Adrian Farrel , danli@huawei.com Subject: Re: Polling for new WG I-Ds hi diego - [snipped] > hence, it is strongly suggested to identify conditions when such = CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the = MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed = just simply in case the carriers want to withdraw their previous decision, = and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves [dc] I think they or some of them already did this. Looking at the pool seems that at least 4 carries voted yes to the ID. [dp] not sure they express specific opinion on this aspect which is = "shall we take care about how to step back from GMPLS ?" it may be the case but then the discussion has much fundamental impact than the discussion = around this specific i-d [dc] I dont' think they said "we agree on moving this ID to WG" without having read the doc, the point in the ID (we already agreed that is not = a mandatory requirement but only optional) is that should (or may or = shall) be possible to move back to NMS a circuit that was provisioned by the = CP. That is in the ID. I was just pointing out that some carriers have already expressed their opinion on the ID and thus on the CP->MP feature. This is in line with = the Dan sentence. The sentence "shall we take care about how to step back from GMPLS?" was not in the intention of the ID. - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) [dc] Of course I think we should. [dp] if i well understand your conclusion putting both of your answers toghether it would mean that CCAMP should take care about how "removing" GMPLS CP ? [dc] No the point is that IMHO could be useful for carriers to have the possibility to move a CP created circuit to the NMS. May be this = operation can be performed via CP. This does not means to remove the whole control plane. ... interesting opinion, it took 6 years for CCAMP to have something = more or less workable now you and your co-authors are probably trying to init an item to disband this work, if this is the case i don't even = understand how we are polling for this document on this list [dc] I don't think this is in the ID. If my previous answer suggested = this is my fault. [snipped] Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 14:14:20 +0000 Sensitivity: Subject: Re: Polling for new WG I-Ds To: "Dimitri.Papadimitriou" Cc: ""ccamp" , ""owner-ccamp" , "Adrian Farrel , "danli" Message-ID: From: "Diego Caviglia" Date: Wed, 23 Aug 2006 16:12:11 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Dimitri, in line. Regards Diego Dimitri.Papadimitriou@alcatel.be on 23/08/2006 15.51.23 To: "Diego Caviglia" cc: "ccamp" , "owner-ccamp" , Adrian Farrel , danli@huawei.com Subject: Re: Polling for new WG I-Ds hi diego - [snipped] > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves [dc] I think they or some of them already did this. Looking at the pool seems that at least 4 carries voted yes to the ID. [dp] not sure they express specific opinion on this aspect which is "shall we take care about how to step back from GMPLS ?" it may be the case but then the discussion has much fundamental impact than the discussion around this specific i-d [dc] I dont' think they said "we agree on moving this ID to WG" without having read the doc, the point in the ID (we already agreed that is not a mandatory requirement but only optional) is that should (or may or shall) be possible to move back to NMS a circuit that was provisioned by the CP. That is in the ID. I was just pointing out that some carriers have already expressed their opinion on the ID and thus on the CP->MP feature. This is in line with the Dan sentence. The sentence "shall we take care about how to step back from GMPLS?" was not in the intention of the ID. - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) [dc] Of course I think we should. [dp] if i well understand your conclusion putting both of your answers toghether it would mean that CCAMP should take care about how "removing" GMPLS CP ? [dc] No the point is that IMHO could be useful for carriers to have the possibility to move a CP created circuit to the NMS. May be this operation can be performed via CP. This does not means to remove the whole control plane. ... interesting opinion, it took 6 years for CCAMP to have something more or less workable now you and your co-authors are probably trying to init an item to disband this work, if this is the case i don't even understand how we are polling for this document on this list [dc] I don't think this is in the ID. If my previous answer suggested this is my fault. [snipped] Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 13:53:18 +0000 To: "Diego Caviglia" Cc: "ccamp" , "owner-ccamp" , Adrian Farrel , danli@huawei.com Subject: Re: Polling for new WG I-Ds MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 23 Aug 2006 15:51:23 +0200 Content-Type: text/plain; charset="US-ASCII" hi diego - "Diego Caviglia" 23/08/2006 11:13 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Dan Li , "owner-ccamp" Subject: Re: Polling for new WG I-Ds Hi Dimitri, some comments in line. Regards Diego Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 23/08/2006 10.33.10 Sent by: owner-ccamp@ops.ietf.org To: Dan Li cc: Adrian Farrel , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds hi - see inline Dan Li Sent by: owner-ccamp@ops.ietf.org 21/08/2006 04:01 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Hi Dimitri, Please see in line. Regards, Dan ----- Original Message ----- From: To: "Adrian Farrel" Cc: ; Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds [snipped] > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves [dc] I think they or some of them already did this. Looking at the pool seems that at least 4 carries voted yes to the ID. [dp] not sure they express specific opinion on this aspect which is "shall we take care about how to step back from GMPLS ?" it may be the case but then the discussion has much fundamental impact than the discussion around this specific i-d - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) [dc] Of course I think we should. [dp] if i well understand your conclusion putting both of your answers toghether it would mean that CCAMP should take care about how "removing" GMPLS CP ? ... interesting opinion, it took 6 years for CCAMP to have something more or less workable now you and your co-authors are probably trying to init an item to disband this work, if this is the case i don't even understand how we are polling for this document on this list [snipped] Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 12:48:06 +0000 To: Dan Li Cc: ccamp , MEURIC Julien RD-CORE-LAN , owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 23 Aug 2006 14:45:41 +0200 Content-Type: text/plain; charset="US-ASCII" just a brief remark i don't see why channel status verification can not be achieved with current mechanism described in section 12.7 of 4204 (and there is a need to come with a complete set of messages for this purpose) now i am even unclear how the problem you stated can occur "The channel status of a data link may become mismatched during the LSP deletion process. If the LSP deletion process is aborted in the middle of the process (perhaps because of a temporary control plane failure), the cross-connection at the upstream node may be removed while the downstream node still keeps its cross-connection." why do you think the notion of soft-state has been introduced ? once the cleanup timeout (set to K times the refresh timeout) interval is reached that then triggers a tear-down thanks, - d. Dan Li Sent by: owner-ccamp@ops.ietf.org 23/08/2006 09:55 To: xuhuiying@huawei.com, "Zafar Ali (zali)" , MEURIC Julien RD-CORE-LAN cc: ccamp Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi, Thanks Julien and Zafar for your comments. I agree with Julien. This I-D just wants to provide a control plane tool to detect the inconsistent data channel status in the tranport plane. Actually I have received several private emails think this I-D addresses a real problem, but regarding the new LMP messages which are introduced in this I-D, some people pointed out that the already deployed channelstatus messages (id = 17, 18, 19 and 20) may be extended to carry also the timeslot information instead only data link. But I have a concern that the Fault Management Messages usually are triggered by fault detection, these messages should not be sent if no fault is detected. The confirmation of data channel status may need to be performed periodically or triggerd by user. I would like to hear from you guys, what's your comments? Not only the concerns raised above, but also other issues in this I-D. Regards, Dan ----- Original Message ----- From: "MEURIC Julien RD-CORE-LAN" To: "Zafar Ali (zali)" ; ; Cc: "ccamp" Sent: Tuesday, July 11, 2006 2:31 AM Subject: RE: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi Zafar. I don't really get you on this. I figure out you're referring to removing the connection states when RSVP refreshes are not received any more, aren't you? If so, I'm afraid this is not enough for transmission devices, where resources can be physically cross-connected even though there is no (or no longer) corresponding RSVP state. Therefore having a mechanism to avoid such discrepancies would be welcome. Regards, Julien P.S.: If you totally rely on a management plane, I agree this should be useless (e.g. the NMS should already know if a cross-connection deletion failed, cf. Diego's 2nd slides seen this morning). ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Dear Authors, RSVP refreshes do this job, so I am not sure motivation for this draft/ LMP extensions. n.b. The draft state, "Although such a situation can be resolved through the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], such a procedure is inefficient since it may require an additional signaling exchange for each LSP that is set up", so I assume that RSVP signaling is present (Although I did not understand the quoted statement from the ID). Even if RSVP is not present, e.g., optical core is completely controlled by a management entity, I would argue introduce presence of LMP. Thanks Regards... Zafar Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 09:33:11 +0000 Sensitivity: Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, To: "Dan Li Cc: "xuhuiying" , ""Zafar Ali (zali)" , "MEURIC Julien RD-CORE-LAN , "ccamp Message-ID: From: "Diego Caviglia" Date: Wed, 23 Aug 2006 11:31:23 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Dan, first of all I think that the ID addresses a real problem. Regarding the bits and bytes I prefer to not implemet new messages but just updateds the existing ones that seems to fit to the problem. I think that having a timeslot that should be usable that is actually unusable is a failure from the control plane prespective. So I think that is correct to use the Fault Management Messages to convey information about unusable channles. Regards Diego Dan Li @ops.ietf.org on 23/08/2006 09.55.49 Sent by: owner-ccamp@ops.ietf.org To: xuhuiying@huawei.com, "Zafar Ali (zali)" , MEURIC Julien RD-CORE-LAN cc: ccamp Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi, Thanks Julien and Zafar for your comments. I agree with Julien. This I-D just wants to provide a control plane tool to detect the inconsistent data channel status in the tranport plane. Actually I have received several private emails think this I-D addresses a real problem, but regarding the new LMP messages which are introduced in this I-D, some people pointed out that the already deployed channelstatus messages (id = 17, 18, 19 and 20) may be extended to carry also the timeslot information instead only data link. But I have a concern that the Fault Management Messages usually are triggered by fault detection, these messages should not be sent if no fault is detected. The confirmation of data channel status may need to be performed periodically or triggerd by user. I would like to hear from you guys, what's your comments? Not only the concerns raised above, but also other issues in this I-D. Regards, Dan ----- Original Message ----- From: "MEURIC Julien RD-CORE-LAN" To: "Zafar Ali (zali)" ; ; Cc: "ccamp" Sent: Tuesday, July 11, 2006 2:31 AM Subject: RE: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi Zafar. I don't really get you on this. I figure out you're referring to removing the connection states when RSVP refreshes are not received any more, aren't you? If so, I'm afraid this is not enough for transmission devices, where resources can be physically cross-connected even though there is no (or no longer) corresponding RSVP state. Therefore having a mechanism to avoid such discrepancies would be welcome. Regards, Julien P.S.: If you totally rely on a management plane, I agree this should be useless (e.g. the NMS should already know if a cross-connection deletion failed, cf. Diego's 2nd slides seen this morning). ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Dear Authors, RSVP refreshes do this job, so I am not sure motivation for this draft/ LMP extensions. n.b. The draft state, "Although such a situation can be resolved through the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], such a procedure is inefficient since it may require an additional signaling exchange for each LSP that is set up", so I assume that RSVP signaling is present (Although I did not understand the quoted statement from the ID). Even if RSVP is not present, e.g., optical core is completely controlled by a management entity, I would argue introduce presence of LMP. Thanks Regards... Zafar Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 09:17:59 +0000 Sensitivity: Subject: Re: Polling for new WG I-Ds To: "Dimitri.Papadimitriou" Cc: "Dan Li , "Adrian Farrel , "ccamp" , "owner-ccamp" Message-ID: From: "Diego Caviglia" Date: Wed, 23 Aug 2006 11:13:44 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Dimitri, some comments in line. Regards Diego Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 23/08/2006 10.33.10 Sent by: owner-ccamp@ops.ietf.org To: Dan Li cc: Adrian Farrel , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds hi - see inline Dan Li Sent by: owner-ccamp@ops.ietf.org 21/08/2006 04:01 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Hi Dimitri, Please see in line. Regards, Dan ----- Original Message ----- From: To: "Adrian Farrel" Cc: ; Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds [snipped] > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves [dc] I think they or some of them already did this. Looking at the pool seems that at least 4 carries voted yes to the ID. - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) [dc] Of course I think we should. [snipped] Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 08:34:09 +0000 To: Dan Li Cc: Adrian Farrel , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 23 Aug 2006 10:33:10 +0200 Content-Type: text/plain; charset="US-ASCII" hi - see inline Dan Li Sent by: owner-ccamp@ops.ietf.org 21/08/2006 04:01 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Hi Dimitri, Please see in line. Regards, Dan ----- Original Message ----- From: To: "Adrian Farrel" Cc: ; Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds > adrian - see in-line > > Adrian Farrel wrote: > > Hi, > > > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > > > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > > > has been updated by the authors to provide further details and > > clarification. > > - ok - > > > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > > - guess it is v03.txt ? - > > > has been updated since the version discussed in Montreal. > > i am ok in investigating the MP->CP but i have two concerns that imho > should deserve more specific attention to maintain consistency wrt to > CP->MP > > section 2.2: if control is lost for an LSP (during CP failure) how can it > be possible transfer that LSP from the CP -> MP ? [dan] Yes, there is a problem if we still want to use the control plane to do the CP->MP transfer. Unless the transfer is based on the predetermined policy, MP takes the control of the LSP resource directly (no signaling required), but this way should not be discussed in CCAMP. [dp] ok so what's left for this doc ? concerning the MP-driven failover - imho nothing > section 4.4: why the document assumes that both MUST be supported ? in > part. concerning the CP->MP if one does implement current GMPLS signaling > restart/recovery why shall this be mandated ? in brief, the document shall > take into account existing mechanisms and prevent overlaps (with existing > GMPLS mechanisms) > [dan] I think the CP->MP should not be the mandatory requirement. [dp] this is what i thought > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. [dp] concerning CP->MP input you provided would be helpful to have carrier's speaking for themselves - now there is indeed a side question shall CCAMP take care about operators that want to step back from GMPLS or more generally any control plane technology (usually concern is how to move forward not backward) > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > > > has been updated as Zafar says in his previous email. > > informational imho - in its current version > > - not sure to understand why the PathErr/Notify can be processed by the > head-end only (what about segment recovery and stitching case) - why only > MBB is possible upon reception (pls use E2E recovery/Segment recovery > capabilities as you address GMPLS networks) > > - compared to path-reopt, error description is identical for the TE link > case which leads to the following point - if errors code/value are the > same how to distinguish them (assuming that the query procedure described > in path-reopt is used during the setup of that LSP) ? - comment is more > for the path-reopt draft than yours but since there is an overlap ... it > must be addressed in a way or another (note that when fully head-end > driven operations look similar but there is a major difference role of > timing and severity of the error code/value) > > - in case shutdown of a protected component link (of a bundle) is > initiated why can't link protection be used ? > > > Please send yes or no for these I-Ds. > > > > Reasons and opinions are also welcomed. > > > > Thanks, > > Adrian > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 08:01:43 +0000 Date: Wed, 23 Aug 2006 15:55:49 +0800 From: Dan Li Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, To: xuhuiying@huawei.com, "Zafar Ali (zali)" , MEURIC Julien RD-CORE-LAN Cc: ccamp Message-id: <007901c6c689$8c828120$d04c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Thanks Julien and Zafar for your comments. I agree with Julien. This I-D just wants to provide a control plane tool to detect the inconsistent data channel status in the tranport plane. Actually I have received several private emails think this I-D addresses a real problem, but regarding the new LMP messages which are introduced in this I-D, some people pointed out that the already deployed channelstatus messages (id = 17, 18, 19 and 20) may be extended to carry also the timeslot information instead only data link. But I have a concern that the Fault Management Messages usually are triggered by fault detection, these messages should not be sent if no fault is detected. The confirmation of data channel status may need to be performed periodically or triggerd by user. I would like to hear from you guys, what's your comments? Not only the concerns raised above, but also other issues in this I-D. Regards, Dan ----- Original Message ----- From: "MEURIC Julien RD-CORE-LAN" To: "Zafar Ali (zali)" ; ; Cc: "ccamp" Sent: Tuesday, July 11, 2006 2:31 AM Subject: RE: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, Hi Zafar. I don't really get you on this. I figure out you're referring to removing the connection states when RSVP refreshes are not received any more, aren't you? If so, I'm afraid this is not enough for transmission devices, where resources can be physically cross-connected even though there is no (or no longer) corresponding RSVP state. Therefore having a mechanism to avoid such discrepancies would be welcome. Regards, Julien P.S.: If you totally rely on a management plane, I agree this should be useless (e.g. the NMS should already know if a cross-connection deletion failed, cf. Diego's 2nd slides seen this morning). ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali) Dear Authors, RSVP refreshes do this job, so I am not sure motivation for this draft/ LMP extensions. n.b. The draft state, "Although such a situation can be resolved through the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], such a procedure is inefficient since it may require an additional signaling exchange for each LSP that is set up", so I assume that RSVP signaling is present (Although I did not understand the quoted statement from the ID). Even if RSVP is not present, e.g., optical core is completely controlled by a management entity, I would argue introduce presence of LMP. Thanks Regards... Zafar Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Aug 2006 00:31:23 +0000 Message-ID: <44EBA14A.30802@kddilabs.jp> Date: Wed, 23 Aug 2006 09:28:58 +0900 From: Tomohiro Otani User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Tomohiro Otani Cc: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hello, I also support the others. Regards, tomo Tomohiro Otani wrote: > Hi Adrian, > > I support the third draft to be a WG. > > Regards, > > tomo > > > Adrian Farrel wrote: >> Hi, >> >> As discussed in Montreal, we need to poll for a couple of new WG drafts. >> >> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt >> has been updated by the authors to provide further details and >> clarification. >> >> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt >> has been updated since the version discussed in Montreal. >> >> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt >> has been updated as Zafar says in his previous email. >> >> >> Please send yes or no for these I-Ds. >> >> Reasons and opinions are also welcomed. >> >> Thanks, >> Adrian >> >> >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Aug 2006 08:52:51 +0000 Message-ID: <0d6701c6c5c8$0f3a5510$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Subject: Fw: I-D ACTION:draft-andersson-rtg-gmpls-change-03.txt Date: Tue, 22 Aug 2006 09:49:54 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit All, After much debate and discussion, the ADs and WG chairs have produced a new revision of the (G)MPLS change process draft. This should be read in conjunction with http://www.ietf.org/internet-drafts/draft-carpenter--protocol-extensions-01.txt To avoid cross-posting, please send any comments (which will be gratefully received) to the Routing Area discussion mailing list only. Thanks, Adrian ----- Original Message ----- From: To: Sent: Monday, August 21, 2006 11:50 PM Subject: I-D ACTION:draft-andersson-rtg-gmpls-change-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Change Process for Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) Protocols and Procedures > Author(s) : L. Andersson, A. Farrel > Filename : draft-andersson-rtg-gmpls-change-03.txt > Pages : 22 > Date : 2006-8-21 > > The issues surrounding the extensibility of IETF protocols have been > widely debated. These issues include when it is reasonable to > extend IETF protocols with little or no review, and when extensions > or variations need to be reviewed by the larger IETF community. > Experience with IETF protocols has shown that extensibility of > protocols without early IETF review can cause problems. > > The Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > suites of protocols have become popular for a number of applications > and deployment scenarios. One result of this popularity is a large > number of suggestions for modifications and extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls-change-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-andersson-rtg-gmpls-change-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-andersson-rtg-gmpls-change-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Aug 2006 16:37:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Mon, 21 Aug 2006 09:36:06 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E0227D2F1@xmb-sjc-234.amer.cisco.com> Thread-Topic: Polling for new WG I-Ds Thread-Index: Aca+IFJ3uCg1j+NFSuqbntfhCmZqlAHH3F1g From: "Dean Cheng \(dcheng\)" To: "Adrian Farrel" , DKIM-Signature: a=rsa-sha1; q=dns; l=979; t=1156178168; x=1157042168; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dcheng@cisco.com; z=From:=22Dean=20Cheng=20\(dcheng\)=22=20 |Subject:RE=3A=20Polling=20for=20new=20WG=20I-Ds; X=v=3Dcisco.com=3B=20h=3DaNdOPGR//yUM/3GHL7DzUEDWuxc=3D; b=thE8nNP45YqRrPP3wka459zxIfsIbUVlMd9slOpq/QQsDdBkQnd1QhxLQVt3yEqRk9qtp/OP qSXXqc7pTryIoCIWzGPMTGAIpsMTw/9cm3BeyD2v5OqzOga0NM1bvJfI; Authentication-Results: sj-dkim-4.cisco.com; header.From=dcheng@cisco.com; dkim=pass ( sig from cisco.com verified; ); Yes to all.=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Saturday, August 12, 2006 7:56 AM > To: ccamp@ops.ietf.org > Subject: Polling for new WG I-Ds >=20 > Hi, >=20 > As discussed in Montreal, we need to poll for a couple of new=20 > WG drafts. >=20 > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpl s-vcat-lcas-04.txt > has been updated by the authors to provide further details=20 > and clarification. >=20 > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-an d-sc-reqs-02.txt > has been updated since the version discussed in Montreal. >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace ful-shutdown-04.txt > has been updated as Zafar says in his previous email. >=20 >=20 > Please send yes or no for these I-Ds. >=20 > Reasons and opinions are also welcomed. >=20 > Thanks, > Adrian=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Aug 2006 13:39:53 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xGDuj1sIgjd7deeABI3V19NjISB2B0ZvL9YqZBheWqKUvQExHq9zYMh45ProUGK9xdSQbJpwZFZBXxkN8PfAdHtXKZgXjZFGzXnf7sM5jGGlbdtgpxpjca+4TahN5CWxs6GJjfEjIy2TwnK8AD38urlPKFtYuHsHcDrw46BP1NQ= ; Message-ID: <20060821133853.31188.qmail@web36801.mail.mud.yahoo.com> Date: Mon, 21 Aug 2006 06:38:52 -0700 (PDT) From: Igor Bryskin Subject: Re: Polling for new WG I-Ds To: Adrian Farrel Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1570073915-1156167532=:30514" Content-Transfer-Encoding: 8bit --0-1570073915-1156167532=:30514 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Yes to all three. Igor ----- Original Message ----- From: To: "Adrian Farrel" Cc: ; Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds > adrian - see in-line > > Adrian Farrel wrote: > > Hi, > > > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > > > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > > > has been updated by the authors to provide further details and > > clarification. > > - ok - > > > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > > - guess it is v03.txt ? - > > > has been updated since the version discussed in Montreal. > > i am ok in investigating the MP->CP but i have two concerns that imho > should deserve more specific attention to maintain consistency wrt to > CP->MP > > section 2.2: if control is lost for an LSP (during CP failure) how can it > be possible transfer that LSP from the CP -> MP ? [dan] Yes, there is a problem if we still want to use the control plane to do the CP->MP transfer. Unless the transfer is based on the predetermined policy, MP takes the control of the LSP resource directly (no signaling required), but this way should not be discussed in CCAMP. > > section 4.4: why the document assumes that both MUST be supported ? in > part. concerning the CP->MP if one does implement current GMPLS signaling > restart/recovery why shall this be mandated ? in brief, the document shall > take into account existing mechanisms and prevent overlaps (with existing > GMPLS mechanisms) > [dan] I think the CP->MP should not be the mandatory requirement. > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. > > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > > > has been updated as Zafar says in his previous email. > > informational imho - in its current version > > - not sure to understand why the PathErr/Notify can be processed by the > head-end only (what about segment recovery and stitching case) - why only > MBB is possible upon reception (pls use E2E recovery/Segment recovery > capabilities as you address GMPLS networks) > > - compared to path-reopt, error description is identical for the TE link > case which leads to the following point - if errors code/value are the > same how to distinguish them (assuming that the query procedure described > in path-reopt is used during the setup of that LSP) ? - comment is more > for the path-reopt draft than yours but since there is an overlap ... it > must be addressed in a way or another (note that when fully head-end > driven operations look similar but there is a major difference role of > timing and severity of the error code/value) > > - in case shutdown of a protected component link (of a bundle) is > initiated why can't link protection be used ? > > > Please send yes or no for these I-Ds. > > > > Reasons and opinions are also welcomed. > > > > Thanks, > > Adrian > > --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --0-1570073915-1156167532=:30514 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
 
Yes to all three.
 
Igor
 
 
----- Original Message -----
From:
To: "Adrian Farrel"
Cc: ;
Sent: Thursday, August 17, 2006 6:32 AM
Subject: Re: Polling for new WG I-Ds


> adrian - see in-line
>
> Adrian Farrel wrote:
> > Hi,
> >
> > As discussed in Montreal, we need to poll for a couple of new WG drafts.
> >
> >
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt
>
> > has been updated by the authors to provide further details and
> > clarification.
>
> - ok -
>
> >
> http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt
>
> - guess it is v03.txt ? -
>
> > has been updated since the version discussed in Montreal.
>
> i am ok in investigating the MP->CP but i have two concerns that imho
> should deserve more specific attention to maintain consistency wrt to
> CP->MP
>
> section 2.2: if control is lost for an LSP (during CP failure) how can it
> be possible transfer that LSP from the CP -> MP ?

[dan] Yes, there is a problem if we still want to use the control plane to do the
CP->MP transfer. Unless the transfer is based on the predetermined policy, MP
takes the control of the LSP resource directly (no signaling required), but this way
should not be discussed in CCAMP.

>
> section 4.4: why the document assumes that both MUST be supported ? in
> part. concerning the CP->MP if one does implement current GMPLS signaling
> restart/recovery why shall this be mandated ? in brief, the document shall
> take into account existing mechanisms and prevent overlaps (with existing
> GMPLS mechanisms)
>
[dan] I think the CP->MP should not be the mandatory requirement.

> hence, it is strongly suggested to identify conditions when such CP->MP is
> required (and not an alternative to existing CP mechanisms) b/f
> progressing that part
>
[dan] In order to make the carriers' life easy, when we provide the MP->CP
conversion feature, the reverse procedure (CP->MP) may also is needed just
simply in case the carriers want to withdraw their previous decision, and
they also feel more comfortable with this "undo" function; In order to achieve
this, we should have the working control plane.

> >
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt
>
> > has been updated as Zafar says in his previous email.
>
> informational imho - in its current version
>
> - not sure to understand why the PathErr/Notify can be processed by the
> head-end only (what about segment recovery and stitching case) - why only
> MBB is possible upon reception (pls use E2E recovery/Segment recovery
> capabilities as you address GMPLS networks)
>
> - compared to path-reopt, error description is identical for the TE link
> case which leads to the following point - if errors code/value are the
> same how to distinguish them (assuming that the query procedure described
> in path-reopt is used during the setup of that LSP) ? - comment is more
> for the path-reopt draft than yours but since there is an overlap ... it
> must be addressed in a way or another (note that when fully head-end
> driven operations look similar but there is a major difference role of
> timing and severity of the error code/value)
>
> - in case shutdown of a protected component link (of a bundle) is
> initiated why can't link protection be used ?
>
> > Please send yes or no for these I-Ds.
> >
> > Reasons and opinions are also welcomed.
> >
> > Thanks,
> > Adrian
>
>


Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --0-1570073915-1156167532=:30514-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Aug 2006 12:35:24 +0000 Message-ID: <44E9A84C.6050000@netscape.net> Date: Mon, 21 Aug 2006 08:34:20 -0400 From: Eric W Gray Reply-To: ewgray@GraIyMage.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yes to all three... Adrian Farrel wrote: > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Aug 2006 07:47:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Mon, 21 Aug 2006 09:46:01 +0200 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: Aca+IJcHieTQ4dp1TaSw+8+Ktiy2ZQG1STIw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , Hi, Yes to all Regards, JL=20 > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel > Envoy=E9 : samedi 12 ao=FBt 2006 16:56 > =C0 : ccamp@ops.ietf.org > Objet : Polling for new WG I-Ds >=20 > Hi, >=20 > As discussed in Montreal, we need to poll for a couple of new=20 > WG drafts. >=20 > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpl > s-vcat-lcas-04.txt > has been updated by the authors to provide further details=20 > and clarification. >=20 > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-an > d-sc-reqs-02.txt > has been updated since the version discussed in Montreal. >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace > ful-shutdown-04.txt > has been updated as Zafar says in his previous email. >=20 >=20 > Please send yes or no for these I-Ds. >=20 > Reasons and opinions are also welcomed. >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Aug 2006 04:54:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for new WG I-Ds Date: Mon, 21 Aug 2006 00:54:33 -0400 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: AcbBhBs3k4XBWtGvQXa/gCA1S1uQsADWKUAg From: "Zafar Ali \(zali\)" To: , "Adrian Farrel" Cc: , DKIM-Signature: a=rsa-sha1; q=dns; l=1954; t=1156136076; x=1157000076; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20 |Subject:RE=3A=20Polling=20for=20new=20WG=20I-Ds |To:,=20=22Adrian=20Farrel=22=20; X=v=3Dcisco.com=3B=20h=3DMDv5AzaRucWmaA9nKW9vsoIzl6o=3D; b=n6D3EcQbG3hzEcLJZe500/SdDhkHFoHkqi9SB8mPnk/hoVnr2+2Q4NMm76txvKxWJrJeMH3P YzaN18ZWQBOdSf49fv02DzD/aC7EKWc0gu3MNYMAfFZUtZbt25I6BQ+i; Authentication-Results: rtp-dkim-2.cisco.com; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com verified; ); Hi Dimitri,=20 Please see my reply inline.=20 Thanks for your support for Graceful Shutdown ID.=20 Regards.. Zafar =20 =20 > =20 > >=20 > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace > ful-shutdown-04.txt=20 >=20 > > has been updated as Zafar says in his previous email. >=20 > informational imho - in its current version=20 >=20 > - not sure to understand why the PathErr/Notify can be=20 > processed by the=20 > head-end only (what about segment recovery and stitching=20 > case) - why only=20 > MBB is possible upon reception (pls use E2E recovery/Segment recovery=20 > capabilities as you address GMPLS networks) >=20 This is a good point and we can address these scenarios in the next version of the ID.=20 > - compared to path-reopt, error description is identical for=20 > the TE link=20 > case which leads to the following point - if errors=20 > code/value are the=20 > same how to distinguish them (assuming that the query=20 > procedure described=20 > in path-reopt is used during the setup of that LSP) ? -=20 > comment is more=20 > for the path-reopt draft than yours but since there is an=20 > overlap ...=20 In that case I will let authors of the path-reopt draft to reply/ comment on this point.=20 > it=20 > must be addressed in a way or another (note that when fully head-end=20 > driven operations look similar but there is a major=20 > difference role of=20 > timing and severity of the error code/value)=20 >=20 > - in case shutdown of a protected component link (of a bundle) is=20 > initiated why can't link protection be used ? >=20 I think this also comes under the category of scenario you mentioned above. We can address it and share the ID with you for further comments, before publishing.=20 =20 > > Please send yes or no for these I-Ds. > >=20 > > Reasons and opinions are also welcomed. > >=20 > > Thanks, > > Adrian=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Aug 2006 04:44:09 +0000 Message-ID: <44E93A1F.9070608@kddilabs.jp> Date: Mon, 21 Aug 2006 13:44:15 +0900 From: Tomohiro Otani User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Adrian, I support the third draft to be a WG. Regards, tomo Adrian Farrel wrote: > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Aug 2006 04:40:53 +0000 Message-ID: <44E9392A.2090202@kddilabs.jp> Date: Mon, 21 Aug 2006 13:40:10 +0900 From: Kenji Kumaki User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Yes to all. Thanks, Kenji Adrian Farrel wrote: > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Aug 2006 04:08:44 +0000 Message-ID: <00ac01c6c4d7$42ac7910$4f1fc00a@Unicom.Local> From: "wjq" To: "IETF" Subject: =?gb2312?B?cmWjulBvbGxpbmcgZm9yIG5ldyBXRyBJLURz?= Date: Mon, 21 Aug 2006 12:07:04 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01C6C51A.50C38410" This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C6C51A.50C38410 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpZZXMgdG8gQUxMLg0KDQpSZWdhcmRzDQoNCg0KDQoNClNpbmNlcmVseSBZb3Vycw0KV2FuZyBK aWFucXVhbg0KQXNzb2NpYXRlIFByb2Zlc3Nvcg0KRW5naW5lZXJpbmcgVGVjaG5vbG9neSBEaXZp c2lvbg0KTmV0d29ya3MgQ29uc3RydWN0aW9uIERlcGFydG1lbnQsDQpDaGluYSBVbml0ZWQsVGVs ZWNvbW11bmljYXRpb25zIENvcnBvcmF0aW9uLA0KTm8uMTMzQSxYaWRhbiBOb3J0aCBTdHJlZXQs WGljaGVuZyBEaXN0cmljdCxCZWlqaW5nLCAxMDAwMzIsQ2hpbmENClRlbDogICs4NiAxMCA2NjUw NTczOQ0KTW9iaWxlo7orODYgMTMzMzEwMTY2MDYNCkZheDogICAgKzg2IDEwIDY2NTA1ODQ0DQpF bWFpbDogIHdhbmdqcUBjaGluYXVuaWNvbS5jb20uY24NCg== ------=_NextPart_000_00A9_01C6C51A.50C38410 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI5NjMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBzaXplPTM+WWVzIHRvIA0KQUxMLjxCUj48QlI+ UmVnYXJkczwvRk9OVD48QlI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+U2lu Y2VyZWx5IFlvdXJzPEJSPldhbmcgSmlhbnF1YW48QlI+QXNzb2NpYXRlIA0KUHJvZmVzc29yPEJS PkVuZ2luZWVyaW5nIFRlY2hub2xvZ3kgRGl2aXNpb248QlI+TmV0d29ya3MgQ29uc3RydWN0aW9u IA0KRGVwYXJ0bWVudCw8QlI+Q2hpbmEgVW5pdGVkLFRlbGVjb21tdW5pY2F0aW9ucyBDb3Jwb3Jh dGlvbiw8QlI+Tm8uMTMzQSxYaWRhbiANCk5vcnRoIFN0cmVldCxYaWNoZW5nIERpc3RyaWN0LEJl aWppbmcsIDEwMDAzMixDaGluYTxCUj5UZWw6Jm5ic3A7ICs4NiAxMCANCjY2NTA1NzM5PEJSPk1v YmlsZaO6Kzg2IDEzMzMxMDE2NjA2PEJSPkZheDombmJzcDsmbmJzcDsmbmJzcDsgKzg2IDEwIA0K NjY1MDU4NDQ8QlI+RW1haWw6Jm5ic3A7IDxBIA0KaHJlZj0ibWFpbHRvOndhbmdqcUBjaGluYXVu aWNvbS5jb20uY24iPndhbmdqcUBjaGluYXVuaWNvbS5jb20uY248L0E+PEJSPjwvRk9OVD48L0RJ Vj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_00A9_01C6C51A.50C38410-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Aug 2006 03:22:44 +0000 Message-ID: <1156130512.44e926d060b39@gold.itu.ch> Date: Mon, 21 Aug 2006 05:21:52 +0200 From: ruiquan.jing@ties.itu.int To: ccamp@ops.ietf.org Subject: RE:Polling for new WG I-Ds MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 Yes to ALL. Regards Jing Ruiquan China Telecom BRI ----- Original Message ----- From: "Adrian Farrel" To: Sent: Saturday, August 12, 2006 10:56 PM Subject: Polling for new WG I-Ds > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas- 04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs- 02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown- 04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Aug 2006 02:02:35 +0000 Date: Mon, 21 Aug 2006 10:01:00 +0800 From: Dan Li Subject: Re: Polling for new WG I-Ds To: Dimitri.Papadimitriou@alcatel.be, Adrian Farrel Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Message-id: <004a01c6c4c5$a64fb200$d04c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Dimitri, Please see in line. Regards, Dan ----- Original Message ----- From: To: "Adrian Farrel" Cc: ; Sent: Thursday, August 17, 2006 6:32 AM Subject: Re: Polling for new WG I-Ds > adrian - see in-line > > Adrian Farrel wrote: > > Hi, > > > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > > > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > > > has been updated by the authors to provide further details and > > clarification. > > - ok - > > > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > > - guess it is v03.txt ? - > > > has been updated since the version discussed in Montreal. > > i am ok in investigating the MP->CP but i have two concerns that imho > should deserve more specific attention to maintain consistency wrt to > CP->MP > > section 2.2: if control is lost for an LSP (during CP failure) how can it > be possible transfer that LSP from the CP -> MP ? [dan] Yes, there is a problem if we still want to use the control plane to do the CP->MP transfer. Unless the transfer is based on the predetermined policy, MP takes the control of the LSP resource directly (no signaling required), but this way should not be discussed in CCAMP. > > section 4.4: why the document assumes that both MUST be supported ? in > part. concerning the CP->MP if one does implement current GMPLS signaling > restart/recovery why shall this be mandated ? in brief, the document shall > take into account existing mechanisms and prevent overlaps (with existing > GMPLS mechanisms) > [dan] I think the CP->MP should not be the mandatory requirement. > hence, it is strongly suggested to identify conditions when such CP->MP is > required (and not an alternative to existing CP mechanisms) b/f > progressing that part > [dan] In order to make the carriers' life easy, when we provide the MP->CP conversion feature, the reverse procedure (CP->MP) may also is needed just simply in case the carriers want to withdraw their previous decision, and they also feel more comfortable with this "undo" function; In order to achieve this, we should have the working control plane. > > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > > > has been updated as Zafar says in his previous email. > > informational imho - in its current version > > - not sure to understand why the PathErr/Notify can be processed by the > head-end only (what about segment recovery and stitching case) - why only > MBB is possible upon reception (pls use E2E recovery/Segment recovery > capabilities as you address GMPLS networks) > > - compared to path-reopt, error description is identical for the TE link > case which leads to the following point - if errors code/value are the > same how to distinguish them (assuming that the query procedure described > in path-reopt is used during the setup of that LSP) ? - comment is more > for the path-reopt draft than yours but since there is an overlap ... it > must be addressed in a way or another (note that when fully head-end > driven operations look similar but there is a major difference role of > timing and severity of the error code/value) > > - in case shutdown of a protected component link (of a bundle) is > initiated why can't link protection be used ? > > > Please send yes or no for these I-Ds. > > > > Reasons and opinions are also welcomed. > > > > Thanks, > > Adrian > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Aug 2006 21:50:28 +0000 Message-ID: <44E635E6.4050809@chello.nl> Date: Fri, 18 Aug 2006 23:49:26 +0200 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Trevor Wilson CC: ccamp@ops.ietf.org Subject: Re: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Trevor, You replied: > Thanks for the clarifications, see in-line for responses. OK, I have added my response [hvh2] and sipped the parts where we agree. >> Section 3.2: >> >> Is Fixed synonymous with no-LCAS ? > > [hvh] No, not necessarily, in this case the client signal will > not change its bandwidth. LCAS can be used for resilience. > [tw] Accepted that this is possible. However I still think the reader > could be forgiven for assuming that Fixed = non-LCAS-capable and Dynamic > = LCAS-capable; so perhaps this needs to be clarified in the text. [hvh2] OK that can be done. >> If so, then in the Fixed co-routed scenario, there can be no graceful >> degradation in the event of a failure. > [tw] I have a typo here is should say Fixed diversely-routed instead of > Fixed co-routed > > [hvh] a mis-connection is also a failure > [tw] but a mis-connection won't cause a hit, since this will occur at > set-up, but I agree that if LCAS is present then graceful degradation > can be achieved in the event of a signal degrade. [hvh2] I don't agree, mis-connections can also occur after set-up, e.g. when a crossconnect is wrongly provisioned and changed an existing connection. >> A hitless decrease can >> in certain circumstances, be achieved by using a signal degrade to >> trigger the LCAS remove operation. > > [hvh] how do you provision/achieve a signal degrade? > [tw] G.806 clause 10.1.1.2 shows "P-Xv_AI_TSD = P_AI[1.. XMR]_TSD" > and "P-Xv/P-X-L_A_Sk_MI_TSDEnable" as inputs to the "LCAS-capable > virtual concatenated path adaptation sink function P-Xv/P-X-L_A_Sk", and > the text says "The MI_TSDEnable input controls whether the sink function > uses AI_TSD[i] indications as contributors for signalling defective > members back to the LCAS source function (MI_TSDEnable = true) or > whether it ignores AI_TSD[i] indications altogether (MI_TSDEnable = > false)." [hvh2] this is the enabling of the TSD to be a trigger. What I dis mean is that it is impossible to force a signal degrade (e.g. by introducing bit errors on purpose). Maybe we should only mention that hitless decrease is guaranteed when a member is removed (and LCAS is enabled). >> Dynamic, diversely routed: A dynamic VCAT group, transported over >> at least two diversely routed subsets of member signals. The >> intent here is dynamic resizing and resilience (but differential >> delay may be a limiting factor). Graceful degradation is >> possible in the event of a TSD (Trail Signal Degrade) on a VCG >> member(s) > > [hvh] graceful degradation is a feature of LCAS, it is not necessary > to mention it here explicitly > [tw] It's equally (if not more) relevant to mention it here than in > the fixed scenario. [hvh2] see my previous comment >> The LCAS in-band >> signaling step is taken first to take the component out of the >> group as the result of a remove command from the LCAS controller; the >> permanently removed member will then be in the IDLE state. > > [hvh] mentioning only one of the LCAS states will create confusion > and is irrelevant to GMPLS > [tw] OK so take out the mention of the DNU state (4.1.3.1) and IDLE > (4.1.3.2). In fact perhaps 4.1.3.1 could be combined with 4.1.3.2 as > follows: - > > 4.1.3 Permanent removal of a VCG member > > A VCG member can be permanently removed from the VCG either following a > temporary removal (due to a failure) or as the result of a management > command. > The LCAS in-band signaling step is taken first to take the component out > of the group, either the temporary removal or as the result of a > management command. [hvh2] good suggestion >> This permanent removal procedure is only applicable to >> LCAS-capable-VCAT. > > [hvh] the paragraph replaced by the latter sentence contains more > relevant detail and should be kept intact. > [tw] The introduction to section 4 states that it (section 4) is "in > support of the LCAS procedure". So I don't quite see how the sentence > that I deleted is relevant to LCAS since it deals with the "VCAT only" > interface. [hvh2] you missed the word "and" in quoting, so section 4 describes extentions for diversely routed paths and (extentions) in support of LCAS". So the detail given in the paragraph is relevant for making the distinction between VCAT with and without LCAS. Cheers, and have a nice weekend, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Aug 2006 19:51:57 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-04.txt Message-Id: Date: Fri, 18 Aug 2006 15:50:02 -0400 --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 - Communication of Alarm Information Author(s) : L. Berger Filename : draft-ietf-ccamp-gmpls-alarm-spec-04.txt Pages : 18 Date : 2006-8-18 This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-alarm-spec-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-18132124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-alarm-spec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-18132124.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Aug 2006 18:33:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Updated version of draft-ietf-ccamp-gmpls-rsvp-te-call Date: Thu, 17 Aug 2006 13:32:34 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0C9C7165@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Updated version of draft-ietf-ccamp-gmpls-rsvp-te-call Thread-Index: Aca+IFg/Talj/sjqTfasdTWKvum7QAECZ0BA From: "Brungard, Deborah A, ALABS" To: "Bill Fenner" , "Ross Callon" Cc: , "Adrian Farrel" Bill and Ross, This draft has been through CCAMP WG last call and has been updated to my satisfaction. All changes were in response to LC comments and my nits. http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call- 01.txt Please take it on its next step to being an RFC. Thanks everyone, Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Aug 2006 15:31:38 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re: Polling for new WG I-Ds Date: Thu, 17 Aug 2006 16:30:09 +0100 Message-ID: Thread-Topic: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re: Polling for new WG I-Ds Thread-Index: AcbBXhcjAtAmZXFgT4GJ+bcFEHDjmQAhJz2Q From: "Trevor Wilson" To: "Huub van Helvoort" , Hi Huub, Thanks for the clarifications, see in-line for responses. Trevor Wilson Nortel Networks Belfast Lab Tel: +44 2890 363701 ESN 751 3701 >This is the Way. This is Nortel.=20 > Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl]=20 Sent: 16 August 2006 19:02 To: ccamp@ops.ietf.org Cc: Wilson, Trevor (IRE07:Q840) Subject: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re: Polling for new WG I-Ds Hello Trevor, You wrote: > I have read the ID-draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > I have the following questions and comments: See my comments in-line [hvh] > Section 3.2: >=20 > Is Fixed synonymous with no-LCAS ? [hvh] No, not necessarily, in this case the client signal will not change its bandwidth. LCAS can be used for resilience. [tw] Accepted that this is possible. However I still think the reader could be forgiven for assuming that Fixed =3D non-LCAS-capable and = Dynamic =3D LCAS-capable; so perhaps this needs to be clarified in the text. > If so, then in the Fixed co-routed scenario, there can be no graceful=20 > degradation in the event of a failure. [tw] I have a typo here is should say Fixed diversely-routed instead of Fixed co-routed [hvh] a mis-connection is also a failure [tw] but a mis-connection won't cause a hit, since this will occur at set-up, but I agree that if LCAS is present then graceful degradation can be achieved in the event of a signal degrade. > This is more applicable to the dynamic, diversely-routed scenario (and > in fact could apply to the dynamic co-routed scenario, although this=20 > is far more unlikely). [hvh] see my previous comment > Regarding 'graceful degradation in the event of a failure': surely=20 > this is a misnomer ? Graceful degradation can only be achieved if the=20 > VCG capacity is hitlessly decreased. A full blown failure on any VCG=20 > member will cause a hit to the traffic, albeit temporary. [hvh] agree > A hitless decrease > can in certain circumstances, be achieved by using a signal degrade to > trigger the LCAS remove operation. [hvh] how do you provision/achieve a signal degrade? [tw] G.806 clause 10.1.1.2 shows "P-Xv_AI_TSD =3D P_AI[1.. XMR]_TSD" and "P-Xv/P-X-L_A_Sk_MI_TSDEnable" as inputs to the "LCAS-capable virtual concatenated path adaptation sink function P-Xv/P-X-L_A_Sk", and the text says "The MI_TSDEnable input controls whether the sink function uses AI_TSD[i] indications as contributors for signalling defective members back to the LCAS source function (MI_TSDEnable =3D true) or whether it ignores AI_TSD[i] indications altogether (MI_TSDEnable =3D false)." > Suggested text for 3.2 (partial) >=20 > Fixed, diversely routed: A fixed bandwidth VCG, transported over=20 > at least two diversely routed subsets of member signals. In this=20 > case, the subsets are link-disjoint over at least one link of the=20 > route. The intent here is more efficient use of network=20 > resources >=20 > (no unique route has the required bandwidth), (note=20 > that differential delay may be a limiting factor). [hvh] I don't agree, LCAS can provide resilience, I agree that the degradation is not graceful [tw] We are converging here (as usual); see my previous comment/suggestion > Dynamic, diversely routed: A dynamic VCAT group, transported over=20 > at least two diversely routed subsets of member signals. The=20 > intent here is dynamic resizing and resilience (but differential > delay may be a limiting factor). Graceful degradation is=20 > possible in the event of a TSD (Trail Signal Degrade) on a VCG member(s) [hvh] graceful degradation is a feature of LCAS, it is not necessary to mention it here explicitly [tw] It's equally (if not more) relevant to mention it here than in the fixed scenario. > Section 4 >=20 > Typo on second line of last paragraph: VC4-7v should be VC-4-7v. [hvh] OK > Section 4.1.3 >=20 > G.7042 section 6.4 addresses VCG capacity decrease (temporary removal=20 > due to member failure) and section 6.5 addresses VCG capacity decrease > (permanent removal). Each of these has distinct meanings and I think=20 > that this ID should make that distinction also, or at least be more=20 > pedantic in the use of 'removal'. >=20 > Perhaps (as far as GMPLS is concerned) there is only the need to=20 > address the VCG capacity decrease (permanent removal), since the=20 > 'temporary removal' is an autonomous action performed by the LCAS=20 > protocol and does not require any management intervention. [hvh] the temporary removal description was in previous versions of this draft, because (as you mention) this draft concerns GMPLS it was removed to avoid confusion. [tw] I'm all for avoiding confusion -- see next comment. > Suggested text for 4.1.3: - >=20 > 4.1.3. Decreasing VCG capacity >=20 > VCG capacity can be decreased in two ways > o Temporary removal of a VCG member(s) due to failure > o Planned permanent removal of a VCG member(s) which requires > management intervention >=20 > 4.1.3.1 Temporary Removal of a VCG member >=20 > This is an autonomous action performed by the LCAS protocol whenever a > failure occurs on an active VCG member(s). The relevant VCG member=20 > will then be in the DNU state. >=20 > There is no management intervention required to perform this=20 > operation. >=20 > This member can then be permanently removed from the VCG. (4.1.3.2) >=20 > 4.1.3.2 Planned permanent removal of a VCG member >=20 > The procedure to remove a component signal is similar to that used=20 > to >=20 > add components as described in Section 4.1.2. The LCAS in-band=20 > signaling step is taken first to take the component out of the=20 > group as the result of a remove command from the LCAS controller; the=20 > permanently removed member will then be in the IDLE state. [hvh] mentioning only one of the LCAS states will create confusion and is irrelevant to GMPLS [tw] OK so take out the mention of the DNU state (4.1.3.1) and IDLE (4.1.3.2). In fact perhaps 4.1.3.1 could be combined with 4.1.3.2 as follows: - 4.1.3 Permanent removal of a VCG member A VCG member can be permanently removed from the VCG either following a temporary removal (due to a failure) or as the result of a management command. The LCAS in-band signaling step is taken first to take the component out of the group, either the temporary removal or as the result of a management command. > LCAS signaling is described in [ITU-T-G.7042] >=20 > In this case, the NVC value is decremented by 1 and the timeslot=20 > identifier for the dropped component is removed from the ordered=20 > list >=20 > in the Generalized Label. >=20 > This permanent removal procedure is only applicable to=20 > LCAS-capable-VCAT. [hvh] the paragraph replaced by the latter sentence contains more relevant detail and should be kept intact. [tw] The introduction to section 4 states that it (section 4) is "in support of the LCAS procedure". So I don't quite see how the sentence that I deleted is relevant to LCAS since it deals with the "VCAT only" interface. =09 > Best regards, >=20 > Trevor >=20 > Trevor Wilson > Nortel Networks Kind regards, Huub van Helvoort. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://members.chello.nl/hhelvoort/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Aug 2006 22:34:06 +0000 To: "Adrian Farrel" Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 17 Aug 2006 00:32:35 +0200 Content-Type: text/plain; charset="US-ASCII" adrian - see in-line Adrian Farrel wrote: > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. - ok - > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt - guess it is v03.txt ? - > has been updated since the version discussed in Montreal. i am ok in investigating the MP->CP but i have two concerns that imho should deserve more specific attention to maintain consistency wrt to CP->MP section 2.2: if control is lost for an LSP (during CP failure) how can it be possible transfer that LSP from the CP -> MP ? section 4.4: why the document assumes that both MUST be supported ? in part. concerning the CP->MP if one does implement current GMPLS signaling restart/recovery why shall this be mandated ? in brief, the document shall take into account existing mechanisms and prevent overlaps (with existing GMPLS mechanisms) hence, it is strongly suggested to identify conditions when such CP->MP is required (and not an alternative to existing CP mechanisms) b/f progressing that part > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. informational imho - in its current version - not sure to understand why the PathErr/Notify can be processed by the head-end only (what about segment recovery and stitching case) - why only MBB is possible upon reception (pls use E2E recovery/Segment recovery capabilities as you address GMPLS networks) - compared to path-reopt, error description is identical for the TE link case which leads to the following point - if errors code/value are the same how to distinguish them (assuming that the query procedure described in path-reopt is used during the setup of that LSP) ? - comment is more for the path-reopt draft than yours but since there is an overlap ... it must be addressed in a way or another (note that when fully head-end driven operations look similar but there is a major difference role of timing and severity of the error code/value) - in case shutdown of a protected component link (of a bundle) is initiated why can't link protection be used ? > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Aug 2006 18:03:09 +0000 Message-ID: <44E35D93.8000204@chello.nl> Date: Wed, 16 Aug 2006 20:01:55 +0200 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: Trevor Wilson Subject: comments on ID-draft-bernstein-ccamp-gmpls-vcat-lcas -- was Re: Polling for new WG I-Ds Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Trevor, You wrote: > I have read the ID-draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > I have the following questions and comments: See my comments in-line [hvh] > Section 3.2: > > Is Fixed synonymous with no-LCAS ? [hvh] No, not necessarily, in this case the client signal will not change its bandwidth. LCAS can be used for resilience. > If so, then in the Fixed co-routed scenario, there can be no graceful > degradation in the event of a failure. [hvh] a mis-connection is also a failure > This is more applicable to the dynamic, diversely-routed scenario (and > in fact could apply to the dynamic co-routed scenario, although this is > far more unlikely). [hvh] see my previous comment > Regarding 'graceful degradation in the event of a failure': surely this > is a misnomer ? Graceful degradation can only be achieved if the VCG > capacity is hitlessly decreased. A full blown failure on any VCG member > will cause a hit to the traffic, albeit temporary. [hvh] agree > A hitless decrease > can in certain circumstances, be achieved by using a signal degrade to > trigger the LCAS remove operation. [hvh] how do you provision/achieve a signal degrade? > Suggested text for 3.2 (partial) > > Fixed, diversely routed: A fixed bandwidth VCG, transported over > at least two diversely routed subsets of member signals. In this > case, the subsets are link-disjoint over at least one link of the > route. The intent here is more efficient use of network resources > > (no unique route has the required bandwidth), (note > that differential delay may be a limiting factor). [hvh] I don't agree, LCAS can provide resilience, I agree that the degradation is not graceful > Dynamic, diversely routed: A dynamic VCAT group, transported over > at least two diversely routed subsets of member signals. The > intent here is dynamic resizing and resilience (but differential > delay may be a limiting factor). Graceful degradation is possible > in the event of a TSD (Trail Signal Degrade) on a VCG member(s) [hvh] graceful degradation is a feature of LCAS, it is not necessary to mention it here explicitly > Section 4 > > Typo on second line of last paragraph: VC4-7v should be VC-4-7v. [hvh] OK > Section 4.1.3 > > G.7042 section 6.4 addresses VCG capacity decrease (temporary removal > due to member failure) and section 6.5 addresses VCG capacity decrease > (permanent removal). Each of these has distinct meanings and I think > that this ID should make that distinction also, or at least be more > pedantic in the use of 'removal'. > > Perhaps (as far as GMPLS is concerned) there is only the need to address > the VCG capacity decrease (permanent removal), since the 'temporary > removal' is an autonomous action performed by the LCAS protocol and does > not require any management intervention. [hvh] the temporary removal description was in previous versions of this draft, because (as you mention) this draft concerns GMPLS it was removed to avoid confusion. > Suggested text for 4.1.3: - > > 4.1.3. Decreasing VCG capacity > > VCG capacity can be decreased in two ways > o Temporary removal of a VCG member(s) due to failure > o Planned permanent removal of a VCG member(s) which requires > management intervention > > 4.1.3.1 Temporary Removal of a VCG member > > This is an autonomous action performed by the LCAS protocol whenever a > failure occurs on an active VCG member(s). The relevant VCG member will > then be in the DNU state. > > There is no management intervention required to perform this operation. > > This member can then be permanently removed from the VCG. (4.1.3.2) > > 4.1.3.2 Planned permanent removal of a VCG member > > The procedure to remove a component signal is similar to that used to > > add components as described in Section 4.1.2. The LCAS in-band > signaling step is taken first to take the component out of the group > as the result of a remove command from the LCAS controller; the > permanently removed member will then be in the IDLE state. [hvh] mentioning only one of the LCAS states will create confusion and is irrelevant to GMPLS > LCAS signaling is described in [ITU-T-G.7042] > > In this case, the NVC value is decremented by 1 and the timeslot > identifier for the dropped component is removed from the ordered list > > in the Generalized Label. > > This permanent removal procedure is only applicable to > LCAS-capable-VCAT. [hvh] the paragraph replaced by the latter sentence contains more relevant detail and should be kept intact. > Best regards, > > Trevor > > Trevor Wilson > Nortel Networks Kind regards, Huub van Helvoort. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Aug 2006 15:56:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6C14C.6374150F" Subject: RE: Polling for new WG I-Ds Date: Wed, 16 Aug 2006 16:55:21 +0100 Message-ID: Thread-Topic: Polling for new WG I-Ds Thread-Index: Aca+INzrNHRdUMHKSc6OnlT4eSXuTgDJK7JQ From: "Trevor Wilson" To: "Adrian Farrel" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C14C.6374150F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, I have read the ID-draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt which I have duplicated below in a word document and applied comments and changes (see change bars) for your perusal. I have the following questions and comments (also in the attached): - Section 3.2: Is Fixed synonymous with no-LCAS ? If so, then in the Fixed co-routed scenario, there can be no graceful degradation in the event of a failure. This is more applicable to the dynamic, diversely-routed scenario (and in fact could apply to the dynamic co-routed scenario, although this is far more unlikely). Regarding 'graceful degradation in the event of a failure': surely this is a misnomer ? Graceful degradation can only be achieved if the VCG capacity is hitlessly decreased. A full blown failure on any VCG member will cause a hit to the traffic, albeit temporary. A hitless decrease can in certain circumstances, be achieved by using a signal degrade to trigger the LCAS remove operation. Suggested text for 3.2 (partial) Fixed, diversely routed: A fixed bandwidth VCG, transported over=20 at least two diversely routed subsets of member signals. In this=20 case, the subsets are link-disjoint over at least one link of the=20 route. The intent here is more efficient use of network resources (no unique route has the required bandwidth), (note=20 that differential delay may be a limiting factor). Dynamic, diversely routed: A dynamic VCAT group, transported over=20 at least two diversely routed subsets of member signals. The=20 intent here is dynamic resizing and resilience (but differential=20 delay may be a limiting factor). Graceful degradation is possible in the event of a TSD (Trail Signal Degrade) on a VCG member(s) =20 Section 4 Typo on second line of last paragraph: VC4-7v should be VC-4-7v. Section 4.1.3 G.7042 section 6.4 addresses VCG capacity decrease (temporary removal due to member failure) and section 6.5 addresses VCG capacity decrease (permanent removal). Each of these has distinct meanings and I think that this ID should make that distinction also, or at least be more pedantic in the use of 'removal'. Perhaps (as far as GMPLS is concerned) there is only the need to address the VCG capacity decrease (permanent removal), since the 'temporary removal' is an autonomous action performed by the LCAS protocol and does not require any management intervention. Suggested text for 4.1.3: - 4.1.3. Decreasing VCG capacity=20 VCG capacity can be decreased in two ways o Temporary removal of a VCG member(s) due to failure o Planned permanent removal of a VCG member(s) which requires management intervention 4.1.3.1 Temporary Removal of a VCG member This is an autonomous action performed by the LCAS protocol whenever a failure occurs on an active VCG member(s). The relevant VCG member will then be in the DNU state. There is no management intervention required to perform this operation. This member can then be permanently removed from the VCG. (4.1.3.2) 4.1.3.2 Planned permanent removal of a VCG member The procedure to remove a component signal is similar to that used to add components as described in Section 4.1.2. The LCAS in-band=20 signaling step is taken first to take the component out of the group as the result of a remove command from the LCAS controller; the permanently removed member will then be in the IDLE state. LCAS signaling is described in [ITU-T-G.7042]=20 In this case, the NVC value is decremented by 1 and the timeslot=20 identifier for the dropped component is removed from the ordered list in the Generalized Label. =20 This permanent removal procedure is only applicable to LCAS-capable-VCAT.=20 Best regards, Trevor Trevor Wilson Nortel Networks Belfast Lab Tel: +44 2890 363701 ESN 751 3701 Confidentiality Notice: This message and any attachments may contain information that is privileged and confidential. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender immediately by reply email and destroy all copies of the original message. -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: 12 August 2006 15:56 To: ccamp@ops.ietf.org Subject: Polling for new WG I-Ds Hi, As discussed in Montreal, we need to poll for a couple of new WG drafts. http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lca s-04.txt=20 has been updated by the authors to provide further details and=20 clarification. http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs- 02.txt=20 has been updated since the version discussed in Montreal. http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdo wn-04.txt=20 has been updated as Zafar says in his previous email. Please send yes or no for these I-Ds. Reasons and opinions are also welcomed. Thanks, Adrian=20 ------_=_NextPart_001_01C6C14C.6374150F Content-Type: application/msword; name="ID-draft bernstein.... VCAT-LCAS..TW-comments.doc" Content-Transfer-Encoding: base64 Content-Description: ID-draft bernstein.... VCAT-LCAS..TW-comments.doc Content-Disposition: attachment; filename="ID-draft bernstein.... VCAT-LCAS..TW-comments.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAAwEAAAAAAAAA EAAABgEAAAEAAAD+////AAAAAPwAAAAFAQAABAEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEACUAJBAAA8BK/AAAAAAAAMAAAAAAABgAA2o8AAA4AYmpiarisuKwAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIuwAANrGAADaxgAAi4YAAAAAAAAAAAAAAAAAAE4BAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAH4HAAAAAAAAfgcAAH4H AAAAAAAAfgcAAAAAAACaBwAAJgAAANIHAAAMAAAA3gcAABQAAAAAAAAAAAAAAPIHAAAAAAAA2qwA AAAAAADarAAAAAAAANqsAAAAAAAA2qwAADQAAAAOrQAAPAEAAPIHAAAAAAAAMdQAAKQBAABWrgAA AAAAAFauAAAAAAAAVq4AAAAAAABWrgAAAAAAAFauAAAAAAAAVq4AAAAAAABWrgAAAAAAAFauAAAA AAAAiNMAAAIAAACK0wAAAAAAAIrTAAAAAAAAitMAAAAAAACK0wAAAAAAAIrTAAAAAAAAitMAACQA AADV1QAAUgIAACfYAABwAAAArtMAABUAAAAAAAAAAAAAAAAAAAAAAAAAfgcAABwAAAC8ugAAAAAA AAAAAAAAAAAAAAAAAAAAAABWrgAAAAAAAFauAAAAAAAAvLoAAAAAAAC8ugAAAAAAAK7TAAAAAAAA AAAAAAAAAAB+BwAAAAAAAH4HAAAAAAAAVq4AAAAAAAAAAAAAAAAAAFauAAAAAAAAw9MAADIAAADS yQAAAAAAANLJAAAAAAAA0skAAAAAAAC8ugAASAQAAH4HAAAAAAAAVq4AAAAAAAB+BwAAAAAAAFau AAAAAAAAiNMAAAAAAAAAAAAAAAAAAMLJAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAvLoAAAAAAACI0wAAAAAAAAAAAAAAAAAA0skAAAAAAADSyQAA VgAAABzSAAB8AAAAfgcAAAAAAAB+BwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1NIAAAAAAABWrgAAAAAAAEquAAAMAAAA8Bs+vUvB xgEAAAAAAAAAANqsAAAAAAAABL8AAJAKAACY0gAADAAAAAAAAAAAAAAAiNMAAAAAAAD10wAAPAAA ADHUAAAAAAAApNIAADAAAACX2AAAAAAAAJTJAAAAAAAAl9gAABgAAADU0gAAAAAAAAAAAAAAAAAA 8gcAAAAAAADyBwAAAAAAAH4HAAAAAAAAfgcAAAAAAAB+BwAAAAAAAH4HAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJfYAAAAAAAAAAAAAAAAAADABwAAEgAAANTSAAC0AAAAVq4AABYDAABssQAANAIAALDJ AAASAAAAoLMAAMQBAABktQAAWAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVq4A AAAAAABWrgAAAAAAAFauAAAAAAAArtMAAAAAAACu0wAAAAAAAPIHAAAAAAAA8gcAACRxAAAWeQAA xDMAAAAAAAAAAAAAlMkAABwAAADyBwAAAAAAAPIHAAAAAAAAFnkAAAAAAAACAAEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhpIGFs bCwNDUkgaGF2ZSByZWFkIHRoZSBJRC1kcmFmdC1iZXJuc3RlaW4tY2NhbXAtZ21wbHMtdmNhdC1s Y2FzLTA0LnR4dCB3aGljaCBJIGhhdmUgZHVwbGljYXRlZCBiZWxvdyBhbmQgYXBwbGllZCBjb21t ZW50cyBhbmQgY2hhbmdlcyAoc2VlIGNoYW5nZSBiYXJzKSBmb3IgeW91ciBwZXJ1c2FsLiBJIGhh dmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzOiAtDQ1TZWN0aW9uIDMuMjoN DUlzIEZpeGVkIHN5bm9ueW1vdXMgd2l0aCBuby1MQ0FTID8NDUlmIHNvLCB0aGVuIGluIHRoZSBG aXhlZCBkaXZlcnNsZXktcm91dGVkIHNjZW5hcmlvLCB0aGVyZSBjYW4gYmUgbm8gZ3JhY2VmdWwg ZGVncmFkYXRpb24gaW4gdGhlIGV2ZW50IG9mIGEgZmFpbHVyZS4NDVRoaXMgaXMgbW9yZSBhcHBs aWNhYmxlIHRvIHRoZSBkeW5hbWljLCBkaXZlcnNsZXktcm91dGVkIHNjZW5hcmlvIChhbmQgaW4g ZmFjdCBjb3VsZCBhcHBseSB0byB0aGUgZHluYW1pYyBjby1yb3V0ZWQgc2NlbmFyaW8sIGFsdGhv dWdoIHRoaXMgaXMgZmFyIG1vcmUgdW5saWtlbHkpLg0NUmVnYXJkaW5nIJFncmFjZWZ1bCBkZWdy YWRhdGlvbiBpbiB0aGUgZXZlbnQgb2YgYSBmYWlsdXJlkjogc3VyZWx5IHRoaXMgaXMgYSBtaXMt bm9tZXIgPyBHcmFjZWZ1bCBkZWdyYWRhdGlvbiBjYW4gb25seSBiZSBhY2hpZXZlZCBpZiB0aGUg VkNHIGNhcGFjaXR5IGlzIGhpdGxlc3NseSBkZWNyZWFzZWQuIFRoaXMgaGl0bGVzcyBkZWNyZWFz ZSBjYW4gYmUgYWNoaWV2ZWQgYnkgdXNpbmcgYSBzaWduYWwgZGVncmFkZSB0byB0cmlnZ2VyIHRo ZSBMQ0FTIHJlbW92ZSBvcGVyYXRpb24uIEEgZnVsbCBibG93biBmYWlsdXJlIHdpbGwgY2F1c2Ug YSBoaXQgdG8gdGhlIHRyYWZmaWMuDUkgc3VnZ2VzdCBhbWVuZGluZyB0aGUgdGV4dCBhcyBmb2xs b3dzOiAtDQ1GaXhlZCwgZGl2ZXJzZWx5IHJvdXRlZDogQSBmaXhlZCBiYW5kd2lkdGggVkNHLCB0 cmFuc3BvcnRlZCBvdmVyIA0gICAgICBhdCBsZWFzdCB0d28gZGl2ZXJzZWx5IHJvdXRlZCBzdWJz ZXRzIG9mIG1lbWJlciBzaWduYWxzLiAgSW4gdGhpcyANICAgICAgY2FzZSwgdGhlIHN1YnNldHMg YXJlIGxpbmstZGlzam9pbnQgb3ZlciBhdCBsZWFzdCBvbmUgbGluayBvZiB0aGUgDSAgICAgIHJv dXRlLiAgVGhlIGludGVudCBoZXJlIGlzIG1vcmUgZWZmaWNpZW50IHVzZSBvZiBuZXR3b3JrIHJl c291cmNlcyANICAgICAgKG5vIHVuaXF1ZSByb3V0ZSBoYXMgdGhlIHJlcXVpcmVkIGJhbmR3aWR0 aCksIGFuZCBhZGRpdGlvbmFsIA0gICAgICByZXNpbGllbmNlIGFuZCBncmFjZWZ1bCBkZWdyYWRh dGlvbiBpbiB0aGUgY2FzZSBvZiBmYWlsdXJlIChub3RlIA0gICAgICB0aGF0IGRpZmZlcmVudGlh bCBkZWxheSBtYXkgYmUgYSBsaW1pdGluZyBmYWN0b3IpLg0NRHluYW1pYywgZGl2ZXJzZWx5IHJv dXRlZDogQSBkeW5hbWljIFZDQVQgZ3JvdXAsIHRyYW5zcG9ydGVkIG92ZXIgDSAgICAgIGF0IGxl YXN0IHR3byBkaXZlcnNlbHkgcm91dGVkIHN1YnNldHMgb2YgbWVtYmVyIHNpZ25hbHMuICBUaGUg DSAgICAgIGludGVudCBoZXJlIGlzIGR5bmFtaWMgcmVzaXppbmcgYW5kIHJlc2lsaWVuY2UgKGJ1 dCBkaWZmZXJlbnRpYWwgDSAgICAgIGRlbGF5IG1heSBiZSBhIGxpbWl0aW5nIGZhY3RvcikuIEdy YWNlZnVsIGRlZ3JhZGF0aW9uIGlzIHBvc3NpYmxlIGluIHRoZSBldmVudCBvZiBhIFRTRCAoVHJh aWwgU2lnbmFsIERlZ3JhZGUpIG9uIGEgVkNHIG1lbWJlcihzKQ0NDVNlY3Rpb24gNA0NVHlwbyBv biBzZWNvbmQgbGluZSBvZiBsYXN0IHBhcmFncmFwaDogVkM0LTd2IHNob3VsZCBiZSBWQy00LTd2 Lg0NDVNlY3Rpb24gNC4xLjMNDUcuNzA0MiBzZWN0aW9uIDYuNCBhZGRyZXNzZXMgVkNHIGNhcGFj aXR5IGRlY3JlYXNlICh0ZW1wb3JhcnkgcmVtb3ZhbCBkdWUgdG8gbWVtYmVyIGZhaWx1cmUpIGFu ZCBzZWN0aW9uIDYuNSBhZGRyZXNlcyBWQ0cgY2FwYWNpdHkgZGVjcmVhc2UgKHBlcm1hbmVudCBy ZW1vdmFsKS4gRWFjaCBvZiB0aGVzZSBoYXMgZGlzdGluY3QgbWVhbmluZ3MgYW5kIEkgdGhpbmsg dGhhdCB0aGlzIElEIHNob3VsZCBtYWtlIHRoYXQgZGlzdGluY3Rpb24gYWxzbywgb3IgYXQgbGVh c3QgYmUgbW9yZSBwZWRhbnRpYyBpbiB0aGUgdXNlIG9mIJFyZW1vdmFski4NDVBlcmhhcHMgKGFz IGZhciBhcyBHTVBMUyBpcyBjb25jZXJuZWQpIHRoZXJlIGlzIG9ubHkgdGhlIG5lZWQgdG8gYWRk cmVzcyB0aGUgVkNHIGNhcGFjaXR5IGRlY3JlYXNlIChwZXJtYW5lbnQgcmVtb3ZhbCksIHNpbmNl IHRoZSCRdGVtcG9yYXJ5IHJlbW92YWySIGlzIGFuIGF1dG9ub21vdXMgYWN0aW9uIHBlcmZvcm1l ZCBieSB0aGUgTENBUyBwcm90b2NvbCBhbmQgZG9lcyBub3QgcmVxdWlyZSBhbnkgbWFuYWdlbWVu dCBpbnRlcnZlbnRpb24uDQ1TdWdnZXN0ZWQgdGV4dCBmb3IgNC4xLjM6IC0NDTQuMS4zLiBEZWNy ZWFzaW5nIFZDRyBjYXBhY2l0eSANDVZDRyBjYXBhY2l0eSBjYW4gYmUgZGVjcmVhc2VkIGluIHR3 byB3YXlzDVRlbXBvcmFyeSByZW1vdmFsIG9mIGEgVkNHIG1lbWJlcihzKSBkdWUgdG8gZmFpbHVy ZQ1QbGFubmVkIHBlcm1hbmFuZW10IHJlbW92YWwgb2YgYSBWQ0cgbWVtYmVyKHMpIHdoaWNoIHJl cXVpcmVzICBtYW5hZ2VtZW50IGludGVydmVudGlvbg0NVGVtcG9yYXJ5IFJlbW92YWwgb2YgYSBW Q0cgbWVtYmVyDQ1UaGlzIGlzIGFuIGF1dG9ub21vdXMgYWN0aW9uIHBlcmZvcm1lZCBieSB0aGUg TENBUyBwcm90b2NvbCB3aGVuZXZlciBhIGZhaWx1cmUgb2NjdXJzIG9uIGFuIGFjdGl2ZSBWQ0cg bWVtYmVyKHMpLiBUaGUgcmVsZXZhbnQgVkNHIG1lbWJlciB3aWxsIHRoZW4gYmUgaW4gdGhlIERO VSBzdGF0ZS4NDVRoZXJlIGlzIG5vIG1hbmFnZW1lbnQgaW50ZXJ2ZW50aW9uIHJlcXVpcmVkIHRv IHBlcmZvcm0gdGhpcyBvcGVyYXRpb24uDQ1UaGlzIG1lbWJlciBjYW4gdGhlbiBiZSBwZXJtYW5l bnRseSByZW1vdmVkIGZyb20gdGhlIFZDRy4gKDQuMS4zLjIpDQ00LjEuMy4yCQlQbGFubmVkIHBl cm1hbmVudCByZW1vdmFsIG9mIGEgVkNHIG1lbWJlcg0NICAgVGhlIHByb2NlZHVyZSB0byByZW1v dmUgYSBjb21wb25lbnQgc2lnbmFsIGlzIHNpbWlsYXIgdG8gdGhhdCB1c2VkIHRvIA0gICBhZGQg Y29tcG9uZW50cyBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuMi4gIFRoZSBMQ0FTIGluLWJh bmQgDSAgIHNpZ25hbGluZyBzdGVwIGlzIHRha2VuIGZpcnN0IHRvIHRha2UgdGhlIGNvbXBvbmVu dCBvdXQgb2YgdGhlIGdyb3VwIGFzIHRoZSByZXN1bHQgb2YgYSByZW1vdmUgY29tbWFuZCBmcm9t IHRoZSBMQ0FTIGNvbnRyb2xsZXI7IHRoZSBwZXJtYW5lbnRseSByZW1vdmVkIG1lbWJlciB3aWxs IHRoZW4gYmUgaW4gdGhlIElETEUgc3RhdGUuDSAgIExDQVMgc2lnbmFsaW5nIGlzIGRlc2NyaWJl ZCBpbiBbSVRVLVQtRy43MDQyXSANDSAgIEluIHRoaXMgY2FzZSwgdGhlIE5WQyB2YWx1ZSBpcyBk ZWNyZW1lbnRlZCBieSAxIGFuZCB0aGUgdGltZXNsb3QgDSAgIGlkZW50aWZpZXIgZm9yIHRoZSBk cm9wcGVkIGNvbXBvbmVudCBpcyByZW1vdmVkIGZyb20gdGhlIG9yZGVyZWQgbGlzdCANICAgaW4g dGhlIEdlbmVyYWxpemVkIExhYmVsLiAgDQ1UaGlzIHBlcm1hbmVudCByZW1vdmFsIHByb2NlZHVy ZSBpcyBvbmx5IGFwcGxpY2FibGUgdG8gTENBUy1jYXBhYmxlLVZDQVQuIA0NDQ0NDENDQU1QIFdv cmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRy4gQmVy bnN0ZWluIA1JbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBHcm90dG8gTmV0d29ya2luZyANVXBkYXRlczogUkZDIDM5NDYgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gQ2F2aWdsaWEgDUNhdGVnb3J5OiBTdGFuZGFy ZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uIA1F eHBpcmVzOiBGZWJydWFyeSAyMDA3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIu IFJhYmJhdCAoZWQuKSANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZ1aml0c3UgDSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEguIHZhbiBIZWx2b29ydCANICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SHVhd2VpIA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBdWd1c3QgNCwgMjAwNiANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDSANICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANICAgICAgIE9wZXJh dGluZyBWaXJ0dWFsIENvbmNhdGVuYXRpb24gKFZDQVQpIGFuZCB0aGUgTGluayBDYXBhY2l0eSAN ICAgICAgQWRqdXN0bWVudCBTY2hlbWUgKExDQVMpIHdpdGggR2VuZXJhbGl6ZWQgTXVsdGktUHJv dG9jb2wgTGFiZWwgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3dpdGNoaW5nIChHTVBM UykgDSAgICAgICAgICAgICAgIGRyYWZ0LWJlcm5zdGVpbi1jY2FtcC1nbXBscy12Y2F0LWxjYXMt MDQudHh0IA0NDVN0YXR1cyBvZiB0aGlzIE1lbW8gDQ0gICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50 ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCAgICAgICANICAgYW55IGFw cGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlz ICAgICAgIA0gICBhd2FyZSBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkg b2Ygd2hpY2ggaGUgb3Igc2hlICAgICAgIA0gICBiZWNvbWVzIGF3YXJlIHdpbGwgYmUgZGlzY2xv c2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mICAgICAgIA0gICBCQ1AgNzkuICAN DSAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nIA0gICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdv cmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IA0gICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NICAgRHJhZnRzLiANDSAgIEludGVy bmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocyANICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgDSAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIA0gICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iIA0NICAgVGhlIGxpc3Qgb2Yg Y3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0gICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCANDSAgIFRoZSBsaXN0IG9mIElu dGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQgDSAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCANDSAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgd2lsbCBleHBpcmUgb24gRmVicnVhcnkgNCwgMjAwNy4gDQ0gICAgIA0NQWJzdHJhY3QgDQ0g ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyByZXF1aXJlbWVudHMgZm9yLCBhbmQgdXNlIG9mLCB0 aGUgR2VuZXJhbGl6ZWQgDSAgIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMp IGNvbnRyb2wgcGxhbmUgaW4gY29uanVuY3Rpb24gDSANIA0gDUJlcm5zdGVpbiAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSA0LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDFdIA0MDUlu dGVybmV0LURyYWZ0ICAgIE9wZXJhdGluZyBWQ0FUIGFuZCBMQ0FTIHdpdGggR01QTFMgICAgICAg IEF1Z3VzdCAyMDA2IA0gICAgDQ0gICB3aXRoIHRoZSBWaXJ0dWFsIENvbmNhdGVuYXRpb24gKFZD QVQpIGxheWVyIDEgaW52ZXJzZSBtdWx0aXBsZXhpbmcgDSAgIG1lY2hhbmlzbSBhbmQgaXRzIGNv bXBhbmlvbiBMaW5rIENhcGFjaXR5IEFkanVzdG1lbnQgU2NoZW1lIChMQ0FTKSANICAgd2hpY2gg Y2FuIGJlIHVzZWQgZm9yIGhpdGxlc3MgZHluYW1pYyByZXNpemluZyBvZiB0aGUgaW52ZXJzZSAN ICAgbXVsdGlwbGV4IGdyb3VwLiAgVGhlc2UgdGVjaG5pcXVlcyBhcHBseSB0byB0aGUgT3B0aWNh bCBUcmFuc3BvcnQgDSAgIE5ldHdvcmsgKE9UTiksIFN5bmNocm9ub3VzIE9wdGljYWwgTmV0d29y ayAoU09ORVQpLCBTeW5jaHJvbm91cyANICAgRGlnaXRhbCBIaWVyYXJjaHkgKFNESCksIGFuZCBQ bGVzaW9jaHJvbm91cyBEaWdpdGFsIEhpZXJhcmNoeSAoUERIKSANICAgc2lnbmFscy4gDQ1Db252 ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgDQ0gICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsIA0gICAiU0hPVUxE IiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4g dGhpcyANICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBS RkMtMjExOSBbUkZDMjExOV0uIA0NVGFibGUgb2YgQ29udGVudHMgDQ0gICAgDSAgIDEuIEludHJv ZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjMgDSAgIDIuIENoYW5nZXMgZnJvbSBkcmFmdC1iZXJuc3RlaW4tY2NhbXAtZ21wbHMtdmNhdC1s Y2FzLTAzLi4uLi4uLi4uLjMgDSAgIDMuIFZDQVQvTENBUyBTY2VuYXJpb3MgYW5kIFNwZWNpZmlj IFJlcXVpcmVtZW50cy4uLi4uLi4uLi4uLi4uLi4uLjMgDSAgICAgIDMuMS4gTXVsdGlwbGUgVkNB VCBHcm91cHMgcGVyIEdNUExTIEVuZHBvaW50Li4uLi4uLi4uLi4uLi4uLi4uLjMgDSAgICAgIDMu Mi4gQ29tcG9uZW50IFNpZ25hbCBDb25maWd1cmF0aW9uIFJlcXVpcmVtZW50cy4uLi4uLi4uLi4u Li4uLjQgDSAgICAgIDMuMy4gVkNBVCBPcGVyYXRpb24gV2l0aCBvciBXaXRob3V0IExDQVMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjQgDSAgIDQuIEdNUExTIE1lY2hhbmlzbXMgZm9yIFNpZ25hbGlu ZyBWQ0FUL0xDQVMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDSAgICAgIDQuMS4gQ28tUm91dGVk IFNpZ25hbHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDSAgICAg ICAgIDQuMS4xLiBPbmUtc2hvdCBTZXR1cCBvZiBDby1Sb3V0ZWQgU2lnbmFsLi4uLi4uLi4uLi4u Li4uLi4uLjUgDSAgICAgICAgIDQuMS4yLiBJbmNyZW1lbnRhbCBTZXR1cCBvZiBDby1Sb3V0ZWQg U2lnbmFsLi4uLi4uLi4uLi4uLi4uLjUgDSAgICAgICAgIDQuMS4zLiBSZW1vdmluZyBhIENvbXBv bmVudCBTaWduYWwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDSAgICAgICAgIDQuMS40LiBS ZW1vdmluZyBNdWx0aXBsZSBDb21wb25lbnQgU2lnbmFscyBpbiBPbmUgU2hvdC4uLi4uLjYgDSAg ICAgICAgIDQuMS41LiBVc2Ugb2YgbXVsdGlwbGUgTFNQcyBmb3IgQ28tUm91dGVkIFNpZ25hbHMu Li4uLi4uLi4uLjcgDSAgICAgICAgIDQuMS42LiBUZWFyZG93biBvZiBXaG9sZSBWQ0cuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDSAgICAgIDQuMi4gRGl2ZXJzZWx5IFJvdXRlZCBT aWduYWxzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDSAgICAgICAgIDQuMi4x LiBBc3NvY2lhdGluZyBEaXZlcnNlbHkgUm91dGVkIFNpZ25hbHMuLi4uLi4uLi4uLi4uLi4uLjcg DSAgICAgICAgIDQuMi4yLiBQcm9jZWR1cmVzIGZvciBWQ0cgU2V0dXAgVXNpbmcgRGl2ZXJzZWx5 IFJvdXRlZCANICAgICAgICAgQ29tcG9uZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uOCANICAgICAgICAgNC4yLjMuIFByb2NlZHVyZXMgZm9yIFZD RyBSZWR1Y3Rpb24vVGVhcmRvd24gVXNpbmcgRGl2ZXJzZWx5IA0gICAgICAgICBSb3V0ZWQgQ29t cG9uZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0gICAg ICAgICA0LjIuNC4gVXBkYXRlIG9mIEFscmVhZHkgRXN0YWJsaXNoZWQgTFNQcy4uLi4uLi4uLi4u Li4uLi4uLi45IA0gICAgICAgICA0LjIuNS4gT25lIExTUCBwZXIgQ2lyY3VpdC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0gICA1LiBJQU5BIENvbnNpZGVyYXRpb25zLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0gICA2LiBTZWN1cml0eSBD b25zaWRlcmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0g ICA3LiBDb250cmlidXRvcnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjExIA0gICA4LiBBY2tub3dsZWRnbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjExIA0gICA5LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEyIA0gICAgICA5LjEuIE5v cm1hdGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEy IA0gICAgICA5LjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjEyIA0gICBBdXRob3IncyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEzIA0gDSANQmVybnN0ZWluICAgICAgICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDQsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQwNSW50 ZXJuZXQtRHJhZnQgICAgT3BlcmF0aW5nIFZDQVQgYW5kIExDQVMgd2l0aCBHTVBMUyAgICAgICAg QXVndXN0IDIwMDYgDSAgICANDSAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQgDSAgIERpc2NsYWltZXIgb2YgVmFsaWRp dHkuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQgDSAgIENvcHly aWdodCBTdGF0ZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMTQgDSAgIEFja25vd2xlZGdtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTUgDSAgICANMS4gSW50cm9kdWN0aW9uIA0NICAgVGhlIEdlbmVy YWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpIHN1aXRlIG9mIA0g ICBwcm90b2NvbHMgYWxsb3dzIHRoZSBhdXRvbWF0ZWQgY29udHJvbCBvZiBkaWZmZXJlbnQgc3dp dGNoaW5nIA0gICB0ZWNobm9sb2dpZXMgaW5jbHVkaW5nIFNPTkVUL1NESC4gICANDSAgIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGV4dGVuc2lvbnMgdG8gUlNWUC1URSB0byBzdXBwb3J0IHRoZSBW aXJ0dWFsIA0gICBDb25jYXRlbmF0aW9uIChWQ0FUKSBsYXllciAxIGludmVyc2UgbXVsdGlwbGV4 aW5nIG1lY2hhbmlzbSBhbmQgaXRzIA0gICBjb21wYW5pb24gTGluayBDYXBhY2l0eSBBZGp1c3Rt ZW50IFNjaGVtZSAoTENBUykuICBUaGVzZSBleHRlbnNpb25zIA0gICBlbmFibGUgdGhlIHNldHVw IG9mIGRpdmVyc2VseSByb3V0ZWQgY2lyY3VpdHMgdGhhdCBhcmUgbWVtYmVycyBvZiB0aGUgDSAg IHNhbWUgVkNBVCBncm91cC4gDQ0yLiBDaGFuZ2VzIGZyb20gZHJhZnQtYmVybnN0ZWluLWNjYW1w LWdtcGxzLXZjYXQtbGNhcy0wMyANDSAgIG8gIERyb3BwZWQgYXBwZW5kaWNlcyANDSAgIG8gIFVw ZGF0ZWQgcmVmZXJlbmNlcyANDSAgIG8gIEZpeGVkIGVycm9yIHcvciB0byBzZXNzaW9ucy4gVGhl IExTUHMgYmVsb25nIHRvIGRpZmZlcmVudCBzZXNzaW9ucyANDSAgIG8gIE1hbnkgZWRpdG9yaWFs IGNoYW5nZXMgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgDQ0gICBvICBSZXdyb3RlIHRoZSBpbnRy b2R1Y3Rpb24gDQ0zLiBWQ0FUL0xDQVMgU2NlbmFyaW9zIGFuZCBTcGVjaWZpYyBSZXF1aXJlbWVu dHMgDQ0gICBUaGVyZSBhcmUgYSBudW1iZXIgb2Ygc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGZvciB0 aGUgc3VwcG9ydCBvZiANICAgVkNBVC9MQ0FTIGluIEdNUExTIHRoYXQgY2FuIGJlIGRlcml2ZWQg ZnJvbSB0aGUgY2FycmllcnMnIA0gICBhcHBsaWNhdGlvbi1zcGVjaWZpYyBkZW1hbmRzIGZvciB0 aGUgdXNlIG9mIFZDQVQvTENBUyBhbmQgZnJvbSB0aGUgDSAgIGZsZXhpYmxlIG5hdHVyZSBvZiBW Q0FUL0xDQVMuICBUaGVzZSBhcmUgc2V0IG91dCBpbiB0aGUgZm9sbG93aW5nIA0gICBzZWN0aW9u LiANDTMuMS4gTXVsdGlwbGUgVkNBVCBHcm91cHMgcGVyIEdNUExTIEVuZHBvaW50ICANDSAgIElu IGdlbmVyYWwsIGFuIExTUiBjYW4gYmUgaW5ncmVzcy9lZ3Jlc3Mgb2Ygb25lIG9yIG1vcmUgVkNB VCBncm91cHMuICANICAgVkNBVCBhbmQgTENBUyBhcmUgaW50ZXJmYWNlIGNhcGFiaWxpdGllcy4g IEFuIExTUiBtYXkgaGF2ZSwgZm9yIA0gICBleGFtcGxlLCBWQ0FULWNhcGFibGUgaW50ZXJmYWNl cyB0aGF0IGFyZSBub3QgTENBUy1jYXBhYmxlLiAgSXQgbWF5IA0gICBhdCB0aGUgc2FtZSB0aW1l IGhhdmUgaW50ZXJmYWNlcyB0aGF0IGFyZSBuZWl0aGVyIFZDQVQgbm9yIExDQVMtDSAgIGNhcGFi bGUuIA0NDQ0gDSANQmVybnN0ZWluICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDQsIDIw MDcgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQwNSW50ZXJuZXQtRHJhZnQgICAgT3BlcmF0aW5n IFZDQVQgYW5kIExDQVMgd2l0aCBHTVBMUyAgICAgICAgQXVndXN0IDIwMDYgDSAgICANDTMuMi4g Q29tcG9uZW50IFNpZ25hbCBDb25maWd1cmF0aW9uIFJlcXVpcmVtZW50cyANDSAgIFdlIGxpc3Qg aW4gdGhpcyBzZWN0aW9uIHRoZSBkaWZmZXJlbnQgc2NlbmFyaW9zIHRoYXQgU0hPVUxEIGJlIA0g ICBzdXBwb3J0ZWQuICBIZXJlIHdlIHVzZSB0aGUgdGVybSAiVkNHIiB0byByZWZlciB0byB0aGUg ZW50aXJlIFZDQVQgDSAgIGdyb3VwIGFuZCB0aGUgdGVybWlub2xvZ3kgInNldCIgYW5kICJzdWJz ZXQiIHRvIHJlZmVyIHRvIHRoZSANICAgY29sbGVjdGlvbiBvZiBwb3RlbnRpYWwgVkNBVCBncm91 cCBtZW1iZXIgc2lnbmFscy4gDQ0gICBvICBGaXhlZCwgY28tcm91dGVkOiBBIGZpeGVkIGJhbmR3 aWR0aCBWQ0csIHRyYW5zcG9ydGVkIG92ZXIgYSBjby0NICAgICAgcm91dGVkIHNldCBvZiBtZW1i ZXIgc2lnbmFscy4gIFRoaXMgaXMgdGhlIGNhc2Ugd2hlcmUgdGhlIGludGVuZGVkIA0gICAgICBi YW5kd2lkdGggb2YgdGhlIFZDRyBkb2VzIG5vdCBjaGFuZ2UgYW5kIGFsbCBtZW1iZXIgc2lnbmFs cyBmb2xsb3cgDSAgICAgIHRoZSBzYW1lIHJvdXRlIGFuZCBtaW5pbWl6ZSBkaWZmZXJlbnRpYWwg ZGVsYXkuICBUaGUgaW50ZW50IGhlcmUgDSAgICAgIGlzIHRoZSBjYXBhYmlsaXR5IHRvIGFsbG9j YXRlIGFuIGFtb3VudCBvZiBiYW5kd2lkdGggY2xvc2UgdG8gdGhhdCANICAgICAgcmVxdWlyZWQg YXQgdGhlIGNsaWVudCBsYXllci4gDQ0gICBvICBGaXhlZCwgZGl2ZXJzZWx5IHJvdXRlZDogQSBm aXhlZCBiYW5kd2lkdGggVkNHLCB0cmFuc3BvcnRlZCBvdmVyIA0gICAgICBhdCBsZWFzdCB0d28g ZGl2ZXJzZWx5IHJvdXRlZCBzdWJzZXRzIG9mIG1lbWJlciBzaWduYWxzLiAgSW4gdGhpcyANICAg ICAgY2FzZSwgdGhlIHN1YnNldHMgYXJlIGxpbmstZGlzam9pbnQgb3ZlciBhdCBsZWFzdCBvbmUg bGluayBvZiB0aGUgDSAgICAgIHJvdXRlLiAgVGhlIGludGVudCBoZXJlIGlzIG1vcmUgZWZmaWNp ZW50IHVzZSBvZiBuZXR3b3JrIHJlc291cmNlcyANICAgICAgKG5vIHVuaXF1ZSByb3V0ZSBoYXMg dGhlIHJlcXVpcmVkIGJhbmR3aWR0aCksIGFuZCBhZGRpdGlvbmFsIA0gICAgICByZXNpbGllbmNl IGFuZCBncmFjZWZ1bCBkZWdyYWRhdGlvbiBpbiB0aGUgY2FzZSBvZiBmYWlsdXJlIChub3RlIA0g ICAgICB0aGF0IGRpZmZlcmVudGlhbCBkZWxheSBtYXkgYmUgYSBsaW1pdGluZyBmYWN0b3IpLiAF DQ0gICBvICBEeW5hbWljLCBjby1yb3V0ZWQ6IEEgZHluYW1pYyBWQ0cgKGJhbmR3aWR0aCBjYW4g YmUgaW5jcmVhc2VkIG9yIA0gICAgICBkZWNyZWFzZWQgdmlhIHRoZSBhZGRpdGlvbiBvciByZW1v dmFsIG9mIG1lbWJlciBzaWduYWxzKSwgDSAgICAgIHRyYW5zcG9ydGVkIG92ZXIgYSBjby1yb3V0 ZWQgc2V0IG9mIG1lbWJlcnMuICBJbnRlbnQgaGVyZSBpcyANICAgICAgZHluYW1pYyBzaXppbmcg b2YgYmFuZHdpZHRoLiANDSAgIG8gIER5bmFtaWMsIGRpdmVyc2VseSByb3V0ZWQ6IEEgZHluYW1p YyBWQ0FUIGdyb3VwLCB0cmFuc3BvcnRlZCBvdmVyIA0gICAgICBhdCBsZWFzdCB0d28gZGl2ZXJz ZWx5IHJvdXRlZCBzdWJzZXRzIG9mIG1lbWJlciBzaWduYWxzLiAgVGhlIA0gICAgICBpbnRlbnQg aGVyZSBpcyBkeW5hbWljIHJlc2l6aW5nIGFuZCByZXNpbGllbmNlIChidXQgZGlmZmVyZW50aWFs IA0gICAgICBkZWxheSBtYXkgYmUgYSBsaW1pdGluZyBmYWN0b3IpLiBHcmFjZWZ1bCBkZWdyYWRh dGlvbiBpcyBwb3NzaWJsZSBpbiB0aGUgZXZlbnQgb2YgYSBUU0QgKFRyYWlsIFNpZ25hbCBEZWdy YWRlKSBvbiBhIFZDRyBtZW1iZXIocykNDTMuMy4gVkNBVCBPcGVyYXRpb24gV2l0aCBvciBXaXRo b3V0IExDQVMgDQ0gICBWQ0FUIGNhcGFiaWxpdGllcyBtYXkgYmUgcHJlc2VudCB3aXRoIG9yIHdp dGhvdXQgdGhlIHByZXNlbmNlIG9mIA0gICBMQ0FTLiAgVGhlIHVzZSBvZiBMQ0FTIGlzIGJlbmVm aWNpYWwgdG8gdGhlIHByb3Zpc2lvbiBvZiBzZXJ2aWNlcywgDSAgIGJ1dCBpbiB0aGUgYWJzZW5j ZSBvZiBMQ0FTLCBWQ0FUIGlzIHN0aWxsIGEgdmFsaWQgdGVjaG5pcXVlLiAgDSAgIFRoZXJlZm9y ZSBHTVBMUyBtZWNoYW5pc21zIGZvciB0aGUgb3BlcmF0aW9uIG9mIFZDQVQgYXJlIFJFUVVJUkVE IGZvciANICAgYm90aCB0aGUgY2FzZSB3aGVyZSBMQ0FTIGlzIGF2YWlsYWJsZSBhbmQgdGhlIGNh c2Ugd2hlcmUgaXQgaXMgbm90IA0gICBhdmFpbGFibGUuICBUaGUgR01QTFMgcHJvY2VkdXJlcyBm b3IgdGhlIHR3byBjYXNlcyBTSE9VTEQgYmUgDSAgIGlkZW50aWNhbC4gDQ00LiBHTVBMUyBNZWNo YW5pc21zIGZvciBTaWduYWxpbmcgVkNBVC9MQ0FTIA0NICAgV2UgZGVzY3JpYmUgaW4gdGhpcyBz ZWN0aW9uIHRoZSBzaWduYWxpbmcgbWVjaGFuaXNtcyB0aGF0IGFscmVhZHkgDSAgIGV4aXN0IGlu IEdNUExTIHVzaW5nIFJTVlAtVEUgW1JGQzM0NzNdIGFuZCB0aGUgZXh0ZW5zaW9ucyBuZWVkZWQs IGZvciANICAgZGl2ZXJzZWx5IHJvdXRlZCBwYXRocyBhbmQgaW4gc3VwcG9ydCBvZiB0aGUgTENB UyBwcm9jZWR1cmUuIA0gDSANQmVybnN0ZWluICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDQsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQwNSW50ZXJuZXQtRHJhZnQgICAgT3Bl cmF0aW5nIFZDQVQgYW5kIExDQVMgd2l0aCBHTVBMUyAgICAgICAgQXVndXN0IDIwMDYgDSAgICAN DSAgIFNlY3Rpb24gNC4xIGlzIGluY2x1ZGVkIGZvciBpbmZvcm1hdGlvbmFsIHB1cnBvc2VzIG9u bHkuICBJdCANICAgZGVzY3JpYmVzIGV4aXN0aW5nIHByb2NlZHVyZXMgYW5kIG1ha2VzIG5vIGNo YW5nZXMuIA0NICAgU2VjdGlvbiA0LjIgZGVzY3JpYmVzIG5ldyBwcm9jZWR1cmVzIHRvIHN1cHBv cnQgZGl2ZXJzZWx5IHJvdXRlZCBWQ0FUIA0gICBncm91cHMuICBXaGVyZSBwb3NzaWJsZSBpdCBy ZXVzZXMgYXBwbGljYWJsZSBleGlzdGluZyBwcm9jZWR1cmVzIGZyb20gDSAgIHNlY3Rpb24gNC4x LiAgDQ00LjEuIENvLVJvdXRlZCBTaWduYWxzIA0NICAgTm90ZSB0aGF0IHRoaXMgc2VjdGlvbiBp cyBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LiANDSAgIFRoZSBleGlzdGluZyBzaWdu YWxpbmcgcHJvdG9jb2xzIHN1cHBvcnQgY28tcm91dGVkIHNpZ25hbCBzZXR1cCB1c2luZyANICAg dGhlIE5WQyBmaWVsZCBhcyBleHBsYWluZWQgaW4gc2VjdGlvbiAyLjEgb2YgW1JGQzM5NDZiaXNd LiAgSW4gdGhpcyANICAgY2FzZSwgb25lIHNpbmdsZSBMU1AgaXMgc2V0IHVwIGluIHN1cHBvcnQg b2YgdGhlIFZDQVQgZ3JvdXAuIA0NICAgVGhlcmUgYXJlIHR3byBvcHRpb25zIGZvciBzZXR0aW5n IHVwIHRoZSBWQ0FUIGdyb3VwLCBkZXBlbmRpbmcgb24gDSAgIGhhcmR3YXJlIGNhcGFiaWxpdHks IG9yIG1hbmFnZW1lbnQgcHJlZmVyZW5jZXM6IG9uZS1zaG90IHNldHVwIGFuZCANICAgaW5jcmVt ZW50YWwgc2V0dXAuIA0NICAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyBleHBsYWluIHRoZSBwcm9j ZWR1cmUgYmFzZWQgb24gYW4gZXhhbXBsZSBvZiANICAgc2V0dGluZyB1cCBhIFZDLTQtN3YgU0RI IFZDQVQgZ3JvdXAgKGNvcnJlc3BvbmRpbmcgdG8gYW4gU1RTLTNjLTd2IA0gICBTT05FVCBWQ0FU IGdyb3VwKS4gDQ00LjEuMS4gT25lLXNob3QgU2V0dXAgb2YgQ28tUm91dGVkIFNpZ25hbCANDSAg IEFuIFJTVlAtVEUgUGF0aCBtZXNzYWdlIGlzIHVzZWQgd2l0aCB0aGUgZm9sbG93aW5nIHBhcmFt ZXRlcnMuIA0NICAgV2l0aCByZWdhcmRzIHRvIHRoZSB0cmFmZmljIHBhcmFtZXRlcnMsIHRoZSBl bGVtZW50YXJ5IHNpZ25hbCBpcyANICAgY2hvc2VuICg2IGZvciBWQy00L1NUUy0zY19TUEUpLiAg VGhlIHZhbHVlIG9mIE5WQyBpcyB0aGVuIHNldCB0byA3LiANDSAgIEEgTXVsdGlwbGllciBUcmFu c2Zvcm0gZ3JlYXRlciB0aGFuIDEgKHNheSBOPjEpIGlzIHVzZWQgaWYgdGhlIA0gICBvcGVyYXRv ciB3YW50cyB0byBzZXQgdXAgTiBWQ0FUIGdyb3VwcyB0aGF0IHdpbGwgYmVsb25nIHRvLCBhbmQg YmUgDSAgIGFzc2lnbmVkIHRvLCBvbmUgTFNQLiANDSAgIFNESCBvciBTT05FVCBsYWJlbHMgaW4g dHVybiBoYXZlIHRvIGJlIGFzc2lnbmVkIGZvciBlYWNoIG1lbWJlciBvZiANICAgdGhlIFZDRyBh bmQgY29uY2F0ZW5hdGVkIHRvIGZvcm0gYSBzaW5nbGUgR2VuZXJhbGl6ZWQgTGFiZWwgDSAgIGNv bnN0cnVjdGVkIGFzIGFuIG9yZGVyZWQgbGlzdCBvZiAzMi1iaXQgdGltZXNsb3QgaWRlbnRpZmll cnMgb2YgdGhlIA0gICBzYW1lIGZvcm1hdCBhcyBURE0gbGFiZWxzLiAgW1JGQzM5NDZiaXNdIHJl cXVpcmVzIHRoYXQgdGhlIG9yZGVyIG9mIA0gICB0aGUgbGFiZWxzIHJlZmxlY3QgdGhlIG9yZGVy IG9mIHRoZSBwYXlsb2FkcyB0byBjb25jYXRlbmF0ZSwgYW5kIG5vdCANICAgdGhlIHBoeXNpY2Fs IG9yZGVyIG9mIHRpbWUtc2xvdHMuIA0NNC4xLjIuIEluY3JlbWVudGFsIFNldHVwIG9mIENvLVJv dXRlZCBTaWduYWwgDQ0gICBJbiBzb21lIGNhc2VzLCBpdCBtYXkgYmUgbmVjZXNzYXJ5IG9yIGRl c2lyYWJsZSB0byBzZXQgdXAgdGhlIFZDRyANICAgbWVtYmVycyBpbmRpdmlkdWFsbHksIG9yIHRv IGFkZCBncm91cCBtZW1iZXJzIHRvIGFuIGV4aXN0aW5nIGdyb3VwLiANDQ0gDSANQmVybnN0ZWlu ICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDQsIDIwMDcgICAgICAgICAgICAgICAgW1Bh Z2UgNV0gDQwNSW50ZXJuZXQtRHJhZnQgICAgT3BlcmF0aW5nIFZDQVQgYW5kIExDQVMgd2l0aCBH TVBMUyAgICAgICAgQXVndXN0IDIwMDYgDSAgICANDSAgIE9uZSBleGFtcGxlIG9mIHRoaXMgbmVl ZCBpcyB3aGVuIHRoZSBoYXJkd2FyZSB0aGF0IHN1cHBvcnRzIFZDQVQgY2FuIA0gICBvbmx5IGFk ZCBWQ0FUIGVsZW1lbnRzIG9uZSBhdCBhIHRpbWUgb3IgY2Fubm90IGF1dG9tYXRpY2FsbHkgbWF0 Y2ggDSAgIHRoZSBlbGVtZW50cyBhdCB0aGUgaW5ncmVzcyBhbmQgZWdyZXNzIGZvciB0aGUgcHVy cG9zZXMgb2YgaW52ZXJzZSANICAgbXVsdGlwbGV4aW5nLiAgU2VyaWFsIG9yIGluY3JlbWVudGFs IHNldHVwIHNvbHZlcyB0aGlzIHByb2JsZW0uIA0NICAgSW4gb3JkZXIgdG8gYWNjb21wbGlzaCBp bmNyZW1lbnRhbCBzZXR1cCBhbiBpdGVyYXRpdmUgcHJvY2VzcyBpcyB1c2VkIA0gICB0byBhZGQg Z3JvdXAgbWVtYmVycy4gIEZvciBlYWNoIGl0ZXJhdGlvbiwgTlZDIGlzIGluY3JlbWVudGVkIHVw IHRvIA0gICB0aGUgZmluYWwgdmFsdWUgcmVxdWlyZWQuICBUaGUgaXRlcmF0aW9uIGNvbnNpc3Rz IG9mIHRoZSBzdWNjZXNzZnVsIA0gICBjb21wbGV0aW9uIG9mIFBhdGggYW5kIFJlc3Ygc2lnbmFs aW5nLiAgQXQgZmlyc3QsIE5WQyA9IDEgYW5kIHRoZSANICAgbGFiZWwgaW5jbHVkZXMganVzdCBv bmUgdGltZXNsb3QgaWRlbnRpZmllciAgDQ0gICBBdCBlYWNoIG9mIHRoZSBuZXh0IGl0ZXJhdGlv bnMsIE5WQyBpcyBzZXQgdG8gKE5WQyArMSksIG9uZSBtb3JlIA0gICB0aW1lc2xvdCBpZGVudGlm aWVyIGlzIGFkZGVkIHRvIHRoZSBvcmRlcmVkIGxpc3QgaW4gdGhlIEdlbmVyYWxpemVkIA0gICBM YWJlbCAoaW4gdGhlIFBhdGggb3IgUmVzdiBtZXNzYWdlKS4gIEEgbm9kZSB0aGF0IHJlY2VpdmVz IGEgUGF0aCANICAgbWVzc2FnZSB0aGF0IGNvbnRhaW5zIGNoYW5nZWQgZmllbGRzIHdpbGwgcHJv Y2VzcyB0aGUgZnVsbCBQYXRoIA0gICBtZXNzYWdlIGFuZCwgYmFzZWQgb24gdGhlIG5ldyB2YWx1 ZSBvZiBOVkMsIGl0IHdpbGwgYWRkIGEgY29tcG9uZW50IA0gICBzaWduYWwgdG8gdGhlIFZDQVQg Z3JvdXAsIGFuZCBzd2l0Y2ggdGhlIG5ldyB0aW1lc2xvdCBiYXNlZCBvbiB0aGUgDSAgIG5ldyBs YWJlbCBpbmZvcm1hdGlvbi4gDQ0gICBGb2xsb3dpbmcgdGhlIGFkZGl0aW9uIG9mIHRoZSBuZXcg bGFiZWwgdG8gdGhlIExTUCwgTENBUyBtYXkgYmUgdXNlZCANICAgaW4tYmFuZCB0byBhZGQgdGhl IG5ldyBsYWJlbCBpbnRvIHRoZSBleGlzdGluZyBWQ0FUIGdyb3VwLiAgTENBUyANICAgc2lnbmFs aW5nIGZvciB0aGlzIGZ1bmN0aW9uIGlzIGRlc2NyaWJlZCBpbiBbSVRVLVQtRy43MDQyXS4gDQ00 LjEuMy4gRGVjcmVhc2luZyBWQ0cgY2FwYWNpdHkgDQ1WQ0cgY2FwYWNpdHkgY2FuIGJlIGRlY3Jl YXNlZCBpbiB0d28gd2F5cw1UZW1wb3JhcnkgcmVtb3ZhbCBvZiBhIFZDRyBtZW1iZXIocykgZHVl IHRvIGZhaWx1cmUgKGdvZXMgdG8gRE5VIHN0YXRlKQ1QbGFubmVkIHBlcm1hbmFuZW10IHJlbW92 YWwgb2YgYSBWQ0cgbWVtYmVyKHMpIChnb2VzIHRvIElETEUgc3RhdGUpIFRoaXMgYWN0aW9uIGlz IGluaXRpYXRlZCBieSBtYW5hZ2VtZW50IGludGVydmVudGlvbi4NDVRlbXBvcmFyeSBSZW1vdmlu ZyBhbCBvZiBhIFZDRyBtZW1iZXIgQ29tcG9uZW50IFNpZ25hbCANDVRoaXMgaXMgYW4gYXV0b25v bW91cyBhY3Rpb24gcGVyZm9ybWVkIGJ5IHRoZSBMQ0FTIHByb3RvY29sIHdoZW5ldmVyIGEgZmFp bHVyZSBvY2N1cnMgb24gYW4gYWN0aXZlIFZDRyBtZW1iZXIocykuIFRoZSByZWxldmFudCBWQ0cg bWVtYmVyIHdpbGwgdGhlbiBiZSBpbiB0aGUgRE5VIHN0YXRlLg0NVGhlcmUgaXMgbm8gbWFuYWdl bWVudCBpbnRlcnZlbnRpb24gcmVxdWlyZWQgdG8gcGVyZm9ybSB0aGlzIG9wZXJhdGlvbi4NDVRo aXMgbWVtYmVyIGNhbiB0aGVuIGJlIHBlcm1hbmVudGx5IHJlbW92ZWQgZnJvbSB0aGUgVkNHLiAo NC4xLjMuMikNDTQuMS4zLjIJCVBsYW5uZWQgcGVybWFuZW50IHJlbW92YWwgb2YgYSBWQ0cgbWVt YmVyDQ0gICBUaGUgcHJvY2VkdXJlIHRvIHJlbW92ZSBhIGNvbXBvbmVudCBzaWduYWwgaXMgc2lt aWxhciB0byB0aGF0IHVzZWQgdG8gDSAgIGFkZCBjb21wb25lbnRzIGFzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDQuMS4yLiAgVGhlIExDQVMgaW4tYmFuZCANICAgc2lnbmFsaW5nIHN0ZXAgaXMgdGFr ZW4gZmlyc3QgdG8gdGFrZSB0aGUgY29tcG9uZW50IG91dCBvZiB0aGUgZ3JvdXAgYXMgdGhlIHJl c3VsdCBvZiBhIHJlbW92ZSBjb21tYW5kIGZyb20gdGhlIExDQVMgY29udHJvbGxlcjsgdGhlIHBl cm1hbmVudGx5IHJlbW92ZWQgbWVtYmVyIHdpbGwgdGhlbiBiZSBpbiB0aGUgSURMRSBzdGF0ZS4g IA0gICBMQ0FTIHNpZ25hbGluZyBpcyBkZXNjcmliZWQgaW4gW0lUVS1ULUcuNzA0Ml0uIA0NICAg SW4gdGhpcyBjYXNlLCB0aGUgTlZDIHZhbHVlIGlzIGRlY3JlbWVudGVkIGJ5IDEgYW5kIHRoZSB0 aW1lc2xvdCANICAgaWRlbnRpZmllciBmb3IgdGhlIGRyb3BwZWQgY29tcG9uZW50IGlzIHJlbW92 ZWQgZnJvbSB0aGUgb3JkZXJlZCBsaXN0IA0gICBpbiB0aGUgR2VuZXJhbGl6ZWQgTGFiZWwuICAN DVRoaXMgcGVybWFuZW50IHJlbW92YWwgcHJvY2VkdXJlIGlzIG9ubHkgYXBwbGljYWJsZSB0byBM Q0FTLWNhcGFibGUtVkNBVC4gVGhpcyBmdW5jdGlvbiBpcyBub3Qgc3VwcG9ydGVkIHdpdGhvdXQg DSAgIG1hbmFnZW1lbnQgaW50ZXJ2ZW50aW9uIGZvciBWQ0FULW9ubHkgaW50ZXJmYWNlcyBhcyBy ZW1vdmluZyBvbmUgDSAgIGNvbXBvbmVudCBvZiB0aGUgVkNHIHdpbGwgcmVzdWx0IGluIGVycm9y cyBpbiB0aGUgaW52ZXJzZS0NICAgbXVsdGlwbGV4aW5nIHByb2NlZHVyZSBvZiBWQ0FUIGFuZCBy ZXN1bHQgaW4gdGhlIHRlYXJkb3duIG9mIHRoZSANICAgd2hvbGUgZ3JvdXAuICBTbywgdGhpcyBp cyBhIGZlYXR1cmUgdGhhdCBvbmx5IExDQVMtY2FwYWJsZSBWQ0FUIA0gICBpbnRlcmZhY2VzIGNh biBzdXBwb3J0IHdpdGhvdXQgbWFuYWdlbWVudCBpbnRlcnZlbnRpb24gYXQgdGhlIGVuZCANICAg cG9pbnRzLiANDQ00LjEuNC4gUmVtb3ZpbmcgTXVsdGlwbGUgQ29tcG9uZW50IFNpZ25hbHMgaW4g T25lIFNob3QgDQ0gICBUaGUgcHJvY2VkdXJlIGlzIHNpbWlsYXIgdG8gNC4xLjMuICBJbiB0aGlz IGNhc2UsIHRoZSBOVkMgdmFsdWUgaXMgDSAgIGNoYW5nZWQgdG8gdGhlIG5ldyB2YWx1ZSBhbmQg YWxsIHJlbGV2YW50IHRpbWVzbG90IGlkZW50aWZpZXJzIGZvciANICAgdGhlIGNvbXBvbmVudHMg dG8gYmUgdG9ybiBkb3duIGFyZSByZW1vdmVkIGZyb20gdGhlIG9yZGVyZWQgbGlzdCBpbiANICAg dGhlIEdlbmVyYWxpemVkIExhYmVsLiAgVGhpcyBpcyBhbHNvIG5vdCBzdXBwb3J0ZWQgZm9yIFZD QVQtb25seSANICAgaW50ZXJmYWNlcyB3aXRob3V0IG1hbmFnZW1lbnQgaW50ZXJ2ZW50aW9uIGFz IHJlbW92aW5nIG9uZSBjb21wb25lbnQgDSANIA1CZXJuc3RlaW4gICAgICAgICAgICAgIEV4cGly ZXMgRmVicnVhcnkgNCwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA2XSANDA1JbnRlcm5ldC1E cmFmdCAgICBPcGVyYXRpbmcgVkNBVCBhbmQgTENBUyB3aXRoIEdNUExTICAgICAgICBBdWd1c3Qg MjAwNiANICAgIA0NICAgb2YgdGhlIFZDRyB3aWxsIHRlYXIgZG93biB0aGUgd2hvbGUgZ3JvdXAs IGJ1dCB0aGUgdXNlIG9mIExDQVMgY2FuIA0gICBmYWNpbGl0YXRlIHRoaXMgcHJvY2VkdXJlLiAN DTQuMS41LiBVc2Ugb2YgbXVsdGlwbGUgTFNQcyBmb3IgQ28tUm91dGVkIFNpZ25hbHMgDQ0gICBD by1yb3V0ZWQgc2lnbmFscyBtYXkgYWxzbyBiZSBzdXBwb3J0ZWQgYnkgZGlzdGluY3QgTFNQcyBz aWduYWxlZCANICAgc2VwYXJhdGVseSB1c2luZyBleGFjdGx5IHRoZSB0ZWNobmlxdWVzIGRlc2Ny aWJlZCBmb3IgZGl2ZXJzZWx5IA0gICByb3V0ZWQgc2lnbmFscyBpbiBTZWN0aW9uIDQuMi4gDQ00 LjEuNi4gVGVhcmRvd24gb2YgV2hvbGUgVkNHIA0NICAgVGhlIGVudGlyZSBMU1AgaXMgZGVsZXRl ZCBpbiBhIHNpbmdsZSBzdGVwIChpLmUuLCBhbGwgY29tcG9uZW50cyBhcmUgDSAgIHJlbW92ZWQg aW4gb25lIGdvKSB1c2luZyBkZWxldGlvbiBwcm9jZWR1cmVzIG9mIFtSRkMzNDczXS4gDQ00LjIu IERpdmVyc2VseSBSb3V0ZWQgU2lnbmFscyANDSAgIFRoZSBpbml0aWFsIEdNUExTIHNwZWNpZmlj YXRpb24gZGlkIG5vdCBzdXBwb3J0IGRpdmVyc2VseSByb3V0ZWQgDSAgIHNpZ25hbHMgdXNpbmcg dGhlIE5WQyBjb25zdHJ1Y3QuICBJbiBmYWN0LCBbUkZDMzk0NmJpc10gc2F5czogDQ0gICAgICAg ICBbLi4uXSBUaGUgc3RhbmRhcmQgZGVmaW5pdGlvbiBmb3IgdmlydHVhbCBjb25jYXRlbmF0aW9u IGFsbG93cyANICAgICAgICAgZWFjaCB2aXJ0dWFsIGNvbmNhdGVuYXRpb24gY29tcG9uZW50cyB0 byB0cmF2ZWwgb3ZlciBkaXZlcnNlIA0gICAgICAgICBwYXRocy4gIFdpdGhpbiBHTVBMUywgdmly dHVhbCBjb25jYXRlbmF0aW9uIGNvbXBvbmVudHMgbXVzdCANICAgICAgICAgdHJhdmVsIG92ZXIg dGhlIHNhbWUgKGNvbXBvbmVudCkgbGluayBpZiB0aGV5IGFyZSBwYXJ0IG9mIHRoZSANICAgICAg ICAgc2FtZSBMU1AuICBUaGlzIGlzIGR1ZSB0byB0aGUgd2F5IHRoYXQgbGFiZWxzIGFyZSBib3Vu ZCB0byBhIA0gICAgICAgICAoY29tcG9uZW50KSBsaW5rLiAgTm90ZSBob3dldmVyLCB0aGF0IHRo ZSByb3V0aW5nIG9mIGNvbXBvbmVudHMgDSAgICAgICAgIG9uIGRpZmZlcmVudCBwYXRocyBpcyBp bmRlZWQgZXF1aXZhbGVudCB0byBlc3RhYmxpc2hpbmcgDSAgICAgICAgIGRpZmZlcmVudCBMU1Bz LCBlYWNoIG9uZSBoYXZpbmcgaXRzIG93biByb3V0ZS4gIFNldmVyYWwgTFNQcyANICAgICAgICAg Y2FuIGJlIGluaXRpYXRlZCBhbmQgdGVybWluYXRlZCBiZXR3ZWVuIHRoZSBzYW1lIG5vZGVzIGFu ZCANICAgICAgICAgdGhlaXIgY29ycmVzcG9uZGluZyBjb21wb25lbnRzIGNhbiB0aGVuIGJlIGFz c29jaWF0ZWQgdG9nZXRoZXIgDSAgICAgICAgIChpLmUuLCB2aXJ0dWFsbHkgY29uY2F0ZW5hdGVk KS4gDQ0gICBEaXZlcnNlIHJvdXRpbmcgb2Ygc2lnbmFscyBjYW4gYmUgYSB1c2VmdWwgY2FwYWJp bGl0eSBidXQgcmVxdWlyZXMgDSAgIHRoZSBleHRlbnNpb25zIGlkZW50aWZpZWQgaW4gdGhpcyBk b2N1bWVudC4gDQ00LjIuMS4gQXNzb2NpYXRpbmcgRGl2ZXJzZWx5IFJvdXRlZCBTaWduYWxzIA0N ICAgVGhlIGZlYXR1cmUgdGhhdCBuZWVkcyB0byBiZSBhZGRlZCBpcyB0aGUgZnVuY3Rpb25hbGl0 eSB0byBhc3NvY2lhdGUgDSAgIHRoZSBjb21wb25lbnRzIG9mIHRoZSBzYW1lIFZDRy4gIEZvciB0 aGlzIHB1cnBvc2UsIHdlIHVzZSB0aGUgDSAgIEFzc29jaWF0aW9uIE9iamVjdCB0aGF0IHdhcyBk ZWZpbmVkIGluIFtFMkUtUkVDT1ZFUlldIHRvIGFzc29jaWF0ZSANICAgd29ya2luZyBhbmQgcmVj b3ZlcnkgTFNQcy4gDQ1UaGUgTENBUyBmZWF0dXJlIGlzIHRvIGVuYWJsZSBoaXRsZXNzIGNhcGFj aXR5IGNoYW5nZSBvbiB0aGUgdHJhbnNwb3J0IHBpcGUNDSAgIEEgZGl2ZXJzZWx5IHJvdXRlZCBW Q0cgdXNlcyBhIG51bWJlciBvZiByb3V0ZXMgUiA8PSBWQ0cgc2l6ZSwgYXMgc29tZSANICAgcm91 dGVzIG1heSBiZSB0aGUgc2FtZSBmb3Igc2V2ZXJhbCBjb21wb25lbnRzLiAgQSBudW1iZXIgb2Yg TFNQcywgTCANICAgKFZDRyA+PSBMID49IFIpIGFyZSB1c2VkIHdpdGggZWFjaCBMU1AgZXN0YWJs aXNoaW5nIGF0IGxlYXN0IG9uZSANICAgY29tcG9uZW50IG9mIHRoZSBWQ0csIGFuZCBhdCBtb3N0 IGFsbCBvZiB0aGUgY28tcm91dGVkIG1lbWJlcnMgb2YgdGhlIA0gICBncm91cC4gIEZvciBhIHNl dCBvZiBjIGNvbXBvbmVudHMgdXNpbmcgdGhlIHNhbWUgcm91dGUsIHdlIHNldCB1cCB0aGUgDSAg IExTUCB3aXRoIE5WQyA9IGMgZXhhY3RseSBhcyBleHBsYWluZWQgaW4gc2VjdGlvbiA0LjEuMS4g IFRoZXJlZm9yZSwgDSANIA1CZXJuc3RlaW4gICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkg NCwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA3XSANDA1JbnRlcm5ldC1EcmFmdCAgICBPcGVy YXRpbmcgVkNBVCBhbmQgTENBUyB3aXRoIEdNUExTICAgICAgICBBdWd1c3QgMjAwNiANICAgIA0N ICAgdGhlIGFzc29jaWF0aW9uIG9mIGdyb3VwIG1lbWJlcnMgb3Igb2Ygc3ViLWdyb3VwcyB0byBm b3JtIHRoZSBWQ0cgDSAgIHJlcXVpcmVzIHRoZSBhc3NvY2lhdGlvbiBvZiB0aGUgTFNQcyB1c2Vk IHRvIGVzdGFibGlzaCB0aGUgZ3JvdXAgDSAgIG1lbWJlcnMuIA0NICAgVG8gYmUgYWJsZSB0byBk aXN0aW5ndWlzaCB0aGUgTFNQcyBpbiB0aGUgVkNHIGVhY2ggbXVzdCBoYXZlIGEgdW5pcXVlIA0g ICBpZGVudGlmaWVyLiBMU1BzIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSBjb21iaW5hdGlvbiBvZiBT ZXNzaW9uIGFuZCANICAgU2VuZGVyIFRlbXBsYXRlIGZpZWxkcy4gIEl0IGlzIGNvbW1vbiBwcmFj dGljZSB3aGVuIG1ha2UtYmVmb3JlLWJyZWFrIA0gICBbUkZDMzIwOV0gaXMgc3VwcG9ydGVkIHRv IGFsbG93IExTUHMgd2l0aCB0aGUgc2FtZSBTZXNzaW9uLCBidXQgDSAgIGRpZmZlcmVudCBTZW5k ZXIgVGVtcGxhdGVzIChzcGVjaWZpY2FsbHkgd2l0aCBkaWZmZXJlbnQgTFNQIElEcykgdG8gDSAg IHNoYXJlIHJlc291cmNlcy4gIFNpbmNlIHJlc291cmNlIHNoYXJpbmcgYmV0d2VlbiBWQ0cgbWVt YmVycyBtdXN0IG5vdCANICAgYmUgYWxsb3dlZCAoYmVjYXVzZSB3ZSB3YW50IGVhY2ggTFNQIHRv IGNvbnRyaWJ1dGUgY2FwYWNpdHkgdG8gdGhlIA0gICBWQ0cpLCBidXQgc2luY2Ugd2Ugd2FudCB0 byBjb250aW51ZSB0byBzdXBwb3J0IG1ha2UtYmVmb3JlLWJyZWFrIGZvciANICAgZWFjaCBncm91 cCBtZW1iZXIsIGl0IGlzIG5lY2Vzc2FyeSB0byBkaXN0aW5ndWlzaCB0aGUgTFNQcyBpbiB0aGUg VkNHIA0gICBieSB2YXJ5aW5nIHRoZSBmaWVsZHMgaW4gdGhlIFNlc3Npb24gb2JqZWN0LiAgU3Bl Y2lmaWNhbGx5LCBhIA0gICBkaWZmZXJlbnQgVHVubmVsIElEIGlzIHVzZWQgdG8gaWRlbnRpZnkg ZWFjaCBMU1AgaW4gdGhlIFZDRy4gDQ0gICBUaHVzLCBWQ0cgbWVtYmVycyBjYW5ub3QgYmUgYXNz b2NpYXRlZCB0aHJvdWdoIHRoZSBTZXNzaW9uIG9iamVjdCwgDSAgIGFuZCB0aGUgQXNzb2NpYXRp b24gb2JqZWN0IGlzIHVzZWQgaW5zdGVhZC4gDQ0gICBUaGUgYXNzaWdubWVudCBvZiB0aGUgQXNz b2NpYXRpb24gSUQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgR01QTFMgDSAgIGJ1dCBNVVNUIGJl IHVuaXF1ZSBmb3IgZWFjaCBWQ0FUIGdyb3VwLiANDSAgIE5vdGUgdGhhdCB0aGUgdXNlIG9mIHRo ZSBBc3NvY2lhdGlvbiBvYmplY3QgdG8gYXNzb2NpYXRlIG1lbWJlcnMgb2YgYSANICAgVkNHIGRv ZXMgbm90IHByZWNsdWRlIHRoZSB1c2Ugb2YgYW5vdGhlciBpbnN0YW5jZSBvZiB0aGUgb2JqZWN0 IHdpdGggDSAgIGEgZGlmZmVyZW50IEFzc29jaWF0aW9uIElEIHRvIGluZGljYXRlIHRoZSBhc3Nv Y2lhdGlvbiBvZiB3b3JraW5nIGFuZCANICAgcmVjb3ZlcnkgTFNQcywgYXMgW0UyRS1SRUNPVkVS WV0gYWxsb3dzIHRoZSB1c2Ugb2YgbXVsdGlwbGUgDSAgIEFzc29jaWF0aW9uIG9iamVjdHMuICBX ZSBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlIEFzc29jaWF0aW9uIA0gICBvYmplY3RzIHVzZWQg Zm9yIHRoZSBWQ0FUIGdyb3VwIGFuZCBvdGhlciBBc3NvY2lhdGlvbiBvYmplY3RzIHRocm91Z2gg DSAgIHRoZSBkZWZpbml0aW9uIG9mIGEgbmV3IGFzc29jaWF0aW9uIHR5cGUgdG8gaW5kaWNhdGUg dGhhdCB0aGlzIGlzIGEgDSAgIFZDRyBhc3NvY2lhdGlvbi4gDQ0gICBBc3NvY2lhdGlvbiBUeXBl OiAxNiBiaXRzICANDSAgICAgICAgICAgICAgIFZhbHVlICAgICAgIFR5cGUgIA0gICAgICAgICAg ICAgICAtLS0tLSAgICAgICAtLS0tICANDSAgICAgICAgICAgICAgICAgMyAgICAgICAgIFZDQVQg Z3JvdXAgIA0NICAgU2VlIFtFMkUtUkVDT1ZFUlldIGZvciB0aGUgZGVmaW5pdGlvbiBvZiBvdGhl ciBmaWVsZHMgYW5kIHZhbHVlcyBvZiANICAgdGhlIEFzc29jaWF0aW9uIG9iamVjdC4gDQ00LjIu Mi4gUHJvY2VkdXJlcyBmb3IgVkNHIFNldHVwIFVzaW5nIERpdmVyc2VseSBSb3V0ZWQgQ29tcG9u ZW50cyANDSAgIEZvciBldmVyeSByb3V0ZSBSLCB1c2UgdGhlIHByb2NlZHVyZSBvdXRsaW5lZCBp biBzZWN0aW9uIDQuMS4xIG9yIA0gICA0LjEuMiBkZXBlbmRpbmcgb24gdGhlIGNhcGFiaWxpdHkg b2YgdGhlIGVxdWlwbWVudCBvciBsb2NhbCBwb2xpY3kuICANICAgVGhlIFBhdGggbWVzc2FnZSBN VVNUIGluY2x1ZGUgdGhlIEFzc29jaWF0aW9uIG9iamVjdCB3aXRoIHR5cGUgc2V0IHRvIA0gICAz LCBhbmQgZWFjaCBQYXRoIG1lc3NhZ2UgTVVTVCB1c2UgdGhlIHNhbWUgQXNzb2NpYXRpb24gSUQu IA0gDSANQmVybnN0ZWluICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDQsIDIwMDcgICAg ICAgICAgICAgICAgW1BhZ2UgOF0gDQwNSW50ZXJuZXQtRHJhZnQgICAgT3BlcmF0aW5nIFZDQVQg YW5kIExDQVMgd2l0aCBHTVBMUyAgICAgICAgQXVndXN0IDIwMDYgDSAgICANDSAgIEZvbGxvd2lu ZyB0aGUgYWRkaXRpb24gb2YgZWFjaCBuZXcgTFNQIChpLmUuLCBvbmNlIHRoZSBSRVNWIG1lc3Nh Z2UgDSAgIGhhcyBiZWVuIHJlY2VpdmVkIGJ5IHRoZSBpbmdyZXNzIExTUiksIExDQVMgc2lnbmFs aW5nIGlzIHVzZWQgaW4tYmFuZCANICAgdG8gaGl0bGVzc2x5IGFkZCB0aGUgbmV3IGxhYmVsIGlu dG8gdGhlIGV4aXN0aW5nIGdyb3VwIFtJVFUtVC0NICAgRy43MDQyXS4gDQ00LjIuMy4gUHJvY2Vk dXJlcyBmb3IgVkNHIFJlZHVjdGlvbi9UZWFyZG93biBVc2luZyBEaXZlcnNlbHkgUm91dGVkIA0g ICBDb21wb25lbnRzIA0NICAgVG8gcmVtb3ZlIHRoZSBjb21wb25lbnQgY2lyY3VpdHMgb24gYW55 IHJvdXRlLCBMQ0FTIHNpZ25hbGluZyBpcyB1c2VkIA0gICBpbi1iYW5kIHRvIHJlbW92ZSB0aGUg bGFiZWxzIGFzc29jaWF0ZWQgd2l0aCB0aGUgTFNQIGZyb20gdGhlIGdyb3VwLiAgDSAgIExDQVMg c2lnbmFsaW5nIGlzIGRlZmluZWQgaW4gW0lUVS1ULUcuNzA0Ml0uIA0NICAgSW4gYWRkaXRpb24s IHRoZSBwcm9jZWR1cmVzIG91dGxpbmVkIGluIHNlY3Rpb24gNC4xLjMgb3IgNC4xLjQgYXJlIA0g ICB1c2VkIHRvIHRlYXIgZG93biB0aGUgdW53YW50ZWQgTFNQLiAgDQ0gICBBZ2FpbiwgdGhpcyBj YW4gb25seSBiZSBkb25lIG9uIExDQVMtY2FwYWJsZSBpbnRlcmZhY2VzLiAgSWYgdGhlIA0gICBw cm9jZWR1cmUgaXMgYXR0ZW1wdGVkIG9uIFZDQVQtb25seSBpbnRlcmZhY2VzLCB0aGVuIHRoZSB3 aG9sZSBWQ0cgaXMgDSAgIHRvcm4gZG93biAodGhpcyBpcyBub3QgYSBncmFjZWZ1bCB0ZWFyZG93 biBzbyBpbmdyZXNzL2VncmVzcyBpbml0aWF0ZSANICAgYSBQYXRoIFRlYXIvUmVzdiBUZWFyKSBv biBhbGwgcm91dGVzLiANDTQuMi40LiBVcGRhdGUgb2YgQWxyZWFkeSBFc3RhYmxpc2hlZCBMU1Bz IA0NICAgRXN0YWJsaXNoZWQgY28tcm91dGVkIFZDQVQgZ3JvdXBzIGN1cnJlbnRseSBkbyBub3Qg c3VwcG9ydCB0aGUgDSAgIEFzc29jaWF0aW9uIG9iamVjdC4gIElmIGEgY28tcm91dGVkIFZDQVQg R3JvdXAgc2l6ZSBpcyB0byBiZSANICAgaW5jcmVhc2VkIHdpdGggbmV3IGRpdmVyc2VseSByb3V0 ZWQgbWVtYmVycywgd2UgdXNlIHRoZSBMU1AgDSAgIG1vZGlmaWNhdGlvbiBwcm9jZWR1cmUgZGVz Y3JpYmVkIGluIFtSRkMyMjA1XS4gIEFuIEFzc29jaWF0aW9uIG9iamVjdCANICAgaXMgYWRkZWQg dG8gdGhlIFBhdGggbWVzc2FnZSBmb3IgdGhlIGV4aXN0aW5nIExTUChzKS4gIFRoYXQgDSAgIEFz c29jaWF0aW9uIG9iamVjdCBjYW4gdGhlbiBiZSB1c2VkIHRvIHNldCB1cCBuZXcgZGl2ZXJzZWx5 IHJvdXRlZCANICAgZ3JvdXAgbWVtYmVycy4gDQ0gICBUaGUgc2FtZSBhcHBsaWVzIHRvIFNPTkVU L1NESCBMU1BzLiAgQW4gb3BlcmF0b3IgbWF5IGRlY2lkZSB0byB1c2UgYW4gDSAgIGFscmVhZHkg Y3Jvc3MtY29ubmVjdGVkIFNPTkVUL1NESCBMU1AgZm9yIGRpdmVyc2VseS1yb3V0ZWQgVkNBVC4g IEluIA0gICB0aGlzIGNhc2UgdGhlIG1vZGlmaWNhdGlvbiBwcm9jZWR1cmUgZGVzY3JpYmVkIGlu IFtSRkMyMjA1XSBpcyB1c2VkIA0gICBhcyB3ZWxsLiANDTQuMi41LiBPbmUgTFNQIHBlciBDaXJj dWl0IA0NICAgVGhlc2UgcHJvY2VkdXJlcyBjYW4gc3VwcG9ydCB0aGUgdXNlIG9mIGFzIG1hbnkg TFNQcyBhcyB0aGVyZSBhcmUgDSAgIGNpcmN1aXRzIGluIHRoZSBWQ0cuICBUaGlzIGNhbiBiZSBk b25lIHdoZW4gZWFjaCBjaXJjdWl0IGlzIA0gICBzZXBhcmF0ZWx5IHJvdXRlZCwgb3Igd2hlbiBz b21lIG9mIHRoZSBjaXJjdWl0cyBhcmUgY28tcm91dGVkLCBhbmQgDSAgIGVhY2ggTFNQIHdpbGwg YmUgdXNlZCB0byBzZXQgdXAgb25lIGVsZW1lbnQgb2YgdGhlIFZDRy4gIFRoZSANICAgQXNzb2Np YXRpb24gb2JqZWN0IGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhlIFZDRyBhc3NvY2lhdGlvbi4gDQ0N DQ0NIA0gDUJlcm5zdGVpbiAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA0LCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDldIA0MDUludGVybmV0LURyYWZ0ICAgIE9wZXJhdGluZyBWQ0FU IGFuZCBMQ0FTIHdpdGggR01QTFMgICAgICAgIEF1Z3VzdCAyMDA2IA0gICAgDQ01LiBJQU5BIENv bnNpZGVyYXRpb25zIA0NICAgVGhpcyBkb2N1bWVudCByZXF1ZXN0cyBmcm9tIElBTkEgdGhlIGFz c2lnbm1lbnQgb2YgYSBuZXcgQXNzb2NpYXRpb24gDSAgIFR5cGUgd2l0aGluIHRoZSBBc3NvY2lh dGlvbiBvYmplY3QuICBUaGlzIG9iamVjdCB3YXMgZGVmaW5lZCBpbiBbRTJFLQ0gICBSRUNPVkVS WV0uIA0NICAgVGhlIHZhbHVlIDMgIlZDQVQgZ3JvdXAiIGlzIHN1Z2dlc3RlZCBpbiBzZWN0aW9u IDQuMi4xLiAgDQ02LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyANDSAgIFRoaXMgZG9jdW1lbnQg aW50cm9kdWNlcyBhIG5ldyB1c2Ugb2YgdGhlIEFzc29jaWF0aW9uIG9iamVjdCBmb3IgDSAgIEdN UExTIHNpZ25hbGluZyBbUkZDMzQ3M10gdG8gYXNzb2NpYXRlIGRpdmVyc2VseSByb3V0ZWQgVkNB VCBncm91cCANICAgbWVtYmVycy4gIEl0IGRvZXMgbm90IGludHJvZHVjZSBhbnkgbmV3IHNpZ25h bGluZyBtZXNzYWdlcywgbm9yIA0gICBjaGFuZ2UgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIExT UnMgdGhhdCBhcmUgYWRqYWNlbnQgaW4gdGhlIGNvbnRyb2wgDSAgIHBsYW5lLiAgVGhpcyBhc3Nv Y2lhdGlvbiBpbmZvcm1hdGlvbiBpbiB0aGUgZXZlbnQgb2YgYW4gaW50ZXJjZXB0aW9uIA0gICBt YXkgaW5kaWNhdGUgdGhhdCB0aGVyZSBhcmUgbWVtYmVycyBvZiB0aGUgc2FtZSBWQ0FUIGdyb3Vw IHRoYXQgdGFrZSANICAgYSBkaWZmZXJlbnQgcm91dGUgYW5kIG1heSBpbmRpY2F0ZSB0byBhbiBp bnRlcmNlcHRvciB0aGF0IHRoZSBuZXR3b3JrIA0gICBtYXkgYmUgbW9yZSByb2J1c3QuIA0NICAg T3RoZXJ3aXNlLCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBhbnkgYWRkaXRpb25h bCBzZWN1cml0eSANICAgY29uc2lkZXJhdGlvbnMuIA0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DSANIA1CZXJuc3RlaW4gICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNCwgMjAwNyAgICAg ICAgICAgICAgIFtQYWdlIDEwXSANDA1JbnRlcm5ldC1EcmFmdCAgICBPcGVyYXRpbmcgVkNBVCBh bmQgTENBUyB3aXRoIEdNUExTICAgICAgICBBdWd1c3QgMjAwNiANICAgIA0NNy4gQ29udHJpYnV0 b3JzIA0NICAgV2F0YXJ1IEltYWp1a3UgKE5UVCkgIA0gICAxLTEgSGlrYXJpLW5vLW9rYSBZb2tv c3VrYSBLYW5hZ2F3YSAyMzktMDg0NyAgDSAgIEphcGFuIA0gICAgDSAgIFBob25lICs4MS00Ni04 NTktNDMxNSANICAgRW1haWw6IGltYWp1a3Uud2F0YXJ1QGxhYi5udHQuY28uanAgIA0gICAgDSAg IEp1bGllbiBNZXVyaWMgDSAgIEZyYW5jZSBUZWxlY29tIA0gICAyLCBhdmVudWUgUGllcnJlIE1h cnppbiANICAgMjIzMDcgTGFubmlvbiBDZWRleCANICAgRnJhbmNlIA0gICAgDSAgIFBob25lOiAr IDMzIDIgOTYgMDUgMjggMjggDSAgIEVtYWlsOiBqdWxpZW4ubWV1cmljQG9yYW5nZS1mdC5jb20g DSAgICANICAgTHluZG9uIE9uZyAgDSAgIENpZW5hIA0gICBQTyBCb3ggMzA4ICANICAgQ3VwZXJ0 aW5vLCBDQSA5NTAxNSANICAgVW5pdGVkIFN0YXRlcyBvZiBBbWVyaWNhIA0gICAgDSAgIFBob25l OiArMSA0MDggNzA1IDI5NzggDSAgIEVtYWlsOiBseW9uZ0BjaWVuYS5jb20gDSAgICANICAgIA04 LiBBY2tub3dsZWRnbWVudHMgDQ0gICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIE1h YXJ0ZW4gVmlzc2VycyBhbmQgQWRyaWFuIEZhcnJlbCBmb3IgDSAgIGV4dGVuc2l2ZSByZXZpZXdz IGFuZCBjb250cmlidXRpb25zIHRvIHRoaXMgZHJhZnQuIA0NDQ0NDQ0NDQ0NDQ0NDQ0gDSANQmVy bnN0ZWluICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDQsIDIwMDcgICAgICAgICAgICAg ICBbUGFnZSAxMV0gDQwNSW50ZXJuZXQtRHJhZnQgICAgT3BlcmF0aW5nIFZDQVQgYW5kIExDQVMg d2l0aCBHTVBMUyAgICAgICAgQXVndXN0IDIwMDYgDSAgICANDTkuIFJlZmVyZW5jZXMgDQ05LjEu IE5vcm1hdGl2ZSBSZWZlcmVuY2VzIA0NICAgW1JGQzIxMTldICAgICAgQnJhZG5lciwgUy4sICJL ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIA0gICAgICAgICAgICAgICAgICBS ZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LiANDSAgIFtS RkMyMjA1XSAgICAgIEJyYWRlbiwgUi4sIFpoYW5nLCBMLiwgQmVyc29uLCBTLiwgSGVyem9nLCBT LiBhbmQgUy4gDSAgICAgICAgICAgICAgICAgIEphbWluLCAiUmVzb3VyY2UgUmVTZXJWYXRpb24g UHJvdG9jb2wgKFJTVlApIC0tIA0gICAgICAgICAgICAgICAgICBWZXJzaW9uIDEsIEZ1bmN0aW9u YWwgU3BlY2lmaWNhdGlvbiIsIFJGQyAyMjA1LCANICAgICAgICAgICAgICAgICAgU2VwdGVtYmVy IDE5OTcuIA0NICAgW1JGQzMyMDldICAgICAgQXdkdWNoZSwgRC4sIEJlcmdlciwgTC4sIEdhbiwg RC4sIExpLCBULiwgU3Jpbml2YXNhbiwgDSAgICAgICAgICAgICAgICAgIFYuLCBhbmQgRy4gU3dh bGxvdywgIlJTVlAtVEU6IEV4dGVuc2lvbnMgdG8gUlNWUCBmb3IgDSAgICAgICAgICAgICAgICAg IExTUCBUdW5uZWxzIiwgUkZDIDMyMDksIERlY2VtYmVyIDIwMDEuIA0NICAgW1JGQzM0NzNdICAg ICAgQmVyZ2VyLCBMLiwgIkdlbmVyYWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIA0gICAgICAg ICAgICAgICAgICBTd2l0Y2hpbmcgKEdNUExTKSBTaWduYWxpbmcgUmVzb3VyY2UgUmVzZXJWYXRp b24gDSAgICAgICAgICAgICAgICAgIFByb3RvY29sLVRyYWZmaWMgRW5naW5lZXJpbmcgKFJTVlAt VEUpIEV4dGVuc2lvbnMiLCANICAgICAgICAgICAgICAgICAgUkZDIDM0NzMsIEphbnVhcnkgMjAw My4gDQ0gICBbUkZDMzk0NmJpc10gICBNYW5uaWUsIEUuIGFuZCBELiBQYXBhZGltaXRyaW91LCAi R2VuZXJhbGl6ZWQgTXVsdGktDSAgICAgICAgICAgICAgICAgIFByb3RvY29sIExhYmVsIFN3aXRj aGluZyAoR01QTFMpIEV4dGVuc2lvbnMgZm9yIA0gICAgICAgICAgICAgICAgICBTeW5jaHJvbm91 cyBPcHRpY2FsIE5ldHdvcmsgKFNPTkVUKSBhbmQgU3luY2hyb25vdXMgDSAgICAgICAgICAgICAg ICAgIERpZ2l0YWwgSGllcmFyY2h5IChTREgpIENvbnRyb2wiLCBJRVRGIGRyYWZ0LCB3b3JrIGlu IA0gICAgICAgICAgICAgICAgICBwcm9ncmVzcywgRGVjZW1iZXIgMjAwNS4gDQ0gICBbRTJFLVJF Q09WRVJZXSBMYW5nLCBKLlAuLCBSZWtodGVyLCBZLiwgYW5kIEQuIFBhcGFkaW1pdHJpb3UgKGVk cy4pLCANICAgICAgICAgICAgICAgICAgIlJTVlAtVEUgRXh0ZW5zaW9ucyBpbiBzdXBwb3J0IG9m IEVuZC10by1FbmQgDSAgICAgICAgICAgICAgICAgIEdlbmVyYWxpemVkIE11bHRpLVByb3RvY29s IExhYmVsIFN3aXRjaGluZyAoR01QTFMpLQ0gICAgICAgICAgICAgICAgICBiYXNlZCBSZWNvdmVy eSIsIElFVEYgZHJhZnQsIHdvcmsgaW4gcHJvZ3Jlc3MsIEFwcmlsIA0gICAgICAgICAgICAgICAg ICAyMDA1LiANDTkuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyANDSAgIFtBTlNJLVQxLjEwNV0g IEFtZXJpY2FuIE5hdGlvbmFsIFN0YW5kYXJkcyBJbnN0aXR1dGUsICJTeW5jaHJvbm91cyANICAg ICAgICAgICAgICAgICAgT3B0aWNhbCBOZXR3b3JrIChTT05FVCkgLSBCYXNpYyBEZXNjcmlwdGlv biBpbmNsdWRpbmcgDSAgICAgICAgICAgICAgICAgIE11bHRpcGxleCBTdHJ1Y3R1cmUsIFJhdGVz LCBhbmQgRm9ybWF0cyIsIEFOU0kgVDEuMTA1LQ0gICAgICAgICAgICAgICAgICAyMDAxLCBNYXkg MjAwMS4gDQ0gICBbSVRVLVQtRy43MDQyXSBJbnRlcm5hdGlvbmFsIFRlbGVjb21tdW5pY2F0aW9u cyBVbmlvbiwgIkxpbmsgQ2FwYWNpdHkgDSAgICAgICAgICAgICAgICAgIEFkanVzdG1lbnQgU2No ZW1lIChMQ0FTKSBmb3IgVmlydHVhbCBDb25jYXRlbmF0ZWQgDSAgICAgICAgICAgICAgICAgIFNp Z25hbHMiLCBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjcwNDIsIEZlYnJ1YXJ5IDIwMDQuIA0NDQ0N IA0gDUJlcm5zdGVpbiAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA0LCAyMDA3ICAgICAg ICAgICAgICAgW1BhZ2UgMTJdIA0MDUludGVybmV0LURyYWZ0ICAgIE9wZXJhdGluZyBWQ0FUIGFu ZCBMQ0FTIHdpdGggR01QTFMgICAgICAgIEF1Z3VzdCAyMDA2IA0gICAgDQ0gICBbSVRVLVQtRy43 MDQzXSBJbnRlcm5hdGlvbmFsIFRlbGVjb21tdW5pY2F0aW9ucyBVbmlvbiwgIlZpcnR1YWwgDSAg ICAgICAgICAgICAgICAgIENvbmNhdGVuYXRpb24gb2YgUGxlc2lvY2hyb25vdXMgRGlnaXRhbCBI aWVyYXJjaHkgDSAgICAgICAgICAgICAgICAgIChQREgpIFNpZ25hbHMiLCBJVFUtVCBSZWNvbW1l bmRhdGlvbiBHLjcwNDMsIEp1bHkgDSAgICAgICAgICAgICAgICAgIDIwMDQuIA0NICAgW0lUVS1U LUcuNzA3XSAgSW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNhdGlvbnMgVW5pb24sICJOZXR3b3Jr IE5vZGUgDSAgICAgICAgICAgICAgICAgIEludGVyZmFjZSBmb3IgdGhlIFN5bmNocm9ub3VzIERp Z2l0YWwgSGllcmFyY2h5IA0gICAgICAgICAgICAgICAgICAoU0RIKSIsIElUVS1UIFJlY29tbWVu ZGF0aW9uIEcuNzA3LCBEZWNlbWJlciAyMDAzLiANDSAgIFtJVFUtVC1HLjcwOV0gIEludGVybmF0 aW9uYWwgVGVsZWNvbW11bmljYXRpb25zIFVuaW9uLCAiSW50ZXJmYWNlcyANICAgICAgICAgICAg ICAgICAgZm9yIHRoZSBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3JrIChPVE4pIiwgSVRVLVQgDSAg ICAgICAgICAgICAgICAgIFJlY29tbWVuZGF0aW9uIEcuNzA5LCBNYXJjaCAyMDAzLiANDUF1dGhv cidzIEFkZHJlc3NlcyANDSAgIEdyZWcgQmVybnN0ZWluIA0gICBHcm90dG8gTmV0d29ya2luZyAN ICAgICAgIA0gICBQaG9uZTogKzEtNTEwLTU3My0yMjM3IA0gICBFbWFpbDogZ3JlZ2JAZ3JvdHRv LW5ldHdvcmtpbmcuY29tIA0gICAgDQ0gICBEaWVnbyBDYXZpZ2xpYSAgDSAgIEVyaWNzc29uIA0g ICBWaWEgQS4gTmVncm9uZSAxL0EgMTYxNTMgDSAgIEdlbm9hIEl0YWx5IA0gICAgDSAgIFBob25l OiArMzkgMDEwIDYwMCAzNzM2IA0gICBFbWFpbDogZGllZ28uY2F2aWdsaWFAKG1hcmNvbmkuY29t LCBlcmljc3Nvbi5jb20pICAgDSAgICANDSAgIFJpY2hhcmQgUmFiYmF0IA0gICBGdWppdHN1IExh Ym9yYXRvcmllcyBvZiBBbWVyaWNhIA0gICAxMjQwIEVhc3QgQXJxdWVzIEF2ZSwgTVMgMzQ1IA0g ICBTdW5ueXZhbGUsIENBIDk0MDg1IA0gICBVbml0ZWQgU3RhdGVzIG9mIEFtZXJpY2EgDSAgICAg ICANICAgUGhvbmU6ICsxIDQwOC01MzAtNDUzNyANICAgRW1haWw6IHJpY2hhcmRAdXMuZnVqaXRz dS5jb20gDSAgICANDQ0NDQ0NDSANIA1CZXJuc3RlaW4gICAgICAgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgNCwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDEzXSANDA1JbnRlcm5ldC1EcmFmdCAg ICBPcGVyYXRpbmcgVkNBVCBhbmQgTENBUyB3aXRoIEdNUExTICAgICAgICBBdWd1c3QgMjAwNiAN ICAgIA0NICAgSHV1YiB2YW4gSGVsdm9vcnQgDSAgIEh1YXdlaSBUZWNobm9sb2dpZXMsIEx0ZC4g DSAgIEtvbGtncmllbmQgMzgsIDEzNTYgQkMgQWxtZXJlIA0gICBUaGUgTmV0aGVybGFuZHMgDSAg ICANICAgUGhvbmU6ICAgKzMxIDM2IDUzMTUwNzYgDSAgIEVtYWlsOiAgIGhoZWx2b29ydEBodWF3 ZWkuY29tIA0NSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudCANDSAgIFRoZSBJRVRGIHRh a2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55IA0g ICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0 IGJlIGNsYWltZWQgdG8gDSAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBv ZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4gDSAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4 dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyANICAgbWlnaHQgb3Ig bWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFz IA0gICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmln aHRzLiAgSW5mb3JtYXRpb24gDSAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byBy aWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUgDSAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQ IDc5LiANDSAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNy ZXRhcmlhdCBhbmQgYW55IA0gICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZh aWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuIA0gICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEg Z2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YgDSAgIHN1Y2ggcHJv cHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzIA0gICBzcGVj aWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9z aXRvcnkgYXQgDSAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLiANDSAgIFRoZSBJRVRGIGludml0 ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkgDSAg IGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJv cHJpZXRhcnkgDSAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJl IHJlcXVpcmVkIHRvIGltcGxlbWVudCANICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNz IHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdCANICAgaWV0Zi1pcHJAaWV0Zi5vcmcuIA0N RGlzY2xhaW1lciBvZiBWYWxpZGl0eSANDSAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbiANICAgIkFTIElTIiBiYXNp cyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRT IA0gICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFO RCBUSEUgSU5URVJORVQgDSAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdB UlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwgDSAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlU RUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgDSAgIElORk9STUFUSU9OIEhF UkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEIA0gICBXQVJS QU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS UE9TRS4gDQ1Db3B5cmlnaHQgU3RhdGVtZW50IA0NICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMjAwNikuIA0NDSANIA1CZXJuc3RlaW4gICAgICAgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgNCwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDE0XSANDA1JbnRlcm5ldC1EcmFm dCAgICBPcGVyYXRpbmcgVkNBVCBhbmQgTENBUyB3aXRoIEdNUExTICAgICAgICBBdWd1c3QgMjAw NiANICAgIA0NICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vu c2VzIGFuZCByZXN0cmljdGlvbnMgDSAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQg YXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIA0gICByZXRhaW4gYWxsIHRoZWlyIHJp Z2h0cy4gDQ1BY2tub3dsZWRnbWVudCANDSAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1 bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUgDSAgIEludGVybmV0IFNvY2lldHku IA0NICAgIA0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NIA0gDUJlcm5zdGVp biAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA0LCAyMDA3ICAgICAgICAgICAgICAgW1Bh Z2UgMTVdIA0MDQVJcyB0aGUgdGVybSCRRml4ZWSSIHN5bm9ueW1vdXMgd2l0aCBuby1MQ0FTLiBJ ZiBzbyB0aGVuIHRoZXJlIGNhbiBiZSBubyCRZ3JhY2VmdWwgZGVncmFkYXRpb26SIGluIHRoZSBG aXhlZCwgZGl2ZXJzZWx5LXJvdXRlZCBzY2VuYXJpby4gSW4gZmFjdCB0aGlzIGFwcGxpZXMgYWxz byB0byB0aGUgRml4ZWQsIGNvLXJvdXRlZCBzY2VuYXJpby4NR3JhY2VmdWwgZGVncmFkYXRpb24g aXMgbW9yZSBhcHBsaWNhYmxlIHRvIHRoZSBkeW5hbWljIHNjZW5hcmlvczsgYWx0aG91Z2ggSSBi ZWxpZXZlIGl0IGFwcGxpZXMgbW9yZSB0byB0aGUgZGl2ZXJzZWx5IJZyb3V0ZWQgc2NlbmFyaW8u DQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAADwgAACMIAAArCAAA 1wgAANoIAADbCAAA3AgAAOcIAADoCAAA6QgAAOoIAAD5CAAAAwkAAAUJAAATCQAAFAkAACcJAAAw CQAAQAkAAEEJAACACQAAgQkAACUKAAAnCgAAmQoAAJ4KAACtCgAAsAoAALUKAADUCgAAcQsAAHIL AACdCwAA7wwAAPjw+Ojg+NXGu7C7qLucu/i7lLv4u+C7jOCE4ITghHxuZlsAAAAAAAAAABQVaJo2 kQAWaJd1XwBtSAkIc0gJCAAOFmiXdV8AbUgJCHNICQgAGwEIgQRIAQAFaA2EqGYWaGMiUABtSAkI c0gJCA4WaO83VwBtSAkIc0gJCAAOFmhjIlAAbUgJCHNICQgADhZoKHSjAG1ICQhzSAkIAA4WaAdw gQBtSAkIc0gJCAAXFWgHcIEAFmgodKMAPioBbUgJCHNICQgOFmg3GnIAbUgJCHNICQgAFBVo3RO5 ABZoN23qAG1ICQhzSAkIABQVaN0TuQAWaCh0owBtSAkIc0gJCAAdFWjdE7kAFmgodKMANQiBPioB XAiBbUgJCHNICQgUFWgEcCIAFmgEcCIAbUgJCHNICQgADhZo3EtyAG1ICQhzSAkIAA4WaNJgegBt SAkIc0gJCAAOFmipEqkAbUgJCHNICQgADhZoBHAiAG1ICQhzSAkIIgAGAAAICAAACQgAANsIAADc CAAA6QgAAOoIAAANCQAADgkAAIIJAACDCQAAJgoAACcKAAByCwAAnAsAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAAChAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAQyQBRcaAAAABAA2EqGYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJd1XwAABAAAZ2Rj IlAAAAQAAGdkKHSjAAAEAABnZAdwgQAABAAAZ2TSYHoAAAEAAAAOAAYAAIuOAADZjwAA/v4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQKcCwAAnQsAAN8LAAAoDAAAcQwA ALsMAAD/DAAARw0AAIANAACBDQAAxA0AAAkOAABRDgAA2Q4AANoOAADbDgAA5Q4AAOYOAAAnDwAA KA8AALkAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0 AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAA AAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAK8AAAAAAAAAAAAA AAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAKoAAAAAAAAAAAAAAACqAAAAAAAAAAAAAAAAqgAA AAAAAAAAAAAAAKoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAGdkKHSjAAAEAABnZNNygAAA BAAAZ2SXdV8ARgAARcaAAAABAA2EqGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJd1XwAAE+8MAABADQAAfg0AAH8NAACADQAA gQ0AAHcOAAB4DgAA2A4AANsOAADlDgAAJg8AACgPAAApDwAANw8AADgPAABLDwAAVA8AAKUPAACt DwAAcBAAAIwRAABAEgAAQRIAAOHWzsbO1riqzpuQiIBxZltTW1NbSD1TAAAAFBVo3RO5ABZorFsq AG1ICQhzSAkIABQVaN0TuQAWaI5QPwBtSAkIc0gJCAAOFmgOSJAAbUgJCHNICQgAFBVo3RO5ABZo 7H3PAG1ICQhzSAkIABQVaN0TuQAWaJo2kQBtSAkIc0gJCAAdFWjdE7kAFmiaNpEANQiBPioBXAiB bUgJCHNICQgOFmiaNpEAbUgJCHNICQgADhZoKHSjAG1ICQhzSAkIABQVaN0TuQAWaCh0owBtSAkI c0gJCAAdFWjdE7kAFmgodKMANQiBPioBXAiBbUgJCHNICQgbAQiBBEgBAAVoFISoZhZo03KAAG1I CQhzSAkIGwEIgQRIAQAFaBOEqGYWaJd1XwBtSAkIc0gJCA4WaGMiUABtSAkIc0gJCAAOFmiXdV8A bUgJCHNICQgAFBVomjaRABZol3VfAG1ICQhzSAkIADsACIEVaJo2kQAWaJd1XwAXaJd1XwBjSAEA Y0gAAGNIAQBkaAAAAABkaAAAAABkaBOEqGZtSAkIc0gJCAAXKA8AACkPAAA3DwAAOA8AAG8QAABw EAAAbxEAAHARAACMEQAAjREAAK0RAACuEQAA2BEAAAwSAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADw AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAA AAAAAAAAAOsAAAAAAAAAAAAAAAChAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABJAAAKJgALRgYARcaAAQABABOEqGYAAAAAAAAAAAAXFxcXFxcXFxcA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAbwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKxbKgAABAAAZ2Ss WyoAAAQAAGdkjlA/AAAEAABnZA5IkAAABAAAZ2QodKMAAA0MEgAAYxIAAGQSAACGEgAAhxIAADAT AAAxEwAAeRMAAHoTAAC+EwAAvxMAAPITAAC1AAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAAGYAAAAA AAAAAAAAAACwAAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAACwAAAAAAAAAAAA AAAAsAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAACwAAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAASQAACiYDC0YFAEXGgAEAAQAThKhmAQMFBwAAAAAAAAAAAAAAAAAAAAAEAAAA AQAAAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAALgABAC4AAgAuAAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2SsWyoAAAQAAGdkrFsqAABJ AAAKJgALRgYARcaAAQABABOEqGYAAAAAAAAAAAAXFxcXFxcXFxcAAAIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKxbKgAAC/ITAADzEwAAPRQAAIEUAABEFQAAdhUA AHcVAAC8FQAABhYAACUWAAAmFgAAcRYAAHIWAABzFgAAdBYAAHUWAAC/FgAACBcAAFEXAACaFwAA 4xcAACwYAAB2GAAAwBgAAAkZAAAuGQAAMBkAAFcZAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADp AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAA AAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAA AADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEAAAEA AAAEAABnZI5QPwAABAAAZ2QOSJAAAAQAAGdkrFsqAAAbQRIAAKkUAADJFAAAAxUAAAUVAABDFQAA bxYAAHEWAAByFgAAcxYAAHQWAAB2FgAA4zcAAOQ3AADVOQAACDoAABk6AAAoOgAAMjoAADU6AAD8 QAAA/UAAANdKAADvSgAAG0sAABxLAABOSwAA9e3i7eL12s/ax7+0qLSajH6afrRwtGJURlQAAAAA AAAbAQiBBEgBAAVo63uoRhZo+HDcAG1ICQhzSAkIGwEIgQRIAQAFaOV7qEYWaPhw3ABtSAkIc0gJ CBsBCIEESAEABWjke6hGFmj4cNwAbUgJCHNICQgbAQiBBEgBAAVoAXuoRhZoxSQLAG1ICQhzSAkI GwEIgQRIAQAFaAyEqGYWaJd1XwBtSAkIc0gJCBsBCIEESAEABWgLhKhmFmiXdV8AbUgJCHNICQgb AQiBBEgBAAVoCoSoZhZol3VfAG1ICQhzSAkIFgNqAAAAABZoxSQLADBKFgA8CIFVCAEAFBVomjaR ABZomjaRAG1ICQhzSAkIAA4WaJo2kQBtSAkIc0gJCAAOFmiOUD8AbUgJCHNICQgAFBVomjaRABZo rFsqAG1ICQhzSAkIAA4WaKxbKgBtSAkIc0gJCAAUFWjdE7kAFmgOSJAAbUgJCHNICQgADhZoDkiQ AG1ICQhzSAkIABQVaN0TuQAWaKxbKgBtSAkIc0gJCBpXGQAAnBkAAOIZAAASGgAATxoAAFAaAABR GgAAZhoAAGcaAACwGgAA+hoAAEUbAACQGwAAnRsAAJ4bAADkGwAAKRwAAGwcAAB4HAAAeRwAAMMc AAAMHQAATx0AAI4dAACPHQAAyh0AAP4dAAD/HQAARB4AAG0eAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAAAAAAAEAABnZJo2kQAAHW0eAABuHgAApx4AAKgeAACuHgAArx4AALke AAC6HgAABB8AAEwfAABOHwAAUB8AAFIfAACbHwAAnR8AAOYfAADrHwAA7B8AADMgAAB6IAAAvCAA AAIhAABGIQAAjiEAAJshAACcIQAAvyEAAMAhAAAIIgAAUSIAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQAAGdkmjaRAAAdUSIAAJgiAACZIgAArCIAAK0iAACyIgAA+iIA AEIjAACKIwAA0iMAABokAABiJAAAqiQAAPIkAAA6JQAAgiUAAMolAAASJgAAWiYAAKImAADqJgAA MicAAHMnAAC7JwAAAigAAEooAACSKAAA2igAACIpAABqKQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEAAB1qKQAAsikAAPopAABCKgAAiioAANIqAAAaKwAA HCsAAB4rAABnKwAAaSsAALIrAAC3KwAAuCsAAAAsAABILAAAkCwAANgsAADdLAAA7iwAAO8sAAAz LQAAdS0AAJ0tAACeLQAA5y0AAC8uAAB3LgAAwS4AANYuAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEAABnZJo2kQAAHdYuAADXLgAAES8AABIvAAAsLwAALS8AAEcvAABI LwAAki8AAJMvAADJLwAAyi8AAOovAADrLwAAHTAAAB4wAABhMAAAnzAAAOYwAAAsMQAAOTEAADox AABpMQAAajEAALQxAAD4MQAAQDIAAIQyAACRMgAAkjIAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAAAAAAAAQAAGdkmjaRAAAdkjIAAJMyAACUMgAAljIAAJgyAADhMgAA4zIAACwz AAAxMwAAMjMAAGQzAABlMwAAqDMAAO8zAAAwNAAAZzQAAGg0AACuNAAA+DQAAEI1AACKNQAA1DUA APk1AAD6NQAAQjYAAIs2AADUNgAAHjcAAGI3AACqNwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEAAB2qNwAA5TcAAOY3AAAuOAAAbzgAALM4AADXOAAA2DgA ACE5AABmOQAArjkAADY6AAA3OgAAYToAAGI6AACnOgAA7joAADA7AAB6OwAAwTsAAAI8AAARPAAA EjwAAD88AABAPAAAhjwAANA8AAARPQAAEz0AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAGdkl3VfAAAEAABnZJo2kQAAHBM9AAAVPQAAXj0AAGA9AACpPQAArj0AAK89AADwPQAA KD4AACk+AABzPgAAvT4AAM8+AADQPgAA6D4AAOk+AAAoPwAAKT8AAHM/AAC7PwAA/D8AAP0/AABD QAAAikAAAKFAAACiQAAA6kAAADFBAABIQQAASUEAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQAAGdkmjaRAAAdSUEAAHRBAAB1QQAAuEEAALlBAAD+QQAARkIAAEdCAACK QgAA0UIAAOtCAADsQgAAM0MAAHNDAAC8QwAABEQAAE1EAABzRAAAdEQAAKJEAACjRAAA6UQAADFF AAAyRQAAM0UAADVFAAA3RQAAgEUAAIJFAADLRQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAAAAAAABAAAZ2SaNpEAAB3LRQAA0EUAANFFAAAaRgAAYUYAAKhGAADsRgAA7UYAADdH AAB/RwAAx0cAAA1IAAA+SAAAP0gAAIRIAADMSAAAEkkAAFZJAACeSQAA5UkAAABKAAABSgAASkoA AI9KAADPSgAA0EoAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAEAABnZJo2kQAAGdBKAADwSgAA8UoAABtLAABjSwAAuQAAAAAAAAAAAAAAAHEA AAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAAAAAAABLAAAKJgALRgYAQyQBRcaA AAABAOZ7qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABnZPhw3AAARwAAQyQBRcaAAAABAOV7qEYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZPhw3ABGAABFxoAA AAEA5HuoRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGdk+HDcAAAETksAAGJLAABjSwAAbEsAAH9LAACSSwAArEsAAMNLAADaSwAA 20sAANxLAADnSwAA7EsAAPBLAADxSwAAAkwAABRMAAAVTAAAh0wAAL5MAAC/TAAA8ePV48fxueO5 46ughqB4XlB4QjQbAQiBBEgBAAVo6XuoRhZo+HDcAG1ICQhzSAkIGwEIgQRIAQAFaBV8qEYWaEoa 3wBtSAkIc0gJCBsBCIEESAEABWjoe6hGFmiaNpEAbUgJCHNICQgzAAiBFWiaNpEAFmiaNpEAF2j4 cNwAY0gBAGRoAAAAAGRoAAAAAGRo6HuoRm1ICQhzSAkIGwEIgQRIAQAFaOh7qEYWaPhw3ABtSAkI c0gJCDMACIEVaJo2kQAWaJo2kQAXaPhw3ABjSAEAZGgAAAAAZGgAAAAAZGjne6hGbUgJCHNICQgU FWiaNpEAFmiaNpEAbUgJCHNICQgAGwEIgQRIAQAFaOd7qEYWaPhw3ABtSAkIc0gJCBsBCIEESAEA BWgEhKhmFmjFV0cAbUgJCHNICQgbAQiBBEgBAAVo7HuoRhZo+HDcAG1ICQhzSAkIGwEIgQRIAQAF aOt7qEYWaPhw3ABtSAkIc0gJCBsBCIEESAEABWjme6hGFmj4cNwAbUgJCHNICQgbAQiBBEgBAAVo A4SoZhZoxVdHAG1ICQhzSAkIABRjSwAA3EsAAN1LAAAVTAAAtAAAAAAAAAAAAAAAAGwAAAAAAAAA AAAAAAAhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABLAAAKJgMLRgUAQyQBRcaAAAABAOd7qEYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABnZPhw3AAARwAAQyQBRcaAAAABAOd7qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZPhw3ABLAAAKJgALRgYAQyQBRcaAAAAB AOZ7qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABnZMVXRwAAAxVMAAAWTAAAv0wAAMBMAAAITQAACU0AALcAAAAAAAAAAAAAAAC3 AAAAAAAAAAAAAAAAbwAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABHAABDJAFFxoAAAAEA6XuoRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdk+HDcAABHAABDJAFFxoAAAAEA 6HuoRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGdk+HDcAAAFv0wAAMBMAAAOTQAATE0AAE1NAACATQAAgU0AADhOAABYTgAAkk4A AJROAADSTgAA1E4AALZPAAC4TwAAxE8AAMVPAAACUAAA8ePVx7muo5uNf3FXo0k7LTsAGwEIgQRI AQAFaBp8qEYWaEoa3wBtSAkIc0gJCBsBCIEESAEABWgZfKhGFmhKGt8AbUgJCHNICQgbAQiBBEgB AAVoBXyoRhZofU6xAG1ICQhzSAkIMwAIgRVomjaRABZomjaRABdoDkiQAGNIAQBkaAAAAABkaAAA AABkaPqCqGZtSAkIc0gJCBsBCIEESAEABWj6gqhmFmgOSJAAbUgJCHNICQgbAQiBBEgBAAVo+YKo ZhZoDkiQAG1ICQhzSAkIGwEIgQRIAQAFaAR8qEYWaA5IkABtSAkIc0gJCA4WaA5IkABtSAkIc0gJ CAAUFWiaNpEAFmiaNpEAbUgJCHNICQgAFBVomjaRABZo+HDcAG1ICQhzSAkIABsBCIEESAEABWjr e6hGFmj4cNwAbUgJCHNICQgbAQiBBEgBAAVo6nuoRhZo+HDcAG1ICQhzSAkIGwEIgQRIAQAFaBZ8 qEYWaEoa3wBtSAkIc0gJCBsBCIEESAEABWjpe6hGFmj4cNwAbUgJCHNICQgbAQiBBEgBAAVo6Huo RhZo+HDcAG1ICQhzSAkIABEJTQAATU0AAE5NAACBTQAAtwAAAAAAAAAAAAAAAG8AAAAAAAAAAAAA AAAnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAQyQBRcaAAAABAOp7qEYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABnZPhw3AAARwAAQyQBRcaAAAABAOt7qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZPhw3AAARwAAQyQBRcaAAAABAOl7 qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABnZEoa3wAAA4FNAACCTQAAzE0AABBOAADVTgAACE8AAAlPAABOTwAAmE8AALdPAAC4 TwAAKlAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAK0AAAAAAAAAAAAAAABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAQyQBRcaA AAABAAV8qEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABnZEoa3wAARwAAQyQBRcaAAAABAAV8qEYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJo2kQAABAAAZ2QO SJAAAAQAAGdkmjaRAAALKlAAAG9QAACtUAAA8lAAADZRAAB8UQAAiFEAAIlRAACKUQAAwlEAAMNR AAAKUgAAUVIAAJlSAADeUgAAJ1MAAClTAAArUwAAdFMAAHZTAAC/UwAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAAsgAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAQyQBRcaAAAABAAh8qEYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJo2 kQAABAAAZ2SaNpEAABQCUAAAh1EAAIhRAACJUQAA5VoAAOZaAAAWWwAAMlsAADNbAACLjgAAjI4A ANiPAADZjwAA2o8AAOXXzMGzpZeMwYJ+esEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhZoPCxjAAAGFmgHcIEAABMDagAAAAAWaAdw gQAwShYAVQgBFBVomjaRABZorFsqAG1ICQhzSAkIABsBCIEESAEABWglfKhGFmipWO8AbUgJCHNI CQgbAQiBBEgBAAVoJHyoRhZorFsqAG1ICQhzSAkIGwEIgQRIAQAFaCR8qEYWaJo2kQBtSAkIc0gJ CBQVaJo2kQAWaJo2kQBtSAkIc0gJCAAUFWiaNpEAFmgxZSgAbUgJCHNICQgAGwEIgQRIAQAFaAZ8 qEYWaJo2kQBtSAkIc0gJCDMACIEVaJo2kQAWaJo2kQAXaEoa3wBjSAEAZGgAAAAAZGgAAAAAZGga fKhGbUgJCHNICQgADb9TAADEUwAAxVMAAAxUAAArVAAALFQAAF9UAABgVAAAplQAAOpUAAANVQAA DlUAACxVAAAtVQAAdlUAALVVAAC2VQAA1VUAANZVAAAbVgAAXVYAAF5WAACnVgAA7lYAADRXAAB8 VwAAw1cAAA1YAABPWAAAllgAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAQAAGdkmjaRAAAdllgAANtYAAAkWQAATlkAAE9ZAACWWQAAxlkAAMdZAAD0WQAA9VkAAD5aAACA WgAAx1oAAOZaAADnWgAAM1sAADRbAAB+WwAAxlsAAAtcAABVXAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACyAAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAQyQBRcaAAAABACR8qEYAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJo2kQAA BAAAZ2SaNpEAABRVXAAAn1wAAOdcAADpXAAA61wAADRdAAA2XQAAf10AAIRdAACFXQAAy10AABBe AAAdXgAAHl4AAGheAACuXgAA+F4AADxfAACEXwAAzl8AABVgAABeYAAAqGAAAOpgAAArYQAALGEA AHNhAACjYQAApGEAAOthAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAE AABnZJo2kQAAHethAAAXYgAAGGIAAGJiAACrYgAA9WIAADVjAAB4YwAAwmMAAApkAAAfZAAAIGQA AD9kAABAZAAAYmQAAIRkAACFZAAArWQAAK5kAAD2ZAAAEmUAABNlAABWZQAAV2UAAJ1lAADmZQAA MGYAAG9mAABxZgAAc2YAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQA AGdkmjaRAAAdc2YAALxmAAC+ZgAAB2cAAAxnAAANZwAAVWcAAJ9nAADhZwAA7mcAAO9nAAA0aAAA Q2gAAERoAACOaAAA2GgAAAlpAAAKaQAAUWkAAHppAAB7aQAAwGkAAApqAABUagAAfmoAAH9qAACq agAAq2oAAO5qAAAvawAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABAAA Z2SaNpEAAB0vawAAb2sAALlrAAD5awAAQGwAAFNsAABUbAAAnmwAAOdsAAAvbQAAPG0AAD1tAABZ bQAAWm0AAKBtAADgbQAAJ24AAGhuAACobgAAqW4AAKpuAACrbgAArG4AAK1uAACvbgAAsW4AAPpu AAD8bgAARW8AAEpvAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEAABn ZJo2kQAAHUpvAABLbwAAY28AAGRvAACtbwAA9m8AAAVwAAAGcAAAQ3AAAERwAABgcAAAYXAAAKZw AADtcAAAMXEAAHtxAADEcQAADXIAAFdyAABvcgAAcHIAALhyAADMcgAAzXIAAM5yAADPcgAA0HIA ANFyAADScgAA03IAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQAAGdk mjaRAAAd03IAANRyAADVcgAA1nIAANdyAADYcgAA2XIAANpyAADbcgAA3HIAAN1yAADecgAA33IA AOByAADhcgAA4nIAAONyAADkcgAA5XIAAOZyAADocgAA6nIAADNzAAA1cwAAfnMAAINzAACEcwAA lXMAAJZzAACwcwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABAAAZ2Sa NpEAAB2wcwAA4nMAAOxzAADxcwAAC3QAADR0AAA5dAAAS3QAAF50AAB6dAAAknQAAJ10AACidAAA wHQAAOd0AADsdAAA/HQAAAZ1AAAWdQAALnUAAEt1AABQdQAAa3UAAIZ1AACLdQAAkHUAAKR1AACl dQAA73UAACZ2AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEAABnZJo2 kQAAHSZ2AAAndgAAKHYAACl2AAAqdgAAK3YAACx2AAAtdgAALnYAAC92AAAwdgAAMXYAADJ2AAAz dgAANHYAADV2AAA3dgAAOXYAAIJ2AACEdgAAzXYAANJ2AADTdgAA4nYAAON2AAD+dgAA/3YAAEZ3 AACMdwAAjXcAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQAAGdkmjaR AAAdjXcAANV3AAAYeAAAW3gAAH54AAB/eAAAyHgAABB5AABKeQAAS3kAAIx5AADQeQAAF3oAAEJ6 AABDegAAinoAAM16AAAUewAAXXsAAIl7AACKewAA03sAABN8AABZfAAAoXwAALp8AAC7fAAA2HwA ANl8AAAgfQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEA AB0gfQAAaX0AALJ9AADVfQAA1n0AACB+AABlfgAArn4AAK9+AACwfgAAsX4AALJ+AAC0fgAAtn4A AP9+AAABfwAASn8AAE9/AABQfwAAlH8AANl/AAAegAAAN4AAADiAAACBgAAAxIAAAAqBAAALgQAA UoEAAJWBAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEAABnZJo2kQAA HZWBAADKgQAAy4EAAN+BAADggQAA84EAAAmCAAARggAALIIAAFOCAABYggAAWYIAAG2CAAB6ggAA l4IAAKeCAACsggAAyIIAAACDAAAFgwAABoMAABmDAAA9gwAAXoMAAHaDAACTgwAAm4MAALaDAADY gwAA3YMAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQAAGdkmjaRAAAd 3YMAAN6DAADfgwAA4IMAAOGDAADigwAA44MAAOSDAADmgwAA6IMAADGEAAAzhAAAfIQAAIGEAACC hAAAmIQAALaEAADYhAAA7IQAAPGEAAANhQAAL4UAADCFAABRhQAAUoUAAJiFAADihQAAKoYAAHGG AAC4hgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEAAB24 hgAAAocAAEeHAABnhwAAaIcAAKuHAADwhwAAOogAAHeIAADBiAAA3ogAAN+IAAAniQAAbIkAALOJ AAD1iQAADIoAAA2KAAAligAAJooAAHCKAAC6igAAAYsAAEmLAACLiwAAzosAABWMAAAWjAAAK4wA ACyMAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEAABnZJo2kQAAHSyM AABbjAAAXIwAAF2MAABfjAAAYYwAAKqMAACsjAAA9YwAAPqMAAD7jAAAQY0AAIeNAACkjQAApY0A ALWNAAC2jQAA+40AABGOAAASjgAAF44AABiOAAAZjgAAGo4AABuOAAAcjgAAHY4AAB6OAAAfjgAA II4AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQAAGdkmjaRAAAdII4A ACGOAAAijgAAI44AACSOAAAljgAAJo4AACeOAAAojgAAKY4AACqOAAArjgAALI4AAC2OAAAujgAA L44AADCOAAAxjgAAMo4AADOOAAA0jgAANY4AADaOAAA3jgAAOI4AADmOAAA6jgAAO44AADyOAAA+ jgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABAAAZ2SaNpEAAB0+jgAA QI4AAImOAACLjgAAUI8AANiPAADZjwAA2o8AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPgAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABBcAZ2TFJAsAAAEXAAAEAABnZJo2kQAAByAAMZBo AR+w0C8gsOA9IbAIByKwCAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAGgASAAEAnAAPAAMA AAADAAAAAABMAABA8f8CAEwADAAAAAAAAAAAAAoATgBvAHIAbQBhAGwALABOAGUAdwAAAAIAAAAc AENKGABfSA0EYUoYAG1ICQRuSAQIc0gJBHRIBAhaAAFAAQACAFoADAAAALQp+AAAAAkASABlAGEA ZABpAG4AZwAgADEAAAAQAAEABiQBE6TwABSkPABAJgAeADUIgUNKIABLSCAAT0oCAFFKAgBcCIFe SgIAYUogAFwAAkABAAIAXAAMAAAAtCn4AAAACQBIAGUAYQBkAGkAbgBnACAAMgAAABAAAgAGJAET pPAAFKQ8AEAmASAANQiBNgiBQ0ocAE9KAgBRSgIAXAiBXQiBXkoCAGFKHABWAANAAQACAFYADAAA ALQp+AAAAAkASABlAGEAZABpAG4AZwAgADMAAAAQAAMABiQBE6TwABSkPABAJgIaADUIgUNKGgBP SgIAUUoCAFwIgV5KAgBhShoASgAEQAEAAgBKAAwAAAC0KfgAAAAJAEgAZQBhAGQAaQBuAGcAIAA0 AAAAEAAEAAYkAROk8AAUpDwAQCYDDgA1CIFDShwAXAiBYUocAAAAAAAAAAAAAABEAEFA8v+hAEQA DAEAAAAAAAAAABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAA AAAAUgBpQPP/swBSAAwBAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMA ADTWBgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABrQPT/wQAoAAABAAAAAAAAAAAHAE4AbwAg AEwAaQBzAHQAAAACAAAAAAAAAJYA/k8RAAIAlgAMAAAAtCn4AAAACwBBAG4AbgBlAHgAXwBUAGkA dABsAGUAAAA1AA8AAyQBBSQBByQBCiYAC0YEAA3GBQAB0AIGD4TQAhGEmP4TpFAAFKQUAF6E0AJg hJj+YSQBAC8AQ0oYAEtIAABPSgAAUEoAAFFKAABcCIFeSgAAX0gBBGFKFABtSAkIc0gJCHRICQQA nAD+TyEAAgGcAAwAAAC0KfgAAAAMAEEAbgBuAGUAeABfAFQAaQB0AGwAZQAxAAAANwAQAAMkAwUk AQomAQtGBAANxgcBaAEBoAUGD4SgBRGEmP4TpDkBFKQAAEAmCV6EoAVghJj+YSQDADEANgiBQ0oW AE9KAABQSgAAUUoAAFwIgV0IgV5KAABfSAEEYUoUAG1ICQhzSAkIdEgJBACWAP5PMQASAZYADAAA ALQp+AAAAAwAQQBuAG4AZQB4AF8AVABpAHQAbABlADIAAAA3ABEAAyQDBSQBCiYCC0YEAA3GBwHQ AgFwCAYPhHAIEYSY/hOktQAUpAAAQCYJXoRwCGCEmP5hJAMAKwBDShQAT0oAAFBKAABRSgAAXAiB XkoAAF9IAQRhShQAbUgJCHNICQh0SAkEAIoA/k9BACIBigAMAAAAtCn4AAAADABBAG4AbgBlAHgA XwBUAGkAdABsAGUAMwAAADcAEgADJAMFJAEKJgMLRgQADcYHAdACAUALBg+EQAsRhJj+E6S1ABSk AABAJglehEALYISY/mEkAwAfAENKFABQSgAAXAiBX0gBBGFKFABtSAkIc0gJCHRICQQAdgD+TwEA MgF2AAwAAAClXdYAAAAIAFIAZQBxACcAbQBlAG4AdAAAAC4AEwANxgUAAW4EwA+EpQYRhJL7E6R4 ADUkADckADgkADlEAgBIJABehKUGYISS+x4ANQiBUEoAAFwIgV9IAQRhShQAbUgJCHNICQh0SAkE igD+TwEAQgGKAAwAAACTCZEAAAAQAFIAZQBxACcAbQBlAG4AdABfAEkAbgBkAGUAbgB0ADEAAAAx ABQADcYIAAJuBKUGwMAPhKUGEYTJ/ROkeAA1JAA3JAA4JAA5RAIASCQAXoSlBmCEyf0AHgA1CIFQ SgAAXAiBX0gBBGFKFABtSAkIc0gJCHRICQR8AP5PAQBSAXwADAAAAJMJkQAAABAAUgBlAHEAJwBt AGUAbgB0AF8ASQBuAGQAZQBuAHQAMgAAACYAFQANxgUAAdwIwA+EpQYTpHgANSQANyQAOCQAOUQC AEgkAF6EpQYbADUIgVBKAABfSAEEYUoUAG1ICQhzSAkIdEgJBABCACdAogBhAUIADAEAAMUkCwAA ABEAQwBvAG0AbQBlAG4AdAAgAFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShAAYUoQADwAHkABAHIB PAAMAQAAxSQLAAAADABDAG8AbQBtAGUAbgB0ACAAVABlAHgAdAAAAAIAFwAIAENKFABhShQAQABq QHEBcgFAAAwBAADFJAsAAAAPAEMAbwBtAG0AZQBuAHQAIABTAHUAYgBqAGUAYwB0AAAAAgAYAAYA NQiBXAiBSACZQAEAkgFIAAwBAADFJAsAAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAAAgAZ ABQAQ0oQAE9KBABRSgQAXkoEAGFKEAANAFQAcgBlAHYAbwByACAAVwBpAGwAcwBvAG4A4y8AANqH AAACAFQAVwAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////3eqhGAAAAAAAAAAAAAAAAAAAAAAAATQEA AFABAAAAAAAA2ocAAAwAAOwAAAoA/////wAAAAAIAAAACQAAANsAAADcAAAA6QAAAOoAAAANAQAA DgEAAIIBAACDAQAAJgIAACcCAAByAwAAnAMAAJ0DAADfAwAAKAQAAHEEAAC7BAAA/wQAAEcFAACA BQAAgQUAAMQFAAAJBgAAUQYAANkGAADaBgAA2wYAAOUGAADmBgAAJwcAACgHAAApBwAANwcAADgH AABvCAAAcAgAAG8JAABwCQAAjAkAAI0JAACtCQAArgkAANgJAAAMCgAAYwoAAGQKAACGCgAAhwoA ADALAAAxCwAAeQsAAHoLAAC+CwAAvwsAAPILAADzCwAAPQwAAIEMAABEDQAAdg0AAHcNAAC8DQAA Bg4AACUOAAAmDgAAcQ4AAHIOAABzDgAAdA4AAHUOAAC/DgAACA8AAFEPAACaDwAA4w8AACwQAAB2 EAAAwBAAAAkRAAAuEQAAMBEAAFcRAACcEQAA4hEAABISAABPEgAAUBIAAFESAABmEgAAZxIAALAS AAD6EgAARRMAAJATAACdEwAAnhMAAOQTAAApFAAAbBQAAHgUAAB5FAAAwxQAAAwVAABPFQAAjhUA AI8VAADKFQAA/hUAAP8VAABEFgAAbRYAAG4WAACnFgAAqBYAAK4WAACvFgAAuRYAALoWAAAEFwAA TBcAAE4XAABQFwAAUhcAAJsXAACdFwAA5hcAAOsXAADsFwAAMxgAAHoYAAC8GAAAAhkAAEYZAACO GQAAmxkAAJwZAAC/GQAAwBkAAAgaAABRGgAAmBoAAJkaAACsGgAArRoAALIaAAD6GgAAQhsAAIob AADSGwAAGhwAAGIcAACqHAAA8hwAADodAACCHQAAyh0AABIeAABaHgAAoh4AAOoeAAAyHwAAcx8A ALsfAAACIAAASiAAAJIgAADaIAAAIiEAAGohAACyIQAA+iEAAEIiAACKIgAA0iIAABojAAAcIwAA HiMAAGcjAABpIwAAsiMAALcjAAC4IwAAACQAAEgkAACQJAAA2CQAAN0kAADuJAAA7yQAADMlAAB1 JQAAnSUAAJ4lAADnJQAALyYAAHcmAADBJgAA1iYAANcmAAARJwAAEicAACwnAAAtJwAARycAAEgn AACSJwAAkycAAMknAADKJwAA6icAAOsnAAAdKAAAHigAAGEoAACfKAAA5igAACwpAAA5KQAAOikA AGkpAABqKQAAtCkAAPgpAABAKgAAhCoAAJEqAACSKgAAkyoAAJQqAACWKgAAmCoAAOEqAADjKgAA LCsAADErAAAyKwAAZCsAAGUrAACoKwAA7ysAADAsAABnLAAAaCwAAK4sAAD4LAAAQi0AAIotAADU LQAA+S0AAPotAABCLgAAiy4AANQuAAAeLwAAYi8AAKovAADlLwAA5i8AAC4wAABvMAAAszAAANcw AADYMAAAITEAAGYxAACuMQAANjIAADcyAABhMgAAYjIAAKcyAADuMgAAMDMAAHozAADBMwAAAjQA ABE0AAASNAAAPzQAAEA0AACGNAAA0DQAABE1AAATNQAAFTUAAF41AABgNQAAqTUAAK41AACvNQAA 8DUAACg2AAApNgAAczYAAL02AADPNgAA0DYAAOg2AADpNgAAKDcAACk3AABzNwAAuzcAAPw3AAD9 NwAAQzgAAIo4AAChOAAAojgAAOo4AAAxOQAASDkAAEk5AAB0OQAAdTkAALg5AAC5OQAA/jkAAEY6 AABHOgAAijoAANE6AADrOgAA7DoAADM7AABzOwAAvDsAAAQ8AABNPAAAczwAAHQ8AACiPAAAozwA AOk8AAAxPQAAMj0AADM9AAA1PQAANz0AAIA9AACCPQAAyz0AANA9AADRPQAAGj4AAGE+AACoPgAA 7D4AAO0+AAA3PwAAfz8AAMc/AAANQAAAPkAAAD9AAACEQAAAzEAAABJBAABWQQAAnkEAAOVBAAAA QgAAAUIAAEpCAACPQgAAz0IAANBCAADwQgAA8UIAABtDAABjQwAA3EMAAN1DAAAVRAAAFkQAAL9E AADARAAACEUAAAlFAABNRQAATkUAAIFFAACCRQAAzEUAABBGAADVRgAACEcAAAlHAABORwAAmEcA ALdHAAC4RwAAKkgAAG9IAACtSAAA8kgAADZJAAB8SQAAiEkAAIlJAACKSQAAwkkAAMNJAAAKSgAA UUoAAJlKAADeSgAAJ0sAAClLAAArSwAAdEsAAHZLAAC/SwAAxEsAAMVLAAAMTAAAK0wAACxMAABf TAAAYEwAAKZMAADqTAAADU0AAA5NAAAsTQAALU0AAHZNAAC1TQAAtk0AANVNAADWTQAAG04AAF1O AABeTgAAp04AAO5OAAA0TwAAfE8AAMNPAAANUAAAT1AAAJZQAADbUAAAJFEAAE5RAABPUQAAllEA AMZRAADHUQAA9FEAAPVRAAA+UgAAgFIAAMdSAADmUgAA51IAADNTAAA0UwAAflMAAMZTAAALVAAA VVQAAJ9UAADnVAAA6VQAAOtUAAA0VQAANlUAAH9VAACEVQAAhVUAAMtVAAAQVgAAHVYAAB5WAABo VgAArlYAAPhWAAA8VwAAhFcAAM5XAAAVWAAAXlgAAKhYAADqWAAAK1kAACxZAABzWQAAo1kAAKRZ AADrWQAAF1oAABhaAABiWgAAq1oAAPVaAAA1WwAAeFsAAMJbAAAKXAAAH1wAACBcAAA/XAAAQFwA AGJcAACEXAAAhVwAAK1cAACuXAAA9lwAABJdAAATXQAAVl0AAFddAACdXQAA5l0AADBeAABvXgAA cV4AAHNeAAC8XgAAvl4AAAdfAAAMXwAADV8AAFVfAACfXwAA4V8AAO5fAADvXwAANGAAAENgAABE YAAAjmAAANhgAAAJYQAACmEAAFFhAAB6YQAAe2EAAMBhAAAKYgAAVGIAAH5iAAB/YgAAqmIAAKti AADuYgAAL2MAAG9jAAC5YwAA+WMAAEBkAABTZAAAVGQAAJ5kAADnZAAAL2UAADxlAAA9ZQAAWWUA AFplAACgZQAA4GUAACdmAABoZgAAqGYAAKlmAACqZgAAq2YAAKxmAACtZgAAr2YAALFmAAD6ZgAA /GYAAEVnAABKZwAAS2cAAGNnAABkZwAArWcAAPZnAAAFaAAABmgAAENoAABEaAAAYGgAAGFoAACm aAAA7WgAADFpAAB7aQAAxGkAAA1qAABXagAAb2oAAHBqAAC4agAAzGoAAM1qAADOagAAz2oAANBq AADRagAA0moAANNqAADUagAA1WoAANZqAADXagAA2GoAANlqAADaagAA22oAANxqAADdagAA3moA AN9qAADgagAA4WoAAOJqAADjagAA5GoAAOVqAADmagAA6GoAAOpqAAAzawAANWsAAH5rAACDawAA hGsAAJVrAACWawAAsGsAAOJrAADsawAA8WsAAAtsAAA0bAAAOWwAAEtsAABebAAAemwAAJJsAACd bAAAomwAAMBsAADnbAAA7GwAAPxsAAAGbQAAFm0AAC5tAABLbQAAUG0AAGttAACGbQAAi20AAJBt AACkbQAApW0AAO9tAAAmbgAAJ24AAChuAAApbgAAKm4AACtuAAAsbgAALW4AAC5uAAAvbgAAMG4A ADFuAAAybgAAM24AADRuAAA1bgAAN24AADluAACCbgAAhG4AAM1uAADSbgAA024AAOJuAADjbgAA /m4AAP9uAABGbwAAjG8AAI1vAADVbwAAGHAAAFtwAAB+cAAAf3AAAMhwAAAQcQAASnEAAEtxAACM cQAA0HEAABdyAABCcgAAQ3IAAIpyAADNcgAAFHMAAF1zAACJcwAAinMAANNzAAATdAAAWXQAAKF0 AAC6dAAAu3QAANh0AADZdAAAIHUAAGl1AACydQAA1XUAANZ1AAAgdgAAZXYAAK52AACvdgAAsHYA ALF2AACydgAAtHYAALZ2AAD/dgAAAXcAAEp3AABPdwAAUHcAAJR3AADZdwAAHngAADd4AAA4eAAA gXgAAMR4AAAKeQAAC3kAAFJ5AACVeQAAynkAAMt5AADfeQAA4HkAAPN5AAAJegAAEXoAACx6AABT egAAWHoAAFl6AABtegAAenoAAJd6AACnegAArHoAAMh6AAAAewAABXsAAAZ7AAAZewAAPXsAAF57 AAB2ewAAk3sAAJt7AAC2ewAA2HsAAN17AADeewAA33sAAOB7AADhewAA4nsAAON7AADkewAA5nsA AOh7AAAxfAAAM3wAAHx8AACBfAAAgnwAAJh8AAC2fAAA2HwAAOx8AADxfAAADX0AAC99AAAwfQAA UX0AAFJ9AACYfQAA4n0AACp+AABxfgAAuH4AAAJ/AABHfwAAZ38AAGh/AACrfwAA8H8AADqAAAB3 gAAAwYAAAN6AAADfgAAAJ4EAAGyBAACzgQAA9YEAAAyCAAANggAAJYIAACaCAABwggAAuoIAAAGD AABJgwAAi4MAAM6DAAAVhAAAFoQAACuEAAAshAAAW4QAAFyEAABdhAAAX4QAAGGEAACqhAAArIQA APWEAAD6hAAA+4QAAEGFAACHhQAApIUAAKWFAAC1hQAAtoUAAPuFAAARhgAAEoYAABeGAAAYhgAA GYYAABqGAAAbhgAAHIYAAB2GAAAehgAAH4YAACCGAAAhhgAAIoYAACOGAAAkhgAAJYYAACaGAAAn hgAAKIYAACmGAAAqhgAAK4YAACyGAAAthgAALoYAAC+GAAAwhgAAMYYAADKGAAAzhgAANIYAADWG AAA2hgAAN4YAADiGAAA5hgAAOoYAADuGAAA8hgAAPoYAAECGAACJhgAAi4YAAFCHAADYhwAA24cA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgABiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAYgADABAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgDBSAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJiABiAAMAIAAAAAAACA AAAAgAAAAAAAAAAAEACYgAYgADADAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAQAJiDBSAAMAEAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAABAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAQAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAgAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA CACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAI AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmkAAABcwAAAAAAAAAIAAAACAAAAAAAAAAAAABJhAAAAXMAAAAAAAAACAAAAAgAAAAAAA AAAAgAQKAAAAADAAAAAAAAAAAAAAAAAAANz+4AAEAAAHAAAAAAgAAAAJAAAA2wAAANwAAADpAAAA 6gAAAA0BAAAOAQAAggEAAIMBAAAmAgAAJwIAAHIDAACcAwAAnQMAAN8DAAAoBAAAcQQAALsEAAD/ BAAARwUAAIAFAACBBQAAxAUAAAkGAABRBgAA2QYAANoGAADbBgAA5QYAAOYGAAAnBwAAKAcAACkH AAA3BwAAOAcAAG8IAABwCAAAbwkAAHAJAACMCQAAjQkAAK0JAACuCQAA2AkAAAwKAABjCgAAZAoA AIYKAACHCgAAMAsAADELAAB5CwAAegsAAL4LAAC/CwAA8gsAAPMLAAA9DAAAgQwAAEQNAAB2DQAA dw0AALwNAAAGDgAAJQ4AACYOAABxDgAAcg4AAHMOAAB0DgAAdQ4AAL8OAAAIDwAAUQ8AAJoPAADj DwAALBAAAHYQAADAEAAACREAAC4RAAAwEQAAVxEAAJwRAADiEQAAEhIAAE8SAABQEgAAURIAAGYS AABnEgAAsBIAAPoSAABFEwAAkBMAAJ0TAACeEwAA5BMAACkUAABsFAAAeBQAAHkUAADDFAAADBUA AE8VAACOFQAAjxUAAMoVAAD+FQAA/xUAAEQWAABtFgAAbhYAAKcWAACoFgAArhYAAK8WAAC5FgAA uhYAAAQXAABMFwAAThcAAFAXAABSFwAAmxcAAJ0XAADmFwAA6xcAAOwXAAAzGAAAehgAALwYAAAC GQAARhkAAI4ZAACbGQAAnBkAAL8ZAADAGQAACBoAAFEaAACYGgAAmRoAAKwaAACtGgAAshoAAPoa AABCGwAAihsAANIbAAAaHAAAYhwAAKocAADyHAAAOh0AAIIdAADKHQAAEh4AAFoeAACiHgAA6h4A ADIfAABzHwAAux8AAAIgAABKIAAAkiAAANogAAAiIQAAaiEAALIhAAD6IQAAQiIAAIoiAADSIgAA GiMAABwjAAAeIwAAZyMAAGkjAACyIwAAtyMAALgjAAAAJAAASCQAAJAkAADYJAAA3SQAAO4kAADv JAAAMyUAAHUlAACdJQAAniUAAOclAAAvJgAAdyYAAMEmAADWJgAA1yYAABEnAAASJwAALCcAAC0n AABHJwAASCcAAJInAACTJwAAyScAAMonAADqJwAA6ycAAB0oAAAeKAAAYSgAAJ8oAADmKAAALCkA ADkpAAA6KQAAaSkAAGopAAC0KQAA+CkAAEAqAACEKgAAkSoAAJIqAACTKgAAlCoAAJYqAACYKgAA 4SoAAOMqAAAsKwAAMSsAADIrAABkKwAAZSsAAKgrAADvKwAAMCwAAGcsAABoLAAAriwAAPgsAABC LQAAii0AANQtAAD5LQAA+i0AAEIuAACLLgAA1C4AAB4vAABiLwAAqi8AAOUvAADmLwAALjAAAG8w AACzMAAA1zAAANgwAAAhMQAAZjEAAK4xAAA2MgAANzIAAGEyAABiMgAApzIAAO4yAAAwMwAAejMA AMEzAAACNAAAETQAABI0AAA/NAAAQDQAAIY0AADQNAAAETUAABM1AAAVNQAAXjUAAGA1AACpNQAA rjUAAK81AADwNQAAKDYAACk2AABzNgAAvTYAAM82AADQNgAA6DYAAOk2AAAoNwAAKTcAAHM3AAC7 NwAA/DcAAP03AABDOAAAijgAAKE4AACiOAAA6jgAADE5AABIOQAASTkAAHQ5AAB1OQAAuDkAALk5 AAD+OQAARjoAAEc6AACKOgAA0ToAAOs6AADsOgAAMzsAAHM7AAC8OwAABDwAAE08AABzPAAAdDwA AKI8AACjPAAA6TwAADE9AAAyPQAAMz0AADU9AAA3PQAAgD0AAII9AADLPQAA0D0AANE9AAAaPgAA YT4AAKg+AADsPgAA7T4AADc/AAB/PwAAxz8AAA1AAAA+QAAAP0AAAIRAAADMQAAAEkEAAFZBAACe QQAA5UEAAABCAAABQgAASkIAAI9CAADPQgAA0EIAAPBCAADxQgAAG0MAAGNDAADcQwAA3UMAABVE AAAWRAAAv0QAAMBEAAAIRQAACUUAAE1FAABORQAAgUUAAIJFAADMRQAAEEYAANVGAAAIRwAACUcA AE5HAACYRwAAt0cAALhHAAAqSAAArUgAAPJIAAA2SQAAfEkAAIhJAACJSQAA9VEAAD5SAACAUgAA x1IAAOZSAADnUgAAM1MAADyGAAA+hgAAQIYAAImGAACLhgAA24cAAJgAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAIABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAZgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAgAGYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIABmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAIABmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAXlAATAMMAAAAAAAAAEAAAABAAAAAAAA AAAAkAF5QAEwDDAAAAAAAAABAAAAAQAAAAAAAAAAAIABeUABMAwwAAAAAAAAAQAAAAEAAAAAAAAA AACAB5hAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYQAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmEAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAAZhAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAGYQAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAgBmEAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA AZhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAGYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAB mEAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAAZhAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAGY QAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAABmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAZhA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAGYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5gAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5gAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5iABiAAMAAAAAAA AACAAAAAgAAAAAAAAAAAgAeYgAYgADABAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAACAB5iDBSAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAA AAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAA ADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAA MAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAw AAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAA AAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAA AAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAA AAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAA AACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAA gAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA gAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACA AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAA AAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAA ADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAA MAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAw AAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAA AAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAA AAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAA AAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAA AACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAA gAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA gAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACA AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAA AAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAA ADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAA MAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAw AAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAA AAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAA AAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAA AAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAA AACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAA gAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA gAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACA AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAA AAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAA ADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAA MAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAw AAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAA AAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAA AAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAA AAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAA AACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAA gAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA gAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACA AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAIAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAACAAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAgAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAADgAAAAAAAHmAAA AAAwAAAAAAAAAIAAAACAAAAA4AAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAOAAAAAAAAeYAAAA ADAAAAAAAAAAgAAAAIAAAADgAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAA AAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAA AAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAA AAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAA AAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAA AACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAA AIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAA gAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACA AAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAA AACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAA AIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAA gAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACA AAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAA AABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAA AFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAA UAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQ AAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAA AAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAA AAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAA AAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAAAA B5gAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAAAeYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAAAH mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAEAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAABAHmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAQB5iABiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAkAeYgAYg ADABAAAAAAAAgAAAAIAAAAAAAAAAABAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACQB5iDBSAA MAAAAAAzBQAAAAAAgAAAAAAAAAAAkAeYAwUgADABAAAAMwUAAAAAAIAAAAAAAAAAABAHeUABMHsx AAAAAAAAAQAAAAEAAAAACAAAAACQB3lAATB7MQAAAAAAAAEAAAABAAAAAAgAAAAAkAeYAwUgADAB AAAAMwUAAAAAAIAAAAAAAAAAABAHmAMFIAAwAQAAADMFAAAAAACAAAAAAAAAAAAQB5hDBSAAMAEA AAAzBQAAAAAAgAAAAAAAAAAAEAeYAwUgADABAAAAMwUAAAAAAIAAAAAAAAAAABAHmAMFIAAwAQAA ADMFAAAAAACAAAAAAAAAAAAAB3lAATCCMQAAAAAAAAEAAAABAAAAAAgAAAAAgAd5QAEwgjEAAAAA AAABAAAAAQAAAAAIAAAAAIAHeUABMIIxAAAAAAAAAQAAAAEAAAAACAAAAACAB3lAATCCMQAAAAAA AAIAAAABAAAAAAgAAAAAgAd5QAEwADAAAAAAAAABAAAAAQAAAAAIAAAAAAAHeUABMIcxAAAAAAAA AQAAAAEAAAAACAAAAACAB3lAATCHMQAAAAAAAAIAAAABAAAAAAgAAAAAgAd5QAEwADAAAAAAAAAB AAAAAQAAAAAIAAAAAAAHeUABMAAwAAAAAAAAAQAAAAEAAAAACAAAAAAQB3lAATAAMAAAAAAAAAEA AAABAAAAAAgAAAAAEAd5QAEwADAAAAAAAAABAAAAAQAAAAAIAAAAAAgHeUABMI0xAAAAAAAAAQAA AAEAAAB4DN8APDL+B3lAATCNMQAAAAAAAAEAAAABAAAAAAgAAAAAiAd5QAEwjTEAAAAAAAACAAAA AQAAAAAIAAAAAIgHeUABMAAwAAAAAAAAAQAAAAEAAAAACAAAAAAIB3lAATAAMAAAAAAAAAEAAAAB AAAAAAgAAAAAEAd5QAEwADAAAAAAAAABAAAAAQAAAAAIAAAAAAAHeUABMI8xAAAAAAAAAQAAAAEA AAB4DN8ArDL+B3lAATCPMQAAAAAAAAEAAAABAAAAAAgAAAAAgAd5QAEwjzEAAAAAAAACAAAAAQAA AAAIAAAAAIAHeUABMAAwAAAAAAAAAQAAAAEAAAAACAAAAAAAB3lAATAAMAAAAAAAAAEAAAABAAAA AAgAAAAAEAd5QAEwADAAAAAAAAABAAAAAQAAAAAIAAAAABAHeUABMAAwAAAAAAAAAQAAAAEAAAAA CAAAAAAAB3lAATAAMAAAAAAAAAEAAAABAAAAeAzfAPyCBQd5QAEwADAAAAAAAAABAAAAAQAAAAAI AAAAAAAHeUABMAAwAAAAAAAAAgAAAAEAAAAACAAAAAAABwAAAAAAMAAAAAAAAAAAAAAAAAAAAAAA AAAAAAeYAAAAADAAAAAAAAAAgAAAAIDfAAEAAAA9gQIHeUABMAAAAAAAAAAAAQAAAAEAAAAAAAAA gBPfBwAGAADvDAAAQRIAAE5LAAC/TAAAAlAAANqPAABIAAAATAAAAFAAAABcAAAAXwAAAGMAAAAA BgAAnAsAACgPAAAMEgAA8hMAAFcZAABtHgAAUSIAAGopAADWLgAAkjIAAKo3AAATPQAASUEAAMtF AADQSgAAY0sAABVMAAAJTQAAgU0AACpQAAC/UwAAllgAAFVcAADrYQAAc2YAAC9rAABKbwAA03IA ALBzAAAmdgAAjXcAACB9AACVgQAA3YMAALiGAAAsjAAAII4AAD6OAADajwAASQAAAEsAAABNAAAA TgAAAE8AAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAF0AAABe AAAAYAAAAGEAAABiAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4A AABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAAAYAANmPAABKAAAA//84AAAABgBeLGoAAAAB ACzuIgAGAF8sagAAAAEArPGAAwYAYCxqAAAAAQDMiX4DBgBhLGoAAAABAAzEGwAGAGIsagAAAAEA PP1/AwYAYyxqAAAAAQC08n8DBgBkLGoAAAABAPQhHAAGAGUsagAAAAEAhBOAAwYAZixqAAAAAQB8 /H8DBgBnLGoAAAABANyTgAMGAGgsagAAAAEALLx/AwYAaSxqAAAAAQC8/H8DBgBqLGoAAAABAMx9 gAMGAGssagAAAAEAjMMbAAYAbCxqAAEAAQBUcIEDBgBtLGoAAAABADQSgAMGAG4sagABAAEA1KqA AwYAbyxqAAAAAQCEJ4ADBgBwLGoAAQABAGy7CAkGAHEsagAAAAEADH8KCQYAcixqAAEAAQDMfgoJ BgBzLGoAAAABALwhDAcGAHQsagABAAEA3FiBAwYAdSxqAAAAAQAcCfoIBgB2LGoAAQABALRBfgMG AHcsagABAAEALB3zBgYAeCxqAAEAAQAcXYEDBgB5LGoAAAABACyWfgMGAHosagABAAEAjH4KCQYA eyxqAAAAAQBcLQgHBgB8LGoAAAABAGwhCAcGAH0sagAAAAEARDAIBwYAfixqAAAAAQCcsYEDBgB/ LGoAAAABAPwUhAMGAIAsagAAAAEA9CEgAAYAgSxqAAAAAQBkEyAABgCCLGoAAQABAEzEGwAGAIMs agAAAAEAbB+IAwYAhCxqAAEAAQCMDyAABgCFLGoAAAABAKQHfgMGAIYsagABAAEA9EaEAwYAhyxq AAAAAQD8v34DBgCILGoAAQABAFQ2ggMGAIksagABAAEATCmCAwYAiixqAAAAAQDs+yIABgCLLGoA AQABAMzPAAcGAIwsagABAAEArDWCAwYAjSxqAAEAAQAM4H8DBgCOLGoAAAABAMSuhwMGAI8sagAB AAEA9DCCAwYAkCxqAAAAAQAcRoIDBgCRLGoAAAACAPxLGwAGAJIsagAAAAEA1EyCAwYAkyxqAAEA AQDMOIIDBgCULGoAAAABAFQqIAAGAJUsagAAAAEAJDiCA/kQAACUFgAAcRcAAD0jAAC3KgAANDUA AKY6AABWPQAASksAAApVAACSXgAA0GYAAAlrAADFawAAxWsAAOVrAADlawAATmwAAE5sAACVbAAA lWwAAAltAAAJbQAAGW0AABltAAAkbQAAJ20AADFtAAAxbQAAWG4AAAl2AADVdgAAg3cAAGt4AAA+ eQAAmnoAAJp6AACgegAAoHoAADR7AAA0ewAAQHsAAEB7AABWewAAYXsAAGF7AABsewAAb3sAAHl7 AAB5ewAAB3wAAIV8AADffAAA33wAAICEAABfhgAA24cAAAAAAAABAAEAAAABAAIAAAABAAMAAAAB AAQAAAABAAUAAAABAAYAAAABAAcAAAABAAgAAAABAAkAAAABAAoAAAABAAsAAAABAAwAAAABAA0A AAACAA4AAAACAA8AAAACABAAAAACABEAAAACABIAAAACABMAAAACABQAAAACABYAAAACABUAAAAC ABkAAAACABcAAAACABgAAAACABoAAAACABsAAAACABwAAAACAB0AAAABAB4AAAABAB8AAAABACAA AAABACEAAAABACIAAAABACMAAAACACQAAAACACUAAAACACYAAAACACcAAAACACgAAAACACoAAAAC ACkAAAACACsAAAACAC4AAAACACwAAAACAC0AAAACAC8AAAACADAAAAACADEAAAACADIAAAABADMA AAABADQAAAACADUAAAACADYAAAABADcAAAABAAcRAACkFgAAgRcAAE0jAADHKgAARDUAAKw6AABm PQAAWksAABpVAACiXgAA4GYAABlrAADNawAAzWsAAOprAADqawAAVGwAAFRsAACbbAAAm2wAAA9t AAATbQAAIm0AACZtAAAsbQAALG0AAEltAABJbQAAaG4AAA52AADldgAAiHcAAHB4AABDeQAAn3oA AJ96AAClegAApXoAADt7AAA7ewAARHsAAFh7AABYewAAansAAG57AAB0ewAAdHsAAJF7AACRewAA F3wAAJZ8AADqfAAA6nwAAJCEAABvhgAA24cAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAH AAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABYA AQAVAAAAGAABABkAAQAXAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAA ACQAAAAlAAAAJgAAACcAAAAoAAAAKgABACkAAAArAAAALQABAC4AAQAsAAAALwAAADAAAAAxAAAA MgAAADMAAAA0AAAANQAAADYAAAA3AAAACQAAADgAAAAqAAAAKoB1cm46c2NoZW1hcy1taWNyb3Nv ZnQtY29tOm9mZmljZTpzbWFydHRhZ3MEgENpdHkAgEIAAAAoAAAAKoB1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MOgGNvdW50cnktcmVnaW9uAIA5AAAAMgAAACqAdXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzBYBwbGFjZQCAOAAAADgAAAAq gHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwSAZGF0ZQCAOwAAACMA AAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncweAYWRkcmVzcwCA OgAAACIAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwaAU3Ry ZWV0AIA5AAAAHwAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdz BYBTdGF0ZQCAPgAAAB4AAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0 dGFncwqAUG9zdGFsQ29kZQCAPgAAAAUAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOnNtYXJ0dGFncwqAUGVyc29uTmFtZQCADAAAAQEAAAAIAAAAAYAyBIAyMDA2BIAyMDA3AYA0 AYA4A4BEYXkFgE1vbnRoBIBZZWFyOAADAAAABgAAAAQAAAAFAAAAAwAAAAcAAAABAAAAOAADAAAA BgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAAD AAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAA OAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAMgAAAAAAOAADAAAABgAAAAAAAAAFAAAAAwAA AAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAA AwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAF AAAAAwAAAAcAAAACAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAMgAAAAAAKgAAAAAA MgAAAAAAKAAAAAAAMgAAAAAAKAAAAAAAMgAAAAAAKAAAAAAAIwAAAAAAIgAAAAAAMgAAAAAAKgAA AAAAHwAAAAAAHgAAAAAAMgAAAAAAKAAAAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAA MgAAAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAMgAAAAAAMgAAAAAAMgAAAAAAMgAA AAAAKgAAAAAAMgAAAAAAKAAAAAAAMgAAAAAAKAAAAAAAMgAAAAAAKgAAAAAAHwAAAAAAMgAAAAAA KgAAAAAAHwAAAAAAHgAAAAAAMgAAAAAAKAAAAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAAC AAAABQAAAAAAMgAAAAAAKAAAAAAAOAADAAAABgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAOAADAAAA BgAAAAAAAAAFAAAAAwAAAAcAAAACAAAAAAAAACcBAAA3AQAAqwEAALQBAAB0AgAAfQIAAMECAADK AgAApQcAAK0HAAAUCgAAHwoAAIQMAACNDAAATA0AAFUNAABHDwAATw8AANUPAADbDwAAbBAAAHQQ AAC4EAAAvhAAAOcUAADwFAAAZhkAAHQZAAB9HAAAhhwAADIeAAA2HgAAeCAAAHwgAABvJwAAcycA ACo0AAAzNAAAYzQAAGw0AAA5NwAAQjcAAOE/AADlPwAA5j8AAO8/AADlQAAA6UAAAJJCAACbQgAA a0MAAHZDAAATRgAAHEYAAN1GAADmRgAAQ0wAAEdMAACXTAAAm0wAAJxMAACkTAAAYlAAAGZQAACQ UAAAlFAAAN9SAADjUgAAvVMAAMFTAADuVQAA8lUAAD9WAABDVgAAd1YAAHtWAAAbVwAAH1cAAJdY AACbWAAAAVsAAAVbAACEXwAAjV8AAKVfAACuXwAAe2AAAIRgAADgYAAA6WAAAGNiAABnYgAApGIA AKhiAAB1ZAAAeWQAAI1lAACRZQAAr2gAALhoAAAYaQAAIWkAAFRpAABYaQAAmWsAAJ9rAACgawAA p2sAALdrAADEawAAxWsAAM1rAAA8bAAAQmwAAENsAABJbAAAcmwAAHhsAACDbAAAimwAAItsAACQ bAAAvGwAAL5sAAD2bAAA+WwAAP9sAAAEbQAAyG0AAM9tAADQbQAA120AAONtAADpbQAAEW8AABhv AAA0bwAAOG8AALZvAAC8bwAA528AAOxvAAD4bwAAA3AAAJFwAACYcAAAqnAAAK1wAAC7cAAAxXAA ALBxAAC5cQAAw3EAAM5xAABVcgAAW3IAAKhzAACvcwAAt3cAAMV3AABiegAAanoAAIR6AACLegAA 0noAAOB6AAARewAAF3sAAEp7AABQewAAhXwAAIl8AACOfAAAlnwAAJt8AAChfAAAuXwAAMN8AADQ fAAA1nwAAIuGAADbhwAABwAEAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAGwAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAHAAAAAAAGAQAADAEAAA4BAACBAQAA eAIAAH8CAADlAwAA5wMAAC4EAAAyBAAAdwQAAHwEAADCBAAAxAQAAEEFAABFBQAATQUAAFEFAADK BQAAzAUAAA8GAAAVBgAAVwYAAFwGAABADAAAQwwAAIQMAACNDAAAvw0AAMkNAAAJDgAACw4AAN0P AADfDwAAIRIAAE0SAACzEgAAthIAAP0SAAACEwAASBMAAE8TAACTEwAAmhMAAOcTAAAcFAAALBQA ADEUAABvFAAAdhQAAMYUAADJFAAADxUAABMVAABSFQAAWhUAAO8XAADzFwAANhgAAD8YAAB9GAAA ghgAAL8YAADIGAAAXBkAAGEZAACRGQAAmBkAAFQaAABcGgAANiUAAD8lAAB4JQAAhCUAADImAAA7 JgAAeiYAAIAmAADEJgAAyCYAABUnAAAfJwAAMCcAADonAABLJwAAUycAAJYnAACdJwAAzScAANcn AACiKAAAtigAAOkoAADxKAAALykAADYpAAD7KQAAAioAAEMqAABFKgAAhyoAAI4qAACrKwAAtCsA APIrAAD3KwAAMywAAD0sAABrLAAAcywAALQsAAC6LAAA/iwAAActAABILQAASy0AAJAtAACSLQAA 2i0AAOItAAD9LQAABS4AAEguAABKLgAAkS4AAJUuAADaLgAA3y4AACUvAAAnLwAAaC8AAHIvAACw LwAAtC8AAOkvAADzLwAANDAAAD0wAAB1MAAAgDAAALkwAADAMAAA2zAAAOUwAAAnMQAAKTEAAGwx AAByMQAAtDEAALkxAACqMgAArzIAAPEyAAD0MgAAfTMAAIEzAADEMwAAzTMAAAU0AAAONAAAiTQA AI40AADTNAAA3DQAAPM1AAD8NQAAdjYAAHw2AADANgAAxzYAAHY3AAB5NwAAvjcAAMI3AABGOAAA TjgAAI04AACYOAAA7TgAAPQ4AAA0OQAARjkAAAE6AAAHOgAAjToAAJU6AADUOgAA3DoAADY7AAA5 OwAAdjsAAIE7AAC/OwAAwzsAAAc8AAAKPAAAUDwAAFM8AADsPAAA8zwAAB0+AAAhPgAAZD4AAGc+ AACrPgAAtz4AADo/AAA8PwAAUT8AAGM/AACCPwAAhT8AAMo/AADUPwAAEEAAABVAAACHQAAAj0AA ABVBAAAcQQAAWUEAAGBBAAChQQAAp0EAAOhBAADrQQAATUIAAFRCAACSQgAAm0IAAKdDAACrQwAA z0UAANJFAAATRgAAHEYAAFFHAABbRwAAm0cAAJ1HAAANSgAAFEoAAFRKAABXSgAAnEoAAJ9KAADh SgAA60oAAMhLAADKSwAAD0wAABlMAACpTAAAs0wAAO1MAADzTAAAeU0AAIBNAAAeTgAAJU4AALBO AAC0TgAA904AAPxOAAA9TwAAQ08AAIVPAACJTwAAzU8AANZPAAAWUAAAGFAAAFhQAABhUAAAn1AA AKJQAADkUAAA6VAAAC1RAABMUQAAmVEAAJxRAABBUgAARFIAAMpSAADRUgAAgVMAAIdTAAAOVAAA F1QAAFhUAABdVAAAiFUAAItVAADOVQAA1lUAABNWAAAaVgAAa1YAAHVWAACxVgAAyFYAAD9XAABI VwAAh1cAAIxXAADRVwAA01cAAGFYAABlWAAAq1gAAK1YAADtWAAA9lgAAHZZAAB5WQAA7lkAAPFZ AACuWgAAr1oAAPhaAAAAWwAAa1sAAHZbAAB7WwAAglsAAMVbAADIWwAADVwAAB1cAAD5XAAA/FwA ADNeAAA1XgAAWF8AAFtfAACiXwAApF8AAORfAADsXwAAkWAAAJhgAABMYQAAT2EAAFRhAABYYQAA w2EAAMxhAAANYgAAEWIAAFdiAABYYgAA8WIAAARjAAAyYwAAO2MAAHJjAAB+YwAAvGMAAL5jAABD ZAAASGQAAKFkAACoZAAA6mQAAO5kAAAyZQAANGUAAKNlAACrZQAA42UAAO1lAAAqZgAALmYAALBn AADTZwAA+WcAAANoAADwaAAA92gAADRpAAA6aQAAfmkAAINpAADHaQAAymkAABBqAAARagAAWmoA AF1qAAC7agAAyWoAAPJtAAD7bQAAVHMAAFhzAABvcwAAd3MAAMtzAADOcwAAa3QAAHB0AADodAAA 83QAAEd4AABXeAAAGnkAACp5AABkeQAAZ3kAANJ6AADiegAA5X0AAOx9AAAtfgAAMX4AAHR+AAB5 fgAAu34AAL9+AAAFfwAAB38AAEp/AABPfwAArn8AALh/AADzfwAA+n8AAD2AAABBgAAAeoAAAIeA AAAqgQAANIEAAG+BAAB1gQAAtoEAALqBAADRgwAAE4QAAD2EAABAhAAARIUAAE2FAACKhQAAkIUA AP6FAAAPhgAAi4YAANuHAAAHADMABwAEAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcABwAAAAAAJwEAADcBAACLhgAA24cAAAcABAAHAAcAAAAAANuHAAA8AAAACAAAAAyREAAAAAEA AAAEAAAAAAACAAMAbSExB7bWoL8PABAAEQASAP8P/w//D/8P/w8AAChA9RS6w44c/w//D/8P/w// D/8P/w//D/8PAAA0dMlmBK1Gkf8P/w//D/8P/w//D/8P/w//DxAAAQAAAAMABwAAAAAAAAAAAQAA AAAAAAAAABAAAA+EAAARhAAAXoQAAGCEAAAHAEEAbgBuAGUAeAAgAAAAAQAAAAAAAQMAAAAAAAAA AAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAFoAQZehAAAYIQAAAMAAAAuAAEAAQAAAAAAAQMFAAAA AAAAAAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAHQAgZehAAAYIQAAAUAAAAuAAEALgACAAEAAAAA AAEDBQcAAAAAAAAAAAAAAAAAAAAYAAAPhAAAEYQAABXGBQAB0AIGXoQAAGCEAAAHAAAALgABAC4A AgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAEAAAZehAAAYIQA AAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAAABgAAA+EAAARhAAA FcYFAAEAAAZehAAAYIQAAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAA AAAAAAAAAAAYAAAPhAAAEYQAABXGBQABAAAGXoQAAGCEAAANAAAALgABAC4AAgAuAAMALgAEAC4A BQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAEAAAZehAAAYIQA AA8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAA ABgAAA+EAAARhAAAFcYFAAEAAAZehAAAYIQAABEAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAu AAcALgAIAAQAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCE YPpvKAABAAAAAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAF YIRg+m8oAAMAAAAuAAEAAwAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGg BQZehKAFYIRg+m8oAAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAMYAAAPhKAF EYRg+hXGBQABoAUGXoSgBWCEYPpvKAAHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAA AAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAAkAAAAuAAEALgACAC4AAwAuAAQA AQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAAsA AAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMYAAAPhKAFEYRg +hXGBQABoAUGXoSgBWCEYPpvKAANAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMF BwkLDQ8AAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAA8AAAAuAAEALgAC AC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+ECAcRhPj4 FcYFAAEIBwZehAgHYIT4+G8oABEAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEA AAAXEAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgUAUUoF AF5KBQBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhKAFEYSY /hXGBQABoAUGXoSgBWCEmP5PSgUAUUoFAF5KBQBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAA AAAAAABoAQAAAAAAABUYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAIdoAAAA AIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EQAsRhJj+FcYFAAFACwZehEAL YISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAA D4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBeSgUAbygAh2gAAAAAiEgAAAEAbwABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oGAFFKBgBv KACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhLATEYSY/hXGBQAB sBMGXoSwE2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAAGRgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAXkoFAG8oAIdoAAAAAIhIAAAB AG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9K BgBRSgYAbygAh2gAAAAAiEgAAAEAp/AGAAAAbSExBwAAAAAAAAAAAAAAAG0hMQcAAAAAAAAAAAAA AABtITEHAAAAAAAAAAAAAAAAbSExBwAAAAAAAAAAAAAAAChA9RQAAAAAAAAAAAAAAAA0dMlmAAAA AAAAAAAAAAAA//////////////////////////////////8DAAAAAAAAAAAA//8DAAAAAAAAABIA AwAJBAMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEJwAAAAQAAAAIAAAA5QAAAAAAAAAm AAAAxSQLAOZbIAAEcCIAMWUoAKxbKgD5Zy4AjlA/AMVXRwBdZk0AYyJQAJFwVQDvN1cAl3VfADws YwA3GnIA3EtyANJgegDTcoAAB3CBAA5IkACTCZEAmjaRADZekQDFK5UAKHSjAEI+pwCpEqkAzwCu AH1OsQDdE7kA7H3PAGki0AClXdYA+HDcAEoa3wAWd+MAN23qAKlY7wC0KfgA/0ABgAEAKwEAACsB AACAv8YBAQABACsBAAAAAAAAKwEAAAAAAAACEAAAAAAAAADahwAAwAAAEABAAAD//wIAAAAHAFUA bgBrAG4AbwB3AG4ADQBUAHIAZQB2AG8AcgAgAFcAaQBsAHMAbwBuAP//AgAIAAAAAAAAAAAAAAAA AAAAAAAAAAEA//8CAAAAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAcAAABHFpABAAACAgYD BQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBh AG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwA AAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAOwaQ AYYHAgEGAAMBAQEBAQMAAAAAAA4IEAAAAAAAAAABAAQAAAAAAFMAaQBtAFMAdQBuAAAAi1tTTwAA NSaQAQAAAgsGBAMFBAQCBId6ACEAAACACAAAAAAAAAD/AQEAAAAAAFQAYQBoAG8AbQBhAAAAPzWQ AQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUA dwAAADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBu AGcAcwAAACIABABxiIwYAPDQAgAAaAEAAAAAu3qoRjKEqGYAAAAABQBOAgAAFBQAAHdyAAABAEQA AAAEAAMQ9AAAABQUAAB3cgAAAQBEAAAA9AAAAAAAAAARJADwEAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAIB6AFtAC0AIGBMjQAAAAAAAAAAAAAAAAAAEeGAABHhgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAQz g1EA8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAAAAAKfD/DwEAAT8AAOQEAABx AwAA////f////38AAAAA////f////3////9/aSLQAP//EgAAAAAAAAAJAFMAZQBjAHQAaQBvAG4A IAAzAAAAAAAAAA0AVAByAGUAdgBvAHIAIABXAGkAbABzAG8AbgANAFQAcgBlAHYAbwByACAAVwBp AGwAcwBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAABgAAAAMAAAAAAAwAAQAMAAIADAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAA AAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAgAEAABEAAAABAAAAkAAAAAIA AACYAAAAAwAAAKwAAAAEAAAAuAAAAAUAAADQAAAABgAAANwAAAAHAAAA6AAAAAgAAAD8AAAACQAA ABQBAAASAAAAIAEAAAoAAAA8AQAADAAAAEgBAAANAAAAVAEAAA4AAABgAQAADwAAAGgBAAAQAAAA cAEAABMAAAB4AQAAAgAAAOQEAAAeAAAADAAAAFNlY3Rpb24gMwAAAB4AAAAEAAAAAAAAAB4AAAAQ AAAAVHJldm9yIFdpbHNvbgAAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAMAAAATm9ybWFs LmRvdAAAHgAAABAAAABUcmV2b3IgV2lsc29uAAAAHgAAAAQAAAA1AAAAHgAAABQAAABNaWNyb3Nv ZnQgV29yZCAxMC4wAEAAAAAAVAtsUgAAAEAAAAAAii1uUcDGAUAAAAAARFShS8HGAQMAAAABAAAA AwAAABQUAAADAAAAd3IAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAA AAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAPwAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUA AACIAAAABgAAAJAAAAARAAAAmAAAABcAAACgAAAACwAAAKgAAAAQAAAAsAAAABMAAAC4AAAAFgAA AMAAAAANAAAAyAAAAAwAAADeAAAAAgAAAOQEAAAeAAAAEAAAAE5vcnRlbCBOZXR3b3JrcwADAAAA 9AAAAAMAAABEAAAAAwAAAEeGAAADAAAAlBoKAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAA AAAAHhAAAAEAAAAKAAAAU2VjdGlvbiAzAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAH AAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAA ACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAA MgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABA AAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4A AABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAA AF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAA awAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAA/v///3gAAAB5 AAAAegAAAHsAAAB8AAAAfQAAAH4AAAD+////gAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcA AACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAA AJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAA pAAAAKUAAACmAAAApwAAAKgAAACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACvAAAAsAAAALEAAACy AAAAswAAALQAAAC1AAAAtgAAALcAAAC4AAAAuQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAA AADBAAAAwgAAAMMAAADEAAAAxQAAAMYAAADHAAAAyAAAAMkAAADKAAAAywAAAMwAAADNAAAAzgAA AM8AAADQAAAA0QAAANIAAADTAAAA1AAAANUAAADWAAAA1wAAANgAAADZAAAA2gAAANsAAADcAAAA 3QAAAN4AAADfAAAA4AAAAOEAAADiAAAA4wAAAOQAAADlAAAA5gAAAOcAAADoAAAA6QAAAOoAAADr AAAA/v///+0AAADuAAAA7wAAAPAAAADxAAAA8gAAAPMAAAD+////9QAAAPYAAAD3AAAA+AAAAPkA AAD6AAAA+wAAAP7////9/////f////8AAAD+////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIA AAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAQC2vvUvBxgECAQAAgAAAAAAAAABEAGEAdABhAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAEAAAAAAA ADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAfwAAAK/YAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAIuwAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOwAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUA bgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAA AP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9AAAAAAQAAAAAAAA AQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP3////+/////v////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////AQAAAP7///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAA AE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQu OAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADA AAAAAAAARgAAAAAAAAAAAAAAAPCM02BMwcYBCQEAAIADAAAAAAAARABhAHQAYQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3AAAAABAAAAAAAAAxAFQA YQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH8A AACv2AAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACLsAAAAAAAA////////////////CAEAAP3////9/////v////7////+ ////BwEAAP////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////+BAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkA AACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAA AJgAAACZAAAAmgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAClAAAA pgAAAKcAAACoAAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAAALMAAAC0 AAAAtQAAALYAAAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9AAAAvgAAAL8AAADAAAAAwQAAAMIA AADDAAAAxAAAAMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4AAADPAAAA0AAA ANEAAADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA3AAAAN0AAADeAAAA 3wAAAOAAAADhAAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADqAAAA6wAAAP7////t AAAA7gAAAO8AAADwAAAA8QAAAPIAAADzAAAA/v////////////////////////////////////// /////////f///////////////////wEAAAD+////AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AAoAAAALAAAADAAAAA0AAAD+//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////BAAAAAIAAAAUAAAAXwBBAGQASABvAGMAUgBlAHYAaQBlAHcA QwB5AGMAbABlAEkARAAAAAMAAAAOAAAAXwBFAG0AYQBpAGwAUwB1AGIAagBlAGMAdAAAAAQAAAAN AAAAXwBBAHUAdABoAG8AcgBFAG0AYQBpAGwAAAAAAAUAAAAYAAAAXwBBAHUAdABoAG8AcgBFAG0A YQBpAGwARABpAHMAcABsAGEAeQBOAGEAbQBlAAAAAgAAALAEAAATAAAACQgAAAMAAACRlpj0HwAA ABgAAABQAG8AbABsAGkAbgBnACAAZgBvAHIAIABuAGUAdwAgAFcARwAgAEkALQBEAHMAAAAfAAAA EwAAAFcASQBMAFMATwBOAFQAQABuAG8AcgB0AGUAbAAuAGMAbwBtAAAAAAAfAAAAHAAAAFcAaQBs AHMAbwBuACwAIABUAHIAZQB2AG8AcgAgACgASQBSAEUAMAA3ADoAUQA4ADQAMAApAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBu AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAOwAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBt AG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAPQCAAAAAAAAAQBDAG8AbQBw AE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIA AgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9z b2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAA AgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rkABAAD8AAAADAAAAAEAAABo AAAADwAAAHAAAAAFAAAAiAAAAAYAAACQAAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAA AAATAAAAuAAAABYAAADAAAAADQAAAMgAAAAMAAAA3gAAAAIAAADkBAAAHgAAABAAAABOb3J0ZWwg TmV0d29ya3MAAwAAAPQAAAADAAAARAAAAAMAAABHhgAAAwAAAJQaCgALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAALAAAAAAAAAB4QAAABAAAACgAAAFNlY3Rpb24gMwAMEAAAAgAAAB4AAAAGAAAAVGl0 bGUAAwAAAAEAAAC0AQAABwAAAAAAAABAAAAAAQAAAPQAAAAAAACA/AAAAAIAAAAEAQAAAwAAAAwB AAAEAAAARAEAAAUAAAB0AQAA ------_=_NextPart_001_01C6C14C.6374150F-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Aug 2006 06:51:12 +0000 Sensitivity: Subject: Re: Polling for new WG I-Ds To: "Adrian Farrel" Cc: " Message-ID: From: "Diego Caviglia" Date: Wed, 16 Aug 2006 08:48:05 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi All, yes to all. Regards Diego "Adrian Farrel" @ops.ietf.org on 12/08/2006 16.56.02 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: cc: Subject: Polling for new WG I-Ds Hi, As discussed in Montreal, we need to poll for a couple of new WG drafts. http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt has been updated by the authors to provide further details and clarification. http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt has been updated since the version discussed in Montreal. http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt has been updated as Zafar says in his previous email. Please send yes or no for these I-Ds. Reasons and opinions are also welcomed. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Aug 2006 12:21:57 +0000 Message-ID: <44E1BBFE.3010106@chello.nl> Date: Tue, 15 Aug 2006 14:20:14 +0200 From: Huub van Helvoort User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Adrian, You asked: > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. Yes to all. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Aug 2006 09:19:23 +0000 Message-Id: <6.0.0.20.2.20060815181729.05a653b0@mailsv4.y.ecl.ntt.co.jp> Date: Tue, 15 Aug 2006 18:17:55 +0900 To: "Adrian Farrel" , From: Wataru Imajuku Subject: Re: Polling for new WG I-Ds Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Hi, All Yes to all. Best Regards Wataru At 23:56 06/08/12, Adrian Farrel wrote: >Hi, > >As discussed in Montreal, we need to poll for a couple of new WG drafts. > >http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt has been updated by the authors to provide further details and clarification. > >http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt has been updated since the version discussed in Montreal. > >http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt has been updated as Zafar says in his previous email. > > >Please send yes or no for these I-Ds. > >Reasons and opinions are also welcomed. > >Thanks, >Adrian > > > > ------------------------------------- Wataru Imajuku@NTT Network Innovation Labs TEL: +81-46-859-4315 FAX: +81-468-59-5541 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Aug 2006 01:20:23 +0000 Date: Tue, 15 Aug 2006 09:18:59 +0800 From: Dan Li Subject: Re: Polling for new WG I-Ds To: Adrian Farrel , ccamp@ops.ietf.org Message-id: <002301c6c008$c915ac70$d04c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, Yes to all. Regards, Dan ----- Original Message ----- From: "Adrian Farrel" To: Sent: Saturday, August 12, 2006 10:56 PM Subject: Polling for new WG I-Ds > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Aug 2006 21:09:39 +0000 From: "Stephanie Pruitt" To: Subject: CFP-MPLS 2006 International Conference, Oct 15-18 2006 Date: Mon, 14 Aug 2006 17:08:23 -0400 Message-ID: <002c01c6bfe5$c74f0b20$28c1d541@admin0hg5amcej> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C6BFC4.403D6B20" thread-index: Aca/5cbTpuI8ue7NS5KO9ZL/Qqpq2A== This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C6BFC4.403D6B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Early bird registration ends soon! Register for MPLS 2006 International Conference Today! OCTOBER 15-18, 2006 Omni Shoreham Hotel WASHINGTON, D.C. 9th Annual International Conference on MPLS and Related Technologies To register: Click here: http://www.mpls2006.com/onlineregis.htm Conference Program: http://www.isocore.com/mpls2006/program.htm Conference Hotel Information: To reserve your room at the hotel, please visit: http://www.mpls2006.com/hotel.htm Stephanie Pruitt MPLS 2006 12359 Sunrise Valley Drive, Suite 100 Reston, VA 20191 Office: (703) 860-1777 Fax: (703) 860-1778 ------=_NextPart_000_002D_01C6BFC4.403D6B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Early bird registration ends = soon!

Register for MPLS 2006 International Conference = Today!

OCTOBER 15-18, 2006
Omni Shoreham Hotel
WASHINGTON, = D.C.
9th Annual International Conference on MPLS and Related = Technologies

 <= /span>

To register:
Click = here: http://www.mpls2006.com= /onlineregis.htm

 

Conference = Program:

http://www.isocore.= com/mpls2006/program.htm

 

Conference Hotel Information:

To reserve your room at the hotel, please = visit:

http://www.mpls2006.com/hotel= .htm

 

 

Stephanie Pruitt

MPLS = 2006

12359 Sunrise Valley Drive, = Suite = 100

Reston, VA 20191=

Office: (703) 860-1777

Fax: = (703) 860-1778

 

------=_NextPart_000_002D_01C6BFC4.403D6B20-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Aug 2006 19:50:55 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt Message-Id: Date: Mon, 14 Aug 2006 15:50:02 -0400 --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 : Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls Author(s) : D. Papadimitriou, A. Farrel Filename : draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt Pages : 29 Date : 2006-8-14 In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs). This document specifies how GMPLS RSVP-TE signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation. The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-14112441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-14112441.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Aug 2006 17:04:23 +0000 Message-ID: <44E0AC9C.3010509@us.fujitsu.com> Date: Mon, 14 Aug 2006 10:02:20 -0700 From: Richard Rabbat User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Polling for new WG I-Ds Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit yes to all btw, draft-caviglia-ccamp-pc-and-sc-reqs-02.txt is now http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-03.txt Richard -- Adrian Farrel wrote: > Hi, > > As discussed in Montreal, we need to poll for a couple of new WG drafts. > > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt > has been updated by the authors to provide further details and > clarification. > > http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt > has been updated since the version discussed in Montreal. > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt > has been updated as Zafar says in his previous email. > > > Please send yes or no for these I-Ds. > > Reasons and opinions are also welcomed. > > Thanks, > Adrian > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 13 Aug 2006 04:32:03 +0000 Date: Sun, 13 Aug 2006 13:30:22 +0900 From: Kenji Kumaki To: ccamp@ops.ietf.org Subject: Re: Montreal draft minutes posted Message-Id: <20060813132909.1B2D.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I believe that ccamper give me some comments. >Deborah: Should make any comments during the next few weeks on the list and do a respin. Thanks, Kenji On Tue, 1 Aug 2006 17:50:47 +0100 "Adrian Farrel" wrote: > http://www3.ietf.org/proceedings/06jul/minutes/ccamp.htm > > Please review. > > Apologies for the delay which is all my fault. > > Thanks to the note takers and to Deborah for compiling the minutes. > > Adrian > -- Kenji Kumaki Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 12 Aug 2006 15:02:21 +0000 Message-ID: <056c01c6be20$237b6c80$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Polling for new WG I-Ds Date: Sat, 12 Aug 2006 15:56:02 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, As discussed in Montreal, we need to poll for a couple of new WG drafts. http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-gmpls-vcat-lcas-04.txt has been updated by the authors to provide further details and clarification. http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt has been updated since the version discussed in Montreal. http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-04.txt has been updated as Zafar says in his previous email. Please send yes or no for these I-Ds. Reasons and opinions are also welcomed. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 12 Aug 2006 15:02:13 +0000 Message-ID: <056a01c6be20$21380c30$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Updated version of draft-ietf-ccamp-gmpls-rsvp-te-call Date: Sat, 12 Aug 2006 15:37:39 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We have just submitted an updated version of draft-ietf-ccamp-gmpls-rsvp-te-call. These changes result from: - WG chair review by Deborah - extensive post WG last call discussions on the CCAMP list. Note that we polled the MPLS WG via the mailing list on the use of the previously reserved bits in the Session object and received no comments. Changes are: == Throughout... Minor punctuation changes == Throughout s/LINK CAPABILITY/LINK_CAPABILITY/ == Abstract s/connection/Connection/ (twice) == Section 2 s/connection/Connection/ (four times) == Section 2 OLD A Call may be associated with zero, one more Connections, NEW A Call may be associated with zero, one, or more than one Connection, == Section 4.2 Use period not colon before list. == Section 3.3 s/Call Segments capabilities/Call Segment capabilities/ == Section 4.3 OLD It is useful for the ingress node of an LSP to know the link capabilities of the link between the network and the egress node. This information may allow the ingress node to tailor its LSP request to fit those capabilities and to better utilize network resources with regard to those capabilities. In particular, this may be used to achieve end-to-end spectral routing attribute negotiation for signal quality negotiation (such as BER) in photonic environments where network edges are signal regeneration capable. Similarly, it may be used to provide end-to-end spatial routing attribute negotiation in multi-area routing environments, in particular, when TE links have been bundled based on technology specific attributes. Call setup may provide a suitable mechanism to exchange information for this purpose, although several other possibilities exist. NEW In an overlay model, it is useful for the ingress node of an LSP to know the link capabilities of the link between the network and the remote overlay network. In the language of [RFC4208], the ingress node can make use of information about the link between the egress network node (NN) and the remote edge node (EN). We call this link the egress network link. This information may allow the ingress node to tailor its LSP request to fit those capabilities and to better utilize network resources with regard to those capabilities. For example, this might be used in transparent optical networks to supply information on lambda availability on egress network links, or, where the egress NN is capable of signal regeneration, it might provide a mechanism for negotiating signal quality attributes (such as bit error rate). Similarly, in multi-domain routing environments it could be used to provide end-to-end selection of component links (i.e., spatial attribute negotiation) where TE links have been bundled based on technology specific attributes. In some circumstances, the Traffic Engineering Database (TED) may contain sufficient information for decisions to be made about which egress network link to use. In other circumstances, the TED might not contain this information and Call setup may provide a suitable mechanism to exchange information for this purpose. The Call-responder may use the Call parameters to select a subset of the available egress network links between the egress NN and the remote EN, and may report these links and their capabilities on the Call response so that the Call-initiator may select a suitable link. The sections that follow indicate the cases where the TED may be used, and those where Call parameter exchange may be appropriate. == Section 4.3.1 OLD In this case, there may be no need to distribute additional link capability information over and above the information distributed by the TE and GMPLS extensions to the IGP. Further, it is possible that future extensions to these IGPs will allow the distribution of more detailed information including optical impairments. NEW In this case the ingress (and correspondingly the egress) lie within the network and there may be no need to distribute additional link capability information over and above the information distributed by the TE and GMPLS extensions to the IGP. Further, it is possible that future extensions to these IGPs will allow the distribution of more detailed information including optical impairments. == Section 4.3.2 OLD In this case, edge link information may not be visible within the core network, nor (and specifically) at other edge nodes. This may prevent an ingress from requesting suitable LSP characteristics to ensure successful LSP setup. Various solutions to this problem exist including the definition of static TE links (that is, not advertised by a routing protocol) between the core network and the edge nodes. Nevertheless, special procedures may be necessary to advertise edge TE link information to the edge nodes outside of the network without advertising the information specific to the contents of the network. In the future, when the requirements are understood on the information that needs to be supported, TE extensions to EGPs may be defined that provide this function. NEW In this case the ingress (and correspondingly the egress) lie outside the network. Edge link information may not be visible within the core network, nor (and specifically) at other edge nodes. This may prevent an ingress from requesting suitable LSP characteristics to ensure successful LSP setup. Various solutions to this problem exist, including the definition of static TE links (that is, not advertised by a routing protocol) between the NNs and ENs. Nevertheless, special procedures may be necessary to advertise to the edge nodes outside of the network information about egress network links without also advertising the information specific to the contents of the network. In the future, when the requirements on the information that needs to be supported are better understood, TE extensions to EGPs may be defined that provide this function, and new rules for leaking TE information between routing instances may be used. == Section 4.3.3 OLD When IGP and EGP solutions are not available at the UNI, there is still a requirement to have, at the local edge nodes, the knowledge of the remote edge link capabilities. The Call setup procedure provides an opportunity to discover edge link capabilities of remote edge nodes before LSP setup is attempted. The LINK CAPABILITY object is defined to allow this information to be exchanged. The information that is included in this object is similar to that distributed by GMPLS-capable IGPs (see [RFC4202]). NEW When IGP and EGP solutions are not available at the User-to-Network Interface (UNI), there is still a requirement to have, at the local edge nodes, the knowledge of the remote edge link capabilities. The Call setup procedure provides an opportunity to discover edge link capabilities of remote edge nodes before LSP setup is attempted. - The Call-responder can return information on one or more egress network links. The Call-reponder could return a full list of the available links with information about the link capabilities, or it could filter the list to return information about only those links which might be appropriate to support the Connections needed by the Call. To do this second option, the Call-responder must determine such appropriate links from information carried in the Call request including destination of the Call, and the level of service (bandwidth, protection, etc.) required. - On receiving a Call response, the Call-initiator must determine paths for the Connections (LSPs) that it will set up. The way that it does this is out of scope for this document since it is an implementation-specific, algorithmic process. However, it can take as input the information about the available egress network links as supplied in the Call response. The LINK_CAPABILITY object is defined to allow this information to be exchanged. The information that is included in this object is similar to that distributed by GMPLS-capable IGPs (see [RFC4202]). == Section 5.1 s/connection/Connection/ (twice) == Section 5.2 s/connection/Connection/ (three times) == Section 5.2.2 s/connection/Connection/ == Section 5.3 Use period not colon before list. == Section 5.3 OLD The LINK CAPABILITY object is introduced to support link capability exchange during Call setup and MAY be included in a Notify message used for Call setup. This optional object includes the bundled link local capabilities of the Call initiating node (or terminating node) indicated by the source address of the Notify message. NEW The LINK_CAPABILITY object is introduced to support link capability exchange during Call setup and MAY be included in a Notify message used for Call setup. This optional object includes the link local capabilities of a link joining the Call-initiating node (or Call-terminating node) to the network. The specific node is indicated by the source address of the Notify message. The link reported can be a single link or can be a bundled link [RFC4201]. == Section 5.3 OLD - Type 1: the link local IPv4 address (numbered bundle) using the format defined in [RFC3209] - Type 2: the link local IPv6 address (numbered bundle) using the format defined in [RFC3209] - Type 4: the link local identifier (unnumbered links and bundles) using the format defined in [RFC3477] - Type 64: the Maximum Reservable Bandwidth corresponding to this bundle (see [RFC4201]) - Type 65: the interface switching capability descriptor (see [RFC4202]) corresponding to this bundle (see also [RFC4201]). NEW - Type 1: the link local IPv4 address of a link or a numbered bundle using the format defined in [RFC3209] - Type 2: the link local IPv6 address of a link or a numbered bundle using the format defined in [RFC3209] - Type 4: the link local identifier of an unnumbered link or bundle using the format defined in [RFC3477] - Type 64: the Maximum Reservable Bandwidth corresponding to this link or bundle (see [RFC4201]) - Type 65: the interface switching capability descriptor (see [RFC4202]) corresponding to this link or bundle (see also [RFC4201]). == Section 5.3 OLD This object MAY also be used to exchange more than one bundled link capability. In this case, the following ordering MUST be followed: one identifier subobject (Type 1, 2 or 4) MUST be inserted before any capability subobject (Type 64 or 65) to which it refers. NEW A single instance of this object MAY be used to exchange capability information relating to more than one link or bundled link. In this case, the following ordering MUST be used: - each link MUST be identified by an identifier subobject (Type 1, 2 or 4) - capability subobjects (Type 64 or 65, and future subobjects) MUST be placed after the identifier subobject for the link or bundle to which they refer. Multiple instances of the LINK_CAPABILITY object within the same Notify message are not supported by this specification. In the event that a Notify message contains multiple LINK_CAPABILITY objects, the receiver SHOULD process the first one as normal and SHOULD ignore subsequent instances of the object. == Section 5.4.1 s/ATTIBUTE/ATTRIBUTE/ == Section 5.5 OLD The format and the contents of the ADMIN_STATUS object are both dictated by [RFC3473] in favor of [RFC3471]. The new "C" bit is added as shown below. NEW [RFC3473] indicates that the format and contents of the ADMIN_STATUS object are as defined in [RFC3471]. The new "C" bit is added for Call control as shown below. == Section 6.1 s/connection/Connection/ == Section 6.1 bullet two s/a further Connection/another Connection/ == Section 6.2 Use period not colon before list. == Section 6.2 bullet one s/call terminating/Call-terminating/ == Section 6.2 bullet two s/value is assigning/value in assigning/ == Section 6.2 bullet three s/call initiating/Call-initiating/ == Section 6.6.1 s/RFC3743/RFC3473/ == Section 6.6.3 3rd para Alignment fixed s/at least the five/at least five/ == Section 6.7 s/call/Call/ s/connection/Connection/ (twice) s/link failures, and the addition/link failures, or the addition/ == Section 7.3.1 s/call/Call/ == Section 9.1 OLD Note, additionally, that the process of Call establishment independent of LSP setup may be used to apply an extra level of authentication and policy to hop-by-hop LSP setup. NEW Note, additionally, that the process of independent Call establishment, where the Call is set up separately from the LSPs, may be used to apply an extra level of authentication and policy for the end-to-end LSPs above that which is available with Call-less, hop-by-hop LSP setup. == Section 9.1 s/Insect/IPsec/ == Section 9.1 ADD The frequency of Call establishment is application dependent and hard to generalize. Key exchange for Call-related message exchanges is therefore something that should be configured or arranged dynamically in different deployments according to the advice in [RFC4107]. Note that the remote RSVP-TE signaling relationship between Call endpoints is no different from the signaling relationship between LSRs that establish an LSP. That is, the LSRs are not necessarily IP-adjacent in the control plane in either case. Thus key exchange should be regarded as a remote procedure, not a single hop procedure. There are several procedures for automatic remote exchange of keys, and IKE [RFC2409] is particularly suggested in [RFC3473]. == Section 11. Updated acknowledgements == Section 12.1 Added RFC 2709 == Section 12.2 Added RFC 4107 == Section 13 Updated Arthi's coordinates == Regards, Adrian and Dimitri Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 12 Aug 2006 14:29:58 +0000 Message-ID: <054801c6be1b$61333c60$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Brungard, Deborah A, ALABS" , "Dimitri Papadimitriou" Subject: Please publish draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt Date: Sat, 12 Aug 2006 15:26:16 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0545_01C6BE23.A76B2EB0" This is a multi-part message in MIME format. ------=_NextPart_000_0545_01C6BE23.A76B2EB0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Please publish the attached I-D and notify the CCAMP mailing list. Thanks, Adrian ------=_NextPart_000_0545_01C6BE23.A76B2EB0 Content-Type: text/plain; format=flowed; name="draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt" CCAMP Working Group Editors Internet Draft D. Papadimitriou (Alcatel) Updates RFC 3473 A. Farrel (Old Dog Consulting) Proposed Category: Standard Track Expiration Date: February 2007 August 2006 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs). This document specifies how GMPLS RSVP-TE signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation. The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 1] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Table of Content 1. Conventions used in this document ............................. 3 2. Introduction .................................................. 3 2.1 Applicability to ASON ........................................ 4 3. Requirements .................................................. 4 3.1 Basic Call Function .......................................... 4 3.2 Call/Connection Separation ................................... 4 3.3 Call Segments ................................................ 5 4. Concepts and Terms ............................................ 5 4.1 What is a Call? .............................................. 5 4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs .......... 5 4.3 Exchanging Access Link Capabilities .......................... 6 4.3.1 Network-initiated Calls .................................... 7 4.3.2 User-initiated Calls ....................................... 7 4.3.3 Utilizing Call Setup ....................................... 7 5. Protocol Extensions for Calls and Connections ................. 8 5.1 Call Setup and Teardown ...................................... 8 5.2 Call Identification .......................................... 8 5.2.1 Long Form Call Identification .............................. 9 5.2.2 Short Form Call Identification ............................. 9 5.2.3 Short Form Call ID Encoding ................................ 9 5.3 LINK_CAPABILITY object ...................................... 10 5.4 Revised Message Formats ..................................... 11 5.4.1 Notify Message ............................................ 21 5.5 ADMIN_STATUS Object ......................................... 21 6. Procedures in Support of Calls and Connections ............... 32 6.1 Call/Connection Setup Procedures ............................ 32 6.2 Call Setup .................................................. 32 6.2.1 Accepting Call Setup ...................................... 54 6.2.2 Call Setup Failure and Rejection .......................... 65 6.3 Adding a Connections to a Call .............................. 65 6.3.1 Adding a Reverse Direction LSP to a Call .................. 76 6.4 Call-Free Connection Setup .................................. 76 6.5 Call Collision .............................................. 76 6.6 Call/Connection Teardown .................................... 87 6.6.1 Removal of a Connection from a Call ....................... 98 6.6.2 Removal of the Last Connection from a Call ................ 98 6.6.3 Teardown of an "Empty" Call ............................... 98 6.6.4 Attempted Teardown of a Call with Existing Connections .... 98 6.6.5 Teardown of a Call from the Egress ........................ 20 6.7 Control Plane Survivability ................................. 20 7. Applicability of Call and Connection Procedures .............. 21 7.1 Network-initiated Calls ..................................... 21 7.2 User-initiated Calls ........................................ 21 7.3 External Call Managers ...................................... 22 7.3.1 Call Segments ............................................. 22 8. Non-support of Call ID ....................................... 22 8.1 Non-Support by External Call Managers ....................... 23 8.2 Non-Support by Transit Node ................................. 23 draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 2] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 8.3 Non-Support by Egress Node .................................. 24 9. Security Considerations ...................................... 24 9.1 Call and Connection Security Considerations ................. 24 10. IANA Considerations ......................................... 25 10.1 RSVP Objects ............................................... 25 10.2 RSVP Error Codes and Error Values .......................... 25 10.3 RSVP ADMIN_STATUS object Bits .............................. 25 11. Acknowledgements ............................................ 26 12. References .................................................. 26 12.1 Normative References ....................................... 26 12.2 Informative References ..................................... 27 13. Authors' Addresses .......................................... 28 1. Conventions used in this document 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 [RFC2119]. In addition, the reader is assumed to be familiar with the terminology used in [RFC3471], [RFC3473], [RFC3477] and [RFC3945]. 2. Introduction This document defines protocol procedures and extensions to support Calls within Generalized MPLS (GMPLS). A Call is an association between endpoints and possibly between key transit points (such as network boundaries) in support of an instance of a service. The end-to-end association is termed a "Call," and the association between two transit points or between an endpoint and a transit point is termed a "Call Segment." An entity that processes a Call or Call Segment is called a "Call Manager." A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In GMPLS such Connections are known as Label Switched Paths (LSPs). A Call may be associated with zero, one, or more than one Connection, and a Connection may be associated with zero or one Call. Thus full and logical Call/Connection separation is needed. An example of the requirement for Calls can be found in the ITU-T's Automatically Switched Optical Network (ASON) architecture [G.8080] and specific requirements for support of Calls in this context can be found in [RFC4139]. Note, however, that while the mechanisms described in this document meet the requirements stated in [RFC4139], they have wider applicability. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 3] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 The mechanisms defined in this document are equally applicable to any packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable interfaces, LSC interfaces, or FSC interfaces. The mechanisms and protocol extensions are backward compatible, and can be used for Call management where only the Call Managers need to be aware of the protocol extensions. 2.1 Applicability to ASON [RFC4139] details the requirements on GMPLS signaling to satisfy the ASON architecture described in [G.8080]. The mechanisms described in this document meet the requirements for Calls as described in Sections 4.2 and 4.3 of [RFC4139] and the additional Call-related requirements in Sections 4.4, 4.7, 5 and 6 of [RFC4139]. [ASON-APPL] describes the applicability of GMPLS protocols to the ASON architecture. 3. Requirements 3.1 Basic Call Function The Call concept is used to deliver the following capabilities. - Verification and identification of the Call initiator (prior to LSP setup). - Support of virtual concatenation with diverse path component LSPs. - Association of multiple LSPs with a single Call (note aspects related to recovery are detailed in [RFC4426] and [GMPLS-E2E]). - Facilitation of control plane operations by allowing operational status change of the associated LSP. Procedures and protocol extensions to support Call setup, and the association of Calls with Connections are described in Section 5 and onwards of this document. 3.2 Call/Connection Separation Full and logical Call and Connection separation is required. That is: - It MUST be possible to establish a Connection without dependence on a Call. - It MUST be possible to establish a Call without any associated Connections. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 4] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 - It MUST be possible to associate more than one Connection with a Call. - Removal of the last Connection associated with a Call SHOULD NOT result in the automatic removal of the Call except as a matter of local policy at the ingress of the Call. - Signaling of a Connection associated with a Call MUST NOT require the distribution or retention of Call-related information (state) within the network. 3.3 Call Segments Call Segment capabilities MUST be supported. Procedures and (GMPLS) RSVP-TE signaling protocol extensions to support Call Segments are described in Section 7.3.1 of this document. 4. Concepts and Terms The concept of a Call and a Connection are also discussed in the ASON architecture [G.8080] and [RFC4139]. This section is not intended as a substitute for those documents, but is a brief summary of the key terms and concepts. 4.1 What is a Call? A Call is an agreement between endpoints possibly in cooperation with the nodes that provide access to the network. Call setup may include capability exchange, policy, authorization and security. A Call is used to facilitate and manage a set of Connections that provide end to end data services. While Connections require state to be maintained at nodes along the data path within the network, Calls do not involve the participation of transit nodes except to forward the Call management requests as transparent messages. A Call may be established and maintained independently of the Connections that it supports. 4.2 A Hierarchy of Calls, Connections, Tunnels and LSPs Clearly there is a hierarchical relationship between Calls and Connections. One or more Connections may be associated with a Call. A Connection may not be part of more than one Call. A Connection may, however, exist without a Call. In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS TE Tunnel. Commonly a Tunnel is identified with a single LSP, but it draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 5] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 should be noted that for protection, load balancing and many other functions, a Tunnel may be supported by multiple parallel LSPs. The following identification reproduces this hierarchy. - Call IDs are unique within the context of the pair of addresses that are the source and destination of the Call. - Tunnel IDs are unique within the context of the Session (that is the destination of the Tunnel). Applications may also find it convenient to keep the Tunnel ID unique within the context of a Call. - LSP IDs are unique within the context of a Tunnel. Note that the Call_ID value of zero is reserved and MUST NOT be used during LSP-independent Call establishment. Throughout the remainder of this document, the terms LSP and Tunnel are used interchangeably with the term Connection. The case of a Tunnel that is supported by more than one LSP is covered implicitly. 4.3 Exchanging Access Link Capabilities In an overlay model, it is useful for the ingress node of an LSP to know the link capabilities of the link between the network and the remote overlay network. In the language of [RFC4208], the ingress node can make use of information about the link between the egress network node (NN) and the remote edge node (EN). We call this link the egress network link. This information may allow the ingress node to tailor its LSP request to fit those capabilities and to better utilize network resources with regard to those capabilities. For example, this might be used in transparent optical networks to supply information on lambda availability on egress network links, or, where the egress NN is capable of signal regeneration, it might provide a mechanism for negotiating signal quality attributes (such as bit error rate). Similarly, in multi-domain routing environments it could be used to provide end-to-end selection of component links (i.e., spatial attribute negotiation) where TE links have been bundled based on technology specific attributes. In some circumstances, the Traffic Engineering Database (TED) may contain sufficient information for decisions to be made about which egress network link to use. In other circumstances, the TED might not contain this information and Call setup may provide a suitable mechanism to exchange information for this purpose. The Call-responder may use the Call parameters to select a subset of the available egress network links between the egress NN and the remote EN, and may report these links and their capabilities on the Call response so that the Call-initiator may select a suitable link. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 6] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 The sections that follow indicate the cases where the TED may be used, and those where Call parameter exchange may be appropriate. 4.3.1 Network-initiated Calls In this case the ingress (and correspondingly the egress) lie within the network and there may be no need to distribute additional link capability information over and above the information distributed by the TE and GMPLS extensions to the IGP. Further, it is possible that future extensions to these IGPs will allow the distribution of more detailed information including optical impairments. 4.3.2 User-initiated Calls In this case the ingress (and correspondingly the egress) lie outside the network. Edge link information may not be visible within the core network, nor (and specifically) at other edge nodes. This may prevent an ingress from requesting suitable LSP characteristics to ensure successful LSP setup. Various solutions to this problem exist, including the definition of static TE links (that is, not advertised by a routing protocol) between the NNs and ENs. Nevertheless, special procedures may be necessary to advertise to the edge nodes outside of the network information about egress network links without also advertising the information specific to the contents of the network. In the future, when the requirements on the information that needs to be supported are better understood, TE extensions to EGPs may be defined that provide this function, and new rules for leaking TE information between routing instances may be used. 4.3.3 Utilizing Call Setup When IGP and EGP solutions are not available at the User-to-Network Interface (UNI), there is still a requirement to have, at the local edge nodes, the knowledge of the remote edge link capabilities. The Call setup procedure provides an opportunity to discover edge link capabilities of remote edge nodes before LSP setup is attempted. - The Call-responder can return information on one or more egress network links. The Call-reponder could return a full list of the available links with information about the link capabilities, or it could filter the list to return information about only those links which might be appropriate to support the Connections needed by the Call. To do this second option, the Call-responder must determine such appropriate links from information carried in the Call request including destination of the Call, and the level of service (bandwidth, protection, etc.) required. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 7] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 - On receiving a Call response, the Call-initiator must determine paths for the Connections (LSPs) that it will set up. The way that it does this is out of scope for this document since it is an implementation-specific, algorithmic process. However, it can take as input the information about the available egress network links as supplied in the Call response. The LINK_CAPABILITY object is defined to allow this information to be exchanged. The information that is included in this object is similar to that distributed by GMPLS-capable IGPs (see [RFC4202]). 5. Protocol Extensions for Calls and Connections This section describes the protocol extensions needed in support of Call identification and management of Calls and Connections. Procedures for the use of these protocol extensions are described in Section 6. 5.1 Call Setup and Teardown Calls are established independently of Connections through the use of the Notify message. The Notify message is a targeted message and does not follow the path of LSPs through the network. Simultaneous Call and Connection establishment (sometimes referred to as piggybacking) is not supported. 5.2 Call Identification As soon as the concept of a Call is introduced, it is necessary to support some means of identifying the Call. This becomes particularly important when Calls and Connections are separated and Connections must contain some reference to the Call. A Call may be identified by a sequence of bytes that may have considerable (but not arbitrary) length. A Call ID of 40 bytes would not be unreasonable. It is not the place of this document to supply rules for encoding or parsing Call IDs, but it must provide a suitable means to communicate Call IDs within the protocol. The full Call identification is referred to as the long Call ID. The Call_ID is only relevant at the sender and receiver nodes. Maintenance of this information in the signaling state is not mandated at any intermediate node. Thus no change in [RFC3473] transit implementations is required and there are no backward compatibility issues. Forward compatibility is maintained by using the existing default values to indicate that no Call processing is required. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 8] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Further, the long Call ID is not required as part of the Connection (LSP) state even at the sender and receiver nodes so long as some form of correlation is available. This correlation is provided through the short Call ID. 5.2.1 Long Form Call Identification The long Call ID is only required on the Notify message used to establish the Call. It is carried in the "Session Name" field of the SESSION_ATTRIBUTE Object on the Notify message. A unique value per Call is inserted in the "Session Name" field by the initiator of the Call. Subsequent network nodes MAY inspect this object and MUST forward this object transparently across network interfaces until reaching the egress node. Note that the structure of this field MAY be the object of further formatting depending on the naming convention(s). However, [RFC3209] defines the "Session Name" field as a Null padded display string, and that any formatting conventions for the Call ID must be limited to this scope. 5.2.2 Short Form Call Identification The Connections (LSPs) associated with a Call need to carry a reference to the Call - the short Call ID. A new field is added to the signaling protocol to identify an individual LSP with the Call to which it belongs. The new field is a 16-bit identifier (unique within the context of the address pairing provided by the Tunnel_End_Point_Address and the Sender_Address of the SENDER TEMPLATE object) that MUST be exchanged on the Notify message during Call initialization and is used on all subsequent LSP messages that are associated with the Call. This identifier is known as the short Call ID and is encoded as described in Section 5.2.3. The Call ID MUST NOT be used as part of the processing to determine the session to which an RSVP signaling message applies. This does not generate any backward compatibility issue since the reserved field of the SESSION object defined in [RFC3209] MUST NOT be examined on receipt. In the unlikely case of short Call_ID exhaustion, local node policy decides upon specific actions to be taken, but might include the use of second Sender_Address. Local policy details are outside of the scope of this document. 5.2.3 Short Form Call ID Encoding The short Call ID is carried in a 16-bit field in the SESSION object carried on the Notify message used during Call setup, and on all messages during LSP setup and management. The field used was previously reserved (MUST be set to zero on transmission and ignored draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 9] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 on receipt). This ensures backward compatibility with nodes that do not utilize Calls. The figure below shows the new version of the object. Class =3D SESSION, Class-Num =3D 1, C-Type =3D 7(IPv4)/8(IPv6) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv4/IPv6 Tunnel end point address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call_ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209]) Call_ID: 16 bits A 16-bit identifier used in the SESSION object that remains constant over the life of the Call. The Call_ID value MUST be set to zero when there is no corresponding Call. Tunnel ID: 16 bits (see [RFC3209]) Extended Tunnel ID: 32 bits/128 bits (see [RFC3209]) 5.3 LINK_CAPABILITY object The LINK_CAPABILITY object is introduced to support link capability exchange during Call setup and MAY be included in a Notify message used for Call setup. This optional object includes the link local capabilities of a link joining the Call-initiating node (or Call-terminating node) to the network. The specific node is indicated by the source address of the Notify message. The link reported can be a single link or can be a bundled link [RFC4201]. The Class Number is selected so that the nodes that do not recognize this object drop it silently. That is, the top bit is set and the next bit is clear. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 10] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 This object has the following format: Class-Num =3D TBA (form 10bbbbbb), C_Type =3D 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The contents of the LINK_CAPABILITY object is defined as series of variable-length data items called subobjects. The subobject format is defined in [RFC3209]. The following subobjects are currently defined. - Type 1: the link local IPv4 address of a link or a numbered bundle using the format defined in [RFC3209] - Type 2: the link local IPv6 address of a link or a numbered bundle using the format defined in [RFC3209] - Type 4: the link local identifier of an unnumbered link or bundle using the format defined in [RFC3477] - Type 64: the Maximum Reservable Bandwidth corresponding to this link or bundle (see [RFC4201]) - Type 65: the interface switching capability descriptor (see [RFC4202]) corresponding to this link or bundle (see also [RFC4201]). Note: future revisions of this document may extend the above list. A single instance of this object MAY be used to exchange capablity information relating to more than one link or bundled link. In this case, the following ordering MUST be used: - each link MUST be identified by an identifier subobject (Type 1, 2 or 4) - capability subobjects (Type 64 or 65, and future subobjects) MUST be placed after the identifier subobject for the link or bundle to which they refer. Mulitple instances of the LINK_CAPABILITY object within the same Notify message are not supported by this specification. In the event that a Notify message contains multiple LINK_CAPABILITY objects, the receiver SHOULD process the first one as normal and SHOULD ignore subsequent instances of the object. 5.4 Revised Message Formats The Notify message is enhanced to support Call establishment and teardown of Calls. See Section 6 for a description of the procedures. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 11] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 5.4.1 Notify Message The Notify message is modified in support of Call establishment by the optional addition of the LINK CAPABILTY object. Further, the SESSION ATTRIBUTE object is added to the sequence to carry the long Call ID. The presence of the SESSION ATTRIBUTE object MAY be used to distinguish a Notify message used for Call management, but see Section 5.5 for another mechanism. The MAY be used to simultaneously set up multiple Calls. The format of the Notify Message is as follows: ::=3D [ ] [[ | ]...] [ ] ::=3D [ ] ::=3D [ ] [ ...] [ ] [ ] [ | ] ::=3D see [RFC3473] ::=3D see [RFC3473] 5.5 ADMIN_STATUS Object Notify messages exchanged for Call control and management purposes carry a specific new bit (the Call Management or C bit) in the ADMIN STATUS object. [RFC3473] indicates that the format and contents of the ADMIN_STATUS object are as defined in [RFC3471]. The new "C" bit is added for Call control as shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved |C|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reflect (R): 1 bit - see [RFC3471] Testing (T): 1 bit - see [RFC3471] Administratively down (A): 1 bit - see [RFC3471] Deletion in progress (D): 1 bit - see [RFC3471] draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 12] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Call Management (C): 1 bit This bit is set when the message is being used to control and manage a Call. The procedures for the use of the C bit are described in Section 6. 6. Procedures in Support of Calls and Connections 6.1 Call/Connection Setup Procedures This section describes the processing steps for Call and Connection setup. There are three cases considered: - A Call is set up without any associated Connection. It is assumed that Connections will be added to the Call at a later time, but this is neither a requirement nor a constraint. - A Connection may be added to an existing Call. This may happen if the Call was set up without any associated Connections, or if another Connection is added to a Call that already has one or more associated Connections. - A Connection may be established without any reference to a Call (see Section 6.4). This encompasses the previous LSP setup procedure. Note that a Call MAY NOT be imposed upon a Connection that is already established. To do so would require changing the short Call ID in the SESSION OBJECT of the existing LSPs and this would constitute a change in the Session Identifier. This is not allowed by existing protocol specifications. Call and Connection teardown procedures are described later in Section 6.6. 6.2 Call Setup A Call is set up before, and independent of, LSP (i.e. Connection) setup. Call setup MAY necessitate verification of the link status and link capability negotiation between the Call ingress node and the Call egress node. The procedure described below is applied only once for a Call and hence only once for the set of LSPs associated with a Call. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 13] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 The Notify message (see [RFC3473]) is used to signal the Call setup request and response. The new Call Management (C) bit in the ADMIN_STATUS object is used to indicate that this Notify is managing a Call. The Notify message is sent with source and destination IPv4/IPv6 addresses set to any of the routable ingress/egress node addresses respectively. At least one session MUST be listed in the of the Notify message. In order to allow for long identification of the Call, the SESSION_ATTRIBUTE object is added as part of the . Note that the ERROR SPEC object is not relevant in Call setup and MUST carry the Error Code zero ("Confirmation") to indicate that there is no error. During Call setup, the ADMIN STATUS object is sent with the following bits set. Bits not listed MUST be set to zero. R - to cause the egress to respond C - to indicate that the Notify message is managing a Call. The SESSION, SESSION ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects included in the of the Notify message are built as follows. - The SESSION object includes as Tunnel_End_Point_Address any of the Call-terminating (egress) node's IPv4/IPv6 routable addresses. The Call_ID is set to a non-zero value unique within the context of the address pairing provided by the Tunnel_End_Point_Address and the Sender_Address from the SENDER TEMPLATE object (see below). This value will be used as the short Call ID carried on all messages for LSPs associated with this Call. Note that the Call_ID value of zero is reserved and MUST NOT be used since it will be present in SESSION objects of LSPs that are not associated with Calls. The Tunnel_ID of the SESSION object is not relevant for this procedure and SHOULD be set to zero. The Extended_Tunnel_ID of the SESSION object is not relevant for this procedure and MAY be set to zero or to an address of the ingress node. - The SESSION ATTRIBUTE object contains priority flags. Currently no use of these flags is envisioned, however, future work may identify value in assigning priorities to Calls; accordingly the Priority fields MAY be set to non-zero values. None of the Flags in the SESSION ATTRIBUTE object is relevant to this process and this field SHOULD be set to zero. The Session Name field is used to carry the long Call Id as described in Section 5. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 14] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 - The SENDER_TEMPLATE object includes as Sender Address any of the Call-initiating (ingress) node's IPv4/IPv6 routable addresses. The LSP_ID is not relevant and SHOULD be set to zero. - The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC objects MUST be ignored upon receipt and SHOULD be set to zero when sent. Additionally, ingress/egress nodes that need to communicate their respective link local capabilities may include a LINK_CAPABILITY object in the Notify message. The receiver of a Notify message may identify whether it is part of Call management or reporting an error by the presence or absence of the SESSION ATTRIUBTE object in the . Full clarity, however, may be achieved by inspection of the new Call Management (C) bit in the ADMIN STATUS object. Note that the POLICY_DATA object may be included in the and MAY be used to identify requestor credentials, account numbers, limits, quotas, etc. This object is opaque to RSVP, which simply passes it to policy control when required. Message IDs MUST be used during Call setup. 6.2.1 Accepting Call Setup A node that receives a Notify message carrying the ADMIN STATUS object with the R and C bits set is being requested to set up a Call. The receiver MAY perform authorization and policy according to local requirements. If the Call is acceptable, the receiver responds with a Notify message reflecting the information from the Call request with two exceptions. - The responder removes any LINK CAPABLITY object that was received and MAY insert a LINK_CAPABILITY object that describes its own access link. - The ADMIN STATUS object is sent with only the C bit set. All other bits MUST be set to zero. The responder MUST use the Message ID object to ensure reliable delivery of the response. If no Message ID Acknowledgement is received after the configured number of retries, the responder SHOULD continue to assume that the Call was successfully established. Call liveliness procedures are covered in Section 6.7. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 15] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 6.2.2 Call Setup Failure and Rejection Call setup may fail or be rejected. If the Notify message can not be delivered, no Message ID acknowledgement will be received by the sender. In the event that the sender has retransmitted the Notify message a configurable number of times without receiving a Message ID Acknowledgement (as described in [RFC2961]), the initiator SHOULD declare the Call failed and SHOULD send a Call teardown request (see Section 6.6). It is also possible that a Message ID Acknowledgement is received but no Call response Notify message is received. In this case, the initiator MAY re-send the Call setup request a configurable number of times (see Section 6.7) before declaring that the Call has failed. At this point the initiator MUST send a Call teardown request (see Section 6.6). If the Notify message cannot be parsed or is in error it MAY be responded to with a Notify message carrying the error code 13 ("Unknown object class") or 14 ("Unknown object C-Type") if appropriate to the error detected. The Call setup MAY be rejected by the receiver because of security, authorization or policy reasons. Suitable error codes already exist [RFC2205] and can be used in the ERROR SPEC object included in the Notify message sent in response. Error response Notify messages SHOULD also use the Message ID object to achieve reliable delivery. No action should be taken on the failure to receive a Message ID Acknowledgement after the configured number of retries. 6.3 Adding a Connections to a Call Once a Call has been established, LSPs can be added to the Call. Since the short Call ID is part of the SESSION Object, any LSP that has the same Call ID value in the SESSION Object belongs to the same Call, and the Notify message used to establish the Call carried the same Call ID in its SESSION object. There will be no confusion between LSPs that are associated with a Call and those which are not, since the Call ID value MUST be equal to zero for LSPs which are not associated with a Call, and MUST NOT be equal to zero for a valid Call ID. LSPs for different Calls can be distinguished because the Call ID is unique within the context of the source address (in the SENDER TEMPLATE object) and the destination address (in the SESSION object). draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 16] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Ingress and egress nodes MAY group together LSPs associated with the same Call and process them as a group according to implementation requirements. Transit nodes need not be aware of the association of multiple LSPs with the same Call. The ingress node MAY choose to set the "Session Name" of an LSP to match the long Call ID of the associated Call. The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages including on Notify messages that pertain to the LSP and MUST be ignored. 6.3.1 Adding a Reverse Direction LSP to a Call Note that once a Call has been established it is symmetric. That is, either end of the Call may add LSPs to the Call. Special care is needed when managing LSPs in the reverse direction since the addresses in the SESSION and SENDER TEMPLATE are reversed. However, since the short Call ID is unique in the context of a given ingress-egress address pair it may safely be used to associate the LSP with the Call. Note that since Calls are defined here to be symmetrical, the issue of potential Call ID collision arises. This is discussed in Section 6.5. 6.4 Call-Free Connection Setup It continues to be possible to set up LSPs as per [RFC3473] without associating them with a Call. If the short Call ID in the SESSION Object is set to zero, there is no associated Call and the Session Name field in the SESSION ATTRIBUTE object MUST be interpreted simply as the name of the session (see [RFC3209]). The C bit of the ADMIN STATUS object MUST NOT be set on messages for LSP control, including on Notify messages that pertain to LSPs, and MUST be ignored when received on such messages. 6.5 Call Collision Since Calls are symmetrical, it is possible that both ends of a Call will attempt to establish Calls with the same long Call IDs at the same time. This is only an issue if the source and destination address pairs match. This situation can be avoided by applying some rules to the contents of the long Call ID, but such mechanisms are outside the scope of this document. If a node that has sent a Call setup request and has not yet received a response, itself receives a Call setup request with the same long draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 17] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Call ID and matching source/destination addresses, it SHOULD process as follows. - If its source address is numerically greater than the remote source address, it MUST discard the received message and continue to wait for a response to its setup request. - If its source address is numerically smaller than the remote source address, it MUST discard state associated with the Call setup that it initiated, and MUST respond to the received Call setup. If a node receives a Call setup request carrying an address pair and long Call ID that match an existing Call, the node MUST return an error message (Notify message) with the new Error Code "Call Management" and the new Error Value "Duplicate Call" in response to the new Call request, and MUST NOT make any changes to the existing Call. A further possibility for contention arises when short Call IDs are assigned by a pair of nodes for two distinct Calls that are set up simultaneously using different long Call IDs. In this event a node receives a Call setup request carrying a short Call ID that matches one that it previously sent for the same address pair. The following processing MUST be followed. - If the receiver's source address is numerically greater than the remote source address, the receiver returns an error (Notify message) with the new Error Code "Call Management" and the new Error Value "Call ID Contention". - If the receiver's source address is numerically less than the remote source address, the receiver accepts and processes the Call request. It will receive an error message sent as described above, and at that point it selects a new short Call ID and re-sends the Call setup request. 6.6 Call/Connection Teardown As with Call/Connection setup, there are several cases to consider. - Removal of a Connection from a Call - Removal of the last Connection from a Call - Teardown of an "empty" Call The case of tearing down an LSP that is not associated with a Call does not need to be examined as it follows exactly the procedures described in [RFC3473]. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 18] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 6.6.1 Removal of a Connection from a Call An LSP that is associated with a Call may be deleted using the standard procedures described in [RFC3473]. No special procedures are required. Note that it is not possible to remove an LSP from a Call without deleting the LSP. It is not valid to change the short Call ID from non-zero to zero since this involves a change to the SESSION object, which is not allowed. 6.6.2 Removal of the Last Connection from a Call When the last LSP associated with a Call is deleted, the question arises as to what happens to the Call. Since a Call may exist independently of Connections, it is not always acceptable to say that the removal of the last LSP from a Call removes the Call. The removal of the last LSP does not remove the Call and the procedures described in the next Section MUST be used to delete the Call. 6.6.3 Teardown of an "Empty" Call When all LSPs have been removed from a Call, the Call may be torn down or left for use by future LSPs. Deletion of Calls is achieved by sending a Notify message just as for Call setup, but the ADMIN STATUS object carries the R, D and C bits on the teardown request and the D and C bits on the teardown response. Other bits MUST be set to zero. When a Notify message is sent for deleting a Call and the initiator does not receive the corresponding reflected Notify message (or possibly even the Message ID Ack), the initiator MAY retry the deletion request using the same retry procedures as used during Call establishment. If no response is received after full retry, the node deleting the Call MAY declare the Call deleted, but under such circumstances the node SHOULD avoid re-using the long or short Call IDs for at least five times the Notify refresh period. 6.6.4 Attempted Teardown of a Call with Existing Connections If a Notify request with the D bit of the ADMIN STATUS object set is received for a Call for which LSPs still exist, the request MUST be rejected with the Error Code "Call Management" and Error Value "Connections Still Exist". The state of the Call MUST NOT be changed. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 19] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 6.6.5 Teardown of a Call from the Egress Since Calls are symmetric they may be torn down from the ingress or egress. When the Call is "empty" (has no associated LSPs) it may be deleted by the egress sending a Notify message just as described above. Note that there is a possibility that both ends of a Call initiate Call deletion at the same time. In this case, the Notify message acting as teardown request MAY be interpreted by its recipient as a teardown response. But since the Notify messages acting as teardown requests carry the R bit in the ADMIN STATUS object, they MUST be responded to anyway. If a teardown request Notify message is received for an unknown Call ID, it is, nevertheless, responded to in the affirmative. 6.7 Control Plane Survivability Delivery of Notify messages is secured using message ID acknowledgements as described in previous sections. Notify messages provide end-to-end communication that does not rely on constant paths through the network. Notify messages are routed according to IGP routing information. No consideration is, therefore, required for network resilience (for example, make-before-break, protection, fast re-route), although end-to-end resilience is of interest for node restart and completely disjoint networks. Periodic Notify messages SHOULD be sent by the initiator and terminator of the Call to keep the Call alive and to handle ingress or egress node restart. The time period for these retransmissions is a local matter, but it is RECOMMENDED that this period should be twice the shortest refresh period of any LSP associated with the Call. When there are no LSPs associated with a Call, an LSR is RECOMMENDED to use a refresh period of no less than one minute. The Notify messages are identical to those sent as if establishing the Call for the first time, except for the LINK_CAPABILITY object, which may have changed since the Call was first established, due to, e.g., the establishment of Connections, link failures, or the addition of new component links. The current link information is useful for the establishment of subsequent Connections. A node that receives a refresh Notify message carrying the R bit in the ADMIN STATUS object MUST respond with a Notify response. A node that receives a refresh Notify message (response or request) MAY reset its timer - thus, in normal processing, Notify refreshes involve a single exchange once per time period. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 20] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 A node (sender or receiver) that is unsure of the status of a Call MAY immediately send a Notify message as if establishing the Call for the first time. Failure to receive a refresh Notify request has no specific meaning. A node that fails to receive a refresh Notify request MAY send its own refresh Notify request to establish the status of the Call. If a node receives no response to a refresh Notify request (including no Message ID Acknowledgement) a node MAY assume that the remote node is unreachable or unavailable. It is a local policy matter whether this causes the local node to teardown associated LSPs and delete the Call. In the event that an edge node restarts without preserved state, it MAY relearn LSP state from adjacent nodes and Call state from remote nodes. If a Path or Resv message is received with a non-zero Call ID but without the C bit in the ADMIN STATUS, and for a Call ID that is not recognized, the receiver is RECOMMENDED to assume that the Call establishment is delayed and ignore the received message. If the Call setup never materializes, the failure by the restarting node to refresh state will cause the LSPs to be torn down. Optionally, the receiver of such an LSP message for an unknown Call ID may return an error (PathErr or ResvErr message) with the error code "Call Management" and Error Value "Unknown Call ID". 7. Applicability of Call and Connection Procedures This section considers the applicability of the different Call establishment procedures at the NNI and UNI reference points. This section is informative and is not intended to prescribe or prevent other options. 7.1 Network-initiated Calls Since the link properties and other traffic-engineering attributes are likely known through the IGP, the LINK_CAPABILITY object is not usually required. In multi-domain networks, it is possible that access link properties and other traffic-engineering attributes are not known since the domains do not share this sort of information. In this case, the Call setup mechanism may include the LINK_CAPABILITY object. 7.2 User-initiated Calls It is possible that the access link properties and other traffic- engineering attributes are not shared across the core network. In this case, the Call setup mechanism may include the LINK_CAPABILITY object. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 21] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Further, the first node within the network may be responsible for managing the Call. In this case, the Notify message that is used to set up the Call is addressed by the user network edge node to the first node of the core network. Moreover, neither the long Call ID nor the short Call ID is supplied (the Session Name Length is set to zero and the Call ID value is set to zero). The Notify message is passed to the first network node which is responsible for generating the long and short Call IDs before dispatching the message to the remote Call end point (which is known from the SESSION object). Further, when used in an overlay context, the first core node is allowed (see [RFC4208]) to replace the Session Name assigned by the ingress node and passed in the Path message. In the case of Call management, the first network node: 1) MAY insert a long Call ID in the Session Name of a Path message 2) MUST replace the Session Name with that originally issued by the user edge node when it returns the Resv message to the ingress node. 7.3 External Call Managers Third party Call management agents may be used to apply policy and authorization at a point that is neither the initiator nor terminator of the Call. The previous example is a particular case of this, but the process and procedures are identical. 7.3.1 Call Segments Call Segments exist between a set of default and configured External Call Managers along a path between the ingress and egress nodes, and use the protocols described in this document. The techniques that are used by a given service provider to identify which External Call Managers within its network should process a given Call are beyond the scope of this document. An External Call Manager uses normal IP routing to route the Notify message to the next External Call Manager. Notify messages (requests and responses) are therefore encapsulated in IP packets that identify the sending and receiving External Call Managers, but the addresses used to identify the Call (the Sender Address in the SENDER TEMPLATE object and the Tunnel Endpoint Address in the SESSION object) continue to identify the endpoints of the Call. 8. Non-support of Call ID It is important that the procedures described above operate as seamlessly as possible with legacy nodes that do not support the extensions described. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 22] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Clearly, there is no need to consider the case where the Call initiator does not support Call setup initiation. 8.1 Non-Support by External Call Managers It is unlikely that a Call initiator will be configured to send Call establishment Notify requests to an external Call manager, including the first network node, if that node does not support Call setup. A node that receives an unexpected Call setup request will fall into one of the following categories. - Node does not support RSVP. The message will fail to be delivered or responded. No Message ID Acknowledgement will be sent. The initiator will retry and then give up. - Node supports RSVP or RSVP-TE but not GMPLS. The message will be delivered but not understood. It will be discarded. No Message ID Acknowledgement will be sent. The initiator will retry and then give up. - Node supports GMPLS but not Call management. The message will be delivered, but parsing will fail because of the presence of the SESSION ATTRIBUTE object. A Message ID Acknowledgement may be sent before the parse fails. When the parse fails the Notify message may be discarded in which case the initiator will retry and then give up, alternatively a parse error may be generated and returned in a Notify message which will indicate to the initiator that Call management is not supported. 8.2 Non-Support by Transit Node Transit nodes SHOULD not examine Notify messages that are not addressed to them. However, they will see short Call IDs in all LSPs associated with Calls. Previous specifications state that these fields SHOULD be ignored on receipt and MUST be transmitted as zero. This is interpreted by some implementations as meaning that the fields should be zeroed before the objects are forwarded. If this happens, LSP setup will not be possible. If either of the fields is zeroed either on the Path or the Resv message, the Resv message will reach the initiator with the field set to zero - this is indication to the initiator that some node in the network is preventing Call management. Use of Explicit Routes may help to mitigate this issue by avoiding such nodes. Ultimately, however, it may be necessary to upgrade the offending nodes to handle these protocol extensions. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 23] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 8.3 Non-Support by Egress Node It is unlikely that an attempt will be made to set up a Call to remote node that does not support Calls. If the egress node does not support Call management through the Notify message it will react (as described in Section 8.1) in the same way as an External Call Manager. 9. Security Considerations Please refer to each of the referenced documents for a description of the security considerations applicable to the features that they provide. 9.1 Call and Connection Security Considerations Call setup is vulnerable to attacks both of spoofing and denial of service. Since Call setup uses Notify messages, the process can be protected by the measures applicable to securing those messages as described in [RFC3473]. Note, additionally, that the process of independent Call establishment, where the Call is set up separately from the LSPs, may be used to apply an extra level of authentication and policy for the end-to-end LSPs above that which is available with Call-less, hop-by-hop LSP setup. It may be possible to protect the Call setup exchange using end-to-end security mechanisms such as those provided by IPsec (see [RFC2402] and [RFC2406]). The frequency of Call establishment is application dependent and hard to generalize. Key exchange for Call-related message exchanges is therefore something that should be configured or arranged dynamically in different deployments according to the advice in [RFC4107]. Note that the remote RSVP-TE signaling relationship between Call endpoints is no different from the signaling relationship between LSRs that establish an LSP. That is, the LSRs are not necessarily IP-adjacent in the control plane in either case. Thus key exchange should be regarded as a remote procedure, not a single hop procedure. There are several procedures for automatic remote exchange of keys, and IKE [RFC2409] is particularly suggested in [RFC3473]. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 24] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 10. IANA Considerations 10.1 RSVP Objects A new RSVP object is introduced: o LINK_CAPABILITY object Class-Num =3D TBA (form 10bbbbbb) The Class Number is selected so that nodes not recognizing this object drop it silently. That is, the top bit is set and the next bit is cleared. C-Type =3D 1 (TE Link Capabilities) The LINK_CAPABILITY object is only defined for inclusion on Notify messages. Refer to Section 5.3 of this document. 10.2 RSVP Error Codes and Error Values New RSVP Error Codes and Error Values are introduced o Error Codes: - Call Management (value TBA) o Error Values: - Call Management/Call ID Contention (value TBA) - Call Management/Connections still Exist (value TBA) - Call Management/Unknown Call ID (value TBA) - Call Management/Duplicate Call (value TBA) 10.3 RSVP ADMIN_STATUS object Bits [GMPLS-E2E] requests IANA to manage the bits of the RSVP ADMIN_STATUS object. One new bit, the C bit, is defined in this document. Bit number 28 is suggested. See Section 5.5 of this document. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 25] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 11. Acknowledgements The authors would like to thank George Swallow, Yakov Rekhter, Lou Berger, Jerry Ash and Kireeti Kompella for their very useful input to, and comments on, an earlier revision of this document. Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions during and after working group last call, and to Deborah Brungard for a final, detailed review. 12. References 12.1 Normative References [GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, "RSVP- TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery," draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in progress. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [RFC2205] R. Braden et al., "Resource ReSerVation Protocol (RSVP)- Version 1 Functional Specification," RFC 2205, September 1997. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header," RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Payload (ESP)," RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. [RFC3471] L. Berger (Editor) et al., "Generalized MPLS - Signaling Functional Description," RFC 3471, January 2003. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 26] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 [RFC3473] L. Berger (Editor) et al., "Generalized MPLS Signaling - RSVP-TE Extensions," RFC 3473, January 2003. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)," RFC 3477, January 2003. [RFC3945] E. Mannie, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4139] D. Papadimitriou, et al., "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)," RFC 4139, July 2005. [RFC4201] Kompella K., Rekhter Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering," RFC 4201, October 2005. [RFC4202] Kompella, K. and Y. Rekhter (Editors) et al., "Routing Extensions in Support of Generalized MPLS," RFC 4202, October 2005. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [RFC4426] Lang, J.P., and B. Rajagopalan (Editors) et al., "Generalized MPLS Recovery Functional Specification," RFC 4426, March 2006. 12.2 Informative References [ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS) RSVP-TE signaling usage in support of Automatically Switched Optical Network (ASON)," draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress. [RFC4107] S. Bellovin and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. For information on the availability of the following document, please see http://www.itu.int. [G.8080] ITU-T, "Architecture for the Automatically Switched Optical Network (ASON)," Recommendation G.8080/ Y.1304, November 2001 (and Revision, January 2003). draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 27] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 13. Authors' Addresses Dimitri Papadimitriou (Alcatel) Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245 EMail: John.E.Drake2@boeing.com Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com Zafar Ali (Cisco) 100 South Main St. #200 Ann Arbor, MI 48104, USA EMail: zali@cisco.com Arthi Ayyangar (Nuova Systems) 2600 San Tomas Expressway Santa Clara, CA 95051 EMail: arthi@nuovasystems.com Don Fedyk (Nortel Networks) 600 Technology Park Drive Billerica, MA, 01821, USA Email: dwfedyk@nortel.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 28] =0C Papadimitriou and Farrel - Expires February 2007 August 2006 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt [Page 29] =0C ------=_NextPart_000_0545_01C6BE23.A76B2EB0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Aug 2006 10:25:19 +0000 Message-ID: <036a01c6bd30$35423890$9b849ed9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Two new communications from the OIF Date: Fri, 11 Aug 2006 11:23:27 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We have received two new communications from the OIF from their recent meeting and in response to our communications on the OIF E-NNI and on Ethernet traffic parameters. The latter asks a question of us, to which we need to respond. There appears to be no response to either of our communications on draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt and on 1:n protection. We still owe our thoughts on the OIF's interworking document so we should do four things: 1. Answer the Ethernet traffic parameters question 2. Poll to find out whether the OIF has any input on draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt, pointing out that the 01 revision is available 3. Poll on 1:n protection to see if we answered all of the questions satisfactorily 4. Send a response on OIF interworking As usual, input is welcome on the list or privately. Deborah and I will post draft text when we have it. I will post the two incoming communications at http://www.olddog.co.uk/incoming.htm Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Aug 2006 05:29:04 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Montreal draft minutes posted Date: Thu, 10 Aug 2006 01:27:08 -0400 Message-ID: Thread-Topic: Montreal draft minutes posted Thread-Index: Aca1ivt5u0gCP564T+iLJzoiAuxxDQGsXFMg From: "Zafar Ali \(zali\)" To: "Adrian Farrel" , Cc: "Jean Philippe Vasseur \(jvasseur\)" , "Anca Zamfir \(ancaz\)" DKIM-Signature: a=rsa-sha1; q=dns; l=1931; t=1155187630; x=1156051630; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20 |Subject:RE=3A=20Montreal=20draft=20minutes=20posted; X=v=3Dcisco.com=3B=20h=3DRt1Hr4ivIAnceFhGv4XiKnYQaf8=3D; b=C466gYIBwKXLYY+3RxflekkM4GsqzRvcPAzPR9K2Imrt+4rhk4J+ONoC2ZK3H9f/DGLxWtVk hk9OFoiYsaO8cxd09yFULRLADGJLnR5V8L7tD/WH4HCOAib90eQGvABI; Authentication-Results: sj-dkim-6.cisco.com; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com verified; ); Hi Adrian,=20 Towards the end of the meeting I requested you to pool WG on draft-ali-ccamp-mpls-graceful-shutdown-04.txt, to become a WG Doc and you gave me an AI to remind you of this via email. Please consider this email as a follow-up on my action item, and an updates to the minutes.=20 Just a bit of back ground,=20 Before IETF/ Montreal, we posted an updated version of the Graceful Shutdown draft (draft-ali-ccamp-mpls-graceful-shutdown-04.txt). In this version we have addressed comments from Adrian, Dimitri, et al during the WG meeting and have removed use of link-attribute sub-TLV from this ID. The ID now makes use of (MAX-METRIC, 0 bandwidth) for communicating graceful shutdown condition in IGP.=20 =20 In the following steps recommended for this ID in the WG meeting IETF/ 65 in Dallas, TX (copied from the WG minutes):=20 =20 Zafar: What about graceful shutdown? Support for WG draft? Kireeti: Graceful link shutdown to WG draft? Small show of hands No-one against Dimitri: If the graceful link shutdown has the routing part fixed the support will be much greater Kireeti: We'll do a poll on the list after the fixes. We believe we have addressed the above mentioned condition from the WG chairs. We will appreciate if you can ask the WG to accept this ID as a WG doc (as part of other documents that you may have planned to pool for).=20 Thanks =20 Regards... Zafar=20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, August 01, 2006 12:51 PM > To: ccamp@ops.ietf.org > Subject: Montreal draft minutes posted >=20 > http://www3.ietf.org/proceedings/06jul/minutes/ccamp.htm >=20 > Please review. >=20 > Apologies for the delay which is all my fault. >=20 > Thanks to the note takers and to Deborah for compiling the minutes. >=20 > Adrian >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Aug 2006 20:14:33 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base' to Proposed Standard (draft-ietf-ccamp-gmpls-lsr-mib) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Mon, 07 Aug 2006 16:12:50 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following documents: - 'Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base ' as a Proposed Standard - 'Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management ' as a Proposed Standard - 'Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-15.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-14.txt Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Aug 2006 08:02:06 +0000 To: ccamp@ops.ietf.org Subject: Fw: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 4 Aug 2006 09:59:54 +0200 Content-Type: text/plain; charset="US-ASCII" this version incorporates comments received on the list, discussion during ietf meeting and other improvements to facilitate reading (thanks for people having commented publicly or privately such as to improve quality of the doc) o) section 5 . clarify processing of router_address TLV . clarify processing of link_id sub-TLV o) section 6 . re-worked structure of the text . detail relationship between OSPF area and ASON RA (section 6) . specific section detailing import/export rules (section 6.1) . split discovery and selection section for downward/upward (section 6.2.1 and section 6.2.2, resp.) . for the former (downward) renamed Associated Area ID as Downstream Associated Area ID (more suitable and prevents confusion w/ Section 6.3 Associated Area ID sub-TLV) . detail scope of loop prevention (section 6.3) . figures have been revisited to prevent confusion with ABR functionality (section 6.3) . new section 6.4 (resiliency) . new section 6.5 (adjacency) -d. ----- Forwarded by Dimitri PAPADIMITRIOU/BE/ALCATEL on 04/08/2006 09:44 ----- Internet-Drafts@ietf.org 04/08/2006 00:50 Please respond to internet-drafts To: i-d-announce@ietf.org cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : OSPFv2 Routing Protocol Extensions for ASON Routing Author(s) : D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt Pages : 0 Date : 2006-8-3 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document provides the extensions of the OSPFv2 Link State Routing Protocol to meet the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 03 Aug 2006 22:52:02 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt Message-Id: Date: Thu, 03 Aug 2006 18:50:02 -0400 --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 : OSPFv2 Routing Protocol Extensions for ASON Routing Author(s) : D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt Pages : 0 Date : 2006-8-3 The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document provides the extensions of the OSPFv2 Link State Routing Protocol to meet the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-3170107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-routing-ospf-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-3170107.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Aug 2006 16:53:08 +0000 Message-ID: <08e301c6b58a$b456cea0$0a23fea9@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Montreal draft minutes posted Date: Tue, 1 Aug 2006 17:50:47 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit http://www3.ietf.org/proceedings/06jul/minutes/ccamp.htm Please review. Apologies for the delay which is all my fault. Thanks to the note takers and to Deborah for compiling the minutes. Adrian