From ramon.casellas@cttc.es Mon Aug 1 01:12:00 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8451021F8666 for ; Mon, 1 Aug 2011 01:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3VVggLbj8NB for ; Mon, 1 Aug 2011 01:11:59 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 2E65521F863A for ; Mon, 1 Aug 2011 01:11:58 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p718BlMs018503; Mon, 1 Aug 2011 10:11:52 +0200 Received: from [192.168.0.102] (62.83.138.129.dyn.user.ono.com [62.83.138.129]) by castor (Postfix) with ESMTP id 383652FC193; Mon, 1 Aug 2011 10:11:46 +0200 (CEST) Message-ID: <4E365FC1.3060805@cttc.es> Date: Mon, 01 Aug 2011 10:11:45 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: JP Vasseur References: <95E8ECEE-858A-4EAC-8401-2D3F1BF2F113@cisco.com> <4E35EEDC.8020203@cttc.es> <1FA86AE7-EF3C-46AD-B961-58C8557291D9@cisco.com> In-Reply-To: <1FA86AE7-EF3C-46AD-B961-58C8557291D9@cisco.com> Content-Type: multipart/alternative; boundary="------------090400090403050603040102" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Mon, 01 Aug 2011 10:11:46 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Cc: "pce@ietf.org" Subject: Re: [Pce] [OSPF] IETF 81 WG Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 08:12:00 -0000 This is a multi-part message in MIME format. --------------090400090403050603040102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit El 01/08/2011 6:16, JP Vasseur escribió: > > On Jul 31, 2011, at 8:10 PM, Ramon Casellas wrote: > >> As detailed below, I tend to think there is a use case to be able to >> dynamically map "TE enabled ABRs" and the domains (areas) they belong to. > > Let's discuss this aspect. It was explained that there was a need to > know that a router was TE-enabled to avoid a signaling failure … how > is that different from other parameters ? I'm afraid I don't understand the question, sorry :) Just in case, I did not mean that TE enabled bit was needed. For simplicity, assume all ABRs are TE enabled. > Second question is what can you do with the OSPF area ID ? I cannot > see any reason for knowing the area ID an ABR is connected to for > inter-area TE LSP computation ? > Thinking about it, it may not be strictly needed, although I was thinking on corner cases such as the following. Consider the topology below (paraphrasing parts of Section 1.2 RFC 3509), where an ABR has no backbone connection . . . Area 0 . +--+ +--+ ..|R1|.. ..|R2|.. . +--+ .. +--+ . . .. . . +--+ . . Area1 |R3| Area2 . . +--+ +--+ . . .. |R4| . . . . +--+ . ....... ....... Being an ABR, R3 can only consider summary-LSAs from the backbone when building the routing table (according to section 16.2 of [RFC2328]), so it will not have any inter-area routes in its routing table, but only intra-area routes from both Area 1 and Area 2. Consequently, according to section 12.4.3, R3 will originate into Areas 1 and 2 only summary-LSAs covering destinations in the directly attached areas. At the same time, router R2, as an ABR connected to the backbone, will inject into Area 2 summary-LSAs describing the destinations in Area 0 (the backbone), Area 1 and other areas reachable through the backbone. (...) This results in a situation where internal router R4 (or PCE) calculates its routes to destinations in the backbone and areas other than Area 1 via R2. (Rcas: although this may be addressed with a virtual link, as RFC3509 mentions later on) So in our use case: - R4 (or PCE) may want to compute an inter-area path towards some endpoint at area1. It may also be requested to follow e.g. a domain sequence within the IRO, listing areas 2 and 1. I would like a clean way to consider R2 and R3 somehow differently. I believe here that knowing the ABRs and the involved areas can be "a good thing" e.g. in minimizing OF codes such as "minimum number of domains". of ocurse, if there is no virtual link, I can deduce that R2 is attached to Area 0 since it is announcing summary LSAs for Area0 and areas other than 1 but I cannot rely on this. - If PCE within Area1 does not support BRPC/VPST, PCE in Area2 could explicitly select P2P paths from R3, selecting those ABRs that are directly attached to Area1. Knowing that R2 is not directly attached to Area1 allows PCE within area 2 to not request the R2 path. - Knowing the area ids of the ABRs provides a simple mechanism to somehow deduce a domain sequence and trigger the approporiate mechanism. Finally, somehow unrelated but in a wider scope, I am still wondering whether "deducing" things directly from summary LSAs rather that from dedicated opaque information that clearly decouples control and data plane is the right thing to do. Ideally (augmented) TED info should be self-contained in opaques :) Probably I am missing something, so I'd be happy to stand corrected :) Thanks R. -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 --------------090400090403050603040102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit El 01/08/2011 6:16, JP Vasseur escribió:

On Jul 31, 2011, at 8:10 PM, Ramon Casellas wrote:

As detailed below, I tend to think there is a use case to be able to dynamically map "TE enabled ABRs" and the domains (areas) they belong to.

Let's discuss this aspect. It was explained that there was a need to know that a router was TE-enabled to avoid a signaling failure … how is that different from other parameters ?

I'm afraid I don't understand the question, sorry :) Just in case, I did not mean that TE enabled bit was needed. For simplicity, assume all ABRs are TE enabled.

Second question is what can you do with the OSPF area ID ? I cannot see any reason for knowing the area ID an ABR is connected to for inter-area TE LSP computation ?


Thinking about it, it may not be strictly needed, although I was thinking on corner cases such as the following. Consider the topology below (paraphrasing parts of Section 1.2 RFC 3509), where  an ABR has no backbone  connection

                          .                .
                           .    Area 0    .
                            +--+      +--+
                          ..|R1|..  ..|R2|..
                         .  +--+  ..  +--+  .
                         .        ..        .
                         .       +--+       .
                         . Area1 |R3| Area2 .
                         .       +--+  +--+ .
                         .        ..   |R4| .
                         .       .  .  +--+ .
                          .......    .......
 Being an ABR, R3 can  only consider summary-LSAs from the backbone when building the routing table (according to section 16.2 of [RFC2328]), so it will not have any inter-area routes in its routing table, but only intra-area routes from both Area 1 and Area 2.  Consequently, according to section 12.4.3, R3 will originate into Areas 1 and 2 only summary-LSAs covering destinations in the directly attached areas. At the same time, router R2, as an ABR connected to the backbone, will inject into Area 2 summary-LSAs describing the destinations in Area 0 (the backbone), Area 1 and other areas reachable through the backbone.  (...) This results in a situation where internal router R4 (or PCE) calculates its routes to destinations in the backbone and areas other than Area 1 via R2.  (Rcas: although this may be addressed with a virtual link, as RFC3509 mentions later on)

So in our use case:

 - R4 (or PCE) may want to compute an inter-area path towards some endpoint at area1. It may also be requested to  follow e.g. a domain sequence within the IRO, listing areas 2 and 1. I would like a clean way to consider R2 and R3 somehow differently. I believe here that knowing the ABRs and the involved areas can be "a good thing" e.g. in minimizing OF codes such as "minimum number of domains". of ocurse, if there is no virtual link, I can deduce that R2 is attached to Area 0 since it is announcing summary LSAs for Area0 and areas other than 1 but I cannot rely on this.

- If PCE within Area1 does not support BRPC/VPST, PCE in Area2 could explicitly select P2P paths from R3, selecting those ABRs that are directly attached to Area1. Knowing that R2 is not directly attached to Area1 allows PCE within area 2 to not request the R2 path.

- Knowing the area ids of the ABRs provides a simple mechanism to somehow deduce a domain sequence and trigger the approporiate mechanism.



Finally, somehow unrelated but in a wider scope, I am still wondering whether "deducing" things directly from summary LSAs rather that from dedicated opaque information that clearly decouples control and data plane is the right thing to do. Ideally (augmented) TED info should be self-contained in opaques :)

Probably I am missing something, so I'd be happy to stand corrected :)

Thanks
R.

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01
--------------090400090403050603040102-- From wenhu.lu@ericsson.com Mon Aug 1 19:00:49 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C382511E8085 for ; Mon, 1 Aug 2011 19:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wQoIZu2tl8i for ; Mon, 1 Aug 2011 19:00:48 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0D911E80C4 for ; Mon, 1 Aug 2011 19:00:47 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7220oPF014999; Mon, 1 Aug 2011 21:00:51 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 1 Aug 2011 22:00:44 -0400 From: Wenhu Lu To: JP Vasseur , "pce@ietf.org" Date: Mon, 1 Aug 2011 22:00:44 -0400 Thread-Topic: [Pce] Fwd: [OSPF] IETF 81 WG Minutes Thread-Index: AcxPoQL16mxBQi80SUOKuvK64/5HyQA/FxaQ Message-ID: <8249B703AE8442429AF89B86E8206AA26F414BFDE3@EUSAACMS0703.eamcs.ericsson.se> References: <95E8ECEE-858A-4EAC-8401-2D3F1BF2F113@cisco.com> In-Reply-To: <95E8ECEE-858A-4EAC-8401-2D3F1BF2F113@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8249B703AE8442429AF89B86E8206AA26F414BFDE3EUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [Pce] Fwd: [OSPF] IETF 81 WG Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 02:00:50 -0000 --_000_8249B703AE8442429AF89B86E8206AA26F414BFDE3EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP and all, Thanks everyone for the comments and discussions regarding this ID during a= nd after the PCE session. I agree with JP that we shouldn't make changes unless they are necessary or= beneficial. I also agree with Ramon, Dhruv and Jonathan that we shouldn't settle on man= ual provisioning if we can do auto-discovery, and we shouldn't settle on br= ute force approaches if we can do things systematically. The discussion during the PCE WG session boiled down to the question: for inter-area path computation, is the "brute force" method good enoug= h that the draft method provides little merit? Here the "brute force" means that a PCE can use OSPF type-3 LSAs to figure = out the ABRs and the reachability to the LSP tailend and do path computatio= n accordingly, regardless whether ABRs are TE enable, or which areas the AB= Rs are connecting to. If an ABR is not TE capable, it will be discarded lat= er by the next PCE. Please correct me if my interpretation is wrong. My arguments are following (Ramon already explained a use-case of the area-= id in an earlier email. Here I add to it a few more points): 1. In BRPC method, the area (domain) sequence will help accomplish the inte= r-area path computation. Nevertheless, knowing not the area-id, the "bruth-= force" won't work with the area sequence. 2. The area-id TLV also implies ABR's TE capability. A typical OSPF topology is a backbone with many surrounding non-backbon= e areas. There can be many ABRs from the backbone's perspective. This means that without the ABR's TE info, the crankback method will ha= ve to spend long time to go through the list. This also means that the BRPC method will have to build a very fat-tree= (VSPT). It cannot trim the tree by excluding the non-TE ABRs and non-relat= ed areas until the VSPT is passed to the next PCE. For a deployed LSP based network, the number of LSPs can be thousands. = Considering the re-optimization, make-before-break, bypass and backup path = computation, the scalability and computation efficiency are very important = factors. The "brute force" apparently is not designed for such heavy computation= tasks. It may quickly become the scalability bottleneck. 3. In terms of information propagation, the intra-area path computation is = self-sustained. The PCE gets everything from the TED. For the inter-area pa= th computation, the self-sustaining nature can be easily preserved with the= addition of the area-id-tlv. In this sense, the "brute force" is not only slow, it has to resort to = some "out-of-band" methods to acquire the ABR information. 4. To answer Abhay's question, RFC 5088 is for PCE auto-discovery. It is no= t for TE-ABR auto-discovery. As Ramon pointed out, they are orthogonal and= complimentary. Thanks, -wenhu ________________________________ From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Va= sseur Sent: Sunday, July 31, 2011 9:43 AM To: pce@ietf.org Subject: [Pce] Fwd: [OSPF] IETF 81 WG Minutes Begin forwarded message: From: JP Vasseur > Subject: Re: [OSPF] IETF 81 WG Minutes Date: July 31, 2011 12:13:02 PM EDT To: Acee Lindem >= , "Abhay Roy (akr)" > Cc: OSPF List > Thanks Acee, Just a feed-back on one ID after the PCE WG meeting: 8) Updates to OSPF TE Extension for Area IDs Slides draft-lu-ospf-area-tlv-01.txt - Wenhu Lu 10 minutes See slides Abhay: What were comments in PCE presentation? Wenhu: Good reception. Why do we need to know Area ID? Isn't it enough to simply know if ABR is TE enabled? Solution avoids "brute force" solution a= nd produces faster convergence. Abhay: Discussed with PCE chairs. RFC 5088 - extensions for PCE. Look at th= ose extensions to see if they can be used. Wenhu: Will do that. JP> The draft was discussed in the PCE WG meeting, but there was no consens= us that this document provides an extension that addresses a use case for PCE. To b= e discussed on the PCE mailing list and we will keep you posted. Thanks. JP. On Jul 29, 2011, at 9:30 PM, Acee Lindem wrote: I've posted the IETF WG Minutes. Thanks much to Les Ginsberg for taking the= m. There was one ISP representative from Asia who commented but we did not = get his name. If this was you, please unicast me and I will update the minu= tes with your name. Abhay and I will follow up with E-mails on specific documents presented at = IETF 81. http://www.ietf.org/proceedings/81/minutes/ospf.txt Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_8249B703AE8442429AF89B86E8206AA26F414BFDE3EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi JP=20 and all,
 
Thanks=20 everyone for the comments and discussions regarding this ID during and= =20 after the PCE session.
I=20 agree with JP that we shouldn't make changes unless they are necessary or=20 beneficial.
I also=20 agree with Ramon, Dhruv and Jonathan that we shouldn't settle on manua= l=20 provisioning if we can do auto-discovery, and we shouldn't settle on brute = force=20 approaches if we can do things systematically.
 
The=20 discussion during the PCE WG session boiled down to the=20 question:
    for inter-area path computation, is the "brute = force"=20 method good enough that the draft method provides little=20 merit?
 
Here=20 the "brute force" means that a PCE can use OSPF type-3 LSAs to figure out t= he=20 ABRs and the reachability to the LSP tailend and do path computation=20 accordingly, regardless whether ABRs are TE enable, or which areas the= ABRs=20 are connecting to. If an ABR is not TE capable, it will be discarded later = by=20 the next PCE. Please correct me if my interpretation is=20 wrong.
 
My=20 arguments are following (Ramon already explained a use-case of the area-id = in an=20 earlier email. Here I add to it a few more points):
1. In=20 BRPC method, the area (domain) sequence will help accomplish the inter-area= path=20 computation. Nevertheless, knowing not the area-id, the "bruth-force" won't= work=20 with the area sequence.
2. The=20 area-id TLV also implies ABR's TE capability.
    A typical OSPF topology is a backbone with many= =20 surrounding non-backbone areas. There can be many ABRs from the backbone's= =20 perspective.
    This means that without the ABR's TE info, the= =20 crankback method will have to spend long time to go through the=20 list.
    This also means that the BRPC method will have = to=20 build a very fat-tree (VSPT). It cannot trim the tree by excluding the non-= TE=20 ABRs and non-related areas until the VSPT is passed to the next=20 PCE.
    For a deployed LSP based network, the number of= LSPs=20 can be thousands. Considering the re-optimization, make-before-break, bypas= s and=20 backup path computation, the scalability and computation efficiency are ver= y=20 important factors.
    The "brute force" apparently is not designed fo= r such=20 heavy computation tasks. It may quickly become the scalability=20 bottleneck.
3. In=20 terms of information propagation, the intra-area path computation is=20 self-sustained. The PCE gets everything from the TED. For the inter-area pa= th=20 computation, the self-sustaining nature can be easily preserved with the=20 addition of the area-id-tlv.
    In this sense, the "brute force" is not only sl= ow, it=20 has to resort to some "out-of-band" methods to acquire the ABR=20 information.
4. To answer Abhay's question, RFC 5088 is for PCE=20 auto-discovery. It is not for TE-ABR auto-discovery.  As Ramon pointed= out,=20 they are orthogonal and complimentary.
 
Thanks,
-wenhu
 
From: pce-bounces@ietf.org=20 [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur
Sent:=20 Sunday, July 31, 2011 9:43 AM
To: pce@ietf.org
Subject:= =20 [Pce] Fwd: [OSPF] IETF 81 WG Minutes



Begin forwarded message:

From: JP Vasseur <jpv@cisco.com>
Subject:=20 Re:=20 [OSPF] IETF 81 WG Minutes
Date: July 31, 2011 12:13= :02 PM=20 EDT
To: <= SPAN=20 style=3D"FONT-SIZE: medium; FONT-FAMILY: 'Helvetica'">Acee Lindem <acee.lindem@ericsson.com>= ,=20 "Abhay Roy (akr)" <akr@cisco.com>
Cc: <= SPAN=20 style=3D"FONT-SIZE: medium; FONT-FAMILY: 'Helvetica'">OSPF List <ospf@ietf.org>

Thanks=20 Acee,

Just a feed-back on one ID after the PCE WG meeting:


8) Updates to OSPF TE Extension for Area IDs  &nbs= p;=20 Slides
   draft-lu-ospf-area-tlv-01.txt
- Wenhu Lu <= BR>10=20 minutes

See slides

Abhay: Wha= t were=20 comments in PCE presentation?
Wenhu: Good reception. Why do we need to know Ar= ea ID?=20 Isn't it enough to 
 simply know if ABR is TE enabled? Solut= ion=20 avoids "brute force" solution and 
 produces faster=20 convergence.

Abhay: Discussed with PCE chairs. RFC 5088 - extensio= ns=20 for PCE. Look at those 
extensions to see if they can be=20 used.
Wenhu: Will do that.

JP> The draft was discussed in the PCE WG meeting, but there was = no=20 consensus that
this document provides an extension that addresses a use case for PC= E. To=20 be discussed
on the PCE mailing list and we will keep you posted.

Thanks.

JP.

On Jul 29, 2011, at 9:30 PM, Acee Lindem wrote:
I've posted the IETF WG Minutes. Thanks much to Les Ginsberg for t= aking=20 them. There was one ISP representative from Asia who commented but we d= id=20 not get his name. If this was you, please unicast me and I will update = the=20 minutes with your name.  

Abhay and I will follow up with=20 E-mails on specific documents presented at IETF 81.

http://www= .ietf.org/proceedings/81/minutes/ospf.txt

Thanks,
Acee=20
_______________________________________________
OSPF mailing=20 list
OSPF@ietf.org
https://www.ietf.org= /mailman/listinfo/ospf

________= _______________________________________
OSPF=20 mailing list
OSPF@ietf.org
https://www.ietf.org/m= ailman/listinfo/ospf

--_000_8249B703AE8442429AF89B86E8206AA26F414BFDE3EUSAACMS0703e_-- From cyril.margaria@nsn.com Tue Aug 2 00:56:05 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A96A21F8D97; Tue, 2 Aug 2011 00:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKl-LuTlxqqe; Tue, 2 Aug 2011 00:56:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 26E0121F8B02; Tue, 2 Aug 2011 00:56:02 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p727tuoN022632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 09:55:57 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p727tuUb014681; Tue, 2 Aug 2011 09:55:56 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Aug 2011 09:55:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC50E9.8B1D5982" Date: Tue, 2 Aug 2011 09:55:26 +0200 Message-ID: In-Reply-To: <33BC8EF6-2208-4CAD-9AE4-BDF02C78A021@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01 Thread-Index: AcxL4Dvjqppf1Ow6RuyZV1dQLZGeuwFCFc5g References: <560E52D0-9A68-4330-8160-725C899B2C7E@cisco.com><00cb01cc4bbd$437624a0$14168182@hp3d061f9287af> <33BC8EF6-2208-4CAD-9AE4-BDF02C78A021@cisco.com> From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext JP Vasseur" , "Fatai Zhang" X-OriginalArrivalTime: 02 Aug 2011 07:55:28.0386 (UTC) FILETIME=[8B6FBE20:01CC50E9] Cc: pce-bounces@ietf.org, pce@ietf.org, =?UTF-8?B?546L56OK?= Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 07:56:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC50E9.8B1D5982 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIA0KDQogDQoNCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgdGhlIHByb2JsZW0gUENFIChp KzEpIGhhcyBjb21wbGV0ZSBrbm93bGVkZ2UgdGhlIGludGVyIEFTIGxpbmsgKGkrMSkgLT4gaSBi dXQgbm90IHRoZSBpLT4oaSsxKSBsaW5rIHByb3BlcnRpZXMgKHVwc3RyZWFtKS4NCg0KIA0KDQpG aXJzdCBJIHdvdWxkIHRlbmQgdG8gdW5kZXJzdGFuZCB0aGUgZm9sbG93aW5nIHNlY3Rpb24gb2Yg UkZDNTQ0MSBhcyA6IA0KDQogIFBDRSAoaSkgY2FuIHZlcmlmeSB0aGUgbGluayBwcm9wZXJ0aWVz IGluIHRoZSBpLT4oaSsxKSBkaXJlY3Rpb24gIA0KDQogDQoNClRoaXMgc2hvdWxkIHNvbHZlIHRo ZSBwcm9ibGVtIG1lbnRpb25lZCBleGNlcHQgaW4gdGhlIGNhc2UgdGhlIGFsZ29yaXRobSByZXF1 aXJlIHRvIGtub3cgdGhlIGxpbmsgcHJvcGVydGllcyBpbiBib3RoIGRpcmVjdGlvbiBhdCB0aGUg c2FtZSB0aW1lLCBidXQgdGhlIGRyYWZ0IGRvZXMgbm90IGFkZHJlc3MgdGhpcyBwcm9ibGVtIGVp dGhlci4NCg0KIA0KDQpQbGVhc2UgaW5kaWNhdGUgaWYgSSBtaXNzZWQgc29tZXRoaW5nLg0KDQri gJwNCg0KU3RlcCBpOg0KDQogICBGb3IgaT1uLTEgdG8gMjogUENFKGkpIGNvbXB1dGVzIFZTUFQo aSksIHRoZSB0cmVlIG1hZGUgb2YgdGhlDQoNCiAgIHNob3J0ZXN0IGNvbnN0cmFpbmVkIHBhdGhz IGJldHdlZW4gZWFjaCBCTi1lbihqLGkpIGFuZCB0aGUgVEUgTFNQDQoNCiAgIGRlc3RpbmF0aW9u LiAgSXQgZG9lcyB0aGlzIGJ5IGNvbnNpZGVyaW5nIGl0cyBvd24gVEVEIGFuZCB0aGUNCg0KICAg aW5mb3JtYXRpb24gaW4gVlNQVChpKzEpLg0KDQogDQoNCiAgIEluIHRoZSBjYXNlIG9mIGludGVy LUFTIFRFIExTUCBjb21wdXRhdGlvbiwgdGhpcyBhbHNvIHJlcXVpcmVzIGFkZGluZw0KDQogICB0 aGUgaW50ZXItQVMgVEUgbGlua3MgdGhhdCBjb25uZWN0IHRoZSBkb21haW4oaSkgdG8gdGhlIGRv bWFpbihpKzEpLg0KDQrigJwNCg0KIA0KDQogDQoNCkZyb206IHBjZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgSlAgVmFzc2V1 cg0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDI3LCAyMDExIDEyOjA1IEFNDQpUbzogRmF0YWkgWmhh bmcNCkNjOiBwY2UtYm91bmNlc0BpZXRmLm9yZzsgcGNlQGlldGYub3JnOyDnjovno4oNClN1Ympl Y3Q6IFJlOiBbUGNlXSByZXF1ZXN0IHRpbWVzbG90IGZvciBkcmFmdC13YW5nLXBjZS1pbnRlci1h cy1leHRlbnRpb25zLTAxDQoNCiANCg0KVGhhdCB3YXMgbXkgcXVlc3Rpb24gdG9vDQoNCiANCg0K T24gSnVsIDI2LCAyMDExLCBhdCAxOjU1IFBNLCBGYXRhaSBaaGFuZyB3cm90ZToNCg0KDQoNCg0K DQpIaSBhbGwsDQoNCiANCg0KUkZDNTM5MiBpcyBhIGtpbmQgb2YgbWVjaGFtaXNtIGFuZCBpdCBp cyBhbHJlYWR5IHRoZXJlLg0KDQogDQoNCldoeSB3ZSBuZWVkIHRvIGRlZmluZSBhbm90aGVyIHNv bHV0aW9uIGJhc2VkIG9uIHNvbWUgbm9uZXhpc3RlbnQgYXNzdW1wdGlvbj8NCg0KIA0KDQogDQoN CiANCg0KIA0KDQogDQoNCiANCg0KDQpGYXRhaQ0KDQogDQoNClRoYW5rcw0KDQoJLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLQ0KDQoJRnJvbTogSlAgVmFzc2V1ciA8bWFpbHRvOmpwdkBjaXNj by5jb20+IA0KDQoJVG86IGZ1LnhpaHVhQHp0ZS5jb20uY24NCg0KCUNjOiBwY2UtYm91bmNlc0Bp ZXRmLm9yZyA7IHBjZUBpZXRmLm9yZyA7IM21IDxtYWlsdG86aGVjaGVuMDAwMUBnbWFpbC5jb20+ IA0KDQoJU2VudDogVHVlc2RheSwgSnVseSAyNiwgMjAxMSAxOjIwIEFNDQoNCglTdWJqZWN0OiBS ZTogW1BjZV0gcmVxdWVzdCB0aW1lc2xvdCBmb3IgZHJhZnQtd2FuZy1wY2UtaW50ZXItYXMtZXh0 ZW50aW9ucy0wMQ0KDQoJIA0KDQoJSGksDQoNCgkgDQoNCglPbiBKdWwgMjUsIDIwMTEsIGF0IDEx OjE2IEFNLCBmdS54aWh1YUB6dGUuY29tLmNuIHdyb3RlOg0KDQoJDQoJDQoJDQoNCgkNCglIaSBK UCwgDQoJDQoJSU1PLCB3ZSBkb24ndCBuZWVkIHR3byBtZXRob2RzLiBUaGUgbWV0aG9kIG9mIGV4 dGVuZGluZyBJR1AgbWF5IGltcGFjdCBvbiBsYXJnZSBhc3BlY3QuIA0KCUV4dGVuZGluZyBCUlBD IGFuZCBQQ0VQIGRlZmluZWQgaW4gdGhpcyBkcmFmdCBpcyBlbm91Z2guIA0KDQoJIA0KDQoJU28g bGV0IHRoZSBXRyBkZWNpZGUgd2hpY2ggb25lIG9mIHRoZSBtZXRob2RzIGlzIG1vc3QgYXBwcm9w cmlhdGUNCg0KCSANCg0KCVRoYW5rcy4NCg0KCSANCg0KCUpQLg0KDQoJDQoJDQoJDQoNCglUaGFu a3MsIA0KCQ0KCVhpaHVhIA0KCQ0KCQ0KDQpKUCBWYXNzZXVyIDxqcHZAY2lzY28uY29tPiANCsiL OiAgcGNlLWJvdW5jZXNAaWV0Zi5vcmcNCg0KMjAxMS0wNy0yNSDPgs6nIDA4OjMwDQoNCsqVyIsN Cg0KzbUgPGhlY2hlbjAwMDFAZ21haWwuY29tPg0KDQrLjQ0KDQpwY2VAaWV0Zi5vcmcNCg0K1rfM og0KDQpSZTogW1BjZV0gcmVxdWVzdCB0aW1lc2xvdCBmb3IgZHJhZnQtd2FuZy1wY2UtaW50ZXIt YXMtZXh0ZW50aW9ucy0wMQ0KDQogDQoNCgkJDQoNCgkNCgkNCgkNCglUaGFua3MgZm9yIHlvdXIg ZmVlZC1iYWNrLiBJdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBoZWFyIGZyb20gdGhlIFdHIGlm IGluZGVlZCANCgl3ZSBuZWVkIHR3byBtZXRob2RzLiBUbyBlYWNoIHNwZWNpZmljIHByb2JsZW0g d2UgY2FuIGNlcnRhaW5seSBmaW5kIGEgbnVtYmVyIA0KCW9mIHdheSB0byBzb2x2ZSBpdCwgYnV0 IGxldCdzIHRyeSB0byBtYWtlIHN1cmUgdGhhdCB3ZSBkbyBub3Qgc3BlY2lmeSBhIG5ldyB0ZWNo bmlxdWUgDQoJaWYgd2UgY2FuIHVzZSB3aGF0IGV4aXN0IHRvZGF5LiANCgkNCglXRyA/IA0KCQ0K CVRoYW5rcy4gDQoJDQoJSlAuIA0KCU9uIEp1bCAyNSwgMjAxMSwgYXQgMTI6MjUgQU0sIM21IHdy b3RlOiANCg0KCUhpLCBYdWVyb25nIGFuZCBQQ0VlcnMNCgkNCglJIGhhdmUgcmVhZCB0aGUgZHJh ZnQuIEl0IHByb3ZpZGVzIGFuIGFsdGVybmF0ZSBtZXRob2QgdGhhdCBleHRlbmRzDQoJQlJQQyBh bmQgUENFUCBwcm90b2NvbCB0byBnZXQgVEUgaW5mb3JtYXRpb24gb2YgSW50ZXItQVMgYmlkZXJl Y3Rpb25hbA0KCWxpbmtzLiBJbiBteSBvcGluaW9uLCBJdCBpcyB1c2VmdWwgZm9yIHRoZSBzbW9v dGggdXBncmFkZSBvZiBleGlzdGluZw0KCU1QTFMvR01QTFMgbmV0d29ya3MgdG8gc3VwcG9ydCBJ bnRlci1BUyBiaWRpcmVjdGlvbmFsIHBhdGgNCgljb21wdXRhdGlvbiwgYmVjYXVzZSBpdCBuZWVk IG5vdCBhbnkgZXh0ZW5zaW9uIG9yIG1vZGlmaWNhdGlvbiB0byB0aGUNCglJR1AgKHN1Y2ggYXMg T1NQRiBhbmQgSVMtSVMpIHVzZWQgaW4gTVBMUy9HTVBMUy1lbmFibGVkDQoJcm91dGVycy9zd2l0 Y2hlcy4gSG93ZXZlciwgdGhlIG1ldGhvZCBvZiBJR1AgZXh0ZW5zaW9uIGlzIGFsc28NCglhcHBs aWNhYmxlIGFuZCBzdWl0YWJsZSBmb3IgbmV3IG5ldHdvcmstZXF1aXBtZW50cy4gU28sIEkgdGhp bmsgdGhlcmUNCglpcyBubyBjb25mbGljdCBiZXR3ZWVuIHRoZXNlIHR3byBtZXRvZHMuIFRoZSBk cmFmdCBjb3VsZCBiZSB1c2VkIGluDQoJdGhlIHNjZW5hcmlvIHdoZXJlIHRoZSBJR1AgZXh0ZW5z aW9uIG9mIEludGVyLUFTIGJpZGVyZWN0aW9uYWwgbGlua3MNCgljYW4gbm90IGJlIHN1cHBvcnRl ZC4NCgkNCglUaGFua3MuDQoJDQoJTGVpIFdhbmcNCglUc2luZ2h1YSBVbml2ZXJzaXR5LCBCZWlq aW5nLCBDaGluYQ0KCWhlY2hlbjAwMDFAZ21haWwuY29tIDxtYWlsdG86aGVjaGVuMDAwMUBnbWFp bC5jb20+ICBvciBsZWl3QHRzaW5naHVhLmVkdS5jbiA8bWFpbHRvOmxlaXdAdHNpbmdodWEuZWR1 LmNuPiANCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K CVBjZSBtYWlsaW5nIGxpc3QNCglQY2VAaWV0Zi5vcmcgPG1haWx0bzpQY2VAaWV0Zi5vcmc+IA0K CWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlIDxodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZT4gDQoNCglfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KCVBjZSBtYWlsaW5nIGxpc3QNCglQY2VAaWV0Zi5v cmcNCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0KDQoJIA0KDQoJ IA0KDQoJIA0KDQoJDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCgkgDQoN CglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCVBjZSBt YWlsaW5nIGxpc3QNCglQY2VAaWV0Zi5vcmcNCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3BjZQ0KDQogDQoNCg== ------_=_NextPart_001_01CC50E9.8B1D5982 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PGJhc2UgaHJlZj0ieC1tc2c6 Ly8xMTkvIj48IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQj Vk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlv cjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwp O30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMg Ki8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7 DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiAzIDkgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJNaWNyb3NvZnQgU2FucyBTZXJpZiI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0x OjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIFVJ IEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBNUyBVSSBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiAwIDcgMiA1 IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWluZ0xpVSI7DQoJcGFub3Nl LTE6MiAyIDMgOSAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OsuOzKU7 DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXtt c28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlIHN0 eWxlPSd3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UnPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24x PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhpLCA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgdGhlIHByb2JsZW0gUENFIChpKzEp IGhhcyBjb21wbGV0ZSBrbm93bGVkZ2UgdGhlIGludGVyIEFTIGxpbmsgKGkrMSkgLSZndDsgaSBi dXQgbm90IHRoZSBpLSZndDsoaSsxKSBsaW5rIHByb3BlcnRpZXMgKHVwc3RyZWFtKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPkZpcnN0IEkgd291bGQgdGVuZCB0byB1bmRlcnN0YW5kIHRoZSBmb2xsb3dp bmcgc2VjdGlvbiBvZiBSRkM1NDQxIGFzIDogPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqBQQ0UgKGkpIGNhbiB2ZXJpZnkg dGhlIGxpbmsgcHJvcGVydGllcyBpbiB0aGUgaS0mZ3Q7KGkrMSkgZGlyZWN0aW9uIMKgPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5UaGlzIHNob3VsZCBzb2x2ZSB0aGUgcHJvYmxlbSBtZW50aW9uZWQgZXhj ZXB0IGluIHRoZSBjYXNlIHRoZSBhbGdvcml0aG0gcmVxdWlyZSB0byBrbm93IHRoZSBsaW5rIHBy b3BlcnRpZXMgaW4gYm90aCBkaXJlY3Rpb24gYXQgdGhlIHNhbWUgdGltZSwgYnV0IHRoZSBkcmFm dCBkb2VzIG5vdCBhZGRyZXNzIHRoaXMgcHJvYmxlbSBlaXRoZXIuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5QbGVhc2UgaW5kaWNhdGUgaWYgSSBtaXNzZWQgc29tZXRoaW5nLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4gPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKA nDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5TdGVwIGk6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqAgRm9yIGk9bi0xIHRvIDI6IFBDRShpKSBjb21wdXRl cyBWU1BUKGkpLCB0aGUgdHJlZSBtYWRlIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgIHNob3J0ZXN0IGNvbnN0 cmFpbmVkIHBhdGhzIGJldHdlZW4gZWFjaCBCTi1lbihqLGkpIGFuZCB0aGUgVEUgTFNQPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PsKgwqAgZGVzdGluYXRpb24uwqAgSXQgZG9lcyB0aGlzIGJ5IGNvbnNpZGVyaW5nIGl0cyBvd24g VEVEIGFuZCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+wqDCoCBpbmZvcm1hdGlvbiBpbiBWU1BUKGkrMSkuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz7CoMKgIEluIHRoZSBjYXNlIG9mIGludGVyLUFTIFRFIExTUCBjb21wdXRhdGlv biwgdGhpcyBhbHNvIHJlcXVpcmVzIGFkZGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgIHRoZSBpbnRlci1BUyBURSBs aW5rcyB0aGF0IGNvbm5lY3QgdGhlIGRvbWFpbihpKSB0byB0aGUgZG9tYWluKGkrMSkuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PuKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9 TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHBjZS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8 L2I+ZXh0IEpQIFZhc3NldXI8YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAyNywgMjAx MSAxMjowNSBBTTxicj48Yj5Ubzo8L2I+IEZhdGFpIFpoYW5nPGJyPjxiPkNjOjwvYj4gcGNlLWJv dW5jZXNAaWV0Zi5vcmc7IHBjZUBpZXRmLm9yZzsgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJNUyBVSSBHb3RoaWMiLCJzYW5zLXNlcmlmIic+546L56OK PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW1BjZV0gcmVxdWVzdCB0aW1l c2xvdCBmb3IgZHJhZnQtd2FuZy1wY2UtaW50ZXItYXMtZXh0ZW50aW9ucy0wMTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlRoYXQgd2FzIG15IHF1ZXN0aW9uIHRvbzxvOnA+PC9v OnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gSnVsIDI2LCAyMDExLCBhdCAxOjU1IFBNLCBGYXRh aSBaaGFuZyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJy Pjxicj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6bmF2eSc+SGkgYWxsLDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y Om5hdnknPlJGQzUzOTIgaXMgYSBraW5kIG9mIG1lY2hhbWlzbSBhbmQgaXQgaXMgYWxyZWFkeSB0 aGVyZS48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Ikhl bHZldGljYSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1p bHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz5XaHkgd2Ug bmVlZCB0byBkZWZpbmUgYW5vdGhlciBzb2x1dGlvbiBiYXNlZCBvbiBzb21lIG5vbmV4aXN0ZW50 IGFzc3VtcHRpb24/PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlm Iic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2Ei LCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGJyPkZh dGFpPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5z LXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2 ZXRpY2EiLCJzYW5zLXNlcmlmIic+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxi bG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBuYXZ5IDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiLLjsyl Iiwic2VyaWYiJz4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOiNFNEU0 RTQnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IsuOzKUiLCJz ZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiy47MpSIsInNlcmlmIic+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiLLjsylIiwic2VyaWYiJz48YSBocmVmPSJtYWlsdG86anB2QGNpc2NvLmNvbSIgdGl0bGU9 ImpwdkBjaXNjby5jb20iPkpQIFZhc3NldXI8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6IsuOzKUiLCJzZXJpZiInPlRvOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6IsuOzKUiLCJzZXJpZiInPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseToiy47MpSIsInNlcmlmIic+PGEgaHJlZj0ibWFpbHRvOmZ1 LnhpaHVhQHp0ZS5jb20uY24iIHRpdGxlPSJmdS54aWh1YUB6dGUuY29tLmNuIj5mdS54aWh1YUB6 dGUuY29tLmNuPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiLLjsyl Iiwic2VyaWYiJz5DYzo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFj ZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiLLjsylIiwic2VyaWYi Jz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6IsuOzKUiLCJzZXJpZiInPjxhIGhyZWY9Im1haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9y ZyIgdGl0bGU9InBjZS1ib3VuY2VzQGlldGYub3JnIj5wY2UtYm91bmNlc0BpZXRmLm9yZzwvYT48 c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjs8c3BhbiBjbGFz cz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwY2VA aWV0Zi5vcmciIHRpdGxlPSJwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwvYT48c3BhbiBjbGFz cz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjs8c3BhbiBjbGFzcz1hcHBsZS1j b252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpoZWNoZW4wMDAxQGdt YWlsLmNvbSIgdGl0bGU9ImhlY2hlbjAwMDFAZ21haWwuY29tIj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCIsInNlcmlmIic+zbU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiLLjsylIiwic2VyaWYiJz5TZW50Ojwvc3Bhbj48L2I+ PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6IsuOzKUiLCJzZXJpZiInPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiy47MpSIsInNlcmlmIic+VHVl c2RheSwgSnVseSAyNiwgMjAxMSAxOjIwIEFNPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6IsuOzKUiLCJzZXJpZiInPlN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBjbGFzcz1h cHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseToiy47MpSIsInNlcmlmIic+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiLLjsylIiwic2VyaWYiJz5SZTogW1BjZV0gcmVxdWVz dCB0aW1lc2xvdCBmb3IgZHJhZnQtd2FuZy1wY2UtaW50ZXItYXMtZXh0ZW50aW9ucy0wMTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiIn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMt c2VyaWYiJz5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNh bnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVs dmV0aWNhIiwic2Fucy1zZXJpZiInPk9uIEp1bCAyNSwgMjAxMSwgYXQgMTE6MTYgQU0sPHNwYW4g Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 ZnUueGlodWFAenRlLmNvbS5jbiI+ZnUueGlodWFAenRlLmNvbS5jbjwvYT48c3BhbiBjbGFzcz1h cHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPndyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz48YnI+PGJyPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTMu NXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNh Iiwic2Fucy1zZXJpZiInPjxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPkhpIEpQLDwvc3Bhbj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0 ZWQtc3BhY2U+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZl dGljYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGJyPjxi cj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiIn PklNTywgd2UgZG9uJ3QgbmVlZCB0d28gbWV0aG9kcy4gVGhlIG1ldGhvZCBvZiBleHRlbmRpbmcg SUdQIG1heSBpbXBhY3Qgb24gbGFyZ2UgYXNwZWN0Ljwvc3Bhbj48c3BhbiBjbGFzcz1hcHBsZS1j b252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+ PGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Iic+RXh0ZW5kaW5nIEJSUEMgYW5kIFBDRVAgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0IGlzIGVub3Vn aC48L3NwYW4+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVw dDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPlNvIGxldCB0aGUgV0cgZGVj aWRlIHdoaWNoIG9uZSBvZiB0aGUgbWV0aG9kcyBpcyBtb3N0IGFwcHJvcHJpYXRlPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5z LXNlcmlmIic+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVs dmV0aWNhIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPkpQLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz48YnI+PGJyPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTMuNXB0 Jz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+VGhhbmtz LDwvc3Bhbj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGJyPjxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPlhpaHVhPC9zcGFuPjxzcGFuIGNsYXNz PWFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMt c2VyaWYiJz48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48dGFibGUgY2xhc3M9TXNvTm9y bWFsVGFibGUgYm9yZGVyPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD0iMTAwJSIgc3R5bGU9J3dpZHRo OjEwMC4wJSc+PHRyPjx0ZCB3aWR0aD0iMzUlIiB2YWxpZ249dG9wIHN0eWxlPSd3aWR0aDozNS4w JTtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+SlAgVmFzc2V1ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpwdkBjaXNjby5jb20iPmpwdkBj aXNjby5jb208L2E+Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNw YWNlPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6Ik1pY3Jvc29mdCBTYW5zIFNlcmlmIiwic2Fucy1zZXJpZiInPsiL PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPjogJm5ic3A7PGEgaHJlZj0ibWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3Jn Ij5wY2UtYm91bmNlc0BpZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ MjAxMS0wNy0yNSDPgs6nIDA4OjMwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvdGQ+PHRkIHdpZHRo PSI2NCUiIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjY0LjAlO3BhZGRpbmc6Ljc1cHQgLjc1cHQg Ljc1cHQgLjc1cHQnPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxscGFk ZGluZz0wIHdpZHRoPSIxMDAlIiBzdHlsZT0nd2lkdGg6MTAwLjAlJz48dHI+PHRkIHZhbGlnbj10 b3Agc3R5bGU9J3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjxwIGNsYXNzPU1zb05v cm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiTVMgR290aGljIic+ypU8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiTWljcm9zb2Z0IFNhbnMgU2VyaWYiLCJz YW5zLXNlcmlmIic+yIs8L3NwYW4+PG86cD48L286cD48L3A+PC90ZD48dGQgdmFsaWduPXRvcCBz dHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCIs InNlcmlmIic+zbU8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ICZsdDs8YSBocmVmPSJtYWlsdG86aGVjaGVuMDAwMUBn bWFpbC5jb20iPmhlY2hlbjAwMDFAZ21haWwuY29tPC9hPiZndDs8L3NwYW4+PG86cD48L286cD48 L3A+PC90ZD48L3RyPjx0cj48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVw dCAuNzVwdCAuNzVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0 LWFsaWduOnJpZ2h0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5Ok1p bmdMaVUnPsuNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvdGQ+PHRkIHZhbGlnbj10b3Agc3R5bGU9 J3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz48YSBocmVmPSJtYWlsdG86cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8L2E+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48dHI+PHRkIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6 Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBz dHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+1rc8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIiwic2VyaWYiJz7Mojwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L3RkPjx0ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOi43NXB0IC43 NXB0IC43NXB0IC43NXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+UmU6IFtQY2VdIHJlcXVl c3QgdGltZXNsb3QgZm9yIGRyYWZ0LXdhbmctcGNlLWludGVyLWFzLWV4dGVudGlvbnMtMDE8L3Nw YW4+PG86cD48L286cD48L3A+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBj ZWxscGFkZGluZz0wPjx0cj48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVw dCAuNzVwdCAuNzVwdCc+PC90ZD48dGQgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzouNzVwdCAu NzVwdCAuNzVwdCAuNzVwdCc+PC90ZD48L3RyPjwvdGFibGU+PC90ZD48L3RyPjwvdGFibGU+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGJyPjxicj48YnI+PC9zcGFuPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+VGhhbmtzIGZvciB5b3VyIGZlZWQt YmFjay4gSXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gaGVhciBmcm9tIHRoZSBXRyBpZiBpbmRl ZWQ8L3NwYW4+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPjxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz53ZSBuZWVkIHR3byBtZXRob2RzLiBUbyBlYWNo IHNwZWNpZmljIHByb2JsZW0gd2UgY2FuIGNlcnRhaW5seSBmaW5kIGEgbnVtYmVyPC9zcGFuPjxz cGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGlj YSIsInNhbnMtc2VyaWYiJz48YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+b2Ygd2F5IHRvIHNvbHZlIGl0LCBidXQgbGV0J3MgdHJ5IHRvIG1h a2Ugc3VyZSB0aGF0IHdlIGRvIG5vdCBzcGVjaWZ5IGEgbmV3IHRlY2huaXF1ZTxzcGFuIGNsYXNz PWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGJy Pjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmlm IHdlIGNhbiB1c2Ugd2hhdCBleGlzdCB0b2RheS48L3NwYW4+PHNwYW4gY2xhc3M9YXBwbGUtY29u dmVydGVkLXNwYWNlPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJI ZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPjxi cj48YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+V0cgPzwvc3Bhbj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYi Jz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGJyPjxicj48L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5UaGFua3MuPC9zcGFuPjxzcGFu IGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVw dDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIs InNhbnMtc2VyaWYiJz48YnI+PGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiInPkpQLjwvc3Bhbj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQt c3BhY2U+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGlj YSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGJyPjwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPk9uIEp1bCAy NSwgMjAxMSwgYXQgMTI6MjUgQU0sIDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNh bWJyaWEgTWF0aCIsInNlcmlmIic+zbU8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz4gd3JvdGU6PC9zcGFuPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZl cnRlZC1zcGFjZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVs dmV0aWNhIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkhpLCBYdWVyb25nIGFuZCBQQ0VlcnM8YnI+PGJy PkkgaGF2ZSByZWFkIHRoZSBkcmFmdC4gSXQgcHJvdmlkZXMgYW4gYWx0ZXJuYXRlIG1ldGhvZCB0 aGF0IGV4dGVuZHM8YnI+QlJQQyBhbmQgUENFUCBwcm90b2NvbCB0byBnZXQgVEUgaW5mb3JtYXRp b24gb2YgSW50ZXItQVMgYmlkZXJlY3Rpb25hbDxicj5saW5rcy4gSW4gbXkgb3BpbmlvbiwgSXQg aXMgdXNlZnVsIGZvciB0aGUgc21vb3RoIHVwZ3JhZGUgb2YgZXhpc3Rpbmc8YnI+TVBMUy9HTVBM UyBuZXR3b3JrcyB0byBzdXBwb3J0IEludGVyLUFTIGJpZGlyZWN0aW9uYWwgcGF0aDxicj5jb21w dXRhdGlvbiwgYmVjYXVzZSBpdCBuZWVkIG5vdCBhbnkgZXh0ZW5zaW9uIG9yIG1vZGlmaWNhdGlv biB0byB0aGU8YnI+SUdQIChzdWNoIGFzIE9TUEYgYW5kIElTLUlTKSB1c2VkIGluIE1QTFMvR01Q TFMtZW5hYmxlZDxicj5yb3V0ZXJzL3N3aXRjaGVzLiBIb3dldmVyLCB0aGUgbWV0aG9kIG9mIElH UCBleHRlbnNpb24gaXMgYWxzbzxicj5hcHBsaWNhYmxlIGFuZCBzdWl0YWJsZSBmb3IgbmV3IG5l dHdvcmstZXF1aXBtZW50cy4gU28sIEkgdGhpbmsgdGhlcmU8YnI+aXMgbm8gY29uZmxpY3QgYmV0 d2VlbiB0aGVzZSB0d28gbWV0b2RzLiBUaGUgZHJhZnQgY291bGQgYmUgdXNlZCBpbjxicj50aGUg c2NlbmFyaW8gd2hlcmUgdGhlIElHUCBleHRlbnNpb24gb2YgSW50ZXItQVMgYmlkZXJlY3Rpb25h bCBsaW5rczxicj5jYW4gbm90IGJlIHN1cHBvcnRlZC48YnI+PGJyPlRoYW5rcy48YnI+PGJyPkxl aSBXYW5nPGJyPlRzaW5naHVhIFVuaXZlcnNpdHksIEJlaWppbmcsIENoaW5hPHU+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsdWUnPjxicj48L3NwYW4+PC91Pjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPjxhIGhyZWY9 Im1haWx0bzpoZWNoZW4wMDAxQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmhlY2hlbjAwMDFAZ21haWwuY29t PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5vcjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGEgaHJlZj0ibWFpbHRvOmxl aXdAdHNpbmdodWEuZWR1LmNuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+bGVpd0B0c2luZ2h1YS5lZHUuY248L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPlBjZSBtYWlsaW5nIGxpc3Q8dT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+ PGJyPjwvc3Bhbj48L3U+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGEgaHJlZj0ibWFpbHRvOlBjZUBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPlBjZUBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjx1PjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OmJsdWUnPjxicj48L3NwYW4+PC91PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3BjZTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwPjx0 dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0PlBjZSBtYWlsaW5nIGxp c3Q8L3R0Pjxicj48dHQ+PGEgaHJlZj0ibWFpbHRvOlBjZUBpZXRmLm9yZyI+UGNlQGlldGYub3Jn PC9hPjwvdHQ+PGJyPjx0dD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3BjZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2U8L2E+ PC90dD48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Ikhl bHZldGljYSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6Ikhl bHZldGljYSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRl ciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGhyIHNpemU9MiB3aWR0aD0i MTAwJSIgYWxpZ249Y2VudGVyPjwvc3Bhbj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fu cy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGlj YSIsInNhbnMtc2VyaWYiJz5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5QY2UgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpQY2VAaWV0Zi5v cmciPlBjZUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wY2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGNlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjwv Ym9keT48L2h0bWw+ ------_=_NextPart_001_01CC50E9.8B1D5982-- From ramon.casellas@cttc.es Tue Aug 2 01:29:35 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C85F21F8CC2 for ; Tue, 2 Aug 2011 01:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv9hVkR1H9uT for ; Tue, 2 Aug 2011 01:29:33 -0700 (PDT) Received: from pollux.cttc.es (pollux.cttc.es [84.88.62.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9766D21F8CA9 for ; Tue, 2 Aug 2011 01:29:29 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by pollux.cttc.es (8.13.1/8.13.1) with ESMTP id p728aUqt017400 for ; Tue, 2 Aug 2011 10:36:30 +0200 Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p728SFQp023480; Tue, 2 Aug 2011 10:28:20 +0200 Received: from [10.1.10.16] (unknown [10.1.10.16]) by castor (Postfix) with ESMTP id D3CE62FC285; Tue, 2 Aug 2011 10:28:14 +0200 (CEST) Message-ID: <4E37B51C.3020705@cttc.es> Date: Tue, 02 Aug 2011 10:28:12 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110801 Thunderbird/6.0 MIME-Version: 1.0 To: pce@ietf.org, "Margaria, Cyril (NSN - DE/Munich)" References: <560E52D0-9A68-4330-8160-725C899B2C7E@cisco.com><00cb01cc4bbd$437624a0$14168182@hp3d061f9287af> <33BC8EF6-2208-4CAD-9AE4-BDF02C78A021@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010007050900060101000902" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Tue, 02 Aug 2011 10:28:15 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 08:29:35 -0000 This is a multi-part message in MIME format. --------------010007050900060101000902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Salut Cyril, all On 08/02/2011 09:55 AM, Margaria, Cyril (NSN - DE/Munich) wrote: > > Hi, > > If I understand correctly the problem PCE (i+1) has complete knowledge > the inter AS link (i+1) -> i but not the i->(i+1) link properties > (upstream). > Or seen the other way round, the PCE(i) does not have the TE link ASBR(i+1) -> ASBR(i) -- I should say does not have it by OSPF-TE InterAS extesions -- I nitpick since I humbly believe that, in the spirit of BRPC, the role of PCE(i+1) should stop at entry ASBR. Reducing paths / trimming and applying BRPC should be done by PCE(i) eventually in a two step: interAS + own AS. > First I would tend to understand the following section of RFC5441 as : > > PCE (i) can verify the link properties in the i->(i+1) direction > Yes, OSPF-InterAs [RFC5392] addresses this. > This should solve the problem mentioned except in the case the > algorithm require to know the link properties in both direction at the > same time, but the draft does not address this problem either. > Indeed, the problem is _bidirectional_ LSPs. The draft does address this by "embedding" the upstream link in the BRPC response. For unidirectional LSPs, the existing method works out of the box. In this sense, if PCE(i) just constructs a generic graph parsing both opaque types, it can just apply BRPC as in a multi-area, since its "TED" would include the InterAs links anyway. > Please indicate if I missed something. > > " > > In the case of inter-AS TE LSP computation, this also requires adding > > the inter-AS TE links that connect the domain(i) to the domain(i+1). > > " > > For bidirectional it would also need the InterAS TE links that connect domain(i+1) to domain(i), e.g the TE link advertised by ASBR(i+1). Hypothetically / theoretically, we have several solutions * a proxy injects opaque 10 or 11 opaque type 6 advertised by ASBR(i+1) within domain(i+1) into domain(i) [*] * some adjacency is brought up between ASBRs which exchange both sides of the TE link. RFC 5392 seems to exclude this. * the TE links are included in the response within the PCRep when vspt=1 and some other flag Thanks Ramon [*] RFC5392 4.1. Origin of Proxied TE Information Section 4 describes how an ASBR advertises TE link information as a proxy for its neighbor ASBR, but does not describe where this information comes from. (...) to obtain some of the required configuration information from BGP. Whether and how to utilize these possibilities is an implementation matter. --------------010007050900060101000902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Salut Cyril, all



On 08/02/2011 09:55 AM, Margaria, Cyril (NSN - DE/Munich) wrote:

Hi,

 

If I understand correctly the problem PCE (i+1) has complete knowledge the inter AS link (i+1) -> i but not the i->(i+1) link properties (upstream).

Or seen the other way round, the PCE(i) does not have the TE link ASBR(i+1) -> ASBR(i) -- I should say does not have it by OSPF-TE InterAS extesions -- I nitpick since  I humbly believe that, in the spirit of BRPC, the role of PCE(i+1) should stop at entry ASBR. Reducing paths / trimming and applying BRPC should be done by PCE(i) eventually in a two step: interAS + own AS.

 

First I would tend to understand the following section of RFC5441 as :

  PCE (i) can verify the link properties in the i->(i+1) direction  

 

Yes, OSPF-InterAs [RFC5392] addresses this.

This should solve the problem mentioned except in the case the algorithm require to know the link properties in both direction at the same time, but the draft does not address this problem either.

 

Indeed, the problem is _bidirectional_ LSPs. The draft does address this by "embedding" the upstream link in the BRPC response. For unidirectional LSPs, the existing method works out of the box. In this sense, if PCE(i) just constructs a generic graph parsing both opaque types, it can just apply BRPC as in a multi-area, since its "TED" would include the InterAs links anyway.

Please indicate if I missed something.

“

 

   In the case of inter-AS TE LSP computation, this also requires adding

   the inter-AS TE links that connect the domain(i) to the domain(i+1).

“


For bidirectional it would also need the InterAS TE links that connect domain(i+1) to domain(i), e.g the TE link advertised by ASBR(i+1).

Hypothetically / theoretically, we have several solutions

* a proxy injects opaque 10 or 11 opaque type 6 advertised by ASBR(i+1) within domain(i+1) into domain(i) [*]

* some adjacency is brought up between ASBRs which exchange both sides of the TE link. RFC 5392 seems to exclude this.

* the TE links are included in the response within the PCRep when vspt=1 and some other flag



Thanks

Ramon



[*] RFC5392

4.1.  Origin of Proxied TE Information

   Section 4 describes how an ASBR advertises TE link information as a
   proxy for its neighbor ASBR, but does not describe where this
   information comes from.
(...)
   to obtain some of the required configuration
   information from BGP.  Whether and how to utilize these possibilities
   is an implementation matter.
--------------010007050900060101000902-- From cyril.margaria@nsn.com Tue Aug 2 01:46:15 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213CB21F8ED1 for ; Tue, 2 Aug 2011 01:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hed404xbaMsN for ; Tue, 2 Aug 2011 01:46:12 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DC29221F8EC9 for ; Tue, 2 Aug 2011 01:46:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p728kGQR028756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 10:46:16 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p728kBgC005825; Tue, 2 Aug 2011 10:46:16 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Aug 2011 10:46:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC50F0.A1C5A2B6" Date: Tue, 2 Aug 2011 10:46:11 +0200 Message-ID: In-Reply-To: <4E37B51C.3020705@cttc.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01 Thread-Index: AcxQ7kvijTZt126eThieZGhfTPNmJQAAF59w References: <560E52D0-9A68-4330-8160-725C899B2C7E@cisco.com><00cb01cc4bbd$437624a0$14168182@hp3d061f9287af> <33BC8EF6-2208-4CAD-9AE4-BDF02C78A021@cisco.com> <4E37B51C.3020705@cttc.es> From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext Ramon Casellas" , X-OriginalArrivalTime: 02 Aug 2011 08:46:12.0669 (UTC) FILETIME=[A1F876D0:01CC50F0] Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 08:46:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC50F0.A1C5A2B6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ramon,=20 =20 From: ext Ramon Casellas [mailto:ramon.casellas@cttc.es]=20 Sent: Tuesday, August 02, 2011 10:28 AM To: pce@ietf.org; Margaria, Cyril (NSN - DE/Munich) Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01 =20 Salut Cyril, all On 08/02/2011 09:55 AM, Margaria, Cyril (NSN - DE/Munich) wrote:=20 Hi,=20 =20 If I understand correctly the problem PCE (i+1) has complete knowledge the inter AS link (i+1) -> i but not the i->(i+1) link properties (upstream). Or seen the other way round, the PCE(i) does not have the TE link ASBR(i+1) -> ASBR(i) -- I should say does not have it by OSPF-TE InterAS extesions -- I nitpick since I humbly believe that, in the spirit of BRPC, the role of PCE(i+1) should stop at entry ASBR. Reducing paths / trimming and applying BRPC should be done by PCE(i) eventually in a two step: interAS + own AS. [Cyril] If one follow strictly the rfc, yes, but the text could be extended (via errata for example) =20 First I would tend to understand the following section of RFC5441 as :=20 PCE (i) can verify the link properties in the i->(i+1) direction =20 =20 Yes, OSPF-InterAs [RFC5392] addresses this. This should solve the problem mentioned except in the case the algorithm require to know the link properties in both direction at the same time, but the draft does not address this problem either. =20 Indeed, the problem is _bidirectional_ LSPs. The draft does address this by "embedding" the upstream link in the BRPC response. For unidirectional LSPs, the existing method works out of the box. In this sense, if PCE(i) just constructs a generic graph parsing both opaque types, it can just apply BRPC as in a multi-area, since its "TED" would include the InterAs links anyway. [Cyril] : well, for bidirectional LSP you need to check the properties in both direction, but both direction are not required to be checked at the same time : PCE (i+1) check the inter-AS link in direction i+1->i (one direction); PCE (i) check the inter-AS link in direction i->(i+1). In case the algorithm really need to consider both te-properties (upstream and downstream) you would need the TE-properties to be known by PCE(i). I Currently doubt that such requirement from an algorithm exist, if there is a example of an algorithm that really requires it (with BRPC and Dijkstra I think not), its welcomed. The draft does include the inter-as link identifiers (which are known) but not their TE-properties, so in this regard the draft is not solving the problem. Please indicate if I missed something. " =20 In the case of inter-AS TE LSP computation, this also requires adding the inter-AS TE links that connect the domain(i) to the domain(i+1). " =20 For bidirectional it would also need the InterAS TE links that connect domain(i+1) to domain(i), e.g the TE link advertised by ASBR(i+1).=20 Hypothetically / theoretically, we have several solutions * a proxy injects opaque 10 or 11 opaque type 6 advertised by ASBR(i+1) within domain(i+1) into domain(i) [*] * some adjacency is brought up between ASBRs which exchange both sides of the TE link. RFC 5392 seems to exclude this. * the TE links are included in the response within the PCRep when = vspt=3D1 and some other flag Thanks Ramon [*] RFC5392 4.1. Origin of Proxied TE Information Section 4 describes how an ASBR advertises TE link information as a proxy for its neighbor ASBR, but does not describe where this information comes from. (...) to obtain some of the required configuration information from BGP. Whether and how to utilize these possibilities is an implementation matter. ------_=_NextPart_001_01CC50F0.A1C5A2B6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ramon,

 

From: ext Ramon Casellas [mailto:ramon.casellas@cttc.es] =
Sent: Tuesday, August 02, 2011 10:28 AM
To: = pce@ietf.org; Margaria, Cyril (NSN - DE/Munich)
Subject: Re: = [Pce] request timeslot for = draft-wang-pce-inter-as-extentions-01

 

Salut = Cyril, all



On 08/02/2011 09:55 AM, Margaria, Cyril (NSN - = DE/Munich) wrote:

Hi,

 

If I understand correctly the problem PCE (i+1) has complete = knowledge the inter AS link (i+1) -> i but not the i->(i+1) link = properties (upstream).

Or seen = the other way round, the PCE(i) does not have the TE link ASBR(i+1) = -> ASBR(i) -- I should say does not have it by OSPF-TE InterAS = extesions -- I nitpick since  I humbly believe that, in the spirit = of BRPC, the role of PCE(i+1) should stop at entry ASBR. Reducing paths = / trimming and applying BRPC should be done by PCE(i) eventually in a = two step: interAS + own AS.

[Cyril] If one follow strictly the rfc, yes, but the text could be = extended (via errata for example)



 

First I would tend to understand the following section of RFC5441 as = :

  PCE (i) can verify the link properties in the i->(i+1) = direction  

 

Yes, OSPF-InterAs = [RFC5392] addresses this.


This should solve the problem mentioned except in the case the = algorithm require to know the link properties in both direction at the = same time, but the draft does not address this problem = either.

 

Indeed, the problem = is _bidirectional_ LSPs. The draft does address this by = "embedding" the upstream link in the BRPC response. For = unidirectional LSPs, the existing method works out of the box. In this = sense, if PCE(i) just constructs a generic graph parsing both opaque = types, it can just apply BRPC as in a multi-area, since its = "TED" would include the InterAs links anyway.
[Cyril]  : well, for bidirectional LSP you = need to check the properties in both direction, but both direction are = not required to be checked at the same time : PCE (i+1) check the = inter-AS link in direction i+1->i (one direction); PCE (i) check the = inter-AS link in direction i->(i+1).

In case the algorithm = really need to consider both te-properties (upstream and downstream) =  you would need the TE-properties to be known by PCE(i). I = Currently doubt that such requirement from an algorithm exist, if there = is a example of an algorithm that really requires it (with BRPC and = Dijkstra  I think not), its welcomed.

The draft does include = the inter-as link identifiers (which are known) but not their = TE-properties, so in this regard the draft is not solving the = problem.



Please indicate if I missed something.

“

 

   In the case of inter-AS TE LSP computation, this also = requires adding

   the inter-AS TE links that connect the domain(i) to the = domain(i+1).

“

 

For = bidirectional it would also need the InterAS TE links that connect = domain(i+1) to domain(i), e.g the TE link advertised by ASBR(i+1). =

Hypothetically / theoretically, we have several = solutions

* a proxy injects opaque 10 or 11 opaque type 6 = advertised by ASBR(i+1) within domain(i+1) into domain(i) [*]

* = some adjacency is brought up between ASBRs which exchange both sides of = the TE link. RFC 5392 seems to exclude this.

* the TE links are = included in the response within the PCRep when vspt=3D1 and some other = flag



Thanks

Ramon



[*] = RFC5392

4.1.  Origin of Proxied TE = Information

   Section 4 describes how an ASBR = advertises TE link information as a
   proxy for its = neighbor ASBR, but does not describe where this
   = information comes from.
(...)
   to obtain some of the = required configuration
   information from BGP.  = Whether and how to utilize these possibilities
   is an = implementation matter.

------_=_NextPart_001_01CC50F0.A1C5A2B6-- From ramon.casellas@cttc.es Tue Aug 2 02:52:10 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8408121F8EBF for ; Tue, 2 Aug 2011 02:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl-oZIBGWn-J for ; Tue, 2 Aug 2011 02:52:09 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFE121F8EBE for ; Tue, 2 Aug 2011 02:52:08 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p729q3CB024032; Tue, 2 Aug 2011 11:52:09 +0200 Received: from [192.168.0.102] (62.83.138.129.dyn.user.ono.com [62.83.138.129]) by castor (Postfix) with ESMTP id 94D7A2FC285; Tue, 2 Aug 2011 11:52:03 +0200 (CEST) Message-ID: <4E37C8C5.5000500@cttc.es> Date: Tue, 02 Aug 2011 11:52:05 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Margaria, Cyril (NSN - DE/Munich)" References: <560E52D0-9A68-4330-8160-725C899B2C7E@cisco.com><00cb01cc4bbd$437624a0$14168182@hp3d061f9287af> <33BC8EF6-2208-4CAD-9AE4-BDF02C78A021@cisco.com> <4E37B51C.3020705@cttc.es> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070601000509070001070601" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Tue, 02 Aug 2011 11:52:03 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Cc: pce@ietf.org Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 09:52:10 -0000 This is a multi-part message in MIME format. --------------070601000509070001070601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 02/08/2011 10:46, Margaria, Cyril (NSN - DE/Munich) escribió: > > Hi Ramon, > > *From:*ext Ramon Casellas [mailto:ramon.casellas@cttc.es] ** > > > This should solve the problem mentioned except in the case the > algorithm require to know the link properties in both direction at the > same time, but the draft does not address this problem either. > > Indeed, the problem is _bidirectional_ LSPs. The draft does address > this by "embedding" the upstream link in the BRPC response. For > unidirectional LSPs, the existing method works out of the box. In this > sense, if PCE(i) just constructs a generic graph parsing both opaque > types, it can just apply BRPC as in a multi-area, since its "TED" > would include the InterAs links anyway. > > > [Cyril] If one follow strictly the rfc, yes, but the text could be > extended (via errata for example) > > > [Cyril] : well, for bidirectional LSP you need to check the > properties in both direction, but both direction are not required to > be checked at the same time : PCE (i+1) check the inter-AS link in > direction i+1->i (one direction); PCE (i) check the inter-AS link in > direction i->(i+1). > [Ramon] Yes, good point. I was sticking/assuming BRPC as in current RFC5441 (narrow minded :) ?) . As you stated BRPC would need to be extended / clarified to allow this use case, and as far as I understood, draft-wang covers this, where the TE links that have been included/excluded by PCE(i+1) should be notifed to PCE(i) as the draft proposes, shouldn't they? > In case the algorithm really need to consider both te-properties > (upstream and downstream) you would need the TE-properties to be > known by PCE(i). I Currently doubt that such requirement from an > algorithm exist, if there is a example of an algorithm that really > requires it (with BRPC and Dijkstra I think not), its welcomed. > [Ramon] Good point too. Even in intra-domain case, without extra assumptions such as both TE metrics are equal in both directions, it is not straightforward to compute the shortest bidirectional path. CSPF can check both directions of the TE link at the same time to insure that (asymmetric) unreserved bandwidth for that priority is enough when considering a link for relaxation. In any case, since only single InterAS links are to be considered, I agree such requirement is not clear. > The draft does include the inter-as link identifiers (which are known) > but not their TE-properties, so in this regard the draft is not > solving the problem. > So, to get the whole picture, let's try to summarize: a) If a single entity (PCE(i)) is able to know TE atts for both directions, current BRPC is ok. RFC5392 does not solve how, and other routing extensions would be needed, or TE attributes manually provisioned b) Otherwise, both directions of InterAS links should be checked independently, but this requires extending RFC5441, PCE(i+1) notifying of excluded / included links and draft-wang-pce-inter-as-extentions-01 addresses this. I guess my point, probably not well explained in previous mails, is that I would slightly prefer a) provided a good solution allows the upstream InterAS links to be known although I would not object to b) since no such good solution exists?. Finally, I am a bit confused by your last statement. If b) is considered (i.e. independent checking, and link exclusion) what problem is left to solve? sorry for being dense. Thanks R. --------------070601000509070001070601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit El 02/08/2011 10:46, Margaria, Cyril (NSN - DE/Munich) escribió:

Hi Ramon,

 

From: ext Ramon Casellas [mailto:ramon.casellas@cttc.es]


This should solve the problem mentioned except in the case the algorithm require to know the link properties in both direction at the same time, but the draft does not address this problem either.

 

Indeed, the problem is _bidirectional_ LSPs. The draft does address this by "embedding" the upstream link in the BRPC response. For unidirectional LSPs, the existing method works out of the box. In this sense, if PCE(i) just constructs a generic graph parsing both opaque types, it can just apply BRPC as in a multi-area, since its "TED" would include the InterAs links anyway.




[Cyril] If one follow strictly the rfc, yes, but the text could be extended (via errata for example)


[Cyril]  : well, for bidirectional LSP you need to check the properties in both direction, but both direction are not required to be checked at the same time : PCE (i+1) check the inter-AS link in direction i+1->i (one direction); PCE (i) check the inter-AS link in direction i->(i+1).

[Ramon] Yes,  good point. I was sticking/assuming  BRPC as in current RFC5441 (narrow minded :) ?) . As you stated BRPC would need to be extended / clarified to allow this use case, and as far as I understood, draft-wang covers this, where the TE links that have been included/excluded by PCE(i+1) should be notifed to PCE(i) as the draft proposes, shouldn't they?

In case the algorithm really need to consider both te-properties (upstream and downstream)  you would need the TE-properties to be known by PCE(i). I Currently doubt that such requirement from an algorithm exist, if there is a example of an algorithm that really requires it (with BRPC and Dijkstra  I think not), its welcomed.

[Ramon] Good point too. Even in intra-domain case, without extra assumptions such as both TE metrics are equal in both directions, it is not straightforward to compute the shortest bidirectional path. CSPF can check both directions of the TE link at the same time to insure that (asymmetric) unreserved bandwidth for that priority is enough when considering a link for relaxation. In any case, since only single InterAS links are to be considered, I agree such requirement is not clear.

The draft does include the inter-as link identifiers (which are known) but not their TE-properties, so in this regard the draft is not solving the problem.


So, to get the whole picture, let's try to summarize:

a) If a single entity (PCE(i)) is able to know TE atts for both directions, current BRPC is ok. RFC5392 does not solve how, and other routing extensions would be needed, or TE attributes manually provisioned

b) Otherwise, both directions of InterAS links should be checked independently, but this requires extending RFC5441, PCE(i+1) notifying of excluded / included links and draft-wang-pce-inter-as-extentions-01 addresses this.

I guess my point, probably not well explained in previous mails, is that I would slightly prefer a) provided a good solution allows the upstream InterAS links to be known although I would not object to b) since no such good solution exists?.

Finally, I am a bit confused by your last statement. If b) is considered (i.e. independent checking, and link exclusion) what problem is left to solve? sorry for being dense.

Thanks
R.

--------------070601000509070001070601-- From dhruvd@huawei.com Tue Aug 2 10:06:05 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E2D21F8686 for ; Tue, 2 Aug 2011 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, J_CHICKENPOX_15=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGA4rQYgSFmL for ; Tue, 2 Aug 2011 10:06:04 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D2ECD11E807F for ; Tue, 2 Aug 2011 10:06:03 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPB000068U9I7@szxga03-in.huawei.com> for pce@ietf.org; Wed, 03 Aug 2011 01:06:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPB00BTC8U9H9@szxga03-in.huawei.com> for pce@ietf.org; Wed, 03 Aug 2011 01:06:09 +0800 (CST) Received: from Lenovo30414 (72-11.223-242.ny.ny.metconnect.net [72.11.223.242]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPB005HQ8TXFA@szxml12-in.huawei.com>; Wed, 03 Aug 2011 01:06:09 +0800 (CST) Date: Tue, 02 Aug 2011 13:05:25 -0400 From: Dhruv Dhody In-reply-to: <8249B703AE8442429AF89B86E8206AA26F414BFDE3@EUSAACMS0703.eamcs.ericsson.se> To: 'Wenhu Lu' , 'JP Vasseur' , pce@ietf.org Message-id: <001801cc5136$61374e00$23a5ea00$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tAg47CEziMCoQaCumfdd6g)" Content-language: en-us Thread-index: AcxPoQL16mxBQi80SUOKuvK64/5HyQA/FxaQACYCYtA= References: <95E8ECEE-858A-4EAC-8401-2D3F1BF2F113@cisco.com> <8249B703AE8442429AF89B86E8206AA26F414BFDE3@EUSAACMS0703.eamcs.ericsson.se> Subject: Re: [Pce] Fwd: [OSPF] IETF 81 WG Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:06:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_tAg47CEziMCoQaCumfdd6g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Wenhu, JP, Ramon and All, I just wanted to add this - >From RFC 5441, section 4.2: Note that PCE(i) only considers the entry BNs of domain(i), i.e., only the BNs that provide connectivity from domain(i-1). In other words, the set BN-en(k,i) is only made of those BNs that provide connectivity from domain (i-1) to domain(i). If we want to follow RFC completely and correctly, PCE must select only those boundary nodes that provides connectivity between the domain (i-1) and (i), and this could only be done when PCE is aware of both the BNs and their connecting domains to make this decision correctly. Regards, Dhruv From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Wenhu Lu Sent: Monday, August 01, 2011 10:01 PM To: JP Vasseur; pce@ietf.org Subject: Re: [Pce] Fwd: [OSPF] IETF 81 WG Minutes Hi JP and all, Thanks everyone for the comments and discussions regarding this ID during and after the PCE session. I agree with JP that we shouldn't make changes unless they are necessary or beneficial. I also agree with Ramon, Dhruv and Jonathan that we shouldn't settle on manual provisioning if we can do auto-discovery, and we shouldn't settle on brute force approaches if we can do things systematically. The discussion during the PCE WG session boiled down to the question: for inter-area path computation, is the "brute force" method good enough that the draft method provides little merit? Here the "brute force" means that a PCE can use OSPF type-3 LSAs to figure out the ABRs and the reachability to the LSP tailend and do path computation accordingly, regardless whether ABRs are TE enable, or which areas the ABRs are connecting to. If an ABR is not TE capable, it will be discarded later by the next PCE. Please correct me if my interpretation is wrong. My arguments are following (Ramon already explained a use-case of the area-id in an earlier email. Here I add to it a few more points): 1. In BRPC method, the area (domain) sequence will help accomplish the inter-area path computation. Nevertheless, knowing not the area-id, the "bruth-force" won't work with the area sequence. 2. The area-id TLV also implies ABR's TE capability. A typical OSPF topology is a backbone with many surrounding non-backbone areas. There can be many ABRs from the backbone's perspective. This means that without the ABR's TE info, the crankback method will have to spend long time to go through the list. This also means that the BRPC method will have to build a very fat-tree (VSPT). It cannot trim the tree by excluding the non-TE ABRs and non-related areas until the VSPT is passed to the next PCE. For a deployed LSP based network, the number of LSPs can be thousands. Considering the re-optimization, make-before-break, bypass and backup path computation, the scalability and computation efficiency are very important factors. The "brute force" apparently is not designed for such heavy computation tasks. It may quickly become the scalability bottleneck. 3. In terms of information propagation, the intra-area path computation is self-sustained. The PCE gets everything from the TED. For the inter-area path computation, the self-sustaining nature can be easily preserved with the addition of the area-id-tlv. In this sense, the "brute force" is not only slow, it has to resort to some "out-of-band" methods to acquire the ABR information. 4. To answer Abhay's question, RFC 5088 is for PCE auto-discovery. It is not for TE-ABR auto-discovery. As Ramon pointed out, they are orthogonal and complimentary. Thanks, -wenhu _____ From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Sunday, July 31, 2011 9:43 AM To: pce@ietf.org Subject: [Pce] Fwd: [OSPF] IETF 81 WG Minutes Begin forwarded message: From: JP Vasseur Subject: Re: [OSPF] IETF 81 WG Minutes Date: July 31, 2011 12:13:02 PM EDT To: Acee Lindem , "Abhay Roy (akr)" Cc: OSPF List Thanks Acee, Just a feed-back on one ID after the PCE WG meeting: 8) Updates to OSPF TE Extension for Area IDs Slides draft-lu-ospf-area-tlv-01.txt - Wenhu Lu 10 minutes See slides Abhay: What were comments in PCE presentation? Wenhu: Good reception. Why do we need to know Area ID? Isn't it enough to simply know if ABR is TE enabled? Solution avoids "brute force" solution and produces faster convergence. Abhay: Discussed with PCE chairs. RFC 5088 - extensions for PCE. Look at those extensions to see if they can be used. Wenhu: Will do that. JP> The draft was discussed in the PCE WG meeting, but there was no consensus that this document provides an extension that addresses a use case for PCE. To be discussed on the PCE mailing list and we will keep you posted. Thanks. JP. On Jul 29, 2011, at 9:30 PM, Acee Lindem wrote: I've posted the IETF WG Minutes. Thanks much to Les Ginsberg for taking them. There was one ISP representative from Asia who commented but we did not get his name. If this was you, please unicast me and I will update the minutes with your name. Abhay and I will follow up with E-mails on specific documents presented at IETF 81. http://www.ietf.org/proceedings/81/minutes/ospf.txt Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --Boundary_(ID_tAg47CEziMCoQaCumfdd6g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear Wenhu, JP, Ramon and All,

 

I just wanted to add this -

 

From RFC 5441, section 4.2:

   Note that PCE(i) only considers the entry BNs of domain(i), i.e.,

   only the BNs that provide connectivity from domain(i-1).  In other

   words, the set BN-en(k,i) is only made of those BNs that provide

   connectivity from domain (i-1) to domain(i).

 

If we want to follow RFC completely and correctly, PCE must select only those boundary nodes that provides connectivity between the domain (i-1) and (i), and this could only be done when PCE is aware of both the BNs and their connecting domains to make this decision correctly.  

 

Regards,

Dhruv

 

le='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Wenhu Lu
Sent: Monday, August 01, 2011 10:01 PM
To: JP Vasseur; pce@ietf.org
Subject: Re: [Pce] Fwd: [OSPF] IETF 81 WG Minutes

 

Hi JP and all,

 

Thanks everyone for the comments and discussions regarding this ID during and after the PCE session.

I agree with JP that we shouldn't make changes unless they are necessary or beneficial.

I also agree with Ramon, Dhruv and Jonathan that we shouldn't settle on manual provisioning if we can do auto-discovery, and we shouldn't settle on brute force approaches if we can do things systematically.

 

The discussion during the PCE WG session boiled down to the question:

    for inter-area path computation, is the "brute force" method good enough that the draft method provides little merit?

 

Here the &qu s that a PCE can use OSPF type-3 LSAs to figure out the ABRs and the reachability to the LSP tailend and do path computation accordingly, regardless whether ABRs are TE enable, or which areas the ABRs are connecting to. If an ABR is not TE capable, it will be discarded later by the next PCE. Please correct me if my interpretation is wrong.

 

My arguments are following (Ramon already explained a use-case of the area-id in an earlier email. Here I add to it a few more points):

1. In BRPC method, the area (domain) sequence will help accomplish the inter-area path computation. Nevertheless, knowing not the area-id, the "bruth-force" won't work with the area sequence.2. The area-id TLV also implies ABR's TE capability.

    A typical OSPF topology is a backbone with many surrounding non-backbone areas. There can be many ABRs from the backbone's perspective.

    This means that without the ABR's TE info, the crankback method will have to spend long time to go through the list.

    This also means that the BRPC method will have to build a very fat-tree (VSPT). It cannot trim the tree by excluding the non-TE ABRs and non-related areas&nbs p;until next PCE.

    For a deployed LSP based network, the number of LSPs can be thousands. Considering the re-optimization, make-before-break, bypass and backup path computation, the scalability and computation efficiency are very important factors.

    The "brute force" apparently is not designed for such heavy computation tasks. It may quickly become the scalability bottleneck.

3. In terms of information propagation, the intra-area path computation is self-sustained. The PCE gets everything from the TED. For the inter-area path computation, the self-sustaining nature c an be ea ddition of the area-id-tlv.

    In this sense, the "brute force" is not only slow, it has to resort to some "out-of-band" methods to acquire the ABR information.

4. To answer Abhay's question, RFC 5088 is for PCE auto-discovery. It is not for TE-ABR auto-discovery.  As Ramon pointed out, they are orthogonal and complimentary.

 

Thanks,

-wenhu

 

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: Sunday, July 31, 2011 9:43 AM
To: pce@ietf.org
Subject: [Pce] Fwd: [OSPF] IETF 81 WG Minutes

 

 

Begin forwarded message:



From: JP Vasseur <jpv@cisco.com>

Subject: Re: [OSPF] IETF 81 WG Minutes

Date: July 31, 2011 12:13:02 PM EDT

To: Acee Lindem <acee.lindem@ericsson.com>, "Abhay Roy (akr)" <akr@cisco.com>

Cc: < /b>OSPF List <ospf@ietf.org>

 

Thanks Acee,

 

Just a feed-back on one ID after the PCE WG meeting:

 


8) Updates to OSPF TE Extension for Area IDs    Slides
   draft-lu-ospf-area-tlv-01.txt
- Wenhu Lu 
10 minutes

See slides

Abhay: What were comments in PCE presentation?
Wenhu: Good reception. Why do we need to know Area ID? Isn't it enough to  y know if ABR is TE enabled? Solution avoids "brute force" solution and 
 produces faster convergence.

Abhay: Discussed with PCE chairs. RFC 5088 - extensions for PCE. Look at those 
extensions to see if they can be used.
Wenhu: Will do that.

 

JP> The draft was discussed in the PCE WG meeting, but there was no consensus that

this document provides an extension that addresses a use case for PCE. To be discussed

on the PCE mailing list and we will keep you posted.

 

Thanks.

 

JP.

  ass=MsoNormal>On Jul 29, 2011, at 9:30 PM, Acee Lindem wrote:



I've posted the IETF WG Minutes. Thanks much to Les Ginsberg for taking them. There was one ISP representative from Asia who commented but we did not get his name. If this was you, please unicast me and I will update the minutes with your name.  

Abhay and I will follow up with E-mails on specific documents presented at IETF 81.

http://www.ietf.org/proceedings/81/minutes/ospf.txt

Thanks,
Acee
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

 

_______________________________________________
OSPF mailing list
> "Upon receiving a TCP connection on the PCEP-registered TCP port"; I do > not > > see any behavior description for the source TCP port (good thing!). > > My guess is that there is no intend to put constraints on the TCP > initiator > > port. I would interpret the sentence you mention as "using the register= ed > > TCP port on the PCE side, i.e. for the source TCP port for PCE to PCC > > messages and for destination TCP port for PCC to PCE messages"... A > little > > cumbersome, I agree. > > > > Authors of RFC 5440, would there be an actual intend to specify > otherwise? > > Implementers, any other interpretation? > > > > Thanks, > > > > Julien > > > > > > -----Original Message----- > > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > > Vishwas Manral > > > > Hi, > > > > I looked at the following in the spec: > > > > =93Transport Protocol > > > > PCEP operates over TCP using a registered TCP port (4189). This > > allows the requirements of reliable messaging and flow control to be > > met without further protocol work. All PCEP messages MUST be sent > > using the registered TCP port for the source and destination TCP > > port.=94 > > > > This has been worrying me a bit. Unlike other protocols like BGP or LDP > > > > In BGP it states clearly: > > > > A BGP implementation MUST connect to and listen on TCP port 179 for > > incoming connections in addition to trying to connect to peers. > > > > and > > > > BGP's destination port SHOULD be port 179, as defined by IANA. > > > > Why do we have this restriction on source port? It is becoming a > > challenging task > > in merchant OS. > > > > Thanks, > > Vishwas > > Vishwas > --0023544710d003c41904a98c7a97 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

=A0
I heard this very issue came up again in the PCE, after a couple of ye= ars. Do you want me to finally put out a draft for this?
=A0
I think this is a basic change and requires a lot more then an errata,= as this changes the basic protocol functioning.
=A0
Thanks,
Vishwas
=A0
On Fri, Sep 11, 2009 at 10:01 AM, Vishwas Manral= <vishwas.ie= tf@gmail.com> wrote:
Hi Adrian,

It would have = been ok if it was a connectionless transport like UDP.

However I not= ice a problem when I want multiple sockets to use the
same port number in particular cases. I figured that I cannot have a
ser= ver socket (accepting connections) as well as a client socket
trying to = connect having the same port number, though I can allow same
port to be = shared across multiple sockets in some cases by using the
socket option SO_REUSEPORT.

Thanks,
Vishw= as

On Fri, Sep 11, 2009 at 9:33 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
= > Hi,
>
> For my part (I only worked as an author quite late= in the process, but I was
> helping to get this through the IESG review that raised issued about T= CP
> ports) I think Julien has not captured the point.
>
>= ; The RFC is not silent about source ports because it does intend to limit = the
> scope.
>
> As Julien says, it does matter which port is li= stened on, and this is
> deliberately a well-known port number so tha= t it is not necessary to
> configure (or advertise) the port that mus= t be called.
>
> But in Section 4.2.1 you will find...
>
> =A0Only = one PCEP session can exist between a pair of PCEP peers at any
> =A0o= ne time. =A0Only one TCP connection on the PCEP port can exist between
&= gt; =A0a pair of PCEP peers at any one time.
>
> One way to help ensure this is to reduce the number of availab= le ports to
> use as the source port.
>
> Does restrictin= g the source port cause any implementation or deployment
> problems?<= br> >
> Thanks,
> Adrian
>
> ----- Original Message = ----- From: <julien.= meuric@orange-ftgroup.com>
> To: <vishwas.ietf@gmail.com>; <jpv@cisco.com>;
> <jeanlouis.l= eroux@orange-ftgroup.com>
> Cc: <pce@ietf.org>
> Sent: Thursday, September 10, 2009 9:57 = AM
> Subject: Re: [Pce] PCE port number
>
>
> Hi Vishwas.=
>
> Interesting comment. We must admit the wording is a bit am= biguous.
>
> RFC 5440 says: "The system listens to the PCE= P-registered TCP port" and
> "Upon receiving a TCP connection on the PCEP-registered TCP port&= quot;; I do not
> see any behavior description for the source TCP por= t (good thing!).
> My guess is that there is no intend to put constra= ints on the TCP initiator
> port. I would interpret the sentence you mention as "using the re= gistered
> TCP port on the PCE side, i.e. for the source TCP port for= PCE to PCC
> messages and for destination TCP port for PCC to PCE me= ssages"... A little
> cumbersome, I agree.
>
> Authors of RFC 5440, would there = be an actual intend to specify otherwise?
> Implementers, any other i= nterpretation?
>
> Thanks,
>
> Julien
>
>
> -----Original Message-----
> From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of
> Vishwas Man= ral
>
> Hi,
>
> I looked at the following in the spec:
= >
> =93Transport Protocol
>
> =A0PCEP operates over TC= P using a registered TCP port (4189). =A0This
> =A0allows the require= ments of reliable messaging and flow control to be
> =A0met without further protocol work. =A0All PCEP messages MUST be sen= t
> =A0using the registered TCP port for the source and destination T= CP
> =A0port.=94
>
> This has been worrying me a bit. Unl= ike other protocols like BGP or LDP
>
> In BGP it states clearly:
>
> =A0A BGP implementat= ion MUST connect to and listen on TCP port 179 for
> =A0incoming conn= ections in addition to trying to connect to peers.
>
> and
&= gt;
> =A0BGP's destination port SHOULD be port 179, as defined by IANA.<= br>>
> Why do we have this restriction on source port? It is becom= ing a
> challenging task
> in merchant OS.
>
> Than= ks,
> Vishwas
> Vishwas
--0023544710d003c41904a98c7a97-- From ramon.casellas@cttc.es Tue Aug 2 16:31:57 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B417411E80FE for ; Tue, 2 Aug 2011 16:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxNvNoQk9+hr for ; Tue, 2 Aug 2011 16:31:56 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 6404511E8095 for ; Tue, 2 Aug 2011 16:31:56 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p72NVqSd026340 for ; Wed, 3 Aug 2011 01:31:57 +0200 Received: from [192.168.0.102] (62.83.138.129.dyn.user.ono.com [62.83.138.129]) by castor (Postfix) with ESMTP id 3EA5D2FC22E for ; Wed, 3 Aug 2011 01:31:53 +0200 (CEST) Message-ID: <4E3888EB.1050501@cttc.es> Date: Wed, 03 Aug 2011 01:31:55 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pce@ietf.org References: <77ead0ec0909091140s2e5a41dbke3e8abb719b74115@mail.gmail.com> <2AA6B590D7B04C28826192EFBCB5FFAD@your029b8cecfe> <77ead0ec0909111001w73c7d3b4w71d3c2cbede85551@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Wed, 03 Aug 2011 01:31:53 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] PCE port number X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:31:57 -0000 El 02/08/2011 23:31, Vishwas Manral escribió: > Hi folks, > I heard this very issue came up again in the PCE, after a couple of > years. Do you want me to finally put out a draft for this? > I think this is a basic change and requires a lot more then an errata, > as this changes the basic protocol functioning. > Hi Vishwas Indeed, I presented the issue in IETF80 in Prague, you may want to check the slides [1-2], plus several mails to the list (along with private ones) discussing technical aspects as BSD sockets, Linux, reuseaddr etc. as a follow up of yours (and others) concerns during latest stages (~2009). During the meeting, it seemed a consensus that it was worth changing, after checking potential security implications. I was hoping a final answer would be given during IETF81. IMHO, I do believe that an errata should be enough, since only the actual protocol transport is affected, not the protocol itself (well, true, the transport is somehow part of the protocol but... :) From a practical point of view, the client just needs to allow the S.O to select an ephemeral port, and avoid a (potentially problematic) bind syscall. It can be argued that forcing the bind does not improve security. Removing this restriction actually simplies both the client/server. Backwards compatilibily is only problematic in the case where the accepting side of the TCP connection (i.e. the PCE acting as a TCP server) actually enforces the incoming source port, rejecting the connection A (completely limited, unofficial, ...) survery did not show that this specific point was affecting a lot of implementations (none?) Thanks and best regards Ramon [1] http://www.ietf.org/proceedings/80/minutes/pce.htm [2] http://www.ietf.org/proceedings/80/slides/pce-0.pdf -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 From vishwas.ietf@gmail.com Tue Aug 2 16:51:29 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B2F21F86C0 for ; Tue, 2 Aug 2011 16:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InRM1tVNPzCS for ; Tue, 2 Aug 2011 16:51:28 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5198721F86BF for ; Tue, 2 Aug 2011 16:51:28 -0700 (PDT) Received: by qwc23 with SMTP id 23so243225qwc.31 for ; Tue, 02 Aug 2011 16:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lsGHCbokXPpNH9x4Yp2vP1VeOnCQIgV2rlXoPx27zbE=; b=gNyg081srh/iRqC9HK/TDLygisIaxqK7n2veDHDAVNSf863B5czeLpqi/uBKG+0BGG V9exvFIdf6sji3fVOEfPVKN/JGPD/xfySeDaPjuv9Yc6pDPRNsUQ+kPN572K2XasJK3K dylaX1LIpMIHolDhqO5GaRPmfZhlEKFXGKiN8= MIME-Version: 1.0 Received: by 10.229.224.145 with SMTP id io17mr1692967qcb.267.1312329095771; Tue, 02 Aug 2011 16:51:35 -0700 (PDT) Received: by 10.229.65.91 with HTTP; Tue, 2 Aug 2011 16:51:35 -0700 (PDT) In-Reply-To: <4E3888EB.1050501@cttc.es> References: <77ead0ec0909091140s2e5a41dbke3e8abb719b74115@mail.gmail.com> <2AA6B590D7B04C28826192EFBCB5FFAD@your029b8cecfe> <77ead0ec0909111001w73c7d3b4w71d3c2cbede85551@mail.gmail.com> <4E3888EB.1050501@cttc.es> Date: Tue, 2 Aug 2011 16:51:35 -0700 Message-ID: From: Vishwas Manral To: Ramon Casellas Content-Type: multipart/alternative; boundary=00163646dad494f62a04a98e6dc3 Cc: pce@ietf.org Subject: Re: [Pce] PCE port number X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:51:30 -0000 --00163646dad494f62a04a98e6dc3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ramon, Great to see you have done extensive work in this area. I had brought this up earlier on the list, and I knew of the problems impending. Infact I remember talking to Julien at one of the IETF's about this. With that said, this is basic functionality change, about which port a protocol should use. I do not think, we can make a change about the transport as an errata. It very clearly is the case of a new draft required= , we can expedite this through the IETF processes so that it is made an RFC soon. Let me know if you are willing to help writing the draft. I think it is a necessary requirement that will help the PCE community, which I only see growing. Thanks, Vishwas On Tue, Aug 2, 2011 at 4:31 PM, Ramon Casellas wrot= e: > El 02/08/2011 23:31, Vishwas Manral escribi=F3: > > Hi folks, >> I heard this very issue came up again in the PCE, after a couple of year= s. >> Do you want me to finally put out a draft for this? >> I think this is a basic change and requires a lot more then an errata, a= s >> this changes the basic protocol functioning. >> >> > Hi Vishwas > > Indeed, I presented the issue in IETF80 in Prague, you may want to check > the slides [1-2], plus several mails to the list (along with private one= s) > discussing technical aspects as BSD sockets, Linux, reuseaddr etc. as a > follow up of yours (and others) concerns during latest stages (~2009). > During the meeting, it seemed a consensus that it was worth changing, aft= er > checking potential security implications. I was hoping a final answer wou= ld > be given during IETF81. > > IMHO, I do believe that an errata should be enough, since only the actual > protocol transport is affected, not the protocol itself (well, true, the > transport is somehow part of the protocol but... :) > From a practical point of view, the client just needs to allow the S.O to > select an ephemeral port, and avoid a (potentially problematic) bind > syscall. It can be argued that forcing the bind does not improve security= . > Removing this restriction actually simplies both the client/server. > > Backwards compatilibily is only problematic in the case where the accepti= ng > side of the TCP connection (i.e. the PCE acting as a TCP server) actually > enforces the incoming source port, rejecting the connection > > A (completely limited, unofficial, ...) survery did not show that this > specific point was affecting a lot of implementations (none?) > > Thanks and best regards > Ramon > > > [1] http://www.ietf.org/**proceedings/80/minutes/pce.htm > > [2] http://www.ietf.org/**proceedings/80/slides/pce-0.**pdf > > -- > Ramon Casellas, Ph.D. > Research Associate - Optical Networking Area -- http://wikiona.cttc.es > CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 > Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain > Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 > --00163646dad494f62a04a98e6dc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ramon,
=A0
Great to see you have done extensive work in this area. I had brought = this up earlier on the list, and I knew of the problems impending. Infact I= remember talking to Julien at one of the IETF's about this.
=A0
With that said,=A0this is basic functionality change, about which port= a protocol should use. I do not think, we can make a change about the tran= sport as an errata. It very clearly is the case of a new draft required, we= can expedite this through the IETF processes so that it is made an RFC soo= n. =A0
=A0
Let me know if you are willing to help writing the draft. I think it i= s a necessary requirement that will help the PCE community, which I only se= e growing.
=A0
Thanks,
Vishwas
On Tue, Aug 2, 2011 at 4:31 PM, Ramon Casellas <= span dir=3D"ltr"><ramon.casell= as@cttc.es> wrote:
El 02/08/2011 23:31, Vishwas Man= ral escribi=F3:=20

Hi folks,
I heard this very i= ssue came up again in the PCE, after a couple of years. Do you want me to f= inally put out a draft for this?
I think this is a basic change and requires a lot more then an errata, as t= his changes the basic protocol functioning.


H= i Vishwas

Indeed, I presented the issue in IETF80 in Prague, you may= want to check the slides [1-2], =A0plus several mails to the list (along w= ith private ones) discussing technical aspects as BSD sockets, Linux, reuse= addr etc. as a follow up of yours (and others) concerns during latest stage= s (~2009). During the meeting, it seemed a consensus that it was worth chan= ging, after checking potential security implications. I was hoping a final = answer would be given during IETF81.

IMHO, I do believe that an errata should be enough, since only the actu= al protocol transport is affected, not the protocol itself (well, true, the= transport is somehow part of the protocol but... :)
From a practical po= int of view, the client just needs to allow the S.O to select an ephemeral = port, and avoid a (potentially problematic) bind syscall. It can be argued = that forcing the bind does not improve security.
Removing this restriction actually simplies both the client/server.

= Backwards compatilibily is only problematic in the case where the accepting= side of the TCP connection (i.e. the PCE acting as a TCP server) actually = enforces the incoming source port, rejecting the connection

A (completely limited, unofficial, ...) survery did not show that this = specific point was affecting a lot of implementations (none?)

Thanks= and best regards
Ramon


[1] http://www.ietf.org/= proceedings/80/minutes/pce.htm

[2] http://www.ietf.org/proceedings/80/slides/pce-0.pdf

--
Ramon Casellas, Ph.D.
Re= search Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4
= Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Te= l.: +34 93 645 29 00 -- Fax. +34 93 645 29 01=20
--00163646dad494f62a04a98e6dc3-- From ramon.casellas@cttc.es Tue Aug 2 17:01:55 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67ECA11E80DD for ; Tue, 2 Aug 2011 17:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFg15cYafK9X for ; Tue, 2 Aug 2011 17:01:54 -0700 (PDT) Received: from aquila.cttc.es (aquila.cttc.es [84.88.62.230]) by ietfa.amsl.com (Postfix) with ESMTP id 9394A11E8095 for ; Tue, 2 Aug 2011 17:01:54 -0700 (PDT) Received: from leo (leo.cttc.es [84.88.62.208]) by aquila.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7320EPd002873; Wed, 3 Aug 2011 04:00:14 +0200 Received: from [192.168.0.102] (62.83.138.129.dyn.user.ono.com [62.83.138.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 3CAAB200F2; Wed, 3 Aug 2011 02:01:46 +0200 (CEST) Message-ID: <4E388FEB.7050008@cttc.es> Date: Wed, 03 Aug 2011 02:01:47 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0909091140s2e5a41dbke3e8abb719b74115@mail.gmail.com> <2AA6B590D7B04C28826192EFBCB5FFAD@your029b8cecfe> <77ead0ec0909111001w73c7d3b4w71d3c2cbede85551@mail.gmail.com> <4E3888EB.1050501@cttc.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.4 (leo [0.0.0.0]); Wed, 03 Aug 2011 02:01:46 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.230 Cc: pce@ietf.org Subject: Re: [Pce] PCE port number X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:01:55 -0000 El 03/08/2011 1:51, Vishwas Manral escribió: > It very clearly is the case of a new draft required, we can expedite > this through the IETF processes so that it is made an RFC soon. I guess I am not knowledgeable enough about best/current IETF-related practices & procedures, so I will humbly step back and let others decide :) (chairs?) > Let me know if you are willing to help writing the draft. I think it > is a necessary requirement that will help the PCE community, which I > only see growing. If this is the case, gladly, although I guess it would be a one-page "Updates" RFC? R. From zhang.fei3@zte.com.cn Tue Aug 2 17:54:10 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F39B11E811C; Tue, 2 Aug 2011 17:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.656 X-Spam-Level: X-Spam-Status: No, score=-98.656 tagged_above=-999 required=5 tests=[AWL=1.630, BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mez59NitgTR2; Tue, 2 Aug 2011 17:54:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DE8DC11E8108; Tue, 2 Aug 2011 17:54:08 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48643280467362; Wed, 3 Aug 2011 08:51:49 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 22013.6446524895; Wed, 3 Aug 2011 08:54:18 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p730sC85090977; Wed, 3 Aug 2011 08:54:12 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4E388FEB.7050008@cttc.es> To: Ramon Casellas , Vishwas Manral MIME-Version: 1.0 X-KeepSent: A48B779B:95AE85C6-482578E1:000457B5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 3 Aug 2011 08:54:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-03 08:54:12, Serialize complete at 2011-08-03 08:54:12 Content-Type: multipart/related; boundary="=_related 0004F481482578E1_=" X-MAIL: mse01.zte.com.cn p730sC85090977 Cc: pce-bounces@ietf.org, pce@ietf.org Subject: Re: [Pce] PCE port number X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:54:10 -0000 This is a multipart message in MIME format. --=_related 0004F481482578E1_= Content-Type: multipart/alternative; boundary="=_alternative 0004F482482578E1_=" --=_alternative 0004F482482578E1_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgUmFtb24sIFZpc2h3YXMNCg0KSSB0aGluayB0aGUgV0cgcHJlZmVyIHRvIHVzZSBSRkMgZXJy YXRhLCANClBsZWFzZSBjaGVjayB0aGUgcHJlc2VudGF0aW9uIG1hdGVyaWFsICJXRyBzdGF0dXMi IGluIElFVEY4MQ0KDQoNCg0KDQpSYW1vbiBDYXNlbGxhcyA8cmFtb24uY2FzZWxsYXNAY3R0Yy5l cz4gDQrlj5Hku7bkuro6ICBwY2UtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0wOC0wMyAwODowMQ0K DQrmlLbku7bkuroNClZpc2h3YXMgTWFucmFsIDx2aXNod2FzLmlldGZAZ21haWwuY29tPg0K5oqE 6YCBDQpwY2VAaWV0Zi5vcmcNCuS4u+mimA0KUmU6IFtQY2VdIFBDRSBwb3J0IG51bWJlcg0KDQoN Cg0KDQoNCg0KRWwgMDMvMDgvMjAxMSAxOjUxLCBWaXNod2FzIE1hbnJhbCBlc2NyaWJpw7M6DQo+ ICBJdCB2ZXJ5IGNsZWFybHkgaXMgdGhlIGNhc2Ugb2YgYSBuZXcgZHJhZnQgcmVxdWlyZWQsIHdl IGNhbiBleHBlZGl0ZSANCj4gdGhpcyB0aHJvdWdoIHRoZSBJRVRGIHByb2Nlc3NlcyBzbyB0aGF0 IGl0IGlzIG1hZGUgYW4gUkZDIHNvb24uIA0KSSBndWVzcyBJIGFtIG5vdCBrbm93bGVkZ2VhYmxl IGVub3VnaCBhYm91dCBiZXN0L2N1cnJlbnQgSUVURi1yZWxhdGVkIA0KcHJhY3RpY2VzICYgcHJv Y2VkdXJlcywgc28gSSB3aWxsIGh1bWJseSBzdGVwIGJhY2sgYW5kIGxldCBvdGhlcnMgZGVjaWRl IA0KOikgKGNoYWlycz8pDQoNCj4gIExldCBtZSBrbm93IGlmIHlvdSBhcmUgd2lsbGluZyB0byBo ZWxwIHdyaXRpbmcgdGhlIGRyYWZ0LiBJIHRoaW5rIGl0IA0KPiBpcyBhIG5lY2Vzc2FyeSByZXF1 aXJlbWVudCB0aGF0IHdpbGwgaGVscCB0aGUgUENFIGNvbW11bml0eSwgd2hpY2ggSSANCj4gb25s eSBzZWUgZ3Jvd2luZy4NCklmIHRoaXMgaXMgdGhlIGNhc2UsIGdsYWRseSwgYWx0aG91Z2ggSSBn dWVzcyBpdCB3b3VsZCBiZSBhIG9uZS1wYWdlIA0KIlVwZGF0ZXMiIFJGQz8NClIuDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBs aXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGNlDQoNCg0KDQo= --=_alternative 0004F482482578E1_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJhbW9uLCBWaXNod2FzPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHRoaW5rIHRo ZSBXRyBwcmVmZXIgdG8gdXNlIFJGQyBlcnJhdGEsDQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPlBsZWFzZSBjaGVjayB0aGUgcHJlc2VudGF0aW9uIG1hdGVyaWFs DQomcXVvdDtXRyBzdGF0dXMmcXVvdDsgaW4gSUVURjgxPC9mb250Pg0KPGJyPjxpbWcgc3JjPWNp ZDpfMV8wN0ZGMjk5NDA3RkYyNDAwMDAwNEYzM0M0ODI1NzhFMT4NCjxicj4NCjxicj4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5SYW1vbiBDYXNlbGxhcyAmbHQ7cmFtb24uY2Fz ZWxsYXNAY3R0Yy5lcyZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPuWPkeS7tuS6ujogJm5ic3A7cGNlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wOC0wMyAwODowMTwvZm9udD4N Cjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+5pS25Lu2 5Lq6PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5WaXNo d2FzIE1hbnJhbCAmbHQ7dmlzaHdhcy5pZXRmQGdtYWlsLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPuaKhOmAgTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+cGNlQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7kuLvpopg8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbUGNlXSBQQ0UgcG9y dCBudW1iZXI8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPkVsIDAzLzA4LzIwMTEgMTo1MSwgVmlzaHdhcyBNYW5yYWwgZXNjcmliacOzOjxi cj4NCiZndDsgJm5ic3A7SXQgdmVyeSBjbGVhcmx5IGlzIHRoZSBjYXNlIG9mIGEgbmV3IGRyYWZ0 IHJlcXVpcmVkLCB3ZSBjYW4NCmV4cGVkaXRlIDxicj4NCiZndDsgdGhpcyB0aHJvdWdoIHRoZSBJ RVRGIHByb2Nlc3NlcyBzbyB0aGF0IGl0IGlzIG1hZGUgYW4gUkZDIHNvb24uIDxicj4NCkkgZ3Vl c3MgSSBhbSBub3Qga25vd2xlZGdlYWJsZSBlbm91Z2ggYWJvdXQgYmVzdC9jdXJyZW50IElFVEYt cmVsYXRlZCA8YnI+DQpwcmFjdGljZXMgJmFtcDsgcHJvY2VkdXJlcywgc28gSSB3aWxsIGh1bWJs eSBzdGVwIGJhY2sgYW5kIGxldCBvdGhlcnMgZGVjaWRlDQo8YnI+DQo6KSAoY2hhaXJzPyk8YnI+ DQo8YnI+DQomZ3Q7ICZuYnNwO0xldCBtZSBrbm93IGlmIHlvdSBhcmUgd2lsbGluZyB0byBoZWxw IHdyaXRpbmcgdGhlIGRyYWZ0LiBJDQp0aGluayBpdCA8YnI+DQomZ3Q7IGlzIGEgbmVjZXNzYXJ5 IHJlcXVpcmVtZW50IHRoYXQgd2lsbCBoZWxwIHRoZSBQQ0UgY29tbXVuaXR5LCB3aGljaA0KSSA8 YnI+DQomZ3Q7IG9ubHkgc2VlIGdyb3dpbmcuPGJyPg0KSWYgdGhpcyBpcyB0aGUgY2FzZSwgZ2xh ZGx5LCBhbHRob3VnaCBJIGd1ZXNzIGl0IHdvdWxkIGJlIGEgb25lLXBhZ2UgPGJyPg0KJnF1b3Q7 VXBkYXRlcyZxdW90OyBSRkM/PGJyPg0KUi48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClBjZSBtYWlsaW5nIGxpc3Q8YnI+DQpQ Y2VAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bj ZTxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0004F482482578E1_=-- --=_related 0004F481482578E1_= Content-Type: image/gif Content-ID: <_1_07FF299407FF24000004F33C482578E1> Content-Transfer-Encoding: base64 R0lGODlhcAOgAucAAAAAAP///5gAAPj40HC46Oi4cAAAcLjo+AAAmND4+NCYAABwuOj4+ACY0Pj4 6LhwAPjouHAAAPjQmJjQ+EhISOjo6GhoaIiIiODg4Hh4eKCgoLi4uNDQ0PDw8JiYmMDAwLCwsNjY 2JiYcHC4uOjQmLjQ+Li4cJjQ0Li4mHBwALhwcNDouHBwcHCYmJi4uABwmHC40JhwAOjouLjo0NC4 cHAAcHBwuJgAcNDQmND40Oj40AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAcAOgAkAI/wADCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtatXrRU+aLhgAYBZABYu aODQ4avbt3Djyp1LdyiGs2czTKSAF8AFt30v9h2M4eHguhsPI15MMjDjx1U/9NWQkm9fCx8qDAxb ti8FhZbxYtYskPPgzwgrnAZRWGAIDYPxCnYcwMPgDQoVI8ww+AIH0gE6vB5swWBoAG0T3h0cQqHq s6hLe2ZN0DTe6BV1bwxBm+Hx5gZ59//1DVw47MsJYwPw0LoCbBACOYhueN4sZePEM2/+0Pl6+utn jTYQBvXhldxB4uFF3kDmEbfQBWf9BdmEUWm3kHoYAhAeXq09tJxZxQ2UIAAdOvQhWgRBeFaJC52o oUUWDrRBbwXFGICKGeaoYEHPmaVXQTOe1daJ8BXUHwDAEXRkbB58cGBi3XXUo1lPEtQXiwLhqKOO Elop20Mg4PVjQZLlhSCHEZ0YopdnGfZlilvG2SWQZ+FG4Z1PLfkBRjEGaZYHEdlWJ0F+rhcoXnYK VOh9DYX5JkU2GuQiAMeZdZCj9n1UplnNFWhQB3gBuikAHGxUwZHYRRQpR6AaGFxfSRr/hCkAjGoU pUMFAsoddAoVCihEgpqV6EC3/tdmQbPWytGxeDYbFQZLxnndsAphUKmOFGAp6bU5ZsuQtXIGUCxE q4IW20IVcKtjqQ0Fa1aq+OGlbEIjxklBrBJJq6+bfVXJULr6nsXuQeM6VC9yEIGrr7fGWupQwQEA HDCpFz7q7MUYZ6zxxi+NijDHIIcs8sgkl2zyySinrPLKLLfs8sswxyzzzDTXbPPNOOes88489+zz z0AHLfTQRBdt9NFIJ6300iFLIC0CCQQwgAAAEKCy03FCfRAEEfQ1AUIKZGjAAVsVcNbYIYWNIdoK ce012HF+LZDa6rGd1NRVr4S31RvR/40h3wX5jaHcBrmNF+EOYR2b1gk5zbhCjkd9kN+AD+233R2Z /XhBeJsFuNoNEGQ2AAswMJDalR+EdegC4Y051ox3DvjeBpnNdudaQ1CCQKPHTrXdo5d+uucRaS55 7cRHFPbmopvFOkKGA/A86ATBLrnsA+Eete5zA8A8Qta3TnXeA2GNOEKjA+7AA843tPzxBY3OevoS Ca5e5e+j3z7k+0v9O9kDCZ7puke+AKwue/8rX/9cB0D/FTB8Dixg5wpIvYXQLoIU7J9C8je5syDO fn2pHP0yAkINCoRrjDNe4SKQQu/BL2zC4xzVnsc0jajwIBdsHtvChjmBrI90AzTID/9peMKuyc18 KyQf3ogYAB4CMIcBBEAPm+hCKk7xhzFsyA231jXp6Q+Iw/seRNyWRfGRD4kFcRvfoBhG+IHPLOcL gBoVCIA4EgSLQfQh+6ZoEA42xHBM5J1ZsuhHhhRSIkNMotycKET2lS6RaTRiACBJELfJ7YJorGTX 1ki11AXAdg1EyAXZ+EkphhJuYsQeQQ6ZEEB+sYzIK+DwZIk8McavigjEpRltWcNeDmWOvgymMIdJ zGIa85jITKYyl8nMZiIGlBSCpkz8SMqmVLMl14QIKxNiNiJmEiSFlF9BnAZLZ5ozKJRcpSnNyDfF BbKNFuwk8tjmTv6Z8I7seycMGZD/zuHxEZ4FwaMDmSjNhFBzhvMkWz+HV05N0hKYdLRj4NbpQE4q UZ4DTegk83mQgsbzomc8yzsB2rZNqg6OubQoE+u5QV3KUZIGyeY5Z6oT+yHABBTNoeL6wrzR9QVz P+zLAkhAUQOqZ3M7xUtP1QNLm+L0n82LTeVI6dGTirSiGo1ibBoayYfCNKJmHMxQUYrVso4SozoM pf0MIIKiftSigEvqWZCKl5EWcYqZPCstBSJXs9D1qqX0YkA5StPCGvawiE2sYhfL2MY69rGQjaxk l+m2E4wPL1mcGlvrqtXBENGnIYylZwmCtxFcdq6SA23yAjtafA5ms1AdSFDxAtsn/6I1ircTwGav qlfTDoZ5a0WBWxvn1m1q0aUT5eVxwbjR1bJyiQzhWg9zqNqzpK66qy1rWqPaWoVUF3DY3WtH7yfa 0KY0ozIUrCBjE8iFTlZmEJWtI03HRoFOpHNfs69CqFpUDuoXIf8VZGwDXMrcqhe3tt2rXj0JTQJX 9Y2YMy5DtthH5D7kh98TKNYYPNyY3pad+x2fRMN6SYTeEm0E1qYuWZniEJOVxfPVbkWh2GJRfvi9 MYsvY0d3Ph2LrJvmJGcecUzkIhv5yEhOspKXzGSOyPQmT36Jj5UizShz5cEZyeFBxdvkLgMFb7C8 4Te7t8MOG9LMpMUomIcszQfnj//CejwwF5mby/lZGJJwbi7r1nziU46XeT80MN8Y6d0O54+/ZY6t Ff18ywwTFs6BZnQUfWcA4TLOkiDu3uP43DzlevnTL0E0AMUZZ7OwzW12wxpXX1pUVQ9wwVkNbAzd 9rjRAW+QQ05i8oIqQlM3UIBavTVzRb3cGPpU0EVsNa61Ouuu1XrZRvV1slMNbVQ30NXB/jW0ZT3A Y0vaobpUXBmpW1Rir7fXshwhqNfN7na7+93wjre8503vetv73jn5rgN9y1M3hteuCoywhYkr51Z2 DeARqexpPRc9D96SvQ617GAI0HCysroFXcQsm9VDQ822FbD6w5y1Hfq10i4cueH/9WR5iedxzkIx uMV9rXAx9+8077Z/NXftT9uqaH2b/Lf+5vhDwku4n/d7oos7ntGV6kaY01zo+I7KljmM4hhTxGkC 9zQdVR5nY2/7IDVOduowXT2Uhl3sXT0fGn2Mx7PLuCF4m4CQWT0Bs2X2xtKEMZ1RqfQb087B6wR8 1fduY1qeXfDfVuem8R54q0+ElVgnm7lJrU5k97m55Wyw46POeWbyuKvgtTjanfl5h3K986hPvepX z/rWu56ZU09Jnuci4SRS3KQ1HXi0FY2S2r/+90OfeEpif/kJYkjrgkzljcHOPmm/vcANFNz3yJ7c BKR4n8+notYrLtYgstH4R3Wj/3zPlnhNi1+ddcz0908OdLf7d/MMpe/ypX9+4NtfI+JmgLnHT36J zP6aoKU10PV8VSU4PbZJs8VVs0V415R/tscQeAM12bSAfBSAUTOALYUh7wRrANZ8ztdIeKFyDlhq X5d9BORw95eCKriCLNiCLviCMOgRErB4XPYRJaR7NQFFM1h/FHGDZwFLVgYSO/gSQxiDRjgSxod8 HLFl6Td+l3ZwsZaBQpVrbkNQOUU142Zi5sZA6fU5uqRjs1d9hdaEetVDVZhVnGZG06NLadhcBjZd JpZLj+NHZ3h5R3iHP0F828VqYSZ64+VX8BNUp9Y1fdiEZJRHdYhh8DNyz6dlFv/mNrahhNonfhPU cWp2Y4f4cHKTiQNRh5OYS2UUaZk2foVoN3RIiBvXhHi4io21U6fHirAYi7I4i7RYi7ZYQ753i1yR ixARhDehh7SHgyvBi8hUcQj3EMRYSs/GNu5FRcKDgWVHbaZ4ZzEGjQKmUIRVYavWUoMXSFUWh3Gm T0DUjNjHUlkGjtdofiC4jdZIjoRXYfQEch3kaGBkjdB3ZnNIje+YZgWHZRN1a8sIQO64jZ+ohmiI UeaIjMJYkK71jOh4j9FWcGJokAppefZYUMmYZD6ocQ9nS+F1dzW4e5KWcvxIdaH0kbmWXmJFVKpI RTt3hVyGkg/XfWWXdFH1iqP/iGDcZV5v9UU0GVZCxZKE01coR17nZYf2hHNG2ZN2CH6DJJSx5JFM lZIGsVOhs4VoRZTIh109RJJHuYcReXR01D6k5JSkA5VmxXjUJo+62JZu+ZZwGZdyOZd0WZeoZ1x8 FoE8aFT4s5CKV39tiEOntWp+A4RqaVtjoziPs4ANxZhUqUguiWaRyYC6dQCKiVM82ZB5pJeudZWX CFI4yWpWQzf/5JgOgWneNktoVph5hGWFZJpzhmv+uF4hiHQl2IFABGfRUzrQtGHjhTa0A1rvtIBe lX6peYKYU18euI/EmTqw5ptRyFhE+ZMsQYxcaHDqlYwZ+VE/aDrXV4+HmZOY//eY6EUR1PeX3+mQ 4pWLkYNCURM5kXOUHFhSLdlG9jhGuNeJX8VXZgd/3ZNFkaeMfSeR6RVIAboQ77eP2CcR93mg/Jl+ DkqAFEWc6UdoOnae0VZieXN4y4lShDafGWpUvGeXQTNlJPoQ8XkxKXqiLNqiLqoRIOoS2zlhRVUA wlOEL5qjivWhnzlo+ig8M+pP0YdLA8lP2Vh55aejSrpMZjlWZNijO1mbM0lbDdSkaBmWzyOT6KdU T5WkS/qlYBqmYjqmZFqmZnqmaNozCjdx3Hc+JeQ7hAdJboNx1EmbfYFw++eV6kc1/MZ0tnk2M+el EkZ5DGlPx+g+fik+N+dFLf8Hcm+aWsJ3gmK5ENLFaESXS32KWn/qp3u6qHYmVb04PhIXklZlUeVU e4SWEL11ckp4qWaUqYC4qZqqqB/XP053klA3WAT6exe6nyEaWEyUqnrWT2w3X25XeFYYW/i1p3ul ee84m3/ZQYRHjIRaYfVZYUpYloxXcKnqR9W6aEwZreO0TpN3TzwKmg6xrC11qrP6RlzGmeoIN7sq n+HZUt8ToOXKrTCZOog3nqFKqiwaNod6FaWnnwB7NED2ggU7ehMxd2n6sBAbsRI7sRRbsRZ7sRib sRq7sRzbsR77sSAbsiI7siRbsiZ7siibsiq7sizbsi4LsVoyMWYCFxDTEOr/8SvkUrMbI7M58m46 q6MuAi8SUS/4chAcEC2XMTAPcbQ5YgFK2xAdUCCDUSTiYjH50he7IiY2+7MBgAExSxxPOxBZiyIM 0SpnUbQGcSTgQSjqEiBhmx1c+xAjsicQMSpjchBe27RvaxBfIjGesQEjsrcHMSUvghBMmyFOu7XM EgJIexZUayJfm7T84jBlWi4e0RfU0iu3grkPUSiFOxDHoS0GIR9xixAW0gGVQgH+UrVWKxD9IbQK 8brIghd0O7p4Mba1O7uOWyOushAUcAEbEAKrm7M8Wy5a8riXorVpyysQIbt8uyMNcRyCy7pmgS+c 6xCeSzDzwRBj+7kD4bwP/wG+BuEnmRumLnK3MLK5rcsQ3VG6xPIo7uu+z7u+IsIcAmEjxaseZyIk A+EpmxEq/zuzDPEBB6Meqpu+9KsRBaIsudIw+css7wvBUIu1SoIXeyu/1Ou9GTy5GvzAkfIhojum s/Iuawu1UivBAhG0aLsZlYIlKowuLfwpfYG+BnHCGqwqpTvC4xK0IUwQ9VLC84sW9IshCkG6ZzEv B+EuSPwwGDwRBaIlOFstntHD9Xu7QXzDDUG4eIG8eOsZK1waMXzFHNzF10HFAvHDL5vGbtHAatzG imXE4+HGcjzHdFzHdnzHeJzHerzHfNzHfvzHgBzIgvyiYeiLP4aDhsN1Ff8Ur7E0sCYRpPY0Ykuo e5SXyPJKQ9pJyfeEMxJ2QCRFqV2kyJvchRBBTjSAg6bsUvC6S3vJyVQKEoUcnmY5qdLarl2XktiH lYbnn/yYI5IYhtCpYsfXyslmR++TnvK3nguJzA8qybj5gQaVIcwTzAopiT5ozbSMQcMsqQNHfx62 obycy/WqqlCKlNG8Ob1Tf7xIzR+hiJXaaMfzzp32Qu94n4UVy806XBToparph/x3m3ZqNQc6gcvJ dfs8EWG4ctfKyBOhRglIlbD5leMK0LranVXpz38Yq/Ysrv43GBK1kRZdqBZhgM8MzVuK0ZNZn8rJ kSUZnd8MVy6NrXtpOIv/lKgK7cyCyVnHpXVhSDmD/NNAHdRCPdREXdRPQaG1NYp62llvI54QyVqZ CdVSGqVsidQ8l6RLvXS2rNBWo9WxStWj3FWjGoJtKqtfnZboum+s2nQyJ5mkrF16qm8l9XQ/dQBn 5al2OtVyzc56ZtRG0a8mSGIMzZ/A+ZDQqq6Fl34c+qxurXfqaZIIyobheazQk5/FPNFy863nCtNo DdmADYHlnNiEk4vVlFehzZ2j7VLro3wH69c/vbCi6RMJuxMO69q2fdu4ndu6nRSQzE1uvRDQOhQR CskJ3dsuCacHpjZPmF3APa9IYdwkYcgNu49zPGXiLGdFGpEjld0X2V9E/3qk6vRI4E1miedem32Q BadXyYqNEhnchK1WNl1LPNjbnYPJsUpgzWiwnoRJbDnR80ps2W2vx+PYj5mQMr2OyRx6ARmOcGOY rc2ybsMCoCrRYL13Whl0W+V942yVTM3S/exXXYqoPBXiJPiDRGV5LS2hAveSIzrccdJQxR3fPnmn usap0RUBcPhA4VeTQKdzmHXiuJrhDcHheW1dQ77jFT5V2yqVQq6rjrzbUB7lUj7lVF7leBycU13R Rv7NIQ3aHs6sViOcJc2cy0mQ+h2ZpVnmEK3mpCzmCZdxvLmvvUzREa3ioWR8DYXna/7l4JabaPZf q9zXWB5ag87cVt4S0/85hdhUrxT6NcKaS13OndAWo/cYdhv9R75qfpdOkeGqky5moHLO5ct2dvs3 5/uo5+VJzhIZoScFNe5pVFCzoo5Ig5B96LZ+67ie67q+67x+M8AYEi4uiYozdl3kTToN6QttFCba E9JdEdANFe7NkM0uEtPusXJ9Elu23n3dQdsY7MQc2Xrtz01KnrFtepi97dpoOr1KS2tn2fHH3Q85 1wBETjKA4/OOS91dZvRIkNn+0ui+Xe7lrOKonkRUpOb924yc7+w98OTpewp/Zgam7QHfeAS6oBXL 4aWupfyz4jpSRj5o0B2azdhJ7PX5TRq/7mpHVm7jAhm35RUOkqEJggf/pkoU/tRS7fILgfF+d1tr ddUnbWo+3+FdDoBTKas3hfBYaucvT+5CX271aqVkVeo971Ya3+tWf/VYn/UlU+2J8zTfDhnK/fUy miF5vnxabzRBZeYewYQZdGDARkAxP2nnpz1ytDuBpT7N9zwT5IXq5ckOZDfRs4YHBkE0T/fcI9Ln PODDZfh2//YuiW54H9Yc/YcaalFVdPiOjzpRBafT+FfIPTvjkzu74/fXefYh8+sQ+ej+utNz/2EB JopKv1Bkx4lHOWblXk2+p/qzVPnw6GdtB3+wL+DuajeUrvoC5Wa45Ee2D0wrzUQYavqqt+zQP/3U X/3Wf/0Yg/o2SN22/88Tzz75D/fkIvH9zi7j2I8ySSj2GoH60DTLNt7QUOj+qEXqT7/zGQRcVRSE Egb7MSr/gAgQDh4AWMAgwEGECQ8qAIAgwUGBBA0qDMDQYYABAgAQoHhQAgCQIUMaOIDQ4kOMGkWu BHmx40uYMWXOpFnT5k2cOXXu5NnT50+gQYUOJVrU6FGkSZUuZbo048amUaVOpVrV6lWsWbVu5drV 61ewYcWOJVvW7Fm0adWuZdvW7Vu4ceXOpVvX7l28efXu5dvX71/AgWUybIgy6EmaTxtQVJywAEuQ ixFmNCBCZIOnBRVGlHzwMWSOkzWOUCnSJcLPLDsPhlxYIWGRBlAAIP95kLLlkJ1Tr1ztuXXv3SJD owY5HOZT0ixP+wadWEDly8Qh967YennwkMaZszSOvHTI5R2xD8de3DmA5CvDw1aPsrHC99t5zxyf Ev33loafkm+tHWZ5ACZQCMDuRsPPNem4SzC7lKDLzSTr9NMoNO+UQ6k+wTK0CjGb9tsvoYg0k+nD jjjj7DUEQRxIMxIdo62kECfK6TPqGKotRooeq80+7XCMycecngpQpxaJ25FDFSWKqcgAgPwvMops LOk4lQSsLrwmVzSIyQB0nDImJJFEyEnGJszxReZqRFO0jYokEyckufTSNjOpBMnKl8T0CE09s1RS zjVfEhLPOOt0EQD/NXckEdAdrzRMQ0gjZY06uj7D8yAIIoBKUk479fRTUEMVdVRSSzX1VFRTVXVV Vlt19VVYY5WVU/ZaUzKhWiG7tDpbRSK015BEnNWoPoNatE4uKcp0U1nnZA3LngrQTAJoz2wUrmSN RdbQYbtlKtfppNuVJnAVhBBYRFm7tqOPhlRoWQq59U1RjYSd90sIL3oMyxNjWtZe+yRrd1x46bwV 1xRf2te952ZzaVkrj90024T+ldFgyRamqF+Ylu3NY4UG3tPdijUNjeMACvaN34EyTtjPdTtCUuR3 TeZJ4yR3BDK+zC7uck2aEd4R5JLTTYhmEp1F+KKgIaR34jp31ohS/2+rtqlYMNHVrlyWRMS6pmUb bVfYdl0S0rjPRGx3zWTTnmjZ0z5r1G2ZljXPT2YDKJvhu3kUL1B/NU1xbXsljjfvl+zeNKK85f6S 7sARhzjkOxHa22DE8c7850Ah51zE1GK2Ft/L7dv8JshDx3ehB+GT9+cdaRxzIJCGtrnoXZE2FHK4 L4QSItrZ3jZz2Ki2+njk41I5eeaxstu/VZ9vfnrqq7f+euyzT7Xc0ww/1NzvV9qVe99X4i/cJFeC TnTt23f/ffjrkh3Fpw8PrU8c+/yotvmF/pLDN21GS6OLXwENeEAEJlCBC2RgAx34QAhGUIITpGAF LXhBDGbwgct7Ff/WUnOpr52pdviyW7WW9qishPBmRsMJxc7SogDChDNKQxHLWjcWF6LlIwDT4F84 mLLbWa5y6vrS/ooYqB+yriAoQxgP2eQfZ63NeH4LGAGZeC9yAQtaKmTOuHbCRYyViYVZbBQYpVS3 IOYLhWKkDg3zJDyojXFkcrTJ2ibAuNBAoAar29hAwmOpGq7xUF5MiMTaCDiZvYyNBCRiGJNEqTld UYk+y2EP7fLDyR1tiEJayQJIMERNIhKIAHCB4IQjwq75rETBC9YnxRahJxoMioDL1fr4mEgTMq4z YAwfSwgZJXSBhEWv4xInReJJUK4tXcZsJSg7FgHRladRjJoSM4X/+Ul3eY8iyjSNIP8WLruNKyIm TBPrgDVF18VxluwbEGSm+TpnWZMg2IzY68wZG8tcC0A8lKQl/flPgAZUoAMlaEENelCEJlShC2Vo Qx36UIhGVKITpWhFLXpRjGZUoxvlaEc9+lGQhlSkIyVpSU16UpSmVKUrZWlLXfpSmMZUpjOlaU1t elOc5lSnO+VpT336U6AGVahDJWpRjXpUpCZVqUs9SAc0EEyWWIADo1qJTyATAp2wpHpQ5SoAblpV ppolA5DRQAVk4lTIgOBTYOWJrSyAE61SL65hZWtYwcIBlph1J08ViQY6VdesAkutNJlr8wq7VMDa lSsUWIlefdIB/5tUgLFdpYBjYSLZrgKgsjMBAVczEIDEwhWskxWJZTtyWIpUYKyUNW0A+AqSD8zE Ayu5AGf7qpDVehYoqP3JSjAQ2dAGQLWZ3SxMRBIA0kKGAx1YCWRpYgGRTDW1yQ1mcV9S1deiiwIz GS5rZ3KBkNRWsV4Br0h+2xQMrMS6L8GseSmSXpGstyPtDcl5EwLfkPg1Jrk9bk8K+wGWfPa6we1A cvUrE7yKxLkHCYFIBPwS/obkrTCBbn0Twl/7vqTCIPGAVYPrkw04mCblBclgE1Lg284kwSFZcEJY YmKYZPfAL2lwSLarEPyCRL7T9e1p1dvahFRgJR2mCIrzS5MVg/+kxQohsXjHyxXeDrirFAnxkW+S XRhXGSQzpgmWE6JlAMBYJtn1qn9DS+KQxFYhvAVzhmmS4w0oZMMAWPJBSOvX2ep4viKZcELyLOHl MiWzwJJJcqXbkRrrmcruvQmcKdJjmghZwS/5c5gXbWWbeHnNIsEqYfv7ZUbbxNEd0XKcn8yVSgOg 0zMZ9KM/fZO6fjgmsX61p0Pi4VoHmSU3PghvB01ohXQ2zZveMkIq3WJhwxYmGKBury5waDPneigA lnBH+GtqV/+6NdkGCU74K2bmTprbZRbtrYnd7ZokVtu2egl+3XxqrKRazbg294VDXZMcOzkAGMZJ vhOC5ndfVtb/tq43TMDMYdCGlr9AfqxIxCvpEisku3qdc53xvYEIR7etAwfKnOedZF5bu7RE4ThF kkzuZAOAyCK3cKMdPm6bJHbhRnE3vL0yZwA8eCe+Fgm2Z3LwcftcJkBXSHLnHZMco3vj0tYwsMct ZgRbwAMbCDhCcpuBcINE6AdJeY5XThFDx5zpBFd6UpL8Wf4eXcoRtwkHpE51Hxf8JskNAd1lspKt Gzy0Je+1tFcC9Zi4fepVt7lZyGxjDXAgwxUIAQhw/veYNNsCH3BsBT7weApY3M5RpTxCLI95zQfg 8RpYNQZA0Gy55yTKy2Y3TJpNARBkGAMfQHNIGI6Qk2td7yxZ//VLDq5ZEIRgwR0wPXX1rfp1t34m j9fs3Hcd+/vSHjJA5jupIdPnmUi+8wf5/K41X/0Pvx76CJl97UFy++oX3iocSHWvPABtnLgdWBmA P5KZ7+D6/xz1bE946svtf5pov5rggIzbtby7O5FQO4qgNkVru/vjMwXcueTbtppINJDIvwEsQPU6 QBcbu3RLwJ2Qv16hP7ITOwBUCALULg48N3JTPxdUKpB7QRmcwVDRQCWjQRzMwUgBgdWiAA8gPB0M QiEcQiIsQiM8QiRMQiVcQiZsQid8QiiMQimcQiqsQiu8QizMQi3cQi7sQi/8QjAMQzEcQzIsQzM8 QzRMQzVcQ/+k4qZeuYhK6hY3tJXl4JqQGJ9gciKs4CWbsJilsMNg8RlAJJl7ApZfQRc9VIs4LIpF rIlBFKaLeUQ8NERHpENvYhxywkQUkidFsiicESOO2A3o0ZyDmQljSkT2ABhqohOSWJvTYBxIXKVj UiWa+MR0IqePMA6s6ZlnGhLYYKdUpKTnOABXNAHwYY1A7CVREiDzuZpOtI9hesY90UVpBKZq4cUR +Q49hMVSZJNkFKNvjCUUCUdZ4pzfMcXhCcXoqEQTwkZHOQ9cPB1NIqckUUdoiQh7fBQ3GqVRVCA3 TMRoeUZ3XBnfsaEpOqOYaBpMuZ1VhEaf2UfEsEXgoaOYkEj/ccmJR0QnPyykqRkZgmHIelElLlJI fhQiQmQXZ2IddjqXc7pIOAkmakQXdKqOlfwZg1TJW/KfbNwUklSZgYSdnBTHn9xHYEJEQQQWtEnJ nRASYYGNX0nK9WicFHmTGJIoiyzHdqqN+PCJUzSIAGKIaFynapKXqqyioLhK+1hJonlHnsikQPrK P7EnFYJLtVFKZhQfmgxKNaqJp1BLTdmlagykoehKs7wJwgTHWPQbutwSeFpGjlQnRsoaLGmXmAGj vtTLtcTIwgCQTmIAzpxFoFSWNLootGxIzpmbxEwcTXmlgymdszmUuhwhrGynW+kd6UDNbpQJtGRJ W9mawEQj/wbBG+NwTZUYjrZxTMpBkNc0yV8qp4mUzWfxJpgYRN/Mw4ngQ9UMlLGREceRDhEJmyOq zdUMTxFpEeLsG9MUlHSMzOmUxs84Deykziyylea0SekkjvDgRHpkQ0lJIv78zxn0TwAdUAItUAM9 UARNUAVdUAZtUAelqXiyp08hyqugFgmRR7fQpkY0Cm3CCQu9iUyxF/ZAgByQUJ74UOlYjY+YyQeN FQollRelikLB0LnYUKcwUWfcT98AGJIkCjHpHyECyBYtlR/qTiqyxeUZyPdoSCQNoiZllszEopI8 lJUcyIh4GkIcp/tkS9O5FC1dSDqK0VHSp/xwkafpjacwm//1pKJBSZKH+UvarEmhrJMnpcb9lKSg kZh1qdMTwh2UlNMhBZVkMaLZHKX5mEghTU/FuSGEWNRz5MRuGlTkhEs4bMyanFGxNJ03vE9M0pTc caY5hE4NXVMzLQlJBVQ25RZHlSMucstQwpMOrRnVEEzREJ2tDFRUiVLKHMtN0RNCHSV7IZovbdTx ZJ3w+FVfXZONdEldhU71LMUr5dVMlcwLndZl7SLg1A5X1ZvKIRMjHVXIzMopaVbkTCf7MVYU+lUu laEBSk5YJdW91KQy+k0hQlVcvVe92M2ueAwh3dfcxFeAtYtQtdetCFFa7IoVDViFXViGbViHfViI jViJnVj/ilUKFBUKMa3Icg0SHLVYWoIqAQlVyHAJSZyJUP1IliBYICrPjlWLiw0LG/VQiqxYSMHO WtxYjVVZs1DXdUUdabTZx1QTl2iXadXNf60LoJWKmM2JHTpYiZUenUzL1YnS0LTPohkOqo1QZxpW Ls1aZR1NI+1F7fhWS+XVdZGYLPUjlIjSsE3Ij9WaJzEhQOxH0YwNfKHKlpGJK0qahFkePi1UKfVa OZ1Re4lWjV2OJA3JnJFWj0SR74RTcd0mnG3YbSVIKvLGTSXWWcWczDVNDoFU8EiAU9XL0QXcqi0m eMWi0jXZj9XRv5Fben0jG9KMPrnVuh2XIllV6tDdx8xU/9AtU2pFVFpUId4VXlx6CBjK21F6V3TJ z46kWTA9SYTkkmvlHCtJVtvpRkC6XCP5nxSp3u0l15oU3ynh2jFlXHM1XWchX5rg2aS1Wtnd0sg5 GMKY16/tG3btRhLB3inh34lE3GIF1oe0S1p1yMUNXnnl1cIdiPqpGQNIgW4EX6Xk2YoV0JDS12Y5 2oTiV6eNWAu+qIHVS28x2IZKWOg9YRROYRVeYRZuYRd+YRhW2pb9iqWNig+GC62lW07JWCLB0RqO YeT54VwdTfmZ3Ak14p/AVCA+IE4aDsJYjc8YDl0yyc64TLdlISvGyiY+FygG3iz+HBkhDB02VGZ5 YtgMY//89RwxxlwnPkdkBExRrZN2qWKNIFPlrGP0LdWRoWPtfFQ8PuNziUk4Rk5XTQ2oRF5DmdG+ MeMlvp70vMtAqRXXleQ1ilUsKsvfrcbKdZRMdohORuTMEVPbPd1Ebg9mTNSy5c1OpOR00iLRfd7I tZP7aZM6YQg+buPuSeVGrp5VJBPDvaJN9pPd9VQt1mWIdA2ETBKApFqVSebZURJnNt5Hfl0UMlzF VF4/rdo+td0zAmZi9mZ3iWY/0QyJtOasaQCGOJmBgIGBKJAyTpFp3uUg1mX5qFRWxctK9JX05V4p febg7CO7BRtPhcVq4Ub2MejViednhZIcHsc7fAluHEX/UeTWdakVQrJoiGYl9uGkxeDhKD7g3g0l iTDNj5aOpKRReU5plV5plm5pl35pmI5pmZ5pmuaoixXiOnpbdJnEkfUm0B3jtrhhssDpm3hZWQYM HtabXEZpGWbqmlbipXDf2K0OPQwaz/kbnSULocahGQaK9+0LHoZqriBqAzUm1xUKRfZStQXTQ6pJ qYZbhwZN2qxPnADPQ7mO+23rcQ1g5sDr7EUchBRcsxXhZ+4MWDRs5W3TZ1ZTaGVgwp7Rs60TtoXO yc5rRvpitmakInVWBO5SN11byNXjJVFcNpEMxf5fvkFTjWDstEWQys5evQ5Cs5ZfH4XnVP5kt72W r65b/8mgWoAW0k49SZHB7eD+VHfZ5IXBbRsFSwaICAGxZftg3kyl1C0V61gqXew+EAvh509e3egU Rz3G7YzWYPUFHJFt4MjN7ualbTK07sDVFIDZXpiQ6rNOjeVgnGtRJoAJxmyVVeO2Egk+7tHcVpoJ J/rZa+3dpK7WpBeIAZJRnZCOZSt17Jlwbypi31HqjV0F0/hW8MwJcAAP7ZEBVAtfX/ge4JOs22CF 3F5u19vM4+7N7FDK3g5P8ZpOQgyGX9Kc6hs3whBOzpQlbIP68R4vciM/ciRPciVfciZv8rSw8KEQ 2e0OFezcHwju1xSyzgiXUR538gqqjw+ZaFkkx5q4Sv/KIMbQ9ed/LsfdoJTD1NznHomg5G+ObEXw MMZm1NsBIskzd0XD4MZtZCWn7tnHZOx4sXPgJcVAl2tzXHNeSU1WRHMv1sYO9nK7wJCoINwBdgmL 7Cdq7oifJMnpJe0Yz0vgVMXn7UmQzE0wkm/7WI6hVKR+EXWcDaGSlpgOv0ltjteZUUqfJHWctPRI YRwsr+2l9l1Y9gkzfx1urJxRD+VlPMxNPonF5Gd03Um45u5kz1+8FGdrlE7bTFXEGeVTrnS2rPYc enNhbx6lIWlnvWqjhRZAYSFYRG/RtuuRedzgxKNQYm3jtKcYdXWA1kqAf/fE7J96f2wtn9PNCVvP 4R3/TYkb85509HwdfOdW8l53pNpqje94v+B4jw95kR95ki95kz95lE/5/4TyolgbbRUcFgWL3f52 gHZjrZh5n8B5lRcoMDeQKV+QdZSJOfZZ9FFGUGrI24iOMOeOn/T0eH0j9E76GwKQQ9IV+egbAqlz 3DhH8rl6ZqH6na8eTG+KGY3tfmJuzTwlYX4j2g1MpN/2yxUTdaXg+NXYbBqe3jh7aP7NMJH1ASJ3 qPdel9D7Yg/7DCpxNCnLK+7HGFF8QidU223ofe5ZE8HmCv9ZPw7XZ+5X/VmTvp9dxoR2OkpmAHJx w38oZVqM9Nwncy/EY/R6SG90OU+fY3IlGJ/N1E9O/4IdROqwZKAnc2kinaDPevDG3NpPpuFvjcI/ fTSEbuZ/fuiPfumffuqvfuu/fuyH/ke08Rg2aq5c8LC46ZYla5c9a74E/6Mx/5TSeRVmf9N9ctse 9Axxf6/u8oJy1JifT6RkTsd9GxEHiAABCgAwcEDgAAEFDwoUCCECAAINBRJEkAChwgUMJjp4sBAj AAATOHq06BBig4kUP6qcmBBASpcKTQZ4CFMlQZYvDaq0GXMiQZ41UbYMyrDixYY2JbZs2vKlSJIA aL7UKFWo0wA7GSolilOnwp8gaSKduLRh1Y0NO4INOXJtyaRZAyiYKjftVa5Oob4VyJZqWJUvaUpw q/+yrtWhN79izVqXplaFUeHaBcm0bNeIcyMDSAwyJl7KQvlKJVs5M1OBj+8qbMxZLGfAmjlP9hu3 4erNunfz7u37N/Dgwof3rnua+MTcvNnGtNkXasjo0iu/TH2YusLUbD0nxz4b6Efo06VDdlp4fEie 1ZsWHp1dsGT00S2Klw/Z5nTYvtczPrhd7XXlPfWeTPKRJ9d56DWGn3Q//ddUbvyB5xqEpz3YknJ7 ETihXgmOhxVzJ9VWH3oCYnichA0ZZZlZEOW32YVOxdidSSmutKCLDQbI2ncqeTide7PZOBBLdB2H HJJJKrkkk0066diRuz1kQAqdASgid0RONmRmHkT/GZptbVl3I0M2ZZlTXy3NqKVQPvmYHkNDmnml lm/N+dVkGQrUnl69DbkiZ9yxRSF8PWJJJ5oBrJmTUHoGwCdIgnoU5JhEErojWhldOWifAxpqqX8e nQlnTxFQaWWpqIJXG5SQ/SmmalFCmtWdmYGmaV4s9hergLMa6eqGYY4KK2eVAvqrXE8quyyzzTr7 LLQafhotteCZWC222Wq7LbfdevstuOGKOy655Y7rYaXmCvdjdJeq+y688co7L7312nsvvvnquy+/ /fr7L8ABCzwwwQUbfDDCCSu8MMMNO/wwxBFLPDHFFVt8McYZa7wxxx17/DHIId9rnHzuiihdmt0Z /4gybiubLPK+/MkcrFNnwdzUsdhCYMNGA9zQaVFFxkwzkzNPezPS3TqqYkg/4ZeukYvxmuxmS68k ddLMWv2k0VC3eDTMOTu1tXCIMYDZXGJ73HXWbXu7dU4x5eQ1lCuHZB3cTc913k9bTXSebN+9GmRl EJRwtWxY5eSZcXSfLLVxYgGeFFSpQWWS4VPP5dyqPZbFdrG6MZha5KsyfrfoOdqZo1CTN+Q6baTL WuTiADau8k8kv4zs3yEF7rhupcdKKqipvgWd7FjPTZnUDK7eLkOwS5hT4lwtH6bUoIvNudvdM0ly iVSfB/yJ1469svknHqjSmrFaNXicNLdfoN3pK/+W8tTzmx16+VR7ylRdCMCfuvSNQKDbHETwhywS jcd+NstMys4zEv2pinshAkn9EvAS/RSvahYSFZ3cF8LdbBBnRSqhCDP1KbUxjyUPFFEEDRO6+cHI I8Q7IAqNlCXv8XA4ZGsJfjiopdPZD1PCueDX3iJBIEKEKTlsGaWCRqHc1IVCNDxUoZiyxFQ5kWi8 Cx5MAhgmGHjEOqDjUqr0Y7MqduqKihkT914nwy1+bUyIIYHQjGRFEBJJQJwCI2ToiJrhoC1MrqnI ChKYRSmGSlWiKVMTjfemLRFIbatZ0x/5ZyNEKrKHnkTOD9M2HgVGzW6qCiVvwMcqqURnh1dD3az/ 0KgoG6KuKWyBHm+WcktHso+WvORfSxLkylVZJ5Mq7KKQvGi8XZpvl3mkVSSTOMmUOXOYihEi9ojn Kb2xMJitBFA1Rygc6KREbWA6JiM7553mRBOC09RVC6eVE99dBIUHVKE1P6nPfe7rhfz8Z7d8lTSB ArSgBj0oQhOq0IUytKEOfShEIyrRJt0zoEUEDqDMVsiJcrSjHv3otyq6LVT+BlASUI8AyAfSlbK0 pS59YmwoZ8CZ8jKT57RnYAoEmQy5aVdvxNPuXCrUoRIVpOzCpSbfQ0GLuFGOJeOKchg4Hfp4kaBF vSpWs8rQRd2QpsiUlAshwh03cbVIPBUromTY/1OnBlWrbn0rXOMq17nSta52vSte86rXvfK1r379 K2ADK9jBErawhj0sYhOr2MUytrGO/aQ/5yVLZ6nyqdcxJf6Oqk0PmnKVzZLARYXzkHw2ZbLAMS2T nBkS0pY2PqQspYFYC89ooRZehcHmY0EWWZiRDUwkjRo2/+I/I37rt74hiGz/NzRVNbU/wq1Q+uL2 rtrGqzDJzW22bNIY6iULUDAdTFL8iZmnXadNXuHQXOC3kvI80Giseu41gQo09ZmSO5WdjnUSlaT7 jsdyremT3woEG/C2DFhYi2kNDxyoK+FUhmGSzYBnItNk5rGQu61blEiY0z3VkkbDZZpnF0mbNP/B Nys3zSlpKAPhQlUvjfIVkX7UZlXsfsufceQwqzQrtAgF68ZMo6op06fezLwIncBkGkqnNeP+pYpQ JF2rjFQwXw/zZkho1DFWHIXlKcOwl79Urk9xrKD4URhqDIoObkGcpvMYYAa4yso8DdQYshlTWsg0 1jOlQtohi/lDZB4TlyAl1fUJmMbksnEnnTpBPq7KNTbxkoDwkzI2YnFVr53lkbTLEC0Ta8hQftRm W/VhTVOZN3FOE35291sry4/RIM7yB3/JKC5jOku1gvFsyVTrtHaaaJx+2a2Hp7eaoTUr50nM0sip 4TKnE4G87Kl6yxpFF/curLJ2sBzbamiEUbf/YhudK3LFue13fbs34R53xNDFMc1qW6ujFTe6tcVu Wu9NwfG+N77zre9987vf/v43wAMu8IETvOAGPzjCE67whTO84Q5/OMQjLvGJU7ziFr84xjOu8Y1z vOMe/zjIQy7ykZO85CY/OcpTrvKVs7zlLn85zGMu85nTvOY2vznOc67znfO85z7/OdCDLvShE73o Rj860pOu9KUzvelOfzrUoy71qVO96la/OtazrvWtc73rXv862MMu9rGTvexmPzva0672tbPdXh0A gQU6C4AMcIBj00HOeDwgnPEcVO5+B8DC7/71DfwdPRfImOCHgx4KBIfvBi18ZwMvHa9nQD4Z/9gA BiowEQx8wEvoycDFEr93+WDgN44vKORNKfnocB0E47FA6XlTAQqMJ/YTE33jDQQC35weoL3/OO6t HnfpWEA4GBiP5m8/eeLYrfi8+T0/od/x4FN9+NHZAHE6MB3G96YCG7iA9SlwgQ0kXzjeB390xE/+ 4XSg89a/AAg6MBHq8377td+N9LNy/vDDPwT0CgEIXADxjV/5KUn+zcv+pV//IccHVB4AUIAH1B21 JGBIqF8BDkcIaIADAoAFeMAHDAcFPuAC1h/rYZ0GTMfuMSAHagAHyN9mdIAAyt0FuKBuwKDfzSBv cADt2Q3oBQD99QbfeZ50YN9mHOBECKEpZf8ADU7EDobEBTbFB0zHB25GBUgH903EBprS4SWJEQZH FEaH8/WG9QHAFDYFEvLgEjbF5M2egVzAF4ZED+6G60WH3jWFDcpgGraE4J2gKVnAEzrFGa6MEu5G E15h1VUh8VULG0IeBfxhQyxi4TXiXHBA4cVgCSqe4IXAeMShU3RhE/6dJE6EJkYHJzrFJ4aEboyh /zUEHxYeETLfDw5HKwKABvTGLNZiU5yi3IWiGtLhynCfJQJAClKhFTYFJIKiI/qgdLyh3OFiVuhi Z/GiU1jiFlrdLJIhtZwhBUggFJ6iM6qENnJjS3yAN07jdNRhS1RAFi4fJrJjAOhiMh4g4Un/RwYk YwCc4TcGwCyWYVPMIQrOhT/S4kQEpDSqRDBiIyy645KMoThmBSWCYVPMIynaIz524ng0ZABgAA1O h+09o3Ss4hFuH0Y2BDlORz42xOKNZAAcI0K2hETCIUWa5FxQI9aNIQDk4bJcoz0+okyqhE7uBiJG x0nOYimaYhfqxu8dZEuqRP69JDrqxkvm4yfiZABoHxhKB1UGJQcypUI2xUNWIN6lnnxkhVVGx06W ZUjkoVP2RlT2IlbqxiiC5VzcYkv8pG5opUDq4XSo5EQQZURKx1NuRls6RSuepNQd5ZLE5QP+xieC ZAAopiES4kduXiLyximGZVcyY0hU4/xR/59WDiNvBGRHamVRCkQrFl8TBmZDjOEFfmJpLotYjqVD FuNcMGQ6SgdoyqF0dKRATMcrbsYsqmZDfOVWqgRkMuZkcmV05KZT4OVtLudviKZTSORvUh1i9mbh tUQw8qVTECdnbudveOdEBKNjboZmYuYlTkQHnCIFpKH0IWHubaZKBCQ/CoRW1t1L8mYABCRzEic9 gkB5NklsogdwSgdn+qR0GCZ8AoeB6qVZiuEyWmR05CF4+oZ4KqcTPl9XLqjpRceBNgR1Yt1B6qeE +p2DoiKDumMsZoXoreiJAl5CpqdKrCMAiKP0DSiBqsQYpuEGhmETliJpNqfcZcAHUGV8yv9ok2Rh dQoEM4YhhuIoinYmks4FWgLAE2ZhfWLnlCJlV7ooSnYplHalQMRlgErdSwLAko4emG5pEaqomHJp enqplEapmrJpAJwpAKDjjYYpkgZpQygmSDKjOO5ogd4gklxnO4ZEeeIlVfIpksopSdImiDaoW9Ip EK6ppc5F8DlqpgrE8YUEiR4mpLYppsJoh8bpm5IqnY6qMtop/q0oXi5mq04pq/IGM5ah9ZVi+DUE ffpG+wXiJsZopzKJYpqqQHwiX9YqnA7rXCChMzpniRrrpT5qqr6otT7JpwJAqEadfzppomZqhfYG M36ndHAnFFKqQCChuVJmtb5quwqETQL/QLFKq0CEK5NkoUAQZ3kS5wei5YcGBwcEonBq6LsiSUDG obPOZLkKaMG2BLLC68KaY3Ssq0qM67W6K7hGrJO4KtRpZkGmaFcW66kqqiiy6nQ4ZrbK6m7YJHoy 63yqXkscp5Og5e7lalNsIOPhq1N0QAh8X2TORcrS67RybJIE4wc26WbI7JIoq8jSZVaILAmS7JMO Lb0qLcMKbdUF7dwZ6Vyoo/TZJTECZl1Ox07a5zm2BEFyrUDQaMtibVNoLf1d47Y6rNg6BTPmZ1Mo pr2CY2XeZd+CLNEmyScG7W7IbW98omoq637So6RmBdh27dle7LIKreFaZt2i3TVu5rpW/0DmkiIg bl+WkuQp/us9gm5WlCS6viw9OqJSuizGum5LxCubZm6aNgQGrONrNgSwkm4AtO7ANkQ5ziVHfqvb NkmsRkeZNgXtAi3uVmrxbobsWuluaGPoMunoRivVEuZ41K6nNi/bBSSOWkDy8qRYzu3xyp35QqOB nGnbAgewFi9L/h3Fokcyau3P3qxYtqew8qmtogdzdq36dpZKKm5V+m/3xea2QuoPxq/fcScBN90G RK/dUAD3NieNtqHaPuIFywcOAqUEe+6sPu/kinDe5iiVtq6BUMD4toR//m66nmxvoLB8+OGhcirs 6u505O4Jg+IKP7Bm6rAF36DaKnC73v/hLq6wlt6w1vXsBRxkE28AEndfADahBRAgcVTAFIOhFQ9H wL5f/BlMBXReFlYxFCPg943x+M3txISxB6BxGVNLsWZw12ZxSJBx2WYLG7txFLcdH/fQw/YxIENc MP5vIBcywIWAC3JuTxoyIwsc+A5hI0dywB2vC0uyJV8yJmeyJm8yJ3eyJ38yKIeyKI8yKZeyKZ8y KqeyKq8yK7eyK78yLMeyLM8yLdeyLd8yLueyLu8yL/eyL/8yMAezMA8zMRezMR8zMiezMi8zMzez Mz8zNEezNE8zNVezNV8zNmezNq+yjjVQPSmTPnXzVImPnHUKfxHauYTWb4CPOgfHOc//x3BtGX3Z TV+8Mz35S7cVDTi7c2e5hj1jW58BCb2BWPhAU4aliomcWag1Vrkd2UI19CvhyD0X2HDN06Vli3Hx hiAti9VYdOdI9JEYV0dHx0VHVN5gm3HNE0hfFBKZGjyL0kS3zGmQV241dD5/EkQLjy3dhua01pdx S0bvxkYry9aEhk6rCU9/0W4U9ZutVG819W8dtZcV0ZQMNEYYhE0LAFYfyfg0G1EZRztj1EFzxgjE x0urk47oRpxJB56hhxkRjXdptQiktZaMEp6MR5qZkPnwDXAw9U+LyAmY9WrxWn/JhAHMNZqtNdgQ NH4x9kKrjDcv9VjjBV+v81hD14ed/5MJuXXQoAdsKHaHvVJjG5los3WBlHVkb4bRoPY4S3Z0DVtP b0ZlIwly6UB8XApByM1B5/Z6JUuybZhLKXReC0dWYxt8fVoHOYWFtdM52RRct4VrnNhiIHc3KfdY 65dvWI1xmAxNQxGZgVWQTNFl49OmTApXDHWhRNh4x7bKCAV2F0dn4c1BbzetLfd3UDdL2Hdq6LeR Nbd5YxCJJbWdAXhpfBhk24192U1+AfQR+RJeF0hfbNRLRPhxtE9Lt5RwK0txx9hHXHjLWFOC4NbS PMiQwZRS77S96RC8fYX5vHcq1deK79b+jDgfmfiJn4+JXAh6v7iqwbia9fV6H7h8sP9WiGeFh6dQ kRsbmqUXgdA4qph4desKlOfZZRnItZCUi4vWeYFYTFjXlRSSl1uLXFi4Rww3R4G1gdP2ZD93kmXQ Zii01CzVN68QsVBGPg3aWe9GQyM3+0hZqWl5iCGFnDs0e6O4KynHjk/SmAFSmn9NmjmAn1M0fIe1 QRcZbaCPXMC5GuXIkqPToPPZgBN6lBc6qTFZ6qT4WkR62dgFaI+HRrT6dFjFb6P6YRU3nvFEc+2H ZLyFk78PcOsaoS8Nn+S6nl+2dNVNPQe5s1XKg/R6z3gRKjk7jl30sXdHj7dztVdIbYi0sp/Wru/a OH27iYn7AGUYibM5rYnUqN/48GT/yW9lu/q8VomRN6xLx6t3llV0dZgx9JrTuXldW4hJeu8ECXgz xLyXupwUm61U2o+b23if2tfsWLcTG0BT2oLlCqGzu6cUvKLNhbTRW0ZDPJHN2cQHtalnGyQBPK/P TqOw/J9FSnnXOZKlu1d5tahRPMljO8uMPK0FEfPYD0T/GNXQ98mo1GDZus23OpHbB9W0+pioVmfg 0bR1tkDfdayveNBcVL3jj8l/DQtwttWbNmlXG2zDmXyMSaJjUKzjUcD/ucMbCNfLHbJNvJIXNFp/ E9m3tlOl9pE5fYHcOs0z277juIHfUu7QfV2jR0nLtF1vRtD3NhPx/TY3xYVNvuXb/0vlX77mx0vm b77nfz7oh77ojz7pl77pnz7qp77qrz7rt77rvz7sg35cL/bErDu33HS8nNE+O4tILQtBpIxKuxnt J0m1JwSlx36z4f7C2D60ZIjyT1fNZzxtRX92T3xHSHRiPD/hr4pYsMXiI791t1vtUzlGo8ju94v2 c835M3qVaXWfpP1+HQm8ez/4n/pgz/5b27s4hdPf27x4AMQCBgEIFgwwQAAAhQAEGjTo4MFChgMd EoQQYaHAAgAMHKj4MYACiQ0NIgRAIMDGhQ1AGlQpEaVJlC9PgoQ4kmLLghcBTEi5sGNBkQqDVrwJ 06FMgkoPJkTZtCZNlh95KmQpgf+jR50FmTJdmjBjzp8Sa+q8+ZQgTaIHugroiFUhggRfcbokWxYu Wq4JfW71+xdwYMGDCRc2fBhxYsWLGTd2/Bjy4qFTQwLVyhQuZZNF08adC7Wo14Ibi2bem7Wgabqc x5KsXJbgZKGWt8KVSxe2SYVoZW8VeRs37N6dJ86G3bJqT4sY1xK0/Xks2qOandJ92nYhb6sGhw9F /Rf7U9WgtcYGAHzrRvSpFfaFeh3sbQglAozfXL7y+rwf1UOP/B/AAAUckMACDTwQQQH7c+im0Kqr jDX+vuPuvLlE66wokSKsSEP8JFyPoJumWvChiDY0CC73dsIIvuLsOpFC9ExyrTP/4EgsEQDKQOJJ xwB4dChF59rj8LvwrKOLxp+KujFEEz1syUgInyQSxI8uFFK5I6FKskO/fvOPJxVXzDLBMs08E800 1VyTzcFM6hHDyx58bSEQb0qyoitJK887zz7qs8KkwLpLIrnelBDGAO4Ua7aG9JwQpC9P0ytOqAgt 1L+KeKI0TCCHtCmi5t7TMsoXPTq0oj0BKxXQKvPLlCqMxMTSvVIpxPTPQPc6EdU2ff0V2GCFXROu S+sqs1cUi5yzpEGLW3SrR3l1Fk9LFXI0ITjzzPYjrBKFlkhsj6tUJ0m1NBUqbQPb1KFOlc3yKIl8 6nLUem2tNFn2EhW0rCutdfFV/7/c9ZTMe7c9NuCCIJo2x2EdfhjiiCWeGDAmFXXySBE1lZXcGC3k 1qEuNW6X45ENcpdeHBuyuMEp2SNzzBYpVdLl2WRkltyUFY6o2phJhrm+IcHdedl+HzRY1Z/sxBi8 o6szeUz3zNUpX1onPbfJhn+WWte/BqYY7LDFHptsAFUi6SUHy+KJM7hcO5sintCDG8vv2C7P7bgx avvanFTijG7i0KZNp+dwQ0vamjtOfDRRW2N043G/DjpLlSiLV22ZScWZ5sa1HgtSqp1ee2+8+258 38arDHLzcX0s/eW3IbX8Q1jLvh333HW/XbeGk74Q0Fmzzg4kmlDy1sPgIyVL+P+LJYKxd5aS3ipe gLHuuKViBWIcR8IFZnFrglWk6TZUo0Q69OSk7zra0SlVviLtIcdxZtbt5dy4hYSXfyw4J98dgAEU 4AAJWEADHtAwU2vU/H5lkub96iYPROAEKVhBC14Qgxl0TFXcY7iILUxxa4qgBklYQhOeEIUpBCD8 wLYRCaYJIa5S4QxpWEMb3hCHOdThDnnYQx/+EIhBFOIQiVhEIx4RiUlU4hKZ2EQnPhGKUZTiFKlY RSteEYtZ1OIWudhFL34RjGEU4xjJWEYznhGNaVTjGtmYoOkR5o2K8VeBkHcrY+mPcnes02cAdakX Dm87LenTzCqWpTk+8ZByFID/DNvYyCAqcDFxFIwkEZNIAdUxf3r0SbH0qKs+EuqFySELa3pHFkYa 5QGcseTEINlA/DVmhI6U5RBbmRhKFjJ1YcOkeU6pE4t57DAzEstNgGOS9RjTdtvKZdlq2aZVJiaW s5SmYTrlnQgh5C17JFpYrEQtBlYvSUqRil3IohdwMjA5Ggkdcpgzkd9x7p3Z9IyRxhmrlQRtmbtM GBzZF7J+CmZozhvchthFvYhQSjSlrJZCGcW9bZ7OL2oZV5961k2EEYmbzYrKOvfpvIwe7I/TFOnP Avka6vhpPoLLyVDQYp+EsCZwr0HcoLTzuY7GlKW3oow1Q2jS/GUuVUULVEqx/7Mb4+ioO94rHKQ+ eRdC1iiZdLrUU4NKKL2IBE9VCyqIMFPS+7zspKqE54RwalQvsc+DuqEqlsKKn7SCZaZlgeQuy+o6 pUV1pHkdUzhBJkyH/HJkOqsdKrXmV3TxEjqAjciI+tmy9DSWadwz7NW2xKiksYxptWFqJ+0KVUHq ca2nIRRwApq1itZLo08RLJFSxz3F2nR56LGfzz6butkux2hlgVpB70pY/3FMr8G1p/AkdaFSXgo4 rcrUcUf7MddNz1zMvYuhQPZXjp5GW+98btFmhr6gaPWWnmJNMyP6T5vh9bHblav16KKuqB2sptrE qHxTG9TvOgu56DVXac1zWv/lMohn88PqQLziLpNJ15TLra5we8jJO55WQP8LmHEXvCpvpqtp2+VM dCtsUW3p82Af5q595eQ6756qw/jsqYqBWZhfntcw/IWWJHm7I+DW92Af1WhGGadVwew3wLmCsGhP x9/KiEsvdbyRj6GUYgbnlSd8ze3MVrsoqOG2L1UOskOnpuXiYPa6qsuUYzHsT6DyS3PWXRJkw6ys 8Zr3Ly9G7GFUMjPaQeWYCell1ZRy5dcpx8/uqhq9vAzhqd32z1QNNHARXVDgMYQEoSs0oyT85JEm 5ylHiSsh/1aewN0tdn5zXOAc+sZOe052LkpbTwO3alRTpFhnxnGpS+pqv+j/s6l3qZacO8pPY+kI wb30LI5BjSWSFJtyqSZJrD09aoj6ElJvNSs7J5S3lxUTrpR9KKedzd7eWprBm4qXlBUdKsf5U16g ep6HHJpH11QPeoNa3zKtNW8PGY/FqKVsu/+8HV67GT+5Jsuu4dzrwlSPkYME6EHRjG485irdEiIe iOG94pcB7Jw/Zp66daxv3LrXo+c+2Y3BHdwal7wwrRxwEx2I8o9E0+VQBl/MC8PBa6OXiCCkedZC unM1ntzngWFhFF1I8xjiPOhJV/rSmd50pz8d6lGX+tSpXnWrXx3rWdf61rneda9/HexhF/vYyV52 s58d7WlX+9rZ3na3v/3q/8/0ldzNBHTdaTe0JAxvJZklgZt1Fu6BPxPdf2j33O19hohvzNQIL3jH A6jxPTQ87hSfwspLpmuRf/zmG2OSEeC3n01dj0Sn3RLSHwc7n59upk4vptODfEwtaGfHX1/VuwA7 IapPMGCqRxQRjJg4TrX9xq/XueCX07pWHb5EetR7jvw+UW9E9p99Ik7hex70wub89g2jGxUR8zP5 QuawcbtWJvG2qN+PCLath6ofqTmEVXmf3TACp6S9/7Dex5GwT37qep1/5ipLo6bCtdiHtwAQNvAP dbSi/0QORy7H3CCwsOaE8cBC/QqO+zKQMKpG8eilWGAvfu6pyXLL/r6DvP+cR11WjtoIacD8rL8Y wAWPjMA6DPFckF66qqRyZc/GqjREECQ+sCVisAUXK1f25SJ6cAFkIAJ6kP204+9KkN40UApH0M6i zVhYQ5RykNrIAvemjMQEioGCw1hOScL6A8Ew5Qy1id/gq1uAD7e4kGggrN2yELb6jfmIbAwTwF9A LFxgMCLmpWFa7lwqUMMsbgoPseHgjzjgZLV2rOdEqy9ObM7E6wCMDDCAzsqCzCw0UXQK0aC8De86 MUtaqY44sM30bwQBjRPVDU8Qz4GwoiHCZCNcwysIsQqjEBFzkXFKy//mKsx88cy4J8rE4v2GMflC iTnEhF6MkZz6ghk9JxL/ebCnFJByzgwYGRAjaOT9wG/kTLCfMOkacStJVMIZ649gcgkrXiAGyMTW BjHzpDEX4zHDbrHEdC3SyMTB6OsH82vf4NFzRuneLmXIeMIFZq/0ju+iQGfgcmINl8eUTMAN89FP yAkgu2ckIo1vmutdVi/5dI1R+ggBIDKXpmPHEGpOOIklaO046oyc8k4eXxImY1ImZ5Ima9ImbxIn c1Ind5Ine9InfxIog1Ioh5Ioi9IojxIpk1Ipl5Ipm9IpnxIqo1Iqp5IqpUnzCAPXOAtoQm4iN/Eu HjFsJg9irlJAyLKF2qwTXdJAzLIqJ8gWCSQrOUtFBO6fJPL2BEgsH4Yt/4UOA7XtgCrvLZ3pldoy hQLzkjZL+8xjK53n77zN2MJQbPLSYfYSME5Q79ByEj0OhgaTMEtIomKiOvDt5czNMdvwzRLT4NSt tQQABKkPdDZMqR6KvTqlHXmqG1HCNkczIbHpAIpFhgJq/IgmJUMTKRzy2aAN+XjTN/UQZ9Qn38Zk OyiONPlKnrom4+ypbxDvM0dFNAmr4/ziOo+kOwEM+eqrniInOkMnPI3yKIYMMghx2objcYwj7+IS tCxyMd9FLS+xncqRcDxoPhUTLZLDP0XFgzDtqMjJNXIKN+SDPqhtfIhHzKylpnRE2gCvxSzFQVEr qRynQ8nq2RhUQ+cipf8CVKZ06qdWDD6FIwfryiVVgv3UJj5bdNpIMjgqFEUVE0QBRkSHcjsPhBDH UVdeC/bs846eqqkidCulC8KokRpZh0g/7md6hHWesb3ITziRBDKtC9sMAAV0RdASQkiBo9EC8LP+ jtyw1HnWbGm+I0oF0C6qZGTAbJmC1LKG9J9icAGpxLnG9DMQ7QbF9E7ZdMyY5k19VPiA9B09MQ27 0jQDri8DAy7WzMRArzRp673epfosdfdObnKqlOTOq1EDhfCYQiQIwFQ/ZxdXcYF8Y1G7qzrACzVk 9b46qXxwZlSpqw6Nz1X/jh7/hR9ZcUsbEpBkbU9pFcVsFelwsj23NDL/DPNYnQwwsjIxwwtavsor m9RMXVNTy2wrPDVUQXUxv4TJcExSK+QibgMr5GJdoWNVHVMFz9RdOUcptKoUU+xed5UNB9Av7BUz 96nHpBU8WXVfD8v5ANFY8QVfZ1VgO/NZX/ULpYSwTotalxVbQ1BVwaKirE0nwBVoWGfSEi18uvXP fmu9NuRaOXN5GuBUswYGGM4vyaVMMTQzr4Qp6FQrcNY8UHbLOCdkdfasfDViQ9b01qm44LG0yKwA 2zRD1skSHdYwpkclAec4H9WO9IgknC9RN1KPWtNjxcR+/C9Av1Z83lC3QkUvxJbUVBY7ZUvHHOpC X3RCbHZO7uw1m+1z/9pRbSHKX/YWYFotNotnbv1xLKj2Ul8Nt5owYu0Wc0rsVxfxHw3XcN0TagVD fvit4qZ1szirFbcWOe9QMMiWZGUzQkT3ZfxzAuLlN0nzmthW4swps4ovjtbz1sKCbiWnndYHRJwT zGLzkDLXovztX92NATCXdQ0RkMal3cjHuQiQcM1Wdwt13SqXenFH5VzkeilXr7LXWavXe8nG5rAE PcKXclBTr8gXQL9XfQVo6BzuU5qufddXfueXfuvXfu8Xf/NXf/eXf/vXf/8XgANYgAeYgAvYgA8Y gaXI7+aVZhPDLjVyhhZYMHoHLM2ELtmLMg1DghN4JqGVQP4NhSzzAf8v70xaKV5a00BEmIM10IMH BIRPSIXjhBuHhbzsVk1ieIU3bzuxjyMpEg4nybyw6fd8UPQYWPdw5R/LE7dOAPSEVPl2ZYit4keX KreoM4rz9lIYMVh7Fa8C1WgM4Iopo/Y6kvim+PT0QohB94xzGI1KyXwxrzEvEDiokVfLy1Uu9ko1 iv1gZoYRcECZY/7UhkaU9qWeRIWTZT80qnTNURG9lS6E7QTJsXUWuQ61i0Z6xU5xRG0ixI/Z2Iym uEAIEQo9QggPN05tp1xZq8RGuW5Azu5WzoR7dldFeIahkV8fcHkMDTMj+VOwo/mIUMgGQoS7LE9l GU6A0JPXyI2XdfH/IFYRc3VZX2yOHjhh65gOdaQMK8TIjtauRPj0pvd6oPni7iKXyIuQvXDH7kgu nhbGwFAHneuprjmZs66FVYWdA0Oax6oOvfhxQQIVMTHIYrk4/MUyE/lgFFdlnNWGd7anyGs47uWe DQ4cu0agkczC3neep66e6Y+9JLmQ7hhneFFUuCcc+00Zi2aQIwt/TtBKCcaif8aJfUKkd/mfomfW OKelPdpK8S+TiaaaSzqjpw4lNdPUBLJ7J7Rg8TAj7jEaPbFudg+3WOCJfbg4iy+PdrWWBTcQX+n0 aNFSF4Cpz6pr93WOuvpOydmtQFchq1ozrxqJgxqBJROu5zrt5Jqu/++a7Owar/ear/var/8asANb sAebsAvbsA8bsRNbsRebsRvbsR8bsTOY90gzUgWzgRND4BbKdSG7r1v4P+jyjZGFAiubLzvpkjf7 PUn7s1Wbs7nPs1N7MbNaYnD4L5ppUpFXQGg7tUO7tQVvh4lTQr2zauV1MGhXNk/bqZVzj6yvnAz6 sIjbn/Us/JymOtHDuJM31dhaqqizN+mr99LWc6+7t8GtWRNkRXEUcQV0YCMOORe09GB0ut1wT0fU R+ijFrsmjiotQyWuqVtkqB7URckpRvkErSZSrURrQ6Njm5CKfQJ8vFEOlAmkp5H6UMX6K0/Zt7Bn ziRLUBNxn4Ymlf8z83Vbx08zvI4n8dAwuvy0tGzNjMDnppj19cHzKsIHZKNrVY94G0twXJ0T4J45 vFJZNM8+J17LBQOHor/DmVMxJaKBDF4H2nUbt53FecYtrbwR5MaTFYURpWYWJcR/3B9v1wkzJUj4 MLaiSm7iO82wa72HzMmrZeWu5GAldhJDvMrfLssZemLDEI/fZSp+1mhJtcP4uWBbST1WIFSNXIZu ux9dB9A3xFxSfCsdLaRZlcz2iWjvnO2klnD9FsK0VokLF2+VTW/wG6KYrfi8gpK8Y8ulyliQe83J aXJFzUXSfL7FN75zQ58l0Nlgqtu0V9PB7nKflytxESEBD3iFu7P/8A2TxHwjkRvYBU5dDIZ0XaZ6 CIl/sLuhuBpXEPmjkj3Yg71dw53cz8jMyx3dtUj+0p3d293d3x3e413e553e693e7x3f813f953f +93f/x3go+6CVTzgJXtNVsngSSjh2W7g87O1dbt9LltYXttc3ZK15zHlLj7sIH68OZ4KyYbiTcjj V1vHvU6FV519aFe54wIHDlLDKWrbN8oHyfM7vVK7obNhmt0tursrxfu6Gaqq8o65tfBqKXflrXM6 v4myCQnojRODgZvoJU67Yf6iZ+Lmk3clOUqBxJuMjWrolZdZmn6yEzKT0vQ809l6fru6oeO7E/Hr daTGg65PjN3I/ztpzCkxvU+0QUmUPvL7xuKWyNBbpeizvGDDRhVzpwhHNxLcwQdfvdnqNHy9gXtH 8Ms314U+Pvje8fWeOKQjVCjDpaxQVw78RhM0aP0D8CN+Rm2KJYcn8UGErkLU5d858E2/XkI/l+B7 NUxn9LOt9BEfrCIfUhuT8Wv08xt99Rm85PUqH4G97u8za7A5AN90skyLIatrZltESAnVxPdxK+kF aKv/23B5/LOUzhlD/JMm+yO+xMlzKgDVG22L4Cm9o2nabSd9Ww+m/eG/KHZr+gECAIIEAQoadPAA QAODDBsqEEiw4AABABYwaFgAokSKBAo+NHCgociRATKCFPlwYP8ACQAATBAJIQKAjgEmVrzI0GTI AB93kvSocePNhixdogRwsiZHoRYxIvWZMuLPqVSrWr2KNavWrVy7Xn3Y8qnXoyqvxjQaAKFCgzbD unWr0ibNhjYXAm2aNiFeh0PlitSp9K3goFfVtjxZdyTgwHOFDoaboO3jlmXBhi3r1a/Tk2r3Mnzo WaRmthQnU5ba0LBYoJBT68XJt+log4unRi3YGfbnoT9nF6wtUnXSAGdf5l3r2DRmkreFNv69erTl 01ZzT7V+VPbSzVDfLjfYnHH1hId3avZdcjVPwmPbu38PP778+VrDW2V5MiPmxFXRFyz6En4+YRfb RegBxh9XqoX/9VJPgdlFVHTbkYbcVAliJRlvWh0oFoG7hUbXhEJBeB15bjWoHkMZNuUheH2JCN1w PzXX4l26iQZjekkt2BKKMgqY3n4UkchVeBwm5d+KNzJUI5OvjQSagTkCR2FYexmZI49GOShelzmp Zx99Yo5JZplmvhdmVaCRkOJ6MuL2pH/QIbCCTMYZBCBMMtF05E5cOqmha4Eel5R+qBFqXo5/HvTk onDepBaRxNnJVZ//9ajnTFSh5+hxFrWoFmcJSVrcpWgxdBafU7YJJWF5NpTqpquKOmioPt3F5pud NrmbkJpy59xxpFL6E5XrqfQqqnsGC2ykmd6J5a+M1poQkttZ/wrUd2duy2233s43nWmeqfYcdOpl xJucrFXIUFFltTUXtumd2xKIX1YonE/oQoiuhNLeOxy6e6EbcL04nTVcUQO3VC6O/8bok7sRwdtf jvMWzNu+05ZXEMIRG4wndYFJK2+xKUrsWMMhPqzjTho/yjGgDCsW87z2Asvsl9b+6nHIg/4F8qSu ikxxzrSt1rOpCw/HIb4m7qwqy7UZ+23VVl+NtYumWXnjWZLKXLPRDt98HNcrl0vlgm9O1a9GFwrd 0kKGig02qzCHvduJQLPsMNptLkj22T+pfevRlxH0drh3Cmq2irMWTlJRGgK+JEkltx3XkJl+vTHe VEluEba+Kf+e1YIqUy44zlozOBLoDMiJOeKad1my61nfjnvuul/Nkra7j5VmlL8PT3zxxh+PfPLK L898887LB+TzZsl0KsrSX4999tpvz3333n/v/Vl8g78upuSfj3766q/Pfvvuvw9//PLPT3/99t+P f/76789///7/D8AACnCABCygAQ+IwAQqcIEMbKADHwjBCEpwghSsoAUviMEManCDHOygBz8IwhCK cIQkLKEJT4jCFKpwhSxsoQtfCMMYNi9cg/Gd5ASzNho+BlpbY08LJeC795znWhaD1bIcSDWRAPFQ 7ZlIRxDCOdVpT13uGeL4ZNjANM3rVFuUkfiWo0Xm+NBcXFz/YRjpY0WVKeuKBkxir5gIPLsUIHBH W1sA04hFCobRJngBSxTVgpkzkgWOgaHjCAUpHzxSJVZItBtfgqig18yNKm70nyLzGME9UqQpRYni jMb4ySDysXKGE4zfBtMY0QnAACJwC7926JTBeNIgZzlBadwSmra5JZWrbGVYGqDL8QEnaR2jlCKp WEwAtIB6uLxRMONmlVreMiwEEJ/e7mVKCknqQs9kV9ncwkpHkpGapXyLGrGipXAiZpM3clZgRjBN ka3OO1KRpimtyTqjdXNx66mhVPA4SkHNEpP40yJYCmW+rOgwmy7y3UEh96XlMLKQurEV3RZjkzcF VJvJlFQl/+H2HC5t9FE7yyEopwUh1aR0VMy65E/EF1KkycSj4kymjNC1HIyyE1BJSZaNOgq0pEzU XHZ85D93Oq2iRvOIhhMqU+c0sdIsDpBR9aZNykLMeeXUX1HzDH/edtWqRo0mQw0SIQmqv4U203D8 tAoi8yYuUvrMm0YNTpweN6JBloiuP33pU13UlDRZ523ZOmsxe1oRGUQAse8i4q+QKbSGRcmd2ZFr ZI34sFcJ9klmreNOKFsg0LpIqQ2VymZ/Nh6+/il6K1EPYT/qpp2Utayv0sxbPwm1nLGWtWj9322F NksHqOBWvz2WYacnmJWi9jaqfBivkjMZSAqtrWZtEnMt9v/WySYERQuxyZ2OWcQ1UtdQGXqMdGdL LJ+9xLpBcWepoGveyFiMt2IsC3ul25v5pui6/6rdZJz6sPeqN1jPbdd/E/VYEfH3nL0t6Elpxlet 8RC/b0SjVAtr1xfRVacsS5OACrzIv3rqIqfVDt/e6l2WNKU4GdkLeNmYzHLlBsRTQW8ZNTtGAsll NiCuEWzDU2LLDo6zOrtVpESLrZftBsDPEbCpjGPbMQJJyaNF8FgB1QDRNrh/xd0iF8Uno+J2Wa8G 3tm4qvXZhEhUJrnFrGe8lsxcJpQk4uOnSJFKUiu3isKtfUEMTtUvGb2YwXCzs0wHhS7qrrHJ6X0y UyqKZiP/GiAFgzqLnNECZwPXFMOP5ilEkUukorzpLB7woaVaRDDZ/tXJrUWLZiytGzijOmYuFVqp +bxl+o3Zy4Jpq1rf0scHX+WGrcGmORmHy1zpGcJveVM3DXkWFqBybwylW6uhuVd2FY1CV/aSXwHg AmaSM5aCgfaqG93qxXVTZTgl5LNvREMEmGDT167QutEkGHmzStSQa2652YTpc9/YfLN5JtPiWS+A Q9mx5eJ3rh9OwbJC/IOQvWN4J45xA0o84xt8yEAF6HGOi1yBGx/5BG9I6P+h3OQsb7nLXw7zmMt8 5jSvuc1vjvOc63znPO+5z3/ObWuDbzFRmiTQj450oNca/2u7puRqii7spEt96i9f+tWazjYwydGQ VO+612HIo+csfTo3Q12Gd2nsmXUOtXC7CdGNU4CPf33udDchuuZiGAhd0nrb1mpVMYZ38pDIPgKD DVga48fVkbbujG/8CX0KlDZrBvKXbZleKf+n8BgdpVAV1OIdD/rQkzBfLV0Kez9FZHQ+rTuN7eFA CGt50ct+9h7Uko+W7ZfTM6DHJmJd5oMC+5V9jb60L77xIQiqSNNuO5RnpLGiknwwEWZXT9o8oo6P /ew3UMmkX760+F6axhQ+mWXh/uo9CzB9Bc1mOAn0p7UP//j7L3YPKr1ze1/23jeM/hey3d0cKRly Q2/yR/+ABWiAB4iACaiAC8iADeiADwiBESiBE0iBFWiBF4iBGaiBG8iBHeiBHwiCISiCI0iCJWiC J4iCKaiCK8iCLfgtJZc8FTcmv6Z2fNFDioZPZUQVNJhP3pMRipZfMLYhFycmK9cVYAFJv8Z1Qfct Mmg8E4FrLkgfMIg8TkgfPLh+/bQ1hraFbtVDc2YmWEcVCPF5fZNIRCgfiWYuKRchk8Z2WMh1Vggf ckg8agGEUkgmVDhAZ9RJFbZUNWiDAyWGVxh1lbJK72chaIg8Q9VlqVJyYeRwx0OHdbhdIVgq7qd4 EBV2mrZ/YhErllFUZicrUpMiSpI6ftE2nGNNC0F8e3b/ViN1W2E1FSxBaL81ESAhOa93iLkoFZtY ToDoi6l1OvinG6iIdiMRjKWHi4cDXUuoNTShhqo3FJRnXEGIX3iUilohiuLRNsN4bI6zjPK0iq31 JtvoODqogdZkHNaEWIRxdxvzSqNGLNY0F4lnOFcCiCOBLX0oFAeXYOPWT4OHbVpYhmFkGYtDg+KX j16BhfFSGioBASUwMhApkfMSeANZjYZzkRHmFNrSbv2IYDVoj2sIj0zYFhTZanpHEWU4V2DohYHE KoIUjUEYNSKJkSYDfCsZktIykhZZko6BkgGZifdoeAvZWR6YabQ0UxGCFpi3Gjo2O0ITGvxhfcKS iKSY/xSdcop4BjGd52le2EOhkZD3cocK9YUOOSgj5Wh8MRzh4ZSLVzIYppZH+Za4x5WxNRY56Izm sjiy6Ick8Y5X2VXOtGnP5zZ3OUl12WkRdSgWdZRY9iwfaGP8RI13448QIjzJRF1RUV7+RJNB1R3F do7dVmT1B5oviRof6Yr3YZRFUoh0U3Hdl5EkIZt0hm4gFpdgI3nYRU8YQhGtZxSVlIPlphuCBBZl uXSVhJt4RZvn522mCSydmW+HEnw0R2yTsZfzMZlMaRy2h5cDxlusVljVWTFYCVGm6H1+s0581Ypk pmkmxWcZhYhJWV/HxYSjeXZ683uY4Z1aKV6CQkfY0v+fXCV0VZKFq5l25ySd1TabmXKNDHeaQ8Z2 94l+3+R7BHqOwycW5KmPUcmB26lp65V61xdRdVJG9BljkQc5z0VYDqJl75Wcq2F9jrmDoNR3DVpj 1MM542cbr/mczxl9bdleI0qjluOhXVlXp0akyldrL4puESozs+Sf/TRhhBSJgnlRhRmTh2meI+Z5 y8aYX6qiGRYa4pmBIDpg86JcnmMZwzJuhqGQ9DKh5oIXkgNgCRM0MYoxr+Q5CAphMBmFWjgZKYeF GlYuTbOm9LKnnfN5VcmjZ9F66ukyA9l9S0dMCiNk7JdMwFY5M4mMygeHmZqeUIqTeAGpYhWh5hcW bRb/S3wqpxgDIlV5pgJHmXPGf0dKUc+iGkFEOFnRjeRYOKSDnz9KJeMoq+45EnXGaVoRTGVpg2Ep JSwDO63Rf41zqxw5Ld4IkFl6U9Q6O1ZXPuiYbRiJENSlh4GhEr8mdybJnFVhOqlTmuWUOcihLsbq Q72arE+Kh2PRO/YZP8Ezpw3mXSMIsNk5Lc66r1jRnvajrKYSqJhEhoiIgQ3bag97sAnrHjC1h2+B sBD3gyQorF0Bhf6KsSVrsieLsimrsivLsi3rsi8LszErszNLszVrszeLszmrszvLsz3rsz8LtEEr tENLtEVrtEeLtEmrtEvLtE3rtE8LtVErtVNLtVVrNrVXi7VZq7Vby7Vd67VfC7ZhK7ZjS7Zla7Zn i7Zpq7Zry7Zt67ZvC7dxK7dzS7d1a7d367IBAQA7 --=_related 0004F481482578E1_=-- From vishwas.ietf@gmail.com Tue Aug 2 20:02:50 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25FF5E800D for ; Tue, 2 Aug 2011 20:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOcZqAkO-BOO for ; Tue, 2 Aug 2011 20:02:50 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id D16EB21F8610 for ; Tue, 2 Aug 2011 20:02:49 -0700 (PDT) Received: by qyk29 with SMTP id 29so298576qyk.10 for ; Tue, 02 Aug 2011 20:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ufooSpF8HL0ALCX4Q8Yvh2AECUeouKg+ohtQi9g2ceU=; b=V+81e0umknsXMdWO6wD5OS1IDh4yvfLGxypDoHnQb8KGhtxLpmsTIjmyb8bfXHQu8k X9i23IiCh00uq4ZAr0gdj8nVZqmDUJmH6529HIVKstJPxfiAlo+E07Mf/FQQA9YJ2kiA QZW/8j/3LCP3ynifgFNHaygR9zjGqEip1imx0= MIME-Version: 1.0 Received: by 10.229.118.72 with SMTP id u8mr4715701qcq.1.1312340576553; Tue, 02 Aug 2011 20:02:56 -0700 (PDT) Received: by 10.229.65.91 with HTTP; Tue, 2 Aug 2011 20:02:56 -0700 (PDT) In-Reply-To: References: <4E388FEB.7050008@cttc.es> Date: Tue, 2 Aug 2011 20:02:56 -0700 Message-ID: From: Vishwas Manral To: zhang.fei3@zte.com.cn Content-Type: multipart/related; boundary=000e0cd5cff4e3cd5304a991199a Cc: pce@ietf.org Subject: Re: [Pce] PCE port number X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 03:02:50 -0000 --000e0cd5cff4e3cd5304a991199a Content-Type: multipart/alternative; boundary=000e0cd5cff4e3cd4f04a9911999 --000e0cd5cff4e3cd4f04a9911999 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Zhang, Thanks. It very clearly mentions Errata is only an option. :) Like I mentioned we have discussed thiw about 2 years back, and you can look at th= e archives for some of the details. -Vishwas On Tue, Aug 2, 2011 at 5:54 PM, wrote: > > Hi Ramon, Vishwas > > I think the WG prefer to use RFC errata, > Please check the presentation material "WG status" in IETF81 > > > > *Ramon Casellas * > =B7=A2=BC=FE=C8=CB: pce-bounces@ietf.org > > 2011-08-03 08:01 > =CA=D5=BC=FE=C8=CB > Vishwas Manral > =B3=AD=CB=CD > pce@ietf.org > =D6=F7=CC=E2 > Re: [Pce] PCE port number > > > > > El 03/08/2011 1:51, Vishwas Manral escribi=A8=AE: > > It very clearly is the case of a new draft required, we can expedite > > this through the IETF processes so that it is made an RFC soon. > I guess I am not knowledgeable enough about best/current IETF-related > practices & procedures, so I will humbly step back and let others decide > :) (chairs?) > > > Let me know if you are willing to help writing the draft. I think it > > is a necessary requirement that will help the PCE community, which I > > only see growing. > If this is the case, gladly, although I guess it would be a one-page > "Updates" RFC? > R. > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > --000e0cd5cff4e3cd4f04a9911999 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Zhang,
 
Thanks. It very clearly mentions Errata is only an option. :) Like I m= entioned we have discussed thiw about 2 years back, and you can look at the= archives for some of the details.
 
-Vishwas

On Tue, Aug 2, 2011 at 5:54 PM, <zhang.fei3@zte.com.cn>= ; wrote:

Hi Ramon, Vishwas

I think the WG prefer to use RFC errata,
Please check the presentation material= "WG status" in IETF81



Ramon Casellas &l= t;ramon.casella= s@cttc.es>
=B7=A2=BC=FE=C8=CB:  pce-bounces@ietf.org=20

2011-08-03 08:01

=CA=D5=BC=FE=C8= =CB
Vishwas Manral <<= a href=3D"mailto:vishwas.ietf@gmail.com" target=3D"_blank">vishwas.ietf@gma= il.com>
=B3=AD=CB=CD
pce@ietf.org=20
=D6=F7=CC=E2
Re: [Pce] PCE port number




El 03/08/2011 1:51, Vishwas Manral escribi=A8=AE:
>=  It very clearly is the case of a new draft required, we can expedite=
> this through the IETF processes so that it is made an RFC soon. <= br>I guess I am not knowledgeable enough about best/current IETF-related practices & procedures, so I will humbly step back and let others decid= e
:) (chairs?)

>  Let me know if you are willing to help= writing the draft. I think it
> is a necessary requirement that wil= l help the PCE community, which I
> only see growing.
If this is the case, gladly, although I guess it = would be a one-page
"Updates" RFC?
R.

_______________________________________________
Pce ma= iling list
Pce@ietf.or= g
https://www.ietf.org/mailman/listinfo/pce



--000e0cd5cff4e3cd4f04a9911999-- --000e0cd5cff4e3cd5304a991199a Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <_1_07FF299407FF24000004F33C482578E1> X-Attachment-Id: 9a4519b18676f0a4_0.1 R0lGODlhcAOgAucAAAAAAP///5gAAPj40HC46Oi4cAAAcLjo+AAAmND4+NCYAABwuOj4+ACY0Pj4 6LhwAPjouHAAAPjQmJjQ+EhISOjo6GhoaIiIiODg4Hh4eKCgoLi4uNDQ0PDw8JiYmMDAwLCwsNjY 2JiYcHC4uOjQmLjQ+Li4cJjQ0Li4mHBwALhwcNDouHBwcHCYmJi4uABwmHC40JhwAOjouLjo0NC4 cHAAcHBwuJgAcNDQmND40Oj40AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAcAOgAkAI/wADCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtatXrRU+aLhgAYBZABYu aODQ4avbt3Djyp1LdyiGs2czTKSAF8AFt30v9h2M4eHguhsPI15MMjDjx1U/9NWQkm9fCx8qDAxb ti8FhZbxYtYskPPgzwgrnAZRWGAIDYPxCnYcwMPgDQoVI8ww+AIH0gE6vB5swWBoAG0T3h0cQqHq s6hLe2ZN0DTe6BV1bwxBm+Hx5gZ59//1DVw47MsJYwPw0LoCbBACOYhueN4sZePEM2/+0Pl6+utn jTYQBvXhldxB4uFF3kDmEbfQBWf9BdmEUWm3kHoYAhAeXq09tJxZxQ2UIAAdOvQhWgRBeFaJC52o oUUWDrRBbwXFGICKGeaoYEHPmaVXQTOe1daJ8BXUHwDAEXRkbB58cGBi3XXUo1lPEtQXiwLhqKOO Elop20Mg4PVjQZLlhSCHEZ0YopdnGfZlilvG2SWQZ+FG4Z1PLfkBRjEGaZYHEdlWJ0F+rhcoXnYK VOh9DYX5JkU2GuQiAMeZdZCj9n1UplnNFWhQB3gBuikAHGxUwZHYRRQpR6AaGFxfSRr/hCkAjGoU pUMFAsoddAoVCihEgpqV6EC3/tdmQbPWytGxeDYbFQZLxnndsAphUKmOFGAp6bU5ZsuQtXIGUCxE q4IW20IVcKtjqQ0Fa1aq+OGlbEIjxklBrBJJq6+bfVXJULr6nsXuQeM6VC9yEIGrr7fGWupQwQEA HDCpFz7q7MUYZ6zxxi+NijDHIIcs8sgkl2zyySinrPLKLLfs8sswxyzzzDTXbPPNOOes88489+zz z0AHLfTQRBdt9NFIJ6300iFLIC0CCQQwgAAAEKCy03FCfRAEEfQ1AUIKZGjAAVsVcNbYIYWNIdoK ce012HF+LZDa6rGd1NRVr4S31RvR/40h3wX5jaHcBrmNF+EOYR2b1gk5zbhCjkd9kN+AD+233R2Z /XhBeJsFuNoNEGQ2AAswMJDalR+EdegC4Y051ox3DvjeBpnNdudaQ1CCQKPHTrXdo5d+uucRaS55 7cRHFPbmopvFOkKGA/A86ATBLrnsA+Eete5zA8A8Qta3TnXeA2GNOEKjA+7AA843tPzxBY3OevoS Ca5e5e+j3z7k+0v9O9kDCZ7puke+AKwue/8rX/9cB0D/FTB8Dixg5wpIvYXQLoIU7J9C8je5syDO fn2pHP0yAkINCoRrjDNe4SKQQu/BL2zC4xzVnsc0jajwIBdsHtvChjmBrI90AzTID/9peMKuyc18 KyQf3ogYAB4CMIcBBEAPm+hCKk7xhzFsyA231jXp6Q+Iw/seRNyWRfGRD4kFcRvfoBhG+IHPLOcL gBoVCIA4EgSLQfQh+6ZoEA42xHBM5J1ZsuhHhhRSIkNMotycKET2lS6RaTRiACBJELfJ7YJorGTX 1ki11AXAdg1EyAXZ+EkphhJuYsQeQQ6ZEEB+sYzIK+DwZIk8McavigjEpRltWcNeDmWOvgymMIdJ zGIa85jITKYyl8nMZiIGlBSCpkz8SMqmVLMl14QIKxNiNiJmEiSFlF9BnAZLZ5ozKJRcpSnNyDfF BbKNFuwk8tjmTv6Z8I7seycMGZD/zuHxEZ4FwaMDmSjNhFBzhvMkWz+HV05N0hKYdLRj4NbpQE4q UZ4DTegk83mQgsbzomc8yzsB2rZNqg6OubQoE+u5QV3KUZIGyeY5Z6oT+yHABBTNoeL6wrzR9QVz P+zLAkhAUQOqZ3M7xUtP1QNLm+L0n82LTeVI6dGTirSiGo1ibBoayYfCNKJmHMxQUYrVso4SozoM pf0MIIKiftSigEvqWZCKl5EWcYqZPCstBSJXs9D1qqX0YkA5StPCGvawiE2sYhfL2MY69rGQjaxk l+m2E4wPL1mcGlvrqtXBENGnIYylZwmCtxFcdq6SA23yAjtafA5ms1AdSFDxAtsn/6I1ircTwGav qlfTDoZ5a0WBWxvn1m1q0aUT5eVxwbjR1bJyiQzhWg9zqNqzpK66qy1rWqPaWoVUF3DY3WtH7yfa 0KY0ozIUrCBjE8iFTlZmEJWtI03HRoFOpHNfs69CqFpUDuoXIf8VZGwDXMrcqhe3tt2rXj0JTQJX 9Y2YMy5DtthH5D7kh98TKNYYPNyY3pad+x2fRMN6SYTeEm0E1qYuWZniEJOVxfPVbkWh2GJRfvi9 MYsvY0d3Ph2LrJvmJGcecUzkIhv5yEhOspKXzGSOyPQmT36Jj5UizShz5cEZyeFBxdvkLgMFb7C8 4Te7t8MOG9LMpMUomIcszQfnj//CejwwF5mby/lZGJJwbi7r1nziU46XeT80MN8Y6d0O54+/ZY6t Ff18ywwTFs6BZnQUfWcA4TLOkiDu3uP43DzlevnTL0E0AMUZZ7OwzW12wxpXX1pUVQ9wwVkNbAzd 9rjRAW+QQ05i8oIqQlM3UIBavTVzRb3cGPpU0EVsNa61Ouuu1XrZRvV1slMNbVQ30NXB/jW0ZT3A Y0vaobpUXBmpW1Rir7fXshwhqNfN7na7+93wjre8503vetv73jn5rgN9y1M3hteuCoywhYkr51Z2 DeARqexpPRc9D96SvQ617GAI0HCysroFXcQsm9VDQ822FbD6w5y1Hfq10i4cueH/9WR5iedxzkIx uMV9rXAx9+8077Z/NXftT9uqaH2b/Lf+5vhDwku4n/d7oos7ntGV6kaY01zo+I7KljmM4hhTxGkC 9zQdVR5nY2/7IDVOduowXT2Uhl3sXT0fGn2Mx7PLuCF4m4CQWT0Bs2X2xtKEMZ1RqfQb087B6wR8 1fduY1qeXfDfVuem8R54q0+ElVgnm7lJrU5k97m55Wyw46POeWbyuKvgtTjanfl5h3K986hPvepX z/rWu56ZU09Jnuci4SRS3KQ1HXi0FY2S2r/+90OfeEpif/kJYkjrgkzljcHOPmm/vcANFNz3yJ7c BKR4n8+notYrLtYgstH4R3Wj/3zPlnhNi1+ddcz0908OdLf7d/MMpe/ypX9+4NtfI+JmgLnHT36J zP6aoKU10PV8VSU4PbZJs8VVs0V415R/tscQeAM12bSAfBSAUTOALYUh7wRrANZ8ztdIeKFyDlhq X5d9BORw95eCKriCLNiCLviCMOgRErB4XPYRJaR7NQFFM1h/FHGDZwFLVgYSO/gSQxiDRjgSxod8 HLFl6Td+l3ZwsZaBQpVrbkNQOUU142Zi5sZA6fU5uqRjs1d9hdaEetVDVZhVnGZG06NLadhcBjZd JpZLj+NHZ3h5R3iHP0F828VqYSZ64+VX8BNUp9Y1fdiEZJRHdYhh8DNyz6dlFv/mNrahhNonfhPU cWp2Y4f4cHKTiQNRh5OYS2UUaZk2foVoN3RIiBvXhHi4io21U6fHirAYi7I4i7RYi7ZYQ753i1yR ixARhDehh7SHgyvBi8hUcQj3EMRYSs/GNu5FRcKDgWVHbaZ4ZzEGjQKmUIRVYavWUoMXSFUWh3Gm T0DUjNjHUlkGjtdofiC4jdZIjoRXYfQEch3kaGBkjdB3ZnNIje+YZgWHZRN1a8sIQO64jZ+ohmiI UeaIjMJYkK71jOh4j9FWcGJokAppefZYUMmYZD6ocQ9nS+F1dzW4e5KWcvxIdaH0kbmWXmJFVKpI RTt3hVyGkg/XfWWXdFH1iqP/iGDcZV5v9UU0GVZCxZKE01coR17nZYf2hHNG2ZN2CH6DJJSx5JFM lZIGsVOhs4VoRZTIh109RJJHuYcReXR01D6k5JSkA5VmxXjUJo+62JZu+ZZwGZdyOZd0WZeoZ1x8 FoE8aFT4s5CKV39tiEOntWp+A4RqaVtjoziPs4ANxZhUqUguiWaRyYC6dQCKiVM82ZB5pJeudZWX CFI4yWpWQzf/5JgOgWneNktoVph5hGWFZJpzhmv+uF4hiHQl2IFABGfRUzrQtGHjhTa0A1rvtIBe lX6peYKYU18euI/EmTqw5ptRyFhE+ZMsQYxcaHDqlYwZ+VE/aDrXV4+HmZOY//eY6EUR1PeX3+mQ 4pWLkYNCURM5kXOUHFhSLdlG9jhGuNeJX8VXZgd/3ZNFkaeMfSeR6RVIAboQ77eP2CcR93mg/Jl+ DkqAFEWc6UdoOnae0VZieXN4y4lShDafGWpUvGeXQTNlJPoQ8XkxKXqiLNqiLqoRIOoS2zlhRVUA wlOEL5qjivWhnzlo+ig8M+pP0YdLA8lP2Vh55aejSrpMZjlWZNijO1mbM0lbDdSkaBmWzyOT6KdU T5WkS/qlYBqmYjqmZFqmZnqmaNozCjdx3Hc+JeQ7hAdJboNx1EmbfYFw++eV6kc1/MZ0tnk2M+el EkZ5DGlPx+g+fik+N+dFLf8Hcm+aWsJ3gmK5ENLFaESXS32KWn/qp3u6qHYmVb04PhIXklZlUeVU e4SWEL11ckp4qWaUqYC4qZqqqB/XP053klA3WAT6exe6nyEaWEyUqnrWT2w3X25XeFYYW/i1p3ul ee84m3/ZQYRHjIRaYfVZYUpYloxXcKnqR9W6aEwZreO0TpN3TzwKmg6xrC11qrP6RlzGmeoIN7sq n+HZUt8ToOXKrTCZOog3nqFKqiwaNod6FaWnnwB7NED2ggU7ehMxd2n6sBAbsRI7sRRbsRZ7sRib sRq7sRzbsR77sSAbsiI7siRbsiZ7siibsiq7sizbsi4LsVoyMWYCFxDTEOr/8SvkUrMbI7M58m46 q6MuAi8SUS/4chAcEC2XMTAPcbQ5YgFK2xAdUCCDUSTiYjH50he7IiY2+7MBgAExSxxPOxBZiyIM 0SpnUbQGcSTgQSjqEiBhmx1c+xAjsicQMSpjchBe27RvaxBfIjGesQEjsrcHMSUvghBMmyFOu7XM EgJIexZUayJfm7T84jBlWi4e0RfU0iu3grkPUSiFOxDHoS0GIR9xixAW0gGVQgH+UrVWKxD9IbQK 8brIghd0O7p4Mba1O7uOWyOushAUcAEbEAKrm7M8Wy5a8riXorVpyysQIbt8uyMNcRyCy7pmgS+c 6xCeSzDzwRBj+7kD4bwP/wG+BuEnmRumLnK3MLK5rcsQ3VG6xPIo7uu+z7u+IsIcAmEjxaseZyIk A+EpmxEq/zuzDPEBB6Meqpu+9KsRBaIsudIw+css7wvBUIu1SoIXeyu/1Ou9GTy5GvzAkfIhojum s/Iuawu1UivBAhG0aLsZlYIlKowuLfwpfYG+BnHCGqwqpTvC4xK0IUwQ9VLC84sW9IshCkG6ZzEv B+EuSPwwGDwRBaIlOFstntHD9Xu7QXzDDUG4eIG8eOsZK1waMXzFHNzF10HFAvHDL5vGbtHAatzG imXE4+HGcjzHdFzHdnzHeJzHerzHfNzHfvzHgBzIgvyiYeiLP4aDhsN1Ff8Ur7E0sCYRpPY0Ykuo e5SXyPJKQ9pJyfeEMxJ2QCRFqV2kyJvchRBBTjSAg6bsUvC6S3vJyVQKEoUcnmY5qdLarl2XktiH lYbnn/yYI5IYhtCpYsfXyslmR++TnvK3nguJzA8qybj5gQaVIcwTzAopiT5ozbSMQcMsqQNHfx62 obycy/WqqlCKlNG8Ob1Tf7xIzR+hiJXaaMfzzp32Qu94n4UVy806XBToparph/x3m3ZqNQc6gcvJ dfs8EWG4ctfKyBOhRglIlbD5leMK0LranVXpz38Yq/Ysrv43GBK1kRZdqBZhgM8MzVuK0ZNZn8rJ kSUZnd8MVy6NrXtpOIv/lKgK7cyCyVnHpXVhSDmD/NNAHdRCPdREXdRPQaG1NYp62llvI54QyVqZ CdVSGqVsidQ8l6RLvXS2rNBWo9WxStWj3FWjGoJtKqtfnZboum+s2nQyJ5mkrF16qm8l9XQ/dQBn 5al2OtVyzc56ZtRG0a8mSGIMzZ/A+ZDQqq6Fl34c+qxurXfqaZIIyobheazQk5/FPNFy863nCtNo DdmADYHlnNiEk4vVlFehzZ2j7VLro3wH69c/vbCi6RMJuxMO69q2fdu4ndu6nRSQzE1uvRDQOhQR CskJ3dsuCacHpjZPmF3APa9IYdwkYcgNu49zPGXiLGdFGpEjld0X2V9E/3qk6vRI4E1miedem32Q BadXyYqNEhnchK1WNl1LPNjbnYPJsUpgzWiwnoRJbDnR80ps2W2vx+PYj5mQMr2OyRx6ARmOcGOY rc2ybsMCoCrRYL13Whl0W+V942yVTM3S/exXXYqoPBXiJPiDRGV5LS2hAveSIzrccdJQxR3fPnmn usap0RUBcPhA4VeTQKdzmHXiuJrhDcHheW1dQ77jFT5V2yqVQq6rjrzbUB7lUj7lVF7leBycU13R Rv7NIQ3aHs6sViOcJc2cy0mQ+h2ZpVnmEK3mpCzmCZdxvLmvvUzREa3ioWR8DYXna/7l4JabaPZf q9zXWB5ag87cVt4S0/85hdhUrxT6NcKaS13OndAWo/cYdhv9R75qfpdOkeGqky5moHLO5ct2dvs3 5/uo5+VJzhIZoScFNe5pVFCzoo5Ig5B96LZ+67ie67q+67x+M8AYEi4uiYozdl3kTToN6QttFCba E9JdEdANFe7NkM0uEtPusXJ9Elu23n3dQdsY7MQc2Xrtz01KnrFtepi97dpoOr1KS2tn2fHH3Q85 1wBETjKA4/OOS91dZvRIkNn+0ui+Xe7lrOKonkRUpOb924yc7+w98OTpewp/Zgam7QHfeAS6oBXL 4aWupfyz4jpSRj5o0B2azdhJ7PX5TRq/7mpHVm7jAhm35RUOkqEJggf/pkoU/tRS7fILgfF+d1tr ddUnbWo+3+FdDoBTKas3hfBYaucvT+5CX271aqVkVeo971Ya3+tWf/VYn/UlU+2J8zTfDhnK/fUy miF5vnxabzRBZeYewYQZdGDARkAxP2nnpz1ytDuBpT7N9zwT5IXq5ckOZDfRs4YHBkE0T/fcI9Ln PODDZfh2//YuiW54H9Yc/YcaalFVdPiOjzpRBafT+FfIPTvjkzu74/fXefYh8+sQ+ej+utNz/2EB JopKv1Bkx4lHOWblXk2+p/qzVPnw6GdtB3+wL+DuajeUrvoC5Wa45Ee2D0wrzUQYavqqt+zQP/3U X/3Wf/0Yg/o2SN22/88Tzz75D/fkIvH9zi7j2I8ySSj2GoH60DTLNt7QUOj+qEXqT7/zGQRcVRSE Egb7MSr/gAgQDh4AWMAgwEGECQ8qAIAgwUGBBA0qDMDQYYABAgAQoHhQAgCQIUMaOIDQ4kOMGkWu BHmx40uYMWXOpFnT5k2cOXXu5NnT50+gQYUOJVrU6FGkSZUuZbo048amUaVOpVrV6lWsWbVu5drV 61ewYcWOJVvW7Fm0adWuZdvW7Vu4ceXOpVvX7l28efXu5dvX71/AgWUybIgy6EmaTxtQVJywAEuQ ixFmNCBCZIOnBRVGlHzwMWSOkzWOUCnSJcLPLDsPhlxYIWGRBlAAIP95kLLlkJ1Tr1ztuXXv3SJD owY5HOZT0ixP+wadWEDly8Qh967YennwkMaZszSOvHTI5R2xD8de3DmA5CvDw1aPsrHC99t5zxyf Ev33loafkm+tHWZ5ACZQCMDuRsPPNem4SzC7lKDLzSTr9NMoNO+UQ6k+wTK0CjGb9tsvoYg0k+nD jjjj7DUEQRxIMxIdo62kECfK6TPqGKotRooeq80+7XCMycecngpQpxaJ25FDFSWKqcgAgPwvMops LOk4lQSsLrwmVzSIyQB0nDImJJFEyEnGJszxReZqRFO0jYokEyckufTSNjOpBMnKl8T0CE09s1RS zjVfEhLPOOt0EQD/NXckEdAdrzRMQ0gjZY06uj7D8yAIIoBKUk479fRTUEMVdVRSSzX1VFRTVXVV Vlt19VVYY5WVU/ZaUzKhWiG7tDpbRSK015BEnNWoPoNatE4uKcp0U1nnZA3LngrQTAJoz2wUrmSN RdbQYbtlKtfppNuVJnAVhBBYRFm7tqOPhlRoWQq59U1RjYSd90sIL3oMyxNjWtZe+yRrd1x46bwV 1xRf2te952ZzaVkrj90024T+ldFgyRamqF+Ylu3NY4UG3tPdijUNjeMACvaN34EyTtjPdTtCUuR3 TeZJ4yR3BDK+zC7uck2aEd4R5JLTTYhmEp1F+KKgIaR34jp31ohS/2+rtqlYMNHVrlyWRMS6pmUb bVfYdl0S0rjPRGx3zWTTnmjZ0z5r1G2ZljXPT2YDKJvhu3kUL1B/NU1xbXsljjfvl+zeNKK85f6S 7sARhzjkOxHa22DE8c7850Ah51zE1GK2Ft/L7dv8JshDx3ehB+GT9+cdaRxzIJCGtrnoXZE2FHK4 L4QSItrZ3jZz2Ki2+njk41I5eeaxstu/VZ9vfnrqq7f+euyzT7Xc0ww/1NzvV9qVe99X4i/cJFeC TnTt23f/ffjrkh3Fpw8PrU8c+/yotvmF/pLDN21GS6OLXwENeEAEJlCBC2RgAx34QAhGUIITpGAF LXhBDGbwgct7Ff/WUnOpr52pdviyW7WW9qishPBmRsMJxc7SogDChDNKQxHLWjcWF6LlIwDT4F84 mLLbWa5y6vrS/ooYqB+yriAoQxgP2eQfZ63NeH4LGAGZeC9yAQtaKmTOuHbCRYyViYVZbBQYpVS3 IOYLhWKkDg3zJDyojXFkcrTJ2ibAuNBAoAar29hAwmOpGq7xUF5MiMTaCDiZvYyNBCRiGJNEqTld UYk+y2EP7fLDyR1tiEJayQJIMERNIhKIAHCB4IQjwq75rETBC9YnxRahJxoMioDL1fr4mEgTMq4z YAwfSwgZJXSBhEWv4xInReJJUK4tXcZsJSg7FgHRladRjJoSM4X/+Ul3eY8iyjSNIP8WLruNKyIm TBPrgDVF18VxluwbEGSm+TpnWZMg2IzY68wZG8tcC0A8lKQl/flPgAZUoAMlaEENelCEJlShC2Vo Qx36UIhGVKITpWhFLXpRjGZUoxvlaEc9+lGQhlSkIyVpSU16UpSmVKUrZWlLXfpSmMZUpjOlaU1t elOc5lSnO+VpT336U6AGVahDJWpRjXpUpCZVqUs9SAc0EEyWWIADo1qJTyATAp2wpHpQ5SoAblpV ppolA5DRQAVk4lTIgOBTYOWJrSyAE61SL65hZWtYwcIBlph1J08ViQY6VdesAkutNJlr8wq7VMDa lSsUWIlefdIB/5tUgLFdpYBjYSLZrgKgsjMBAVczEIDEwhWskxWJZTtyWIpUYKyUNW0A+AqSD8zE Ayu5AGf7qpDVehYoqP3JSjAQ2dAGQLWZ3SxMRBIA0kKGAx1YCWRpYgGRTDW1yQ1mcV9S1deiiwIz GS5rZ3KBkNRWsV4Br0h+2xQMrMS6L8GseSmSXpGstyPtDcl5EwLfkPg1Jrk9bk8K+wGWfPa6we1A cvUrE7yKxLkHCYFIBPwS/obkrTCBbn0Twl/7vqTCIPGAVYPrkw04mCblBclgE1Lg284kwSFZcEJY YmKYZPfAL2lwSLarEPyCRL7T9e1p1dvahFRgJR2mCIrzS5MVg/+kxQohsXjHyxXeDrirFAnxkW+S XRhXGSQzpgmWE6JlAMBYJtn1qn9DS+KQxFYhvAVzhmmS4w0oZMMAWPJBSOvX2ep4viKZcELyLOHl MiWzwJJJcqXbkRrrmcruvQmcKdJjmghZwS/5c5gXbWWbeHnNIsEqYfv7ZUbbxNEd0XKcn8yVSgOg 0zMZ9KM/fZO6fjgmsX61p0Pi4VoHmSU3PghvB01ohXQ2zZveMkIq3WJhwxYmGKBury5waDPneigA lnBH+GtqV/+6NdkGCU74K2bmTprbZRbtrYnd7ZokVtu2egl+3XxqrKRazbg294VDXZMcOzkAGMZJ vhOC5ndfVtb/tq43TMDMYdCGlr9AfqxIxCvpEisku3qdc53xvYEIR7etAwfKnOedZF5bu7RE4ThF kkzuZAOAyCK3cKMdPm6bJHbhRnE3vL0yZwA8eCe+Fgm2Z3LwcftcJkBXSHLnHZMco3vj0tYwsMct ZgRbwAMbCDhCcpuBcINE6AdJeY5XThFDx5zpBFd6UpL8Wf4eXcoRtwkHpE51Hxf8JskNAd1lspKt Gzy0Je+1tFcC9Zi4fepVt7lZyGxjDXAgwxUIAQhw/veYNNsCH3BsBT7weApY3M5RpTxCLI95zQfg 8RpYNQZA0Gy55yTKy2Y3TJpNARBkGAMfQHNIGI6Qk2td7yxZ//VLDq5ZEIRgwR0wPXX1rfp1t34m j9fs3Hcd+/vSHjJA5jupIdPnmUi+8wf5/K41X/0Pvx76CJl97UFy++oX3iocSHWvPABtnLgdWBmA P5KZ7+D6/xz1bE946svtf5pov5rggIzbtby7O5FQO4qgNkVru/vjMwXcueTbtppINJDIvwEsQPU6 QBcbu3RLwJ2Qv16hP7ITOwBUCALULg48N3JTPxdUKpB7QRmcwVDRQCWjQRzMwUgBgdWiAA8gPB0M QiEcQiIsQiM8QiRMQiVcQiZsQid8QiiMQimcQiqsQiu8QizMQi3cQi7sQi/8QjAMQzEcQzIsQzM8 QzRMQzVcQ/+k4qZeuYhK6hY3tJXl4JqQGJ9gciKs4CWbsJilsMNg8RlAJJl7ApZfQRc9VIs4LIpF rIlBFKaLeUQ8NERHpENvYhxywkQUkidFsiicESOO2A3o0ZyDmQljSkT2ABhqohOSWJvTYBxIXKVj UiWa+MR0IqePMA6s6ZlnGhLYYKdUpKTnOABXNAHwYY1A7CVREiDzuZpOtI9hesY90UVpBKZq4cUR +Q49hMVSZJNkFKNvjCUUCUdZ4pzfMcXhCcXoqEQTwkZHOQ9cPB1NIqckUUdoiQh7fBQ3GqVRVCA3 TMRoeUZ3XBnfsaEpOqOYaBpMuZ1VhEaf2UfEsEXgoaOYkEj/ccmJR0QnPyykqRkZgmHIelElLlJI fhQiQmQXZ2IddjqXc7pIOAkmakQXdKqOlfwZg1TJW/KfbNwUklSZgYSdnBTHn9xHYEJEQQQWtEnJ nRASYYGNX0nK9WicFHmTGJIoiyzHdqqN+PCJUzSIAGKIaFynapKXqqyioLhK+1hJonlHnsikQPrK P7EnFYJLtVFKZhQfmgxKNaqJp1BLTdmlagykoehKs7wJwgTHWPQbutwSeFpGjlQnRsoaLGmXmAGj vtTLtcTIwgCQTmIAzpxFoFSWNLootGxIzpmbxEwcTXmlgymdszmUuhwhrGynW+kd6UDNbpQJtGRJ W9mawEQj/wbBG+NwTZUYjrZxTMpBkNc0yV8qp4mUzWfxJpgYRN/Mw4ngQ9UMlLGREceRDhEJmyOq zdUMTxFpEeLsG9MUlHSMzOmUxs84Deykziyylea0SekkjvDgRHpkQ0lJIv78zxn0TwAdUAItUAM9 UARNUAVdUAZtUAelqXiyp08hyqugFgmRR7fQpkY0Cm3CCQu9iUyxF/ZAgByQUJ74UOlYjY+YyQeN FQollRelikLB0LnYUKcwUWfcT98AGJIkCjHpHyECyBYtlR/qTiqyxeUZyPdoSCQNoiZllszEopI8 lJUcyIh4GkIcp/tkS9O5FC1dSDqK0VHSp/xwkafpjacwm//1pKJBSZKH+UvarEmhrJMnpcb9lKSg kZh1qdMTwh2UlNMhBZVkMaLZHKX5mEghTU/FuSGEWNRz5MRuGlTkhEs4bMyanFGxNJ03vE9M0pTc caY5hE4NXVMzLQlJBVQ25RZHlSMucstQwpMOrRnVEEzREJ2tDFRUiVLKHMtN0RNCHSV7IZovbdTx ZJ3w+FVfXZONdEldhU71LMUr5dVMlcwLndZl7SLg1A5X1ZvKIRMjHVXIzMopaVbkTCf7MVYU+lUu laEBSk5YJdW91KQy+k0hQlVcvVe92M2ueAwh3dfcxFeAtYtQtdetCFFa7IoVDViFXViGbViHfViI jViJnVj/ilUKFBUKMa3Icg0SHLVYWoIqAQlVyHAJSZyJUP1IliBYICrPjlWLiw0LG/VQiqxYSMHO WtxYjVVZs1DXdUUdabTZx1QTl2iXadXNf60LoJWKmM2JHTpYiZUenUzL1YnS0LTPohkOqo1QZxpW Ls1aZR1NI+1F7fhWS+XVdZGYLPUjlIjSsE3Ij9WaJzEhQOxH0YwNfKHKlpGJK0qahFkePi1UKfVa OZ1Re4lWjV2OJA3JnJFWj0SR74RTcd0mnG3YbSVIKvLGTSXWWcWczDVNDoFU8EiAU9XL0QXcqi0m eMWi0jXZj9XRv5Fben0jG9KMPrnVuh2XIllV6tDdx8xU/9AtU2pFVFpUId4VXlx6CBjK21F6V3TJ z46kWTA9SYTkkmvlHCtJVtvpRkC6XCP5nxSp3u0l15oU3ynh2jFlXHM1XWchX5rg2aS1Wtnd0sg5 GMKY16/tG3btRhLB3inh34lE3GIF1oe0S1p1yMUNXnnl1cIdiPqpGQNIgW4EX6Xk2YoV0JDS12Y5 2oTiV6eNWAu+qIHVS28x2IZKWOg9YRROYRVeYRZuYRd+YRhW2pb9iqWNig+GC62lW07JWCLB0RqO YeT54VwdTfmZ3Ak14p/AVCA+IE4aDsJYjc8YDl0yyc64TLdlISvGyiY+FygG3iz+HBkhDB02VGZ5 YtgMY//89RwxxlwnPkdkBExRrZN2qWKNIFPlrGP0LdWRoWPtfFQ8PuNziUk4Rk5XTQ2oRF5DmdG+ MeMlvp70vMtAqRXXleQ1ilUsKsvfrcbKdZRMdohORuTMEVPbPd1Ebg9mTNSy5c1OpOR00iLRfd7I tZP7aZM6YQg+buPuSeVGrp5VJBPDvaJN9pPd9VQt1mWIdA2ETBKApFqVSebZURJnNt5Hfl0UMlzF VF4/rdo+td0zAmZi9mZ3iWY/0QyJtOasaQCGOJmBgIGBKJAyTpFp3uUg1mX5qFRWxctK9JX05V4p febg7CO7BRtPhcVq4Ub2MejViednhZIcHsc7fAluHEX/UeTWdakVQrJoiGYl9uGkxeDhKD7g3g0l iTDNj5aOpKRReU5plV5plm5pl35pmI5pmZ5pmuaoixXiOnpbdJnEkfUm0B3jtrhhssDpm3hZWQYM HtabXEZpGWbqmlbipXDf2K0OPQwaz/kbnSULocahGQaK9+0LHoZqriBqAzUm1xUKRfZStQXTQ6pJ qYZbhwZN2qxPnADPQ7mO+23rcQ1g5sDr7EUchBRcsxXhZ+4MWDRs5W3TZ1ZTaGVgwp7Rs60TtoXO yc5rRvpitmakInVWBO5SN11byNXjJVFcNpEMxf5fvkFTjWDstEWQys5evQ5Cs5ZfH4XnVP5kt72W r65b/8mgWoAW0k49SZHB7eD+VHfZ5IXBbRsFSwaICAGxZftg3kyl1C0V61gqXew+EAvh509e3egU Rz3G7YzWYPUFHJFt4MjN7ualbTK07sDVFIDZXpiQ6rNOjeVgnGtRJoAJxmyVVeO2Egk+7tHcVpoJ J/rZa+3dpK7WpBeIAZJRnZCOZSt17Jlwbypi31HqjV0F0/hW8MwJcAAP7ZEBVAtfX/ge4JOs22CF 3F5u19vM4+7N7FDK3g5P8ZpOQgyGX9Kc6hs3whBOzpQlbIP68R4vciM/ciRPciVfciZv8rSw8KEQ 2e0OFezcHwju1xSyzgiXUR538gqqjw+ZaFkkx5q4Sv/KIMbQ9ed/LsfdoJTD1NznHomg5G+ObEXw MMZm1NsBIskzd0XD4MZtZCWn7tnHZOx4sXPgJcVAl2tzXHNeSU1WRHMv1sYO9nK7wJCoINwBdgmL 7Cdq7oifJMnpJe0Yz0vgVMXn7UmQzE0wkm/7WI6hVKR+EXWcDaGSlpgOv0ltjteZUUqfJHWctPRI YRwsr+2l9l1Y9gkzfx1urJxRD+VlPMxNPonF5Gd03Um45u5kz1+8FGdrlE7bTFXEGeVTrnS2rPYc enNhbx6lIWlnvWqjhRZAYSFYRG/RtuuRedzgxKNQYm3jtKcYdXWA1kqAf/fE7J96f2wtn9PNCVvP 4R3/TYkb85509HwdfOdW8l53pNpqje94v+B4jw95kR95ki95kz95lE/5/4TyolgbbRUcFgWL3f52 gHZjrZh5n8B5lRcoMDeQKV+QdZSJOfZZ9FFGUGrI24iOMOeOn/T0eH0j9E76GwKQQ9IV+egbAqlz 3DhH8rl6ZqH6na8eTG+KGY3tfmJuzTwlYX4j2g1MpN/2yxUTdaXg+NXYbBqe3jh7aP7NMJH1ASJ3 qPdel9D7Yg/7DCpxNCnLK+7HGFF8QidU223ofe5ZE8HmCv9ZPw7XZ+5X/VmTvp9dxoR2OkpmAHJx w38oZVqM9Nwncy/EY/R6SG90OU+fY3IlGJ/N1E9O/4IdROqwZKAnc2kinaDPevDG3NpPpuFvjcI/ fTSEbuZ/fuiPfumffuqvfuu/fuyH/ke08Rg2aq5c8LC46ZYla5c9a74E/6Mx/5TSeRVmf9N9ctse 9Axxf6/u8oJy1JifT6RkTsd9GxEHiAABCgAwcEDgAAEFDwoUCCECAAINBRJEkAChwgUMJjp4sBAj AAATOHq06BBig4kUP6qcmBBASpcKTQZ4CFMlQZYvDaq0GXMiQZ41UbYMyrDixYY2JbZs2vKlSJIA aL7UKFWo0wA7GSolilOnwp8gaSKduLRh1Y0NO4INOXJtyaRZAyiYKjftVa5Oob4VyJZqWJUvaUpw q/+yrtWhN79izVqXplaFUeHaBcm0bNeIcyMDSAwyJl7KQvlKJVs5M1OBj+8qbMxZLGfAmjlP9hu3 4erNunfz7u37N/Dgwof3rnua+MTcvNnGtNkXasjo0iu/TH2YusLUbD0nxz4b6Efo06VDdlp4fEie 1ZsWHp1dsGT00S2Klw/Z5nTYvtczPrhd7XXlPfWeTPKRJ9d56DWGn3Q//ddUbvyB5xqEpz3YknJ7 ETihXgmOhxVzJ9VWH3oCYnichA0ZZZlZEOW32YVOxdidSSmutKCLDQbI2ncqeTide7PZOBBLdB2H HJJJKrkkk0066diRuz1kQAqdASgid0RONmRmHkT/GZptbVl3I0M2ZZlTXy3NqKVQPvmYHkNDmnml lm/N+dVkGQrUnl69DbkiZ9yxRSF8PWJJJ5oBrJmTUHoGwCdIgnoU5JhEErojWhldOWifAxpqqX8e nQlnTxFQaWWpqIJXG5SQ/SmmalFCmtWdmYGmaV4s9hergLMa6eqGYY4KK2eVAvqrXE8quyyzzTr7 LLQafhotteCZWC222Wq7LbfdevstuOGKOy655Y7rYaXmCvdjdJeq+y688co7L7312nsvvvnquy+/ /fr7L8ABCzwwwQUbfDDCCSu8MMMNO/wwxBFLPDHFFVt8McYZa7wxxx17/DHIId9rnHzuiihdmt0Z /4gybiubLPK+/MkcrFNnwdzUsdhCYMNGA9zQaVFFxkwzkzNPezPS3TqqYkg/4ZeukYvxmuxmS68k ddLMWv2k0VC3eDTMOTu1tXCIMYDZXGJ73HXWbXu7dU4x5eQ1lCuHZB3cTc913k9bTXSebN+9GmRl EJRwtWxY5eSZcXSfLLVxYgGeFFSpQWWS4VPP5dyqPZbFdrG6MZha5KsyfrfoOdqZo1CTN+Q6baTL WuTiADau8k8kv4zs3yEF7rhupcdKKqipvgWd7FjPTZnUDK7eLkOwS5hT4lwtH6bUoIvNudvdM0ly iVSfB/yJ1469svknHqjSmrFaNXicNLdfoN3pK/+W8tTzmx16+VR7ylRdCMCfuvSNQKDbHETwhywS jcd+NstMys4zEv2pinshAkn9EvAS/RSvahYSFZ3cF8LdbBBnRSqhCDP1KbUxjyUPFFEEDRO6+cHI I8Q7IAqNlCXv8XA4ZGsJfjiopdPZD1PCueDX3iJBIEKEKTlsGaWCRqHc1IVCNDxUoZiyxFQ5kWi8 Cx5MAhgmGHjEOqDjUqr0Y7MqduqKihkT914nwy1+bUyIIYHQjGRFEBJJQJwCI2ToiJrhoC1MrqnI ChKYRSmGSlWiKVMTjfemLRFIbatZ0x/5ZyNEKrKHnkTOD9M2HgVGzW6qCiVvwMcqqURnh1dD3az/ 0KgoG6KuKWyBHm+WcktHso+WvORfSxLkylVZJ5Mq7KKQvGi8XZpvl3mkVSSTOMmUOXOYihEi9ojn Kb2xMJitBFA1Rygc6KREbWA6JiM7553mRBOC09RVC6eVE99dBIUHVKE1P6nPfe7rhfz8Z7d8lTSB ArSgBj0oQhOq0IUytKEOfShEIyrRJt0zoEUEDqDMVsiJcrSjHv3otyq6LVT+BlASUI8AyAfSlbK0 pS59YmwoZ8CZ8jKT57RnYAoEmQy5aVdvxNPuXCrUoRIVpOzCpSbfQ0GLuFGOJeOKchg4Hfp4kaBF vSpWs8rQRd2QpsiUlAshwh03cbVIPBUromTY/1OnBlWrbn0rXOMq17nSta52vSte86rXvfK1r379 K2ADK9jBErawhj0sYhOr2MUytrGO/aQ/5yVLZ6nyqdcxJf6Oqk0PmnKVzZLARYXzkHw2ZbLAMS2T nBkS0pY2PqQspYFYC89ooRZehcHmY0EWWZiRDUwkjRo2/+I/I37rt74hiGz/NzRVNbU/wq1Q+uL2 rtrGqzDJzW22bNIY6iULUDAdTFL8iZmnXadNXuHQXOC3kvI80Giseu41gQo09ZmSO5WdjnUSlaT7 jsdyremT3woEG/C2DFhYi2kNDxyoK+FUhmGSzYBnItNk5rGQu61blEiY0z3VkkbDZZpnF0mbNP/B Nys3zSlpKAPhQlUvjfIVkX7UZlXsfsufceQwqzQrtAgF68ZMo6op06fezLwIncBkGkqnNeP+pYpQ JF2rjFQwXw/zZkho1DFWHIXlKcOwl79Urk9xrKD4URhqDIoObkGcpvMYYAa4yso8DdQYshlTWsg0 1jOlQtohi/lDZB4TlyAl1fUJmMbksnEnnTpBPq7KNTbxkoDwkzI2YnFVr53lkbTLEC0Ta8hQftRm W/VhTVOZN3FOE35291sry4/RIM7yB3/JKC5jOku1gvFsyVTrtHaaaJx+2a2Hp7eaoTUr50nM0sip 4TKnE4G87Kl6yxpFF/curLJ2sBzbamiEUbf/YhudK3LFue13fbs34R53xNDFMc1qW6ujFTe6tcVu Wu9NwfG+N77zre9987vf/v43wAMu8IETvOAGPzjCE67whTO84Q5/OMQjLvGJU7ziFr84xjOu8Y1z vOMe/zjIQy7ykZO85CY/OcpTrvKVs7zlLn85zGMu85nTvOY2vznOc67znfO85z7/OdCDLvShE73o Rj860pOu9KUzvelOfzrUoy71qVO96la/OtazrvWtc73rXv862MMu9rGTvexmPzva0672tbPdXh0A gQU6C4AMcIBj00HOeDwgnPEcVO5+B8DC7/71DfwdPRfImOCHgx4KBIfvBi18ZwMvHa9nQD4Z/9gA BiowEQx8wEvoycDFEr93+WDgN44vKORNKfnocB0E47FA6XlTAQqMJ/YTE33jDQQC35weoL3/OO6t HnfpWEA4GBiP5m8/eeLYrfi8+T0/od/x4FN9+NHZAHE6MB3G96YCG7iA9SlwgQ0kXzjeB390xE/+ 4XSg89a/AAg6MBHq8377td+N9LNy/vDDPwT0CgEIXADxjV/5KUn+zcv+pV//IccHVB4AUIAH1B21 JGBIqF8BDkcIaIADAoAFeMAHDAcFPuAC1h/rYZ0GTMfuMSAHagAHyN9mdIAAyt0FuKBuwKDfzSBv cADt2Q3oBQD99QbfeZ50YN9mHOBECKEpZf8ADU7EDobEBTbFB0zHB25GBUgH903EBprS4SWJEQZH FEaH8/WG9QHAFDYFEvLgEjbF5M2egVzAF4ZED+6G60WH3jWFDcpgGraE4J2gKVnAEzrFGa6MEu5G E15h1VUh8VULG0IeBfxhQyxi4TXiXHBA4cVgCSqe4IXAeMShU3RhE/6dJE6EJkYHJzrFJ4aEboyh /zUEHxYeETLfDw5HKwKABvTGLNZiU5yi3IWiGtLhynCfJQJAClKhFTYFJIKiI/qgdLyh3OFiVuhi Z/GiU1jiFlrdLJIhtZwhBUggFJ6iM6qENnJjS3yAN07jdNRhS1RAFi4fJrJjAOhiMh4g4Un/RwYk YwCc4TcGwCyWYVPMIQrOhT/S4kQEpDSqRDBiIyy645KMoThmBSWCYVPMIynaIz524ng0ZABgAA1O h+09o3Ss4hFuH0Y2BDlORz42xOKNZAAcI0K2hETCIUWa5FxQI9aNIQDk4bJcoz0+okyqhE7uBiJG x0nOYimaYhfqxu8dZEuqRP69JDrqxkvm4yfiZABoHxhKB1UGJQcypUI2xUNWIN6lnnxkhVVGx06W ZUjkoVP2RlT2IlbqxiiC5VzcYkv8pG5opUDq4XSo5EQQZURKx1NuRls6RSuepNQd5ZLE5QP+xieC ZAAopiES4kduXiLyximGZVcyY0hU4/xR/59WDiNvBGRHamVRCkQrFl8TBmZDjOEFfmJpLotYjqVD FuNcMGQ6SgdoyqF0dKRATMcrbsYsqmZDfOVWqgRkMuZkcmV05KZT4OVtLudviKZTSORvUh1i9mbh tUQw8qVTECdnbudveOdEBKNjboZmYuYlTkQHnCIFpKH0IWHubaZKBCQ/CoRW1t1L8mYABCRzEic9 gkB5NklsogdwSgdn+qR0GCZ8AoeB6qVZiuEyWmR05CF4+oZ4KqcTPl9XLqjpRceBNgR1Yt1B6qeE +p2DoiKDumMsZoXoreiJAl5CpqdKrCMAiKP0DSiBqsQYpuEGhmETliJpNqfcZcAHUGV8yv9ok2Rh dQoEM4YhhuIoinYmks4FWgLAE2ZhfWLnlCJlV7ooSnYplHalQMRlgErdSwLAko4emG5pEaqomHJp enqplEapmrJpAJwpAKDjjYYpkgZpQygmSDKjOO5ogd4gklxnO4ZEeeIlVfIpksopSdImiDaoW9Ip EK6ppc5F8DlqpgrE8YUEiR4mpLYppsJoh8bpm5IqnY6qMtop/q0oXi5mq04pq/IGM5ah9ZVi+DUE ffpG+wXiJsZopzKJYpqqQHwiX9YqnA7rXCChMzpniRrrpT5qqr6otT7JpwJAqEadfzppomZqhfYG M36ndHAnFFKqQCChuVJmtb5quwqETQL/QLFKq0CEK5NkoUAQZ3kS5wei5YcGBwcEonBq6LsiSUDG obPOZLkKaMG2BLLC68KaY3Ssq0qM67W6K7hGrJO4KtRpZkGmaFcW66kqqiiy6nQ4ZrbK6m7YJHoy 63yqXkscp5Og5e7lalNsIOPhq1N0QAh8X2TORcrS67RybJIE4wc26WbI7JIoq8jSZVaILAmS7JMO Lb0qLcMKbdUF7dwZ6Vyoo/TZJTECZl1Ox07a5zm2BEFyrUDQaMtibVNoLf1d47Y6rNg6BTPmZ1Mo pr2CY2XeZd+CLNEmyScG7W7IbW98omoq637So6RmBdh27dle7LIKreFaZt2i3TVu5rpW/0DmkiIg bl+WkuQp/us9gm5WlCS6viw9OqJSuizGum5LxCubZm6aNgQGrONrNgSwkm4AtO7ANkQ5ziVHfqvb NkmsRkeZNgXtAi3uVmrxbobsWuluaGPoMunoRivVEuZ41K6nNi/bBSSOWkDy8qRYzu3xyp35QqOB nGnbAgewFi9L/h3Fokcyau3P3qxYtqew8qmtogdzdq36dpZKKm5V+m/3xea2QuoPxq/fcScBN90G RK/dUAD3NieNtqHaPuIFywcOAqUEe+6sPu/kinDe5iiVtq6BUMD4toR//m66nmxvoLB8+OGhcirs 6u505O4Jg+IKP7Bm6rAF36DaKnC73v/hLq6wlt6w1vXsBRxkE28AEndfADahBRAgcVTAFIOhFQ9H wL5f/BlMBXReFlYxFCPg943x+M3txISxB6BxGVNLsWZw12ZxSJBx2WYLG7txFLcdH/fQw/YxIENc MP5vIBcywIWAC3JuTxoyIwsc+A5hI0dywB2vC0uyJV8yJmeyJm8yJ3eyJ38yKIeyKI8yKZeyKZ8y KqeyKq8yK7eyK78yLMeyLM8yLdeyLd8yLueyLu8yL/eyL/8yMAezMA8zMRezMR8zMiezMi8zMzez Mz8zNEezNE8zNVezNV8zNmezNq+yjjVQPSmTPnXzVImPnHUKfxHauYTWb4CPOgfHOc//x3BtGX3Z TV+8Mz35S7cVDTi7c2e5hj1jW58BCb2BWPhAU4aliomcWag1Vrkd2UI19CvhyD0X2HDN06Vli3Hx hiAti9VYdOdI9JEYV0dHx0VHVN5gm3HNE0hfFBKZGjyL0kS3zGmQV241dD5/EkQLjy3dhua01pdx S0bvxkYry9aEhk6rCU9/0W4U9ZutVG819W8dtZcV0ZQMNEYYhE0LAFYfyfg0G1EZRztj1EFzxgjE x0urk47oRpxJB56hhxkRjXdptQiktZaMEp6MR5qZkPnwDXAw9U+LyAmY9WrxWn/JhAHMNZqtNdgQ NH4x9kKrjDcv9VjjBV+v81hD14ed/5MJuXXQoAdsKHaHvVJjG5los3WBlHVkb4bRoPY4S3Z0DVtP b0ZlIwly6UB8XApByM1B5/Z6JUuybZhLKXReC0dWYxt8fVoHOYWFtdM52RRct4VrnNhiIHc3KfdY 65dvWI1xmAxNQxGZgVWQTNFl49OmTApXDHWhRNh4x7bKCAV2F0dn4c1BbzetLfd3UDdL2Hdq6LeR Nbd5YxCJJbWdAXhpfBhk24192U1+AfQR+RJeF0hfbNRLRPhxtE9Lt5RwK0txx9hHXHjLWFOC4NbS PMiQwZRS77S96RC8fYX5vHcq1deK79b+jDgfmfiJn4+JXAh6v7iqwbia9fV6H7h8sP9WiGeFh6dQ kRsbmqUXgdA4qph4desKlOfZZRnItZCUi4vWeYFYTFjXlRSSl1uLXFi4Rww3R4G1gdP2ZD93kmXQ Zii01CzVN68QsVBGPg3aWe9GQyM3+0hZqWl5iCGFnDs0e6O4KynHjk/SmAFSmn9NmjmAn1M0fIe1 QRcZbaCPXMC5GuXIkqPToPPZgBN6lBc6qTFZ6qT4WkR62dgFaI+HRrT6dFjFb6P6YRU3nvFEc+2H ZLyFk78PcOsaoS8Nn+S6nl+2dNVNPQe5s1XKg/R6z3gRKjk7jl30sXdHj7dztVdIbYi0sp/Wru/a OH27iYn7AGUYibM5rYnUqN/48GT/yW9lu/q8VomRN6xLx6t3llV0dZgx9JrTuXldW4hJeu8ECXgz xLyXupwUm61U2o+b23if2tfsWLcTG0BT2oLlCqGzu6cUvKLNhbTRW0ZDPJHN2cQHtalnGyQBPK/P TqOw/J9FSnnXOZKlu1d5tahRPMljO8uMPK0FEfPYD0T/GNXQ98mo1GDZus23OpHbB9W0+pioVmfg 0bR1tkDfdayveNBcVL3jj8l/DQtwttWbNmlXG2zDmXyMSaJjUKzjUcD/ucMbCNfLHbJNvJIXNFp/ E9m3tlOl9pE5fYHcOs0z277juIHfUu7QfV2jR0nLtF1vRtD3NhPx/TY3xYVNvuXb/0vlX77mx0vm b77nfz7oh77ojz7pl77pnz7qp77qrz7rt77rvz7sg35cL/bErDu33HS8nNE+O4tILQtBpIxKuxnt J0m1JwSlx36z4f7C2D60ZIjyT1fNZzxtRX92T3xHSHRiPD/hr4pYsMXiI791t1vtUzlGo8ju94v2 c835M3qVaXWfpP1+HQm8ez/4n/pgz/5b27s4hdPf27x4AMQCBgEIFgwwQAAAhQAEGjTo4MFChgMd EoQQYaHAAgAMHKj4MYACiQ0NIgRAIMDGhQ1AGlQpEaVJlC9PgoQ4kmLLghcBTEi5sGNBkQqDVrwJ 06FMgkoPJkTZtCZNlh95KmQpgf+jR50FmTJdmjBjzp8Sa+q8+ZQgTaIHugroiFUhggRfcbokWxYu Wq4JfW71+xdwYMGDCRc2fBhxYsWLGTd2/Bjy4qFTQwLVyhQuZZNF08adC7Wo14Ibi2bem7Wgabqc x5KsXJbgZKGWt8KVSxe2SYVoZW8VeRs37N6dJ86G3bJqT4sY1xK0/Xks2qOandJ92nYhb6sGhw9F /Rf7U9WgtcYGAHzrRvSpFfaFeh3sbQglAozfXL7y+rwf1UOP/B/AAAUckMACDTwQQQH7c+im0Kqr jDX+vuPuvLlE66wokSKsSEP8JFyPoJumWvChiDY0CC73dsIIvuLsOpFC9ExyrTP/4EgsEQDKQOJJ xwB4dChF59rj8LvwrKOLxp+KujFEEz1syUgInyQSxI8uFFK5I6FKskO/fvOPJxVXzDLBMs08E800 1VyTzcFM6hHDyx58bSEQb0qyoitJK887zz7qs8KkwLpLIrnelBDGAO4Ua7aG9JwQpC9P0ytOqAgt 1L+KeKI0TCCHtCmi5t7TMsoXPTq0oj0BKxXQKvPLlCqMxMTSvVIpxPTPQPc6EdU2ff0V2GCFXROu S+sqs1cUi5yzpEGLW3SrR3l1Fk9LFXI0ITjzzPYjrBKFlkhsj6tUJ0m1NBUqbQPb1KFOlc3yKIl8 6nLUem2tNFn2EhW0rCutdfFV/7/c9ZTMe7c9NuCCIJo2x2EdfhjiiCWeGDAmFXXySBE1lZXcGC3k 1qEuNW6X45ENcpdeHBuyuMEp2SNzzBYpVdLl2WRkltyUFY6o2phJhrm+IcHdedl+HzRY1Z/sxBi8 o6szeUz3zNUpX1onPbfJhn+WWte/BqYY7LDFHptsAFUi6SUHy+KJM7hcO5sintCDG8vv2C7P7bgx avvanFTijG7i0KZNp+dwQ0vamjtOfDRRW2N043G/DjpLlSiLV22ZScWZ5sa1HgtSqp1ee2+8+258 38arDHLzcX0s/eW3IbX8Q1jLvh333HW/XbeGk74Q0Fmzzg4kmlDy1sPgIyVL+P+LJYKxd5aS3ipe gLHuuKViBWIcR8IFZnFrglWk6TZUo0Q69OSk7zra0SlVviLtIcdxZtbt5dy4hYSXfyw4J98dgAEU 4AAJWEADHtAwU2vU/H5lkub96iYPROAEKVhBC14Qgxl0TFXcY7iILUxxa4qgBklYQhOeEIUpBCD8 wLYRCaYJIa5S4QxpWEMb3hCHOdThDnnYQx/+EIhBFOIQiVhEIx4RiUlU4hKZ2EQnPhGKUZTiFKlY RSteEYtZ1OIWudhFL34RjGEU4xjJWEYznhGNaVTjGtmYoOkR5o2K8VeBkHcrY+mPcnes02cAdakX Dm87LenTzCqWpTk+8ZByFID/DNvYyCAqcDFxFIwkEZNIAdUxf3r0SbH0qKs+EuqFySELa3pHFkYa 5QGcseTEINlA/DVmhI6U5RBbmRhKFjJ1YcOkeU6pE4t57DAzEstNgGOS9RjTdtvKZdlq2aZVJiaW s5SmYTrlnQgh5C17JFpYrEQtBlYvSUqRil3IohdwMjA5Ggkdcpgzkd9x7p3Z9IyRxhmrlQRtmbtM GBzZF7J+CmZozhvchthFvYhQSjSlrJZCGcW9bZ7OL2oZV5961k2EEYmbzYrKOvfpvIwe7I/TFOnP Avka6vhpPoLLyVDQYp+EsCZwr0HcoLTzuY7GlKW3oow1Q2jS/GUuVUULVEqx/7Mb4+ioO94rHKQ+ eRdC1iiZdLrUU4NKKL2IBE9VCyqIMFPS+7zspKqE54RwalQvsc+DuqEqlsKKn7SCZaZlgeQuy+o6 pUV1pHkdUzhBJkyH/HJkOqsdKrXmV3TxEjqAjciI+tmy9DSWadwz7NW2xKiksYxptWFqJ+0KVUHq ca2nIRRwApq1itZLo08RLJFSxz3F2nR56LGfzz6butkux2hlgVpB70pY/3FMr8G1p/AkdaFSXgo4 rcrUcUf7MddNz1zMvYuhQPZXjp5GW+98btFmhr6gaPWWnmJNMyP6T5vh9bHblav16KKuqB2sptrE qHxTG9TvOgu56DVXac1zWv/lMohn88PqQLziLpNJ15TLra5we8jJO55WQP8LmHEXvCpvpqtp2+VM dCtsUW3p82Af5q595eQ6756qw/jsqYqBWZhfntcw/IWWJHm7I+DW92Af1WhGGadVwew3wLmCsGhP x9/KiEsvdbyRj6GUYgbnlSd8ze3MVrsoqOG2L1UOskOnpuXiYPa6qsuUYzHsT6DyS3PWXRJkw6ys 8Zr3Ly9G7GFUMjPaQeWYCell1ZRy5dcpx8/uqhq9vAzhqd32z1QNNHARXVDgMYQEoSs0oyT85JEm 5ylHiSsh/1aewN0tdn5zXOAc+sZOe052LkpbTwO3alRTpFhnxnGpS+pqv+j/s6l3qZacO8pPY+kI wb30LI5BjSWSFJtyqSZJrD09aoj6ElJvNSs7J5S3lxUTrpR9KKedzd7eWprBm4qXlBUdKsf5U16g ep6HHJpH11QPeoNa3zKtNW8PGY/FqKVsu/+8HV67GT+5Jsuu4dzrwlSPkYME6EHRjG485irdEiIe iOG94pcB7Jw/Zp66daxv3LrXo+c+2Y3BHdwal7wwrRxwEx2I8o9E0+VQBl/MC8PBa6OXiCCkedZC unM1ntzngWFhFF1I8xjiPOhJV/rSmd50pz8d6lGX+tSpXnWrXx3rWdf61rneda9/HexhF/vYyV52 s58d7WlX+9rZ3na3v/3q/8/0ldzNBHTdaTe0JAxvJZklgZt1Fu6BPxPdf2j33O19hohvzNQIL3jH A6jxPTQ87hSfwspLpmuRf/zmG2OSEeC3n01dj0Sn3RLSHwc7n59upk4vptODfEwtaGfHX1/VuwA7 IapPMGCqRxQRjJg4TrX9xq/XueCX07pWHb5EetR7jvw+UW9E9p99Ik7hex70wub89g2jGxUR8zP5 QuawcbtWJvG2qN+PCLath6ofqTmEVXmf3TACp6S9/7Dex5GwT37qep1/5ipLo6bCtdiHtwAQNvAP dbSi/0QORy7H3CCwsOaE8cBC/QqO+zKQMKpG8eilWGAvfu6pyXLL/r6DvP+cR11WjtoIacD8rL8Y wAWPjMA6DPFckF66qqRyZc/GqjREECQ+sCVisAUXK1f25SJ6cAFkIAJ6kP204+9KkN40UApH0M6i zVhYQ5RykNrIAvemjMQEioGCw1hOScL6A8Ew5Qy1id/gq1uAD7e4kGggrN2yELb6jfmIbAwTwF9A LFxgMCLmpWFa7lwqUMMsbgoPseHgjzjgZLV2rOdEqy9ObM7E6wCMDDCAzsqCzCw0UXQK0aC8De86 MUtaqY44sM30bwQBjRPVDU8Qz4GwoiHCZCNcwysIsQqjEBFzkXFKy//mKsx88cy4J8rE4v2GMflC iTnEhF6MkZz6ghk9JxL/ebCnFJByzgwYGRAjaOT9wG/kTLCfMOkacStJVMIZ649gcgkrXiAGyMTW BjHzpDEX4zHDbrHEdC3SyMTB6OsH82vf4NFzRuneLmXIeMIFZq/0ju+iQGfgcmINl8eUTMAN89FP yAkgu2ckIo1vmutdVi/5dI1R+ggBIDKXpmPHEGpOOIklaO046oyc8k4eXxImY1ImZ5Ima9ImbxIn c1Ind5Ine9InfxIog1Ioh5Ioi9IojxIpk1Ipl5Ipm9IpnxIqo1Iqp5IqpUnzCAPXOAtoQm4iN/Eu HjFsJg9irlJAyLKF2qwTXdJAzLIqJ8gWCSQrOUtFBO6fJPL2BEgsH4Yt/4UOA7XtgCrvLZ3pldoy hQLzkjZL+8xjK53n77zN2MJQbPLSYfYSME5Q79ByEj0OhgaTMEtIomKiOvDt5czNMdvwzRLT4NSt tQQABKkPdDZMqR6KvTqlHXmqG1HCNkczIbHpAIpFhgJq/IgmJUMTKRzy2aAN+XjTN/UQZ9Qn38Zk OyiONPlKnrom4+ypbxDvM0dFNAmr4/ziOo+kOwEM+eqrniInOkMnPI3yKIYMMghx2objcYwj7+IS tCxyMd9FLS+xncqRcDxoPhUTLZLDP0XFgzDtqMjJNXIKN+SDPqhtfIhHzKylpnRE2gCvxSzFQVEr qRynQ8nq2RhUQ+cipf8CVKZ06qdWDD6FIwfryiVVgv3UJj5bdNpIMjgqFEUVE0QBRkSHcjsPhBDH UVdeC/bs846eqqkidCulC8KokRpZh0g/7md6hHWesb3ITziRBDKtC9sMAAV0RdASQkiBo9EC8LP+ jtyw1HnWbGm+I0oF0C6qZGTAbJmC1LKG9J9icAGpxLnG9DMQ7QbF9E7ZdMyY5k19VPiA9B09MQ27 0jQDri8DAy7WzMRArzRp673epfosdfdObnKqlOTOq1EDhfCYQiQIwFQ/ZxdXcYF8Y1G7qzrACzVk 9b46qXxwZlSpqw6Nz1X/jh7/hR9ZcUsbEpBkbU9pFcVsFelwsj23NDL/DPNYnQwwsjIxwwtavsor m9RMXVNTy2wrPDVUQXUxv4TJcExSK+QibgMr5GJdoWNVHVMFz9RdOUcptKoUU+xed5UNB9Av7BUz 96nHpBU8WXVfD8v5ANFY8QVfZ1VgO/NZX/ULpYSwTotalxVbQ1BVwaKirE0nwBVoWGfSEi18uvXP fmu9NuRaOXN5GuBUswYGGM4vyaVMMTQzr4Qp6FQrcNY8UHbLOCdkdfasfDViQ9b01qm44LG0yKwA 2zRD1skSHdYwpkclAec4H9WO9IgknC9RN1KPWtNjxcR+/C9Av1Z83lC3QkUvxJbUVBY7ZUvHHOpC X3RCbHZO7uw1m+1z/9pRbSHKX/YWYFotNotnbv1xLKj2Ul8Nt5owYu0Wc0rsVxfxHw3XcN0TagVD fvit4qZ1szirFbcWOe9QMMiWZGUzQkT3ZfxzAuLlN0nzmthW4swps4ovjtbz1sKCbiWnndYHRJwT zGLzkDLXovztX92NATCXdQ0RkMal3cjHuQiQcM1Wdwt13SqXenFH5VzkeilXr7LXWavXe8nG5rAE PcKXclBTr8gXQL9XfQVo6BzuU5qufddXfueXfuvXfu8Xf/NXf/eXf/vXf/8XgANYgAeYgAvYgA8Y gaXI7+aVZhPDLjVyhhZYMHoHLM2ELtmLMg1DghN4JqGVQP4NhSzzAf8v70xaKV5a00BEmIM10IMH BIRPSIXjhBuHhbzsVk1ieIU3bzuxjyMpEg4nybyw6fd8UPQYWPdw5R/LE7dOAPSEVPl2ZYit4keX KreoM4rz9lIYMVh7Fa8C1WgM4Iopo/Y6kvim+PT0QohB94xzGI1KyXwxrzEvEDiokVfLy1Uu9ko1 iv1gZoYRcECZY/7UhkaU9qWeRIWTZT80qnTNURG9lS6E7QTJsXUWuQ61i0Z6xU5xRG0ixI/Z2Iym uEAIEQo9QggPN05tp1xZq8RGuW5Azu5WzoR7dldFeIahkV8fcHkMDTMj+VOwo/mIUMgGQoS7LE9l GU6A0JPXyI2XdfH/IFYRc3VZX2yOHjhh65gOdaQMK8TIjtauRPj0pvd6oPni7iKXyIuQvXDH7kgu nhbGwFAHneuprjmZs66FVYWdA0Oax6oOvfhxQQIVMTHIYrk4/MUyE/lgFFdlnNWGd7anyGs47uWe DQ4cu0agkczC3neep66e6Y+9JLmQ7hhneFFUuCcc+00Zi2aQIwt/TtBKCcaif8aJfUKkd/mfomfW OKelPdpK8S+TiaaaSzqjpw4lNdPUBLJ7J7Rg8TAj7jEaPbFudg+3WOCJfbg4iy+PdrWWBTcQX+n0 aNFSF4Cpz6pr93WOuvpOydmtQFchq1ozrxqJgxqBJROu5zrt5Jqu/++a7Owar/ear/var/8asANb sAebsAvbsA8bsRNbsRebsRvbsR8bsTOY90gzUgWzgRND4BbKdSG7r1v4P+jyjZGFAiubLzvpkjf7 PUn7s1Wbs7nPs1N7MbNaYnD4L5ppUpFXQGg7tUO7tQVvh4lTQr2zauV1MGhXNk/bqZVzj6yvnAz6 sIjbn/Us/JymOtHDuJM31dhaqqizN+mr99LWc6+7t8GtWRNkRXEUcQV0YCMOORe09GB0ut1wT0fU R+ijFrsmjiotQyWuqVtkqB7URckpRvkErSZSrURrQ6Njm5CKfQJ8vFEOlAmkp5H6UMX6K0/Zt7Bn ziRLUBNxn4Ymlf8z83Vbx08zvI4n8dAwuvy0tGzNjMDnppj19cHzKsIHZKNrVY94G0twXJ0T4J45 vFJZNM8+J17LBQOHor/DmVMxJaKBDF4H2nUbt53FecYtrbwR5MaTFYURpWYWJcR/3B9v1wkzJUj4 MLaiSm7iO82wa72HzMmrZeWu5GAldhJDvMrfLssZemLDEI/fZSp+1mhJtcP4uWBbST1WIFSNXIZu ux9dB9A3xFxSfCsdLaRZlcz2iWjvnO2klnD9FsK0VokLF2+VTW/wG6KYrfi8gpK8Y8ulyliQe83J aXJFzUXSfL7FN75zQ58l0Nlgqtu0V9PB7nKflytxESEBD3iFu7P/8A2TxHwjkRvYBU5dDIZ0XaZ6 CIl/sLuhuBpXEPmjkj3Yg71dw53cz8jMyx3dtUj+0p3d293d3x3e413e553e693e7x3f813f953f +93f/x3go+6CVTzgJXtNVsngSSjh2W7g87O1dbt9LltYXttc3ZK15zHlLj7sIH68OZ4KyYbiTcjj V1vHvU6FV519aFe54wIHDlLDKWrbN8oHyfM7vVK7obNhmt0tursrxfu6Gaqq8o65tfBqKXflrXM6 v4myCQnojRODgZvoJU67Yf6iZ+Lmk3clOUqBxJuMjWrolZdZmn6yEzKT0vQ809l6fru6oeO7E/Hr daTGg65PjN3I/ztpzCkxvU+0QUmUPvL7xuKWyNBbpeizvGDDRhVzpwhHNxLcwQdfvdnqNHy9gXtH 8Ms314U+Pvje8fWeOKQjVCjDpaxQVw78RhM0aP0D8CN+Rm2KJYcn8UGErkLU5d858E2/XkI/l+B7 NUxn9LOt9BEfrCIfUhuT8Wv08xt99Rm85PUqH4G97u8za7A5AN90skyLIatrZltESAnVxPdxK+kF aKv/23B5/LOUzhlD/JMm+yO+xMlzKgDVG22L4Cm9o2nabSd9Ww+m/eG/KHZr+gECAIIEAQoadPAA QAODDBsqEEiw4AABABYwaFgAokSKBAo+NHCgociRATKCFPlwYP8ACQAATBAJIQKAjgEmVrzI0GTI AB93kvSocePNhixdogRwsiZHoRYxIvWZMuLPqVSrWr2KNavWrVy7Xn3Y8qnXoyqvxjQaAKFCgzbD unWr0ibNhjYXAm2aNiFeh0PlitSp9K3goFfVtjxZdyTgwHOFDoaboO3jlmXBhi3r1a/Tk2r3Mnzo WaRmthQnU5ba0LBYoJBT68XJt+log4unRi3YGfbnoT9nF6wtUnXSAGdf5l3r2DRmkreFNv69erTl 01ZzT7V+VPbSzVDfLjfYnHH1hId3avZdcjVPwmPbu38PP778+VrDW2V5MiPmxFXRFyz6En4+YRfb RegBxh9XqoX/9VJPgdlFVHTbkYbcVAliJRlvWh0oFoG7hUbXhEJBeB15bjWoHkMZNuUheH2JCN1w PzXX4l26iQZjekkt2BKKMgqY3n4UkchVeBwm5d+KNzJUI5OvjQSagTkCR2FYexmZI49GOShelzmp Zx99Yo5JZplmvhdmVaCRkOJ6MuL2pH/QIbCCTMYZBCBMMtF05E5cOqmha4Eel5R+qBFqXo5/HvTk onDepBaRxNnJVZ//9ajnTFSh5+hxFrWoFmcJSVrcpWgxdBafU7YJJWF5NpTqpquKOmioPt3F5pud NrmbkJpy59xxpFL6E5XrqfQqqnsGC2ykmd6J5a+M1poQkttZ/wrUd2duy2233s43nWmeqfYcdOpl xJucrFXIUFFltTUXtumd2xKIX1YonE/oQoiuhNLeOxy6e6EbcL04nTVcUQO3VC6O/8bok7sRwdtf jvMWzNu+05ZXEMIRG4wndYFJK2+xKUrsWMMhPqzjTho/yjGgDCsW87z2Asvsl9b+6nHIg/4F8qSu ikxxzrSt1rOpCw/HIb4m7qwqy7UZ+23VVl+NtYumWXnjWZLKXLPRDt98HNcrl0vlgm9O1a9GFwrd 0kKGig02qzCHvduJQLPsMNptLkj22T+pfevRlxH0drh3Cmq2irMWTlJRGgK+JEkltx3XkJl+vTHe VEluEba+Kf+e1YIqUy44zlozOBLoDMiJOeKad1my61nfjnvuul/Nkra7j5VmlL8PT3zxxh+PfPLK L898887LB+TzZsl0KsrSX4999tpvz3333n/v/Vl8g78upuSfj3766q/Pfvvuvw9//PLPT3/99t+P f/76789///7/D8AACnCABCygAQ+IwAQqcIEMbKADHwjBCEpwghSsoAUviMEManCDHOygBz8IwhCK cIQkLKEJT4jCFKpwhSxsoQtfCMMYNi9cg/Gd5ASzNho+BlpbY08LJeC795znWhaD1bIcSDWRAPFQ 7ZlIRxDCOdVpT13uGeL4ZNjANM3rVFuUkfiWo0Xm+NBcXFz/YRjpY0WVKeuKBkxir5gIPLsUIHBH W1sA04hFCobRJngBSxTVgpkzkgWOgaHjCAUpHzxSJVZItBtfgqig18yNKm70nyLzGME9UqQpRYni jMb4ySDysXKGE4zfBtMY0QnAACJwC7926JTBeNIgZzlBadwSmra5JZWrbGVYGqDL8QEnaR2jlCKp WEwAtIB6uLxRMONmlVreMiwEEJ/e7mVKCknqQs9kV9ncwkpHkpGapXyLGrGipXAiZpM3clZgRjBN ka3OO1KRpimtyTqjdXNx66mhVPA4SkHNEpP40yJYCmW+rOgwmy7y3UEh96XlMLKQurEV3RZjkzcF VJvJlFQl/+H2HC5t9FE7yyEopwUh1aR0VMy65E/EF1KkycSj4kymjNC1HIyyE1BJSZaNOgq0pEzU XHZ85D93Oq2iRvOIhhMqU+c0sdIsDpBR9aZNykLMeeXUX1HzDH/edtWqRo0mQw0SIQmqv4U203D8 tAoi8yYuUvrMm0YNTpweN6JBloiuP33pU13UlDRZ523ZOmsxe1oRGUQAse8i4q+QKbSGRcmd2ZFr ZI34sFcJ9klmreNOKFsg0LpIqQ2VymZ/Nh6+/il6K1EPYT/qpp2Utayv0sxbPwm1nLGWtWj9322F NksHqOBWvz2WYacnmJWi9jaqfBivkjMZSAqtrWZtEnMt9v/WySYERQuxyZ2OWcQ1UtdQGXqMdGdL LJ+9xLpBcWepoGveyFiMt2IsC3ul25v5pui6/6rdZJz6sPeqN1jPbdd/E/VYEfH3nL0t6Elpxlet 8RC/b0SjVAtr1xfRVacsS5OACrzIv3rqIqfVDt/e6l2WNKU4GdkLeNmYzHLlBsRTQW8ZNTtGAsll NiCuEWzDU2LLDo6zOrtVpESLrZftBsDPEbCpjGPbMQJJyaNF8FgB1QDRNrh/xd0iF8Uno+J2Wa8G 3tm4qvXZhEhUJrnFrGe8lsxcJpQk4uOnSJFKUiu3isKtfUEMTtUvGb2YwXCzs0wHhS7qrrHJ6X0y UyqKZiP/GiAFgzqLnNECZwPXFMOP5ilEkUukorzpLB7woaVaRDDZ/tXJrUWLZiytGzijOmYuFVqp +bxl+o3Zy4Jpq1rf0scHX+WGrcGmORmHy1zpGcJveVM3DXkWFqBybwylW6uhuVd2FY1CV/aSXwHg AmaSM5aCgfaqG93qxXVTZTgl5LNvREMEmGDT167QutEkGHmzStSQa2652YTpc9/YfLN5JtPiWS+A Q9mx5eJ3rh9OwbJC/IOQvWN4J45xA0o84xt8yEAF6HGOi1yBGx/5BG9I6P+h3OQsb7nLXw7zmMt8 5jSvuc1vjvOc63znPO+5z3/ObWuDbzFRmiTQj450oNca/2u7puRqii7spEt96i9f+tWazjYwydGQ VO+612HIo+csfTo3Q12Gd2nsmXUOtXC7CdGNU4CPf33udDchuuZiGAhd0nrb1mpVMYZ38pDIPgKD DVga48fVkbbujG/8CX0KlDZrBvKXbZleKf+n8BgdpVAV1OIdD/rQkzBfLV0Kez9FZHQ+rTuN7eFA CGt50ct+9h7Uko+W7ZfTM6DHJmJd5oMC+5V9jb60L77xIQiqSNNuO5RnpLGiknwwEWZXT9o8oo6P /ew3UMmkX760+F6axhQ+mWXh/uo9CzB9Bc1mOAn0p7UP//j7L3YPKr1ze1/23jeM/hey3d0cKRly Q2/yR/+ABWiAB4iACaiAC8iADeiADwiBESiBE0iBFWiBF4iBGaiBG8iBHeiBHwiCISiCI0iCJWiC J4iCKaiCK8iCLfgtJZc8FTcmv6Z2fNFDioZPZUQVNJhP3pMRipZfMLYhFycmK9cVYAFJv8Z1Qfct Mmg8E4FrLkgfMIg8TkgfPLh+/bQ1hraFbtVDc2YmWEcVCPF5fZNIRCgfiWYuKRchk8Z2WMh1Vggf ckg8agGEUkgmVDhAZ9RJFbZUNWiDAyWGVxh1lbJK72chaIg8Q9VlqVJyYeRwx0OHdbhdIVgq7qd4 EBV2mrZ/YhErllFUZicrUpMiSpI6ftE2nGNNC0F8e3b/ViN1W2E1FSxBaL81ESAhOa93iLkoFZtY ToDoi6l1OvinG6iIdiMRjKWHi4cDXUuoNTShhqo3FJRnXEGIX3iUilohiuLRNsN4bI6zjPK0iq31 JtvoODqogdZkHNaEWIRxdxvzSqNGLNY0F4lnOFcCiCOBLX0oFAeXYOPWT4OHbVpYhmFkGYtDg+KX j16BhfFSGioBASUwMhApkfMSeANZjYZzkRHmFNrSbv2IYDVoj2sIj0zYFhTZanpHEWU4V2DohYHE KoIUjUEYNSKJkSYDfCsZktIykhZZko6BkgGZifdoeAvZWR6YabQ0UxGCFpi3Gjo2O0ITGvxhfcKS iKSY/xSdcop4BjGd52le2EOhkZD3cocK9YUOOSgj5Wh8MRzh4ZSLVzIYppZH+Za4x5WxNRY56Izm sjiy6Ick8Y5X2VXOtGnP5zZ3OUl12WkRdSgWdZRY9iwfaGP8RI13448QIjzJRF1RUV7+RJNB1R3F do7dVmT1B5oviRof6Yr3YZRFUoh0U3Hdl5EkIZt0hm4gFpdgI3nYRU8YQhGtZxSVlIPlphuCBBZl uXSVhJt4RZvn522mCSydmW+HEnw0R2yTsZfzMZlMaRy2h5cDxlusVljVWTFYCVGm6H1+s0581Ypk pmkmxWcZhYhJWV/HxYSjeXZ683uY4Z1aKV6CQkfY0v+fXCV0VZKFq5l25ySd1TabmXKNDHeaQ8Z2 94l+3+R7BHqOwycW5KmPUcmB26lp65V61xdRdVJG9BljkQc5z0VYDqJl75Wcq2F9jrmDoNR3DVpj 1MM542cbr/mczxl9bdleI0qjluOhXVlXp0akyldrL4puESozs+Sf/TRhhBSJgnlRhRmTh2meI+Z5 y8aYX6qiGRYa4pmBIDpg86JcnmMZwzJuhqGQ9DKh5oIXkgNgCRM0MYoxr+Q5CAphMBmFWjgZKYeF GlYuTbOm9LKnnfN5VcmjZ9F66ukyA9l9S0dMCiNk7JdMwFY5M4mMygeHmZqeUIqTeAGpYhWh5hcW bRb/S3wqpxgDIlV5pgJHmXPGf0dKUc+iGkFEOFnRjeRYOKSDnz9KJeMoq+45EnXGaVoRTGVpg2Ep JSwDO63Rf41zqxw5Ld4IkFl6U9Q6O1ZXPuiYbRiJENSlh4GhEr8mdybJnFVhOqlTmuWUOcihLsbq Q72arE+Kh2PRO/YZP8Ezpw3mXSMIsNk5Lc66r1jRnvajrKYSqJhEhoiIgQ3bag97sAnrHjC1h2+B sBD3gyQorF0Bhf6KsSVrsieLsimrsivLsi3rsi8LszErszNLszVrszeLszmrszvLsz3rsz8LtEEr tENLtEVrtEeLtEmrtEvLtE3rtE8LtVErtVNLtVVrNrVXi7VZq7Vby7Vd67VfC7ZhK7ZjS7Zla7Zn i7Zpq7Zry7Zt67ZvC7dxK7dzS7d1a7d367IBAQA7 --000e0cd5cff4e3cd5304a991199a-- From wang.xuerong@zte.com.cn Wed Aug 3 00:16:45 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A545E8015 for ; Wed, 3 Aug 2011 00:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.916 X-Spam-Level: X-Spam-Status: No, score=-94.916 tagged_above=-999 required=5 tests=[AWL=0.919, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_53=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOlZyJkVgXGA for ; Wed, 3 Aug 2011 00:16:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id CDD125E8001 for ; Wed, 3 Aug 2011 00:16:43 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131321441414862; Wed, 3 Aug 2011 15:07:20 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 22013.1441414862; Wed, 3 Aug 2011 15:07:37 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id p7377bjK075956 for ; Wed, 3 Aug 2011 15:07:37 +0800 (GMT-8) (envelope-from wang.xuerong@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p7372uu5069017; Wed, 3 Aug 2011 15:02:56 +0800 (GMT-8) (envelope-from wang.xuerong@zte.com.cn) Message-Id: <201108030707.p7377bjK075956@mse01.zte.com.cn> In-Reply-To: <4E37C8C5.5000500@cttc.es> To: Ramon Casellas MIME-Version: 1.0 X-KeepSent: 34BA26A6:F5398824-482578E1:000C9655; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: wang.xuerong@zte.com.cn Date: Wed, 3 Aug 2011 15:02:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-03 15:02:57, Serialize complete at 2011-08-03 15:02:57 Content-Type: multipart/related; boundary="=_related 0026B966482578E1_=" X-MAIL: mse01.zte.com.cn p7377bjK075956 X-MSS: AUDITRELEASE@mse01.zte.com.cn Cc: pce-bounces@ietf.org, pce@ietf.org, "Margaria, Cyril \(NSN - DE/Munich\)" Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 07:16:45 -0000 This is a multipart message in MIME format. --=_related 0026B966482578E1_= Content-Type: multipart/alternative; boundary="=_alternative 0026B968482578E1_=" --=_alternative 0026B968482578E1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UmFtb24gQ2FzZWxsYXMgPHJhbW9uLmNhc2VsbGFzQGN0dGMuZXM+IA0Kt6K8/sjLOiAgcGNlLWJv dW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDgtMDIgMTc6NTINCg0KytW8/sjLDQoiTWFyZ2FyaWEsIEN5 cmlsIChOU04gLSBERS9NdW5pY2gpIiA8Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbT4NCrOty80NCnBj ZUBpZXRmLm9yZw0K1vfM4g0KUmU6IFtQY2VdIHJlcXVlc3QgdGltZXNsb3QgZm9yIGRyYWZ0LXdh bmctcGNlLWludGVyLWFzLWV4dGVudGlvbnMtMDENCg0KDQoNCg0KDQoNCkVsIDAyLzA4LzIwMTEg MTA6NDYsIE1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSBlc2NyaWJpqK46IA0KSGkg UmFtb24sIA0KIA0KRnJvbTogZXh0IFJhbW9uIENhc2VsbGFzIFttYWlsdG86cmFtb24uY2FzZWxs YXNAY3R0Yy5lc10gDQoNClRoaXMgc2hvdWxkIHNvbHZlIHRoZSBwcm9ibGVtIG1lbnRpb25lZCBl eGNlcHQgaW4gdGhlIGNhc2UgdGhlIGFsZ29yaXRobSANCnJlcXVpcmUgdG8ga25vdyB0aGUgbGlu ayBwcm9wZXJ0aWVzIGluIGJvdGggZGlyZWN0aW9uIGF0IHRoZSBzYW1lIHRpbWUsIA0KYnV0IHRo ZSBkcmFmdCBkb2VzIG5vdCBhZGRyZXNzIHRoaXMgcHJvYmxlbSBlaXRoZXIuDQogDQpJbmRlZWQs IHRoZSBwcm9ibGVtIGlzIF9iaWRpcmVjdGlvbmFsXyBMU1BzLiBUaGUgZHJhZnQgZG9lcyBhZGRy ZXNzIHRoaXMgDQpieSAiZW1iZWRkaW5nIiB0aGUgdXBzdHJlYW0gbGluayBpbiB0aGUgQlJQQyBy ZXNwb25zZS4gRm9yIHVuaWRpcmVjdGlvbmFsIA0KTFNQcywgdGhlIGV4aXN0aW5nIG1ldGhvZCB3 b3JrcyBvdXQgb2YgdGhlIGJveC4gSW4gdGhpcyBzZW5zZSwgaWYgUENFKGkpIA0KanVzdCBjb25z dHJ1Y3RzIGEgZ2VuZXJpYyBncmFwaCBwYXJzaW5nIGJvdGggb3BhcXVlIHR5cGVzLCBpdCBjYW4g anVzdCANCmFwcGx5IEJSUEMgYXMgaW4gYSBtdWx0aS1hcmVhLCBzaW5jZSBpdHMgIlRFRCIgd291 bGQgaW5jbHVkZSB0aGUgSW50ZXJBcyANCmxpbmtzIGFueXdheS4NCg0KDQpbQ3lyaWxdIElmIG9u ZSBmb2xsb3cgc3RyaWN0bHkgdGhlIHJmYywgeWVzLCBidXQgdGhlIHRleHQgY291bGQgYmUgDQpl eHRlbmRlZCAodmlhIGVycmF0YSBmb3IgZXhhbXBsZSkNCg0KW0N5cmlsXSAgOiB3ZWxsLCBmb3Ig YmlkaXJlY3Rpb25hbCBMU1AgeW91IG5lZWQgdG8gY2hlY2sgdGhlIHByb3BlcnRpZXMgaW4gDQpi b3RoIGRpcmVjdGlvbiwgYnV0IGJvdGggZGlyZWN0aW9uIGFyZSBub3QgcmVxdWlyZWQgdG8gYmUg Y2hlY2tlZCBhdCB0aGUgDQpzYW1lIHRpbWUgOiBQQ0UgKGkrMSkgY2hlY2sgdGhlIGludGVyLUFT IGxpbmsgaW4gZGlyZWN0aW9uIGkrMS0+aSAob25lIA0KZGlyZWN0aW9uKTsgUENFIChpKSBjaGVj ayB0aGUgaW50ZXItQVMgbGluayBpbiBkaXJlY3Rpb24gaS0+KGkrMSkuDQogICAgIFtYdWVyb25n IFdhbmddOklmIGV2ZXJ5IEFTQlIgb25seSBjb25uZWN0IHRvIG9uZSBBU0JSLCBQQ0UoaSsxKWFu ZCANClBDRShpKSBjYW4gY2hlY2sgdGhlIGludGVyLUFTIGxpbmsgc2VwcmF0ZWx5LkJ1dCBjb25z aWRlciBmb2xsb3dpbmcgDQpzY2VuYXJpbyx0aGVyZSBhcmUgdHdvIGludGVyLUFTIGJpLWRpcmVj dGlvbiBsaW5rcyBjb25uZWN0IHRvIA0KQVNCUjQoaS5lLixsaW5rIEEgYW5kIGxpbmsgQiksUENF MiBtdXN0IGxldCBQQ0UxIGtub3cgd2hpY2ggb2YgdGhlbSANCnNhdGlzZnkgdGhlIGNvbnN0cmFp bnRzIGluIGRpcmVjdGlvbiBpKzEtPmkuICBTaW1pbGFyIHNpdHVhdGlvbiBpcyB0aGUgDQppbnRl ci1BUyBiaS1kaXJlY3Rpb24gbGlua3MgY29ubmVjdCB0byBBU0JSNSAoVGhlcmUgYXJlIHR3byBp bnRlci1BUyANCmJpLWRpcmVjdGlvbiBsaW5rcyBjb25uZWN0IHRvIEFTQlI1LGkuZS4sbGluayBD IGFuZCBsaW5rIEQpLg0KIA0KIA0KW1JhbW9uXSBZZXMsICBnb29kIHBvaW50LiBJIHdhcyBzdGlj a2luZy9hc3N1bWluZyAgQlJQQyBhcyBpbiBjdXJyZW50IA0KUkZDNTQ0MSAobmFycm93IG1pbmRl ZCA6KSA/KSAuIEFzIHlvdSBzdGF0ZWQgQlJQQyB3b3VsZCBuZWVkIHRvIGJlIA0KZXh0ZW5kZWQg LyBjbGFyaWZpZWQgdG8gYWxsb3cgdGhpcyB1c2UgY2FzZSwgYW5kIGFzIGZhciBhcyBJIHVuZGVy c3Rvb2QsIA0KZHJhZnQtd2FuZyBjb3ZlcnMgdGhpcywgd2hlcmUgdGhlIFRFIGxpbmtzIHRoYXQg aGF2ZSBiZWVuIA0KaW5jbHVkZWQvZXhjbHVkZWQgYnkgUENFKGkrMSkgc2hvdWxkIGJlIG5vdGlm ZWQgdG8gUENFKGkpIGFzIHRoZSBkcmFmdCANCnByb3Bvc2VzLCBzaG91bGRuJ3QgdGhleT8NCg0K SW4gY2FzZSB0aGUgYWxnb3JpdGhtIHJlYWxseSBuZWVkIHRvIGNvbnNpZGVyIGJvdGggdGUtcHJv cGVydGllcyAodXBzdHJlYW0gDQphbmQgZG93bnN0cmVhbSkgIHlvdSB3b3VsZCBuZWVkIHRoZSBU RS1wcm9wZXJ0aWVzIHRvIGJlIGtub3duIGJ5IFBDRShpKS4gSSANCkN1cnJlbnRseSBkb3VidCB0 aGF0IHN1Y2ggcmVxdWlyZW1lbnQgZnJvbSBhbiBhbGdvcml0aG0gZXhpc3QsIGlmIHRoZXJlIGlz IA0KYSBleGFtcGxlIG9mIGFuIGFsZ29yaXRobSB0aGF0IHJlYWxseSByZXF1aXJlcyBpdCAod2l0 aCBCUlBDIGFuZCBEaWprc3RyYSANCkkgdGhpbmsgbm90KSwgaXRzIHdlbGNvbWVkLg0KW1JhbW9u XSBHb29kIHBvaW50IHRvby4gRXZlbiBpbiBpbnRyYS1kb21haW4gY2FzZSwgd2l0aG91dCBleHRy YSANCmFzc3VtcHRpb25zIHN1Y2ggYXMgYm90aCBURSBtZXRyaWNzIGFyZSBlcXVhbCBpbiBib3Ro IGRpcmVjdGlvbnMsIGl0IGlzIA0Kbm90IHN0cmFpZ2h0Zm9yd2FyZCB0byBjb21wdXRlIHRoZSBz aG9ydGVzdCBiaWRpcmVjdGlvbmFsIHBhdGguIENTUEYgY2FuIA0KY2hlY2sgYm90aCBkaXJlY3Rp b25zIG9mIHRoZSBURSBsaW5rIGF0IHRoZSBzYW1lIHRpbWUgdG8gaW5zdXJlIHRoYXQgDQooYXN5 bW1ldHJpYykgdW5yZXNlcnZlZCBiYW5kd2lkdGggZm9yIHRoYXQgcHJpb3JpdHkgaXMgZW5vdWdo IHdoZW4gDQpjb25zaWRlcmluZyBhIGxpbmsgZm9yIHJlbGF4YXRpb24uIEluIGFueSBjYXNlLCBz aW5jZSBvbmx5IHNpbmdsZSBJbnRlckFTIA0KbGlua3MgYXJlIHRvIGJlIGNvbnNpZGVyZWQsIEkg YWdyZWUgc3VjaCByZXF1aXJlbWVudCBpcyBub3QgY2xlYXIuDQoNClRoZSBkcmFmdCBkb2VzIGlu Y2x1ZGUgdGhlIGludGVyLWFzIGxpbmsgaWRlbnRpZmllcnMgKHdoaWNoIGFyZSBrbm93bikgYnV0 IA0Kbm90IHRoZWlyIFRFLXByb3BlcnRpZXMsIHNvIGluIHRoaXMgcmVnYXJkIHRoZSBkcmFmdCBp cyBub3Qgc29sdmluZyB0aGUgDQpwcm9ibGVtLg0KDQpbWHVlcm9uZyBXYW5nXTpJIHRoaW5rIFBD RShpKzEpIG5lZWQgbm90IHRvIGluY2x1ZGUgVEUtcHJvcGVydGllcyBvZiANCmludGVyLUFTIGxp bmtzLCBiZWNhdXNlIHRoZSBzZWxlY3RlZCBpbnRlci1BUyBsaW5rcyBhbHJlYWR5IHNhdGlzZnkg dGhlIA0KcmVxdWlyZWQgY29uc3RyYWludHMsc3VjaCBhcyBiYW5kd2l0aC4gUGVyaGFwcyB0aGUg b25seSBURS1wcm9wZXJ0eSBuZWVkIA0KdG8gY2FycnkgaXMgVEUgbWV0cmljcy4gQnV0IGluIHRo ZSBjYXNlIG9mIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCANCmNvbXB1dGF0aW9uLG1heWJl IFRFIG1ldHJpY3MgbmVlZCB0byBiZSBlcXVlYWwgaW4gYm90aCBkaXJlY3Rpb25zPyBPciBpZiAN CnRoZXJlIGlzIGluZGVlZCBleGlzdCBzdWNoIHJlcXVpcmVtZW50LHRoZSBtZXRyaWMgY2FuIGNh cnJ5IGluIHRoZSBQQ1JlcCANCnRvby4NCg0KU28sIHRvIGdldCB0aGUgd2hvbGUgcGljdHVyZSwg bGV0J3MgdHJ5IHRvIHN1bW1hcml6ZToNCg0KYSkgSWYgYSBzaW5nbGUgZW50aXR5IChQQ0UoaSkp IGlzIGFibGUgdG8ga25vdyBURSBhdHRzIGZvciBib3RoIA0KZGlyZWN0aW9ucywgY3VycmVudCBC UlBDIGlzIG9rLiBSRkM1MzkyIGRvZXMgbm90IHNvbHZlIGhvdywgYW5kIG90aGVyIA0Kcm91dGlu ZyBleHRlbnNpb25zIHdvdWxkIGJlIG5lZWRlZCwgb3IgVEUgYXR0cmlidXRlcyBtYW51YWxseSBw cm92aXNpb25lZA0KDQpbWHVlcm9uZyBXYW5nXTpBdCBmaXJzdCxpbiB0aGUgY2FzZSBvZiBiaWRp cmVjdGlvbmFsIExTUCBjb21wdXRhdGlvbix0aGVyZSANCmluZGVlZCBleGlzdCBzb21lIHByb2Js ZW0gYXMgZGlzY3Vzc2VkIGluIHRoZSBtYWlsbGlzdC5BbmQgUkZDNTM5MiBhbHNvIA0KcG9pbnQg b3V0IHRoZSBwcm9ibGVtLlNlY29uZGx5LGludGVyLUFTIGNvbXB1dGF0aW9uIGlzIHRoZSB2ZXJ5 IGltcG9ydGFudCANCnNjZW5hcmlvIG9mIFBDRSBhcHBsaWNhdGlvbixzbyB3ZSBuZWVkIHRvIHNv bHZlIHRoZSBwcm9ibGVtLlJGQzUzOTIgDQppbnRyb2R1Y2VzIGEgbWV0aG9kIG9mIElHUCBwcm94 eSxidXQgaG93IHRvIGRvIGl0IGlzIG5vdCBjbGVhci4gUHJveHkgDQptZXRob2Qgc2hvdWxkIG5v dCBiZSBhIGxvY2FsIG1lY2hhbmlzbSBiZWNhdXNlIGl0IGlzIHJlbGF0ZWQgdG8gdGhlIA0KY28t b3BlcmF0ZSBhbW9uZyBkaWZmZXJlbnQgY2Fycmllci5TbyBhdCBsYXN0LGhvdyB0byBzb2x2ZSB0 aGUgcHJvbGVtIG11c3QgDQpiZSBzdGFuZGFsaXplZC4gVGhlIG1ldGhvZCBpbiBkcmFmdC13YW5n IGlzIHZlcnkgc2ltcGxlIGFuZCB2YWxpZC4gDQpiKSBPdGhlcndpc2UsIGJvdGggZGlyZWN0aW9u cyBvZiBJbnRlckFTIGxpbmtzIHNob3VsZCBiZSBjaGVja2VkIA0KaW5kZXBlbmRlbnRseSwgYnV0 IHRoaXMgcmVxdWlyZXMgZXh0ZW5kaW5nIFJGQzU0NDEsIFBDRShpKzEpIG5vdGlmeWluZyBvZiAN CmV4Y2x1ZGVkIC8gaW5jbHVkZWQgbGlua3MgYW5kIGRyYWZ0LXdhbmctcGNlLWludGVyLWFzLWV4 dGVudGlvbnMtMDEgDQphZGRyZXNzZXMgdGhpcy4NCg0KSSBndWVzcyBteSBwb2ludCwgcHJvYmFi bHkgbm90IHdlbGwgZXhwbGFpbmVkIGluIHByZXZpb3VzIG1haWxzLCBpcyB0aGF0IEkgDQp3b3Vs ZCBzbGlnaHRseSBwcmVmZXIgYSkgcHJvdmlkZWQgYSBnb29kIHNvbHV0aW9uIGFsbG93cyB0aGUg dXBzdHJlYW0gDQpJbnRlckFTIGxpbmtzIHRvIGJlIGtub3duIGFsdGhvdWdoIEkgd291bGQgbm90 IG9iamVjdCB0byBiKSBzaW5jZSBubyBzdWNoIA0KZ29vZCBzb2x1dGlvbiBleGlzdHM/Lg0KDQpG aW5hbGx5LCBJIGFtIGEgYml0IGNvbmZ1c2VkIGJ5IHlvdXIgbGFzdCBzdGF0ZW1lbnQuIElmIGIp IGlzIGNvbnNpZGVyZWQgDQooaS5lLiBpbmRlcGVuZGVudCBjaGVja2luZywgYW5kIGxpbmsgZXhj bHVzaW9uKSB3aGF0IHByb2JsZW0gaXMgbGVmdCB0byANCnNvbHZlPyBzb3JyeSBmb3IgYmVpbmcg ZGVuc2UuDQoNCltYdWVyb25nIFdhbmddOlRoZXJlIGFyZSBzb21lIGNhc2VzIHRoYXQgY2FuIG5v dCBjaGVjayB0aGUgYm90aCBkaXJlY3Rpb25zIA0Kb2YgSW50ZXJBUyBsaW5rcyBpbmRlcGVuZGVu dGx5LiBJJ3YgZGVzY3JpYmVkIHRoZSBzY2VuYXJpbyBhYm92ZSBpbiB0aGlzIA0KbWFpbC4gDQoN Cg0KVGhhbmtzIA0KUi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xl bHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11 bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxp Z2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xv c2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVt YWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFu ZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2Uu IEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5k aXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNl cyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0026B968482578E1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+UmFtb24gQ2Fz ZWxsYXMgJmx0O3JhbW9uLmNhc2VsbGFzQGN0dGMuZXMmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3BjZS1ib3VuY2VzQGll dGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDgt MDIgMTc6NTI8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+JnF1b3Q7TWFyZ2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpJnF1b3Q7DQom bHQ7Y3lyaWwubWFyZ2FyaWFAbnNuLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnBjZUBpZXRm Lm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtQY2VdIHJlcXVlc3QgdGltZXNsb3QgZm9yIGRy YWZ0LXdhbmctcGNlLWludGVyLWFzLWV4dGVudGlvbnMtMDE8L2ZvbnQ+PC90YWJsZT4NCjxicj4N Cjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJs ZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+RWwgMDIvMDgvMjAxMSAxMDo0NiwgTWFy Z2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpDQplc2NyaWJpqK46IDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5IaSBSYW1vbiwgPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gZXh0IFJh bW9uIENhc2VsbGFzIFs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmFtb24uY2FzZWxsYXNAY3R0Yy5l cz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpyYW1vbi5j YXNlbGxhc0BjdHRjLmVzPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+ XQ0KPC9mb250Pg0KPHA+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+VGhpcyBzaG91bGQgc29sdmUgdGhlIHByb2JsZW0NCm1lbnRpb25lZCBleGNlcHQgaW4g dGhlIGNhc2UgdGhlIGFsZ29yaXRobSByZXF1aXJlIHRvIGtub3cgdGhlIGxpbmsgcHJvcGVydGll cw0KaW4gYm90aCBkaXJlY3Rpb24gYXQgdGhlIHNhbWUgdGltZSwgYnV0IHRoZSBkcmFmdCBkb2Vz IG5vdCBhZGRyZXNzIHRoaXMNCnByb2JsZW0gZWl0aGVyLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SW5kZWVkLCB0aGUgcHJvYmxlbSBpcyBfYmlk aXJlY3Rpb25hbF8NCkxTUHMuIFRoZSBkcmFmdCBkb2VzIGFkZHJlc3MgdGhpcyBieSAmcXVvdDtl bWJlZGRpbmcmcXVvdDsgdGhlIHVwc3RyZWFtDQpsaW5rIGluIHRoZSBCUlBDIHJlc3BvbnNlLiBG b3IgdW5pZGlyZWN0aW9uYWwgTFNQcywgdGhlIGV4aXN0aW5nIG1ldGhvZA0Kd29ya3Mgb3V0IG9m IHRoZSBib3guIEluIHRoaXMgc2Vuc2UsIGlmIFBDRShpKSBqdXN0IGNvbnN0cnVjdHMgYSBnZW5l cmljDQpncmFwaCBwYXJzaW5nIGJvdGggb3BhcXVlIHR5cGVzLCBpdCBjYW4ganVzdCBhcHBseSBC UlBDIGFzIGluIGEgbXVsdGktYXJlYSwNCnNpbmNlIGl0cyAmcXVvdDtURUQmcXVvdDsgd291bGQg aW5jbHVkZSB0aGUgSW50ZXJBcyBsaW5rcyBhbnl3YXkuPC9mb250Pg0KPHA+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+W0N5cmlsXSBJZiBvbmUg Zm9sbG93IHN0cmljdGx5DQp0aGUgcmZjLCB5ZXMsIGJ1dCB0aGUgdGV4dCBjb3VsZCBiZSBleHRl bmRlZCAodmlhIGVycmF0YSBmb3IgZXhhbXBsZSk8L2ZvbnQ+DQo8cD4NCjxicj48Zm9udCBzaXpl PTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltDeXJpbF0gJm5ic3A7OiB3 ZWxsLA0KZm9yIGJpZGlyZWN0aW9uYWwgTFNQIHlvdSBuZWVkIHRvIGNoZWNrIHRoZSBwcm9wZXJ0 aWVzIGluIGJvdGggZGlyZWN0aW9uLA0KYnV0IGJvdGggZGlyZWN0aW9uIGFyZSBub3QgcmVxdWly ZWQgdG8gYmUgY2hlY2tlZCBhdCB0aGUgc2FtZSB0aW1lIDogUENFDQooaSsxKSBjaGVjayB0aGUg aW50ZXItQVMgbGluayBpbiBkaXJlY3Rpb24gaSsxLSZndDtpIChvbmUgZGlyZWN0aW9uKTsgUENF DQooaSkgY2hlY2sgdGhlIGludGVyLUFTIGxpbmsgaW4gZGlyZWN0aW9uIGktJmd0OyhpKzEpLjwv Zm9udD4NCjxwPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwO1tYdWVyb25nIFdhbmdd OklmIGV2ZXJ5IEFTQlIgb25seSBjb25uZWN0DQp0byBvbmUgQVNCUiwgUENFKGkrMSlhbmQgUENF KGkpIGNhbiBjaGVjayB0aGUgaW50ZXItQVMgbGluayBzZXByYXRlbHkuQnV0DQpjb25zaWRlciBm b2xsb3dpbmcgc2NlbmFyaW8sdGhlcmUgYXJlIHR3byBpbnRlci1BUyBiaS1kaXJlY3Rpb24gbGlu a3MgY29ubmVjdA0KdG8gQVNCUjQoaS5lLixsaW5rIEEgYW5kIGxpbmsgQiksUENFMiBtdXN0IGxl dCBQQ0UxIGtub3cgd2hpY2ggb2YgdGhlbQ0Kc2F0aXNmeSB0aGUgY29uc3RyYWludHMgaW4gZGly ZWN0aW9uIGkrMS0mZ3Q7aS4gJm5ic3A7U2ltaWxhciBzaXR1YXRpb24NCmlzIHRoZSBpbnRlci1B UyBiaS1kaXJlY3Rpb24gbGlua3MgY29ubmVjdCB0byBBU0JSNSAoVGhlcmUgYXJlIHR3byBpbnRl ci1BUw0KYmktZGlyZWN0aW9uIGxpbmtzIGNvbm5lY3QgdG8gQVNCUjUsaS5lLixsaW5rIEMgYW5k IGxpbmsgRCkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGltZyBzcmM9Y2lkOl8xXzA3OEM4Mzc0MDc4 QzgwOUMwMDI2Qjk2MDQ4MjU3OEUxPg0KPHA+PGZvbnQgc2l6ZT0zPltSYW1vbl0gWWVzLCAmbmJz cDtnb29kIHBvaW50LiBJIHdhcyBzdGlja2luZy9hc3N1bWluZw0KJm5ic3A7QlJQQyBhcyBpbiBj dXJyZW50IFJGQzU0NDEgKG5hcnJvdyBtaW5kZWQgOikgPykgLiBBcyB5b3Ugc3RhdGVkIEJSUEMN CndvdWxkIG5lZWQgdG8gYmUgZXh0ZW5kZWQgLyBjbGFyaWZpZWQgdG8gYWxsb3cgdGhpcyB1c2Ug Y2FzZSwgYW5kIGFzIGZhcg0KYXMgSSB1bmRlcnN0b29kLCBkcmFmdC13YW5nIGNvdmVycyB0aGlz LCB3aGVyZSB0aGUgVEUgbGlua3MgdGhhdCBoYXZlIGJlZW4NCmluY2x1ZGVkL2V4Y2x1ZGVkIGJ5 IFBDRShpKzEpIHNob3VsZCBiZSBub3RpZmVkIHRvIFBDRShpKSBhcyB0aGUgZHJhZnQNCnByb3Bv c2VzLCBzaG91bGRuJ3QgdGhleT88YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9y PSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JbiBjYXNlIHRoZSBhbGdvcml0aG0NCnJl YWxseSBuZWVkIHRvIGNvbnNpZGVyIGJvdGggdGUtcHJvcGVydGllcyAodXBzdHJlYW0gYW5kIGRv d25zdHJlYW0pICZuYnNwO3lvdQ0Kd291bGQgbmVlZCB0aGUgVEUtcHJvcGVydGllcyB0byBiZSBr bm93biBieSBQQ0UoaSkuIEkgQ3VycmVudGx5IGRvdWJ0IHRoYXQNCnN1Y2ggcmVxdWlyZW1lbnQg ZnJvbSBhbiBhbGdvcml0aG0gZXhpc3QsIGlmIHRoZXJlIGlzIGEgZXhhbXBsZSBvZiBhbiBhbGdv cml0aG0NCnRoYXQgcmVhbGx5IHJlcXVpcmVzIGl0ICh3aXRoIEJSUEMgYW5kIERpamtzdHJhICZu YnNwO0kgdGhpbmsgbm90KSwgaXRzDQp3ZWxjb21lZC48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+ W1JhbW9uXSBHb29kIHBvaW50IHRvby4gRXZlbiBpbiBpbnRyYS1kb21haW4gY2FzZSwgd2l0aG91 dA0KZXh0cmEgYXNzdW1wdGlvbnMgc3VjaCBhcyBib3RoIFRFIG1ldHJpY3MgYXJlIGVxdWFsIGlu IGJvdGggZGlyZWN0aW9ucywNCml0IGlzIG5vdCBzdHJhaWdodGZvcndhcmQgdG8gY29tcHV0ZSB0 aGUgc2hvcnRlc3QgYmlkaXJlY3Rpb25hbCBwYXRoLiBDU1BGDQpjYW4gY2hlY2sgYm90aCBkaXJl Y3Rpb25zIG9mIHRoZSBURSBsaW5rIGF0IHRoZSBzYW1lIHRpbWUgdG8gaW5zdXJlIHRoYXQNCihh c3ltbWV0cmljKSB1bnJlc2VydmVkIGJhbmR3aWR0aCBmb3IgdGhhdCBwcmlvcml0eSBpcyBlbm91 Z2ggd2hlbiBjb25zaWRlcmluZw0KYSBsaW5rIGZvciByZWxheGF0aW9uLiBJbiBhbnkgY2FzZSwg c2luY2Ugb25seSBzaW5nbGUgSW50ZXJBUyBsaW5rcyBhcmUNCnRvIGJlIGNvbnNpZGVyZWQsIEkg YWdyZWUgc3VjaCByZXF1aXJlbWVudCBpcyBub3QgY2xlYXIuPGJyPg0KPC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhlIGRyYWZ0 IGRvZXMgaW5jbHVkZQ0KdGhlIGludGVyLWFzIGxpbmsgaWRlbnRpZmllcnMgKHdoaWNoIGFyZSBr bm93bikgYnV0IG5vdCB0aGVpciBURS1wcm9wZXJ0aWVzLA0Kc28gaW4gdGhpcyByZWdhcmQgdGhl IGRyYWZ0IGlzIG5vdCBzb2x2aW5nIHRoZSBwcm9ibGVtLjwvZm9udD4NCjxwPg0KPHA+PGZvbnQg c2l6ZT0zPltYdWVyb25nIFdhbmddOkkgdGhpbmsgUENFKGkrMSkgbmVlZCBub3QgdG8gaW5jbHVk ZSBURS1wcm9wZXJ0aWVzDQpvZiBpbnRlci1BUyBsaW5rcywgYmVjYXVzZSB0aGUgc2VsZWN0ZWQg aW50ZXItQVMgbGlua3MgYWxyZWFkeSBzYXRpc2Z5DQp0aGUgcmVxdWlyZWQgY29uc3RyYWludHMs c3VjaCBhcyBiYW5kd2l0aC4gUGVyaGFwcyB0aGUgb25seSBURS1wcm9wZXJ0eQ0KbmVlZCB0byBj YXJyeSBpcyBURSBtZXRyaWNzLiBCdXQgaW4gdGhlIGNhc2Ugb2YgY28tcm91dGVkIGJpZGlyZWN0 aW9uYWwNCkxTUCBjb21wdXRhdGlvbixtYXliZSBURSBtZXRyaWNzIG5lZWQgdG8gYmUgZXF1ZWFs IGluIGJvdGggZGlyZWN0aW9ucz8NCk9yIGlmIHRoZXJlIGlzIGluZGVlZCBleGlzdCBzdWNoIHJl cXVpcmVtZW50LHRoZSBtZXRyaWMgY2FuIGNhcnJ5IGluIHRoZQ0KUENSZXAgdG9vLjwvZm9udD4N CjxwPg0KPHA+PGZvbnQgc2l6ZT0zPlNvLCB0byBnZXQgdGhlIHdob2xlIHBpY3R1cmUsIGxldCdz IHRyeSB0byBzdW1tYXJpemU6PGJyPg0KPGJyPg0KYSkgSWYgYSBzaW5nbGUgZW50aXR5IChQQ0Uo aSkpIGlzIGFibGUgdG8ga25vdyBURSBhdHRzIGZvciBib3RoIGRpcmVjdGlvbnMsDQpjdXJyZW50 IEJSUEMgaXMgb2suIFJGQzUzOTIgZG9lcyBub3Qgc29sdmUgaG93LCBhbmQgb3RoZXIgcm91dGlu ZyBleHRlbnNpb25zDQp3b3VsZCBiZSBuZWVkZWQsIG9yIFRFIGF0dHJpYnV0ZXMgbWFudWFsbHkg cHJvdmlzaW9uZWQ8YnI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+W1h1ZXJvbmcgV2FuZ106 QXQgZmlyc3QsaW4gdGhlIGNhc2Ugb2YgYmlkaXJlY3Rpb25hbCBMU1ANCmNvbXB1dGF0aW9uLHRo ZXJlIGluZGVlZCBleGlzdCBzb21lIHByb2JsZW0gYXMgZGlzY3Vzc2VkIGluIHRoZSBtYWlsbGlz dC5BbmQNClJGQzUzOTIgYWxzbyBwb2ludCBvdXQgdGhlIHByb2JsZW0uU2Vjb25kbHksaW50ZXIt QVMgY29tcHV0YXRpb24gaXMgdGhlDQp2ZXJ5IGltcG9ydGFudCBzY2VuYXJpbyBvZiBQQ0UgYXBw bGljYXRpb24sc28gd2UgbmVlZCB0byBzb2x2ZSB0aGUgcHJvYmxlbS5SRkM1MzkyDQppbnRyb2R1 Y2VzIGEgbWV0aG9kIG9mIElHUCBwcm94eSxidXQgaG93IHRvIGRvIGl0IGlzIG5vdCBjbGVhci4g UHJveHkgbWV0aG9kDQpzaG91bGQgbm90IGJlIGEgbG9jYWwgbWVjaGFuaXNtIGJlY2F1c2UgaXQg aXMgcmVsYXRlZCB0byB0aGUgY28tb3BlcmF0ZQ0KYW1vbmcgZGlmZmVyZW50IGNhcnJpZXIuU28g YXQgbGFzdCxob3cgdG8gc29sdmUgdGhlIHByb2xlbSBtdXN0IGJlIHN0YW5kYWxpemVkLg0KVGhl IG1ldGhvZCBpbiBkcmFmdC13YW5nIGlzIHZlcnkgc2ltcGxlIGFuZCB2YWxpZC4gJm5ic3A7ICZu YnNwOyA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+YikgT3RoZXJ3aXNlLCBib3RoIGRpcmVjdGlv bnMgb2YgSW50ZXJBUyBsaW5rcyBzaG91bGQgYmUNCmNoZWNrZWQgaW5kZXBlbmRlbnRseSwgYnV0 IHRoaXMgcmVxdWlyZXMgZXh0ZW5kaW5nIFJGQzU0NDEsIFBDRShpKzEpIG5vdGlmeWluZw0Kb2Yg ZXhjbHVkZWQgLyBpbmNsdWRlZCBsaW5rcyBhbmQgZHJhZnQtd2FuZy1wY2UtaW50ZXItYXMtZXh0 ZW50aW9ucy0wMQ0KYWRkcmVzc2VzIHRoaXMuPGJyPg0KPGJyPg0KSSBndWVzcyBteSBwb2ludCwg cHJvYmFibHkgbm90IHdlbGwgZXhwbGFpbmVkIGluIHByZXZpb3VzIG1haWxzLCBpcyB0aGF0DQpJ IHdvdWxkIHNsaWdodGx5IHByZWZlciBhKSBwcm92aWRlZCBhIGdvb2Qgc29sdXRpb24gYWxsb3dz IHRoZSB1cHN0cmVhbQ0KSW50ZXJBUyBsaW5rcyB0byBiZSBrbm93biBhbHRob3VnaCBJIHdvdWxk IG5vdCBvYmplY3QgdG8gYikgc2luY2Ugbm8gc3VjaA0KZ29vZCBzb2x1dGlvbiBleGlzdHM/Ljxi cj4NCjxicj4NCkZpbmFsbHksIEkgYW0gYSBiaXQgY29uZnVzZWQgYnkgeW91ciBsYXN0IHN0YXRl bWVudC4gSWYgYikgaXMgY29uc2lkZXJlZA0KKGkuZS4gaW5kZXBlbmRlbnQgY2hlY2tpbmcsIGFu ZCBsaW5rIGV4Y2x1c2lvbikgd2hhdCBwcm9ibGVtIGlzIGxlZnQgdG8NCnNvbHZlPyBzb3JyeSBm b3IgYmVpbmcgZGVuc2UuPC9mb250Pg0KPHA+DQo8cD48Zm9udCBzaXplPTM+W1h1ZXJvbmcgV2Fu Z106VGhlcmUgYXJlIHNvbWUgY2FzZXMgdGhhdCBjYW4gbm90IGNoZWNrDQp0aGUgYm90aCBkaXJl Y3Rpb25zIG9mIEludGVyQVMgbGlua3MgaW5kZXBlbmRlbnRseS4gSSd2IGRlc2NyaWJlZCB0aGUg c2NlbmFyaW8NCmFib3ZlIGluIHRoaXMgbWFpbC4gPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zPjxi cj4NCjxicj4NClRoYW5rcyA8YnI+DQpSLjxicj4NCjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUGNlIG1h aWxpbmcgbGlzdDxicj4NClBjZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcGNlPGJyPg0KPC9mb250PjwvdHQ+DQo8cD4NCjxicj48cHJlPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5i c3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWls Jm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNw O25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21h aW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1p dHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29m Jm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMm bmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQm bmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJz cDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJz cDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lv dSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5i c3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9y Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7 ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Ro b3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZu YnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNw O3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNw YW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0026B968482578E1_=-- --=_related 0026B966482578E1_= Content-Type: image/gif Content-ID: <_1_078C8374078C809C0026B960482578E1> Content-Transfer-Encoding: base64 R0lGODlhOAI1AecAAP///wAAAOjo6PDw8ICAgPjouLjo+ND4+Hh4eEBAQPj46Oj4+NjY2Li4uDAw MODg4LhwAJjQ+Pj40PjQmMjIyDg4OHAAcNCYAABwuIiIiJiYmAAAmGBgYFBQUHBwcAAAcCAgILCw sFhYWOi4cACY0KCgoMDAwKioqEhISBAQENDQ0CgoKBgYGHC46JgAAGhoaHAAAJCQkLhwmHAAmAgI CHBwuHCY0LhwcNCYmJgAcJhwuJgAmLi46Oj46JiY0ACYuLiYuNC4uOi4mJiYcLjo0Ljo6HC4uLiY AND40ND46OjQmJjQ0Li40NDQ6OjouHC40NCYcOi4uEgAAHBwmJhwACgwMDhIUJi4uJi46Li4mNC4 cNDQ+AAAKAAASAAgOABAUABQcABgYABwcACQyBAAEBAICBAQGBAgICAAICAgACAgGCAoKCAwQCgA KCggGCgoICg4SChAWDAASDAgADhAQDhQYDhgeEAAQEgASEhYaEhokFAAQFBQSFCAqFCIqFgAWFhA AIBIAIBoQKhgiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAOAI1AUAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDijxIoKTJjgFGWkypsqXLlzBjypxJs6bN mwpZ4jyoM+YDAiBQlNhJtKjRo0iTKoXZE2EBGAECbDgw4YOBg0+jYlgwsMCMAwNLhkXYdOkDDys0 LF3LtmXZpG/byhX5AAUHAQPj7tQ7l+AABBVU9B28NIQIFggYJOQrsICFqxcw9IDQYqACIFwdXz14 obJBAgzflqiwIgZewqgRDhCBIPVLxiHfxkhw2rXtiQI4JDChEfbeiwIQgAhx+6aABBSKz/T9kTkA BgkUK0dNoQLv6XNXt8aOcUCF5Nxrpv8cEQFAZK4CLwSw2hhqVBJdobIn6BWsQLEpQU9kUOFB+Jsa cPDfgACE0MEABPq1gnQJikeTcw0JsIJ/DW5UHYIVZlhQDC8UR4EDGv62XEUClMABCCu8cAKGA3Vw QogNiTAUjDQqJEBgbblYo4gyQWjRhwtRQAAKNKCQgWC2NZDAjkxGVIIIRRGwXZM4+biRlVg91l4E mo2glRMzcKjZmFpOAN9AE2zV1VcAaDbBVG1+pQQeeYDgRhslIEimAZq1+ZhjROSwGUETeKYABGeW BAKLVDYakZQzsUCho5TSNEAKjK4lJJFGInlCBxlhGWqlN4WAgkovxEDqqjY9iRoKxFH/VOILKKoo Kka3srqRA+BxxOtisekqrAApyCVjczvYB0BVBkggKACHltcnACOwxyy1aqKZLQCg5SrsRpJmBOtC 3ub0bV4PGqXCCkqZUMFDAjQQAwIJrBBABR0gUEIDPKV7Lk6uVpRCbcAqJEGyaM6nH1n/AlAuRQ93 NDBFDDRAwAsJpEBDAhwgEAKSEhGrUsQSkdywRQhMCRFzJhfUcngBFCrQofBJwMNAnfm52VPS/snm QOQRhF9GJpyAgAgJBMBCAghk0MCkD4HA4E0eZOCWvw2/zPDWDwXokNYCgT2d2ORedGhUWi0wQQBn zgwB2i2s/cPb8J39gQcIvD2VBC5g/6AE29RKdcDZRrgQgGfq+R3A3AEUHsATbzNe2dloe/Gifgt7 RLa5JzNGOdptr6xQuA6l/HWw/25e8FFe36TkyTDy9XlU80XEV+sNMQAC7DepzrVRCfB7k+m8Z+i7 w2V3LWDxIzZvFPE3uct8hcffvvxDpk6vPUepFsWBWtv/V71CE0tUdfjoS/QpUghknv77AIhs0ffw 12/Q60vRkKn9zJ+f0QAsIBj/tkc6tujOJcczSAKLlwEPfGQAIIDaAEXnvIpQjj0KkIGy0vOeAahh EAcowBSoAJ/EcUU9G0CC4SSjwcBZ5VAYOMLhLKPBDCYBAjGcoQR0MJkAlIdaoTNI+/9GskCCFPFf AmDB/j4SsJhkxTMEuQCcGvMznE0xNUcMG0yGOB3/ae5gymKWs64SLZ0JpFpXudYItgWAHaKHW1lk 1aWW2BIJSbAjYyzIU+ZzgdDB8I3muSK33LeWACBMIGJ8VhmnhcZlsWeNgATjWDY3gAU1aF0owRpI JHm2HxLES2nDShULQki2NLAhAxCAKlfJyo4wYAV05F8ctWYdJnmnVxWZ5QQZoqO5cHGAs0SbMIdJ zGIa85jITKYyl8nMZjrzmbrcZUG6N51bvi+aEOHPpBRwAzJ2UyEFsIFE0gTIhmRwgwVxY0G4uRm+ edIiTUxej3ZpggTEckDQmVrWNGn/kOPgcoLWlGZNxvUtAXSglAJ1iAYScMeELiSfDt0I/UKSSlaq 8p63IYADrsM/FVQAARiNaHde4ECRFsRd/+xIKkPqF4sKgKXKacBhEtOknwTlRSZlSwhA8IKG/ksD KwBpTCoKkYsmBKaNYkAMPJCxFCSgag0QIEcGIC96sWBjLzhSTld1AhSAgAA+tU0JvApWeLn0pSoZ QCwritStuvWtEnlAA0KQspQhLQEJqIAwQYBXvNYVARpoQEobVVFVwvWwiJ1eYVnZVlmd9awxQWhi J0vZyvZmKSaLVwMTQIMOxECflg2taIm4EFCGsk3yKQJmTHvaN6EzNEixaU9Hq5w4/9qOtiRijGnf ubaoeIa160ljVAQJW9fkBgVhxe1MBnACWtl2ZaBVbvwSYLXfHeW5IxlNdKWLSqBkoLHIW8i02ugC KAIAB2AZL9DeKZaHQKieHRgs//zJPGwiBKK0HYAHkAsS7J6uIxrlaMO8iD6doJdQUYkAenuLNjWx VpCuVeBE1idS/swotMcB347qCd6GKSCUWQnAEpjwthkyGG3l2a15ArCV3hI3Yr0Mn4E6HNoZ/2ei DrXvQELgAQewQAQaSO5B8PctDnHXQhWgcU1O6VYdf4ReHUjBRwWsoV8eeSQPWIFUdxJjuDp5ItOq z0GAZEaJDKELVfhxkCGiXoO0uf8gQhgCcQEAQcle+SVdlkn2KvvlllDzJkoVgZQRQGWHEPnOR6Fw Sw6N6AQdKzVJzBRdfQxkIaOrgpQlcEekhhAHQLOZIGr0cjE1l3heVgI+cKfbalfmPjbmMTTrChbI OUlujZbRFwke55oj6poccCkA3PKoMD3aP1PEyPI0WKpdwN6xuGyfxL4JpGxStKPpFQQVoIHTLA0x fuKWyRKB3q41B+04T1HM502vluKk7quMgLg5M6Ktb0LVea2ABgFwAAr0JbxRK9m93hbW+A6iaYb8 uri8Tt2DLMbUq3LMY/JdZ4kx2MIovgdaGhQhCVeMATo0AIUqZHEPWuilF+JQhlD/PKcNT65DHr7t hxdcwu6uFm1dDfwg4G6IlcedSYXX/CamDnh/hc4q38Q6LAuzsxYTIu6FKHohKfg0M4vl83kipeAy wV2vEz4yhWDyIeXjbp9vEvaaaH3rPe96Qsj8kF+Jneg0kR+P0J520jJd6QdpOt0zdHbjUH3v4dH7 Q3AMeALhmiicLrxy8jyRPSseO8ZOitwfTxjBz0/DlCfM4deyApChzuqiJShIvp7YsTtkdi0GnGVK HIA+yI1u0HqbyQXHN8XBx0tTIZzhEMfivzHOcZBb3NtSXmI1YQ4A0kMdqlUde1ZPy9U6O7oCBFD7 NxKAJXiPaN9HwnaVcPLlBjEt/xvTM2dnY7aNy4Y5BJy/buhr5ugDOXCts38Rxiun8+T+OUeeaBAp KkvMZYRaPsQd9ncQjOURtWRSpncRr/RvffEAi3JZ+ncReUQfMMBHfoRD6DECKddC7UUYWFcQK3VU woYR22c/CxgRllcjj9ZtE8g/A+AAnjcYHIaCcMdLONUwjvdfoLdLO/gf+DU9KSgQ9GUQ7EReLXBO nwQf4YRxIVQDXBE0CtAEI1AzPFAAUHhO9dGEWLgATTgzNZRxUNiEO+QEUGgZ31R9QnMRHlWC4dWD 75NzTbIaJXUuTpYBtPFWRUh3hFc8AfZWHiVUV0YAHeCGbzUa3DYRbKUaLuWAa/9xFiCAeQ1zAivA AduVecjnAPTHPIHoEmgVEYYlEIvlKIaRAkB2iW3xACbCAkKBiS/BABzgALHiKA9AKzloE4v1iQdB VK7Yi9hhAgjgYxxQAoYIE8AojMSoEbmoi3FnVL74jNBYEMxIURbliNF4jZS1iC11gNjYjd74Pkn3 jeI4jhSxibelFAHQAA2wRFSljg2QAXWFMSngVFBVjOR4j9/iX6sjEioQAx1QJBkQcfg4kCGij9ZF EzbVigRpd2xhkPUDG30SGZORcphRZvQxSmvYL8CWASCAAPa4kA3hkDxXeBC5bkhIEAf2Zug2SAjX FyrQAfwFkufYkIpXFxzwACL/+WzFIQAegCMyCQBjBQIeMItviBCslS1Z8QGqtQDApSbqMUPdpgJ4 +FWJmFizcUc5KW//YVAq84wPwAGIgYpaCU7uMRXX4mbuwUaohnTmt4+7qAEV4AC3+FYnUAFimZWX 1iDHoSqFR4mzlUulhWII5ltnNExWwVrmRUESoQFC+ZHas4fQBocEEYTSdVxVyYOFtBExsFHpA5m8 M4SUmVh/4ZOfl5kgoVECWSmeKYQ3aBChKVJHY43pU5diSSMNgAKy2SgsYW72gW4puW5i1ifv9n8Y iTzmOBAtuEslwFDclQG4ySQ7Bz8xYyiI0kY3kx6VEWYw0DN8MkorOTQXEXTh/3OCR2ZjFRKC0tma D/F0xWOeiuee0/GDuzRLGnAYDjCUGBF5wjIAKNBvvcif/okaD+AAl1lg6gkAUkkkCUAAqRmDM0gp 2iSO0ckW7BlRQwgRwFgBKeBZHFBdjXIhBEmeRYGeCXWhF/F0zPUCKwACw+iYfeGgPykQyVkUbudl B6oQJ8ZiXBFhAgGBCMI3VsGjBvEAAcIC90mUy1J+CAGkBiCkA8GkCyF/B6GfMWpHREGlW2WiZAk6 rzYoAkEFbOBIfPInMFAzOrAAYzRG0RKcj6ECe2AFNDAHYEABTzEV6LYndRpCX+Em77Re5pEtJQFB PxGjCkGiKiGiOaWlCJGjPv90NmwUYutBBQEgBvIhXIKzLMN1AHzzOG+zFVmxFZuaQoYzFVkgBVGR BgEQBlAhqsJEAr1FnToqgD7UfYS6EHLYEqRHWYrKEaJnFMyFFiyajAlRoSVzowlFqyKBpbWaXVDi Gj+RAkaKn4D5gjl1qx5RQMs6VKSGGom3EFL5jws6WLvqUAWIEZuXrS8xo2xhqMWKWlCUR/5nRkfH LH+0euOXH6IVbB0hnkvHdegKABOKFHP0RYYjmKvHHs8HJ45RBBDgSRNQHrRmEtd3nCalrOoDKm7J EXhJW+xaKqfir0whXecKESNblHUncMaqEn1oFCtbEXJFAA03rluFrXHFAi3/SZaJmZFjmY8pqxIJ eBS9RFUagAAo4GkrwDSB1WEyu1XdKhHqKmELsamCKbEfuLMoS63G+C4hQQF0pRs0QI8E0ADbZbHD Jpm4VXYPkXzJdrI2F38b1FsKRhXD5GDCdEVPmbNZ+bRyBY8JAAIBkACscQKFthEreCU9C1eT9xA/ O5KGq3BBcx44E1ztwaWTy2oCsZb30S3zJhINUAII0AFGyzQxEFUE8QA2SxTyCbKvATs3VxCpqxCm i5lsuyofFqshNmIlVhmMmmKCmThaIEyJCRsq0AAI4LVO9QII0AAqcITRUoF6JE7OWxCLCwBBgKbP Yk4aFL2Xe6br9E2HcgYP/6q6CMS644sQvcoQJZuX+WeHh9u9m1GF5wRKEXAB0iJOWniGphUHgeBJ XXhOZtJGydKFX+iE9+uF0OsCrHaEACAIX6Cz6xsTG1sUrVsQucoQ03azGhuZEJwUyHYT+lO+Ztu2 BnOdw0kSGEwQLYsQKQy14rsqS8u5SwJoMyeTsHGWNsOSAJcQ1ooQiKq+s+vC7TsShesSr3uPE1wQ 6TsQSayrQSwSK/wSQyyORzyZMxySd/bCIdG0NBHF3zjFA3FwMXJh0oXFH6G2NrHE3ejFAoHGABC7 R0bGCDi4MgHGC6nGANuVDBGw/1oT/BopBQqNdvy0C/HBe0wUNNsqzQqSav9sxvDyd4VsEzVKFNP7 yCExyQ7hxpQ8E5YcPVqbySFBrA9RwZ6sEudbFDs8ygxYxRShr6g8Eof8PHjcyiTiyBfxxLJcEWxc E2TbuCFMWYSsEUV8yxOxy0XBxbjSxNIUaR8RyaWHzNDivQ2rvY0hTk5ABl66ENUrzQhxTtKsTgQR a3wTOqL8wCErWj1sEco8WWSswPCrQfJLv21iA50nhlEIN/DcGFmoQf8LRgIsTmA4OPRMhgjspbRm wlqcdk/xrs8Sr30yryaXLQ+rkRS7S6X8EbnMETJzEFK7FVGwQXyjpHIBxxBhy3JxyscstQn2zet3 FQmrbgzbp2dUGSYRAFX/e1jjLBKgHBJdqB59WnKD0tEFEa+uwRIJ/aQLrbBa4tAGUK8FgAVJik74 qhId2xfluhLO7BAZbRAbvQBAjUiUGx74xxAjuBEN6H0FK0y1I6WOCkhCnbltCRcoPYAHy9Lth9Qv jZblIbFSt9d83dd+/dfPdNXiBYU8XRA+PRBdbdggDYIeuhBnJZsw6hGf40kobRXoFWIQ1qpDLdgI MaB/TBggKoG9nBFxTTuDotadCkhBIzTh2BcmPRDOOBCFxRGvbYNYKxG1HR6CWrYbLNmsR9lnbdkh VJb2AVwpbRtkO9YyUdGyxNkCEdpNwsztOtq7JN1K4dnSJNKRXSl9fMI0/xdRF00UAWXb1G1w/fEv JM3CvS1QAuAAtelLEy3C5Y0QrjI7OUsQ4ewSbS1xbIR65aSIliS7qytN6Z0aKhAdBnrb0/VPR+hO +/2//ytFN2Qt5UG/HGgeXELYdgqF5MQzA3xO/ufh0MtDTfDN3xR7900RzG21A24/A7AbNPKaGlzO NoIcu3TBvcgADuCi+GTjnSN00JGa9rOafCiJXEWauPUACcCXiCXjR1bgq1ICnDlZHtXYoqXkYjxa WE6Nj8WNyvGHDhWIuZlTHyLHOTUA+SISsU2C1RgeGRBUPL4qA/Dmgph5JqCJInXn8V1U4LVSLpUg DAC6SFop9eTj43jnRv+uPWL+EqH4EMot240OI4YRlg2SkFleq38BAt91LvWEAkIeEl5uI3HuKAkK kOGLE0oVZRXAoMKMEDJF6TCynKWBUbk45rsY6tuYU5pVvH2lV2jjAH2FV74eFcCOV6wRtp/d6hCx nCzQooRxjFTpWI2Ii2uu7LdsAps1j6K7jh1BAUbTAfZSAawRAqNuG6tk69ae7rxjUere7lSC6w/0 2Lfu7vReHMsI7x5x79NY7/ze7/7+7xkF8AK/PR+45wfhaYCd8L8+8AxvETXNy0jxt5xVTBvTV3iT MqNb7g2/8YxLFLmiWUyl7VDF8SSfw3BBUc1VKytS8izvw0ZRRDzmYzT/1fIMH8HYNekz/+8Ir/A8 T+yYaPNGgfPv3coRzOKAV8NWkd9rUx71epbVi6lKilARHAON2e5F7/JHzxCaEc5vFn0VSUUb1Nrq rRTBsQKb3upX36+PV5KD0vXv9/XslrkSm7FrAYsrMJeenPYmS5IMcZZe/UOrfZYZvZKbS/dyEQJp gcp6r/cnA1RAfxuIb+U/yQDO2Vmftfgo4gEBimhAFSuPrxx6vpA2JQKDvvcGIUYuAB9LH3tq4vRq A7FyTUotyQAI8GNmbll3jqSf/4sVgPfQKABAoZAdTx+PwfUmSfxLDfcCAQWDIvaGj6Av0Oy3/1Ye 8AJLtPuBJwLoblk8/xmJbcX2XXH84Z/8gCR/VJt9zEEBHVABm59TKuAA7Y/1Hl8hZZ55VO+RLoij rLb61PJDgg8QLQBMEAggyAIAAAgkZNjQYcIADyU6POGAw4OJGTVu5NjR40eQISUS6CCAY4oAKVWu ZNnS5UuYMVOmEPnRgUycOV86cDjgxYuaQYUOJVrU6MQGFTqoKBrx6FOJTmsOyACCwACoWbVulSig QgmuYcVOlDr2YdmGDRwwMNvW7duHIVZogIoWLki7NR+geIH17l+zAhJQAFx4aN62iBMySMDW8GPI HOXS1ao4ckPLIlVUQOD38mePggmDJh21cGYAjB2XZt3WhIMMYlFfnv+tmbPn1qRF5+Zdu7JH1byF H32QYKFZlDqVL1dOM+xmsMMf75bO2nfW68Grb+9YosJq7uEzksQtPiyKEOZBX68rkkKF8uqlDxCB QP59iRQcmMAPNQbQ/iBzqgAYCgJAghwMAOCCDQ4AoAALFFQAAhISmuADAybEAKGBAmjwLIVEIsC+ AHMzoYLRSixxAA48UDEoBhww6cXTDvRBAhciSGhCDBuCUMEFK3wwwgmFTKiAGRxkaKGIjgtpgAT4 ozEyDUSIb0r8QujgSiwd6uCELgELAMeVdGSIRwV/TIhBByEsAgIzGUJSSQLqJCAAJ2syIQEuwwxL Aw78nFLLPqcsQQT/Qf8KYAclB8IQQQnhHBLIEXq8UMERNpQzyYaYNAqBPBPd6oQORMWSUEEHcIAp U99i76lXJ3rAAYxafQpVWwfdsssGEsjV1Rqf4oCyX4PCtVhdCzXvhRiQTQwwBgLgoIRaiwoBBWdB euC7bMNktkQBVqi2W65iNUoqCjJAIQAUMkjxyRXAI/ehb+ftclt5xSPVXtmClbUEDlhYwYMQlGXI g9j4ZagBFAxWWL5D5RMhuod/E1OkBhBwIAURNMg3oRMVHgDFigVFTzwH3i0ZVn+HUiGGDmiogAAp HwDB4URHXDnRzWYcboB4d7ZYUa4EOOEFFgIQ4QSfcx1ZZaG7PFm4/1nHjfrclrlSlSkTCKiAhg5i YNXPkK8WFVDeGFgBZ7M9MrcptyqQ0iEGqkzBAQTSUxHUtk2tmjX9+m7vYre+7GiAEDxYgYVhrZ4v aMFNnZi0fSM/6m2iMJczQgCKnAjhIzn3KN11UeAAao/UzEj1iQg00KEGQrVc0Gs/C3x2rAknSvUL SMCxx4b4CCSlD4hwofjjs8CQwAAKYh4DMgO4AgYuzFiBAyk8POB34wMwEkLjkUfe+0knSCnOhCS4 McdOAcjAA9lxD1MFB9jmymb75Scr66B4b5D1B81gDRT4UQE5Zz6VRGACRgpgmyI0AU1lQQ5VKAMa MsAA1RnQAGoqIP8MyPeQ6J1PIXaqk/5ahT/DDAAEjjNhSDQnlBdOKiGV2qDo0ueCMYBACRHS4IHY J4EtEEhHQJzTpHAkkAXKUAh3sILMPPCHGkZxUgXkFEMkwCiGXCohBGhWC1ulQha2JWVePAz/2oLC whjtBSAAwQtK0LSaGI6MXyTZXeQ4x5rEMI+FuR1ouva1DmRgbBwZ41BuwhxE7gSPNSmkW0C3yJok J5GTVIlzABMx4dRNBHfLm0RWMMig6FEkopTfHcfSK0hGbnLhQZziGLcCipVRd6m0Ceq0woIw0rJk A0hB/kgDOtKxiwC21Agp8aJLkAyABXDUSr2QaTZMmud9GXkAwAT/5oETFMqYH9km7hgAArGg8pl9 W2V4KgeSjG1MBDFYTTc74s7Z1Y4ruBxn33jpy8f0kSgv64BUcNCoDgUgAv9EoEo0NYKVfKghEOQQ Q+A5u2k2s4v1bFs059NL7CRECENQaBEB8E8ZNlCGI1AoAISQBU1hJkQU5Ygzj/LNjMDzoSwNSwIa sJ1ysmwEOrpAShcUAOAxLyXf8yDwEnIQhm7RU/GjqUPo+ZRHmqZcTdVXqaRjUVgRZEcUOhAPGHIB gWQQBjqiopIukFAHlXCmsxOnUQRgSaluZa1UzUojc3NPrSggJZoS6hKYAIGUILElOkKoCM+a0qSq lK4bcelQ+BbT/7DMdbFHwSprhjXVWU5WIk8dCl4hi9mVHZKSlOQJaEDwsc/IU65m1OzCfEUUBJDo s6vdmWRBBBq0tUaZzPyICU6AABEkIAAsSAACMtCAB9jWIcqNXGNFkgLeKrYjIOWm0Jjr0NJAtzUR lYgKMsaBBNAgBQl4AQIaAMr9Zba1dAOnUNo6241stKQOkd11uWNfAOA3I5clDQMaQIMXJIAFNEgA B/JGTBeydr0JyWlIHlvMjux0QSkt4RZvuzL86ncilRWLABqQAQQkAAQBUAoCSiCl3EZWwQvWZ0js ml6NaLVzXB0hhGu7YsC89SkDaIAGEICCFQTAAShAgAYagLMXD//tLho2m031woJ3amRCAeCrBwXK ESYLJ8OskZtHGlACBHSgAgEAQXFj0IDoiuScKlbvghuiWpBw+MJKrtiACmTFBC3oQ2rynKMyBAFN TUBH5kNfflf6Gb5RIATAFS5x4dcA1G7FyWPZctREO9qclPYhSeYIfzciU+vaCEdmQpOPRNe70P2Z gQmBApBC1KS/eBcBAU4BgcubAU1HRgUreFabHyZZxPxHJJy1MW0xHMIrnwkCPfKfA99U6I/SyU54 0soDYucBAQcgAfU5AYITQgN8boW7/fK1woA9kV2P0m1sxjAWLfSoPE+IrKKjoZ8BkCkOyfggFn6V h2MQ4jewxA//GsHRqiVy2qKwaSIaauiMV9KCqVEax/M690Q+CRKYRhm0Jas0Q3jsYxTcZAXFNXJ8 FHADCaFcIwWwAUcmbSGfekQBMgCoQySgg4Z3TuUnD0C4E1xuflVcIs7VyHuLTedfA4YC2jYucmty cgWNWuFZrFASGZSEZStI0AuqgyAEcoEIFKAGC2CT2BfAUCGy/Ew0L/tY1X7zHjShIVA/EAzg4JaO 37jXElkzR/oO34zqnWhEofsRZw7QEVRI7Yc3+711pAARCKJCEuCB2RmfJLWbXe07ojnjx/52HThh 7GdSuQSkYIf2bRwuWR6O0B8yABqAJMWfZjfHJw6Y2F6G08Ze//LVMnNzDvU054cGvENezpHca5z3 db79X2ZvGNvmHcOpG2vqiQ/joU+008SiveqTDnTDGB0wD4CyWySJaUTCdfocEf6SSMjU5Wok+R15 cPeX//3Bl0bOcMm4m6G/ESFiCAm7PvuTiOeTP9kqwMBbv/wjjQP8C/Hzv9XDO42As414wLhCOnNr vruYP8PAQAncO4nLiAhEitcKQenqPcvivsIYNxQEFhF8iP7jiHR7QewCv8KIOMPwQBuMwdrLwI0g vx6ECA6Eiy6DDB4cQnIzC8uAvWMaQun7DISDDBBUwgUcwYmYQY44QhuMwsgQQioJFCtkQgokwROk P/hbMC+EjP/9g4sSHMPBIcOMaMOHKJsuLEK3aLDC0EI41MD7a4gqlAhw68E1fAxiMwwd68MfXMSG SMKNMKUQPD/0Ww71i4wWewzWWy/XewhP8whhU0Rk0ZnP4EJQjEMslIjdywg+LEVROT7IEEVWZBkf ZIhEDAlXjEU/WUXDsENcLApJnMSXqESGoMOJsMBe7BKiewztOsYA6USQSEVm7I9aBA09jEbxOMSP +DtrDJCowi0x3EbzuESQmEJwDBDPIg0wLMfwgMWaCER1rA5HvAxIfEfhwMaQWEZ6VA98LA1xzMfS cEfJwBZ/FI9k/IxbHEjQgMaPcEaE5I03TC2BbEjSMMag2C3/iRwOeywNhXyKSwNGncg1NztIY4nI i2SNgnTAbzzFCZTAfhQKhizJyHjI0rg4OWzABdNBo7BImASNjGyNGlRJGHQzgHQPkFysjvRInCjK kJgylXgdEHIBIZlHqJi6h2C4qgSsDUACr2KIeDTFlVwwAWABn9sIbWyqQvwIuqO71Wm5btyIxEJL mssI4HOICVAo9XEIcvS+MrxJveEKF6Sqs5S50ssRqhyIqiOBDACEDcA6S+GpCBiBrwu7sSu7sUM7 t2s5zjuAtgu7loM7uRNAg2sIXuQ96rKQ8yEoljgotGqIs0o2IlywoRyKtjRLPJSIwnOBFji8hki8 B9GDDvA8/4SQMAVoAt6kPMujuTnJvM/DzM7pPORczgMJvdHbKiHZPAurv6GRLyXxKJDKIE5RE5Jy kClzSkMjQJoKy7H8CKmkqMDUipbkDpqkLQlrvzUBKiARqg96kKJyNWUzkzpxijQcJ5wUi43kisI8 EhioThgoqcKaL/FoT6hAI/w4x4ySMc+hvK8KK9EJwLJ6iAH8z/WaTbEAmkgLiwuYHge9AKOKNoc4 0PDwJ4BCoIE6gILaq+BczRkSofhzi3DJJfH4SewArCpLCb8CrOYJqDK5twT6KQxwAg9y0Ex0lr+c iPR0iAJ9CrDqkJhjSgf9qi5dktbTKI7azirqzg39Ts4Jz/+GmEuVClCjkNASKcvMqc2gcFECUVCF qlEqG777kNOeEAABqFKGWE+tgMws2lOJaM0V1bOacxI3FRDHm7CGOqugsrL8ZJ4VJRMKW6qxeM/7 mNI5xUGjONEFrTkV5c/u5E9CUxEg1YgBAFRYFVQAENGs4M3dzM9WmzsImC+qfL9HFRAL5SoMXRMN vc/q69AW9U9PGQs/7Q9ahSE6DYksNZ8tNdIvzdCJ+FXQoNCMeFVY/VZBBdWjoE/WRNTD4hCEKrQD 1VbI0CtE7au/CiwkXdLCurLD0oKU6NKZElcVIdQ9EtWhMFTTjLmvIh7+1LmDdVRWWqGOANQBwApv hdWjaNb/OYJQoXhWGsHYn7PJWl01hDKSXFU2BnVKX11YH02IV70Sb30K+pHVUAPYmhDJLunKjVXB rSDXgtWUc81RM6lXlTASdv0MOJWIlN0Il00ImSUjiw2Jlv0Vfq0umPUiTwWAhy2MT6Slpf0IdswV isWyaJ2d0WyNB1iBNDOhrOWIp+mWqVXAoHymrv0Mf5Wfs9WIPTla+fibUPpawcFO6XhbwZnbz0kY fqlG5bNZWiJR+YjbyAFch6jbkqFIr41ay5FJ6WCACjjZvmFclK2jlenRmv1KSHpJ9SBGs9Fcvl2Z k5wz0J0jz6URxY0awHVchJ2xCIAUiXi7PPOIg7Ddjjg8/95dU5xziNskWD3hk3WTXLO52imJkRKF XTykjq0y2OY01aGa3gKYAiqokJ09q6x0ASrrgbhEKAzRkCM40sycOazDgPIVCLgDLFJTuRkjz6DQ 2NfkWP2xXMztD+1YXA6EXtKjFBI4vMKKALB7kJYDTiUNrAI+krE7vCS6ogPQPOY8POB8u+PhT7Uc NeurCQFYC7bdyxYi3C7Z37aBUP9VtpXYEPNhIKZsHvP5AcCqkCkbX6zcHhfAACUgH4RqkCkzAu8t iMPKYRgOAB8OgCcArCEWiBbOz+MIWr6zqon4RaSMCWG0HMhNFBJ2XvA7YTJ6XUX0CvTKlSxmQMN1 CC7Go/8zZkXRLRbLjSXbazO18DbWHYxeXONuyYCSWBkpnuJgbAifcBGqGmMrtGN72QwwCcHXmJvF EuQXJOScfFi7xT0rWTAP4IBIlh/LVeQQpA8WhIqI/VZwxY/N6Ay6IoD9sEH6SEAWO+WiCVTc+ORY 7Y9RvuSKMWVN7sETaIz1Ai5a9tZCgeVADZBZTiVbZkXB0D6WstxDbmWcAWZavovN8ID8jRoB0Jhb ZsUMqIAwhqQBQIDLHdFgDglQdlgVqeYVyIBn7hINGJhpVsRu1mZa8uZt9uRw/oiihWUseQAOAIFl Lhm1WIqGfOd5jpxibouiTaZ6plqJ9RMKQIEEcGNn0ZL/CripnaRaDkCB5l2ZAShot1hZewZUKi1b GnkAAgABFIBoPwkBEWABBMjokowBEEAAkZ6XELAIl9YKX/aIg34YkjZplM6SlW7pihZnxenkbmEA MaNoRAxlV03onREAgAGBgelL6TABjWGBjmnnodaIhn5oZ1GBNULm14NkswDmjCBn3GmlFWij45rp sOCxGFCcNmKarR6Lnu4AqsYSBkAArFbqph7nso7lrnBqMvKw90mAFBgvDyiyBmjsa54ICmjsL4st AbM1AnC6uoaMve7rANlsEcjrhh1nwr6LhWYxyXbszO6PB7CbmZHjx1jtTWptogDm0X6LnE5t3D4j 1kYYejS7CxMAMxRIAdnGaaaeDrTObeQm7dgJMBogLiKLLROTbEX2L8mGbgQAr5twgA5AgBMY6ET5 5OQOb3UsbvEu71RK54YAZfQ2b/Z2muPuMPV21faeb6GB5fWmbYeF5NKmb/62F9F+71b+bwDvbwJH lttWaPJ+a0i+koAAADs= --=_related 0026B966482578E1_=-- From julien.meuric@orange-ftgroup.com Sun Aug 7 06:22:33 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C10421F86EE for ; Sun, 7 Aug 2011 06:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+K8OtxuzGwG for ; Sun, 7 Aug 2011 06:22:32 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 008E421F84FD for ; Sun, 7 Aug 2011 06:22:31 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9DBA66D8001; Sun, 7 Aug 2011 15:24:10 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 8E9016C8003; Sun, 7 Aug 2011 15:24:10 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 7 Aug 2011 15:22:51 +0200 Received: from [10.193.116.50] ([10.193.116.50]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 7 Aug 2011 15:22:50 +0200 Message-ID: <4E3E91A8.2000301@orange-ftgroup.com> Date: Sun, 07 Aug 2011 15:22:48 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ramon Casellas References: <95E8ECEE-858A-4EAC-8401-2D3F1BF2F113@cisco.com> <4E35EEDC.8020203@cttc.es> <1FA86AE7-EF3C-46AD-B961-58C8557291D9@cisco.com> <4E365FC1.3060805@cttc.es> In-Reply-To: <4E365FC1.3060805@cttc.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Aug 2011 13:22:50.0437 (UTC) FILETIME=[1B139F50:01CC5505] Cc: "pce@ietf.org" Subject: Re: [Pce] [OSPF] IETF 81 WG Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 13:22:33 -0000 Hi Ramon. My interference below. Cheers, Julien Le 01/08/2011 10:11, Ramon Casellas a écrit : > El 01/08/2011 6:16, JP Vasseur escribió: >> >> On Jul 31, 2011, at 8:10 PM, Ramon Casellas wrote: >> >>> As detailed below, I tend to think there is a use case to be able to >>> dynamically map "TE enabled ABRs" and the domains (areas) they >>> belong to. >> >> Let's discuss this aspect. It was explained that there was a need to >> know that a router was TE-enabled to avoid a signaling failure … how >> is that different from other parameters ? > > I'm afraid I don't understand the question, sorry :) Just in case, I > did not mean that TE enabled bit was needed. For simplicity, assume > all ABRs are TE enabled. I think JP was referring to the discussion in Quebec. (If you missed it like me, audio archives may help to catch up.) During the meeting, it seemed that "there was a need to know that a router was TE-enabled to avoid a signaling failure". If it is not known a priori, it is discovered at signaling time and crankback may be used. Nonetheless, knowing that the ABR is TE-enabled is not enough: the links to the destination may still not be TE-enabled, the available bandwidth may not be enough, the SRLG/administrative groups may not suit... Thus the extension would only save very few crankbacks, and might not be worth the effort. But I note that this is not the use case you have in mind. > >> Second question is what can you do with the OSPF area ID ? I cannot >> see any reason for knowing the area ID an ABR is connected to for >> inter-area TE LSP computation ? >> > > Thinking about it, it may not be strictly needed, although I was > thinking on corner cases such as the following. Consider the topology > below (paraphrasing parts of Section 1.2 RFC 3509), where an ABR has > no backbone connection > > . . > . Area 0 . > +--+ +--+ > ..|R1|.. ..|R2|.. > . +--+ .. +--+ . > . .. . > . +--+ . > . Area1 |R3| Area2 . > . +--+ +--+ . > . .. |R4| . > . . . +--+ . > ....... ....... > Being an ABR, R3 can only consider summary-LSAs from the backbone when > building the routing table (according to section 16.2 of [RFC2328]), > so it will not have any inter-area routes in its routing table, but > only intra-area routes from both Area 1 and Area 2. Consequently, > according to section 12.4.3, R3 will originate into Areas 1 and 2 only > summary-LSAs covering destinations in the directly attached areas. At > the same time, router R2, as an ABR connected to the backbone, will > inject into Area 2 summary-LSAs describing the destinations in Area 0 > (the backbone), Area 1 and other areas reachable through the backbone. > (...) This results in a situation where internal router R4 (or PCE) > calculates its routes to destinations in the backbone and areas other > than Area 1 via R2. (Rcas: although this may be addressed with a > virtual link, as RFC3509 mentions later on) Thanks for providing this. If you believe this is an actual use case, it may be relevant to the Wenhu's I-D. You also mentions 2 significant things: it might be a corner case and existing solutions may already be enough... > > So in our use case: > > - R4 (or PCE) may want to compute an inter-area path towards some > endpoint at area1. It may also be requested to follow e.g. a domain > sequence within the IRO, listing areas 2 and 1. I would like a clean > way to consider R2 and R3 somehow differently. I believe here that > knowing the ABRs and the involved areas can be "a good thing" e.g. in > minimizing OF codes such as "minimum number of domains". of ocurse, if > there is no virtual link, I can deduce that R2 is attached to Area 0 > since it is announcing summary LSAs for Area0 and areas other than 1 > but I cannot rely on this. It looks like there a lots of assumptions here. Per area-PCE function out of ABRs? If so, why using PCE? The PCE architecture already provides some solutions to that problem: PCE-capable ABR, virtual link between PCE and remote areas... Before moving forward, I think the context should be elaborated. > > - If PCE within Area1 does not support BRPC/VPST, This reads to me like "if the existing solution is not supported, let us define a solution". :-) Both scenarios would require upgrade, so what motives another one? > PCE in Area2 could explicitly select P2P paths from R3, selecting > those ABRs that are directly attached to Area1. Knowing that R2 is not > directly attached to Area1 allows PCE within area 2 to not request the > R2 path. So it seems that it would help in reducing the number of requests to be sent. But what if, instead of R3, we have R3a and R3b? It would not help here, while VSPT does. > > - Knowing the area ids of the ABRs provides a simple mechanism to > somehow deduce a domain sequence and trigger the approporiate mechanism. I like "simple". But adding a simple extension to address corner cases is still introducing complexity somewhere... Currently, the question is on the use cases for advertising area IDs: there might be some, but they are not obvious to me yet. > > > > Finally, somehow unrelated but in a wider scope, I am still wondering > whether "deducing" things directly from summary LSAs rather that from > dedicated opaque information that clearly decouples control and data > plane is the right thing to do. Ideally (augmented) TED info should be > self-contained in opaques :) Opinions from others about this issue would be valuable. > > Probably I am missing something, so I'd be happy to stand corrected :) > > Thanks > R. > > -- > Ramon Casellas, Ph.D. > Research Associate - Optical Networking Area --http://wikiona.cttc.es > CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 > Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain > Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From daniel@olddog.co.uk Sun Aug 7 07:35:52 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C952521F86EE for ; Sun, 7 Aug 2011 07:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.958 X-Spam-Level: X-Spam-Status: No, score=-100.958 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5kh-xmNIqzt for ; Sun, 7 Aug 2011 07:35:52 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1457421F86C4 for ; Sun, 7 Aug 2011 07:35:51 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p77Ea8NL002540 for ; Sun, 7 Aug 2011 15:36:12 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p77Ea7ah002519 for ; Sun, 7 Aug 2011 15:36:08 +0100 From: "Daniel King" To: Date: Sun, 7 Aug 2011 15:36:02 +0100 Message-ID: <011801cc550f$558bfdd0$00a3f970$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0119_01CC5517.B750DB00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxVDwYuYrN1Yas4TAiyHykUJMPNGA== Content-Language: en-gb Subject: [Pce] IETF 81 PCE Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 14:35:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0119_01CC5517.B750DB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, The PCE minutes (thanks to Meral) for IETF 81 have been uploaded: http://www.ietf.org/proceedings/81/minutes/pce.htm If you have any amendments or comments please email me and CC the co-chairs by August 19th, 2011. Br, Dan. ------=_NextPart_000_0119_01CC5517.B750DB00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All, =

 

The PCE minutes (thanks to Meral) for IETF 81 have = been uploaded:

 

http://www.ie= tf.org/proceedings/81/minutes/pce.htm

 

If you have = any amendments or comments please email me and CC the co-chairs by = August 19th, 2011.

 

Br, = Dan.           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;        

= ------=_NextPart_000_0119_01CC5517.B750DB00-- From ramon.casellas@cttc.es Sun Aug 7 10:49:06 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC95521F86C7 for ; Sun, 7 Aug 2011 10:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Asj3pXiHtyDB for ; Sun, 7 Aug 2011 10:49:06 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id BDCBA21F85FF for ; Sun, 7 Aug 2011 10:49:05 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p77Hn95H013292 for ; Sun, 7 Aug 2011 19:49:14 +0200 Received: from [10.1.10.16] (unknown [10.1.10.16]) by castor (Postfix) with ESMTP id 11BB92FC27A for ; Sun, 7 Aug 2011 19:49:11 +0200 (CEST) Message-ID: <4E3ED015.2030606@cttc.es> Date: Sun, 07 Aug 2011 19:49:09 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110801 Thunderbird/6.0 MIME-Version: 1.0 To: pce@ietf.org References: <95E8ECEE-858A-4EAC-8401-2D3F1BF2F113@cisco.com> <4E35EEDC.8020203@cttc.es> <1FA86AE7-EF3C-46AD-B961-58C8557291D9@cisco.com> <4E365FC1.3060805@cttc.es> <4E3E91A8.2000301@orange-ftgroup.com> In-Reply-To: <4E3E91A8.2000301@orange-ftgroup.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Sun, 07 Aug 2011 19:49:12 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] [OSPF] IETF 81 WG Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 17:49:07 -0000 Dear Julien, PCErs See inline tagged [Ramon] On 08/07/2011 03:22 PM, Julien Meuric wrote: >> I'm afraid I don't understand the question, sorry :) Just in case, I >> did not mean that TE enabled bit was needed. For simplicity, assume >> all ABRs are TE enabled. > I think JP was referring to the discussion in Quebec. (If you missed > it like me, audio archives may help to catch up.) > During the meeting, it seemed that "there was a need to know that a > router was TE-enabled to avoid a signaling failure". If it is not > known a priori, it is discovered at signaling time and crankback may > be used. Nonetheless, knowing that the ABR is TE-enabled is not > enough: the links to the destination may still not be TE-enabled, the > available bandwidth may not be enough, the SRLG/administrative groups > may not suit... Thus the extension would only save very few > crankbacks, and might not be worth the effort. > But I note that this is not the use case you have in mind. [Ramon] thanks for the explanation :) indeed, I consider this two different things > >> >>> Second question is what can you do with the OSPF area ID ? I cannot >>> see any reason for knowing the area ID an ABR is connected to for >>> inter-area TE LSP computation ? >> Being an ABR, R3 can only consider summary-LSAs from the backbone >> when building the routing table (according to section 16.2 of >> [RFC2328]), so it will not have any inter-area routes in its routing >> table, but only intra-area routes from both Area 1 and Area 2. >> Consequently, according to section 12.4.3, R3 will originate into >> Areas 1 and 2 only summary-LSAs covering destinations in the directly >> attached areas. At the same time, router R2, as an ABR connected to >> the backbone, will inject into Area 2 summary-LSAs describing the >> destinations in Area 0 (the backbone), Area 1 and other areas >> reachable through the backbone. (...) This results in a situation >> where internal router R4 (or PCE) calculates its routes to >> destinations in the backbone and areas other than Area 1 via R2. >> (Rcas: although this may be addressed with a virtual link, as RFC3509 >> mentions later on) > Thanks for providing this. If you believe this is an actual use case, > it may be relevant to the Wenhu's I-D. You also mentions 2 significant > things: it might be a corner case and existing solutions may already > be enough... > [Ramon] I am not sure how "corner" this case is :) but I would guess that multi-homed areas, with one or more ABRs connected to area 0 and one or more ABRs connected to "neighbor" areas it's quite common, and may be improved? I understand that, being OSPF-TE and all areas having to be attached to Area 0, the restriction simplifies a lot of things with regard to arbitrary domain meshes. This is to me, as you may guess, a main argument _against_ what is proposed. For reference below, consider Figure 1 +-----------------------------+ | Area 0 (v) | | | +--A---B--+--C-----D---+--E---+ | | | | Area 1 X Area 2 | Area 3 | | Z | Y (u) | | | | +---------+------------+------+ >> >> So in our use case: >> >> - R4 (or PCE) may want to compute an inter-area path towards some >> endpoint at area1. It may also be requested to follow e.g. a domain >> sequence within the IRO, listing areas 2 and 1. I would like a clean >> way to consider R2 and R3 somehow differently. I believe here that >> knowing the ABRs and the involved areas can be "a good thing" e.g. in >> minimizing OF codes such as "minimum number of domains". of ocurse, >> if there is no virtual link, I can deduce that R2 is attached to Area >> 0 since it is announcing summary LSAs for Area0 and areas other than >> 1 but I cannot rely on this. > It looks like there a lots of assumptions here. Per area-PCE function > out of ABRs? If so, why using PCE? The PCE architecture already > provides some solutions to that problem: PCE-capable ABR, virtual link > between PCE and remote areas... Before moving forward, I think the > context should be elaborated. [Ramon] I would like to decouple the roles of ABR and PCE. Although deploying PCEs in ABR has some advantages, it is not mandatory. We consider one PCE per area, which may have several ABRs. I would not exclude my case :) of "one area, one PCE in the middle" . Moreover, if being area 2, we have the aforementioned one or more ABRs towards area 0, one or more ABRs towards area 1 (left/west) and one or more ABRs towards area 3 (right/east) wouldn't we need 2 or more PCEs (without considering the PCEs that also should be in the neighboring areas) ? > >> >> - If PCE within Area1 does not support BRPC/VPST, > This reads to me like "if the existing solution is not supported, let > us define a solution". :-) Both scenarios would require upgrade, so > what motives another one? > [Ramon] Agreed :) the fact that PCE with area 1 did not support BRPC was to simplify the example, in order for the upstream PCE to request only the "downstream segment". >> PCE in Area2 could explicitly select P2P paths from R3, selecting >> those ABRs that are directly attached to Area1. Knowing that R2 is >> not directly attached to Area1 allows PCE within area 2 to not >> request the R2 path. > So it seems that it would help in reducing the number of requests to > be sent. But what if, instead of R3, we have R3a and R3b? It would not > help here, while VSPT does. [Ramon] Yes, multiple ABRs would almost imply BRPC for performance, yet the mapping of ABRs to neighboring areas remains the same problem. Although I do understand your points and current things can somehow be made to work, allow me a further example. Consider that we want to compute a Path from (u) to (v) and either we want to honor a domain sequence (2, 1, 0), or PCE2 does not know of PCE0, or other potential cases... 1.- PCE2 will select PCE1 (any discovery or assume PCED OSPF extensions) and send the request. 2.- PCE2 will select PCE0. 3.- PCE0 will receive the request: RP(1, vspt=true) ENDPOINTS(u, v): 4.- It needs to apply BRPC so the upstream PCE will be able to reduce/trim paths. - It needs to obtain the entry nodes to the domain. Note that there are three aspects: a) the domain sequence, the PCE sequence and the location reachability of endpoints. If it is only based on reachability, what prevents PCE0 from just replying the paths { {C, v} {D, v} } ? If it is based on reachability info plus PCE considerations it has several choices: { A, B } , { C, D } purely based on summaries, { A, B, C, D } others? Considering the example, it would make sense to restrict the VSPT to A and B. To select a subset of ABRs (note that the "domain sequence" may or may not be present): a) It could use the PCE1 address, but this is mixing things, the entity acting as a PCC could be located anywhere (e.g. a parent PCE or an NMS). It should use the source endpoint to select the entry border nodes. b) it could check the domain sequence (if present 2, 1, 0) identify the upstream domain (1) or map the requester PCE to a domain (1) using NEIGH_DOMAIN PCED extensions, but the previous point still applies c) it could check the domain sequence (if present 2, 1, 0) identify the upstream domain (1) and select from the border nodes those that are attached to area 1 (A and B) d) Other (existing? mechanisms) involve summary / external LSA, hopefully with different metrics, etc. can we guarantee this? My personal preference is c) Of course, any subset of entry border nodes will "work" since PCE1 will end up filtering to its own exit nodes, but some paths may be wasted? >> - Knowing the area ids of the ABRs provides a simple mechanism to >> somehow deduce a domain sequence and trigger the approporiate mechanism. > > I like "simple". But adding a simple extension to address corner cases > is still introducing complexity somewhere... Currently, the question > is on the use cases for advertising area IDs: there might be some, but > they are not obvious to me yet. [Ramon] The "cornicity" :) of the proposed use case is not clear yet, and the simple extension does not change in any form what is currently available. If you have the info, you may use it. If not, nothing changes. >> Finally, somehow unrelated but in a wider scope, I am still wondering >> whether "deducing" things directly from summary LSAs rather that from >> dedicated opaque information that clearly decouples control and data >> plane is the right thing to do. Ideally (augmented) TED info should >> be self-contained in opaques :) > Opinions from others about this issue would be valuable. [Ramon] I guess this last sentence somehow wraps and summarizes my point. Feedback on this would be greatly appreciated, towards a self-contained augmented TED with border nodes and reachability info. Thanks for reading (longer than expected) R. From ramon.casellas@cttc.es Sun Aug 7 10:58:31 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856F721F8777 for ; Sun, 7 Aug 2011 10:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD18GfGR7P6R for ; Sun, 7 Aug 2011 10:58:31 -0700 (PDT) Received: from aquila.cttc.es (aquila.cttc.es [84.88.62.230]) by ietfa.amsl.com (Postfix) with ESMTP id ABD6921F8770 for ; Sun, 7 Aug 2011 10:58:30 -0700 (PDT) Received: from leo (leo.cttc.es [84.88.62.208]) by aquila.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p77JvYQ4019209 for ; Sun, 7 Aug 2011 21:57:36 +0200 Received: from [10.1.10.16] (unknown [10.1.10.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 3CA41200E4 for ; Sun, 7 Aug 2011 19:58:42 +0200 (CEST) Message-ID: <4E3ED24B.6020505@cttc.es> Date: Sun, 07 Aug 2011 19:58:35 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110801 Thunderbird/6.0 MIME-Version: 1.0 To: pce@ietf.org References: <95E8ECEE-858A-4EAC-8401-2D3F1BF2F113@cisco.com> <4E35EEDC.8020203@cttc.es> <1FA86AE7-EF3C-46AD-B961-58C8557291D9@cisco.com> <4E365FC1.3060805@cttc.es> <4E3E91A8.2000301@orange-ftgroup.com> <4E3ED015.2030606@cttc.es> In-Reply-To: <4E3ED015.2030606@cttc.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.4 (leo [0.0.0.0]); Sun, 07 Aug 2011 19:58:42 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.230 Subject: Re: [Pce] [OSPF] IETF 81 WG Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 17:58:31 -0000 On 08/07/2011 07:49 PM, Ramon Casellas wrote: > > 2.- PCE2 will select PCE0. > err s/PCE2/PCE1 > My personal preference is c) Of course, any subset of entry border > nodes will "work" since PCE1 will end up filtering to its own exit > nodes, but some paths may be wasted? > it should say "c). Of course" R. From wenhu.lu@ericsson.com Mon Aug 8 12:42:55 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7491A11E8082 for ; Mon, 8 Aug 2011 12:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC+K0BLqq2zM for ; Mon, 8 Aug 2011 12:42:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 749B211E8081 for ; Mon, 8 Aug 2011 12:42:54 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p78Jh6e2011663; Mon, 8 Aug 2011 14:43:17 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 8 Aug 2011 15:43:14 -0400 From: Wenhu Lu To: Julien Meuric , Ramon Casellas Date: Mon, 8 Aug 2011 15:43:12 -0400 Thread-Topic: [Pce] [OSPF] IETF 81 WG Minutes Thread-Index: AcxVBTNHfBZ9LLXDR+CuX9EJ2axDtAA+PFDw Message-ID: <8249B703AE8442429AF89B86E8206AA26F415592AD@EUSAACMS0703.eamcs.ericsson.se> References: <95E8ECEE-858A-4EAC-8401-2D3F1BF2F113@cisco.com> <4E35EEDC.8020203@cttc.es> <1FA86AE7-EF3C-46AD-B961-58C8557291D9@cisco.com> <4E365FC1.3060805@cttc.es> <4E3E91A8.2000301@orange-ftgroup.com> In-Reply-To: <4E3E91A8.2000301@orange-ftgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] [OSPF] IETF 81 WG Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 19:42:55 -0000 Hi Julien, My comments inline.=20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Julie= n Meuric Sent: Sunday, August 07, 2011 6:23 AM To: Ramon Casellas Cc: pce@ietf.org Subject: Re: [Pce] [OSPF] IETF 81 WG Minutes Hi Ramon. My interference below. Cheers, Julien Le 01/08/2011 10:11, Ramon Casellas a =E9crit : > El 01/08/2011 6:16, JP Vasseur escribi=F3: >> >> On Jul 31, 2011, at 8:10 PM, Ramon Casellas wrote: >> >>> As detailed below, I tend to think there is a use case to be able to=20 >>> dynamically map "TE enabled ABRs" and the domains (areas) they=20 >>> belong to. >> >> Let's discuss this aspect. It was explained that there was a need to=20 >> know that a router was TE-enabled to avoid a signaling failure . how=20 >> is that different from other parameters ? > > I'm afraid I don't understand the question, sorry :) Just in case, I=20 > did not mean that TE enabled bit was needed. For simplicity, assume=20 > all ABRs are TE enabled. I think JP was referring to the discussion in Quebec. (If you missed it lik= e me, audio archives may help to catch up.) During the meeting, it seemed t= hat "there was a need to know that a router was TE-enabled to avoid a signa= ling failure". If it is not known a priori, it is discovered at signaling t= ime and crankback may be used.=20 Nonetheless, knowing that the ABR is TE-enabled is not enough: the links to= the destination may still not be TE-enabled,=20 [wenhu] That is right. Router-level TE-enable info is too coarse. The draft= covers the link cases exactly as your mentioned. the available bandwidth may not be enough, the SRLG/administrative groups m= ay not suit...=20 [wenhu] The intra-area CSPF is designed to handle these. The draft doesn't = reinvent them. Thus the extension would only save very few crankbacks, and might not be wo= rth the effort. [wenhu] Savings? Methods like BRPC doesn't even work and is blind in terms = of following area sequence. Regards, -wenhu But I note that this is not the use case you have in mind. > >> Second question is what can you do with the OSPF area ID ? I cannot=20 >> see any reason for knowing the area ID an ABR is connected to for=20 >> inter-area TE LSP computation ? >> > > Thinking about it, it may not be strictly needed, although I was=20 > thinking on corner cases such as the following. Consider the topology=20 > below (paraphrasing parts of Section 1.2 RFC 3509), where an ABR has=20 > no backbone connection > > . . > . Area 0 . > +--+ +--+ > ..|R1|.. ..|R2|.. > . +--+ .. +--+ . > . .. . > . +--+ . > . Area1 |R3| Area2 . > . +--+ +--+ . > . .. |R4| . > . . . +--+ . > ....... ....... > Being an ABR, R3 can only consider summary-LSAs from the backbone when=20 > building the routing table (according to section 16.2 of [RFC2328]),=20 > so it will not have any inter-area routes in its routing table, but=20 > only intra-area routes from both Area 1 and Area 2. Consequently,=20 > according to section 12.4.3, R3 will originate into Areas 1 and 2 only=20 > summary-LSAs covering destinations in the directly attached areas. At=20 > the same time, router R2, as an ABR connected to the backbone, will=20 > inject into Area 2 summary-LSAs describing the destinations in Area 0=20 > (the backbone), Area 1 and other areas reachable through the backbone. > (...) This results in a situation where internal router R4 (or PCE)=20 > calculates its routes to destinations in the backbone and areas other=20 > than Area 1 via R2. (Rcas: although this may be addressed with a=20 > virtual link, as RFC3509 mentions later on) Thanks for providing this. If you believe this is an actual use case, it ma= y be relevant to the Wenhu's I-D. You also mentions 2 significant things: it might be a corner case and existing solutions may already be eno= ugh... > > So in our use case: > > - R4 (or PCE) may want to compute an inter-area path towards some=20 > endpoint at area1. It may also be requested to follow e.g. a domain=20 > sequence within the IRO, listing areas 2 and 1. I would like a clean=20 > way to consider R2 and R3 somehow differently. I believe here that=20 > knowing the ABRs and the involved areas can be "a good thing" e.g. in=20 > minimizing OF codes such as "minimum number of domains". of ocurse, if=20 > there is no virtual link, I can deduce that R2 is attached to Area 0=20 > since it is announcing summary LSAs for Area0 and areas other than 1=20 > but I cannot rely on this. It looks like there a lots of assumptions here. Per area-PCE function out o= f ABRs? If so, why using PCE? The PCE architecture already provides some so= lutions to that problem: PCE-capable ABR, virtual link between PCE and remo= te areas... Before moving forward, I think the context should be elaborated= . > > - If PCE within Area1 does not support BRPC/VPST, This reads to me like "if the existing solution is not supported, let us de= fine a solution". :-) Both scenarios would require upgrade, so what motives= another one? > PCE in Area2 could explicitly select P2P paths from R3, selecting=20 > those ABRs that are directly attached to Area1. Knowing that R2 is not=20 > directly attached to Area1 allows PCE within area 2 to not request the > R2 path. So it seems that it would help in reducing the number of requests to be sen= t. But what if, instead of R3, we have R3a and R3b? It would not help here,= while VSPT does. > > - Knowing the area ids of the ABRs provides a simple mechanism to=20 > somehow deduce a domain sequence and trigger the approporiate mechanism. I like "simple". But adding a simple extension to address corner cases=20 is still introducing complexity somewhere... Currently, the question is=20 on the use cases for advertising area IDs: there might be some, but they=20 are not obvious to me yet. > > > > Finally, somehow unrelated but in a wider scope, I am still wondering=20 > whether "deducing" things directly from summary LSAs rather that from=20 > dedicated opaque information that clearly decouples control and data=20 > plane is the right thing to do. Ideally (augmented) TED info should be=20 > self-contained in opaques :) Opinions from others about this issue would be valuable. > > Probably I am missing something, so I'd be happy to stand corrected :) > > Thanks > R. > > --=20 > Ramon Casellas, Ph.D. > Research Associate - Optical Networking Area --http://wikiona.cttc.es > CTTC - Centre Tecnol=F2gic de Telecomunicacions de Catalunya, PMT Ed B4 > Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain > Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From ramon.casellas@cttc.es Mon Aug 15 12:17:16 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A764411E80E2 for ; Mon, 15 Aug 2011 12:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5x+hloWXSsv for ; Mon, 15 Aug 2011 12:17:15 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 0488811E80D7 for ; Mon, 15 Aug 2011 12:17:14 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7FJHJhU027235; Mon, 15 Aug 2011 21:17:24 +0200 Received: from [192.168.0.193] (unknown [95.62.145.63]) by castor (Postfix) with ESMTP id EBD362FC246; Mon, 15 Aug 2011 21:17:19 +0200 (CEST) Message-ID: <4E4970BE.6040002@cttc.es> Date: Mon, 15 Aug 2011 21:17:18 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110809 Thunderbird/6.0 MIME-Version: 1.0 To: pce@ietf.org, Dhruv Dhody Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Mon, 15 Aug 2011 21:17:20 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: [Pce] Comments / review of draft-dhody-pce-pcep-domain-sequence-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 19:17:16 -0000 Dear Dhruv, all PCErs Please find below a (rather long, apologies in advance) review and comments for draft-dhody-pce-pcep-domain-sequence-00. First and foremost, I believe the draft addresses a couple of much-needed extensions, namely, area sub-objects encoding and domain sequences. Following chairs suggestion to foster discussion, I am sending directly to the main mailing list. Comments and discussions welcome :) Encoding of a Domain Sequence ================================ I agree that using the Include Route Object (IRO) is a natural choice rather than adding a new object class. However, I have some doubts as detailed below. I may have missed previous discussions on this topic. For the actual encoding, basically the options we have are: a) Keep the RFC5440 IRO object (Object class 10, object type 1) b) Use a new IRO object (Object class 10, object type 2) i.e. "the request includes/refers to a domain sequence". In this case: b.1. that replaces current one with better defined semantics and scenarios b.2. that complements (can be together with) current one, requires changes in the PCEP request grammar. c) Propose a new object class i.e. DOMAIN_SEQUENCE It isn't clear to me which option is best. The reasons for this are several. The first option, which is the one proposed in the draft has, imho, some drawbacks, some of them due to the strictest interpretation of IRO as defined in RFC5440. 1. _Object Ordering_ Unfortunately RFC5440 does not mention anything regarding sub-object ordering, it only says "to specify that the computed path MUST traverse a set of specified network elements" and does not include some text in the spirit of "Objects within an IRO object MUST appear in the resulting ERO in the same order that they appear in the IRO". Unless I am mistaken, this means that, at least in theory, we should not make assumptions whether the sub-objects included in the IRO shall appear in the resulting ERO in the same relative ordering. An implementation is free to iterate the IRO subobjects, mark the nodes and links that appear in the IRO and execute some kind of traveling salesman problem that makes sure that the path travereses the referred elements, albeit the order is not guaranteed. - The relative object ordering, however, is fundamental in the domain sequence. This can be made explicit in the new type, i.e. we can clearly define new procedures and restrictions for a new object type. 2. _Different Scopes_ - Using new object or different object types easily differentiates two different scopes. This was already done with RFC5440 BANDWIDTH object, so type 2 means "bandwidth for re-optimization", or with draft-ietf-pce-gmpls with the ENDPOINTS / BANDWIDTH object since it was mentioned that the strictest interpretation of RFC5440 forbids this object to have TLVs. With a different type or class one IRO(10,1) can refer to objects to be included within the current domain and the other IRO(10,2) strictly to the domain sequence. - It is easier for an implementation to check type 1 for algorithmic constraints and to check type 2 for domain sequence and "next PCE" resolution. In a typical implementation, this may be done at different places. In other words, a PCE may be able to support a domain sequence which is used for next PCE resolution / BRPC / etc. but may not be support an element based IRO since e.g. the backend algorithms may be based on some CSPF or Dijkstra path computation. What should this PCE do? a new class or new type could help. For example, a new type can clearly state that a IRO (10,2) with the p-bit set means, for example, that Domain sequence must be honored, and that elements within a TE domain MAY be honored. 3. _Limited Procedures_ - Nothing is said in IRO and XRO objects what the procedures are when a sub-object is not found. In XRO the straighforward option is to simply ignore the unknown subobject. It is not clear to me what should be the default procedure for an unkonwn IRO subobject. It could be ignored or it could trigger an error. If we apply this to the domain sequence, I would say that an unknown subobject at this level should trigger some kind of high level error, like "PCE domain chain broken" or similiar - An IRO object with a p-bit (mandatory) set, means that the object must be processed so, imho, means that the resulting ERO must contain the elements in the IRO. This can be enforced / checked with the subobjects are TED elements, but it is not clear how to proceed with Areas and AS. - Does not support areas, and nothing is said regarding the order of areas and AS. 4. _Strict vs Loose_ - RFC 5440 clearly states "The L bit of such sub-object has no meaning within an IRO". If we now allow domain sequences, is there any use case where having loose objects makes sense? For example, one may have AS domain sequence with some AS being "loose". This is somehow against current IRO. Option c) has also several drawbacks, notably that it could end up somehow redundant with IRO if we want to be able to specify domain sequences while also imposing also border nodes and/or inter-domain links. I think that my personal preference would be using a new IRO object type (e.g. 2) which could be extended to include Areas, AS, clarify ordering, improve semantics and better define procedures. This new IRO "replaces" or "extends" the old IRO and may appear where IRO(10,1) appears. A single intra domain PCE could use "regular" IRO, while the new type conveys "multi-domain information". If the preferred option is to keep (10,1) the draft should clarify procedures but this could somehow contradict RFC5440? As stated above, my main driver to suggest another type is the previous work where a new type has been added where RFC5440 was strict. Area encoding =================== The following encoding is proposed for Area IDs: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Area Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area Id (continued) | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | // ISIS Area ID // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ However, with the additional constraint for ISIS: "The Length MUST be at least 4, and MUST be a multiple of 4." This implies that there will be padding at the end, or a reserved field, which is not clear neither from the text or the figure. An alternetive proposed encoding would be (uint32_t alignment): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // ISIS Area ID // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If, as Adrian mentioned in some old mail, 4-byte ASes need to be taken into account 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext AS Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Scenarios ======================= I believe that the draft should also address or just mention those cases where there are additional restrictions or constraints covering which border nodes (ABRs, ASBRs) or border links (InterAS links) while defining a domain sequence. e.g. AS100, IPv4 prefix, AS200 e.g. Area0, ABR1, Area1 In Section3.3.1 It is somehow confusing to mention that Both AS are made of area 0, somehow mixing "deployment scenarios" and "examples". I think that a domain sequence made of AS only subobjects is independent of whether the ASes are, in turn, divided into IGP areas or not. In other words, a domain sequence composed of only AS is only a high level description of the domains that the path must traverse, regardless of the areas. The domain sequence may or may not incude IGP areas . Maybe the draft needs a formal section that details how the domain sequence is encoded, before jumping into deployment scenarios / examples. A rough draft, not checked, and to be discussed would be as follows: For reference, current RFC5440 basically is IRO ::= element-list ::= [] element := | | | If we want to clearly define ordering and preferred format, a proposed grammar could be of the form IRO ::= | | 1) inter-AS IRO ::= [] An inter-AS IRO is composed of a part regarding the current AS followed by one or more AS parts 2) intra-AS IRO ::= [ ] An Intra-AS IRO is optionally qualified by an AS subobject followed by one or more area IROs. 3) intra-Area IRO ::= An Intra Area IRO is optionally qualified by an area subobject followed by one or more intra-area (i.e. TE domain) elements. where 4) ::= [] 5) AS ::= [] An AS list has one or more AS-level IROs, each AS-level IRO has one AS subobject optionally followed by one or more area-level IRO which has an Area subobject (in turn, optionally followed by network elements) 6) ::= [] 7) area ::= [] [] 8) element-list ::= [] 9) element := | | referring to RFC5440 IRO subobjects. And to cover AS inter-AS links 10) AS ::= [ | ] Example of Inter-AS IRO ======================================= node1, node2, area2, AS100, AS200, area2, area3 <-----------><-----><------><----> <-----------> area area AS area list <------------------><------><------------------> area list AS AS <-----------------><---------------------------> IntraAS AS list So the main points are: a) optimal encoding of domain sequence b) suggestion for IGP area subobjects and c) formal (RBNF) specification of domain sequences within the IRO Thanks for reading Ramon From dhruvd@huawei.com Mon Aug 15 22:17:16 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECA511E8085 for ; Mon, 15 Aug 2011 22:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLKnND+Jdpxd for ; Mon, 15 Aug 2011 22:17:10 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 56FB121F86FF for ; Mon, 15 Aug 2011 22:17:09 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ000M179DT34@szxga03-in.huawei.com> for pce@ietf.org; Tue, 16 Aug 2011 13:17:53 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ000ER79DTD7@szxga03-in.huawei.com> for pce@ietf.org; Tue, 16 Aug 2011 13:17:53 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQ00001I9DQ5U@szxml04-in.huawei.com> for pce@ietf.org; Tue, 16 Aug 2011 13:17:53 +0800 (CST) Date: Tue, 16 Aug 2011 10:47:50 +0530 From: Dhruv Dhody In-reply-to: <4E4970BE.6040002@cttc.es> To: 'Ramon Casellas' , pce@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4862 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_VtMUErEd/vzaPrJZb60uZA)" Thread-index: AcxbgAaB5lWLZV+iRSCb8mcbzfFXvQATX5qA References: <4E4970BE.6040002@cttc.es> Subject: Re: [Pce] Comments / review of draft-dhody-pce-pcep-domain-sequence-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 05:17:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_VtMUErEd/vzaPrJZb60uZA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Ramon and PCE-WG, (1) Encoding of Domain Seq in IRO. I like your suggestion to have new IRO object (Object class 10, object type 2). This will allow us to add clear rules of processing with respect to domain sequence. We can add text in the draft to define clear behaviour while processing this new IRO object type. Request WG to weight in this option. (2) Area Encoding I have kept the subobject similar to IPv4/IPv6 subobjects. But I have no objection to your proposed encoding either. Wrt to AS Number subobject (type=32) as defined in RFC 3209 allow only 2 octet AS Number. WG Chair/Area director: How to handle this - (a) Update to RSVP RFC 3209? (b) Errata to RSVP RFC 3209? (c) New subobject to be defined in this draft to handle 4-byte AS Number? Request Chairs/AD to comment. (3) Scenarios BN (Boundary Node) and inter-as TE link information be part of domain sequence? Hmmm. Adding this optional information in-case the administrator want to exert control by pre-selecting the BNs and inter-AS link, this deployment scenario can be added as well. We can rearrange the section in the draft to handle scenarios and examples separately. For section 3.3.1, if the domain sequence is made up of only AS, then in that case PCE should be able to select the next PCE without any ambiguity. In the example, just the AS number is enough. If the AS is further made up of multiple areas and there is a separate PCE serving each area. PCE should be able to select the next PCE correctly only when both AS and Area information is available. Thus a distinction was made. If adding RBNF gives more clarity to draft, am all for it! Ramon: I wanted to thank you for such detail review, as you have suggested detailed text to the draft; we can co-author the draft so that all your suggestions/texts is correctly incorporated. Regards, Dhruv **************************************************************************** *********** Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Ramon Casellas [mailto:ramon.casellas@cttc.es] Sent: Tuesday, August 16, 2011 12:47 AM To: pce@ietf.org; Dhruv Dhody Subject: Comments / review of draft-dhody-pce-pcep-domain-sequence-00 Dear Dhruv, all PCErs Please find below a (rather long, apologies in advance) review and comments for draft-dhody-pce-pcep-domain-sequence-00. First and foremost, I believe the draft addresses a couple of much-needed extensions, namely, area sub-objects encoding and domain sequences. Following chairs suggestion to foster discussion, I am sending directly to the main mailing list. Comments and discussions welcome :) Encoding of a Domain Sequence ================================ I agree that using the Include Route Object (IRO) is a natural choice rather than adding a new object class. However, I have some doubts as detailed below. I may have missed previous discussions on this topic. For the actual encoding, basically the options we have are: a) Keep the RFC5440 IRO object (Object class 10, object type 1) b) Use a new IRO object (Object class 10, object type 2) i.e. "the request includes/refers to a domain sequence". In this case: b.1. that replaces current one with better defined semantics and scenarios b.2. that complements (can be together with) current one, requires changes in the PCEP request grammar. c) Propose a new object class i.e. DOMAIN_SEQUENCE It isn't clear to me which option is best. The reasons for this are several. The first option, which is the one proposed in the draft has, imho, some drawbacks, some of them due to the strictest interpretation of IRO as defined in RFC5440. 1. _Object Ordering_ Unfortunately RFC5440 does not mention anything regarding sub-object ordering, it only says "to specify that the computed path MUST traverse a set of specified network elements" and does not include some text in the spirit of "Objects within an IRO object MUST appear in the resulting ERO in the same order that they appear in the IRO". Unless I am mistaken, this means that, at least in theory, we should not make assumptions whether the sub-objects included in the IRO shall appear in the resulting ERO in the same relative ordering. An implementation is free to iterate the IRO subobjects, mark the nodes and links that appear in the IRO and execute some kind of traveling salesman problem that makes sure that the path travereses the referred elements, albeit the order is not guaranteed. - The relative object ordering, however, is fundamental in the domain sequence. This can be made explicit in the new type, i.e. we can clearly define new procedures and restrictions for a new object type. 2. _Different Scopes_ - Using new object or different object types easily differentiates two different scopes. This was already done with RFC5440 BANDWIDTH object, so type 2 means "bandwidth for re-optimization", or with draft-ietf-pce-gmpls with the ENDPOINTS / BANDWIDTH object since it was mentioned that the strictest interpretation of RFC5440 forbids this object to have TLVs. With a different type or class one IRO(10,1) can refer to objects to be included within the current domain and the other IRO(10,2) strictly to the domain sequence. - It is easier for an implementation to check type 1 for algorithmic constraints and to check type 2 for domain sequence and "next PCE" resolution. In a typical implementation, this may be done at different places. In other words, a PCE may be able to support a domain sequence which is used for next PCE resolution / BRPC / etc. but may not be support an element based IRO since e.g. the backend algorithms may be based on some CSPF or Dijkstra path computation. What should this PCE do? a new class or new type could help. For example, a new type can clearly state that a IRO (10,2) with the p-bit set means, for example, that Domain sequence must be honored, and that elements within a TE domain MAY be honored. 3. _Limited Procedures_ - Nothing is said in IRO and XRO objects what the procedures are when a sub-object is not found. In XRO the straighforward option is to simply ignore the unknown subobject. It is not clear to me what should be the default procedure for an unkonwn IRO subobject. It could be ignored or it could trigger an error. If we apply this to the domain sequence, I would say that an unknown subobject at this level should trigger some kind of high level error, like "PCE domain chain broken" or similiar - An IRO object with a p-bit (mandatory) set, means that the object must be processed so, imho, means that the resulting ERO must contain the elements in the IRO. This can be enforced / checked with the subobjects are TED elements, but it is not clear how to proceed with Areas and AS. - Does not support areas, and nothing is said regarding the order of areas and AS. 4. _Strict vs Loose_ - RFC 5440 clearly states "The L bit of such sub-object has no meaning within an IRO". If we now allow domain sequences, is there any use case where having loose objects makes sense? For example, one may have AS domain sequence with some AS being "loose". This is somehow against current IRO. Option c) has also several drawbacks, notably that it could end up somehow redundant with IRO if we want to be able to specify domain sequences while also imposing also border nodes and/or inter-domain links. I think that my personal preference would be using a new IRO object type (e.g. 2) which could be extended to include Areas, AS, clarify ordering, improve semantics and better define procedures. This new IRO "replaces" or "extends" the old IRO and may appear where IRO(10,1) appears. A single intra domain PCE could use "regular" IRO, while the new type conveys "multi-domain information". If the preferred option is to keep (10,1) the draft should clarify procedures but this could somehow contradict RFC5440? As stated above, my main driver to suggest another type is the previous work where a new type has been added where RFC5440 was strict. Area encoding =================== The following encoding is proposed for Area IDs: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Area Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area Id (continued) | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | // ISIS Area ID // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ However, with the additional constraint for ISIS: "The Length MUST be at least 4, and MUST be a multiple of 4." This implies that there will be padding at the end, or a reserved field, which is not clear neither from the text or the figure. An alternetive proposed encoding would be (uint32_t alignment): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // ISIS Area ID // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If, as Adrian mentioned in some old mail, 4-byte ASes need to be taken into account 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext AS Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Scenarios ======================= I believe that the draft should also address or just mention those cases where there are additional restrictions or constraints covering which border nodes (ABRs, ASBRs) or border links (InterAS links) while defining a domain sequence. e.g. AS100, IPv4 prefix, AS200 e.g. Area0, ABR1, Area1 In Section3.3.1 It is somehow confusing to mention that Both AS are made of area 0, somehow mixing "deployment scenarios" and "examples". I think that a domain sequence made of AS only subobjects is independent of whether the ASes are, in turn, divided into IGP areas or not. In other words, a domain sequence composed of only AS is only a high level description of the domains that the path must traverse, regardless of the areas. The domain sequence may or may not incude IGP areas . Maybe the draft needs a formal section that details how the domain sequence is encoded, before jumping into deployment scenarios / examples. A rough draft, not checked, and to be discussed would be as follows: For reference, current RFC5440 basically is IRO ::= element-list ::= [] element := | | | If we want to clearly define ordering and preferred format, a proposed grammar could be of the form IRO ::= | | 1) inter-AS IRO ::= [] An inter-AS IRO is composed of a part regarding the current AS followed by one or more AS parts 2) intra-AS IRO ::= [ ] An Intra-AS IRO is optionally qualified by an AS subobject followed by one or more area IROs. 3) intra-Area IRO ::= An Intra Area IRO is optionally qualified by an area subobject followed by one or more intra-area (i.e. TE domain) elements. where 4) ::= [] 5) AS ::= [] An AS list has one or more AS-level IROs, each AS-level IRO has one AS subobject optionally followed by one or more area-level IRO which has an Area subobject (in turn, optionally followed by network elements) 6) ::= [] 7) area ::= [] [] 8) element-list ::= [] 9) element := | | referring to RFC5440 IRO subobjects. And to cover AS inter-AS links 10) AS ::= [ | ] Example of Inter-AS IRO ======================================= node1, node2, area2, AS100, AS200, area2, area3 <-----------><-----><------><----> <-----------> area area AS area list <------------------><------><------------------> area list AS AS <-----------------><---------------------------> IntraAS AS list So the main points are: a) optimal encoding of domain sequence b) suggestion for IGP area subobjects and c) formal (RBNF) specification of domain sequences within the IRO Thanks for reading Ramon --Boundary_(ID_VtMUErEd/vzaPrJZb60uZA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear Ramon and PCE-WG,

 

(1) Encoding of Domain Seq in IRO.

I like your suggestion to have new IRO object (Object class 10, object type 2).

This will allow us to add clear rules of processing with respect to domain sequence.

We can add text in the draft to define clear behaviour while processing this new IRO object type.

 

Request WG to weight in this option.

 

(2) Area Encoding

I have kept the subobject similar to IPv4/IPv6 subobjects. But I have no objection to your proposed encoding either.

Wrt to AS Number subobject (type=32) as defined in RFC 3209 allow only 2 octet AS Number.

WG Chair/Area director: How to handle this –

(a)    Update to RSVP RFC 3209?

(b)    Errata to RSVP RFC 3209?

(c)    New subobject to be defined in this draft to handle 4-byte AS Number?

 

Request Chairs/AD to comment.

 

(3) Scenarios

BN (Boundary Node) and inter-as TE link information be part of domain sequence? Hmmm…

Adding this optional information in-case the administrator want to exert control by pre-selecting the BNs and inter-AS link, this deployment scenario can be added as well.  

 

We can rearrange the section in the draft to handle scenarios and examples separately.

For section 3.3.1, if the domain sequence is made up of only AS, then in that case PCE should be able to select the next PCE without any ambiguity. In the example, just the AS number is enough.

If the AS is further made up of multiple areas and there is a separate PCE serving each area. PCE should be able to select the next PCE correctly only when both AS and Area information is available. Thus a distinction was made.

 

If adding RBNF gives more clarity to draft, am all for it!

 

Ramon: I wanted to thank you for such detail review, as you have suggested detailed text to the draft; we can co-author the draft so that all your suggestions/texts is correctly incorporated.

 

Regards,

Dhruv

 

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

Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422

 

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

 

-----Original Message-----
From: Ramon Casellas [mailto:ramon.casellas@cttc.es]
Sent: Tuesday, August 16, 2011 12:47 AM
To: pce@ietf.org; Dhruv Dhody
Subject: Comments / review of draft-dhody-pce-pcep-domain-sequence-00

 

Dear Dhruv, all PCErs

 

Please find below a (rather long, apologies in advance) review and

comments for

draft-dhody-pce-pcep-domain-sequence-00. First and foremost, I believe

the draft

addresses a couple of much-needed extensions, namely, area sub-objects

encoding

and domain sequences. Following chairs suggestion to foster discussion, I am

sending directly to the main mailing list.

 

Comments and discussions welcome :)

 

 

Encoding of a Domain Sequence

================================

 

I agree that using the Include Route Object (IRO) is a natural choice rather

than adding a new object class. However, I have some doubts as detailed

below.

I may have missed previous discussions on this topic.

For the actual encoding, basically the options we have are:

 

a) Keep the RFC5440 IRO object (Object class 10, object type 1)

 

b) Use a new IRO object (Object class 10, object type 2) i.e. "the

request includes/refers to a domain sequence". In this case:

 

b.1. that replaces current one with better defined semantics and scenarios

 

b.2. that complements (can be together with) current one, requires

changes in

the PCEP request grammar.

 

c) Propose a new object class i.e. DOMAIN_SEQUENCE

 

It isn't clear to me which option is best. The reasons for this are several.

The first option, which is the one proposed in the draft has, imho, some

drawbacks, some of them due to the strictest interpretation of IRO as

defined in

RFC5440.

 

     1. _Object Ordering_

 

     Unfortunately RFC5440 does not mention anything regarding sub-object

     ordering, it only says "to specify that the computed path MUST traverse

     a set of specified network elements" and does not include some text in

     the spirit of "Objects within an IRO object MUST appear in the

resulting

     ERO in the same order that they appear in the IRO". Unless I am

mistaken,

     this means that, at least in theory, we should not make assumptions

whether

     the sub-objects included in the IRO shall appear in the resulting

ERO in the

     same relative ordering. An implementation is free to iterate the IRO

     subobjects, mark the nodes and links that appear in the IRO and execute

     some kind of traveling salesman problem that makes sure that the path

     travereses the referred elements, albeit the order is not guaranteed.

 

     - The relative object ordering, however, is fundamental in the domain

     sequence. This can be made explicit in the new type, i.e.  we can

clearly

     define new procedures and restrictions for a new object type.

 

 

     2. _Different Scopes_

 

     - Using  new object or different object types easily differentiates two

     different scopes. This was already done with RFC5440 BANDWIDTH

object, so type 2

     means "bandwidth for re-optimization", or with draft-ietf-pce-gmpls

with the

     ENDPOINTS / BANDWIDTH object since it was mentioned that the strictest

     interpretation of RFC5440 forbids this object to have TLVs. With a

     different type or class one IRO(10,1) can refer to objects to be

included

     within the current domain and the other IRO(10,2) strictly to the

     domain sequence.

 

     - It is easier for an implementation to check type 1 for algorithmic

     constraints and to check type 2 for domain sequence and "next PCE"

resolution.

     In a typical implementation, this may be done at different places.

In other

     words, a PCE may be able to support a domain sequence which is used

for next

     PCE resolution  / BRPC / etc. but may not be support an element

based IRO since

     e.g. the backend algorithms may be based on some CSPF or Dijkstra path

     computation. What should this PCE do? a new class or new type could

help. For

     example, a new type can clearly state that a IRO (10,2) with the

p-bit set

     means, for example, that Domain sequence must be honored, and that

elements

     within a TE domain MAY be honored.

 

 

     3. _Limited Procedures_

 

     - Nothing is said in IRO and XRO objects what the procedures are when a

     sub-object is not found. In XRO the straighforward option is to simply

     ignore the unknown subobject. It is not clear to me what should be the

     default procedure for an unkonwn IRO subobject. It could be ignored or

     it could trigger an error. If we apply this to the domain sequence, I

     would say that an unknown subobject at this level should trigger some

     kind of high level error, like "PCE domain chain broken" or similiar

 

     - An IRO object with a p-bit (mandatory) set, means that the object

must

     be processed so, imho, means that the resulting ERO must contain the

     elements in the IRO. This can be enforced / checked with the subobjects

     are TED elements, but it is not clear how to proceed with Areas and AS.

 

     - Does not support areas, and nothing is said regarding the order of

     areas and AS.

 

     4.  _Strict vs Loose_

     - RFC 5440 clearly states "The L bit of such sub-object has no meaning

     within an IRO". If we now allow domain sequences, is there any use case

     where having loose objects makes sense? For example, one may have

     AS domain sequence with some AS being "loose". This is somehow against

     current IRO.

 

 

Option c) has also several drawbacks, notably that it could end up somehow

redundant with IRO if we want to be able to specify domain sequences

while also

imposing also border nodes and/or inter-domain links.  I think that my

personal

preference would be using a new IRO object type (e.g.  2) which could be

extended to include Areas, AS, clarify ordering, improve semantics and

better

define procedures. This new IRO "replaces" or "extends" the old IRO and may

appear where IRO(10,1) appears. A single intra domain PCE could use

"regular"

IRO, while the new type conveys "multi-domain information". If the

preferred

option is to keep (10,1) the draft should clarify procedures but this could

somehow contradict RFC5440? As stated above, my main driver to suggest

another

type is the previous work where a new type has been added where RFC5440 was

strict.

 

 

 

Area encoding

===================

 

     The following encoding is proposed for Area IDs:

 

     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

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |L|    Type     |     Length    |      Area Id (4 bytes)        |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     | Area Id (continued)           |           Resvd               |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

     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

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |L|    Type     |     Length    |                               |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |

     //                        ISIS Area ID                         //

     |                                                               |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

     However, with the additional constraint for ISIS: "The Length MUST

be at least

     4, and MUST be a multiple of 4." This implies that there will be

padding at the

     end, or a reserved field, which is not clear neither from the text

or the

     figure. An alternetive proposed encoding would be (uint32_t alignment):

 

 

     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

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |L|    Type     |     Length    |         Reserved              |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                         Area Id (4 bytes)                     |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

     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

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |L|    Type     |     Length    |         Reserved              |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                                                               |

     //                        ISIS Area ID                         //

     |                                                               |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

     If, as Adrian mentioned in some old mail, 4-byte ASes need to be

     taken into account

 

     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

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |L|    Type     |     Length    |         Reserved              |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                       Ext AS Id (4 bytes)                     |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

Scenarios

=======================

 

I believe that the draft should also address or just mention those cases

where

there are additional restrictions or constraints covering which border nodes

(ABRs, ASBRs) or border links (InterAS links) while defining a domain

sequence.

 

e.g. AS100, IPv4 prefix, AS200

 

e.g. Area0, ABR1, Area1

 

 

In Section3.3.1 It is somehow confusing to mention that Both AS are made of

area 0, somehow mixing "deployment scenarios" and "examples". I think that a

domain sequence made of AS only subobjects is independent of whether the

ASes

are, in turn, divided into IGP areas or not. In other words, a domain

sequence

composed of only AS is only a high level description of the domains that the

path must traverse, regardless of the areas. The domain sequence may or

may not

incude IGP areas .

 

Maybe the draft needs a formal section that details how the domain

sequence is

encoded, before jumping into deployment scenarios / examples. A rough draft,

not checked, and to be discussed would be as follows:

 

For reference, current RFC5440 basically is

 

IRO ::= <element-list>

element-list ::= <element> [<element-list>]

element := <ipv4prefix> | <ipv6prefix> | <unnum_ifid> | <AS subobject>

 

If we want to clearly define ordering and preferred format, a proposed

grammar

could be of the form

 

IRO ::= <inter-AS IRO> | <intra-AS IRO>  | <intra-area IRO>

 

1) inter-AS IRO   ::= [<intra-AS IRO>] <AS-list>

 

     An inter-AS IRO is composed of a part regarding the current AS

     followed by one or more AS parts

 

2) intra-AS IRO   ::= [ <AS> ] <area-list>

 

     An Intra-AS IRO is optionally qualified by an AS subobject

     followed by one or more area IROs.

 

3) intra-Area IRO ::= <area>

 

     An Intra Area IRO is optionally qualified by an area subobject

     followed by one or more intra-area (i.e. TE domain) elements.

 

where

 

4) <AS-list> ::= <AS> [<AS-list>]

 

5) AS ::= <AS subobject> [<area-list>]

 

 

An AS list has one or more AS-level IROs, each AS-level IRO has one

AS subobject optionally followed by one or more area-level IRO which has

an Area subobject (in turn, optionally followed by network elements)

 

 

6) <area-list>  ::= <area> [<area-list>]

 

7) area ::= [<IGP area subobject>] [<element-list>]

 

8) element-list ::= <element> [<element-list>]

 

9) element := <ipv4prefix> | <ipv6prefix> | <unnum_ifid> referring to

RFC5440 IRO subobjects.

 

 

And to cover AS inter-AS links

 

10) AS ::= <AS subobject> [ <area-list> | <element> ]

 

 

Example of Inter-AS IRO

=======================================

 

node1, node2, area2, AS100, AS200, area2, area3

<-----------><-----><------><----> <----------->

     area      area    AS             area list

<------------------><------><------------------>

      area list        AS              AS

<-----------------><--------------------------->

      IntraAS                 AS list

 

 

So the main points are: a) optimal encoding of domain sequence b) suggestion

for IGP area subobjects and c) formal (RBNF) specification of domain

sequences

within the IRO

 

Thanks for reading

 

Ramon

 

--Boundary_(ID_VtMUErEd/vzaPrJZb60uZA)-- From ramon.casellas@cttc.es Mon Aug 15 23:54:31 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B81F11E8098 for ; Mon, 15 Aug 2011 23:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8LHSrnmRlzI for ; Mon, 15 Aug 2011 23:54:29 -0700 (PDT) Received: from aquila.cttc.es (aquila.cttc.es [84.88.62.230]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7F411E8085 for ; Mon, 15 Aug 2011 23:54:28 -0700 (PDT) Received: from leo (leo.cttc.es [84.88.62.208]) by aquila.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7G8sUw3019380; Tue, 16 Aug 2011 10:54:33 +0200 Received: from [192.168.0.193] (unknown [95.62.145.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 2B04C2010F; Tue, 16 Aug 2011 08:54:48 +0200 (CEST) Message-ID: <4E4A1435.5050500@cttc.es> Date: Tue, 16 Aug 2011 08:54:45 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110809 Thunderbird/6.0 MIME-Version: 1.0 To: Dhruv Dhody References: <4E4970BE.6040002@cttc.es> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070605030709030405070308" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.4 (leo [0.0.0.0]); Tue, 16 Aug 2011 08:54:48 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.230 Cc: pce@ietf.org Subject: Re: [Pce] Comments / review of draft-dhody-pce-pcep-domain-sequence-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 06:54:31 -0000 This is a multi-part message in MIME format. --------------070605030709030405070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dhruv Please see inline On 08/16/2011 07:17 AM, Dhruv Dhody wrote: > > Dear Ramon and PCE-WG, > > (1) Encoding of Domain Seq in IRO. > > I like your suggestion to have new IRO object (Object class 10, object > type 2). > Imho it is a good trade-off. Using type 1 would not be backwards compatible // > > (2) Area Encoding > > I have kept the subobject similar to IPv4/IPv6 subobjects. But I have > no objection to your proposed encoding either. > Indeed, that's what I thought. My proposal was motivated by: a) ISIS area restriction and b) alignment issues, e.g. in 32 bit machines Consider this #include #include struct A { uint8_t type; uint8_t len; uint32_t addr; uint16_t resv; }; struct B { uint8_t type; uint8_t len; uint16_t resv; uint32_t addr; }; int main () { std::cout << sizeof(A) << std::endl; std::cout << sizeof(B) << std::endl; return 0; } The output is 12 and 8. The compiler adds padding to align the address. > Wrt to AS Number subobject (type=32) as defined in RFC 3209 allow only > 2 octet AS Number. > Indeed, nothing changes w.r.t to the already existing AS number sub-object, but I was proposing _another_ new sub-object to also take into account 4-byte AS. See http://tools.ietf.org/html/rfc4893 Since you are already proposing Area sub-objects, you may as well include 4-byte AS > > WG Chair/Area director: How to handle this -- > > (a)Update to RSVP RFC 3209? > > (b)Errata to RSVP RFC 3209? > > (c)New subobject to be defined in this draft to handle 4-byte AS Number? > > // > If you add Area sub-objects, you may as well add 4-byte AS. We can later on address this appropriately since as you mention it is generic and may need to be addressed by ccamp? > If adding RBNF gives more clarity to draft, am all for it! > The RBNF may be overkill and/or may be simplified :) but the important point is that a detailed, generic guideline could be added and the RBNF tries to provide some formal information structure > Ramon: I wanted to thank you for such detail review, as you have > suggested detailed text to the draft; we can co-author the draft so > that all your suggestions/texts is correctly incorporated. > Thanks R. --------------070605030709030405070308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dhruv

Please see inline

On 08/16/2011 07:17 AM, Dhruv Dhody wrote:

Dear Ramon and PCE-WG,

 

(1) Encoding of Domain Seq in IRO.

I like your suggestion to have new IRO object (Object class 10, object type 2). 

Imho it is a good trade-off. Using type 1 would not be backwards compatible

 

(2) Area Encoding

I have kept the subobject similar to IPv4/IPv6 subobjects. But I have no objection to your proposed encoding either.

Indeed, that's what I thought. My proposal was motivated by: a) ISIS area restriction and b) alignment issues, e.g. in 32 bit machines
Consider this

#include <iostream>
#include <cstdint>

struct A {
        uint8_t  type;
        uint8_t  len;
        uint32_t addr;
        uint16_t resv;
};

struct B {
        uint8_t   type;
        uint8_t   len;
        uint16_t  resv;
        uint32_t  addr;
};


int main () {
        std::cout << sizeof(A) << std::endl;
        std::cout << sizeof(B) << std::endl;
        return 0;
}

The output is 12 and 8. The compiler adds padding to align the address.


Wrt to AS Number subobject (type=32) as defined in RFC 3209 allow only 2 octet AS Number.

Indeed, nothing changes w.r.t to the already existing AS number sub-object, but I was proposing _another_  new sub-object to also take into account 4-byte AS. See http://tools.ietf.org/html/rfc4893 Since you are already proposing Area sub-objects, you may as well include 4-byte AS

WG Chair/Area director: How to handle this –

(a)    Update to RSVP RFC 3209?

(b)    Errata to RSVP RFC 3209?

(c)    New subobject to be defined in this draft to handle 4-byte AS Number?

 

If you add Area sub-objects, you may as well add 4-byte AS. We can later on address this appropriately since as you mention it is generic and may need to be addressed by ccamp?


If adding RBNF gives more clarity to draft, am all for it!


The RBNF may be overkill and/or may be simplified :)  but the important point is that a detailed, generic guideline could be added and the RBNF tries to provide some formal information structure
 

 

Ramon: I wanted to thank you for such detail review, as you have suggested detailed text to the draft; we can co-author the draft so that all your suggestions/texts is correctly incorporated.

 


Thanks
R.

--------------070605030709030405070308-- From wwwrun@ietfa.amsl.com Tue Aug 16 09:50:14 2011 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id DEDA621F8B39; Tue, 16 Aug 2011 09:50:14 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110816165014.DEDA621F8B39@ietfa.amsl.com> Date: Tue, 16 Aug 2011 09:50:14 -0700 (PDT) Cc: pce@ietf.org, jpv@cisco.com Subject: [Pce] WG Action: RECHARTER: Path Computation Element (pce) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:50:15 -0000 The Path Computation Element (pce) working group in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Path Computation Element (pce) ----------------------------------- Current Status: Active Working Group Last Updated: 2011-08-11 Chairs: JP Vasseur Julien Meuric Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Secretary: Daniel King Mailing List: Address: pce@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify the required protocols so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs. In this architecture path computation does not necessarily occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on each head-end LSR. The PCE WG works on application of this model within a single domain or within a group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG specifies the PCE communication Protocol (PCEP) and needed extensions for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. Security mechanisms such as authentication and confidentiality are included. The WG determines requirements for extensions to existing routing and signaling protocols in support of the PCE architecture and the signaling of inter-domain paths (e.g. RSVP-TE and its GMPLS variations). Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The WG also works on the mechanisms to for multi-layer path computation and PCEP extensions for communication between several network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) while keeping consistency with the GMPLS architecture specified in the CCAMP WG. Work Items: - PCEP extensions for MPLS and GMPLS Traffic Engineered LSP path computation models involving PCE(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. Both intra- and inter-domain applications are covered. - In cooperation with protocol specific Working Group (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for communication in the various GMPLS-controlled networks, including WSON. - Definition of PCEP extensions for path computation in multi-layer networks. Goals and Milestones: Done Submit first draft of PCE architecture document Done Submit first draft of PCE discovery requirements and protocol extensions documents Done Submit first draft of the PCE communication protocol requirements Done Submit first draft of the definition of objective metrics Done Submit first draft of the PCE communication protocol specification Done Submit PCE architecture specification to the IESG to be considered as Informational RFC Done Submit first draft of the MIB module for the PCE protocol Done Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Done Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Done Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Done Submit first draft of the PCE P2MP communication requirements Done Submit first draft of the PCE P2MP PCEP protocol extensions Done Submit PCE P2MP communication requirements to the IESG to be considered as an Informational RFC Done Submit PCE P2MP PCEP protocol extensions to the IESG to be considered as an Proposed Standard RFC Done Submit applicability and metrics documents to the IESG Oct 2011 Submit WSON requirements to the IESG to be considered as an Informational RFC Dec 2011 Submit extensions for hierarchical PCE path computation model as WG document Jan 2012 Submit the PCEP MIB to the IESG to be considered as a Proposed Standard Jan 2012 Submit P2MP MIB as a WG document Feb 2012 Submit the discovery MIB to the IESG to be considered as a Proposed Standard Feb 2012 Submit inter-layer extensions to the IESG to be considered as a Proposed Standard Mar 2012 Submit inter-area/AS applicability statement to the IESG as an informational RFC Mar 2012 Submit PCEP extensions for WSON as a WG document Apr 2012 Submit the GMPLS requirements to the IESG to be considered as an Informational RFC Jun 2012 Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard Aug 2012 Submit PCEP extensions for WSON to the IESG to be considered as a Proposed Standard Oct 2012 Submit P2MP MIB to the IESG to be considered as a Proposed Standard Feb 2013 Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard Mar 2013 Evaluate WG progress, recharter or close From jpv@cisco.com Thu Aug 18 00:08:58 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F3821F84CC for ; Thu, 18 Aug 2011 00:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.19 X-Spam-Level: X-Spam-Status: No, score=-110.19 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Xxkfwceyxkq for ; Thu, 18 Aug 2011 00:08:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A5DC521F84CB for ; Thu, 18 Aug 2011 00:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4823; q=dns/txt; s=iport; t=1313651390; x=1314860990; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=m3hAUSs3+RvZAxgT/DZHsZWcekttPkXPh/VM+v6bIcM=; b=Unaxqf6wxrM1vEo40TW8UQTRikhdcU93xTejPoQcDKjdBE/gosMvoWxt rm8Hn1C/fjDVwHw0a2hNlcCHqpCNCLthaT+gRThrxRslidHul+OyVjinb SN97aR2TpGEO8AVggkuiGCWbVANLoj7gVoNSOR+UAq/0E0tcjLm59xdfz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC26TE6Q/khN/2dsb2JhbABBgk2mI3eBQAEBAQECAQEBAQ8BWwsFCwtGJzAGEwkZh04EmU4BnnOFaV8EkxOFFYti X-IronPort-AV: E=Sophos;i="4.68,243,1312156800"; d="scan'208,217";a="111370720" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 18 Aug 2011 07:09:47 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7I79l4v027909; Thu, 18 Aug 2011 07:09:47 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 09:09:47 +0200 Received: from ams-jvasseur-8914.cisco.com ([10.55.86.16]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 09:09:46 +0200 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_24980498-B388-4B59-915F-5A13C9CE13C6" From: JP Vasseur In-Reply-To: <011801cc550f$558bfdd0$00a3f970$@olddog.co.uk> Date: Thu, 18 Aug 2011 09:09:46 +0200 Message-Id: <3C35142F-65C3-4215-AC71-C9992147722E@cisco.com> References: <011801cc550f$558bfdd0$00a3f970$@olddog.co.uk> To: Daniel King X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 18 Aug 2011 07:09:46.0307 (UTC) FILETIME=[CFA3B130:01CC5D75] Cc: pce@ietf.org Subject: Re: [Pce] IETF 81 PCE Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 07:08:58 -0000 --Apple-Mail=_24980498-B388-4B59-915F-5A13C9CE13C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Many Thanks to Meral and Dan for the minutes. On Aug 7, 2011, at 4:36 PM, Daniel King wrote: > Hi All, > =20 > The PCE minutes (thanks to Meral) for IETF 81 have been uploaded: > =20 > http://www.ietf.org/proceedings/81/minutes/pce.htm > =20 > If you have any amendments or comments please email me and CC the = co-chairs by August 19th, 2011. > =20 > Br, Dan. = =20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce --Apple-Mail=_24980498-B388-4B59-915F-5A13C9CE13C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Many Thanks to Meral and Dan for the = minutes.

On Aug 7, 2011, at 4:36 PM, Daniel King = wrote:

Hi All,
 
The PCE minutes (thanks to = Meral) for IETF 81 have been uploaded:
 
_____= __________________________________________
Pce mailing list
Pce@ietf.org
In-Reply-To: <3C35142F-65C3-4215-AC71-C9992147722E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] IETF 81 PCE Minutes Thread-Index: AcxdddZl83DktGWaRQGLdho6gEGkyQADAkCg References: <011801cc550f$558bfdd0$00a3f970$@olddog.co.uk> <3C35142F-65C3-4215-AC71-C9992147722E@cisco.com> From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext JP Vasseur" , "Daniel King" X-OriginalArrivalTime: 18 Aug 2011 08:36:38.0690 (UTC) FILETIME=[F2763820:01CC5D81] Cc: pce@ietf.org Subject: Re: [Pce] IETF 81 PCE Minutes X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 08:35:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC5D81.F2733E76 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 The correct link is=20 http://www.ietf.org/proceedings/81/minutes/pce.html =20 BR. =20 From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of ext JP Vasseur Sent: Thursday, August 18, 2011 9:10 AM To: Daniel King Cc: pce@ietf.org Subject: Re: [Pce] IETF 81 PCE Minutes =20 Many Thanks to Meral and Dan for the minutes. =20 On Aug 7, 2011, at 4:36 PM, Daniel King wrote: Hi All, =20 The PCE minutes (thanks to Meral) for IETF 81 have been uploaded: =20 http://www.ietf.org/proceedings/81/minutes/pce.htm =20 If you have any amendments or comments please email me and CC the co-chairs by August 19th, 2011. =20 Br, Dan. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce =20 ------_=_NextPart_001_01CC5D81.F2733E76 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The correct link is

http://www.i= etf.org/proceedings/81/minutes/pce.html

 

BR.

 

From:= = pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = ext JP Vasseur
Sent: Thursday, August 18, 2011 9:10 = AM
To: Daniel King
Cc: = pce@ietf.org
Subject: Re: [Pce] IETF 81 PCE = Minutes

 

Many Thanks = to Meral and Dan for the minutes.

 

On = Aug 7, 2011, at 4:36 PM, Daniel King wrote:



Hi = All,

 =

The PCE = minutes (thanks to Meral) for IETF 81 have been = uploaded:

 =

 =

If you = have any amendments or comments please email me and CC the co-chairs by = August 19th, 2011.

 =

Br, = Dan.           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;        

_________= ______________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/m= ailman/listinfo/pce

 

------_=_NextPart_001_01CC5D81.F2733E76-- From wwwrun@rfc-editor.org Thu Aug 18 02:10:40 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3A521F8B31 for ; Thu, 18 Aug 2011 02:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrCIOkQCQiqn for ; Thu, 18 Aug 2011 02:10:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1273321F8B2E for ; Thu, 18 Aug 2011 02:10:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9A20598C234; Thu, 18 Aug 2011 02:11:33 -0700 (PDT) To: jpv@cisco.com, jeanlouis.leroux@orange-ftgroup.com, stbryant@cisco.com, adrian@olddog.co.uk, jpv@cisco.com, julien.meuric@orange-ftgroup.com From: RFC Errata System Message-Id: <20110818091133.9A20598C234@rfc-editor.org> Date: Thu, 18 Aug 2011 02:11:33 -0700 (PDT) Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Technical Errata Reported] RFC5440 (2940) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 09:10:40 -0000 The following errata report has been submitted for RFC5440, "Path Computation Element (PCE) Communication Protocol (PCEP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5440&eid=2940 -------------------------------------- Type: Technical Reported by: Ramon Casellas Section: 5 Original Text ------------- PCEP operates over TCP using a registered TCP port (4189). This allows the requirements of reliable messaging and flow control to be met without further protocol work. All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port. Corrected Text -------------- PCEP operates over TCP using a registered TCP port (4189). This allows the requirements of reliable messaging and flow control to be met without further protocol work. A PCE MUST listen for incoming connections at the registered port and a PCC SHOULD use the registered port as source port but MAY use any source port (e.g. ephemeral port). In other words, a PCC connecting to a remote PCE is not constrained to use the registered TCP port as the TCP source port, although it MAY use it. Notes ----- As discussed / agreed during IETF80, IETF81 and following chairs / AD suggestion Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5440 (draft-ietf-pce-pcep-19) -------------------------------------- Title : Path Computation Element (PCE) Communication Protocol (PCEP) Publication Date : March 2009 Author(s) : JP. Vasseur, Ed., JL. Le Roux, Ed. Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Thu Aug 18 02:27:19 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6E521F855F for ; Thu, 18 Aug 2011 02:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI9BOutdPGiY for ; Thu, 18 Aug 2011 02:27:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D255A21F854E for ; Thu, 18 Aug 2011 02:27:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9ACE198C231; Thu, 18 Aug 2011 02:28:10 -0700 (PDT) To: jpv@cisco.com, jeanlouis.leroux@orange-ftgroup.com, stbryant@cisco.com, adrian@olddog.co.uk, jpv@cisco.com, julien.meuric@orange-ftgroup.com From: RFC Errata System Message-Id: <20110818092810.9ACE198C231@rfc-editor.org> Date: Thu, 18 Aug 2011 02:28:10 -0700 (PDT) Cc: pce@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Technical Errata Reported] RFC5440 (2941) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 09:27:19 -0000 The following errata report has been submitted for RFC5440, "Path Computation Element (PCE) Communication Protocol (PCEP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5440&eid=2941 -------------------------------------- Type: Technical Reported by: Ramon Casellas Section: 10.7.1 Original Text ------------- o PCEP uses a single registered port for all communications. The PCE SHOULD listen for TCP connections only on ports where communication is expected. o The PCE SHOULD NOT allow parallel TCP connections from the same PCC on the PCEP-registered port. Corrected Text -------------- o PCEP uses a single registered port for all communications. The PCE MUST listen for TCP connections only on ports where communication is expected. o The PCE MUST NOT allow parallel TCP connections from the same PCC on the PCEP-registered port. Notes ----- RFC 5440 is not consistent regarding the use of RFC2119 keywords. In section 5 the RFC states "MUST" regarding the registered port and in section 10.7.1 it is stated "SHOULD". Section 10.7.1 seems to imply the PCE could listen at any port (which is technically possible, but not in line with the rest of the document). Finally, the restriction about multiple connections is confusing: Section 4.2.1 "Only one PCEP session can exist between a pair of PCEP peers at any one time" but section 10.7.1 uses "SHOULD NOT". Technically, without the TCP source restriction, it should be possible to accept multiple connections from a PCEP peer, but such a change could have broader implications Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5440 (draft-ietf-pce-pcep-19) -------------------------------------- Title : Path Computation Element (PCE) Communication Protocol (PCEP) Publication Date : March 2009 Author(s) : JP. Vasseur, Ed., JL. Le Roux, Ed. Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From julien.meuric@orange-ftgroup.com Mon Aug 22 02:26:07 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD5C21F8AFF for ; Mon, 22 Aug 2011 02:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae5kVc02VQnc for ; Mon, 22 Aug 2011 02:26:07 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7022B21F854D for ; Mon, 22 Aug 2011 02:26:07 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 142DE7B800F for ; Mon, 22 Aug 2011 11:28:31 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 0BC896C0001 for ; Mon, 22 Aug 2011 11:28:31 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 11:27:10 +0200 Received: from [10.193.71.150] ([10.193.71.150]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 11:27:10 +0200 Message-ID: <4E5220EE.3030701@orange-ftgroup.com> Date: Mon, 22 Aug 2011 11:27:10 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Aug 2011 09:27:10.0186 (UTC) FILETIME=[AB06CCA0:01CC60AD] Subject: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 09:26:08 -0000 Hi PCE WG. The updated charter is on line, it is now time to move some of our work forward. There has been much discussion and work about draft-zhao-pce-pcep-inter-domain-p2mp-procedures (version 7 already, formerly 2 I-Ds). This message starts a poll on adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 as WG document. Please reply to this e-mail and tell whether you support the adoption or not. Comments are always welcome to motivate answers, especially in case of disagreement. Regards, JP & Julien From daniel@olddog.co.uk Mon Aug 22 11:49:05 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD2C21F8C19 for ; Mon, 22 Aug 2011 11:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1GClJbcnmOp for ; Mon, 22 Aug 2011 11:49:05 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id C866021F8BE8 for ; Mon, 22 Aug 2011 11:49:04 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7MIo9pV009759 for ; Mon, 22 Aug 2011 19:50:09 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7MIo7QC009753 for ; Mon, 22 Aug 2011 19:50:08 +0100 From: "Daniel King" To: References: <4E5220EE.3030701@orange-ftgroup.com> In-Reply-To: <4E5220EE.3030701@orange-ftgroup.com> Date: Mon, 22 Aug 2011 19:49:57 +0100 Message-ID: <004601cc60fc$4fd81c90$ef8855b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQJ+Li6G09PY+otzcBiAhiJxmUMfyZPFmZiw Content-Language: en-gb Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 18:49:05 -0000 Hi Julien, All, First, a disclosure. I am a co-author. Second, I support the document! Br, Dan. -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: 22 August 2011 10:27 To: pce@ietf.org Subject: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Hi PCE WG. The updated charter is on line, it is now time to move some of our work forward. There has been much discussion and work about draft-zhao-pce-pcep-inter-domain-p2mp-procedures (version 7 already, formerly 2 I-Ds). This message starts a poll on adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 as WG document. Please reply to this e-mail and tell whether you support the adoption or not. Comments are always welcome to motivate answers, especially in case of disagreement. Regards, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From zali@cisco.com Mon Aug 22 12:35:02 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AAC21F8C4F for ; Mon, 22 Aug 2011 12:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ozKtwgJJQzJ for ; Mon, 22 Aug 2011 12:35:01 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD6521F8C4C for ; Mon, 22 Aug 2011 12:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=1200; q=dns/txt; s=iport; t=1314041767; x=1315251367; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=7QXqDYiI48zxin22FniVuujUXU9hu71bcViUkWGvLCw=; b=WXqIL7c5M89WZLnoMG01/7lkXZDH6o4RKw0Aw1HU0YUZIuY72gUXXOc2 z9wesuR1w7a9XByfq2FbskxozoBGr/8NGUOsAQXfp+iYIpVoEGxSidad9 MaWQRU1tEZn9EqV5m6K7vdq78GTVA+tyWGmTdgy+Og6S/2mkfGAWGcIDH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABavUk6tJV2Y/2dsb2JhbABBqBV3gUABAQEBAwEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAIEARIIGodTlikBnnOFaV8Eh2CQSYwA X-IronPort-AV: E=Sophos;i="4.68,264,1312156800"; d="scan'208";a="15427547" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 22 Aug 2011 19:36:07 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7MJa6fd031214; Mon, 22 Aug 2011 19:36:07 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 14:36:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Aug 2011 14:36:04 -0500 Message-ID: <7CC717E2F49DAA4A827DA3FEA237111B05BA3132@XMB-RCD-103.cisco.com> In-Reply-To: <004601cc60fc$4fd81c90$ef8855b0$@olddog.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Poll ondraft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Thread-Index: AQJ+Li6G09PY+otzcBiAhiJxmUMfyZPFmZiwgAAPWxA= References: <4E5220EE.3030701@orange-ftgroup.com> <004601cc60fc$4fd81c90$ef8855b0$@olddog.co.uk> From: "Zafar Ali (zali)" To: "Daniel King" , X-OriginalArrivalTime: 22 Aug 2011 19:36:06.0915 (UTC) FILETIME=[BC9D3530:01CC6102] Subject: Re: [Pce] Poll ondraft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:35:02 -0000 Support (I am one of the authors).=20 Thanks Regards ... Zafar=20 > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Julien > Meuric > Sent: 22 August 2011 10:27 > To: pce@ietf.org > Subject: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures- > 07 >=20 > Hi PCE WG. >=20 > The updated charter is on line, it is now time to move some of our work > forward. >=20 > There has been much discussion and work about > draft-zhao-pce-pcep-inter-domain-p2mp-procedures (version 7 already, > formerly 2 I-Ds). This message starts a poll on adoption of > draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 as WG document. > Please reply to this e-mail and tell whether you support the adoption or > not. Comments are always welcome to motivate answers, especially in case > of > disagreement. >=20 > Regards, >=20 > JP & Julien >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From ramon.casellas@cttc.es Mon Aug 22 23:58:23 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC1821F8B7B for ; Mon, 22 Aug 2011 23:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUPTiDYGXa8J for ; Mon, 22 Aug 2011 23:58:22 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 5214021F8B4F for ; Mon, 22 Aug 2011 23:58:21 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7N6wrFR019555; Tue, 23 Aug 2011 08:59:05 +0200 Received: from 10.217.255.145 (212-166-128-115.red-acceso.airtel.net [212.166.128.115]) by castor (Postfix) with ESMTP id 6DA882FC286; Tue, 23 Aug 2011 08:58:50 +0200 (CEST) Date: Tue, 23 Aug 2011 08:57:17 +0200 Message-ID: From: Ramon Casellas To: Julien Meuric , "pce@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Tue, 23 Aug 2011 08:58:54 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 06:58:23 -0000 U3VwcG9ydCAoYXMgYSBjb2F1dGhvcikKUi4= From huawei.danli@huawei.com Tue Aug 23 17:13:43 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03C621F8BA8 for ; Tue, 23 Aug 2011 17:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=3.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd-Vv6cJywwa for ; Tue, 23 Aug 2011 17:13:43 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABB721F8B8F for ; Tue, 23 Aug 2011 17:13:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00B0WOORD8@szxga03-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 08:14:51 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE007S1OORAF@szxga03-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 08:14:51 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ16848; Wed, 24 Aug 2011 08:14:51 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 08:14:47 +0800 Received: from l00037133 (10.70.77.146) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 08:14:50 +0800 Date: Wed, 24 Aug 2011 08:14:50 +0800 From: Dan Li X-Originating-IP: [10.70.77.146] To: Julien Meuric , pce@ietf.org Message-id: <004601cc61f2$d72b70b0$924d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4E5220EE.3030701@orange-ftgroup.com> Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 00:13:43 -0000 Support! Dan ----- Original Message ----- From: "Julien Meuric" To: Sent: Monday, August 22, 2011 5:27 PM Subject: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 > Hi PCE WG. > > The updated charter is on line, it is now time to move some of our work > forward. > > There has been much discussion and work about > draft-zhao-pce-pcep-inter-domain-p2mp-procedures (version 7 already, > formerly 2 I-Ds). This message starts a poll on adoption of > draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 as WG document. > Please reply to this e-mail and tell whether you support the adoption or > not. Comments are always welcome to motivate answers, especially in case > of disagreement. > > Regards, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From zhangfatai@huawei.com Tue Aug 23 18:11:37 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB9221F8BBA for ; Tue, 23 Aug 2011 18:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.159 X-Spam-Level: X-Spam-Status: No, score=-5.159 tagged_above=-999 required=5 tests=[AWL=1.440, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQuk9EGG1-pS for ; Tue, 23 Aug 2011 18:11:36 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBFD21F8BB9 for ; Tue, 23 Aug 2011 18:11:36 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00A7FRB6LT@szxga03-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 09:11:30 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00LJ1RB6ZO@szxga03-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 09:11:30 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ21437; Wed, 24 Aug 2011 09:11:29 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 09:11:26 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.184]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Wed, 24 Aug 2011 09:11:29 +0800 Date: Wed, 24 Aug 2011 01:11:03 +0000 From: Zhangfatai In-reply-to: <4E5220EE.3030701@orange-ftgroup.com> X-Originating-IP: [10.70.76.157] To: Julien Meuric , "pce@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Thread-index: AQHMYK315NcbM5z3o0qyAI5lidBSA5UrNAOA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E5220EE.3030701@orange-ftgroup.com> Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 01:11:37 -0000 U3VwcG9ydC4NCg0KDQoNCg0KVGhhbmtzDQrCoA0KRmF0YWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHBjZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGNlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdWxpZW4gTWV1cmljDQpTZW50OiAyMDEx5bm0OOaciDIy 5pelIDE3OjI3DQpUbzogcGNlQGlldGYub3JnDQpTdWJqZWN0OiBbUGNlXSBQb2xsIG9uIGRyYWZ0 LXpoYW8tcGNlLXBjZXAtaW50ZXItZG9tYWluLXAybXAtcHJvY2VkdXJlcy0wNw0KDQpIaSBQQ0Ug V0cuDQoNClRoZSB1cGRhdGVkIGNoYXJ0ZXIgaXMgb24gbGluZSwgaXQgaXMgbm93IHRpbWUgdG8g bW92ZSBzb21lIG9mIG91ciB3b3JrIA0KZm9yd2FyZC4NCg0KVGhlcmUgaGFzIGJlZW4gbXVjaCBk aXNjdXNzaW9uIGFuZCB3b3JrIGFib3V0IA0KZHJhZnQtemhhby1wY2UtcGNlcC1pbnRlci1kb21h aW4tcDJtcC1wcm9jZWR1cmVzICh2ZXJzaW9uIDcgYWxyZWFkeSwgDQpmb3JtZXJseSAyIEktRHMp LiBUaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgcG9sbCBvbiBhZG9wdGlvbiBvZiANCmRyYWZ0LXpoYW8t cGNlLXBjZXAtaW50ZXItZG9tYWluLXAybXAtcHJvY2VkdXJlcy0wNyBhcyBXRyBkb2N1bWVudC4g DQpQbGVhc2UgcmVwbHkgdG8gdGhpcyBlLW1haWwgYW5kIHRlbGwgd2hldGhlciB5b3Ugc3VwcG9y dCB0aGUgYWRvcHRpb24gb3IgDQpub3QuIENvbW1lbnRzIGFyZSBhbHdheXMgd2VsY29tZSB0byBt b3RpdmF0ZSBhbnN3ZXJzLCBlc3BlY2lhbGx5IGluIGNhc2UgDQpvZiBkaXNhZ3JlZW1lbnQuDQoN ClJlZ2FyZHMsDQoNCkpQICYgSnVsaWVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQo= From dhruv.dhody@huawei.com Tue Aug 23 21:04:37 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E5421F8B1B for ; Tue, 23 Aug 2011 21:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8Xukds9K-Zw for ; Tue, 23 Aug 2011 21:04:36 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE4821F8B19 for ; Tue, 23 Aug 2011 21:04:36 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00GQYZDIF7@szxga03-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 12:05:42 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQE00J5VZC74T@szxga03-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 12:05:42 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ40747; Wed, 24 Aug 2011 12:05:42 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 12:05:38 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.184]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Wed, 24 Aug 2011 12:05:41 +0800 Date: Wed, 24 Aug 2011 04:05:14 +0000 From: Dhruv Dhody In-reply-to: <4E5220EE.3030701@orange-ftgroup.com> X-Originating-IP: [10.18.24.85] To: Julien Meuric , "pce@ietf.org" Message-id: <23CE718903A838468A8B325B80962F9BB63717@SZXEML520-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Thread-index: AQHMYK33e9ZkQmh+gkCR5TQ+Rmkk/5UrZKBA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E5220EE.3030701@orange-ftgroup.com> Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 04:09:17 -0000 I Support! Regards, Dhruv *************************************************************************************** Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: Monday, August 22, 2011 2:57 PM To: pce@ietf.org Subject: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Hi PCE WG. The updated charter is on line, it is now time to move some of our work forward. There has been much discussion and work about draft-zhao-pce-pcep-inter-domain-p2mp-procedures (version 7 already, formerly 2 I-Ds). This message starts a poll on adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 as WG document. Please reply to this e-mail and tell whether you support the adoption or not. Comments are always welcome to motivate answers, especially in case of disagreement. Regards, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From sureshbr@huawei.com Tue Aug 23 21:56:19 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAF421F8B8B for ; Tue, 23 Aug 2011 21:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkj1XPTG51FZ for ; Tue, 23 Aug 2011 21:56:18 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id BA67721F8B86 for ; Tue, 23 Aug 2011 21:56:18 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQF002471ROL4@szxga03-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 12:57:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQF003UD1ROB7@szxga03-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 12:57:24 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQF00BLX1RM4D@szxml04-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 12:57:24 +0800 (CST) Date: Wed, 24 Aug 2011 10:27:17 +0530 From: Suresh In-reply-to: To: pce@ietf.org Message-id: <4EA797DD1FF84E94BD97E2C69129F619@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4862 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcxhYli3i+F6sDscSAe4+//EzRN96QAt+UEg References: Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 04:56:19 -0000 Support .. Regards Suresh -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ramon Casellas Sent: Tuesday, August 23, 2011 12:27 PM To: Julien Meuric; pce@ietf.org Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Support (as a coauthor) R. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From udayasreepalle@huawei.com Tue Aug 23 23:31:45 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EE221F8B30 for ; Tue, 23 Aug 2011 23:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQxr4Bfkik1Q for ; Tue, 23 Aug 2011 23:31:44 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A726E21F8B27 for ; Tue, 23 Aug 2011 23:31:44 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQF00EGH66SOL@szxga03-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 14:32:52 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQF00BY466SW0@szxga03-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 14:32:52 +0800 (CST) Received: from BLRNSHTIPL4NC ([10.18.1.34]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQF00GU866RJ0@szxml06-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 14:32:52 +0800 (CST) Date: Wed, 24 Aug 2011 12:02:51 +0530 From: Udayasree In-reply-to: <4E5220EE.3030701@orange-ftgroup.com> To: 'Julien Meuric' , pce@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4862 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcxgrgMhYZ6ueK8USUSzrqNdbquPHwBeZjIg References: <4E5220EE.3030701@orange-ftgroup.com> Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 06:31:45 -0000 I support Regards, Udaya -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: Monday, August 22, 2011 2:57 PM To: pce@ietf.org Subject: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Hi PCE WG. The updated charter is on line, it is now time to move some of our work forward. There has been much discussion and work about draft-zhao-pce-pcep-inter-domain-p2mp-procedures (version 7 already, formerly 2 I-Ds). This message starts a poll on adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 as WG document. Please reply to this e-mail and tell whether you support the adoption or not. Comments are always welcome to motivate answers, especially in case of disagreement. Regards, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From cyril.margaria@nsn.com Wed Aug 24 00:11:12 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A71521F8AF8 for ; Wed, 24 Aug 2011 00:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fec4QFG8ErCT for ; Wed, 24 Aug 2011 00:11:09 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5F41B21F8AE6 for ; Wed, 24 Aug 2011 00:11:07 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p7O7CHSE022500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Aug 2011 09:12:17 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p7O7CG4b015091; Wed, 24 Aug 2011 09:12:17 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Aug 2011 09:12:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Aug 2011 09:12:14 +0200 Message-ID: In-Reply-To: <4E5220EE.3030701@orange-ftgroup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Thread-Index: AcxgrbDuPppqvabtSRaIME0N9vfWUgBf2i5A References: <4E5220EE.3030701@orange-ftgroup.com> From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext Julien Meuric" , X-OriginalArrivalTime: 24 Aug 2011 07:12:16.0305 (UTC) FILETIME=[27861210:01CC622D] Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 07:11:13 -0000 Support Regards, Cyril > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > ext Julien Meuric > Sent: Monday, August 22, 2011 11:27 AM > To: pce@ietf.org > Subject: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp- > procedures-07 >=20 > Hi PCE WG. >=20 > The updated charter is on line, it is now time to move some of our work > forward. >=20 > There has been much discussion and work about draft-zhao-pce-pcep- > inter-domain-p2mp-procedures (version 7 already, formerly 2 I-Ds). This > message starts a poll on adoption of > draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 as WG document. > Please reply to this e-mail and tell whether you support the adoption > or not. Comments are always welcome to motivate answers, especially in > case of disagreement. >=20 > Regards, >=20 > JP & Julien >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From leeyoung@huawei.com Wed Aug 24 07:50:47 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2378B21F8715 for ; Wed, 24 Aug 2011 07:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t2Shjb45BAu for ; Wed, 24 Aug 2011 07:50:46 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5321F86E0 for ; Wed, 24 Aug 2011 07:50:46 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQF00HF8TAKSU@usaga04-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 09:51:56 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQF00I7QTAJAZ@usaga04-in.huawei.com> for pce@ietf.org; Wed, 24 Aug 2011 09:51:56 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 07:51:51 -0700 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 24 Aug 2011 07:51:55 -0700 Date: Wed, 24 Aug 2011 14:51:55 +0000 From: Leeyoung In-reply-to: <4E5220EE.3030701@orange-ftgroup.com> X-Originating-IP: [10.47.144.142] To: Julien Meuric , "pce@ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E17181572BA@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Thread-index: AQHMYK339XbFv/a2e0qL0KZmIXTF45UsGVLg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4E5220EE.3030701@orange-ftgroup.com> Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 14:50:47 -0000 Support Young -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: Monday, August 22, 2011 4:27 AM To: pce@ietf.org Subject: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Hi PCE WG. The updated charter is on line, it is now time to move some of our work forward. There has been much discussion and work about draft-zhao-pce-pcep-inter-domain-p2mp-procedures (version 7 already, formerly 2 I-Ds). This message starts a poll on adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 as WG document. Please reply to this e-mail and tell whether you support the adoption or not. Comments are always welcome to motivate answers, especially in case of disagreement. Regards, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From huaimo.chen@huawei.com Fri Aug 26 06:49:30 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F065A21F8B13 for ; Fri, 26 Aug 2011 06:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTOVDgD+dSn9 for ; Fri, 26 Aug 2011 06:49:29 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id DCEF921F8A57 for ; Fri, 26 Aug 2011 06:49:29 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQJ00F4ZFSKS5@usaga02-in.huawei.com> for pce@ietf.org; Fri, 26 Aug 2011 08:50:45 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LQJ0066LFSKE2@usaga02-in.huawei.com> for pce@ietf.org; Fri, 26 Aug 2011 08:50:44 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 26 Aug 2011 06:50:37 -0700 Received: from DFWEML504-MBX.china.huawei.com ([169.254.4.82]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Fri, 26 Aug 2011 06:50:44 -0700 Date: Fri, 26 Aug 2011 13:50:43 +0000 From: Huaimo Chen In-reply-to: <4E5220EE.3030701@orange-ftgroup.com> X-Originating-IP: [10.47.139.125] To: Julien Meuric , "pce@ietf.org" Message-id: <5316A0AB3C851246A7CA5758973207D40B8E3D77@dfweml504-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Thread-index: AQHMYK34R4kMswJRZUmB9wyxPFlefJUvLMUg X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: Re: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:49:31 -0000 Support! Regards, Huaimo -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric Sent: Monday, August 22, 2011 5:27 AM To: pce@ietf.org Subject: [Pce] Poll on draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 Hi PCE WG. The updated charter is on line, it is now time to move some of our work forward. There has been much discussion and work about draft-zhao-pce-pcep-inter-domain-p2mp-procedures (version 7 already, formerly 2 I-Ds). This message starts a poll on adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07 as WG document. Please reply to this e-mail and tell whether you support the adoption or not. Comments are always welcome to motivate answers, especially in case of disagreement. Regards, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce