From lberger@labn.net Thu Jan 3 13:51:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D1921F8D70 for ; Thu, 3 Jan 2013 13:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.476 X-Spam-Level: X-Spam-Status: No, score=-99.476 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, 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 NsqEPEZUTHHx for ; Thu, 3 Jan 2013 13:51:27 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id A88E821F8D68 for ; Thu, 3 Jan 2013 13:51:26 -0800 (PST) Received: (qmail 17841 invoked by uid 0); 3 Jan 2013 21:50:58 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 3 Jan 2013 21:50:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=myxt81pRa4naxgAEyXJwGbVy8jR6GujF7alnSCCFidk=; b=EYSf9MWeHCwI5qH02uYvf8I1OmGwf0slRveK6hofe7GUEj3VlLW45+H9xSaaCjphJEBAPcSCaKWu+B+UJaA20bQO5ZRgCLZ/4OZrgShWsXXHbCgh8rB1y6as6mIIo4xd; Received: from box313.bluehost.com ([69.89.31.113]:55103 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Tqsgk-000212-6o; Thu, 03 Jan 2013 14:50:58 -0700 Message-ID: <50E5FD4A.1080207@labn.net> Date: Thu, 03 Jan 2013 16:51:06 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Fatai Zhang References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 21:51:28 -0000 Hi Fatai, Happy new year. Please see below for responses. On 12/25/2012 3:33 AM, Fatai Zhang wrote: > > Hi Lou, > > Please see in-line below. > > A new version will be issued after all open issues are resolved. > > > > > > Best Regards > > Fatai > > > -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, December 20, 2012 10:12 PM >> To: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: 答复: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 >> >> Fatai/Authors, >> Thank you for the mail, and sorry about my delayed response. BTW >> please feel free to continue discussing the remaining open issues on the >> list and reaching closure on the list (on specific text/resolutions) >> prior to publishing the next rev. >> >> Please see below for inline responses. >> >> On 12/7/2012 4:53 AM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> Please see how the LC comments addressed below. >>> >>> >>> >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> >>> -----邮件原件----- >>> 发件人: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 代表 Lou Berger >>> 发送时间: 2012年10月22日 10:01 >>> 收件人: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> 主题: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>> >>> Authors, >>> I have the following LC comments: >>> >>> General comments: >>> >>> - This document also needs some addition work on conformance language. >>> I'll try to point out cases in the detailed comments below. >>> >> [Fatai] OK. Checked and refined based on your detailed comments. >>> >> >> I think this rev is an improvement, but there's still more work needed. >> I have made some specific comments/suggestions below. >> >>> - Section 5 essentially defines a new set of traffic parameters. Given >>> the changes, why not ask for a new C-TYPE and not worry about [RFC4328] >>> compatibility/description? >>> >> [Fatai] Accepted to have a new C-TYPE and updated the text accordingly. >>> >> >> Okay. >> >>> Detailed editorial and technical comments: >>> >>> - Please verify that abbreviations are defined before being used . >>> There are a number of these. >>> >> [Fatai] Went through and updated. >> >> thanks. >> >>> >>> - Please use a consistent decimal representation (sometimes commas are >>> used other times periods) >>> >> [Fatai] OK. Commas are used. >> >> great, although a quick skim finds: >> s/1,301.683.217/1,301,683.217 >> >> >> >>> >>> - the references [G709-v1] and [G709-v3] each actually refer to multiple >>> documents, each documented needs to have it's own (correct) reference, >>> i.g., [G709-v1] and [G709-v1a1]. The document text will need to be >>> revisited to ensure the proper reference is made. >>> >> [Fatai] Accepted and used the same approach for framework draft. >> >> great >> >> >>> - >>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-04.txt >>> shows there are unresolved nits that need to resolved . >> >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-05.txt >> still shows a warning, notably: >> >> (Using the creation date from RFC4328, updated by this document, for >> RFC5378 checks: 2005-01-17) >> >> -- The document seems to lack a disclaimer for pre-RFC5378 work, but may >> have content which was first submitted before 10 November 2008. If you >> have contacted all the original authors and they are all willing to grant >> the BCP78 rights to the IETF Trust, then this is fine, and you can ignore >> this comment. If not, you may need to add the pre-RFC5378 disclaimer. >> (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) >> > [Fatai] Will update “Copyright Notice” section. okay >> >>> I'm using line >>> numbers from this url in my subsequent comments. >>> >> [...] >> >>> - Section 3. Perhaps combine with section 1. >>> >> [Fatai] Accepted and refined. >>> >> >> I don't see where this suggestion was followed, but that's okay, it was >> just a suggestion. >> > [Fatai] OK. >> >> [...] >>> - Section 5: assuming this is now a new c-type need text for that, as >>> well as to formally defined the fields/field sizes. >>> >> [Fatai] Accepted to have a new C-TYPE and updated the text accordingly. >> >> Formal field definitions are missing and need to be added. >> > [Fatai] The format is the same as RFC4328. Did you mean that it > needs “Length”, “Class-Num” and “C-Type”? If yes, I will add > them. If you mean that it needs text to define all the fields, I > think the text is already there (then this comment may be related > to your other comments below). Its important to differentiate the syntax (i.e., format) from the semantics (i.e., usage). How about: Signal Type: 8 bits As defined in [RFC4328] Section 3.2.1, with the following additional values: (insert lines 266-285) Reserved: 8 bits As defined in [RFC4328] Section 3.2.5. Tolerance: 16 bits (insert lines 296-298) NVC: 16 bits As defined in [RFC4328] Section 3.2.3. Multiplier (MT): 16 bits As defined in [RFC4328] Section 3.2.4. Bit_Rate: 32 bits (insert lines 290-294) The other parts, lines 287-288, 300-319 should be merged into section 5.1. >> >> Also the draft says: >> >> Note that the error process on the traffic parameters MUST follow the >> rules defined in Section 6 of [RFC4328]. >> >> Given the different fields, shouldn't any OTN-TDM related traffic parameter processing now be defined in this document? >> > [Fatai] I just wanted to avoid the overlapped text (almost the same text as RFC4328). Will accept your suggestion to expand the text as follows: > > There is no Adspec associated with the OTN-TDM SENDER_TSPEC. Either > the Adspec is omitted or an Int-serv Adspec with the Default General > Characterization Parameters and Guaranteed Service fragment is used, > see [RFC2210]. > > For a particular sender in a session, the contents of the FLOWSPEC > object received in a Resv message SHOULD be identical to the contents > of the SENDER_TSPEC object received in the corresponding Path > message. If the objects do not match, a ResvErr message with a > "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. > > Intermediate and egress nodes MUST verify that the node itself, and > the interfaces on which the LSP will be established, can support the > requested Signal Type, NVC, Tolerance and Bit_Rate values. If the > requested value(s) cannot be supported, the receiver node MUST > generate a PathErr message with a "Traffic Control Error/Service > unsupported" indication (see [RFC2205]). > > In addition, if the MT field is received with a zero value, the node > MUST generate a PathErr message with a "Traffic Control Error/Bad > Tspec value" indication (see [RFC2205]). > Is this a new section, perhaps 5.3? >> >>> >> [...] >>> >>> - Lines 320-336,338-346 are essentially repeated in sections 5.1 and >>> 5.2, why not move this text into their respective sections? >>> >> [Fatai] Accepted and refined the text. >> >> >> I don't see where this suggestion was followed. For example: >> >> 287 In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be >> 288 used together to represent the actual bandwidth of ODUflex, where: >> >> and >> >> 323 In case of ODUflex(CBR), the information of Bit_Rate and Tolerance in >> 324 the ODUflex traffic parameters MUST be used to determine the total >> 325 number of tributary slots N in the HO ODUk link to be reserved. Here: >> > [Fatai] Sorry I should not say “Accepted and refined the text.” > last time. They are not repeated. here, the text just describes the > meaning of the corresponding fields (as we always do), so the above > text should be there irrespectively. Section 5.1 & section 5.2 > describe “how” with more detail information including formulation, > Table information and example. > If the text in the early part of 5 is revised as I suggest above (and the other lines are merged as suggested above) then this comment will be resolved. >> >>> >>> - lines 445-468: Why not just carry "n" directly? >>> >> [Fatai] to make it consistent with ODUflex(CBR). >> >> Given that the recent decision to have an OTN-TDM specific set of >> traffic parameters, doesn't it now make sense to just carry N directly? >> > [Fatai] No. “N” cannot be used for ODUflex(CBR) case. Do you really mean "cannot"? I may be missing something, but it would seem less ambiguous/prone to interop issues if N was directly carried. > It is better > to have consistent format and the same meaning of one field for both > ODUflex(CBR) and GFP. This is why we have section 5.1 &5.2 to > describe the complex stuff. > I actually wasn't suggesting that N be carried in the bit rate field. The bit rate field can either be set as described or to zero (i.e., ignored). At the time, I was thinking about carrying N in the reserved field. But perhaps the right place is MT, if my understanding is right (would always be 1 otherwise). I'm open to either... >> >> [...] >> >>> >>> - Line 576: "Padded bits" seems off, how about "Pad bits" or "Padding", >> >> Again, how about "Pad bits" or "Padding"? >> > [Fatai] OK. Should use “Pad bits” instead of “Padding bits” “Pad bits” it is... >> >>> also bits aren't represented in label format (line 494)., also "behind" >>> --> "after" >>> >> [Fatai] Accepted and updated. >>> >> >> [...] >> >>> >>> - Lines 658-660. The normative language in 4328 isn't actually >>> presented in the section titled "label distribution procedures" (or >>> "rules" as section 4.2 is actually titled), so this paragraph doesn't >>> make sense. I suggest either (a) defining the full set of required >>> procedures in this document, or (b) referring to the "required >>> processing defined in [RFC4328]" and other rfcs as appropriate. >>> >> [Fatai] Accepted and updated accordingly. >>> >>> - Lines 662-667: what about generating upstream, suggested, label set, >>> etc. Perhaps you should rephrase much into more general rules. >>> >> [Fatai] Accepted and updated accordingly. >>> >> >> I think section 6.2 still needs a bit of work. >> >> So are there procedures that an ingress must follow? >> For example: >> - Setting of fields in the label request object, such as the OTN-TDM >> Switching Type defined in [OTN-OSPF]. >> >> What about the egress, are there any special procedures? >> >> The final three paragraphs of the section introduce upstream behaviors >> *after* you've described the downstream behavior without specifics of >> the new upstream behavior. As a general rule and in this case in >> particular, I really think it would be better to cover procedures in the >> following order >> - Ingress >> - Generic upstream >> - Generic downstream >> - Egress >> >> Also, generic statements should not use conformance language, >> particularly when more detailed rules/procedures, which include such >> language, follow. >> >> If you'd like we can discuss/review details on the list once you have a >> proposed revision. (I see a bunch of more minor comments on this >> section, but don't think it makes sense to focus on these until the more >> major comments are addressed.) >> > [Fatai] Will refine the text based on your suggestion. Do I need to > copy so much text here for review? It's up to you, but personally, I think it's better to discuss the text on the list first rather than publishing and then discuss/wordsmith. But this is just a personal preference. Either way works. (draft revision numbers are cheap after all.) >> >> >> [...] >>> >>> - Lines 682-685: Who is this learning/identification accomplished? >>> >> [Fatai] Accepted and updated. >>> >>> - Lines 703-704: If this is the normative section defining requirement >>> processing, the procedures need to be spelled out for all required cases. >>> >> [Fatai] Accepted and updated accordingly. >>> >>> - Lines 706-707: I think this needs to be rephrased to be clear what >>> behavior is required for a node to be conformant with this sentence. >>> >> [Fatai] Accepted and refined accordingly. >>> >>> - Lines 711-714: why "SHOULD" vs "MUST"? >>> >> [Fatai] Accepted and updated. >>> >> >> I'll defer responses to the discussion on prior comment. >> >>> - Line 712: By "integrity of the label" do you mean "if the label is >>> acceptable"? >>> >> [Fatai] Yes, and updated. >>> >>> >>> - Line 725: By "reserved resource" do you mean "indicated resource"? >>> >> [Fatai] Yes, and updated. >>> >>> - Line 726: Does "do not match" mean "inconsistent"? >>> >> [Fatai] Yes, and updated. >> >> WRT lines 624-627, I think you still need additional specificity >> differentiate upstream/downstream required behavior. Perhaps something >> along the lines of: >> >> When an upstream node receives a Resv message containing an s/an/a >> LABEL object with an OTN-TDM label, the node MUST verify that >> the label is acceptable. If the label is not acceptable, the >> node MUST generate a ResvErr message with a "Routing >> problem/Unacceptable label value" indication. Per [RFC3473], >> the generated ResvErr message MAY include an >> ACCEPTABLE_LABEL_SET object. With the exception of label >> semantics, Downstream node processing a received ResvErr >> messages and of ACCEPTABLE_LABEL_SET objects is not modified >> by this document. >> >> Similarly, when a downstream node receives a Path message >> containing an UPSTREAM_LABEL object with an OTN-TDM label, >> the node MUST verify that the label is acceptable. If the >> label is not acceptable, the node MUST generate a PathErr >> message with a "Routing problem/Unacceptable label value" >> indication. Per [RFC3473], the generated ResvErr message MAY >> include an ACCEPTABLE_LABEL_SET object. With the exception >> of label semantics, Downstream node processing received >> PathErr messages and of ACCEPTABLE_LABEL_SET objects is not >> modified by this document. >> >> A received label SHALL be considered unacceptable when one of >> the following cases occurs: >> >> - The received label doesn't conform with local policy. >> > [Fatai] OK. Accept your proposed text. >> ... >> >>> >>> - Line 730, Drop "As". >>> >> [Fatai] Accepted and updated. >>> >>> - Section 6.4: Missing conformance language. >>> >> [Fatai] Went through and updated. >> >> New line 660: The procedures are similar to section 6 of [RFC6344]. >> >> Hereto, If this is the normative section defining required processing, >> the procedures need to be spelled out for all required cases or refer to >> specific (and unmodified) procedures to follow in a reference document. >> So either define the processing or say procures defined in > reference> are followed. >> > [Fatai] OK, I think it is better to say “The procedures MUST follow > Section 5 of [RFC6344].” Are there any procedures defined in section6.3 that differ/add to 6344? If I'm not mistaken, the only thing is that ODUflex signal types cannot use "multiplication". (Please confirm.) Assuming I'm correct, how about replacing the contents of the section with something along the lines of: Support for Virtual Concatenation, as defined by [RFC6344], is not modified by this document. With the exception of ODUflex signal types, signal multiplication as defined in [RFC6344] and [RFC4328]. >> >>> >>> - Lines 758-759: This reads like an informative statement, but includes >>> conformance language. How does a node conform? I suggest rephrasing to >>> be clear. >>> >> [Fatai] Accepted and updated. >>> >> >> I think this section should be revised to ensure that the >> responsibilities of each type of processing node (ingress, upstream, >> downstream, egress) is clear. >> >> I guess, we'll have a thread on this section too... >> > [Fatai] Will refine the text based on your suggestion. great. >> >> [...] >> >>> >>> - Section 9, should also reference 4328 and cover delta in information >>> and added risks. >>> >> [Fatai] Accepted and updated. >> >> We'll see if this is enough to keep the security reviewers happy... >> >>> >>> - Section 10: This section needs some work. (I'm assuming your familiar >>> with rfc5226). >>> >> [Fatai] Accepted and updated. >>> >> >> Better, but you should at least refer to the existing registries, which already includes G-PIDs (see >> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml) >> >>> - Is it time to create a "Signal Type" registry? >>> >> [Fatai] We are not sure, because no "Signal Types" have been registered in the existing RFCs (like RFC3473, RFC4328..). >>> >> >> I think including a request to establish such a registry in this >> document would be useful. Is anyone up to proposing the requisite text? >> > [Fatai] OK to register “Signal Type”. Is this a question or statement? Thanks, Lou >> >> Value Signal Type Reference >> ----- ----------- --------- >> 0 Not significant [this document] >> 1 ODU1 (i.e., 2.5 Gbps) [this document] >> 2 ODU2 (i.e., 10 Gbps) [this document] >> 3 ODU3 (i.e., 40 Gbps) [this document] >> 4 ODU4 (i.e., 100 Gbps) [this document] >> 5 Reserved (for future use) [this document] >> 6 Optical Channel (Och) at 2.5 Gbps [this document] >> 7 OCh at 10 Gbps [this document] >> 8 OCh at 40 Gbps [this document] >> 9 OCh at 100 Gbps [this document] >> 10 ODU0 (i.e., 1.25 Gbps) [this document] >> 11 ODU2e (i.e., 10Gbps for FC1200 [this document] >> and GE LAN) >> 12~19 Reserved (for future use) [this document] >> 20 ODUflex(CBR) (i.e., 1.25*N Gbps) [this document] >> 21 ODUflex(Generic Framing [this document] >> Procedure-Framed (GFP-F)), >> resizable (i.e., 1.25*N Gbps) >> 22 ODUflex(GFP-F), non resizable [this document] >> (i.e., 1.25*N Gbps) >> 23~255 Reserved (for future use) [this document] >> >> >> Thanks, >> Lou >> >> >>> That's it on this document. >>> >>> Lou >>> - >> From adrian@olddog.co.uk Sat Jan 5 14:19:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67A921F853A for ; Sat, 5 Jan 2013 14:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 vruRla74Vtvr for ; Sat, 5 Jan 2013 14:19:25 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECF621F852C for ; Sat, 5 Jan 2013 14:19:24 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r05MJNY7000320; Sat, 5 Jan 2013 22:19:23 GMT Received: from 950129200 (089144192159.atnat0001.highway.a1.net [89.144.192.159]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r05MJMAm000310; Sat, 5 Jan 2013 22:19:22 GMT From: "Adrian Farrel" To: Date: Sat, 5 Jan 2013 22:19:23 -0000 Message-ID: <00bc01cdeb92$b7b3f830$271be890$@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: Ac3rkov/hzhmWNlBR7e6vuxrJKsMNQ== Content-Language: en-gb Cc: ccamp@ietf.org Subject: [CCAMP] AD review of draft-ietf-ccamp-lmp-behavior-negotiation X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 22:19:25 -0000 Hi, I have done my usual AD review of this document to catch any issues that might come up in IETF last call or IESG review. I only have one comment on this document which is that Section 2.1 needs to include a reference to the BNF format rules you are using, i.e., RFC 5511) and you need to add a normative reference. Since this is the only comment I have, please take it as an IETF last call comment and don't forget to make the change once last call is completed. Thanks, Adrian From iesg-secretary@ietf.org Mon Jan 7 07:38:18 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8455221F88E4; Mon, 7 Jan 2013 07:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.272 X-Spam-Level: X-Spam-Status: No, score=-102.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, 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 qidqxd2wxIyM; Mon, 7 Jan 2013 07:38:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F99721F865D; Mon, 7 Jan 2013 07:38:18 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107153818.14941.79558.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 07:38:18 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: (Link Management Protocol Behavior Negotiation and Configuration Modifications) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:38:18 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Link Management Protocol Behavior Negotiation and Configuration Modifications' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS) networks. This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations. This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-lmp-behavior-negotiation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-lmp-behavior-negotiation/ballot/ No IPR declarations have been submitted directly on this I-D. From fred.gruman@us.fujitsu.com Mon Jan 7 08:24:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7911E80C5 for ; Mon, 7 Jan 2013 08:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 Q48TBJA5awzD for ; Mon, 7 Jan 2013 08:24:18 -0800 (PST) Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8CA11E80AD for ; Mon, 7 Jan 2013 08:24:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,424,1355119200"; d="scan'208,217";a="25751795" Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp02.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 07 Jan 2013 10:24:17 -0600 Received: from RCHEXMBP2.fnc.net.local ([169.254.1.67]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.02.0298.004; Mon, 7 Jan 2013 10:24:17 -0600 From: "Gruman, Fred" To: "ccamp@ietf.org" Thread-Topic: Switching Capability/Type for ospf-g709v3, signaling-g709v3 Thread-Index: Ac3s82+y8vO2F259QmKlwmEkZgQsmg== Date: Mon, 7 Jan 2013 16:24:16 +0000 Message-ID: <5DF87403A81B0C43AF3EB1626511B2923C3031BF@RCHEXMBP2.fnc.net.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19516.000 x-tm-as-result: No--29.007600-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_5DF87403A81B0C43AF3EB1626511B2923C3031BFRCHEXMBP2fncnet_" MIME-Version: 1.0 Subject: [CCAMP] Switching Capability/Type for ospf-g709v3, signaling-g709v3 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:24:19 -0000 --_000_5DF87403A81B0C43AF3EB1626511B2923C3031BFRCHEXMBP2fncnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fatai, Daniele, I noticed that in the latest routing draft of ospf-g709v3-04 that the switc= hing capability was changed from 101 to 110. The latest signaling draft si= gnaling-g709v3-05 still lists 101 as the switching type (in section 4) alth= ough it does defer to [OTN-OSPF]. I assume that the switching capability/t= ype is to be consistent between routing and signaling and that the new reco= mmendation is 110. Is this correct? If so, I would recommend removing the "(101, TBA by IANA)" from the signali= ng draft and rely on the reference to [OTN-OSPF]. Thanks, Fred --_000_5DF87403A81B0C43AF3EB1626511B2923C3031BFRCHEXMBP2fncnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Fatai, Daniele,

 

I noticed that in the latest routing draft of ospf-g= 709v3-04 that the switching capability was changed from 101 to 110.  T= he latest signaling draft signaling-g709v3-05 still lists 101 as the switch= ing type (in section 4) although it does defer to [OTN-OSPF].  I assume that the switching capability/type is = to be consistent between routing and signaling and that the new recommendat= ion is 110.  Is this correct?

 

If so, I would recommend removing the “(101, T= BA by IANA)” from the signaling draft and rely on the reference to [O= TN-OSPF].

 

Thanks,

Fred

 

--_000_5DF87403A81B0C43AF3EB1626511B2923C3031BFRCHEXMBP2fncnet_-- From daniele.ceccarelli@ericsson.com Tue Jan 8 03:06:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E7021F8EE9 for ; Tue, 8 Jan 2013 03:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 TvMAxKJya7qx for ; Tue, 8 Jan 2013 03:06:10 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBF321F8EE7 for ; Tue, 8 Jan 2013 03:06:09 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-5e-50ebfda0130c Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 31.C8.24873.0ADFBE05; Tue, 8 Jan 2013 12:06:08 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.193]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 12:06:08 +0100 From: Daniele Ceccarelli To: "Gruman, Fred" , "ccamp@ietf.org" Thread-Topic: Switching Capability/Type for ospf-g709v3, signaling-g709v3 Thread-Index: Ac3s82+y8vO2F259QmKlwmEkZgQsmgAnFmNA Date: Tue, 8 Jan 2013 11:06:07 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4805CD90@ESESSMB301.ericsson.se> References: <5DF87403A81B0C43AF3EB1626511B2923C3031BF@RCHEXMBP2.fnc.net.local> In-Reply-To: <5DF87403A81B0C43AF3EB1626511B2923C3031BF@RCHEXMBP2.fnc.net.local> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4805CD90ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje6Cv68DDLZvkrV4MucGi0V/62xW i77m86wOzB4tR96yeixZ8pPJY9qvNWwBzFFcNimpOZllqUX6dglcGduO7GAt2GVS8X/qJeYG xoe6XYycHBICJhIHbyxghLDFJC7cW8/WxcjFISRwiFHi8Nd+RghnMaPEwefPgRwODjYBK4kn h3xAGkQEQiR2XL3CBGIzC6hLLNv6kxWkRFjAQ2JFuwdEiafE3ktr2EHCIgJGEp/XO4KEWQRU JPavuMECYvMKeEtsXnOHFcQWEvCTeNy3Hmwip4C/xK6vt9lAbEYBWYkJuxcxQmwSl7j1ZD4T xMkCEkv2nGeGsEUlXj7+xwphK0rsPNvODFGfL3Fhy3pWiF2CEidnPmGZwCg6C8moWUjKZiEp g4jrSdyYOoUNwtaWWLbwNTOErSsx498hFmTxBYzsqxjZcxMzc9LLjTYxAmPs4JbfqjsY75wT OcQozcGiJM4b7nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj1ydJ4erHrJeOPfUvdnN4 NGv6vcdy95b0XmhxWVe5TJ/fSz67aO6vtX6mvGzuSv5nLp/j/BR9Z1bpmqlzNz+TmeReJ2Zm bdp4zyvM4MkEPevlf1mvZXs/3NL4aZLu4o5L+7/rf7g+KfjKbLYp3vIMTaUb9deEfs1c0jlN +rT+BFlhV9H/TCt/KrEUZyQaajEXFScCANh3Tip/AgAA Subject: Re: [CCAMP] Switching Capability/Type for ospf-g709v3, signaling-g709v3 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 11:06:12 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE4805CD90ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fred, during the last call it was suggested to change the switching capability fr= om 101 to 110. The comment was raised just against OSPF, but i think it was= just an oversight. If Fatai and the other co-authors agree i would suggest aligning also RSVP = to 110 (either explicitely or with a reference to OSPF) Many thanks Daniele ________________________________ From: Gruman, Fred [mailto:fred.gruman@us.fujitsu.com] Sent: luned=EC 7 gennaio 2013 17.24 To: ccamp@ietf.org Cc: Fatai Zhang; Daniele Ceccarelli Subject: Switching Capability/Type for ospf-g709v3, signaling-g709v3 Hi Fatai, Daniele, I noticed that in the latest routing draft of ospf-g709v3-04 that the switc= hing capability was changed from 101 to 110. The latest signaling draft si= gnaling-g709v3-05 still lists 101 as the switching type (in section 4) alth= ough it does defer to [OTN-OSPF]. I assume that the switching capability/t= ype is to be consistent between routing and signaling and that the new reco= mmendation is 110. Is this correct? If so, I would recommend removing the "(101, TBA by IANA)" from the signali= ng draft and rely on the reference to [OTN-OSPF]. Thanks, Fred --_000_4A1562797D64E44993C5CBF38CF1BE4805CD90ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Fred,
 
during the last call it was sugge= sted to change the switching capability from 101 to 110. The comment was ra= ised just against OSPF, but i think it was just an oversight.
 
If Fatai and the other co-authors= agree i would suggest aligning also RSVP to 110 (either explicitely or wit= h a reference to OSPF)
 
Many thanks
Daniele
 
 

From: Gruman, Fred [mailto:fred.gru= man@us.fujitsu.com]
Sent: luned=EC 7 gennaio 2013 17.24
To: ccamp@ietf.org
Cc: Fatai Zhang; Daniele Ceccarelli
Subject: Switching Capability/Type for ospf-g709v3, signaling-g709v3=

Hi Fatai, Daniele,

 

I noticed that in the latest routing draft of ospf-g= 709v3-04 that the switching capability was changed from 101 to 110.  T= he latest signaling draft signaling-g709v3-05 still lists 101 as the switch= ing type (in section 4) although it does defer to [OTN-OSPF].  I assume that the switching capability/type is = to be consistent between routing and signaling and that the new recommendat= ion is 110.  Is this correct?

 

If so, I would recommend removing the “(101, T= BA by IANA)” from the signaling draft and rely on the reference to [O= TN-OSPF].

 

Thanks,

Fred

 

--_000_4A1562797D64E44993C5CBF38CF1BE4805CD90ESESSMB301ericsso_-- From internet-drafts@ietf.org Tue Jan 8 09:38:50 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320D721F8853; Tue, 8 Jan 2013 09:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, 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 XC7AEd0xvBvx; Tue, 8 Jan 2013 09:38:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A7C21F8506; Tue, 8 Jan 2013 09:38:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130108173849.5983.68415.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2013 09:38:49 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:38:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Traffic Engineering Extensions to OSPF for Generalized M= PLS (GMPLS) Control of Evolving G.709 OTN Networks Author(s) : Daniele Ceccarelli Diego Caviglia Fatai Zhang Dan Li Sergio Belotti Pietro Vittorio Grandi Rajan Rao Khuzema Pithewan John E Drake Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-05.txt Pages : 34 Date : 2013-01-08 Abstract: ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers, enabling optimized support for an increasingly abundant service mix. This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of all currently defined ODU containers, in support of both sub-lambda and lambda level routing granularity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniele.ceccarelli@ericsson.com Tue Jan 8 09:39:17 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A9011E80EF for ; Tue, 8 Jan 2013 09:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.648 X-Spam-Level: X-Spam-Status: No, score=-5.648 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_37=0.6, J_CHICKENPOX_51=0.6, 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 Tzjcjf5ji7DA for ; Tue, 8 Jan 2013 09:39:15 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AA8B311E810A for ; Tue, 8 Jan 2013 09:39:14 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-73-50ec59c1cb5f Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1F.80.24873.1C95CE05; Tue, 8 Jan 2013 18:39:13 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.193]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 18:39:12 +0100 From: Daniele Ceccarelli To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt Thread-Index: AQHN0q1CtM7xyI06Pk6wLux+sh8SWpggyrwAgACr+ICAAObagIAA/nUQgABAtwCAHDAwkA== Date: Tue, 8 Jan 2013 17:39:11 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4805D2BB@ESESSMB301.ericsson.se> References: <20121128073754.7548.6383.idtracker@ietfa.amsl.com> <50BE6C54.7060606@labn.net> <50D24D68.5040005@labn.net> <4A1562797D64E44993C5CBF38CF1BE4804556A@ESESSMB301.ericsson.se> <50D39F51.8010802@labn.net> <4A1562797D64E44993C5CBF38CF1BE48046263@ESESSMB301.ericsson.se> <50D4AB0E.6070207@labn.net> In-Reply-To: <50D4AB0E.6070207@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje7ByDcBBu0HlS2ezLnBYvG34TWL RUfzWxYHZo8lS34yeXzY1Mzm8eXyZ7YA5igum5TUnMyy1CJ9uwSujInv7rEXfPnNWLFy902W Bsb3hxm7GDk5JARMJE5em8YGYYtJXLi3Hsjm4hASOMQocbJ7A5SzmFHi7LZO5i5GDg42ASuJ J4d8QBpEBBQlvn5cxARSwyzQyiix6twLJpCEsICXxNRdV5lA6kUEvCXu3MiGMMMkri/SAzFZ BFQk9p3yBSnmBSqY938K1KadTBKHpzxnAUlwCmgAlb9nB7EZBWQlJuxeBHYzs4C4xK0n85kg bhaQWLLnPDOELSrx8vE/VghbUWLn2XZmiHo9iRtTp7BB2NoSyxa+ZoZYLChxcuYTlgmMYrOQ jJ2FpGUWkpZZSFoWMLKsYmTPTczMSS832sQIjJyDW36r7mC8c07kEKM0B4uSOG+464UAIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYx1jwuvP6/QepXIcUPIsn5+/OZG48t9wX/zJx7NWn1l c9Ibn4nrVKYVxbqv2tj2NOjWRosFkTKN2+3WhbqnBXjphYUKi2Zwrzo4v/jPC1tfJ7YC9bB1 dpYPNwQc5fUPPF19wjnYsKbj9Z4v7TzHCgue+HcyMBULdu1N/smjryVs/vzZzpPHTJRYijMS DbWYi4oTAUF8w5lqAgAA Cc: CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:39:17 -0000 Hi Lou, Please find further comments in line. Since the changes from v04 start to be quite a lot we published v05. Please= provide further comments (if any) with respect to that version. BR Daniele & Sergio=20 >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net]=20 >Sent: venerd=EC 21 dicembre 2012 19.32 >To: Daniele Ceccarelli >Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >Subject: Re: [CCAMP] I-D Action:=20 >draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt > >Daniele, > Much thanks -- I do expect that the thread might extend=20 >beyond the end of year holiday, and that many/most are off next week... > >See below for responses. > >On 12/21/2012 10:49 AM, Daniele Ceccarelli wrote: >> Hi Lou, >>=20 >> Please see in line. >>=20 >> We'll upload -05 when all the issues will be solved. >>=20 >> BR >> Daniele & Sergio >>=20 >> PS. The info model after christmas holidays >>=20 >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: venerd=EC 21 dicembre 2012 0.29 >>> To: Daniele Ceccarelli >>> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>> Subject: Re: [CCAMP] I-D Action:=20 >>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>> >>> Daniele / Authors, >>> Thank you for the response. Please see below for my responses. >>> >>> >>> On 12/20/2012 3:57 AM, Daniele Ceccarelli wrote: >>>> Hi Lou, >>>> >>>> Below you can find the last call comments pasted with >>> replies in line. >>>> >>>> All nits, typos and suggested text changes without any >>> comment in line >>>> have been accepted/modified accordingly. >>>> >>> >>>> BR >>>> Daniele & Sergio >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>>> On Behalf >>>>> Of Lou Berger >>>>>> Sent: mercoled=EC 26 ottobre 2011 0.37 >>>>>> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org >>>>>> Cc: CCAMP >>>>>> Subject: [CCAMP] some comments on gmpls-ospf-g709v3-00 >>>>> ... >>>>>> 2) SCSI TLV formatting >>>>>> >>>>>> The field descriptions are missing format related conformance >>>>>> (RFC2119) language. >>>>>> >>>> >>>> Done >>> >>> Thanks. >>> >>> Some points: >>> (Using line numbers from >>> http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft >> -ietf-ccamp-gmpls-ospf-g709v3-04.txt) >>> >>> I like your solution for the general TLV format definition. >>> >>> Lines 303/304: "Different sub-TLV MAY be presented in=20 >ascending Type=20 >>> order." >>> >>> I suspect you mean s/Different sub-TLV/Multiple sub-TLVs >>> >>=20 >> See below >>=20 >>> By "ascending Type order", are you refering to the TLV type?=20 >>> Are multiple TLVs of the same type allowed? If not, how are errors=20 >>> handled? >>=20 >> Yes and yes. Multiple TLVs of the same type are often=20 >present as each of them represents a branch of the muxing tree. >> What about changing into: >>=20 >> Sub-TLV SHOULD be presented >> in ascending Type order (i.e. type 1 before and type 2 after). > >Is there any technical reason for such ordering? It doesn't=20 >seem to add any value to me. Ok. It was meant to be just a guideline but indeed doesn't add any value. S= entence removed. > >I actually was expecting you to say something referring back=20 >to signal type or number of stages represented in the TLV... WRT signal type each TLV is self-consistent, in the sense that there is no = need to have them in a given order. In all the example we have ordered them= form the root to the leaves of the tree so to make it more "human-readable= ". We could suggest to follow that orded but like in the case of type 1 and= type2 is does not add any value (except being more easily read). WRT to number of stage the order is important. Actually the text says that = they MUST be put is ascending order and an example (ODU1->ODU2->ODU3) is pr= ovided: OLD - Stage#1 ... Stage#N : These fields are 8 bits long. Their number is= variable and a field is present for=20 each of the indicated number of stages. The last one MUST always indicat= e the server ODU container (ODUk/OTUk) and they MUST be listed in ascending order from the smallest to the bigg= est one. The values of the Stage fields MUST be the same ones defined for the Sig= nal Type field. If the number of stages is 0, then the Stage and Padding fields MUST be omi= tted. =20 Example: in case the ODU1->ODU2->OD3 hierarchy, the Signal Type field is= set to ODU1 and=20 two Stage fields are present, the first indicating ODU2 and the second O= DU3 (server layer).=20 =20 We added: "from the smallest to the biggest one." at the end of the first s= entence: NEW: =20 [CUT] =20 The last one MUST always indicate the server ODU container (ODUk/OTUk) and they MUST be listed in ascending order from the smallest to the bigges= t one. [CUT] > >>=20 >>> >>> Lines 306-322: >>> >>> Given that Figures 4 and 5 completely repeat the information in=20 >>> Figure 4, I propose that you drop Figure 4. (and align the=20 >preceding=20 >>> paragraph to match.) >>=20 >> Figure 4 and 5 represent TLV type1 and TLV type2=20 >respectively, which are quite different from each other. The=20 >first 3 rows are identical but the rest of the TLV is pretty=20 >different. We would prefer to keep both of them. >>=20 > >Ahh. Sorry, let me try again: > >Given that Figures 4 and 5 completely repeat the information=20 >in Figure *4*, I propose that you drop Figure *3*. (and align=20 >the preceding paragraph to match.) Done OLD The format of the SCSI MUST be as depicted in the following figure, where= =20 one Type 1 sub-TLV MUST be used for any fixed container and one Type 2 sub= -TLV MUST be used for any variable container.=20 NEW The SCSI MUST include one Type 1 sub-TLV for any fixed container and one T= ype 2 sub-TLV for any variable container.=20 > >Also, just realized that figures 4 and 5 really should=20 >indicate that priorities are not always included. And that a=20 >second padding field may be needed too! How about: > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D 1 (Unres-fix) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type | Num of Stages |T|S| TSG | Res | Priority | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stage#1 | ... | Stage#N | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unreserved ODUj at Prio 0 | ..... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unreserved ODUj at Prio 7 | Unreserved Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 4: Bandwidth TLV - Type 1 - OK. Wrote padding instead of unreserved Padding > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D 2 (Unres/MAX-var) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Signal Type | Num of Stages |T|S| TSG | Res | Priority | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stage#1 | ... | Stage#N | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unreserved Bandwidth at priority 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unreserved Bandwidth at priority 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Maximum LSP Bandwidth at priority 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Maximum LSP Bandwidth at priority 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 5: Bandwidth TLV - Type 2 - > >(Note some field names have been expanded to match descriptions) OK > >>> >>>> >>>>>> >>>>>> 3) SCSI TLV procedures >>>>>> >>>>>> You have defined the formats of the TLVs in Section 4.1, but not=20 >>>>>> explicitly how they are to be used. Some RFC2119 language >>> really is >>>>>> needed to cover how the SCSI is to be encoded and parsed. At a=20 >>>>>> minimum, any TLV inclusion, ordering requirements, and exception=20 >>>>>> handling should be covered. (For example, your examples >>>>> always show a >>>>>> particular ordering relative to Stage#, is this required, >>>>> recommended, >>>>>> or just a possibility. You have some informative language, >>> which is >>>>>> great, but you also need some RFC2119 language.) >>>> >>>> Done >>> >>> The length of each TLV type and each field should be defined.=20 >>> (You have it for some fields, but not others). >>=20 >> Now all of them should have been filled. >>=20 > >great. > >>> >>> 414 With respect to ODUflex, ODUflex Constant Bit Rate (CBR) and >>> 415 ODUflex Generig Framing Procedure-Frame mapped (GFP-F) MUST >>> 416 always be advertised separately as they use different >>> 417 adaptation functions. In the case both GFP-F resizable and non >>> 418 resizable (i.e. 21 and 22) are supported, Signal Type 21 >>> 419 implicitely supports also signal Signal Type 22, so=20 >only Signal=20 >>> 420 Type 21 MUST be advertised. Signal Type 22 MUST be used only >>> 421 for non resizable resources. >>> >>> Shouldn't this text be moved to after line 304? >>=20 >> Agree. Done. > >great. > >>=20 >>> >>> Line 416: By separately do you mean "in separate TLVs"? >>=20 >> Yes.changed > >great. > >>> >>> Lines 416/7: Your reference to "different adaptation=20 >functions" lacks=20 >>> context as it is the sole reference in the document to "adaptation=20 >>> functions". I think you need to either define this=20 >terminology (via=20 >>> reference is fine) or replace it some other terminology. >>> >>=20 >> Reference to [G.805] added > >okay. Given the signal type definitions are in [OTN-SIG], what=20 >additional information is added by this paragraph? What am I missing? Things are quite different between signaling and routing when it comes to "= implication". In the case of signaling you either signal type 21 o 22, whil= e in the case of routing if both of them are supported there is no need to = advertise both of them and just signal type 21 is enough because it implies= also signal type 22 support. > >>=20 >>> Line 419/whole document: Please double check the document for=20 >>> spelling errors (there's one in the above paragraph.) >>> >>> Line 423: >>> >>> By "number of multiplexing stages level below the indicated signal=20 >>> type", do you mean "number of multiplexing stages represented as=20 >>> transporting the indicated signal type"? >>> >>> Lines 424-426. It's best not to define semantics through example. =20 >>> How about replacing 423-426 with: >>> >>> - Number of stages (8 bits): This field indicates the number of=20 >>> multiplexing stages used to transport the indicated signal type. It=20 >>> MUST be set to the number of stages represented in the TLV. >>> >> OK >>=20 >>> >>> Line 428: s/Flags:/Flags (8 bits) >>=20 >> ok >>> >>> Lines 455-462: should be revised to use 2119 conformance language=20 >>> (and to clarify the malformed text.) >>=20 >> OK >>=20 >>> >>> The "RES" field isn't defined. >>=20 >> - Res (3 bits): reserved bits. MUST be set to 0. > >"and ignored on receipt." Ok > >>=20 >>> >>> 464-479: I know what you mean, but I think the text really isn't=20 >>> clear and should be revised. Suggest you just rewrite rather then=20 >>> tweak (as we tried in this rev.) I'm happy to discuss on=20 >list if that=20 >>> will help. >>> >>=20 >> OLD >> 464 - Priority (8 bits): field with 1 flag for each=20 >priority. Each >> 465 bit MUST be set when the related priority is=20 >supported and MUST be >> 466 cleared when the related priority is not=20 >supported. The priority >> 467 0 is related to the most significant bit. When=20 >no priority is >> 468 supported, priority 0 MUST be advertised. >>=20 >> 470 - Stage#1 ... Stage#N : These fields are 8 bits=20 >long. Their >> 471 number is variable and a field is present for each of the >> 472 indicated number of stages. The last one MUST=20 >always indicate the >> 473 server ODU container (ODUk/OTUk) and they MUST be=20 >listed in >> 474 ascending order. The values of the Stage fields=20 >MUST be the same >> 475 ones defined for the Signal Type field. If the=20 >number of stages >> 476 is 0, then the Stage and Padding fields MUST be omitted. >>=20 >> 478 - Padding: Given that the number of Stages is=20 >variable, padding to >> 479 32 bits field MUST be used when needed. >>=20 >> NEW >>=20 >> - Priority (8 bits): bitmap used to state which priorities are being >s/state/indicate >> advertised. The left most bit represent priority 0 (highest) and the=20 >> right most priority 7 (lowest) And are presented in ascending orded. >s/) A/), a >s/orded/ordered > >> Each bit MUST be set when the related priority is supported and MUST >"A bit MUST be set (1) for each corresponding priority=20 >represented in the TLV and MUST" > >> be cleared when the related priority is not supported.=20 >s/be cleared/NOT be set (0) >s/supported/represented. > >> When the >> interface does not support priorities, the advertisement MUST be=20 >> compliant with the advertisement of priority 0. >>=20 >Replace with >"At least one priority level MUST be advertised. A value of=20 >zero (0) MUST be used when not overridden by local policy." NEW - Priority (8 bits): field with 1 flag for each priority. A bit MUST= be set (1) for each corresponding priority=20 represented in the TLV and MUST NOT be set (0) when the related priority= is not represented.=20 At least one priority level MUST be advertised. A value of zero (0) MUST= be used when not overridden by local policy. > >> - Stage#1 ... Stage#N : Each field is 8 bits long. One=20 >field MUST be=20 >> used in ascending order (from the lowest order ODU to the highest=20 >> order ODU) for each stage of the muxing branch being advertised. The=20 >> last one MUST always indicate the server ODU container (ODUk/OTUk). >> The values of the Stage fields MUST be the same ones defined for the=20 >> Signal Type field. If the number of stages is 0, the Stage=20 >field MUST=20 >> NOT be included. >>=20 >How about: >Stage (8 bits): Each Stage field indicates the signal type=20 >used in the to transport the signal indicated in the Signal=20 >Type field. The number of Stage fields included in a TLV MUST=20 >equal the value of the Number of Stages field. The Stage=20 >fields MUST be ordered to match the data plane in ascending=20 >order (from the lowest order ODU to the highest order ODU). Saying that each stage field indicates the signal type used to transport th= e signal indicated in the signal type field is not correct because e.g. In = the case of ODU1->ODU2->ODU3 it is not correct to say that ODU2 and ODU3 ar= e used to transport the ODU1 because the ODU2 tranports the ODU1 and the OD= U3 tranports the ODU3. How about: - Stage (8 bits): Each Stage field indicates the signal type beloning to= the muxing branch used to=20 transport the signal indicated in the Signal=20 Type field. The number of Stage fields included in a TLV MUST equal the va= lue of the Number of Stages field. The Stage=20 fields MUST be ordered to match the data plane in ascending order (from th= e lowest order ODU to the highest order ODU). The values of the Stage fields MUST be the same ones defined for the = Signal Type field. If the number of stages is 0, then the Stage and Padding fields MUST be omi= tted. > > >> - Padding: Padding bytes MUST be inserted so that the >> subsequent field starts at a 4-byte aligned boundary. It is >> important to note that the Length field includes the padding >> bytes. Padding SHOULD be using zeros. >>=20 >How about: >Padding (variable): The Padding field is used to ensure the 32=20 >bit alignment of stage fields. The length of the Padding field=20 >is always a multiple of 8 bits (1 byte). Its length can be=20 >calculated, in bytes, as: > % 4 When present, the=20 >Padding field MUST be set to a zero (0) value on transmission=20 >and MUST be ignored on receipt. > In case of number of stages =3D=3D 3, " %= 4" is 3, correct? While the padding bytes is 1. Wouldn't "4-" be more correct? How about: - Padding (variable): The Padding field is used to ensure the 32 bit al= ignment of stage fields. The length of the Padding field is always a multiple of 8 bits (1 byte).= Its length can be=20 calculated, in bytes, as: 4- "value of Number of Stages field". The Padd= ing field MUST be set to a zero (0) value on transmission and MUST be ignored on receip= t. >>=20 >>> 481-493: I still find this text is really confusing. I think it=20 >>> would cleaner to separate out the fixed container and variable=20 >>> container field definitions (3 definitions: Unres ODUj at Prio N,=20 >>> Unreserved Bandwidth at priority N, and MAX LSP Bandwidth=20 >at priority=20 >>> N). Again happy to discuss further on list. >>> >>=20 >> OLD >> 481 - Unreserved Bandwidth/Max LSP BW : In case of=20 >fixed containers >> 482 (Type=3D1) the Unreserved Bandwidth field MUST be=20 >16 bits long and >> 483 indicates the Unreserved Bandwidth in number of available >> 484 containers. Unreserved/MAX LSP BW fields for=20 >each identified >> 485 priority MUST be included, in order of increasing=20 >prioritiy (0 to >> 486 7) and Unreserved/MAX LSP BW fields for other=20 >priority values MUST >> 487 be omitted. In case the number of supported=20 >priorities is odd, a >> 488 16 bits all zeros padding field MUST be added. =20 >On the other hand, >> 489 in case of variable containers (Type 2) the=20 >Unreserved/MAX LSP >> 490 Bandwidth fields MUST be 32 bits long and=20 >expressed in IEEE >> 491 floating point format. The advertisement of the=20 >MAX LSP bandwidth >> 492 MUST take into account HO OPUk bit rate tolerance and be >> 493 calculated according to the following formula: >>=20 >> NEW >> - Unreserved ODUj at Prio N (16 bits): This field is used=20 >only in case=20 >> of fixed containers (Type=3D1). It MUST be 16 bits long and indicates=20 >> the Unreserved Bandwidth in number of available containers. >> A different field for each supported priority MUST be used. In case=20 >> the number of supported priorities is odd, a 16 bits all=20 >zeros padding=20 >> field MUST be added. >>=20 >How about: >- Unreserved ODUj (16 bits): This field indicates the=20 >Unreserved Bandwidth at a particular priority level. This=20 >field MUST be set to the number of ODUs at the indicated the=20 >Signal Type for a particular priority level. One field MUST=20 >be present for each bit set in the Priority field, and is=20 >ordered to match the Priority field. Fields MUST not be=20 >present for priority levels that are not indicated in the=20 >Priority field.This field is REQUIRED for Type 1 (fixed=20 >container) TLVs, and MUST NOT be used for Type 2 TLVs. > >Also: >Unreserved Padding (variable): The Padding field is used to ensure the >32 bit alignment of Unreserved ODUj fields. The length of the=20 >Unreserved Padding field is always a multiple of 16 bits (2=20 >byte). Its length can be calculated, in bytes, as: > % 2=20 >When present, the Unreserved Padding field MUST be set to a=20 >zero (0) value on transmission and MUST be ignored on receipt. > Ok, but shouldn't it be:=20 "Its length can be calculated, in multiple of 2 bytes, as: "number of priorities indicated in Priorities field" % 2." ? When the number of priorities is odd, the unreserved padding field is 2 byt= e, when the number of priorities is even, the padding field is not there. >> - Unreserved Bandwidth at priority N (32 bits): This field is used=20 >> only in case of variable containers (Type=3D2). It MUST be 32=20 >bits long=20 >> and indicates the Unreserved Bandwidth in bits/s in IEEE floating=20 >> point format. A different field for each supported priority MUST be=20 >> used. >>=20 >How about: >Unreserved Bandwidth (32 bits): This field indicates the=20 >Unreserved Bandwidth at a particular priority level. This=20 >field MUST be set to the bandwidth, in bits/s in IEEE=20 >floating point format, available at the indicated the Signal=20 >Type for a particular priority level. One field MUST be=20 >present for each bit set in the Priority field, and is ordered=20 >to match the Priority field. Fields MUST not be present for=20 >priority levels that are not indicated in the Priority=20 >field.This field is REQUIRED for Type 2 (variable container)=20 >TLVs, and MUST NOT be used for Type 1 TLVs. > >> - MAX LSP Bandwidth at priority N (32 bit): This field is=20 >used only in=20 >> case of variable containers (Type=3D2). It MUST be 32 bits long and=20 >> expressed in bits/s in IEEE floating point format. The advertisement=20 >> of the MAX LSP bandwidth MUST take into account HO OPUk bit rate=20 >> tolerance and be calculated according to the following formula: >>=20 >How about: >Maximum LSP Bandwidth (32 bit): This field indicates the=20 >maximum bandwidth that can be allocated for a single LSP at a=20 >particular priority level. This field MUST be set to the=20 >maximum bandwidth, in bits/s in IEEE floating point format,=20 >available to a single LSP at the indicated the Signal Type for=20 >a particular priority level. One field MUST be present for=20 >each bit set in the Priority field, and is ordered to match=20 >the Priority field. Fields MUST not be present for priority=20 >levels that are not indicated in the Priority field.This field=20 >is REQUIRED for Type 2 (variable container) TLVs, and MUST NOT=20 >be used for Type 1 TLVs. > OK > >>>> >>>>> ... >>>>>> 6) Finally, some nits: >>>>>> s/[OTN-INFO], the OSPF-TE/[OTN-INFO], OSPF-TE s/list of them/list >>>>> s/Priority :8 bits/Priority (8 bits): >>>>>> s/infer/imply >>>>>> >>>>>> >>>>> >>>>> - You have some very nice examples, but are inconsistent=20 >in filling=20 >>>>> in field values. I think all values that can possibly be=20 >filled in=20 >>>>> in the examples should be. >>>>> >>>> >>>> All the relevant ones have been introduces. Some non=20 >relevant fields=20 >>>> have been left with just the field name in. E.g. In an >>> example showing >>>> priorities management the T, S and TSG fields have not been filled=20 >>>> with 1 or 0 but just T,S and TSG have been left to make=20 >the reading=20 >>>> easier. >>>> >>> >>> I think this will confuse some readers. I think it would=20 >be better =20 >>> to fill in as much as possible, and if not, indicate that=20 >the fields=20 >>> are not important to the case (or can carry a specific set of=20 >>> values). For example why not show that reserved&padding fields are=20 >>> 0, that the SWCaps=3DOTN-TDM, etc. >>=20 >> Done (only T, S ans TSG left indicated as T, S and TSG when non=20 >> relevant for the example) >>=20 > >Will you add text to that effect to each of those examples? OK > >>> >>>>> Detailed editorial and technical comments: >>>>> >>> Thank you! >>> [...] >>> >>> >>>>> - Section 7 -- update to reference 4203 and 5920. Discuss=20 >>>>> implications / added risk of additional information >>> provided in this >>>>> document. >>>> Reference to 4203 added and this piece of text added at the end: >>>> >>>> For security threats, defensive techniques,=20 >monitoring/detection/ >>>> reporting of security attacks and requirements please refer to >>>> [RFC5920] . >>>> >>>>> >>>>> Section 8. This section needs some work. (I'm assuming your=20 >>>>> familiar with rfc5226). >>>> >>> >>> Hereto, we'll see what the reviewers say... >>> >>>> What about: >>>> >>>> 8. IANA Considerations >>>> >>>> Upon approval of this document, IANA will make the=20 >assignment of a >>>> new registry, the "OTN-TDM Container Registry" under a new GMPLS >>>> Routing Parameters" with two new types (1 and 2) >>>> >>>> >>>> Switching Type Description Reference >>>> ---------------------- -------------------------- ---------- >>>> 110 (suggested) OTN-TDM capable (OTN-TDM) [This.I-D] >>>> >>>> This document defines the following sub-TLVs of the ISCD TLV: >>>> >>>> Value Sub-TLV >>>> ----- ------------------------------------------------- >>>> 1 Unreserved Bandwidth for fixed containers >>>> 2 Unreserved/MAX LSP bandwidth for flexible containers >>>> >>>>> >>>>> - Switching types are assigned in >>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig- >>>>> parameters.xml#gmpls-sig-parameters-3 >>>>> (Again I suggest 110, not 101, but this isn't a big deal) >>>>> >>>>> - I think you are actually asking for IANA to establish a >>> new registry. >>>>> Perhaps something like "OTN-TDM Container Registry" under a new=20 >>>>> "GMPLS Routing Parameters" with two new types. >>> >>> Sorry, I wasn't clear in my prior mail. I didn't mean for the text=20 >>> to end up in the draft unmodified. Take a look at >>>=20 >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-dcsc-channel-ext-04 >>> for an example of how to ask for a new Switching Type, and >>> http://tools.ietf.org/html/draft-ietf-ccamp-rfc4420bis-03 for an=20 >>> example of how to ask for a new TLV registry. >>=20 >>=20 >> Upon approval of this document, IANA will make the=20 >assignment in the >> "Switching Types" section of the "GMPLS Signaling Parameters" >> registry located at=20 >http://www.iana.org/assignments/gmpls-sig-parameters:=20 >> Value Type Reference >> --------- -------------------------- ---------- >> 110 (*) OTN-TDM capable (OTN-TDM) [This.I-D] >>=20 >> (*) Suggested value >> This document defines a new sub-TLV for the ISCD sub-TLV. >How about >This document defines 2 new TLVs that are carried in Interface=20 >Switching Capability Descriptors [RFC4203] with Signal Type OTN-TDM. > >> Each >> TLV includes a 16-bit type identifier (the T-field). Two >s/Two/The same >> T-field values are applicable to the new sub-TLV. ok >>=20 >> IANA >> The IANA has created a new registry and will manage TLV type >> identifiers as follows: >How about: >Upon approval of this document, IANA will create and maintain=20 >a new registry, the "sub-TLVs of the OTN-TDM Interface=20 >Switching Capability Descriptor TLV" registry under the "Open=20 >Shortest Path First >(OSPF) Traffic Engineering TLVs" registry, see=20 >http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traf fic-eng-tlvs.xml, > with the TLV types as follows: > >>=20 >> - TLV Type =3D 1 >> - TLV Name =3D Unreserved Bandwidth for fixed containers >> =20 >> - TLV Type =3D 2 >> - TLV Name =3D Unreserved Bandwidth for fixed containers > >The request Registration Procedures are Standards Action. > >Lou > >>=20 >>> >>> Lou >>> >>>>> >>>>> That's it on this document. >>>>> >>>>> Lou >>>>> >>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>>> Behalf Of Lou Berger >>>>> Sent: gioved=EC 20 dicembre 2012 0.28 >>>>> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>>> Subject: Re: [CCAMP] I-D Action:=20 >>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>> >>>>> Authors? >>>>> >>>>> On 12/4/2012 4:34 PM, Lou Berger wrote: >>>>>> Authors, >>>>>> Please review any changes and how LC comments are addressed. >>>>>> >>>>>> Thank you, >>>>>> Lou >>>>>> >>>>>> On 11/28/2012 2:37 AM, internet-drafts@ietf.org wrote: >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. >>>>>>> This draft is a work item of the Common Control and >>>>> Measurement Plane Working Group of the IETF. >>>>>>> >>>>>>> Title : Traffic Engineering Extensions to=20 >>>>> OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN=20 >>>>> Networks >>>>>>> Author(s) : Daniele Ceccarelli >>>>>>> Diego Caviglia >>>>>>> Fatai Zhang >>>>>>> Dan Li >>>>>>> Sergio Belotti >>>>>>> Pietro Vittorio Grandi >>>>>>> Rajan Rao >>>>>>> Khuzema Pithewan >>>>>>> John E Drake >>>>>>> Filename :=20 >draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>>> Pages : 33 >>>>>>> Date : 2012-11-27 >>>>>>> >>>>>>> Abstract: >>>>>>> ITU-T Recommendation G.709 [G.709-2012] has introduced >>>>> new fixed and >>>>>>> flexible Optical Data Unit (ODU) containers,=20 >enabling optimized >>>>>>> support for an increasingly abundant service mix. >>>>>>> >>>>>>> This document describes Open Shortest Path First - Traffic >>>>>>> Engineering (OSPF-TE) routing protocol extensions to support >>>>>>> Generalized MPLS (GMPLS) control of all currently defined ODU >>>>>>> containers, in support of both sub-lambda and lambda >>>>> level routing >>>>>>> granularity. >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> >>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-04 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> >>>>> >>>=20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-0 >>>>>>> 4 >>>>>>> >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>> >>>> >>>> >>> >>=20 >>=20 >>=20 >= From lberger@labn.net Wed Jan 9 09:16:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B4021F86E4 for ; Wed, 9 Jan 2013 09:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 Snm-Dbr-6vRX for ; Wed, 9 Jan 2013 09:16:35 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 26DED21F8652 for ; Wed, 9 Jan 2013 09:16:35 -0800 (PST) Received: (qmail 4151 invoked by uid 0); 9 Jan 2013 17:16:09 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 9 Jan 2013 17:16:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=pC0IvgYKqX5/E7KNn53UU9ZwJ+yLd1dOhHxu1+fJJZI=; b=BbZCXxMIhh2HA1Et3aYHTxLOrb7i1SCz2UH12Uuz50IYnRAB2HMLluw3KKI+XD/lCL7GM/bNMg+TUiglAmRvbNqNEFeKgC/YxrXNP2jQHPzJoLwOfkPkVWNfx/J6nhgP; Received: from box313.bluehost.com ([69.89.31.113]:54367 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TszG5-0008WM-Bu; Wed, 09 Jan 2013 10:16:09 -0700 Message-ID: <50EDA5E3.80106@labn.net> Date: Wed, 09 Jan 2013 12:16:19 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Recommendation G.798 (2010) Amendment 2 (04/12) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 17:16:36 -0000 Hello, Does anyone know when this document is going to be publicly available? Unless I missed it, I don't think IETF participants have open access to this document and it is being referenced in the g.709 drafts. Thanks, Lou From lberger@labn.net Wed Jan 9 10:24:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83FC21F8583 for ; Wed, 9 Jan 2013 10:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.576 X-Spam-Level: X-Spam-Status: No, score=-101.576 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, J_CHICKENPOX_51=0.6, 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 tdXm1pG9qn0K for ; Wed, 9 Jan 2013 10:24:51 -0800 (PST) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 42A7C21F85C8 for ; Wed, 9 Jan 2013 10:24:51 -0800 (PST) Received: (qmail 22130 invoked by uid 0); 9 Jan 2013 18:24:24 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 9 Jan 2013 18:24:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=6xiZ2QvSefFMXSzbOuyM0XuFwxKwyALxkRr5Kh3qDlQ=; b=BKV4rQe7xoJJJN0MkI2EbSXAdb7MvMd2plknW93Ds5QZtj2pqZG/oTnjebLzxIPUtli6R2lknsFTadXV6dyjnMNVj9+17FJhFxlCYxqAokNlNQbkwcT0ZovaxDTUnd9v; Received: from box313.bluehost.com ([69.89.31.113]:35556 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Tt0K8-0003tV-0E; Wed, 09 Jan 2013 11:24:24 -0700 Message-ID: <50EDB5E1.5040200@labn.net> Date: Wed, 09 Jan 2013 13:24:33 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Daniele Ceccarelli References: <20121128073754.7548.6383.idtracker@ietfa.amsl.com> <50BE6C54.7060606@labn.net> <50D24D68.5040005@labn.net> <4A1562797D64E44993C5CBF38CF1BE4804556A@ESESSMB301.ericsson.se> <50D39F51.8010802@labn.net> <4A1562797D64E44993C5CBF38CF1BE48046263@ESESSMB301.ericsson.se> <50D4AB0E.6070207@labn.net> <4A1562797D64E44993C5CBF38CF1BE4805D2BB@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4805D2BB@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 18:24:54 -0000 Daniele, see below. On 1/8/2013 12:39 PM, Daniele Ceccarelli wrote: > Hi Lou, > > Please find further comments in line. > > Since the changes from v04 start to be quite a lot we published v05. Please provide further comments (if any) with respect to that version. > Okay. Note that you have a nit to clean up the next time you update: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-ospf-g709v3-05.txt > BR > Daniele & Sergio > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: venerd 21 dicembre 2012 19.32 >> To: Daniele Ceccarelli >> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >> Subject: Re: [CCAMP] I-D Action: >> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >> >> Daniele, >> Much thanks -- I do expect that the thread might extend >> beyond the end of year holiday, and that many/most are off next week... >> >> See below for responses. >> >> On 12/21/2012 10:49 AM, Daniele Ceccarelli wrote: >>> Hi Lou, >>> >>> Please see in line. >>> >>> We'll upload -05 when all the issues will be solved. >>> >>> BR >>> Daniele & Sergio >>> >>> PS. The info model after christmas holidays >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: venerd 21 dicembre 2012 0.29 >>>> To: Daniele Ceccarelli >>>> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>> >>>> Daniele / Authors, >>>> Thank you for the response. Please see below for my responses. >>>> >>>> >>>> On 12/20/2012 3:57 AM, Daniele Ceccarelli wrote: >>>>> Hi Lou, >>>>> >>>>> Below you can find the last call comments pasted with >>>> replies in line. >>>>> >>>>> All nits, typos and suggested text changes without any >>>> comment in line >>>>> have been accepted/modified accordingly. >>>>> >>>> >>>>> BR >>>>> Daniele & Sergio >>>>> >>>>> >>>>>>> -----Original Message----- >>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>>>> On Behalf >>>>>> Of Lou Berger >>>>>>> Sent: mercoled 26 ottobre 2011 0.37 >>>>>>> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org >>>>>>> Cc: CCAMP >>>>>>> Subject: [CCAMP] some comments on gmpls-ospf-g709v3-00 >>>>>> ... >>>>>>> 2) SCSI TLV formatting >>>>>>> >>>>>>> The field descriptions are missing format related conformance >>>>>>> (RFC2119) language. >>>>>>> >>>>> >>>>> Done >>>> >>>> Thanks. >>>> >>>> Some points: >>>> (Using line numbers from >>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft >>> -ietf-ccamp-gmpls-ospf-g709v3-04.txt) >>>> >>>> I like your solution for the general TLV format definition. >>>> >>>> Lines 303/304: "Different sub-TLV MAY be presented in >> ascending Type >>>> order." >>>> >>>> I suspect you mean s/Different sub-TLV/Multiple sub-TLVs >>>> >>> >>> See below >>> >>>> By "ascending Type order", are you refering to the TLV type? >>>> Are multiple TLVs of the same type allowed? If not, how are errors >>>> handled? >>> >>> Yes and yes. Multiple TLVs of the same type are often >> present as each of them represents a branch of the muxing tree. >>> What about changing into: >>> >>> Sub-TLV SHOULD be presented >>> in ascending Type order (i.e. type 1 before and type 2 after). >> >> Is there any technical reason for such ordering? It doesn't >> seem to add any value to me. > > Ok. It was meant to be just a guideline but indeed doesn't add any > value. Sentence removed. > >> >> I actually was expecting you to say something referring back >> to signal type or number of stages represented in the TLV... > > WRT signal type each TLV is self-consistent, in the sense that there is no need to have them in a given order. In all the example we have ordered them form the root to the leaves of the tree so to make it more "human-readable". We could suggest to follow that orded but like in the case of type 1 and type2 is does not add any value (except being more easily read). > > WRT to number of stage the order is important. Actually the text says that they MUST be put is ascending order and an example (ODU1->ODU2->ODU3) is provided: > > OLD > - Stage#1 ... Stage#N : These fields are 8 bits long. Their number is variable and a field is present for > each of the indicated number of stages. The last one MUST always indicate the server ODU container (ODUk/OTUk) > and they MUST be listed in ascending order from the smallest to the biggest one. > The values of the Stage fields MUST be the same ones defined for the Signal Type field. If > the number of stages is 0, then the Stage and Padding fields MUST be omitted. > > Example: in case the ODU1->ODU2->OD3 hierarchy, the Signal Type field is set to ODU1 and > two Stage fields are present, the first indicating ODU2 and the second ODU3 (server layer). > > We added: "from the smallest to the biggest one." at the end of the first sentence: > > NEW: > [CUT] > The last one MUST always indicate the server ODU container (ODUk/OTUk) > and they MUST be listed in ascending order from the smallest to the biggest one. > [CUT] > >> >>> >>>> >>>> Lines 306-322: >>>> >>>> Given that Figures 4 and 5 completely repeat the information in >>>> Figure 4, I propose that you drop Figure 4. (and align the >> preceding >>>> paragraph to match.) >>> >>> Figure 4 and 5 represent TLV type1 and TLV type2 >> respectively, which are quite different from each other. The >> first 3 rows are identical but the rest of the TLV is pretty >> different. We would prefer to keep both of them. >>> >> >> Ahh. Sorry, let me try again: >> >> Given that Figures 4 and 5 completely repeat the information >> in Figure *4*, I propose that you drop Figure *3*. (and align >> the preceding paragraph to match.) > > Done > > OLD > The format of the SCSI MUST be as depicted in the following figure, where > one Type 1 sub-TLV MUST be used for any fixed container and one Type 2 sub-TLV > MUST be used for any variable container. > NEW > The SCSI MUST include one Type 1 sub-TLV for any fixed container and one Type 2 sub-TLV > for any variable container. > I think this new/revised text is ambiguous: You say "one ... for any" (twice). Is this one for each, or one for all (containers)? The flow into the next paragraph is a bit hard to follow. >> >> Also, just realized that figures 4 and 5 really should >> indicate that priorities are not always included. And that a >> second padding field may be needed too! How about: >> >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type = 1 (Unres-fix) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Signal Type | Num of Stages |T|S| TSG | Res | Priority | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Stage#1 | ... | Stage#N | Padding | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Unreserved ODUj at Prio 0 | ..... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Unreserved ODUj at Prio 7 | Unreserved Padding | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 4: Bandwidth TLV - Type 1 - > > OK. Wrote padding instead of unreserved Padding > >> >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type = 2 (Unres/MAX-var) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Signal Type | Num of Stages |T|S| TSG | Res | Priority | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Stage#1 | ... | Stage#N | Padding | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Unreserved Bandwidth at priority 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Unreserved Bandwidth at priority 7 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Maximum LSP Bandwidth at priority 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Maximum LSP Bandwidth at priority 7 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 5: Bandwidth TLV - Type 2 - >> >> (Note some field names have been expanded to match descriptions) > > OK > >> >>>> >>>>> >>>>>>> >>>>>>> 3) SCSI TLV procedures >>>>>>> >>>>>>> You have defined the formats of the TLVs in Section 4.1, but not >>>>>>> explicitly how they are to be used. Some RFC2119 language >>>> really is >>>>>>> needed to cover how the SCSI is to be encoded and parsed. At a >>>>>>> minimum, any TLV inclusion, ordering requirements, and exception >>>>>>> handling should be covered. (For example, your examples >>>>>> always show a >>>>>>> particular ordering relative to Stage#, is this required, >>>>>> recommended, >>>>>>> or just a possibility. You have some informative language, >>>> which is >>>>>>> great, but you also need some RFC2119 language.) >>>>> >>>>> Done >>>> >>>> The length of each TLV type and each field should be defined. >>>> (You have it for some fields, but not others). >>> >>> Now all of them should have been filled. >>> >> >> great. >> >>>> >>>> 414 With respect to ODUflex, ODUflex Constant Bit Rate (CBR) and >>>> 415 ODUflex Generig Framing Procedure-Frame mapped (GFP-F) MUST >>>> 416 always be advertised separately as they use different >>>> 417 adaptation functions. In the case both GFP-F resizable and non >>>> 418 resizable (i.e. 21 and 22) are supported, Signal Type 21 >>>> 419 implicitely supports also signal Signal Type 22, so >> only Signal >>>> 420 Type 21 MUST be advertised. Signal Type 22 MUST be used only >>>> 421 for non resizable resources. >>>> >>>> Shouldn't this text be moved to after line 304? >>> >>> Agree. Done. >> >> great. >> >>> >>>> >>>> Line 416: By separately do you mean "in separate TLVs"? >>> >>> Yes.changed >> >> great. >> >>>> >>>> Lines 416/7: Your reference to "different adaptation >> functions" lacks >>>> context as it is the sole reference in the document to "adaptation >>>> functions". I think you need to either define this >> terminology (via >>>> reference is fine) or replace it some other terminology. >>>> >>> >>> Reference to [G.805] added >> >> okay. Given the signal type definitions are in [OTN-SIG], what >> additional information is added by this paragraph? What am I missing? > > Things are quite different between signaling and routing when it comes to "implication". In the case of signaling you either signal type 21 o 22, while in the case of routing if both of them are supported there is no need to advertise both of them and just signal type 21 is enough because it implies also signal type 22 support. > >> >>> >>>> Line 419/whole document: Please double check the document for >>>> spelling errors (there's one in the above paragraph.) you still have some errors... >>>> >>>> Line 423: >>>> >>>> By "number of multiplexing stages level below the indicated signal >>>> type", do you mean "number of multiplexing stages represented as >>>> transporting the indicated signal type"? >>>> >>>> Lines 424-426. It's best not to define semantics through example. >>>> How about replacing 423-426 with: >>>> >>>> - Number of stages (8 bits): This field indicates the number of >>>> multiplexing stages used to transport the indicated signal type. It >>>> MUST be set to the number of stages represented in the TLV. >>>> >>> OK >>> >>>> >>>> Line 428: s/Flags:/Flags (8 bits) >>> >>> ok >>>> >>>> Lines 455-462: should be revised to use 2119 conformance language >>>> (and to clarify the malformed text.) >>> >>> OK OLD 409 Value 1 MUST be used on those interfaces where the fallback 410 procedure is enabled and the default value of 1.25 Gbps can be 411 falled back to 2.5 if needed. Value 2 MUST be used on [RFC4328] 412 interfaces while value 3 MUST be used on [G.709-2012] interfaces 413 where the fallback procedure is unsupported/disabled. Value 0 414 MUST be used for non multiplexed signal (i.e. non OTN client). How about: A value of 1 MUST be used on interfaces which are configured to support the fall back procedures defined in [G.798-a2]. A value of 2 MUST be used on interfaces that only support 2.5 Gbps time slots, such as [RFC4328] interfaces. A value of 3 MUST be used on interfaces that are configured to only support 1.25 Gbps time slots. A value or 3 MUST be used for non multiplexed signal types (i.e. a non OTN client). >>> >>>> >>>> The "RES" field isn't defined. >>> >>> - Res (3 bits): reserved bits. MUST be set to 0. >> >> "and ignored on receipt." > > Ok > >> >>> >>>> >>>> 464-479: I know what you mean, but I think the text really isn't >>>> clear and should be revised. Suggest you just rewrite rather then >>>> tweak (as we tried in this rev.) I'm happy to discuss on >> list if that >>>> will help. >>>> >>> >>> OLD >>> 464 - Priority (8 bits): field with 1 flag for each >> priority. Each >>> 465 bit MUST be set when the related priority is >> supported and MUST be >>> 466 cleared when the related priority is not >> supported. The priority >>> 467 0 is related to the most significant bit. When >> no priority is >>> 468 supported, priority 0 MUST be advertised. >>> >>> 470 - Stage#1 ... Stage#N : These fields are 8 bits >> long. Their >>> 471 number is variable and a field is present for each of the >>> 472 indicated number of stages. The last one MUST >> always indicate the >>> 473 server ODU container (ODUk/OTUk) and they MUST be >> listed in >>> 474 ascending order. The values of the Stage fields >> MUST be the same >>> 475 ones defined for the Signal Type field. If the >> number of stages >>> 476 is 0, then the Stage and Padding fields MUST be omitted. >>> >>> 478 - Padding: Given that the number of Stages is >> variable, padding to >>> 479 32 bits field MUST be used when needed. >>> >>> NEW >>> >>> - Priority (8 bits): bitmap used to state which priorities are being >> s/state/indicate >>> advertised. The left most bit represent priority 0 (highest) and the >>> right most priority 7 (lowest) And are presented in ascending orded. >> s/) A/), a >> s/orded/ordered >> >>> Each bit MUST be set when the related priority is supported and MUST >> "A bit MUST be set (1) for each corresponding priority >> represented in the TLV and MUST" >> >>> be cleared when the related priority is not supported. >> s/be cleared/NOT be set (0) >> s/supported/represented. >> >>> When the >>> interface does not support priorities, the advertisement MUST be >>> compliant with the advertisement of priority 0. >>> >> Replace with >> "At least one priority level MUST be advertised. A value of >> zero (0) MUST be used when not overridden by local policy." > > NEW > - Priority (8 bits): field with 1 flag for each priority. A bit MUST be set (1) for each corresponding priority > represented in the TLV and MUST NOT be set (0) when the related priority is not represented. > At least one priority level MUST be advertised. A value of zero (0) MUST be used when not > overridden by local policy. How about: - Priority (8 bits): a bitmap used to indicate which priorities are being advertised. The bitmap is in ascending order, with the leftmost bit representing priority level 0 (i.e., the highest) and the rightmost bit representing priority level 7 (i.e., the lowest). A bit MUST be set (1) corresponding to each priority represented in the TLV, and MUST NOT be set (0) when the corresponding priority is not represented. At least one priority level MUST be advertised that, unless overridden by local policy, SHALL be at priority level 0. >> >>> - Stage#1 ... Stage#N : Each field is 8 bits long. One >> field MUST be >>> used in ascending order (from the lowest order ODU to the highest >>> order ODU) for each stage of the muxing branch being advertised. The >>> last one MUST always indicate the server ODU container (ODUk/OTUk). >>> The values of the Stage fields MUST be the same ones defined for the >>> Signal Type field. If the number of stages is 0, the Stage >> field MUST >>> NOT be included. >>> >> How about: >> Stage (8 bits): Each Stage field indicates the signal type >> used in the to transport the signal indicated in the Signal >> Type field. The number of Stage fields included in a TLV MUST >> equal the value of the Number of Stages field. The Stage >> fields MUST be ordered to match the data plane in ascending >> order (from the lowest order ODU to the highest order ODU). > > Saying that each stage field indicates the signal type used to > transport the signal indicated in the signal type field is not > correct because e.g. In the case of ODU1->ODU2->ODU3 it is not > correct to say that ODU2 and ODU3 are used to transport the ODU1 > because the ODU2 tranports the ODU1 and the ODU3 tranports the ODU3. > How about: > > - Stage (8 bits): Each Stage field indicates the signal type > beloning to the muxing branch used to transport the signal indicated > in the Signal Type field. The number of Stage fields included in a > TLV MUST equal the value of the Number of Stages field. The Stage > fields MUST be ordered to match the data plane in ascending order > (from the lowest order ODU to the highest order ODU). The values of > the Stage fields MUST be the same ones defined for the Signal Type > field. If the number of stages is 0, then the Stage and Padding > fields MUST be omitted. > How about: Stage (8 bits): Each Stage field indicates a signal type in the multiplexing hierarchy used to transport the signal indicated in the Signal Type field. The number of Stage fields included in a TLV MUST equal the value of the Number of Stages field. The Stage fields MUST be ordered to match the data plane in ascending order (from the lowest order ODU to the highest order ODU). The values of the Stage field are the same as those defined for the Signal Type field. When the Number of stage field carries a 0, then the Stage and Padding fields MUST be omitted. >> >> >>> - Padding: Padding bytes MUST be inserted so that the >>> subsequent field starts at a 4-byte aligned boundary. It is >>> important to note that the Length field includes the padding >>> bytes. Padding SHOULD be using zeros. >>> >> How about: >> Padding (variable): The Padding field is used to ensure the 32 >> bit alignment of stage fields. The length of the Padding field >> is always a multiple of 8 bits (1 byte). Its length can be >> calculated, in bytes, as: >> % 4 When present, the >> Padding field MUST be set to a zero (0) value on transmission >> and MUST be ignored on receipt. >> > > In case of number of stages == 3, " % 4" is 3, correct? While the padding bytes is 1. > Wouldn't "4-" be more correct? Woops. 4-( % 4), right? > > How about: > - Padding (variable): The Padding field is used to ensure the 32 bit alignment of stage fields. > The length of the Padding field is always a multiple of 8 bits (1 byte). Its length can be > calculated, in bytes, as: 4- "value of Number of Stages field". see above. > The Padding field MUST > be set to a zero (0) value on transmission and MUST be ignored on receipt. s/The/When present, the > >>> >>>> 481-493: I still find this text is really confusing. I think it >>>> would cleaner to separate out the fixed container and variable >>>> container field definitions (3 definitions: Unres ODUj at Prio N, >>>> Unreserved Bandwidth at priority N, and MAX LSP Bandwidth >> at priority >>>> N). Again happy to discuss further on list. >>>> >>> >>> OLD >>> 481 - Unreserved Bandwidth/Max LSP BW : In case of >> fixed containers >>> 482 (Type=1) the Unreserved Bandwidth field MUST be >> 16 bits long and >>> 483 indicates the Unreserved Bandwidth in number of available >>> 484 containers. Unreserved/MAX LSP BW fields for >> each identified >>> 485 priority MUST be included, in order of increasing >> prioritiy (0 to >>> 486 7) and Unreserved/MAX LSP BW fields for other >> priority values MUST >>> 487 be omitted. In case the number of supported >> priorities is odd, a >>> 488 16 bits all zeros padding field MUST be added. >> On the other hand, >>> 489 in case of variable containers (Type 2) the >> Unreserved/MAX LSP >>> 490 Bandwidth fields MUST be 32 bits long and >> expressed in IEEE >>> 491 floating point format. The advertisement of the >> MAX LSP bandwidth >>> 492 MUST take into account HO OPUk bit rate tolerance and be >>> 493 calculated according to the following formula: >>> >>> NEW >>> - Unreserved ODUj at Prio N (16 bits): This field is used >> only in case >>> of fixed containers (Type=1). It MUST be 16 bits long and indicates >>> the Unreserved Bandwidth in number of available containers. >>> A different field for each supported priority MUST be used. In case >>> the number of supported priorities is odd, a 16 bits all >> zeros padding >>> field MUST be added. >>> >> How about: >> - Unreserved ODUj (16 bits): This field indicates the >> Unreserved Bandwidth at a particular priority level. This >> field MUST be set to the number of ODUs at the indicated the >> Signal Type for a particular priority level. One field MUST >> be present for each bit set in the Priority field, and is >> ordered to match the Priority field. Fields MUST not be s/MUST not/MUST NOT >> present for priority levels that are not indicated in the >> Priority field. >> This field is REQUIRED for Type 1 (fixed >> container) TLVs, and MUST NOT be used for Type 2 TLVs. >> Actually, these lines are redundant with the format definition and can be dropped. >> Also: >> Unreserved Padding (variable): The Padding field is used to ensure the >> 32 bit alignment of Unreserved ODUj fields. The length of the >> Unreserved Padding field is always a multiple of 16 bits (2 >> byte). Its length can be calculated, in bytes, as: >> % 2 >> When present, the Unreserved Padding field MUST be set to a >> zero (0) value on transmission and MUST be ignored on receipt. >> > > Ok, but shouldn't it be: > "Its length can be calculated, in multiple of 2 bytes, > as: "number of priorities indicated in Priorities field" % 2." ? > > When the number of priorities is odd, the unreserved padding field is 2 byte, when the number of priorities is even, the padding field is not there. > How about: - Unreserved Padding (variable): The Padding field is used to ensure the 32 bit alignment of Unreserved ODUj fields. When present the Unreserved Padding field is 16 bits (2 byte) long. When the number of priorities is odd, the unreserved Unreserved Padding field MUST be included. When the number of priorities is even, the Unreserved Padding MUST be omitted. > >>> - Unreserved Bandwidth at priority N (32 bits): This field is used >>> only in case of variable containers (Type=2). It MUST be 32 >> bits long >>> and indicates the Unreserved Bandwidth in bits/s in IEEE floating >>> point format. A different field for each supported priority MUST be >>> used. >>> >> How about: >> Unreserved Bandwidth (32 bits): This field indicates the >> Unreserved Bandwidth at a particular priority level. This >> field MUST be set to the bandwidth, in bits/s in IEEE >> floating point format, available at the indicated the Signal >> Type for a particular priority level. One field MUST be >> present for each bit set in the Priority field, and is ordered >> to match the Priority field. Fields MUST not be present for >> priority levels that are not indicated in the Priority >> field.This field is REQUIRED for Type 2 (variable container) >> TLVs, and MUST NOT be used for Type 1 TLVs. >> The Unreserved Bandwidth field remains undefined in the current text. >>> - MAX LSP Bandwidth at priority N (32 bit): This field is >> used only in >>> case of variable containers (Type=2). It MUST be 32 bits long and >>> expressed in bits/s in IEEE floating point format. The advertisement >>> of the MAX LSP bandwidth MUST take into account HO OPUk bit rate >>> tolerance and be calculated according to the following formula: >>> >> How about: >> Maximum LSP Bandwidth (32 bit): This field indicates the >> maximum bandwidth that can be allocated for a single LSP at a >> particular priority level. This field MUST be set to the >> maximum bandwidth, in bits/s in IEEE floating point format, >> available to a single LSP at the indicated the Signal Type for >> a particular priority level. One field MUST be present for >> each bit set in the Priority field, and is ordered to match >> the Priority field. Fields MUST not be present for priority >> levels that are not indicated in the Priority field. >> This field >> is REQUIRED for Type 2 (variable container) TLVs, and MUST NOT >> be used for Type 1 TLVs. >> Actually, these lines are redundant with the format definition and can be dropped. > > OK > >> >>>>> >>>>>> ... >>>>>>> 6) Finally, some nits: >>>>>>> s/[OTN-INFO], the OSPF-TE/[OTN-INFO], OSPF-TE s/list of them/list >>>>>> s/Priority :8 bits/Priority (8 bits): >>>>>>> s/infer/imply >>>>>>> >>>>>>> >>>>>> >>>>>> - You have some very nice examples, but are inconsistent >> in filling >>>>>> in field values. I think all values that can possibly be >> filled in >>>>>> in the examples should be. >>>>>> >>>>> >>>>> All the relevant ones have been introduces. Some non >> relevant fields >>>>> have been left with just the field name in. E.g. In an >>>> example showing >>>>> priorities management the T, S and TSG fields have not been filled >>>>> with 1 or 0 but just T,S and TSG have been left to make >> the reading >>>>> easier. >>>>> >>>> >>>> I think this will confuse some readers. I think it would >> be better >>>> to fill in as much as possible, and if not, indicate that >> the fields >>>> are not important to the case (or can carry a specific set of >>>> values). For example why not show that reserved&padding fields are >>>> 0, that the SWCaps=OTN-TDM, etc. >>> >>> Done (only T, S ans TSG left indicated as T, S and TSG when non >>> relevant for the example) >>> >> >> Will you add text to that effect to each of those examples? > > OK > >> >>>> >>>>>> Detailed editorial and technical comments: >>>>>> >>>> Thank you! >>>> [...] >>>> >>>> >>>>>> - Section 7 -- update to reference 4203 and 5920. Discuss >>>>>> implications / added risk of additional information >>>> provided in this >>>>>> document. >>>>> Reference to 4203 added and this piece of text added at the end: >>>>> >>>>> For security threats, defensive techniques, >> monitoring/detection/ >>>>> reporting of security attacks and requirements please refer to >>>>> [RFC5920] . >>>>> >>>>>> >>>>>> Section 8. This section needs some work. (I'm assuming your >>>>>> familiar with rfc5226). >>>>> >>>> >>>> Hereto, we'll see what the reviewers say... >>>> >>>>> What about: >>>>> >>>>> 8. IANA Considerations >>>>> >>>>> Upon approval of this document, IANA will make the >> assignment of a >>>>> new registry, the "OTN-TDM Container Registry" under a new GMPLS >>>>> Routing Parameters" with two new types (1 and 2) >>>>> >>>>> >>>>> Switching Type Description Reference >>>>> ---------------------- -------------------------- ---------- >>>>> 110 (suggested) OTN-TDM capable (OTN-TDM) [This.I-D] >>>>> >>>>> This document defines the following sub-TLVs of the ISCD TLV: >>>>> >>>>> Value Sub-TLV >>>>> ----- ------------------------------------------------- >>>>> 1 Unreserved Bandwidth for fixed containers >>>>> 2 Unreserved/MAX LSP bandwidth for flexible containers >>>>> >>>>>> >>>>>> - Switching types are assigned in >>>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig- >>>>>> parameters.xml#gmpls-sig-parameters-3 >>>>>> (Again I suggest 110, not 101, but this isn't a big deal) >>>>>> >>>>>> - I think you are actually asking for IANA to establish a >>>> new registry. >>>>>> Perhaps something like "OTN-TDM Container Registry" under a new >>>>>> "GMPLS Routing Parameters" with two new types. >>>> >>>> Sorry, I wasn't clear in my prior mail. I didn't mean for the text >>>> to end up in the draft unmodified. Take a look at >>>> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-dcsc-channel-ext-04 >>>> for an example of how to ask for a new Switching Type, and >>>> http://tools.ietf.org/html/draft-ietf-ccamp-rfc4420bis-03 for an >>>> example of how to ask for a new TLV registry. >>> >>> >>> Upon approval of this document, IANA will make the >> assignment in the >>> "Switching Types" section of the "GMPLS Signaling Parameters" >>> registry located at >> http://www.iana.org/assignments/gmpls-sig-parameters: >>> Value Type Reference >>> --------- -------------------------- ---------- >>> 110 (*) OTN-TDM capable (OTN-TDM) [This.I-D] >>> >>> (*) Suggested value >>> This document defines a new sub-TLV for the ISCD sub-TLV. >> How about >> This document defines 2 new TLVs that are carried in Interface >> Switching Capability Descriptors [RFC4203] with Signal Type OTN-TDM. >> >>> Each >>> TLV includes a 16-bit type identifier (the T-field). Two >> s/Two/The same >>> T-field values are applicable to the new sub-TLV. > ok > >>> >>> IANA >>> The IANA has created a new registry and will manage TLV type >>> identifiers as follows: >> How about: >> Upon approval of this document, IANA will create and maintain >> a new registry, the "sub-TLVs of the OTN-TDM Interface >> Switching Capability Descriptor TLV" registry under the "Open >> Shortest Path First >> (OSPF) Traffic Engineering TLVs" registry, see >> http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traf > fic-eng-tlvs.xml, >> with the TLV types as follows: >> >>> >>> - TLV Type = 1 >>> - TLV Name = Unreserved Bandwidth for fixed containers >>> >>> - TLV Type = 2 >>> - TLV Name = Unreserved Bandwidth for fixed containers >> >> The request Registration Procedures are Standards Action. >> What case does "Whether allowed on ISCD sub-TLV" cover? The scope of the registry is the OTN-TDM Interface Switching Capability Descriptor TLV. Thanks, Lou >> Lou >> >>> >>>> >>>> Lou >>>> >>>>>> >>>>>> That's it on this document. >>>>>> >>>>>> Lou >>>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>> Behalf Of Lou Berger >>>>>> Sent: gioved 20 dicembre 2012 0.28 >>>>>> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>>>> Subject: Re: [CCAMP] I-D Action: >>>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>> >>>>>> Authors? >>>>>> >>>>>> On 12/4/2012 4:34 PM, Lou Berger wrote: >>>>>>> Authors, >>>>>>> Please review any changes and how LC comments are addressed. >>>>>>> >>>>>>> Thank you, >>>>>>> Lou >>>>>>> >>>>>>> On 11/28/2012 2:37 AM, internet-drafts@ietf.org wrote: >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line >>>>>> Internet-Drafts directories. >>>>>>>> This draft is a work item of the Common Control and >>>>>> Measurement Plane Working Group of the IETF. >>>>>>>> >>>>>>>> Title : Traffic Engineering Extensions to >>>>>> OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN >>>>>> Networks >>>>>>>> Author(s) : Daniele Ceccarelli >>>>>>>> Diego Caviglia >>>>>>>> Fatai Zhang >>>>>>>> Dan Li >>>>>>>> Sergio Belotti >>>>>>>> Pietro Vittorio Grandi >>>>>>>> Rajan Rao >>>>>>>> Khuzema Pithewan >>>>>>>> John E Drake >>>>>>>> Filename : >> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>>>> Pages : 33 >>>>>>>> Date : 2012-11-27 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> ITU-T Recommendation G.709 [G.709-2012] has introduced >>>>>> new fixed and >>>>>>>> flexible Optical Data Unit (ODU) containers, >> enabling optimized >>>>>>>> support for an increasingly abundant service mix. >>>>>>>> >>>>>>>> This document describes Open Shortest Path First - Traffic >>>>>>>> Engineering (OSPF-TE) routing protocol extensions to support >>>>>>>> Generalized MPLS (GMPLS) control of all currently defined ODU >>>>>>>> containers, in support of both sub-lambda and lambda >>>>>> level routing >>>>>>>> granularity. >>>>>>>> >>>>>>>> >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 >>>>>>>> >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-04 >>>>>>>> >>>>>>>> A diff from the previous version is available at: >>>>>>>> >>>>>> >>>> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-gmpls-ospf-g709v3-0 >>>>>>>> 4 >>>>>>>> >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > From adrian@olddog.co.uk Thu Jan 10 05:05:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538FF21F8833 for ; Thu, 10 Jan 2013 05:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 Eds-DUcUx2nx for ; Thu, 10 Jan 2013 05:05:20 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADB821F882E for ; Thu, 10 Jan 2013 05:05:19 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0AD5HMd026646; Thu, 10 Jan 2013 13:05:18 GMT Received: from 950129200 (089144192226.atnat0001.highway.a1.net [89.144.192.226]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0AD5EC6026592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jan 2013 13:05:16 GMT From: "Adrian Farrel" To: "'Lou Berger'" , "'CCAMP'" Date: Thu, 10 Jan 2013 13:05:16 -0000 Message-ID: <001401cdef33$243758f0$6ca60ad0$@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: Ac3vMyFObSEnmBJVSSmdb+wyYQL5ZA== Content-Language: en-gb Subject: Re: [CCAMP] Recommendation G.798 (2010) Amendment 2 (04/12) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 13:05:21 -0000 You're right. Although this seems to have been approved in April 2012 and is "in force", it is in "pre-published state" and can only be downloaded by people with an ITU-T access account (TIES). If you need the material for review you have two options: 1. Send a liaison statement asking that you are sent a copy 2. Ask the liaison manager (John Drake) to negotiate direct with the relevant ITU-T folk to get hold of a copy. There shouldn't be an issue in either case because the document is in the publication process. If you are only worried about the normative reference, then don't worry. The I-D can be held in the RFC Editor Queue until the Amendment is finally published (although you might want to call this out in the shepherd write-up so that it is not fumbled). Cheers, Adrian > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Lou Berger > Sent: 09 January 2013 17:16 > To: CCAMP > Subject: [CCAMP] Recommendation G.798 (2010) Amendment 2 (04/12) > > Hello, > > Does anyone know when this document is going to be publicly available? > Unless I missed it, I don't think IETF participants have open access to > this document and it is being referenced in the g.709 drafts. > > Thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Thu Jan 10 07:13:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772CF21F87BB for ; Thu, 10 Jan 2013 07:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, 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 G7SRW-qQu+Qk for ; Thu, 10 Jan 2013 07:13:26 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 707E221F86A1 for ; Thu, 10 Jan 2013 07:13:26 -0800 (PST) Received: (qmail 2344 invoked by uid 0); 10 Jan 2013 15:13:03 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 10 Jan 2013 15:13:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=VProV4/GHyts6xUwqpWKYa7bMnSrBpMlvXx7CFY36UE=; b=1iMk2x9AQpp8gk8KlmYOssNb0gShdqxCjQWPwpPO0KZNvYnIzPKdB5D+OVw9F+41nK75eCtUjvcTBnIY+fqX++/1Ft4GhpGtp1Rz8E4AHdhinaHGLSzJVJ4+OukZPSku; Received: from box313.bluehost.com ([69.89.31.113]:35314 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TtJoV-00020a-2g; Thu, 10 Jan 2013 08:13:03 -0700 Message-ID: <50EEDA89.30809@labn.net> Date: Thu, 10 Jan 2013 10:13:13 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <001401cdef33$243758f0$6ca60ad0$@olddog.co.uk> In-Reply-To: <001401cdef33$243758f0$6ca60ad0$@olddog.co.uk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: 'CCAMP' Subject: Re: [CCAMP] Recommendation G.798 (2010) Amendment 2 (04/12) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 15:13:27 -0000 Agreed. Another option is to just wait for it to be published if the document is likely to be published in the near future... Lou On 1/10/2013 8:05 AM, Adrian Farrel wrote: > You're right. > > Although this seems to have been approved in April 2012 and is "in force", it is > in "pre-published state" and can only be downloaded by people with an ITU-T > access account (TIES). > > If you need the material for review you have two options: > 1. Send a liaison statement asking that you are sent a copy > 2. Ask the liaison manager (John Drake) to negotiate direct with the > relevant ITU-T folk to get hold of a copy. > There shouldn't be an issue in either case because the document is in the > publication process. > > If you are only worried about the normative reference, then don't worry. The I-D > can be held in the RFC Editor Queue until the Amendment is finally published > (although you might want to call this out in the shepherd write-up so that it is > not fumbled). > > Cheers, > Adrian > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >> Lou Berger >> Sent: 09 January 2013 17:16 >> To: CCAMP >> Subject: [CCAMP] Recommendation G.798 (2010) Amendment 2 (04/12) >> >> Hello, >> >> Does anyone know when this document is going to be publicly available? >> Unless I missed it, I don't think IETF participants have open access to >> this document and it is being referenced in the g.709 drafts. >> >> Thanks, >> Lou >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > From wwwrun@rfc-editor.org Thu Jan 10 14:28:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB05C21F8552; Thu, 10 Jan 2013 14:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUOuAUu7e4TK; Thu, 10 Jan 2013 14:28:45 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 68C1C21F8546; Thu, 10 Jan 2013 14:28:45 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0993DB1E002; Thu, 10 Jan 2013 14:18:18 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130110221818.0993DB1E002@rfc-editor.org> Date: Thu, 10 Jan 2013 14:18:18 -0800 (PST) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 6827 on Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 22:28:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6827 Title: Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols Author: A. Malis, Ed., A. Lindem, Ed., D. Papadimitriou, Ed. Status: Standards Track Stream: IETF Date: January 2013 Mailbox: andrew.g.malis@verizon.com, acee.lindem@ericsson.com, dimitri.papadimitriou@alcatel-lucent.com Pages: 30 Characters: 73279 Obsoletes: RFC5787 Updates: RFC5786 I-D Tag: draft-ietf-ccamp-rfc5787bis-06.txt URL: http://www.rfc-editor.org/rfc/rfc6827.txt The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From daniele.ceccarelli@ericsson.com Fri Jan 11 06:18:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F05321F88EA for ; Fri, 11 Jan 2013 06:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_37=0.6, J_CHICKENPOX_51=0.6, 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 n0PdcLhxXUVC for ; Fri, 11 Jan 2013 06:18:23 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0C01121F88EF for ; Fri, 11 Jan 2013 06:18:21 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-e1-50f01f2ca32d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 39.A9.32353.C2F10F05; Fri, 11 Jan 2013 15:18:20 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.193]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 15:18:19 +0100 From: Daniele Ceccarelli To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt Thread-Index: AQHN0q1CtM7xyI06Pk6wLux+sh8SWpggyrwAgACr+ICAAObagIAA/nUQgABAtwCAHDAwkIABqhyAgALpGHA= Date: Fri, 11 Jan 2013 14:18:18 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4805E624@ESESSMB301.ericsson.se> References: <20121128073754.7548.6383.idtracker@ietfa.amsl.com> <50BE6C54.7060606@labn.net> <50D24D68.5040005@labn.net> <4A1562797D64E44993C5CBF38CF1BE4804556A@ESESSMB301.ericsson.se> <50D39F51.8010802@labn.net> <4A1562797D64E44993C5CBF38CF1BE48046263@ESESSMB301.ericsson.se> <50D4AB0E.6070207@labn.net> <4A1562797D64E44993C5CBF38CF1BE4805D2BB@ESESSMB301.ericsson.se> <50EDB5E1.5040200@labn.net> In-Reply-To: <50EDB5E1.5040200@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja6O/IcAg84jYhZP5txgsfjb8JrF oqP5LYsDs8eSJT+ZPD5sambz+HL5M1sAcxSXTUpqTmZZapG+XQJXxqvZk9kKtm9mqnh2/gNL A+PCj4xdjJwcEgImErNnnWCCsMUkLtxbz9bFyMUhJHCIUeL15evsEM4SRon20zdZuhg5ONgE rCSeHPIBaRARUJT4+nERE0gNs0Aro8Sqcy/AJgkLeElM3XWVCaReRMBb4s6NbIj6JInJM2aA hVkEVCUWLKsGCfMCVdz7f58NxBYSmMks0dCQBmJzCmhI9B1cxApiMwrISkzYvQjsZmYBcYlb T+ZD3SwgsWTPeWYIW1Ti5eN/rBC2osTHV/ug6vUkbkydwgZha0ssW/iaGWKvoMTJmU9YJjCK zUIydhaSlllIWmYhaVnAyLKKkT03MTMnvdx8EyMwcg5u+W2wg3HTfbFDjNIcLErivOGuFwKE BNITS1KzU1MLUovii0pzUosPMTJxcEo1MNpvOSOePzGYX0tk3ekUZqbpDmyLrZdsYI2TDo35 EMnTFeCa+KqgtGW+67evN5X8tjjvqjDgyvXvO3vidna3rqUBh+y6q+utGabeuXJ+XkCDh6nr 74KbV8zXC5s28EwI3zmh869stH7O9Gbfsr+MU5S6WFeusX6uVcJ89ZJ17qaGMr2Z2270K7EU ZyQaajEXFScCAF40cwJqAgAA Cc: CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 14:18:25 -0000 Hi Lou, Please see below. BR Daniele & Sergio >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net] >Sent: mercoled=EC 9 gennaio 2013 19.25 >To: Daniele Ceccarelli >Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >Subject: Re: [CCAMP] I-D Action:=20 >draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt > >Daniele, > >see below. > > >On 1/8/2013 12:39 PM, Daniele Ceccarelli wrote: >> Hi Lou, >>=20 >> Please find further comments in line. >>=20 >> Since the changes from v04 start to be quite a lot we >published v05. Please provide further comments (if any) with respect to=20 >that version. >>=20 > >Okay. Note that you have a nit to clean up the next time you update: >http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft -ietf-ccamp-gmpls-ospf-g709v3-05.txt > fixed > >> BR >> Daniele & Sergio >>=20 >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: venerd=EC 21 dicembre 2012 19.32 >>> To: Daniele Ceccarelli >>> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>> Subject: Re: [CCAMP] I-D Action:=20 >>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>> >>> Daniele, >>> Much thanks -- I do expect that the thread might extend >beyond the >>> end of year holiday, and that many/most are off next week... >>> >>> See below for responses. >>> >>> On 12/21/2012 10:49 AM, Daniele Ceccarelli wrote: >>>> Hi Lou, >>>> >>>> Please see in line. >>>> >>>> We'll upload -05 when all the issues will be solved. >>>> >>>> BR >>>> Daniele & Sergio >>>> >>>> PS. The info model after christmas holidays >>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: venerd=EC 21 dicembre 2012 0.29 >>>>> To: Daniele Ceccarelli >>>>> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>>> Subject: Re: [CCAMP] I-D Action:=20 >>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>> >>>>> Daniele / Authors, >>>>> Thank you for the response. Please see below for my responses. >>>>> >>>>> >>>>> On 12/20/2012 3:57 AM, Daniele Ceccarelli wrote: >>>>>> Hi Lou, >>>>>> >>>>>> Below you can find the last call comments pasted with >>>>> replies in line. >>>>>> >>>>>> All nits, typos and suggested text changes without any >>>>> comment in line >>>>>> have been accepted/modified accordingly. >>>>>> >>>>> >>>>>> BR >>>>>> Daniele & Sergio >>>>>> >>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>>>>> On Behalf >>>>>>> Of Lou Berger >>>>>>>> Sent: mercoled=EC 26 ottobre 2011 0.37 >>>>>>>> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org >>>>>>>> Cc: CCAMP >>>>>>>> Subject: [CCAMP] some comments on gmpls-ospf-g709v3-00 >>>>>>> ... >>>>>>>> 2) SCSI TLV formatting >>>>>>>> >>>>>>>> The field descriptions are missing format related conformance >>>>>>>> (RFC2119) language. >>>>>>>> >>>>>> >>>>>> Done >>>>> >>>>> Thanks. >>>>> >>>>> Some points: >>>>> (Using line numbers from >>>>> http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft >>>> -ietf-ccamp-gmpls-ospf-g709v3-04.txt) >>>>> >>>>> I like your solution for the general TLV format definition. >>>>> >>>>> Lines 303/304: "Different sub-TLV MAY be presented in >>> ascending Type >>>>> order." >>>>> >>>>> I suspect you mean s/Different sub-TLV/Multiple sub-TLVs >>>>> >>>> >>>> See below >>>> >>>>> By "ascending Type order", are you refering to the TLV type?=20 >>>>> Are multiple TLVs of the same type allowed? If not, how >are errors >>>>> handled? >>>> >>>> Yes and yes. Multiple TLVs of the same type are often >>> present as each of them represents a branch of the muxing tree. >>>> What about changing into: >>>> >>>> Sub-TLV SHOULD be presented >>>> in ascending Type order (i.e. type 1 before and type 2 after). >>> >>> Is there any technical reason for such ordering? It doesn't seem to=20 >>> add any value to me. >>=20 >> Ok. It was meant to be just a guideline but indeed doesn't add any=20 >> value. Sentence removed. >>=20 >>> >>> I actually was expecting you to say something referring back to=20 >>> signal type or number of stages represented in the TLV... >>=20 >> WRT signal type each TLV is self-consistent, in the sense >that there is no need to have them in a given order. In all the example=20 >we have ordered them form the root to the leaves of the tree so to make=20 >it more "human-readable". We could suggest to follow that orded but=20 >like in the case of type 1 and type2 is does not add any value (except=20 >being more easily read). >>=20 >> WRT to number of stage the order is important. Actually the >text says that they MUST be put is ascending order and an example=20 >(ODU1->ODU2->ODU3) is provided: >>=20 >> OLD >> - Stage#1 ... Stage#N : These fields are 8 bits long.=20 >Their number is variable and a field is present for >> each of the indicated number of stages. The last one >MUST always indicate the server ODU container (ODUk/OTUk) >> and they MUST be listed in ascending order from the >smallest to the biggest one. >> The values of the Stage fields MUST be the same ones >defined for the Signal Type field. If >> the number of stages is 0, then the Stage and Padding >fields MUST be omitted. >> =20 >> Example: in case the ODU1->ODU2->OD3 hierarchy, the >Signal Type field is set to ODU1 and >> two Stage fields are present, the first indicating >ODU2 and the second ODU3 (server layer).=20 >> =20 >> We added: "from the smallest to the biggest one." at the end >of the first sentence: >>=20 >> NEW: =20 >> [CUT] =20 >> The last one MUST always indicate the server ODU >container (ODUk/OTUk) >> and they MUST be listed in ascending order from the >smallest to the biggest one. >> [CUT] >>=20 >>> >>>> >>>>> >>>>> Lines 306-322: >>>>> >>>>> Given that Figures 4 and 5 completely repeat the information in=20 >>>>> Figure 4, I propose that you drop Figure 4. (and align the >>> preceding >>>>> paragraph to match.) >>>> >>>> Figure 4 and 5 represent TLV type1 and TLV type2 >>> respectively, which are quite different from each other.=20 >The first 3 >>> rows are identical but the rest of the TLV is pretty different. We=20 >>> would prefer to keep both of them. >>>> >>> >>> Ahh. Sorry, let me try again: >>> >>> Given that Figures 4 and 5 completely repeat the information in=20 >>> Figure *4*, I propose that you drop Figure *3*. (and align the=20 >>> preceding paragraph to match.) >>=20 >> Done >>=20 >> OLD >> The format of the SCSI MUST be as depicted in the >following figure, where >> one Type 1 sub-TLV MUST be used for any fixed container >and one Type 2 sub-TLV >> MUST be used for any variable container.=20 >> NEW >> The SCSI MUST include one Type 1 sub-TLV for any fixed >container and one Type 2 sub-TLV >> for any variable container.=20 >>=20 > >I think this new/revised text is ambiguous: > >You say "one ... for any" (twice). Is this one for each, or one for all=20 >(containers)? Yes...One for each...corrected. > >The flow into the next paragraph is a bit hard to follow. > How about: NEW With respect to ODUflex, three different signal types are allowed: 20 - ODUflex Constant Bit Rate (CBR), 21 - ODUflex Generig Framing=20 Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non resizable. They MUST always be advertised in separate Type 2 TLVs as they use different adaptation functions [G.805]. In case both GFP-F resizable and non resizable (i.e. 21 and 22) are supported, only Signal Type 21 MUST be advertised as resizable ODUflex implies non resizable one. Signal Type 22 MUST be used when only non resizable ODUflex is supported. >>> >>> Also, just realized that figures 4 and 5 really should >indicate that >>> priorities are not always included. And that a second >padding field >>> may be needed too! How about: >>> >>> >>> 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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type =3D 1 (Unres-fix) | Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Signal Type | Num of Stages |T|S| TSG | Res | Priority | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Stage#1 | ... | Stage#N | Padding | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Unreserved ODUj at Prio 0 | ..... | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Unreserved ODUj at Prio 7 | Unreserved Padding | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Figure 4: Bandwidth TLV - Type 1 - >>=20 >> OK. Wrote padding instead of unreserved Padding >>=20 >>> >>> >>> 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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type =3D 2 (Unres/MAX-var) | Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Signal Type | Num of Stages |T|S| TSG | Res | Priority | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Stage#1 | ... | Stage#N | Padding | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Unreserved Bandwidth at priority 0 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | ... | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Unreserved Bandwidth at priority 7 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Maximum LSP Bandwidth at priority 0 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | ... | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Maximum LSP Bandwidth at priority 7 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Figure 5: Bandwidth TLV - Type 2 - >>> >>> (Note some field names have been expanded to match descriptions) >>=20 >> OK >>=20 >>> >>>>> >>>>>> >>>>>>>> >>>>>>>> 3) SCSI TLV procedures >>>>>>>> >>>>>>>> You have defined the formats of the TLVs in Section >4.1, but not >>>>>>>> explicitly how they are to be used. Some RFC2119 language >>>>> really is >>>>>>>> needed to cover how the SCSI is to be encoded and parsed. At a=20 >>>>>>>> minimum, any TLV inclusion, ordering requirements, and >exception >>>>>>>> handling should be covered. (For example, your examples >>>>>>> always show a >>>>>>>> particular ordering relative to Stage#, is this required, >>>>>>> recommended, >>>>>>>> or just a possibility. You have some informative language, >>>>> which is >>>>>>>> great, but you also need some RFC2119 language.) >>>>>> >>>>>> Done >>>>> >>>>> The length of each TLV type and each field should be defined.=20 >>>>> (You have it for some fields, but not others). >>>> >>>> Now all of them should have been filled. >>>> >>> >>> great. >>> >>>>> >>>>> 414 With respect to ODUflex, ODUflex Constant Bit Rate (CBR) and >>>>> 415 ODUflex Generig Framing Procedure-Frame mapped (GFP-F) MUST >>>>> 416 always be advertised separately as they use different >>>>> 417 adaptation functions. In the case both GFP-F resizable and=20 >>>>> non >>>>> 418 resizable (i.e. 21 and 22) are supported, Signal Type 21 >>>>> 419 implicitely supports also signal Signal Type 22, so >>> only Signal >>>>> 420 Type 21 MUST be advertised. Signal Type 22 MUST be used only >>>>> 421 for non resizable resources. >>>>> >>>>> Shouldn't this text be moved to after line 304? >>>> >>>> Agree. Done. >>> >>> great. >>> >>>> >>>>> >>>>> Line 416: By separately do you mean "in separate TLVs"? >>>> >>>> Yes.changed >>> >>> great. >>> >>>>> >>>>> Lines 416/7: Your reference to "different adaptation >>> functions" lacks >>>>> context as it is the sole reference in the document to >"adaptation >>>>> functions". I think you need to either define this >>> terminology (via >>>>> reference is fine) or replace it some other terminology. >>>>> >>>> >>>> Reference to [G.805] added >>> >>> okay. Given the signal type definitions are in [OTN-SIG], what=20 >>> additional information is added by this paragraph? What am >I missing? >>=20 >> Things are quite different between signaling and routing >when it comes to "implication". In the case of signaling you either=20 >signal type 21 o 22, while in the case of routing if both of them are=20 >supported there is no need to advertise both of them and just signal=20 >type 21 is enough because it implies also signal type 22 support. >>=20 >>> >>>> >>>>> Line 419/whole document: Please double check the document for=20 >>>>> spelling errors (there's one in the above paragraph.) > >you still have some errors... No more errors seems to be there according to the spell check, if there are= any left please indicate them explicitely. > >>>>> >>>>> Line 423: >>>>> >>>>> By "number of multiplexing stages level below the >indicated signal >>>>> type", do you mean "number of multiplexing stages represented as=20 >>>>> transporting the indicated signal type"? >>>>> >>>>> Lines 424-426. It's best not to define semantics through >example. =20 >>>>> How about replacing 423-426 with: >>>>> >>>>> - Number of stages (8 bits): This field indicates the number of=20 >>>>> multiplexing stages used to transport the indicated >signal type. It >>>>> MUST be set to the number of stages represented in the TLV. >>>>> >>>> OK >>>> >>>>> >>>>> Line 428: s/Flags:/Flags (8 bits) >>>> >>>> ok >>>>> >>>>> Lines 455-462: should be revised to use 2119 conformance language=20 >>>>> (and to clarify the malformed text.) >>>> >>>> OK > >OLD > >409 Value 1 MUST be used on those interfaces where the fallback 410=20 >procedure is enabled and the default value of >1.25 Gbps can be >411 falled back to 2.5 if needed. Value 2 MUST be used on [RFC4328] >412 interfaces while value 3 MUST be used on [G.709-2012] interfaces >413 where the fallback procedure is unsupported/disabled. Value 0 >414 MUST be used for non multiplexed signal (i.e. non OTN client). > >How about: >A value of 1 MUST be used on interfaces which are configured to support=20 >the fall back procedures defined in [G.798-a2]. A value of 2 MUST be=20 >used on interfaces that only support 2.5 Gbps time slots, such as=20 >[RFC4328] interfaces. A value of 3 MUST be used on interfaces that are=20 >configured to only support >1.25 Gbps time slots. A value or 3 MUST be used for non multiplexed=20 >signal types (i.e. a non OTN client). > OK but in the last sentence it's value 0, not 3. >>>> >>>>> >>>>> The "RES" field isn't defined. >>>> >>>> - Res (3 bits): reserved bits. MUST be set to 0. >>> >>> "and ignored on receipt." >>=20 >> Ok >>=20 >>> >>>> >>>>> >>>>> 464-479: I know what you mean, but I think the text really isn't=20 >>>>> clear and should be revised. Suggest you just rewrite=20 >rather then=20 >>>>> tweak (as we tried in this rev.) I'm happy to discuss on >>> list if that >>>>> will help. >>>>> >>>> >>>> OLD >>>> 464 - Priority (8 bits): field with 1 flag for each=20 >>> priority. Each >>>> 465 bit MUST be set when the related priority is=20 >>> supported and MUST be >>>> 466 cleared when the related priority is not=20 >>> supported. The priority >>>> 467 0 is related to the most significant bit. When=20 >>> no priority is >>>> 468 supported, priority 0 MUST be advertised. >>>> >>>> 470 - Stage#1 ... Stage#N : These fields are 8 bits=20 >>> long. Their >>>> 471 number is variable and a field is present=20 >for each of the >>>> 472 indicated number of stages. The last one MUST=20 >>> always indicate the >>>> 473 server ODU container (ODUk/OTUk) and they MUST be=20 >>> listed in >>>> 474 ascending order. The values of the Stage fields=20 >>> MUST be the same >>>> 475 ones defined for the Signal Type field. If the=20 >>> number of stages >>>> 476 is 0, then the Stage and Padding fields=20 >MUST be omitted. >>>> >>>> 478 - Padding: Given that the number of Stages is=20 >>> variable, padding to >>>> 479 32 bits field MUST be used when needed. >>>> >>>> NEW >>>> >>>> - Priority (8 bits): bitmap used to state which priorities=20 >are being >>> s/state/indicate >>>> advertised. The left most bit represent priority 0=20 >(highest) and the=20 >>>> right most priority 7 (lowest) And are presented in=20 >ascending orded. >>> s/) A/), a >>> s/orded/ordered >>> >>>> Each bit MUST be set when the related priority is=20 >supported and MUST >>> "A bit MUST be set (1) for each corresponding priority=20 >represented in=20 >>> the TLV and MUST" >>> >>>> be cleared when the related priority is not supported.=20 >>> s/be cleared/NOT be set (0) >>> s/supported/represented. >>> >>>> When the >>>> interface does not support priorities, the advertisement MUST be=20 >>>> compliant with the advertisement of priority 0. >>>> >>> Replace with >>> "At least one priority level MUST be advertised. A value=20 >of zero (0)=20 >>> MUST be used when not overridden by local policy." >>=20 >> NEW >> - Priority (8 bits): field with 1 flag for each=20 >priority. A bit MUST be set (1) for each corresponding priority=20 >> represented in the TLV and MUST NOT be set (0) when=20 >the related priority is not represented.=20 >> At least one priority level MUST be advertised. A=20 >value of zero (0) MUST be used when not >> overridden by local policy. > >How about: >- Priority (8 bits): a bitmap used to indicate which=20 >priorities are being advertised. The bitmap is in ascending=20 >order, with the leftmost bit representing priority level 0=20 >(i.e., the highest) and the rightmost bit representing=20 >priority level 7 (i.e., the lowest). A bit MUST be set (1)=20 >corresponding to each priority represented in the TLV, and=20 >MUST NOT be set (0) when the corresponding priority is not=20 >represented. At least one priority level MUST be advertised=20 >that, unless overridden by local policy, SHALL be at priority level 0. > OK >>> >>>> - Stage#1 ... Stage#N : Each field is 8 bits long. One >>> field MUST be >>>> used in ascending order (from the lowest order ODU to the highest=20 >>>> order ODU) for each stage of the muxing branch being=20 >advertised. The=20 >>>> last one MUST always indicate the server ODU container (ODUk/OTUk). >>>> The values of the Stage fields MUST be the same ones=20 >defined for the=20 >>>> Signal Type field. If the number of stages is 0, the Stage >>> field MUST >>>> NOT be included. >>>> >>> How about: >>> Stage (8 bits): Each Stage field indicates the signal type used in=20 >>> the to transport the signal indicated in the Signal Type field. The=20 >>> number of Stage fields included in a TLV MUST equal the=20 >value of the=20 >>> Number of Stages field. The Stage fields MUST be ordered to match=20 >>> the data plane in ascending order (from the lowest order ODU to the=20 >>> highest order ODU). >>=20 >> Saying that each stage field indicates the signal type used to=20 >> transport the signal indicated in the signal type field is=20 >not correct=20 >> because e.g. In the case of ODU1->ODU2->ODU3 it is not=20 >correct to say=20 >> that ODU2 and ODU3 are used to transport the ODU1 because the ODU2=20 >> tranports the ODU1 and the ODU3 tranports the ODU3. >> How about: >>=20 >> - Stage (8 bits): Each Stage field indicates the signal type=20 >> beloning to the muxing branch used to transport the signal indicated=20 >> in the Signal Type field. The number of Stage fields=20 >included in a TLV=20 >> MUST equal the value of the Number of Stages field. The=20 >Stage fields=20 >> MUST be ordered to match the data plane in ascending order (from the=20 >> lowest order ODU to the highest order ODU). The values of the Stage=20 >> fields MUST be the same ones defined for the Signal Type=20 >field. If the=20 >> number of stages is 0, then the Stage and Padding fields MUST be=20 >> omitted. >>=20 > >How about: >Stage (8 bits): Each Stage field indicates a signal type in=20 >the multiplexing hierarchy used to transport the signal=20 >indicated in the Signal Type field. The number of Stage fields=20 >included in a TLV MUST equal the value of the Number of Stages=20 >field. The Stage fields MUST be ordered to match the data=20 >plane in ascending order (from the lowest order ODU to the=20 >highest order ODU). The values of the Stage field are the same=20 >as those defined for the Signal Type field. When the Number of=20 >stage field carries a 0, then the Stage and Padding fields=20 >MUST be omitted. > OK >>> >>> >>>> - Padding: Padding bytes MUST be inserted so that the >>>> subsequent field starts at a 4-byte aligned=20 >boundary. It is >>>> important to note that the Length field includes=20 >the padding >>>> bytes. Padding SHOULD be using zeros. >>>> >>> How about: >>> Padding (variable): The Padding field is used to ensure the 32 bit=20 >>> alignment of stage fields. The length of the Padding field=20 >is always=20 >>> a multiple of 8 bits (1 byte). Its length can be calculated, in=20 >>> bytes, as: >>> % 4 When present,=20 >the Padding=20 >>> field MUST be set to a zero (0) value on transmission and MUST be=20 >>> ignored on receipt. >>> >>=20 >> In case of number of stages =3D=3D 3, "Stages field> % 4" is 3, correct? While the padding bytes is 1. >> Wouldn't "4-" be more correct? > >Woops. 4-( % 4), right? OK > > >>=20 >> How about: >> - Padding (variable): The Padding field is used to=20 >ensure the 32 bit alignment of stage fields. >> The length of the Padding field is always a multiple=20 >of 8 bits (1 byte). Its length can be=20 >> calculated, in bytes, as: 4- "value of Number of=20 >Stages field".=20 >see above. >> The Padding field MUST >> be set to a zero (0) value on transmission and MUST=20 >be ignored on=20 >> receipt. > >s/The/When present, the OK > > >>=20 >>>> >>>>> 481-493: I still find this text is really confusing. I think it=20 >>>>> would cleaner to separate out the fixed container and variable=20 >>>>> container field definitions (3 definitions: Unres ODUj at Prio N,=20 >>>>> Unreserved Bandwidth at priority N, and MAX LSP Bandwidth >>> at priority >>>>> N). Again happy to discuss further on list. >>>>> >>>> >>>> OLD >>>> 481 - Unreserved Bandwidth/Max LSP BW : In case of=20 >>> fixed containers >>>> 482 (Type=3D1) the Unreserved Bandwidth field MUST be=20 >>> 16 bits long and >>>> 483 indicates the Unreserved Bandwidth in=20 >number of available >>>> 484 containers. Unreserved/MAX LSP BW fields for=20 >>> each identified >>>> 485 priority MUST be included, in order of increasing=20 >>> prioritiy (0 to >>>> 486 7) and Unreserved/MAX LSP BW fields for other=20 >>> priority values MUST >>>> 487 be omitted. In case the number of supported=20 >>> priorities is odd, a >>>> 488 16 bits all zeros padding field MUST be added. =20 >>> On the other hand, >>>> 489 in case of variable containers (Type 2) the=20 >>> Unreserved/MAX LSP >>>> 490 Bandwidth fields MUST be 32 bits long and=20 >>> expressed in IEEE >>>> 491 floating point format. The advertisement of the=20 >>> MAX LSP bandwidth >>>> 492 MUST take into account HO OPUk bit rate=20 >tolerance and be >>>> 493 calculated according to the following formula: >>>> >>>> NEW >>>> - Unreserved ODUj at Prio N (16 bits): This field is used >>> only in case >>>> of fixed containers (Type=3D1). It MUST be 16 bits long and=20 >indicates=20 >>>> the Unreserved Bandwidth in number of available containers. >>>> A different field for each supported priority MUST be=20 >used. In case=20 >>>> the number of supported priorities is odd, a 16 bits all >>> zeros padding >>>> field MUST be added. >>>> >>> How about: >>> - Unreserved ODUj (16 bits): This field indicates the Unreserved=20 >>> Bandwidth at a particular priority level. This field MUST=20 >be set to=20 >>> the number of ODUs at the indicated the Signal Type for a=20 >particular=20 >>> priority level. One field MUST be present for each bit set in the=20 >>> Priority field, and is ordered to match the Priority field. Fields=20 >>> MUST not be > >s/MUST not/MUST NOT > >>> present for priority levels that are not indicated in the Priority=20 >>> field. > >>> This field is REQUIRED for Type 1 (fixed >>> container) TLVs, and MUST NOT be used for Type 2 TLVs. >>> > >Actually, these lines are redundant with the format definition and can >be dropped. > OK >>> Also: >>> Unreserved Padding (variable): The Padding field is used to=20 >ensure the >>> 32 bit alignment of Unreserved ODUj fields. The length of the=20 >>> Unreserved Padding field is always a multiple of 16 bits (2=20 >>> byte). Its length can be calculated, in bytes, as: >>> % 2=20 >>> When present, the Unreserved Padding field MUST be set to a=20 >>> zero (0) value on transmission and MUST be ignored on receipt. >>> >>=20 >> Ok, but shouldn't it be:=20 >> "Its length can be calculated, in multiple of 2 bytes, >> as: "number of priorities indicated in Priorities field" % 2." ? >>=20 >> When the number of priorities is odd, the unreserved padding=20 >field is 2 byte, when the number of priorities is even, the=20 >padding field is not there. >>=20 >How about: > >- Unreserved Padding (variable): The Padding field is used to ensure >the 32 bit alignment of Unreserved ODUj fields. When present the >Unreserved Padding field is 16 bits (2 byte) long. When the number of >priorities is odd, the unreserved Unreserved Padding field MUST be >included. When the number of priorities is even, the Unreserved Padding >MUST be omitted. > OK, but it's not variable. When present it's always 16 bits. >>=20 >>>> - Unreserved Bandwidth at priority N (32 bits): This field is used=20 >>>> only in case of variable containers (Type=3D2). It MUST be 32=20 >>> bits long=20 >>>> and indicates the Unreserved Bandwidth in bits/s in IEEE floating=20 >>>> point format. A different field for each supported=20 >priority MUST be=20 >>>> used. >>>> >>> How about: >>> Unreserved Bandwidth (32 bits): This field indicates the=20 >>> Unreserved Bandwidth at a particular priority level. This=20 >>> field MUST be set to the bandwidth, in bits/s in IEEE=20 >>> floating point format, available at the indicated the Signal=20 >>> Type for a particular priority level. One field MUST be=20 >>> present for each bit set in the Priority field, and is ordered=20 >>> to match the Priority field. Fields MUST not be present for=20 >>> priority levels that are not indicated in the Priority=20 >>> field.This field is REQUIRED for Type 2 (variable container)=20 >>> TLVs, and MUST NOT be used for Type 1 TLVs. >>> > >The Unreserved Bandwidth field remains undefined in the current text. Lost it. Now is there.=20 > >>>> - MAX LSP Bandwidth at priority N (32 bit): This field is=20 >>> used only in=20 >>>> case of variable containers (Type=3D2). It MUST be 32 bits long and=20 >>>> expressed in bits/s in IEEE floating point format. The=20 >advertisement=20 >>>> of the MAX LSP bandwidth MUST take into account HO OPUk bit rate=20 >>>> tolerance and be calculated according to the following formula: >>>> >>> How about: >>> Maximum LSP Bandwidth (32 bit): This field indicates the=20 >>> maximum bandwidth that can be allocated for a single LSP at a=20 >>> particular priority level. This field MUST be set to the=20 >>> maximum bandwidth, in bits/s in IEEE floating point format,=20 >>> available to a single LSP at the indicated the Signal Type for=20 >>> a particular priority level. One field MUST be present for=20 >>> each bit set in the Priority field, and is ordered to match=20 >>> the Priority field. Fields MUST not be present for priority=20 >>> levels that are not indicated in the Priority field. > >>> This field=20 >>> is REQUIRED for Type 2 (variable container) TLVs, and MUST NOT=20 >>> be used for Type 1 TLVs. >>> > >Actually, these lines are redundant with the format definition and can >be dropped. Yes > >>=20 >> OK >>=20 >>> >>>>>> >>>>>>> ... >>>>>>>> 6) Finally, some nits: >>>>>>>> s/[OTN-INFO], the OSPF-TE/[OTN-INFO], OSPF-TE s/list=20 >of them/list >>>>>>> s/Priority :8 bits/Priority (8 bits): >>>>>>>> s/infer/imply >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> - You have some very nice examples, but are inconsistent=20 >>> in filling=20 >>>>>>> in field values. I think all values that can possibly be=20 >>> filled in=20 >>>>>>> in the examples should be. >>>>>>> >>>>>> >>>>>> All the relevant ones have been introduces. Some non=20 >>> relevant fields=20 >>>>>> have been left with just the field name in. E.g. In an >>>>> example showing >>>>>> priorities management the T, S and TSG fields have not=20 >been filled=20 >>>>>> with 1 or 0 but just T,S and TSG have been left to make=20 >>> the reading=20 >>>>>> easier. >>>>>> >>>>> >>>>> I think this will confuse some readers. I think it would=20 >>> be better =20 >>>>> to fill in as much as possible, and if not, indicate that=20 >>> the fields=20 >>>>> are not important to the case (or can carry a specific set of=20 >>>>> values). For example why not show that reserved&padding=20 >fields are=20 >>>>> 0, that the SWCaps=3DOTN-TDM, etc. >>>> >>>> Done (only T, S ans TSG left indicated as T, S and TSG when non=20 >>>> relevant for the example) >>>> >>> >>> Will you add text to that effect to each of those examples? >>=20 >> OK >>=20 >>> >>>>> >>>>>>> Detailed editorial and technical comments: >>>>>>> >>>>> Thank you! >>>>> [...] >>>>> >>>>> >>>>>>> - Section 7 -- update to reference 4203 and 5920. Discuss=20 >>>>>>> implications / added risk of additional information >>>>> provided in this >>>>>>> document. >>>>>> Reference to 4203 added and this piece of text added at the end: >>>>>> >>>>>> For security threats, defensive techniques,=20 >>> monitoring/detection/ >>>>>> reporting of security attacks and requirements please refer to >>>>>> [RFC5920] . >>>>>> >>>>>>> >>>>>>> Section 8. This section needs some work. (I'm assuming your=20 >>>>>>> familiar with rfc5226). >>>>>> >>>>> >>>>> Hereto, we'll see what the reviewers say... >>>>> >>>>>> What about: >>>>>> >>>>>> 8. IANA Considerations >>>>>> >>>>>> Upon approval of this document, IANA will make the=20 >>> assignment of a >>>>>> new registry, the "OTN-TDM Container Registry" under=20 >a new GMPLS >>>>>> Routing Parameters" with two new types (1 and 2) >>>>>> >>>>>> >>>>>> Switching Type Description Reference >>>>>> ---------------------- -------------------------- ---------- >>>>>> 110 (suggested) OTN-TDM capable (OTN-TDM) [This.I-D] >>>>>> >>>>>> This document defines the following sub-TLVs of the ISCD TLV: >>>>>> >>>>>> Value Sub-TLV >>>>>> ----- ------------------------------------------------- >>>>>> 1 Unreserved Bandwidth for fixed containers >>>>>> 2 Unreserved/MAX LSP bandwidth for flexible containers >>>>>> >>>>>>> >>>>>>> - Switching types are assigned in >>>>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig- >>>>>>> parameters.xml#gmpls-sig-parameters-3 >>>>>>> (Again I suggest 110, not 101, but this isn't a big deal) >>>>>>> >>>>>>> - I think you are actually asking for IANA to establish a >>>>> new registry. >>>>>>> Perhaps something like "OTN-TDM Container Registry" under a new=20 >>>>>>> "GMPLS Routing Parameters" with two new types. >>>>> >>>>> Sorry, I wasn't clear in my prior mail. I didn't mean=20 >for the text=20 >>>>> to end up in the draft unmodified. Take a look at >>>>> >>>=20 >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-dcsc-channel-ext-04 >>>>> for an example of how to ask for a new Switching Type, and >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rfc4420bis-03 for an=20 >>>>> example of how to ask for a new TLV registry. >>>> >>>> >>>> Upon approval of this document, IANA will make the=20 >>> assignment in the >>>> "Switching Types" section of the "GMPLS Signaling Parameters" >>>> registry located at=20 >>> http://www.iana.org/assignments/gmpls-sig-parameters:=20 >>>> Value Type Reference >>>> --------- -------------------------- ---------- >>>> 110 (*) OTN-TDM capable (OTN-TDM) [This.I-D] >>>> >>>> (*) Suggested value >>>> This document defines a new sub-TLV for the ISCD sub-TLV. >>> How about >>> This document defines 2 new TLVs that are carried in Interface=20 >>> Switching Capability Descriptors [RFC4203] with Signal Type OTN-TDM. >>> >>>> Each >>>> TLV includes a 16-bit type identifier (the T-field). Two >>> s/Two/The same >>>> T-field values are applicable to the new sub-TLV. >> ok >>=20 >>>> >>>> IANA >>>> The IANA has created a new registry and will manage TLV type >>>> identifiers as follows: >>> How about: >>> Upon approval of this document, IANA will create and maintain=20 >>> a new registry, the "sub-TLVs of the OTN-TDM Interface=20 >>> Switching Capability Descriptor TLV" registry under the "Open=20 >>> Shortest Path First >>> (OSPF) Traffic Engineering TLVs" registry, see=20 >>> http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traf >> fic-eng-tlvs.xml, >>> with the TLV types as follows: >>> >>>> >>>> - TLV Type =3D 1 >>>> - TLV Name =3D Unreserved Bandwidth for fixed containers >>>> =20 >>>> - TLV Type =3D 2 >>>> - TLV Name =3D Unreserved Bandwidth for fixed containers >>> >>> The request Registration Procedures are Standards Action. >>> > >What case does "Whether allowed on ISCD sub-TLV" cover? The=20 >scope of the >registry is the OTN-TDM Interface Switching Capability Descriptor TLV. Removed, it didn't make much sense. > >Thanks, >Lou > > >>> Lou >>> >>>> >>>>> >>>>> Lou >>>>> >>>>>>> >>>>>>> That's it on this document. >>>>>>> >>>>>>> Lou >>>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>>>>> Behalf Of Lou Berger >>>>>>> Sent: gioved=EC 20 dicembre 2012 0.28 >>>>>>> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>>>>> Subject: Re: [CCAMP] I-D Action:=20 >>>>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>>> >>>>>>> Authors? >>>>>>> >>>>>>> On 12/4/2012 4:34 PM, Lou Berger wrote: >>>>>>>> Authors, >>>>>>>> Please review any changes and how LC comments=20 >are addressed. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Lou >>>>>>>> >>>>>>>> On 11/28/2012 2:37 AM, internet-drafts@ietf.org wrote: >>>>>>>>> >>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>> Internet-Drafts directories. >>>>>>>>> This draft is a work item of the Common Control and >>>>>>> Measurement Plane Working Group of the IETF. >>>>>>>>> >>>>>>>>> Title : Traffic Engineering Extensions to=20 >>>>>>> OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN=20 >>>>>>> Networks >>>>>>>>> Author(s) : Daniele Ceccarelli >>>>>>>>> Diego Caviglia >>>>>>>>> Fatai Zhang >>>>>>>>> Dan Li >>>>>>>>> Sergio Belotti >>>>>>>>> Pietro Vittorio Grandi >>>>>>>>> Rajan Rao >>>>>>>>> Khuzema Pithewan >>>>>>>>> John E Drake >>>>>>>>> Filename :=20 >>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>>>>> Pages : 33 >>>>>>>>> Date : 2012-11-27 >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> ITU-T Recommendation G.709 [G.709-2012] has introduced >>>>>>> new fixed and >>>>>>>>> flexible Optical Data Unit (ODU) containers,=20 >>> enabling optimized >>>>>>>>> support for an increasingly abundant service mix. >>>>>>>>> >>>>>>>>> This document describes Open Shortest Path First - Traffic >>>>>>>>> Engineering (OSPF-TE) routing protocol extensions=20 >to support >>>>>>>>> Generalized MPLS (GMPLS) control of all currently=20 >defined ODU >>>>>>>>> containers, in support of both sub-lambda and lambda >>>>>>> level routing >>>>>>>>> granularity. >>>>>>>>> >>>>>>>>> >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> >>>>>=20 >https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 >>>>>>>>> >>>>>>>>> There's also a htmlized version available at: >>>>>>>>>=20 >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-04 >>>>>>>>> >>>>>>>>> A diff from the previous version is available at: >>>>>>>>> >>>>>>> >>>>> >>>=20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-0 >>>>>>>>> 4 >>>>>>>>> >>>>>>>>> >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> CCAMP mailing list >>>>>>>>> CCAMP@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>=20 >>=20 >>=20 >= From daniele.ceccarelli@ericsson.com Fri Jan 11 07:20:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDDD21F88EF for ; Fri, 11 Jan 2013 07:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 6ZeFXDKbyQ2E for ; Fri, 11 Jan 2013 07:20:20 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D8B4B21F88CC for ; Fri, 11 Jan 2013 07:20:19 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-8a-50f02db29e8c Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2F.02.32353.2BD20F05; Fri, 11 Jan 2013 16:20:18 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.193]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 16:20:17 +0100 From: Daniele Ceccarelli To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-05.txt Thread-Index: AQHN0l52PdatEzhfmEu/vlp3CQwlUZggy0OAgACv+RCAAFa1gIAimJzw Date: Fri, 11 Jan 2013 15:20:17 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4805E67B@ESESSMB301.ericsson.se> References: <20121128073621.29401.81832.idtracker@ietfa.amsl.com> <50BE5DB0.9040507@labn.net> <50D24D55.5060003@labn.net> <4A1562797D64E44993C5CBF38CF1BE4804558C@ESESSMB301.ericsson.se> <50D329AF.1050506@labn.net> In-Reply-To: <50D329AF.1050506@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje4m3Q8BBh/mGlo8mXODxWLK7O8s Fh3Nb1kcmD2WLPnJ5PFhUzObx5fLn9kCmKO4bFJSczLLUov07RK4Mq4c5Co461kxZ8UM9gbG busuRk4OCQETiVuPFjBD2GISF+6tZ+ti5OIQEjjEKPFhdwsLhLOEUeLb5YtAVRwcbAJWEk8O +YA0iAgoSnz9uIgJpIZZYBqjxN09p9hBEsICPhJ9T46xQxT5ShxeuZcRwnaTOD13GlicRUBV 4vn0/WwgM3kFvCVezE4ECQsJ3GaUuP8kHsTmFNCQ6Pg4lw3EZhSQlZiwexHYGGYBcYlbT+Yz QRwtILFkz3moB0QlXj7+xwphK0p8fLUPql5P4sbUKWwQtrbEsoWvwep5BQQlTs58wjKBUWwW krGzkLTMQtIyC0nLAkaWVYzsuYmZOenl5psYgVFzcMtvgx2Mm+6LHWKU5mBREucNd70QICSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoGx4Ft9tLrCtkcHwt5d/2b8sufSc8mv2ZPzt6koKj7V 1zliu4qT/VfgDJNO4xn1P8LYVPco5y1OcjWa6M3wozXZ53Sq6mct5zM+PYfzhN727J/wtev3 2vjKT2svVk3we+/+ef3iiQncPOWP7XN8+zTmvrXkWTvZZbnSbJ2Jtxnn5M/Zy3NE+8cNJZbi jERDLeai4kQA3x1OA2gCAAA= Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:20:22 -0000 Hi Lou, Please see in line. Please also note that the references to G.798 amd2 and G.872 amd2 were chan= ged into G.798 new revision and G.872 new revision.=20 The first one is pre-published on the ITU-T ties web page and will be offic= ially published on January 16th, while G.872 was published in October. Both= of them are actually available for ties users only.=20 These are the documents that should be requested to be publicly available (= no clue on when they will be available and if it is worth waiting for them = or a liaison might be more useful).=20 BR Daniele & Sergio >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net]=20 >Sent: gioved=EC 20 dicembre 2012 16.07 >To: Daniele Ceccarelli >Cc: ccamp@ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >Subject: Re: [CCAMP] I-D Action:=20 >draft-ietf-ccamp-otn-g709-info-model-05.txt > >Daniele / Authors, > Thank you for the response. Please see below for my responses. > > > >On 12/20/2012 4:05 AM, Daniele Ceccarelli wrote: >> Hi Lou, >>=20 >> Below you can find the last call comments pasted with=20 >replies in line. >>=20 >> All nits, typos and suggested text changes without any=20 >comment in line have been accepted/modified accordingly. >>=20 >> BR >> Daniele & Sergio >>=20 >>=20 >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>> Behalf Of Lou Berger >>> Sent: sabato 20 ottobre 2012 0.06 >>> To: CCAMP; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>> Subject: [CCAMP] WG Last Call comments on >>> draft-ietf-ccamp-otn-g709-info-model-04 >>> >>> >>> Authors, >>> I have the following LC comments: >>> >>> General comments: >>> >>> - There's a lot of text/concepts that is common to both=20 >this document=20 >>> and the framework document. The document certainly adds additional=20 >>> useful detail, but I'm not sure it's really provides an information=20 >>> model of any kind. Optimally, I think this document should=20 >be merged=20 >>> with the framework document. I think this would yield a more=20 >>> comprehensive and understandable result. I really don't=20 >see this as=20 >>> a lot of work/time, although it clearly would be a major change >>> >>> If this is considered to be to onerous a proposal, then=20 >this document=20 >>> should at least be updated to (a) reduce duplication text with the=20 >>> framework document and (b) remove any references to "model"=20 >and just=20 >>> talk about providing "Additional Information" >>=20 >> All duplicated text have been removed from this ID and kept=20 >into the FWK (mostly End of section 1, whole sections 2 and 3). >>=20 > >okay. > >> Title changed into: >> Evaluation of existing GMPLS encoding against G.709v3 Optical=20 >> Transport Networks (OTN) >>=20 >> And abstract into: >> [...] >> This document provides an evaluation of existing Generalized >> Multiprotocol Label Switching (GMPLS) routing and=20 >signaling methods >> against the G.709-2012 OTN networks. >>=20 > >okay. > >>> >>> - The document should be reviewed by the authors to ensure it is=20 >>> consistent with the latest solutions documents and WG discussions. =20 >>> For example, there are multiple references to the contentious and=20 >>> much discussed "penultimate hop" case without any references to the=20 >>> agreed upon approach. >>=20 >> Done. Please see section 3.2 >>=20 > >There still a number of instances where penultimate hop=20 >section of interface is mentioned. As we discussed on the=20 >list, this issue actually exists for any node that is=20 >selecting the egress' nodes incoming interface. This can be=20 >at the ingress (in setting an ERO), a transit node (doing ERO=20 >expansion), or the penultimate hop. So there are some=20 >additional fixes needed. > OK. When penultimate node is mentioned the text is changed so to say that i= t's also an issue=20 of any intermediate node performing ERO expansions. It should not be an ing= ress Node issue as the ingress is aware of the hierarchty. >>> >>> Editorial comments: >>> >>> - Please verify that abbreviations are defined before being used . >>> There are a number of these. >>=20 >> Done >>> >>> - Please use a consistent decimal representation (sometimes commas=20 >>> are used other times periods) > >There are instances where this is still an issue, e.g., search=20 >for 1,25. > ok >>> >>> - the references [G709-v1] and [G709-v3] each actually refer to=20 >>> multiple documents, each documented needs to have it's own >>> (correct) reference, i.g., [G709-v1] and [G709-v1a1]. The document=20 >>> text will need to be revisited to ensure the proper reference is=20 >>> made. >>=20 >> RFC4328 for older versions of G709 and G709-2012 for the latest one=20 >> (v4) >>=20 > >great. > >>> >>> - >>> http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft >> -ietf-ccamp-otn-g709-info-model-04.txt >>> shows there are unresolved nits that need to resolved . I'm using=20 >>> line numbers from this url in my subsequent comments. >>> >>> Line 18: Suggest dropping "The recent revision of" >>> > >This chance was not made, was this intentional? (and this=20 >terminology continues to be used.) -- Yes this is a style=20 >comment -- so ignore as you see fit. Just missed it. It was removed and just reference to 709-2012 left. > >>> Line 20/21: Suggest dropping the marketing phrase "enabling=20 >optimized=20 >>> support for an increasingly abundant service mix." >>> > >This chance was not made, was this intentional? I think form=20 >of "marketing" doesn't belong in an PS -- just MO. removed > >>> Lines 93-127 (through "of"): I don't see how this text provides any=20 >>> value. I suggest dropping it, or at most just reference the FWK=20 >>> document. > >No real change here. This text remains. Why are LSA types=20 >mentioned here at all? They aren't mentioned in the body of=20 >the document so should be removed. Agree. Removed. > >>> >>> Lines 319-341: Instances of "G.709" should be "[G.709-V3]" >>> > >still missing '[]' > >[...] > Last chages turned G.709 into G.709-2012.=20 >Thanks I think that's it. >Lou > > >>=20 >>> >>> That's it on this document. >>> >>> Lou >>=20 >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>> Behalf Of Lou Berger >>> Sent: gioved=EC 20 dicembre 2012 0.27 >>> To: ccamp@ietf.org;=20 >>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>> Subject: Re: [CCAMP] I-D Action:=20 >>> draft-ietf-ccamp-otn-g709-info-model-05.txt >>> >>> Authors? >>> >>> On 12/4/2012 3:31 PM, Lou Berger wrote: >>>> Authors, >>>> Please review any changes and how LC comments are addressed. >>>> >>>> Thank you, >>>> Lou >>>> >>>> On 11/28/2012 2:36 AM, internet-drafts@ietf.org wrote: >>>>> >>>>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. >>>>> This draft is a work item of the Common Control and >>> Measurement Plane Working Group of the IETF. >>>>> >>>>> Title : Evaluation of existing GMPLS encoding=20 >>> against G.709v3 Optical Transport Networks (OTN) >>>>> Author(s) : Sergio Belotti >>>>> Pietro Vittorio Grandi >>>>> Daniele Ceccarelli >>>>> Diego Caviglia >>>>> Fatai Zhang >>>>> Dan Li >>>>> Filename : draft-ietf-ccamp-otn-g709-info-model-05.txt >>>>> Pages : 22 >>>>> Date : 2012-11-27 >>>>> >>>>> Abstract: >>>>> The recent revision of ITU-T recommendation G.709 >>> [G.709-2012] has >>>>> introduced new fixed and flexible Optical Data Unit >>> (ODU) containers >>>>> in Optical Transport Networks (OTNs), enabling optimized >>> support for >>>>> an increasingly abundant service mix. >>>>> >>>>> This document provides an evaluation of existing Generalized >>>>> Multiprotocol Label Switching (GMPLS) routing and >>> signaling methods >>>>> against the G.709-2012 OTN networks. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> >>>=20 >https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-05 >>>>> >>>>> A diff from the previous version is available at: >>>>> >>>=20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-otn-g709-info-model >>>>> -05 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>=20 >>=20 >>=20 >= From internet-drafts@ietf.org Fri Jan 11 07:32:17 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F6621F84FD; Fri, 11 Jan 2013 07:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 KALhNs9UBAEE; Fri, 11 Jan 2013 07:32:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FBD21F8462; Fri, 11 Jan 2013 07:32:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130111153211.3507.99663.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 07:32:11 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:32:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Evaluation of existing GMPLS encoding against G.709v3 Op= tical Transport Networks (OTN) Author(s) : Sergio Belotti Pietro Vittorio Grandi Daniele Ceccarelli Diego Caviglia Fatai Zhang Dan Li Filename : draft-ietf-ccamp-otn-g709-info-model-06.txt Pages : 22 Date : 2013-01-11 Abstract: ITU-T recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling methods against the G.709 [G.709-2012] OTN networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-otn-g709-info-model-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=8723a90b54=sshew@ciena.com Fri Jan 11 10:20:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3209621F8918 for ; Fri, 11 Jan 2013 10:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 55DEC84A8niL for ; Fri, 11 Jan 2013 10:20:03 -0800 (PST) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1E57B21F84BB for ; Fri, 11 Jan 2013 10:20:01 -0800 (PST) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id r0BIDbwI013954; Fri, 11 Jan 2013 13:20:01 -0500 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 19tqbxr3my-11 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 11 Jan 2013 13:20:00 -0500 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 11 Jan 2013 13:19:51 -0500 Received: from ONWVEXCHMB02.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Fri, 11 Jan 2013 13:19:50 -0500 From: "Shew, Stephen" To: Lou Berger , CCAMP Date: Fri, 11 Jan 2013 13:19:49 -0500 Thread-Topic: [CCAMP] Recommendation G.798 (2010) Amendment 2 (04/12) Thread-Index: Ac3ujRiTyezwDtSaRReDPXs2yDPqiQBmn0HA Message-ID: <510C3D5C5DFBCB46AE189D936C1DD605A6F4853EBF@ONWVEXCHMB02.ciena.com> References: <50EDA5E3.80106@labn.net> In-Reply-To: <50EDA5E3.80106@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19548.000 x-tm-as-result: No--34.542900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-11_07:2013-01-11, 2013-01-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1211240000 definitions=main-1301110170 Subject: Re: [CCAMP] Recommendation G.798 (2010) Amendment 2 (04/12) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 18:20:06 -0000 I contacted the ITU-T editing staff (similar to the RFC editor) and they in= dicated that unless there are any editorial issues which require resolution= by the G.709 editor, the amendment should be published by the end of this = month (January). So, it shouldn't be long. Stephen -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: 09 January, 2013 12:16 To: CCAMP Subject: [CCAMP] Recommendation G.798 (2010) Amendment 2 (04/12) Hello, Does anyone know when this document is going to be publicly available? Unless I missed it, I don't think IETF participants have open access to thi= s document and it is being referenced in the g.709 drafts. Thanks, Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Fri Jan 11 12:01:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1582121F8B2E for ; Fri, 11 Jan 2013 12:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, 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 9o-xNbF1kD68 for ; Fri, 11 Jan 2013 12:01:39 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id C10A821F8B0E for ; Fri, 11 Jan 2013 12:01:38 -0800 (PST) Received: (qmail 10842 invoked by uid 0); 11 Jan 2013 20:01:14 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 11 Jan 2013 20:01:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=pqzQddy+1GNPWHKVJInE/0S+cq0sUxzLzmcXeQP9/VE=; b=DxBrJy91k5VpWcDMkCXrNeFvR77TxgmFlMzEoRGANq1Vy5xoi0VoIsM00kSZ0kz+jFggVj3cLlXIAawV8TE0iU455Nr4hsrBvq+wlywD9zyiLAPocN15FT6oTtXtOswp; Received: from box313.bluehost.com ([69.89.31.113]:40133 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ttkmw-0006yq-Bt; Fri, 11 Jan 2013 13:01:14 -0700 Message-ID: <50F06F91.7040507@labn.net> Date: Fri, 11 Jan 2013 15:01:21 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Shew, Stephen" References: <50EDA5E3.80106@labn.net> <510C3D5C5DFBCB46AE189D936C1DD605A6F4853EBF@ONWVEXCHMB02.ciena.com> In-Reply-To: <510C3D5C5DFBCB46AE189D936C1DD605A6F4853EBF@ONWVEXCHMB02.ciena.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Recommendation G.798 (2010) Amendment 2 (04/12) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:01:40 -0000 Stephen, That's great. Thank you. Authors, Keep in mind, when referencing new specifications from other bodies, once the referenced spec is approved we can always request that pre publication versions be sent via a liaison. Clearly we don't need one in this case given publication timing. Lou On 1/11/2013 1:19 PM, Shew, Stephen wrote: > I contacted the ITU-T editing staff (similar to the RFC editor) and > they indicated that unless there are any editorial issues which > require resolution by the G.709 editor, the amendment should be > published by the end of this month (January). So, it shouldn't be > long. > > Stephen > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 09 January, 2013 12:16 > To: CCAMP > Subject: [CCAMP] Recommendation G.798 (2010) Amendment 2 (04/12) > > Hello, > > Does anyone know when this document is going to be publicly available? > Unless I missed it, I don't think IETF participants have open access to this document and it is being referenced in the g.709 drafts. > > Thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Fri Jan 11 12:29:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A751421F8786 for ; Fri, 11 Jan 2013 12:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.613 X-Spam-Level: X-Spam-Status: No, score=-101.613 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, J_CHICKENPOX_51=0.6, 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 E7WNEXDsyb-K for ; Fri, 11 Jan 2013 12:29:17 -0800 (PST) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 0908721F86AA for ; Fri, 11 Jan 2013 12:29:15 -0800 (PST) Received: (qmail 20016 invoked by uid 0); 11 Jan 2013 20:28:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 11 Jan 2013 20:28:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=PNuAz78mdsABATT52MDZ+Fbbu7tLgOy9LWyr0SyL4Dk=; b=hJFULEvTuBe69hoTASG3Qu/mjTI4yJOlJf8uRLOkxmMgT6n8KdQCa9SXO0oveUxFViTFjfcojdLBce7l10KH+b6ldUONVG4emiBcBC+fx6f+Hifk/9abVxxBuRe43pJc; Received: from box313.bluehost.com ([69.89.31.113]:43425 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TtlDa-00011F-86; Fri, 11 Jan 2013 13:28:46 -0700 Message-ID: <50F07604.5080705@labn.net> Date: Fri, 11 Jan 2013 15:28:52 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Daniele Ceccarelli References: <20121128073754.7548.6383.idtracker@ietfa.amsl.com> <50BE6C54.7060606@labn.net> <50D24D68.5040005@labn.net> <4A1562797D64E44993C5CBF38CF1BE4804556A@ESESSMB301.ericsson.se> <50D39F51.8010802@labn.net> <4A1562797D64E44993C5CBF38CF1BE48046263@ESESSMB301.ericsson.se> <50D4AB0E.6070207@labn.net> <4A1562797D64E44993C5CBF38CF1BE4805D2BB@ESESSMB301.ericsson.se> <50EDB5E1.5040200@labn.net> <4A1562797D64E44993C5CBF38CF1BE4805E624@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4805E624@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:29:19 -0000 Daniele, I think the following is the sole open point! Some minor changes: > How about: > > NEW > With respect to ODUflex, three different signal types are allowed: 20 > - ODUflex Constant Bit Rate (CBR), 21 - ODUflex Generig Framing s/Generig/Generic > Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non > resizable. They MUST always be advertised in separate Type 2 TLVs as s/They/Each > they use different adaptation functions [G.805]. In case both GFP-F s/they/each s/In case/In the case that > resizable and non resizable (i.e. 21 and 22) are supported, only > Signal Type 21 MUST be advertised s/MUST/SHALL >as resizable ODUflex implies non resizable one. How about replace line with with: "as, per [G.709], this type also implies support for type 22 adaptation." (please confirm the reference). >Signal Type 22 MUST be used when only non resizable > ODUflex is supported. > Much thanks, Lou On 1/11/2013 9:18 AM, Daniele Ceccarelli wrote: > Hi Lou, > > Please see below. > > BR > Daniele & Sergio > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: mercoled 9 gennaio 2013 19.25 >> To: Daniele Ceccarelli >> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >> Subject: Re: [CCAMP] I-D Action: >> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >> >> Daniele, >> >> see below. >> >> >> On 1/8/2013 12:39 PM, Daniele Ceccarelli wrote: >>> Hi Lou, >>> >>> Please find further comments in line. >>> >>> Since the changes from v04 start to be quite a lot we >> published v05. Please provide further comments (if any) with respect to >> that version. >>> >> >> Okay. Note that you have a nit to clean up the next time you update: >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft > -ietf-ccamp-gmpls-ospf-g709v3-05.txt >> > > fixed > >> >>> BR >>> Daniele & Sergio >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: venerd 21 dicembre 2012 19.32 >>>> To: Daniele Ceccarelli >>>> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>> >>>> Daniele, >>>> Much thanks -- I do expect that the thread might extend >> beyond the >>>> end of year holiday, and that many/most are off next week... >>>> >>>> See below for responses. >>>> >>>> On 12/21/2012 10:49 AM, Daniele Ceccarelli wrote: >>>>> Hi Lou, >>>>> >>>>> Please see in line. >>>>> >>>>> We'll upload -05 when all the issues will be solved. >>>>> >>>>> BR >>>>> Daniele & Sergio >>>>> >>>>> PS. The info model after christmas holidays >>>>> >>>>>> -----Original Message----- >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>> Sent: venerd 21 dicembre 2012 0.29 >>>>>> To: Daniele Ceccarelli >>>>>> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>>>> Subject: Re: [CCAMP] I-D Action: >>>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>> >>>>>> Daniele / Authors, >>>>>> Thank you for the response. Please see below for my responses. >>>>>> >>>>>> >>>>>> On 12/20/2012 3:57 AM, Daniele Ceccarelli wrote: >>>>>>> Hi Lou, >>>>>>> >>>>>>> Below you can find the last call comments pasted with >>>>>> replies in line. >>>>>>> >>>>>>> All nits, typos and suggested text changes without any >>>>>> comment in line >>>>>>> have been accepted/modified accordingly. >>>>>>> >>>>>> >>>>>>> BR >>>>>>> Daniele & Sergio >>>>>>> >>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>>>>>> On Behalf >>>>>>>> Of Lou Berger >>>>>>>>> Sent: mercoled 26 ottobre 2011 0.37 >>>>>>>>> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org >>>>>>>>> Cc: CCAMP >>>>>>>>> Subject: [CCAMP] some comments on gmpls-ospf-g709v3-00 >>>>>>>> ... >>>>>>>>> 2) SCSI TLV formatting >>>>>>>>> >>>>>>>>> The field descriptions are missing format related conformance >>>>>>>>> (RFC2119) language. >>>>>>>>> >>>>>>> >>>>>>> Done >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Some points: >>>>>> (Using line numbers from >>>>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft >>>>> -ietf-ccamp-gmpls-ospf-g709v3-04.txt) >>>>>> >>>>>> I like your solution for the general TLV format definition. >>>>>> >>>>>> Lines 303/304: "Different sub-TLV MAY be presented in >>>> ascending Type >>>>>> order." >>>>>> >>>>>> I suspect you mean s/Different sub-TLV/Multiple sub-TLVs >>>>>> >>>>> >>>>> See below >>>>> >>>>>> By "ascending Type order", are you refering to the TLV type? >>>>>> Are multiple TLVs of the same type allowed? If not, how >> are errors >>>>>> handled? >>>>> >>>>> Yes and yes. Multiple TLVs of the same type are often >>>> present as each of them represents a branch of the muxing tree. >>>>> What about changing into: >>>>> >>>>> Sub-TLV SHOULD be presented >>>>> in ascending Type order (i.e. type 1 before and type 2 after). >>>> >>>> Is there any technical reason for such ordering? It doesn't seem to >>>> add any value to me. >>> >>> Ok. It was meant to be just a guideline but indeed doesn't add any >>> value. Sentence removed. >>> >>>> >>>> I actually was expecting you to say something referring back to >>>> signal type or number of stages represented in the TLV... >>> >>> WRT signal type each TLV is self-consistent, in the sense >> that there is no need to have them in a given order. In all the example >> we have ordered them form the root to the leaves of the tree so to make >> it more "human-readable". We could suggest to follow that orded but >> like in the case of type 1 and type2 is does not add any value (except >> being more easily read). >>> >>> WRT to number of stage the order is important. Actually the >> text says that they MUST be put is ascending order and an example >> (ODU1->ODU2->ODU3) is provided: >>> >>> OLD >>> - Stage#1 ... Stage#N : These fields are 8 bits long. >> Their number is variable and a field is present for >>> each of the indicated number of stages. The last one >> MUST always indicate the server ODU container (ODUk/OTUk) >>> and they MUST be listed in ascending order from the >> smallest to the biggest one. >>> The values of the Stage fields MUST be the same ones >> defined for the Signal Type field. If >>> the number of stages is 0, then the Stage and Padding >> fields MUST be omitted. >>> >>> Example: in case the ODU1->ODU2->OD3 hierarchy, the >> Signal Type field is set to ODU1 and >>> two Stage fields are present, the first indicating >> ODU2 and the second ODU3 (server layer). >>> >>> We added: "from the smallest to the biggest one." at the end >> of the first sentence: >>> >>> NEW: >>> [CUT] >>> The last one MUST always indicate the server ODU >> container (ODUk/OTUk) >>> and they MUST be listed in ascending order from the >> smallest to the biggest one. >>> [CUT] >>> >>>> >>>>> >>>>>> >>>>>> Lines 306-322: >>>>>> >>>>>> Given that Figures 4 and 5 completely repeat the information in >>>>>> Figure 4, I propose that you drop Figure 4. (and align the >>>> preceding >>>>>> paragraph to match.) >>>>> >>>>> Figure 4 and 5 represent TLV type1 and TLV type2 >>>> respectively, which are quite different from each other. >> The first 3 >>>> rows are identical but the rest of the TLV is pretty different. We >>>> would prefer to keep both of them. >>>>> >>>> >>>> Ahh. Sorry, let me try again: >>>> >>>> Given that Figures 4 and 5 completely repeat the information in >>>> Figure *4*, I propose that you drop Figure *3*. (and align the >>>> preceding paragraph to match.) >>> >>> Done >>> >>> OLD >>> The format of the SCSI MUST be as depicted in the >> following figure, where >>> one Type 1 sub-TLV MUST be used for any fixed container >> and one Type 2 sub-TLV >>> MUST be used for any variable container. >>> NEW >>> The SCSI MUST include one Type 1 sub-TLV for any fixed >> container and one Type 2 sub-TLV >>> for any variable container. >>> >> >> I think this new/revised text is ambiguous: >> >> You say "one ... for any" (twice). Is this one for each, or one for all >> (containers)? > > Yes...One for each...corrected. > >> >> The flow into the next paragraph is a bit hard to follow. >> > How about: > > NEW > With respect to ODUflex, three different signal types are allowed: > 20 - ODUflex Constant Bit Rate (CBR), 21 - ODUflex Generig Framing > Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) > non resizable. They MUST always be > advertised in separate Type 2 TLVs as they use different adaptation > functions [G.805]. In case both GFP-F resizable and non > resizable (i.e. 21 and 22) are supported, only Signal Type 21 MUST be > advertised as resizable ODUflex implies non resizable one. > Signal Type 22 MUST be used when only non resizable ODUflex > is supported. > > >>>> >>>> Also, just realized that figures 4 and 5 really should >> indicate that >>>> priorities are not always included. And that a second >> padding field >>>> may be needed too! How about: >>>> >>>> >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Type = 1 (Unres-fix) | Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Signal Type | Num of Stages |T|S| TSG | Res | Priority | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Stage#1 | ... | Stage#N | Padding | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Unreserved ODUj at Prio 0 | ..... | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Unreserved ODUj at Prio 7 | Unreserved Padding | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> Figure 4: Bandwidth TLV - Type 1 - >>> >>> OK. Wrote padding instead of unreserved Padding >>> >>>> >>>> >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Type = 2 (Unres/MAX-var) | Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Signal Type | Num of Stages |T|S| TSG | Res | Priority | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Stage#1 | ... | Stage#N | Padding | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Unreserved Bandwidth at priority 0 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | ... | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Unreserved Bandwidth at priority 7 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Maximum LSP Bandwidth at priority 0 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | ... | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Maximum LSP Bandwidth at priority 7 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> Figure 5: Bandwidth TLV - Type 2 - >>>> >>>> (Note some field names have been expanded to match descriptions) >>> >>> OK >>> >>>> >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> 3) SCSI TLV procedures >>>>>>>>> >>>>>>>>> You have defined the formats of the TLVs in Section >> 4.1, but not >>>>>>>>> explicitly how they are to be used. Some RFC2119 language >>>>>> really is >>>>>>>>> needed to cover how the SCSI is to be encoded and parsed. At a >>>>>>>>> minimum, any TLV inclusion, ordering requirements, and >> exception >>>>>>>>> handling should be covered. (For example, your examples >>>>>>>> always show a >>>>>>>>> particular ordering relative to Stage#, is this required, >>>>>>>> recommended, >>>>>>>>> or just a possibility. You have some informative language, >>>>>> which is >>>>>>>>> great, but you also need some RFC2119 language.) >>>>>>> >>>>>>> Done >>>>>> >>>>>> The length of each TLV type and each field should be defined. >>>>>> (You have it for some fields, but not others). >>>>> >>>>> Now all of them should have been filled. >>>>> >>>> >>>> great. >>>> >>>>>> >>>>>> 414 With respect to ODUflex, ODUflex Constant Bit Rate (CBR) and >>>>>> 415 ODUflex Generig Framing Procedure-Frame mapped (GFP-F) MUST >>>>>> 416 always be advertised separately as they use different >>>>>> 417 adaptation functions. In the case both GFP-F resizable and >>>>>> non >>>>>> 418 resizable (i.e. 21 and 22) are supported, Signal Type 21 >>>>>> 419 implicitely supports also signal Signal Type 22, so >>>> only Signal >>>>>> 420 Type 21 MUST be advertised. Signal Type 22 MUST be used only >>>>>> 421 for non resizable resources. >>>>>> >>>>>> Shouldn't this text be moved to after line 304? >>>>> >>>>> Agree. Done. >>>> >>>> great. >>>> >>>>> >>>>>> >>>>>> Line 416: By separately do you mean "in separate TLVs"? >>>>> >>>>> Yes.changed >>>> >>>> great. >>>> >>>>>> >>>>>> Lines 416/7: Your reference to "different adaptation >>>> functions" lacks >>>>>> context as it is the sole reference in the document to >> "adaptation >>>>>> functions". I think you need to either define this >>>> terminology (via >>>>>> reference is fine) or replace it some other terminology. >>>>>> >>>>> >>>>> Reference to [G.805] added >>>> >>>> okay. Given the signal type definitions are in [OTN-SIG], what >>>> additional information is added by this paragraph? What am >> I missing? >>> >>> Things are quite different between signaling and routing >> when it comes to "implication". In the case of signaling you either >> signal type 21 o 22, while in the case of routing if both of them are >> supported there is no need to advertise both of them and just signal >> type 21 is enough because it implies also signal type 22 support. >>> >>>> >>>>> >>>>>> Line 419/whole document: Please double check the document for >>>>>> spelling errors (there's one in the above paragraph.) >> >> you still have some errors... > > No more errors seems to be there according to the spell check, if there are any left please indicate them explicitely. > >> >>>>>> >>>>>> Line 423: >>>>>> >>>>>> By "number of multiplexing stages level below the >> indicated signal >>>>>> type", do you mean "number of multiplexing stages represented as >>>>>> transporting the indicated signal type"? >>>>>> >>>>>> Lines 424-426. It's best not to define semantics through >> example. >>>>>> How about replacing 423-426 with: >>>>>> >>>>>> - Number of stages (8 bits): This field indicates the number of >>>>>> multiplexing stages used to transport the indicated >> signal type. It >>>>>> MUST be set to the number of stages represented in the TLV. >>>>>> >>>>> OK >>>>> >>>>>> >>>>>> Line 428: s/Flags:/Flags (8 bits) >>>>> >>>>> ok >>>>>> >>>>>> Lines 455-462: should be revised to use 2119 conformance language >>>>>> (and to clarify the malformed text.) >>>>> >>>>> OK >> >> OLD >> >> 409 Value 1 MUST be used on those interfaces where the fallback 410 >> procedure is enabled and the default value of >> 1.25 Gbps can be >> 411 falled back to 2.5 if needed. Value 2 MUST be used on [RFC4328] >> 412 interfaces while value 3 MUST be used on [G.709-2012] interfaces >> 413 where the fallback procedure is unsupported/disabled. Value 0 >> 414 MUST be used for non multiplexed signal (i.e. non OTN client). >> >> How about: >> A value of 1 MUST be used on interfaces which are configured to support >> the fall back procedures defined in [G.798-a2]. A value of 2 MUST be >> used on interfaces that only support 2.5 Gbps time slots, such as >> [RFC4328] interfaces. A value of 3 MUST be used on interfaces that are >> configured to only support >> 1.25 Gbps time slots. A value or 3 MUST be used for non multiplexed >> signal types (i.e. a non OTN client). >> > > OK but in the last sentence it's value 0, not 3. > >>>>> >>>>>> >>>>>> The "RES" field isn't defined. >>>>> >>>>> - Res (3 bits): reserved bits. MUST be set to 0. >>>> >>>> "and ignored on receipt." >>> >>> Ok >>> >>>> >>>>> >>>>>> >>>>>> 464-479: I know what you mean, but I think the text really isn't >>>>>> clear and should be revised. Suggest you just rewrite >> rather then >>>>>> tweak (as we tried in this rev.) I'm happy to discuss on >>>> list if that >>>>>> will help. >>>>>> >>>>> >>>>> OLD >>>>> 464 - Priority (8 bits): field with 1 flag for each >>>> priority. Each >>>>> 465 bit MUST be set when the related priority is >>>> supported and MUST be >>>>> 466 cleared when the related priority is not >>>> supported. The priority >>>>> 467 0 is related to the most significant bit. When >>>> no priority is >>>>> 468 supported, priority 0 MUST be advertised. >>>>> >>>>> 470 - Stage#1 ... Stage#N : These fields are 8 bits >>>> long. Their >>>>> 471 number is variable and a field is present >> for each of the >>>>> 472 indicated number of stages. The last one MUST >>>> always indicate the >>>>> 473 server ODU container (ODUk/OTUk) and they MUST be >>>> listed in >>>>> 474 ascending order. The values of the Stage fields >>>> MUST be the same >>>>> 475 ones defined for the Signal Type field. If the >>>> number of stages >>>>> 476 is 0, then the Stage and Padding fields >> MUST be omitted. >>>>> >>>>> 478 - Padding: Given that the number of Stages is >>>> variable, padding to >>>>> 479 32 bits field MUST be used when needed. >>>>> >>>>> NEW >>>>> >>>>> - Priority (8 bits): bitmap used to state which priorities >> are being >>>> s/state/indicate >>>>> advertised. The left most bit represent priority 0 >> (highest) and the >>>>> right most priority 7 (lowest) And are presented in >> ascending orded. >>>> s/) A/), a >>>> s/orded/ordered >>>> >>>>> Each bit MUST be set when the related priority is >> supported and MUST >>>> "A bit MUST be set (1) for each corresponding priority >> represented in >>>> the TLV and MUST" >>>> >>>>> be cleared when the related priority is not supported. >>>> s/be cleared/NOT be set (0) >>>> s/supported/represented. >>>> >>>>> When the >>>>> interface does not support priorities, the advertisement MUST be >>>>> compliant with the advertisement of priority 0. >>>>> >>>> Replace with >>>> "At least one priority level MUST be advertised. A value >> of zero (0) >>>> MUST be used when not overridden by local policy." >>> >>> NEW >>> - Priority (8 bits): field with 1 flag for each >> priority. A bit MUST be set (1) for each corresponding priority >>> represented in the TLV and MUST NOT be set (0) when >> the related priority is not represented. >>> At least one priority level MUST be advertised. A >> value of zero (0) MUST be used when not >>> overridden by local policy. >> >> How about: >> - Priority (8 bits): a bitmap used to indicate which >> priorities are being advertised. The bitmap is in ascending >> order, with the leftmost bit representing priority level 0 >> (i.e., the highest) and the rightmost bit representing >> priority level 7 (i.e., the lowest). A bit MUST be set (1) >> corresponding to each priority represented in the TLV, and >> MUST NOT be set (0) when the corresponding priority is not >> represented. At least one priority level MUST be advertised >> that, unless overridden by local policy, SHALL be at priority level 0. >> > > OK > >>>> >>>>> - Stage#1 ... Stage#N : Each field is 8 bits long. One >>>> field MUST be >>>>> used in ascending order (from the lowest order ODU to the highest >>>>> order ODU) for each stage of the muxing branch being >> advertised. The >>>>> last one MUST always indicate the server ODU container (ODUk/OTUk). >>>>> The values of the Stage fields MUST be the same ones >> defined for the >>>>> Signal Type field. If the number of stages is 0, the Stage >>>> field MUST >>>>> NOT be included. >>>>> >>>> How about: >>>> Stage (8 bits): Each Stage field indicates the signal type used in >>>> the to transport the signal indicated in the Signal Type field. The >>>> number of Stage fields included in a TLV MUST equal the >> value of the >>>> Number of Stages field. The Stage fields MUST be ordered to match >>>> the data plane in ascending order (from the lowest order ODU to the >>>> highest order ODU). >>> >>> Saying that each stage field indicates the signal type used to >>> transport the signal indicated in the signal type field is >> not correct >>> because e.g. In the case of ODU1->ODU2->ODU3 it is not >> correct to say >>> that ODU2 and ODU3 are used to transport the ODU1 because the ODU2 >>> tranports the ODU1 and the ODU3 tranports the ODU3. >>> How about: >>> >>> - Stage (8 bits): Each Stage field indicates the signal type >>> beloning to the muxing branch used to transport the signal indicated >>> in the Signal Type field. The number of Stage fields >> included in a TLV >>> MUST equal the value of the Number of Stages field. The >> Stage fields >>> MUST be ordered to match the data plane in ascending order (from the >>> lowest order ODU to the highest order ODU). The values of the Stage >>> fields MUST be the same ones defined for the Signal Type >> field. If the >>> number of stages is 0, then the Stage and Padding fields MUST be >>> omitted. >>> >> >> How about: >> Stage (8 bits): Each Stage field indicates a signal type in >> the multiplexing hierarchy used to transport the signal >> indicated in the Signal Type field. The number of Stage fields >> included in a TLV MUST equal the value of the Number of Stages >> field. The Stage fields MUST be ordered to match the data >> plane in ascending order (from the lowest order ODU to the >> highest order ODU). The values of the Stage field are the same >> as those defined for the Signal Type field. When the Number of >> stage field carries a 0, then the Stage and Padding fields >> MUST be omitted. >> > > OK > >>>> >>>> >>>>> - Padding: Padding bytes MUST be inserted so that the >>>>> subsequent field starts at a 4-byte aligned >> boundary. It is >>>>> important to note that the Length field includes >> the padding >>>>> bytes. Padding SHOULD be using zeros. >>>>> >>>> How about: >>>> Padding (variable): The Padding field is used to ensure the 32 bit >>>> alignment of stage fields. The length of the Padding field >> is always >>>> a multiple of 8 bits (1 byte). Its length can be calculated, in >>>> bytes, as: >>>> % 4 When present, >> the Padding >>>> field MUST be set to a zero (0) value on transmission and MUST be >>>> ignored on receipt. >>>> >>> >>> In case of number of stages == 3, "> Stages field> % 4" is 3, correct? While the padding bytes is 1. >>> Wouldn't "4-" be more correct? >> >> Woops. 4-( % 4), right? > > OK > > >> >> >>> >>> How about: >>> - Padding (variable): The Padding field is used to >> ensure the 32 bit alignment of stage fields. >>> The length of the Padding field is always a multiple >> of 8 bits (1 byte). Its length can be >>> calculated, in bytes, as: 4- "value of Number of >> Stages field". >> see above. >>> The Padding field MUST >>> be set to a zero (0) value on transmission and MUST >> be ignored on >>> receipt. >> >> s/The/When present, the > > OK > >> >> >>> >>>>> >>>>>> 481-493: I still find this text is really confusing. I think it >>>>>> would cleaner to separate out the fixed container and variable >>>>>> container field definitions (3 definitions: Unres ODUj at Prio N, >>>>>> Unreserved Bandwidth at priority N, and MAX LSP Bandwidth >>>> at priority >>>>>> N). Again happy to discuss further on list. >>>>>> >>>>> >>>>> OLD >>>>> 481 - Unreserved Bandwidth/Max LSP BW : In case of >>>> fixed containers >>>>> 482 (Type=1) the Unreserved Bandwidth field MUST be >>>> 16 bits long and >>>>> 483 indicates the Unreserved Bandwidth in >> number of available >>>>> 484 containers. Unreserved/MAX LSP BW fields for >>>> each identified >>>>> 485 priority MUST be included, in order of increasing >>>> prioritiy (0 to >>>>> 486 7) and Unreserved/MAX LSP BW fields for other >>>> priority values MUST >>>>> 487 be omitted. In case the number of supported >>>> priorities is odd, a >>>>> 488 16 bits all zeros padding field MUST be added. >>>> On the other hand, >>>>> 489 in case of variable containers (Type 2) the >>>> Unreserved/MAX LSP >>>>> 490 Bandwidth fields MUST be 32 bits long and >>>> expressed in IEEE >>>>> 491 floating point format. The advertisement of the >>>> MAX LSP bandwidth >>>>> 492 MUST take into account HO OPUk bit rate >> tolerance and be >>>>> 493 calculated according to the following formula: >>>>> >>>>> NEW >>>>> - Unreserved ODUj at Prio N (16 bits): This field is used >>>> only in case >>>>> of fixed containers (Type=1). It MUST be 16 bits long and >> indicates >>>>> the Unreserved Bandwidth in number of available containers. >>>>> A different field for each supported priority MUST be >> used. In case >>>>> the number of supported priorities is odd, a 16 bits all >>>> zeros padding >>>>> field MUST be added. >>>>> >>>> How about: >>>> - Unreserved ODUj (16 bits): This field indicates the Unreserved >>>> Bandwidth at a particular priority level. This field MUST >> be set to >>>> the number of ODUs at the indicated the Signal Type for a >> particular >>>> priority level. One field MUST be present for each bit set in the >>>> Priority field, and is ordered to match the Priority field. Fields >>>> MUST not be >> >> s/MUST not/MUST NOT >> >>>> present for priority levels that are not indicated in the Priority >>>> field. >> >>>> This field is REQUIRED for Type 1 (fixed >>>> container) TLVs, and MUST NOT be used for Type 2 TLVs. >>>> >> >> Actually, these lines are redundant with the format definition and can >> be dropped. >> > > OK > >>>> Also: >>>> Unreserved Padding (variable): The Padding field is used to >> ensure the >>>> 32 bit alignment of Unreserved ODUj fields. The length of the >>>> Unreserved Padding field is always a multiple of 16 bits (2 >>>> byte). Its length can be calculated, in bytes, as: >>>> % 2 >>>> When present, the Unreserved Padding field MUST be set to a >>>> zero (0) value on transmission and MUST be ignored on receipt. >>>> >>> >>> Ok, but shouldn't it be: >>> "Its length can be calculated, in multiple of 2 bytes, >>> as: "number of priorities indicated in Priorities field" % 2." ? >>> >>> When the number of priorities is odd, the unreserved padding >> field is 2 byte, when the number of priorities is even, the >> padding field is not there. >>> >> How about: >> >> - Unreserved Padding (variable): The Padding field is used to ensure >> the 32 bit alignment of Unreserved ODUj fields. When present the >> Unreserved Padding field is 16 bits (2 byte) long. When the number of >> priorities is odd, the unreserved Unreserved Padding field MUST be >> included. When the number of priorities is even, the Unreserved Padding >> MUST be omitted. >> > > OK, but it's not variable. When present it's always 16 bits. > >>> >>>>> - Unreserved Bandwidth at priority N (32 bits): This field is used >>>>> only in case of variable containers (Type=2). It MUST be 32 >>>> bits long >>>>> and indicates the Unreserved Bandwidth in bits/s in IEEE floating >>>>> point format. A different field for each supported >> priority MUST be >>>>> used. >>>>> >>>> How about: >>>> Unreserved Bandwidth (32 bits): This field indicates the >>>> Unreserved Bandwidth at a particular priority level. This >>>> field MUST be set to the bandwidth, in bits/s in IEEE >>>> floating point format, available at the indicated the Signal >>>> Type for a particular priority level. One field MUST be >>>> present for each bit set in the Priority field, and is ordered >>>> to match the Priority field. Fields MUST not be present for >>>> priority levels that are not indicated in the Priority >>>> field.This field is REQUIRED for Type 2 (variable container) >>>> TLVs, and MUST NOT be used for Type 1 TLVs. >>>> >> >> The Unreserved Bandwidth field remains undefined in the current text. > > Lost it. Now is there. > >> >>>>> - MAX LSP Bandwidth at priority N (32 bit): This field is >>>> used only in >>>>> case of variable containers (Type=2). It MUST be 32 bits long and >>>>> expressed in bits/s in IEEE floating point format. The >> advertisement >>>>> of the MAX LSP bandwidth MUST take into account HO OPUk bit rate >>>>> tolerance and be calculated according to the following formula: >>>>> >>>> How about: >>>> Maximum LSP Bandwidth (32 bit): This field indicates the >>>> maximum bandwidth that can be allocated for a single LSP at a >>>> particular priority level. This field MUST be set to the >>>> maximum bandwidth, in bits/s in IEEE floating point format, >>>> available to a single LSP at the indicated the Signal Type for >>>> a particular priority level. One field MUST be present for >>>> each bit set in the Priority field, and is ordered to match >>>> the Priority field. Fields MUST not be present for priority >>>> levels that are not indicated in the Priority field. >> >>>> This field >>>> is REQUIRED for Type 2 (variable container) TLVs, and MUST NOT >>>> be used for Type 1 TLVs. >>>> >> >> Actually, these lines are redundant with the format definition and can >> be dropped. > > Yes > >> >>> >>> OK >>> >>>> >>>>>>> >>>>>>>> ... >>>>>>>>> 6) Finally, some nits: >>>>>>>>> s/[OTN-INFO], the OSPF-TE/[OTN-INFO], OSPF-TE s/list >> of them/list >>>>>>>> s/Priority :8 bits/Priority (8 bits): >>>>>>>>> s/infer/imply >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> - You have some very nice examples, but are inconsistent >>>> in filling >>>>>>>> in field values. I think all values that can possibly be >>>> filled in >>>>>>>> in the examples should be. >>>>>>>> >>>>>>> >>>>>>> All the relevant ones have been introduces. Some non >>>> relevant fields >>>>>>> have been left with just the field name in. E.g. In an >>>>>> example showing >>>>>>> priorities management the T, S and TSG fields have not >> been filled >>>>>>> with 1 or 0 but just T,S and TSG have been left to make >>>> the reading >>>>>>> easier. >>>>>>> >>>>>> >>>>>> I think this will confuse some readers. I think it would >>>> be better >>>>>> to fill in as much as possible, and if not, indicate that >>>> the fields >>>>>> are not important to the case (or can carry a specific set of >>>>>> values). For example why not show that reserved&padding >> fields are >>>>>> 0, that the SWCaps=OTN-TDM, etc. >>>>> >>>>> Done (only T, S ans TSG left indicated as T, S and TSG when non >>>>> relevant for the example) >>>>> >>>> >>>> Will you add text to that effect to each of those examples? >>> >>> OK >>> >>>> >>>>>> >>>>>>>> Detailed editorial and technical comments: >>>>>>>> >>>>>> Thank you! >>>>>> [...] >>>>>> >>>>>> >>>>>>>> - Section 7 -- update to reference 4203 and 5920. Discuss >>>>>>>> implications / added risk of additional information >>>>>> provided in this >>>>>>>> document. >>>>>>> Reference to 4203 added and this piece of text added at the end: >>>>>>> >>>>>>> For security threats, defensive techniques, >>>> monitoring/detection/ >>>>>>> reporting of security attacks and requirements please refer to >>>>>>> [RFC5920] . >>>>>>> >>>>>>>> >>>>>>>> Section 8. This section needs some work. (I'm assuming your >>>>>>>> familiar with rfc5226). >>>>>>> >>>>>> >>>>>> Hereto, we'll see what the reviewers say... >>>>>> >>>>>>> What about: >>>>>>> >>>>>>> 8. IANA Considerations >>>>>>> >>>>>>> Upon approval of this document, IANA will make the >>>> assignment of a >>>>>>> new registry, the "OTN-TDM Container Registry" under >> a new GMPLS >>>>>>> Routing Parameters" with two new types (1 and 2) >>>>>>> >>>>>>> >>>>>>> Switching Type Description Reference >>>>>>> ---------------------- -------------------------- ---------- >>>>>>> 110 (suggested) OTN-TDM capable (OTN-TDM) [This.I-D] >>>>>>> >>>>>>> This document defines the following sub-TLVs of the ISCD TLV: >>>>>>> >>>>>>> Value Sub-TLV >>>>>>> ----- ------------------------------------------------- >>>>>>> 1 Unreserved Bandwidth for fixed containers >>>>>>> 2 Unreserved/MAX LSP bandwidth for flexible containers >>>>>>> >>>>>>>> >>>>>>>> - Switching types are assigned in >>>>>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig- >>>>>>>> parameters.xml#gmpls-sig-parameters-3 >>>>>>>> (Again I suggest 110, not 101, but this isn't a big deal) >>>>>>>> >>>>>>>> - I think you are actually asking for IANA to establish a >>>>>> new registry. >>>>>>>> Perhaps something like "OTN-TDM Container Registry" under a new >>>>>>>> "GMPLS Routing Parameters" with two new types. >>>>>> >>>>>> Sorry, I wasn't clear in my prior mail. I didn't mean >> for the text >>>>>> to end up in the draft unmodified. Take a look at >>>>>> >>>> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-dcsc-channel-ext-04 >>>>>> for an example of how to ask for a new Switching Type, and >>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rfc4420bis-03 for an >>>>>> example of how to ask for a new TLV registry. >>>>> >>>>> >>>>> Upon approval of this document, IANA will make the >>>> assignment in the >>>>> "Switching Types" section of the "GMPLS Signaling Parameters" >>>>> registry located at >>>> http://www.iana.org/assignments/gmpls-sig-parameters: >>>>> Value Type Reference >>>>> --------- -------------------------- ---------- >>>>> 110 (*) OTN-TDM capable (OTN-TDM) [This.I-D] >>>>> >>>>> (*) Suggested value >>>>> This document defines a new sub-TLV for the ISCD sub-TLV. >>>> How about >>>> This document defines 2 new TLVs that are carried in Interface >>>> Switching Capability Descriptors [RFC4203] with Signal Type OTN-TDM. >>>> >>>>> Each >>>>> TLV includes a 16-bit type identifier (the T-field). Two >>>> s/Two/The same >>>>> T-field values are applicable to the new sub-TLV. >>> ok >>> >>>>> >>>>> IANA >>>>> The IANA has created a new registry and will manage TLV type >>>>> identifiers as follows: >>>> How about: >>>> Upon approval of this document, IANA will create and maintain >>>> a new registry, the "sub-TLVs of the OTN-TDM Interface >>>> Switching Capability Descriptor TLV" registry under the "Open >>>> Shortest Path First >>>> (OSPF) Traffic Engineering TLVs" registry, see >>>> http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traf >>> fic-eng-tlvs.xml, >>>> with the TLV types as follows: >>>> >>>>> >>>>> - TLV Type = 1 >>>>> - TLV Name = Unreserved Bandwidth for fixed containers >>>>> >>>>> - TLV Type = 2 >>>>> - TLV Name = Unreserved Bandwidth for fixed containers >>>> >>>> The request Registration Procedures are Standards Action. >>>> >> >> What case does "Whether allowed on ISCD sub-TLV" cover? The >> scope of the >> registry is the OTN-TDM Interface Switching Capability Descriptor TLV. > > Removed, it didn't make much sense. > >> >> Thanks, >> Lou >> >> >>>> Lou >>>> >>>>> >>>>>> >>>>>> Lou >>>>>> >>>>>>>> >>>>>>>> That's it on this document. >>>>>>>> >>>>>>>> Lou >>>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>>>> Behalf Of Lou Berger >>>>>>>> Sent: gioved 20 dicembre 2012 0.28 >>>>>>>> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>>>>>> Subject: Re: [CCAMP] I-D Action: >>>>>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>>>> >>>>>>>> Authors? >>>>>>>> >>>>>>>> On 12/4/2012 4:34 PM, Lou Berger wrote: >>>>>>>>> Authors, >>>>>>>>> Please review any changes and how LC comments >> are addressed. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Lou >>>>>>>>> >>>>>>>>> On 11/28/2012 2:37 AM, internet-drafts@ietf.org wrote: >>>>>>>>>> >>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>> Internet-Drafts directories. >>>>>>>>>> This draft is a work item of the Common Control and >>>>>>>> Measurement Plane Working Group of the IETF. >>>>>>>>>> >>>>>>>>>> Title : Traffic Engineering Extensions to >>>>>>>> OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN >>>>>>>> Networks >>>>>>>>>> Author(s) : Daniele Ceccarelli >>>>>>>>>> Diego Caviglia >>>>>>>>>> Fatai Zhang >>>>>>>>>> Dan Li >>>>>>>>>> Sergio Belotti >>>>>>>>>> Pietro Vittorio Grandi >>>>>>>>>> Rajan Rao >>>>>>>>>> Khuzema Pithewan >>>>>>>>>> John E Drake >>>>>>>>>> Filename : >>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>>>>>> Pages : 33 >>>>>>>>>> Date : 2012-11-27 >>>>>>>>>> >>>>>>>>>> Abstract: >>>>>>>>>> ITU-T Recommendation G.709 [G.709-2012] has introduced >>>>>>>> new fixed and >>>>>>>>>> flexible Optical Data Unit (ODU) containers, >>>> enabling optimized >>>>>>>>>> support for an increasingly abundant service mix. >>>>>>>>>> >>>>>>>>>> This document describes Open Shortest Path First - Traffic >>>>>>>>>> Engineering (OSPF-TE) routing protocol extensions >> to support >>>>>>>>>> Generalized MPLS (GMPLS) control of all currently >> defined ODU >>>>>>>>>> containers, in support of both sub-lambda and lambda >>>>>>>> level routing >>>>>>>>>> granularity. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>> >>>>>> >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 >>>>>>>>>> >>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-04 >>>>>>>>>> >>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-gmpls-ospf-g709v3-0 >>>>>>>>>> 4 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> CCAMP mailing list >>>>>>>>>> CCAMP@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> CCAMP mailing list >>>>>>>>> CCAMP@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > From lberger@labn.net Fri Jan 11 13:01:17 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC8821F8A0C for ; Fri, 11 Jan 2013 13:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.852 X-Spam-Level: X-Spam-Status: No, score=-102.852 tagged_above=-999 required=5 tests=[AWL=0.747, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 5n8XPwazdqGj for ; Fri, 11 Jan 2013 13:01:16 -0800 (PST) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id E401221F87D6 for ; Fri, 11 Jan 2013 13:01:10 -0800 (PST) Received: (qmail 18344 invoked by uid 0); 11 Jan 2013 21:00:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 11 Jan 2013 21:00:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XjKC7tBEebzEh8nTWTDgfrmgoavxULeVwj89rzGBb6M=; b=XP9sxoVDU5achNjkH+lKUrZsXdYu5wKdR+qd6YkCbSyXL/syrYMfYDMbYCXEcQ8A2f6ZeP1zYCDdWjMVpzUpeBBboNp/M/3/V7xGrGi4O67PlDY9aq3Ri+BHNGxKVB6L; Received: from box313.bluehost.com ([69.89.31.113]:47635 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ttlia-0007Mc-5n; Fri, 11 Jan 2013 14:00:48 -0700 Message-ID: <50F07D86.4060109@labn.net> Date: Fri, 11 Jan 2013 16:00:54 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Daniele Ceccarelli References: <20121128073621.29401.81832.idtracker@ietfa.amsl.com> <50BE5DB0.9040507@labn.net> <50D24D55.5060003@labn.net> <4A1562797D64E44993C5CBF38CF1BE4804558C@ESESSMB301.ericsson.se> <50D329AF.1050506@labn.net> <4A1562797D64E44993C5CBF38CF1BE4805E67B@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4805E67B@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:01:17 -0000 Daniele, See below for detailed responses. Also, look to http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-otn-g709-info-model-06.txt for nits. Much thanks, Lou On 1/11/2013 10:20 AM, Daniele Ceccarelli wrote: > Hi Lou, > > Please see in line. > > Please also note that the references to G.798 amd2 and G.872 amd2 > were changed into G.798 new revision and G.872 new revision. > okay. Whichever is most accurate should be listed. > The first one is pre-published on the ITU-T ties web page and will be > officially published on January 16th, while G.872 was published in > October. Both of them are actually available for ties users only. > I believe the 1st has been covered in today's on-list discussion. The second was sent over already (thanks to Malcolm!) in https://datatracker.ietf.org/liaison/1204/ > These are the documents that should be requested to be publicly > available (no clue on when they will be available and if it is worth > waiting for them or a liaison might be more useful). > Based on today's discussion, I think we're fine. > BR > Daniele & Sergio > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: gioved 20 dicembre 2012 16.07 >> To: Daniele Ceccarelli >> Cc: ccamp@ietf.org; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >> Subject: Re: [CCAMP] I-D Action: >> draft-ietf-ccamp-otn-g709-info-model-05.txt >> >> Daniele / Authors, >> Thank you for the response. Please see below for my responses. >> >> >> >> On 12/20/2012 4:05 AM, Daniele Ceccarelli wrote: >>> Hi Lou, >>> >>> Below you can find the last call comments pasted with >> replies in line. >>> >>> All nits, typos and suggested text changes without any >> comment in line have been accepted/modified accordingly. >>> >>> BR >>> Daniele & Sergio >>> >>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf Of Lou Berger >>>> Sent: sabato 20 ottobre 2012 0.06 >>>> To: CCAMP; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: [CCAMP] WG Last Call comments on >>>> draft-ietf-ccamp-otn-g709-info-model-04 >>>> >>>> >>>> Authors, >>>> I have the following LC comments: >>>> >>>> General comments: >>>> >>>> - There's a lot of text/concepts that is common to both >> this document >>>> and the framework document. The document certainly adds additional >>>> useful detail, but I'm not sure it's really provides an information >>>> model of any kind. Optimally, I think this document should >> be merged >>>> with the framework document. I think this would yield a more >>>> comprehensive and understandable result. I really don't >> see this as >>>> a lot of work/time, although it clearly would be a major change >>>> >>>> If this is considered to be to onerous a proposal, then >> this document >>>> should at least be updated to (a) reduce duplication text with the >>>> framework document and (b) remove any references to "model" >> and just >>>> talk about providing "Additional Information" >>> >>> All duplicated text have been removed from this ID and kept >> into the FWK (mostly End of section 1, whole sections 2 and 3). >>> >> >> okay. >> >>> Title changed into: >>> Evaluation of existing GMPLS encoding against G.709v3 Optical >>> Transport Networks (OTN) >>> >>> And abstract into: >>> [...] >>> This document provides an evaluation of existing Generalized >>> Multiprotocol Label Switching (GMPLS) routing and >> signaling methods >>> against the G.709-2012 OTN networks. >>> >> >> okay. >> >>>> >>>> - The document should be reviewed by the authors to ensure it is >>>> consistent with the latest solutions documents and WG discussions. >>>> For example, there are multiple references to the contentious and >>>> much discussed "penultimate hop" case without any references to the >>>> agreed upon approach. >>> >>> Done. Please see section 3.2 >>> >> >> There still a number of instances where penultimate hop >> section of interface is mentioned. As we discussed on the >> list, this issue actually exists for any node that is >> selecting the egress' nodes incoming interface. This can be >> at the ingress (in setting an ERO), a transit node (doing ERO >> expansion), or the penultimate hop. So there are some >> additional fixes needed. >> > > OK. When penultimate node is mentioned the text is changed so to say that it's also an issue > of any intermediate node performing ERO expansions. It should not be an ingress > Node issue as the ingress is aware of the hierarchty. I think maintains the references to "penultimate node" may perpetuate the confusion that resulted in so much discussion. How about: OLD to permit the penultimate hop choosing the correct interface towards the egress node or any intermediate node choosing the right path when performing ERO expansion NEW to enable a downstream node to choose an appropriate interface, or interfaces, towards the egress node. OLD The signaled TSGs information is not enough to have a complete choice since the penultimate hop node (or any intermediate node performing ERO expansion) has NEW Signaled TSGs information is insufficient to completely identify interfaces that support the LSP's adaptation requirements as any downstream node performing ERO expansion has OLD In this way, when the penultimate node (or the intermediate node performing ERO expansion) receives such object, together with the Traffic Parameters Object, is allowed to choose the correct interface towards the egress node. NEW Such an object, together with the Traffic Parameters object, would enable any downstream node that performs ERO expansion to choose an appropriate interface, or interfaces, towards the egress node. > >>>> >>>> Editorial comments: >>>> >>>> - Please verify that abbreviations are defined before being used . >>>> There are a number of these. >>> >>> Done >>>> >>>> - Please use a consistent decimal representation (sometimes commas >>>> are used other times periods) >> >> There are instances where this is still an issue, e.g., search >> for 1,25. >> > ok s/2,5/2.5 > >>>> >>>> - the references [G709-v1] and [G709-v3] each actually refer to >>>> multiple documents, each documented needs to have it's own >>>> (correct) reference, i.g., [G709-v1] and [G709-v1a1]. The document >>>> text will need to be revisited to ensure the proper reference is >>>> made. >>> >>> RFC4328 for older versions of G709 and G709-2012 for the latest one >>> (v4) >>> >> >> great. >> >>>> >>>> - >>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft >>> -ietf-ccamp-otn-g709-info-model-04.txt >>>> shows there are unresolved nits that need to resolved . I'm using >>>> line numbers from this url in my subsequent comments. >>>> >>>> Line 18: Suggest dropping "The recent revision of" >>>> >> >> This chance was not made, was this intentional? (and this >> terminology continues to be used.) -- Yes this is a style >> comment -- so ignore as you see fit. > > Just missed it. It was removed and just reference to 709-2012 left. No problem. > >> >>>> Line 20/21: Suggest dropping the marketing phrase "enabling >> optimized >>>> support for an increasingly abundant service mix." >>>> >> >> This chance was not made, was this intentional? I think form >> of "marketing" doesn't belong in an PS -- just MO. > > removed > >> >>>> Lines 93-127 (through "of"): I don't see how this text provides any >>>> value. I suggest dropping it, or at most just reference the FWK >>>> document. >> >> No real change here. This text remains. Why are LSA types >> mentioned here at all? They aren't mentioned in the body of >> the document so should be removed. > > Agree. Removed. > >> >>>> >>>> Lines 319-341: Instances of "G.709" should be "[G.709-V3]" >>>> >> >> still missing '[]' >> >> [...] >> > > Last chages turned G.709 into G.709-2012. non sequitur... Much thanks. Lou > >> Thanks I think that's it. >> Lou >> >> >>> >>>> >>>> That's it on this document. >>>> >>>> Lou >>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf Of Lou Berger >>>> Sent: gioved 20 dicembre 2012 0.27 >>>> To: ccamp@ietf.org; >>>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-otn-g709-info-model-05.txt >>>> >>>> Authors? >>>> >>>> On 12/4/2012 3:31 PM, Lou Berger wrote: >>>>> Authors, >>>>> Please review any changes and how LC comments are addressed. >>>>> >>>>> Thank you, >>>>> Lou >>>>> >>>>> On 11/28/2012 2:36 AM, internet-drafts@ietf.org wrote: >>>>>> >>>>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. >>>>>> This draft is a work item of the Common Control and >>>> Measurement Plane Working Group of the IETF. >>>>>> >>>>>> Title : Evaluation of existing GMPLS encoding >>>> against G.709v3 Optical Transport Networks (OTN) >>>>>> Author(s) : Sergio Belotti >>>>>> Pietro Vittorio Grandi >>>>>> Daniele Ceccarelli >>>>>> Diego Caviglia >>>>>> Fatai Zhang >>>>>> Dan Li >>>>>> Filename : draft-ietf-ccamp-otn-g709-info-model-05.txt >>>>>> Pages : 22 >>>>>> Date : 2012-11-27 >>>>>> >>>>>> Abstract: >>>>>> The recent revision of ITU-T recommendation G.709 >>>> [G.709-2012] has >>>>>> introduced new fixed and flexible Optical Data Unit >>>> (ODU) containers >>>>>> in Optical Transport Networks (OTNs), enabling optimized >>>> support for >>>>>> an increasingly abundant service mix. >>>>>> >>>>>> This document provides an evaluation of existing Generalized >>>>>> Multiprotocol Label Switching (GMPLS) routing and >>>> signaling methods >>>>>> against the G.709-2012 OTN networks. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> >>>> >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-05 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> >>>> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-otn-g709-info-model >>>>>> -05 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> >>> >>> >> > > > From adrian@olddog.co.uk Fri Jan 11 13:10:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61DB21F8ACE; Fri, 11 Jan 2013 13:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 hL-iEZ67fLul; Fri, 11 Jan 2013 13:10:53 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5948A21F8AC8; Fri, 11 Jan 2013 13:10:50 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0BLAmOk032164; Fri, 11 Jan 2013 21:10:48 GMT Received: from 950129200 (089144192150.atnat0001.highway.a1.net [89.144.192.150]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0BLAj8v032133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Jan 2013 21:10:47 GMT From: "Adrian Farrel" To: , , , , Date: Fri, 11 Jan 2013 21:10:47 -0000 Message-ID: <01cb01cdf040$2219c5e0$664d51a0$@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: Ac3wPqAVHt9RLqNORBmXnogF2kx3kQ== Content-Language: en-gb Subject: [CCAMP] FW: Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:10:55 -0000 Heads up. A lot of you will be interested in this. Comments as usual for IETF last calls (see the instructions embedded). Do not send your comments in reply to *this* message. Thanks, Adrian > Sent: 11 January 2013 19:36 > To: IETF-Announce > Cc: opsawg@ietf.org > Subject: Last Call: (An > Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) > to Informational RFC > > > The IESG has received a request from the Operations and Management Area > Working Group WG (opsawg) to consider the following document: > - 'An Overview of Operations, Administration, and Maintenance (OAM) > Mechanisms' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset that can be used for fault detection and > isolation, and for performance measurement. OAM mechanisms have been > defined for various layers in the protocol stack, and are used with a > variety of protocols. > > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From lberger@labn.net Mon Jan 14 09:05:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDFF21F8A11 for ; Mon, 14 Jan 2013 09:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 V4mxVdqLrq8N for ; Mon, 14 Jan 2013 09:05:56 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 5175C21F892C for ; Mon, 14 Jan 2013 09:05:56 -0800 (PST) Received: (qmail 8445 invoked by uid 0); 14 Jan 2013 17:05:34 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 14 Jan 2013 17:05:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=DIUKpLrjwCxo9e11OiHjwX7aXB6vyfID32VUgKZgaJY=; b=lbcZ9IuF8WsroRTH4TEkQvVY8JngT7nNzH+EBRl0SvRKOtKV1QUMXc+U/DkFSaAPL1vv1TOXSdnx7KqKhn5+hgZ7swo/75S7BarEDqaRJ8JC1xqTFfpTqm6/5ha6aADk; Received: from box313.bluehost.com ([69.89.31.113]:48299 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TunTZ-0001xk-Of; Mon, 14 Jan 2013 10:05:33 -0700 Message-ID: <50F43AE4.6090807@labn.net> Date: Mon, 14 Jan 2013 12:05:40 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Margaria, Cyril (NSN - DE/Munich)" , dirk.schroetter@nutsix.de, "Giovanni Martinelli (giomarti)" , Steve.Balls@metaswitch.com, Ben.Wright@metaswitch.com References: <50BE808B.8070808@labn.net> In-Reply-To: <50BE808B.8070808@labn.net> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Regarding IPR on draft-margaria-ccamp-lsp-attribute-ero-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:05:57 -0000 Dirk, Please respond so that we can move this draft forward. Thank you, Lou PS CCAMP, if anyone knows how to contact Dirk please forward this message to him, or let us know who to reach him. On 12/4/2012 6:00 PM, Lou Berger wrote: > Authors, Contributors, (CCAMP) > > As part of the preparation for the poll on making this document a WG > document: > > Are you aware of any IPR that applies to > draft-margaria-ccamp-lsp-attribute-ero-02? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE'S TO LINES. > > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > CCAMP WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From db3546@att.com Mon Jan 14 10:25:31 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3940C21F882C for ; Mon, 14 Jan 2013 10:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 mFhiNfqDafOa for ; Mon, 14 Jan 2013 10:25:29 -0800 (PST) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7B821F8479 for ; Mon, 14 Jan 2013 10:25:28 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id 99d44f05.2aaac8a00940.329644.00-591.906865.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 14 Jan 2013 18:25:29 +0000 (UTC) X-MXL-Hash: 50f44d995ca4208c-36679e871037931b24a1b6fca9be650405e8c641 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 59d44f05.0.329630.00-432.906820.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 14 Jan 2013 18:25:26 +0000 (UTC) X-MXL-Hash: 50f44d9667e3cc1c-30c1faae79d5b0383c6dba084d660c1953328724 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0EIPO3O024644; Mon, 14 Jan 2013 10:25:25 -0800 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0EIPIJY024424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 10:25:18 -0800 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by fflint03.pst.cso.att.com (RSA Interceptor); Mon, 14 Jan 2013 10:24:57 -0800 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0318.001; Mon, 14 Jan 2013 13:24:56 -0500 From: "BRUNGARD, DEBORAH A" To: "George Swallow (swallow@cisco.com)" , "cfilsfil@cisco.com" , "'ruediger.kunze@telekom.de' (ruediger.kunze@telekom.de)" Thread-Topic: [CCAMP] Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 Thread-Index: AQHN0nNHY2qCATmn5UmCEaY+YBPBHJhJYsRw Date: Mon, 14 Jan 2013 18:24:55 +0000 Message-ID: References: <50BE8099.90903@labn.net> In-Reply-To: <50BE8099.90903@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=Lu0lPAhc c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=moStjiy5nyYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=EyqTNXCpBRQA:10 a=48vgC7mUAAAA:8 a=Vd7jPXspK3RZ-X] X-AnalysisOut: [tFc_oA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=mBFNsK4nY9A] X-AnalysisOut: [XRSVn:21 a=tcNitwQ5x9X9Fbwx:21] Cc: "ccamp@ietf.org" Subject: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:25:31 -0000 Authors, Can you please respond on IPR for this draft so we can start the poll? Thanks, Deborah -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Tuesday, December 04, 2012 6:01 PM To: Zafar Ali; George Swallow; Clarence Filsfils; Matt Hartley; Ori Gerstel= ; Gabriele Maria Galimberti; Kenji Kumaki; Rudiger Kunze; Julien Meuric Cc: CCAMP Subject: [CCAMP] Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 Authors, Contributors, (CCAMP) As part of the preparation for the poll on making this document a WG document: Are you aware of any IPR that applies to draft-ali-ccamp-xro-lsp-subobject-02? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Mon Jan 14 10:31:31 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE96221F8890 for ; Mon, 14 Jan 2013 10:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 OT4xqwemJKGA for ; Mon, 14 Jan 2013 10:31:31 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9121F888C for ; Mon, 14 Jan 2013 10:31:31 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id 30f44f05.2aaaff057940.334319.00-558.916103.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 14 Jan 2013 18:31:31 +0000 (UTC) X-MXL-Hash: 50f44f034edc2b71-be2f672e97a7e6b27843d5aa142c53c36cff212a Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id dfe44f05.0.334282.00-332.915989.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 14 Jan 2013 18:31:26 +0000 (UTC) X-MXL-Hash: 50f44efe78d086be-0a5ed17f85ce11c0f2428af67092eb5e28fd37d2 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0EIVOXe003645; Mon, 14 Jan 2013 10:31:25 -0800 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0EIVEOR003305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 10:31:18 -0800 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by fflint04.pst.cso.att.com (RSA Interceptor); Mon, 14 Jan 2013 10:30:54 -0800 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0318.001; Mon, 14 Jan 2013 13:30:53 -0500 From: "BRUNGARD, DEBORAH A" To: "George Swallow (swallow@cisco.com)" , "'ruediger.kunze@telekom.de' (ruediger.kunze@telekom.de)" Thread-Topic: [CCAMP] Regarding IPR on draft-ali-ccamp-te-metric-recording-03 Thread-Index: AQHN0nM9+l5XMkKoqUO4g/EEepgWO5hJZCQA Date: Mon, 14 Jan 2013 18:30:53 +0000 Message-ID: References: <50BE8093.7090800@labn.net> In-Reply-To: <50BE8093.7090800@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=DojhDhD+ c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=99lcvn2hCx8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=aT0cttEDz8YA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8] X-AnalysisOut: [ a=Vd7jPXspK3RZ-XtFc_oA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=JfD0Fch1gWkA:10 a=FgK2cTR4rZR0sWmV:21 a=Bjw_ICFGl7Q4] X-AnalysisOut: [YdR_:21] Cc: "ccamp@ietf.org" Subject: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-te-metric-recording-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:31:32 -0000 Authors, Can you please respond on IPR for this draft so we can start the poll? Thanks, Deborah -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Tuesday, December 04, 2012 6:01 PM To: Zafar Ali (zali); George Swallow (swallow); cfilsfil@cisco.com; mhartle= y@cisco.com; Kenji Kumaki; Rudiger Kunze; CCAMP Subject: [CCAMP] Regarding IPR on draft-ali-ccamp-te-metric-recording-03 Authors, Contributors, (CCAMP) As part of the preparation for the poll on making this document a WG document: Are you aware of any IPR that applies to draft-ali-ccamp-te-metric-recording-03? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From zali@cisco.com Mon Jan 14 10:43:37 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878B921F85CB for ; Mon, 14 Jan 2013 10:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 t2f+I4f+jx4p for ; Mon, 14 Jan 2013 10:43:36 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C55EF21F858A for ; Mon, 14 Jan 2013 10:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2788; q=dns/txt; s=iport; t=1358189016; x=1359398616; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2mTTtkxXey746WEZgbJKfQPDY8Wa9xdeiHBIxTsuXQM=; b=D8ZcQu3TASAm7hHsWTc0AxPbukihIqnbi8K86/BbIK5XOUFPdP8vjel8 utFeL2uE591Ndp0S+uk5RKJokj5E0fU5HcxqqWTW8Uwx7tEUZCMX5EyuG Qu6iUX+YaNHaNnfnFLlr5eQCLR4o4W7YjMDv63ovcs/RoWJK4iCaumsI0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAPtP9FCtJV2b/2dsb2JhbABEukSDNRZzgh4BAQEEAQEBawYFDAYBCBEEAQELHS4LFAgBCAIEAQ0FCIgRDLR1jGsLg1dhA5cnjy2CdYFvNQ X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208";a="162256494" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 14 Jan 2013 18:43:36 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0EIha2G002706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 18:43:36 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 12:43:35 -0600 From: "Zafar Ali (zali)" To: "BRUNGARD, DEBORAH A" , "George Swallow (swallow)" , "Clarence Filsfils (cfilsfil)" , "'ruediger.kunze@telekom.de' (ruediger.kunze@telekom.de)" Thread-Topic: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 Thread-Index: AQHN0nM1MCyoML8mJk+CgcQwSXSVyZhJyJWA//+xZAA= Date: Mon, 14 Jan 2013 18:43:35 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.247.118] Content-Type: text/plain; charset="Windows-1252" Content-ID: <953923C9FD31A34F9D227E735F244F20@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:43:37 -0000 Hi Deborah:=20 Thanks for your follow-up; much appreciated. Please note that the ID is also about to expire. We will be posted a ver -03 shortly.=20 Thanks Regards =8A Zafar=20 On 1/14/13 1:24 PM, "BRUNGARD, DEBORAH A" wrote: >Authors, >Can you please respond on IPR for this draft so we can start the poll? >Thanks, >Deborah > >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >Lou Berger >Sent: Tuesday, December 04, 2012 6:01 PM >To: Zafar Ali; George Swallow; Clarence Filsfils; Matt Hartley; Ori >Gerstel; Gabriele Maria Galimberti; Kenji Kumaki; Rudiger Kunze; Julien >Meuric >Cc: CCAMP >Subject: [CCAMP] Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 > >Authors, Contributors, (CCAMP) > >As part of the preparation for the poll on making this document a WG >document: > >Are you aware of any IPR that applies to >draft-ali-ccamp-xro-lsp-subobject-02? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > >If you are listed as a document author or contributor please answer the >above by responding to this email regardless of whether or not you are >aware of any relevant IPR. This document will not advance to the next >stage until a response has been received from each author and listed >contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS >MESSAGE'S TO LINES. > >If you are on the CCAMP WG email list but are not listed as an author or >contributor, we remind you of your obligations under the IETF IPR rules >which encourages you to notify the IETF if you are aware of IPR of >others on an IETF contribution, or to refrain from participating in any >contribution or discussion related to your undisclosed IPR. For more >information, please see the RFCs listed above and >http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > >Thank you, >CCAMP WG Chairs > >PS Please include all listed in the headers of this message in your >response. > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From zali@cisco.com Mon Jan 14 10:44:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC93621F87A6 for ; Mon, 14 Jan 2013 10:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YIfIN532maAa for ; Mon, 14 Jan 2013 10:44:54 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BABC921F888E for ; Mon, 14 Jan 2013 10:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2750; q=dns/txt; s=iport; t=1358189095; x=1359398695; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jH9MZJLaahTFwABZHG6MiqT0yEc2LmbNaLVtttv9xgo=; b=dtLKYToXuPolyaffWwjimvsz3YGwSlrMCq6P7/+8OskLzb2w0OyRSzvQ XbGhwmXSAi+cOLHLQZ4TnPcnSwWUH78+34jJvLFKaJ1Fr3iU+8dAv5Cju BYY0YffAhH8HyG4wk7AyCznV7dRzK84eOUeCvAsaLGfShleVWNUJz4E1G w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJtR9FCtJV2b/2dsb2JhbABEukSDNRZzgh4BAQEEAQEBawYFDAYBCBEEAQELHS4LFAgBCAIEAQ0FCIgRDLRqjGsLg1dhA5cnjy2CdYFvNQ X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208";a="162258964" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jan 2013 18:44:54 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0EIispl003775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 18:44:54 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 12:44:53 -0600 From: "Zafar Ali (zali)" To: "BRUNGARD, DEBORAH A" , "George Swallow (swallow)" , "'ruediger.kunze@telekom.de' (ruediger.kunze@telekom.de)" Thread-Topic: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-te-metric-recording-03 Thread-Index: AQHN0nMuO7pIcuFJkkCRmuRB33QAlZhJykCA//+wGIA= Date: Mon, 14 Jan 2013 18:44:53 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.247.118] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1D03C915F5BE0F40836B54738F8A31F3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-te-metric-recording-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:44:55 -0000 Hi Deborah: Thanks for your follow-up; much appreciated. Please note that the ID is also about to expire. We will be posting a ver -04 shortly. Thanks Regards =8A Zafar On 1/14/13 1:30 PM, "BRUNGARD, DEBORAH A" wrote: >Authors, >Can you please respond on IPR for this draft so we can start the poll? >Thanks, >Deborah > >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >Lou Berger >Sent: Tuesday, December 04, 2012 6:01 PM >To: Zafar Ali (zali); George Swallow (swallow); cfilsfil@cisco.com; >mhartley@cisco.com; Kenji Kumaki; Rudiger Kunze; CCAMP >Subject: [CCAMP] Regarding IPR on draft-ali-ccamp-te-metric-recording-03 > >Authors, Contributors, (CCAMP) > >As part of the preparation for the poll on making this document a WG >document: > >Are you aware of any IPR that applies to >draft-ali-ccamp-te-metric-recording-03? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > >If you are listed as a document author or contributor please answer the >above by responding to this email regardless of whether or not you are >aware of any relevant IPR. This document will not advance to the next >stage until a response has been received from each author and listed >contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS >MESSAGE'S TO LINES. > >If you are on the CCAMP WG email list but are not listed as an author or >contributor, we remind you of your obligations under the IETF IPR rules >which encourages you to notify the IETF if you are aware of IPR of >others on an IETF contribution, or to refrain from participating in any >contribution or discussion related to your undisclosed IPR. For more >information, please see the RFCs listed above and >http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > >Thank you, >CCAMP WG Chairs > >PS Please include all listed in the headers of this message in your >response. > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From zali@cisco.com Mon Jan 14 10:52:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C63421F8AB8 for ; Mon, 14 Jan 2013 10:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 hPNMUAaR+-NH for ; Mon, 14 Jan 2013 10:52:30 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2F18B21F8818 for ; Mon, 14 Jan 2013 10:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3128; q=dns/txt; s=iport; t=1358189550; x=1359399150; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kiMinNe0cCcJorNd1tNGZaVC5uOHBALWR2ykjRz3TS4=; b=icS5qV4hrmLQd4soo/Uii7anyFrZr6S6YzMsQaypEcx5k+VJLJVs7xYr iau738kdBNwqWwtAVxfpu7oY/a1bb0f2uAg+E8moCoOuUWZaA5eY+SXF2 AmBSL7u0NTtYXLTjvrynutTa0jxyCezK6vX9Bv15ZDYjLgtckmbkHqH7M c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAAhT9FCtJV2b/2dsb2JhbABEukSDNRZzgh4BAQEEAQEBawYFDAYBCBEEAQEBCh0uCxQIAQgCBAENBQiIEQy0aoxrC4NXYQOXJ48tgnWBbzU X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208";a="162238437" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 14 Jan 2013 18:52:29 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0EIqTDY013172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 18:52:29 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 12:52:29 -0600 From: "Zafar Ali (zali)" To: "BRUNGARD, DEBORAH A" , "George Swallow (swallow)" , "'ruediger.kunze@telekom.de' (ruediger.kunze@telekom.de)" Thread-Topic: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-te-metric-recording-03 Thread-Index: AQHN0nMuO7pIcuFJkkCRmuRB33QAlZhJykCA//+wGICAAAIdgA== Date: Mon, 14 Jan 2013 18:52:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.247.118] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <8A8A9791B1684147A49449F1492A6351@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-te-metric-recording-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:52:33 -0000 Hi Deborah: Sorry sent it too quick. I had email for some drafts that they are expiring this week and got confused. This ID is valid until April 21, 2013. Please ignore my email. Thanks Regards ... Zafar=20 On 1/14/13 1:44 PM, "Zafar Ali (zali)" wrote: >Hi Deborah: > >Thanks for your follow-up; much appreciated. > >Please note that the ID is also about to expire. We will be posting a ver >-04 shortly. > >Thanks > >Regards =A9 Zafar > > > > >On 1/14/13 1:30 PM, "BRUNGARD, DEBORAH A" wrote: > >>Authors, >>Can you please respond on IPR for this draft so we can start the poll? >>Thanks, >>Deborah >> >>-----Original Message----- >>From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >>Lou Berger >>Sent: Tuesday, December 04, 2012 6:01 PM >>To: Zafar Ali (zali); George Swallow (swallow); cfilsfil@cisco.com; >>mhartley@cisco.com; Kenji Kumaki; Rudiger Kunze; CCAMP >>Subject: [CCAMP] Regarding IPR on draft-ali-ccamp-te-metric-recording-03 >> >>Authors, Contributors, (CCAMP) >> >>As part of the preparation for the poll on making this document a WG >>document: >> >>Are you aware of any IPR that applies to >>draft-ali-ccamp-te-metric-recording-03? >> >> Please state either: >> >> "No, I'm not aware of any IPR that applies to this draft" >> or >> "Yes, I'm aware of IPR that applies to this draft" >> >>If so, has this IPR been disclosed in compliance with IETF IPR rules >>(see RFCs 3979, 4879, 3669 and 5378 for more details)? >> >> If yes to the above, please state either: >> >> "Yes, the IPR has been disclosed in compliance with IETF IPR rules" >> or >> "No, the IPR has not been disclosed" >> >> If you answer no, please provide any additional details you think >> appropriate. >> >>If you are listed as a document author or contributor please answer the >>above by responding to this email regardless of whether or not you are >>aware of any relevant IPR. This document will not advance to the next >>stage until a response has been received from each author and listed >>contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS >>MESSAGE'S TO LINES. >> >>If you are on the CCAMP WG email list but are not listed as an author or >>contributor, we remind you of your obligations under the IETF IPR rules >>which encourages you to notify the IETF if you are aware of IPR of >>others on an IETF contribution, or to refrain from participating in any >>contribution or discussion related to your undisclosed IPR. For more >>information, please see the RFCs listed above and >>http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >> >>Thank you, >>CCAMP WG Chairs >> >>PS Please include all listed in the headers of this message in your >>response. >> >>_______________________________________________ >>CCAMP mailing list >>CCAMP@ietf.org >>https://www.ietf.org/mailman/listinfo/ccamp >>_______________________________________________ >>CCAMP mailing list >>CCAMP@ietf.org >>https://www.ietf.org/mailman/listinfo/ccamp > From wwwrun@rfc-editor.org Mon Jan 14 17:33:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE2311E80B8; Mon, 14 Jan 2013 17:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFfOzdtT5m5a; Mon, 14 Jan 2013 17:33:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E839A11E80A2; Mon, 14 Jan 2013 17:33:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6D474B1E004; Mon, 14 Jan 2013 17:22:59 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130115012259.6D474B1E004@rfc-editor.org> Date: Mon, 14 Jan 2013 17:22:59 -0800 (PST) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 6825 on Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 01:33:42 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6825 Title: Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS Author: M. Miyazawa, T. Otani, K. Kumaki, T. Nadeau Status: Standards Track Stream: IETF Date: January 2013 Mailbox: ma-miyazawa@kddilabs.jp, Tm-otani@kddi.com, ke-kumaki@kddi.com, tnadeau@juniper.net Pages: 40 Characters: 72765 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-ted-mib-15.txt URL: http://www.rfc-editor.org/rfc/rfc6825.txt This memo defines the Management Information Base (MIB) objects for managing the Traffic Engineering Database (TED) information with extensions in support of the Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. [STANDARDS-TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From zhangfatai@huawei.com Mon Jan 14 18:43:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607D811E809B for ; Mon, 14 Jan 2013 18:43:16 -0800 (PST) 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=[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 on8N58YT-P5C for ; Mon, 14 Jan 2013 18:43:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1812011E8099 for ; Mon, 14 Jan 2013 18:43:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOT81750; Tue, 15 Jan 2013 02:43:13 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 02:43:06 +0000 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 02:43:12 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Tue, 15 Jan 2013 10:43:03 +0800 From: Fatai Zhang To: Daniele Ceccarelli , "Gruman, Fred" , "ccamp@ietf.org" Thread-Topic: Switching Capability/Type for ospf-g709v3, signaling-g709v3 Thread-Index: Ac3s82+y8vO2F259QmKlwmEkZgQsmgAnFmNAAU6H/qA= Date: Tue, 15 Jan 2013 02:43:03 +0000 Message-ID: References: <5DF87403A81B0C43AF3EB1626511B2923C3031BF@RCHEXMBP2.fnc.net.local> <4A1562797D64E44993C5CBF38CF1BE4805CD90@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4805CD90@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF835855C67SZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] Switching Capability/Type for ospf-g709v3, signaling-g709v3 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 02:43:16 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF835855C67SZXEML552MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fred and Daniele, Yes, I will update to make them consistent. Best Regards Fatai From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Tuesday, January 08, 2013 7:06 PM To: Gruman, Fred; ccamp@ietf.org Cc: Fatai Zhang Subject: RE: Switching Capability/Type for ospf-g709v3, signaling-g709v3 Hi Fred, during the last call it was suggested to change the switching capability fr= om 101 to 110. The comment was raised just against OSPF, but i think it was= just an oversight. If Fatai and the other co-authors agree i would suggest aligning also RSVP = to 110 (either explicitely or with a reference to OSPF) Many thanks Daniele ________________________________ From: Gruman, Fred [mailto:fred.gruman@us.fujitsu.com] Sent: luned=EC 7 gennaio 2013 17.24 To: ccamp@ietf.org Cc: Fatai Zhang; Daniele Ceccarelli Subject: Switching Capability/Type for ospf-g709v3, signaling-g709v3 Hi Fatai, Daniele, I noticed that in the latest routing draft of ospf-g709v3-04 that the switc= hing capability was changed from 101 to 110. The latest signaling draft si= gnaling-g709v3-05 still lists 101 as the switching type (in section 4) alth= ough it does defer to [OTN-OSPF]. I assume that the switching capability/t= ype is to be consistent between routing and signaling and that the new reco= mmendation is 110. Is this correct? If so, I would recommend removing the "(101, TBA by IANA)" from the signali= ng draft and rely on the reference to [OTN-OSPF]. Thanks, Fred --_000_F82A4B6D50F9464B8EBA55651F541CF835855C67SZXEML552MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Fred and Daniele,

 

Yes, I will update to make them consistent.

 

&n= bsp;

&n= bsp;

Best Re= gards

&n= bsp;

Fatai

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsso= n.com]
Sent: Tuesday, January 08, 2013 7:06 PM
To: Gruman, Fred; ccamp@ietf.org
Cc: Fatai Zhang
Subject: RE: Switching Capability/Type for ospf-g709v3, signaling-g7= 09v3

 

Hi Fred,=

 

during the last= call it was suggested to change the switching capability from 101 to 110. = The comment was raised just against OSPF, but i think it was just an oversight.=

 

If Fatai and th= e other co-authors agree i would suggest aligning also RSVP to 110 (either = explicitely or with a reference to OSPF)

 

Many thanks
Daniele

 

 

 

From: Gruman, Fred [mailto:f= red.gruman@us.fujitsu.com]
Sent: luned=EC 7 gennaio 2013 17.24
To: ccamp@ietf.org
Cc: Fatai Zhang; Daniele Ceccarelli
Subject: Switching Capability/Type for ospf-g709v3, signaling-g709v3=

Hi Fatai, Daniele,

 

I noticed that in the latest ro= uting draft of ospf-g709v3-04 that the switching capability was changed fro= m 101 to 110.  The latest signaling draft signaling-g709v3-05 still li= sts 101 as the switching type (in section 4) although it does defer to [OTN-OSPF].  I assume that the switching= capability/type is to be consistent between routing and signaling and that= the new recommendation is 110.  Is this correct?

 

If so, I would recommend removi= ng the “(101, TBA by IANA)” from the signaling draft and rely o= n the reference to [OTN-OSPF].

 

Thanks,

Fred

 

--_000_F82A4B6D50F9464B8EBA55651F541CF835855C67SZXEML552MBXchi_-- From zhangfatai@huawei.com Mon Jan 14 23:47:24 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE19121F8B08 for ; Mon, 14 Jan 2013 23:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.327 X-Spam-Level: X-Spam-Status: No, score=-4.327 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 bhPkhgVsBVBc for ; Mon, 14 Jan 2013 23:47:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 27ACB21F88C4 for ; Mon, 14 Jan 2013 23:47:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANN99720; Tue, 15 Jan 2013 07:47:18 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 07:47:10 +0000 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 07:47:16 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Tue, 15 Jan 2013 15:47:13 +0800 From: Fatai Zhang To: Lou Berger Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 Thread-Index: AQHN4nqPdVRTcHuIFUSv0ekPirccYZg3rcsAgBJvoeA= Date: Tue, 15 Jan 2013 07:47:12 +0000 Message-ID: References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> In-Reply-To: <50E5FD4A.1080207@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF835855DB5SZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 07:47:25 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF835855DB5SZXEML552MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTG91LA0KDQoNCg0KU29ycnkgZm9yIGxhdGUgcmVzcG9uc2UgYmVjYXVzZSBvZiBteSB2YWNh dGlvbi4NCg0KDQoNClBsZWFzZSBzZWUgaW4tbGluZSBiZWxvdy4NCg0KDQoNCg0KDQoNCg0KDQoN CkJlc3QgUmVnYXJkcw0KDQoNCg0KRmF0YWkNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NClNlbnQ6IEZy aWRheSwgSmFudWFyeSAwNCwgMjAxMyA1OjUxIEFNDQpUbzogRmF0YWkgWmhhbmcNCkNjOiBDQ0FN UDsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3Jn DQpTdWJqZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQoNCg0KDQoNCg0KSGkgRmF0YWksDQoN CiAgICAgICAgIEhhcHB5IG5ldyB5ZWFyLiAgUGxlYXNlIHNlZSBiZWxvdyBmb3IgcmVzcG9uc2Vz Lg0KDQoNCg0KT24gMTIvMjUvMjAxMiAzOjMzIEFNLCBGYXRhaSBaaGFuZyB3cm90ZToNCg0KPg0K DQo+IEhpIExvdSwNCg0KPg0KDQo+IFBsZWFzZSBzZWUgaW4tbGluZSBiZWxvdy4NCg0KPg0KDQo+ IEEgbmV3IHZlcnNpb24gd2lsbCBiZSBpc3N1ZWQgYWZ0ZXIgYWxsIG9wZW4gaXNzdWVzIGFyZSBy ZXNvbHZlZC4NCg0KPg0KDQo+DQoNCj4NCg0KPg0KDQo+DQoNCj4gQmVzdCBSZWdhcmRzDQoNCj4N Cg0KPiBGYXRhaQ0KDQo+DQoNCj4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+ PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCg0KPj4gU2VudDog VGh1cnNkYXksIERlY2VtYmVyIDIwLCAyMDEyIDEwOjEyIFBNDQoNCj4+IFRvOiBGYXRhaSBaaGFu Zw0KDQo+PiBDYzogQ0NBTVA7IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2 M0B0b29scy5pZXRmLm9yZw0KDQo+PiBTdWJqZWN0OiBSZTogtPC4tDogW0NDQU1QXSBXRyBMYXN0 IENhbGwgY29tbWVudHMgb24NCg0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcw OXYzLTA0DQoNCj4+DQoNCj4+IEZhdGFpL0F1dGhvcnMsDQoNCj4+ICAgICAgICAgIFRoYW5rIHlv dSBmb3IgdGhlIG1haWwsIGFuZCBzb3JyeSBhYm91dCBteSBkZWxheWVkIHJlc3BvbnNlLiBCVFcN Cg0KPj4gcGxlYXNlIGZlZWwgZnJlZSB0byBjb250aW51ZSBkaXNjdXNzaW5nIHRoZSByZW1haW5p bmcgb3BlbiBpc3N1ZXMgb24gdGhlDQoNCj4+IGxpc3QgYW5kIHJlYWNoaW5nIGNsb3N1cmUgb24g dGhlIGxpc3QgKG9uIHNwZWNpZmljIHRleHQvcmVzb2x1dGlvbnMpDQoNCj4+IHByaW9yIHRvIHB1 Ymxpc2hpbmcgdGhlIG5leHQgcmV2Lg0KDQo+Pg0KDQo+PiBQbGVhc2Ugc2VlIGJlbG93IGZvciBp bmxpbmUgcmVzcG9uc2VzLg0KDQo+Pg0KDQo+PiBPbiAxMi83LzIwMTIgNDo1MyBBTSwgRmF0YWkg Wmhhbmcgd3JvdGU6DQoNCj4+PiBIaSBMb3UsDQoNCj4+Pg0KDQo+Pj4gUGxlYXNlIHNlZSBob3cg dGhlIExDIGNvbW1lbnRzIGFkZHJlc3NlZCBiZWxvdy4NCg0KPj4+DQoNCj4+PiBCZXN0IFJlZ2Fy ZHMNCg0KPj4+DQoNCj4+PiBGYXRhaQ0KDQo+Pj4NCg0KPj4+DQoNCj4+PiAtLS0tLdPKvP7Urbz+ LS0tLS0NCg0KPj4+ILeivP7IyzogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1w LWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCg0KTG91IEJlcmdlcg0KDQo+Pj4gt6LLzcqxvOQ6IDIw MTLE6jEw1MIyMsjVIDEwOjAxDQoNCj4+PiDK1bz+yMs6IENDQU1QOyBkcmFmdC1pZXRmLWNjYW1w LWdtcGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCg0KPj4+INb3zOI6IFtDQ0FN UF0gV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uDQoNCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2ln bmFsaW5nLWc3MDl2My0wNA0KDQo+Pj4NCg0KPj4+IEF1dGhvcnMsDQoNCj4+PiAgICAgSSBoYXZl IHRoZSBmb2xsb3dpbmcgTEMgY29tbWVudHM6DQoNCj4+Pg0KDQo+Pj4gR2VuZXJhbCBjb21tZW50 czoNCg0KPj4+DQoNCj4+PiAtIFRoaXMgZG9jdW1lbnQgYWxzbyBuZWVkcyBzb21lIGFkZGl0aW9u IHdvcmsgb24gY29uZm9ybWFuY2UgbGFuZ3VhZ2UuDQoNCj4+PiBJJ2xsIHRyeSB0byBwb2ludCBv dXQgY2FzZXMgaW4gdGhlIGRldGFpbGVkIGNvbW1lbnRzIGJlbG93Lg0KDQo+Pj4NCg0KPj4gW0Zh dGFpXSBPSy4gQ2hlY2tlZCBhbmQgcmVmaW5lZCBiYXNlZCBvbiB5b3VyIGRldGFpbGVkIGNvbW1l bnRzLg0KDQo+Pj4NCg0KPj4NCg0KPj4gSSB0aGluayB0aGlzIHJldiBpcyBhbiBpbXByb3ZlbWVu dCwgYnV0IHRoZXJlJ3Mgc3RpbGwgbW9yZSB3b3JrIG5lZWRlZC4NCg0KPj4gSSBoYXZlIG1hZGUg c29tZSBzcGVjaWZpYyBjb21tZW50cy9zdWdnZXN0aW9ucyBiZWxvdy4NCg0KPj4NCg0KPj4+IC0g U2VjdGlvbiA1IGVzc2VudGlhbGx5IGRlZmluZXMgYSBuZXcgc2V0IG9mIHRyYWZmaWMgcGFyYW1l dGVycy4gIEdpdmVuDQoNCj4+PiB0aGUgY2hhbmdlcywgd2h5IG5vdCBhc2sgZm9yIGEgbmV3IEMt VFlQRSBhbmQgbm90IHdvcnJ5IGFib3V0IFtSRkM0MzI4XQ0KDQo+Pj4gY29tcGF0aWJpbGl0eS9k ZXNjcmlwdGlvbj8NCg0KPj4+DQoNCj4+IFtGYXRhaV0gQWNjZXB0ZWQgdG8gaGF2ZSBhIG5ldyBD LVRZUEUgYW5kIHVwZGF0ZWQgdGhlIHRleHQgYWNjb3JkaW5nbHkuDQoNCj4+Pg0KDQo+Pg0KDQo+ PiBPa2F5Lg0KDQo+Pg0KDQo+Pj4gRGV0YWlsZWQgZWRpdG9yaWFsIGFuZCB0ZWNobmljYWwgY29t bWVudHM6DQoNCj4+Pg0KDQo+Pj4gLSBQbGVhc2UgdmVyaWZ5IHRoYXQgYWJicmV2aWF0aW9ucyBh cmUgZGVmaW5lZCBiZWZvcmUgYmVpbmcgdXNlZCAuDQoNCj4+PiBUaGVyZSBhcmUgYSBudW1iZXIg b2YgdGhlc2UuDQoNCj4+Pg0KDQo+PiBbRmF0YWldIFdlbnQgdGhyb3VnaCBhbmQgdXBkYXRlZC4N Cg0KPj4NCg0KPj4gdGhhbmtzLg0KDQo+Pg0KDQo+Pj4NCg0KPj4+IC0gUGxlYXNlIHVzZSBhIGNv bnNpc3RlbnQgZGVjaW1hbCByZXByZXNlbnRhdGlvbiAoc29tZXRpbWVzIGNvbW1hcyBhcmUNCg0K Pj4+IHVzZWQgb3RoZXIgdGltZXMgcGVyaW9kcykNCg0KPj4+DQoNCj4+IFtGYXRhaV0gT0suIENv bW1hcyBhcmUgdXNlZC4NCg0KPj4NCg0KPj4gZ3JlYXQsIGFsdGhvdWdoIGEgcXVpY2sgc2tpbSBm aW5kczoNCg0KPj4gcy8xLDMwMS42ODMuMjE3LzEsMzAxLDY4My4yMTcNCg0KPj4NCg0KPj4NCg0K Pj4NCg0KPj4+DQoNCj4+PiAtIHRoZSByZWZlcmVuY2VzIFtHNzA5LXYxXSBhbmQgW0c3MDktdjNd IGVhY2ggYWN0dWFsbHkgcmVmZXIgdG8gbXVsdGlwbGUNCg0KPj4+IGRvY3VtZW50cywgZWFjaCBk b2N1bWVudGVkIG5lZWRzIHRvIGhhdmUgaXQncyBvd24gKGNvcnJlY3QpIHJlZmVyZW5jZSwNCg0K Pj4+IGkuZy4sIFtHNzA5LXYxXSBhbmQgW0c3MDktdjFhMV0uIFRoZSBkb2N1bWVudCB0ZXh0IHdp bGwgbmVlZCB0byBiZQ0KDQo+Pj4gcmV2aXNpdGVkIHRvIGVuc3VyZSB0aGUgcHJvcGVyIHJlZmVy ZW5jZSBpcyBtYWRlLg0KDQo+Pj4NCg0KPj4gW0ZhdGFpXSBBY2NlcHRlZCBhbmQgdXNlZCB0aGUg c2FtZSBhcHByb2FjaCBmb3IgZnJhbWV3b3JrIGRyYWZ0Lg0KDQo+Pg0KDQo+PiBncmVhdA0KDQo+ Pg0KDQo+Pg0KDQo+Pj4gLQ0KDQo+Pj4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkbml0cz91 cmw9aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFs aW5nLWc3MDl2My0wNC50eHQNCg0KPj4+IHNob3dzIHRoZXJlIGFyZSB1bnJlc29sdmVkIG5pdHMg dGhhdCBuZWVkIHRvIHJlc29sdmVkIC4NCg0KPj4NCg0KPj4NCg0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkbml0cz91cmw9aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtY2NhbXAt Z21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNS50eHQNCg0KPj4gc3RpbGwgc2hvd3MgYSB3YXJuaW5n LCBub3RhYmx5Og0KDQo+Pg0KDQo+PiAgICAgIChVc2luZyB0aGUgY3JlYXRpb24gZGF0ZSBmcm9t IFJGQzQzMjgsIHVwZGF0ZWQgYnkgdGhpcyBkb2N1bWVudCwgZm9yDQoNCj4+ICAgICAgUkZDNTM3 OCBjaGVja3M6IDIwMDUtMDEtMTcpDQoNCj4+DQoNCj4+ICAgLS0gVGhlIGRvY3VtZW50IHNlZW1z IHRvIGxhY2sgYSBkaXNjbGFpbWVyIGZvciBwcmUtUkZDNTM3OCB3b3JrLA0KDQpidXQgbWF5DQoN Cj4+ICAgICAgaGF2ZSBjb250ZW50IHdoaWNoIHdhcyBmaXJzdCBzdWJtaXR0ZWQgYmVmb3JlIDEw IE5vdmVtYmVyIDIwMDguDQoNCklmIHlvdQ0KDQo+PiAgICAgIGhhdmUgY29udGFjdGVkIGFsbCB0 aGUgb3JpZ2luYWwgYXV0aG9ycyBhbmQgdGhleSBhcmUgYWxsIHdpbGxpbmcNCg0KdG8gZ3JhbnQN Cg0KPj4gICAgICB0aGUgQkNQNzggcmlnaHRzIHRvIHRoZSBJRVRGIFRydXN0LCB0aGVuIHRoaXMg aXMgZmluZSwgYW5kIHlvdQ0KDQpjYW4gaWdub3JlDQoNCj4+ICAgICAgdGhpcyBjb21tZW50LiAg SWYgbm90LCB5b3UgbWF5IG5lZWQgdG8gYWRkIHRoZSBwcmUtUkZDNTM3OA0KDQpkaXNjbGFpbWVy Lg0KDQo+PiAgICAgIChTZWUgdGhlIExlZ2FsIFByb3Zpc2lvbnMgZG9jdW1lbnQgYXQNCg0KaHR0 cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvIGZvciBtb3JlIGluZm9ybWF0aW9uLikN Cg0KPj4NCg0KPiBbRmF0YWldIFdpbGwgdXBkYXRlIKGwQ29weXJpZ2h0IE5vdGljZaGxIHNlY3Rp b24uDQoNCg0KDQpva2F5DQoNCg0KDQo+Pg0KDQo+Pj4gSSdtIHVzaW5nIGxpbmUNCg0KPj4+IG51 bWJlcnMgZnJvbSB0aGlzIHVybCBpbiBteSBzdWJzZXF1ZW50IGNvbW1lbnRzLg0KDQo+Pj4NCg0K Pj4gWy4uLl0NCg0KPj4NCg0KPj4+IC0gU2VjdGlvbiAzLiAgUGVyaGFwcyBjb21iaW5lIHdpdGgg c2VjdGlvbiAxLg0KDQo+Pj4NCg0KPj4gW0ZhdGFpXSBBY2NlcHRlZCBhbmQgcmVmaW5lZC4NCg0K Pj4+DQoNCj4+DQoNCj4+IEkgZG9uJ3Qgc2VlIHdoZXJlIHRoaXMgc3VnZ2VzdGlvbiB3YXMgZm9s bG93ZWQsIGJ1dCB0aGF0J3Mgb2theSwgaXQgd2FzDQoNCj4+IGp1c3QgYSBzdWdnZXN0aW9uLg0K DQo+Pg0KDQo+IFtGYXRhaV0gT0suDQoNCj4+DQoNCj4+IFsuLi5dDQoNCj4+PiAtIFNlY3Rpb24g NTogYXNzdW1pbmcgdGhpcyBpcyBub3cgYSBuZXcgYy10eXBlIG5lZWQgdGV4dCBmb3IgdGhhdCwg YXMNCg0KPj4+IHdlbGwgYXMgdG8gZm9ybWFsbHkgZGVmaW5lZCB0aGUgZmllbGRzL2ZpZWxkIHNp emVzLg0KDQo+Pj4NCg0KPj4gW0ZhdGFpXSBBY2NlcHRlZCB0byBoYXZlIGEgbmV3IEMtVFlQRSBh bmQgdXBkYXRlZCB0aGUgdGV4dCBhY2NvcmRpbmdseS4NCg0KPj4NCg0KPj4gRm9ybWFsIGZpZWxk IGRlZmluaXRpb25zIGFyZSBtaXNzaW5nIGFuZCBuZWVkIHRvIGJlIGFkZGVkLg0KDQo+Pg0KDQoN Cg0KPiBbRmF0YWldIFRoZSBmb3JtYXQgaXMgdGhlIHNhbWUgYXMgUkZDNDMyOC4gRGlkIHlvdSBt ZWFuIHRoYXQgaXQNCg0KPiBuZWVkcyChsExlbmd0aKGxLCChsENsYXNzLU51baGxIGFuZCChsEMt VHlwZaGxPyBJZiB5ZXMsIEkgd2lsbCBhZGQNCg0KPiB0aGVtLiBJZiB5b3UgbWVhbiB0aGF0IGl0 IG5lZWRzIHRleHQgdG8gZGVmaW5lIGFsbCB0aGUgZmllbGRzLCBJDQoNCj4gdGhpbmsgdGhlIHRl eHQgaXMgYWxyZWFkeSB0aGVyZSAodGhlbiB0aGlzIGNvbW1lbnQgbWF5IGJlIHJlbGF0ZWQNCg0K PiB0byB5b3VyIG90aGVyIGNvbW1lbnRzIGJlbG93KS4NCg0KDQoNCkl0cyBpbXBvcnRhbnQgdG8g ZGlmZmVyZW50aWF0ZSB0aGUgc3ludGF4IChpLmUuLCBmb3JtYXQpIGZyb20gdGhlDQoNCnNlbWFu dGljcyAoaS5lLiwgdXNhZ2UpLiAgSG93IGFib3V0Og0KDQoNCg0KU2lnbmFsIFR5cGU6IDggYml0 cw0KDQogICBBcyBkZWZpbmVkIGluIFtSRkM0MzI4XSBTZWN0aW9uIDMuMi4xLCB3aXRoIHRoZSBm b2xsb3dpbmcgYWRkaXRpb25hbA0KDQp2YWx1ZXM6DQoNCiAgKGluc2VydCBsaW5lcyAyNjYtMjg1 KQ0KDQoNCg0KUmVzZXJ2ZWQ6IDggYml0cw0KDQogICBBcyBkZWZpbmVkIGluIFtSRkM0MzI4XSBT ZWN0aW9uIDMuMi41Lg0KDQoNCg0KVG9sZXJhbmNlOiAxNiBiaXRzDQoNCiAgIChpbnNlcnQgbGlu ZXMgMjk2LTI5OCkNCg0KDQoNCk5WQzogMTYgYml0cw0KDQogICBBcyBkZWZpbmVkIGluIFtSRkM0 MzI4XSBTZWN0aW9uIDMuMi4zLg0KDQoNCg0KTXVsdGlwbGllciAoTVQpOiAxNiBiaXRzDQoNCiAg IEFzIGRlZmluZWQgaW4gW1JGQzQzMjhdIFNlY3Rpb24gMy4yLjQuDQoNCg0KDQpCaXRfUmF0ZTog MzIgYml0cw0KDQogICAoaW5zZXJ0IGxpbmVzIDI5MC0yOTQpDQoNCg0KDQpUaGUgb3RoZXIgcGFy dHMsIGxpbmVzIDI4Ny0yODgsIDMwMC0zMTkgc2hvdWxkIGJlIG1lcmdlZCBpbnRvIHNlY3Rpb24g NS4xLg0KDQoNCg0KW0ZhdGFpXSBHb3QgaXQuIE9LIHRvIGFjY2VwdCB5b3VyIHN1Z2dlc3Rpb24g YW5kIHRyeSB0byB1cGRhdGUgdGhlIHRleHQgaW4gdGhpcyB3YXkuDQoNCg0KDQo+Pg0KDQo+PiBB bHNvIHRoZSBkcmFmdCBzYXlzOg0KDQo+Pg0KDQo+PiAgICBOb3RlIHRoYXQgdGhlIGVycm9yIHBy b2Nlc3Mgb24gdGhlIHRyYWZmaWMgcGFyYW1ldGVycyBNVVNUIGZvbGxvdyB0aGUNCg0KPj4gICAg cnVsZXMgZGVmaW5lZCBpbiBTZWN0aW9uIDYgb2YgW1JGQzQzMjhdLg0KDQo+Pg0KDQo+PiBHaXZl biB0aGUgZGlmZmVyZW50IGZpZWxkcywgc2hvdWxkbid0IGFueSBPVE4tVERNIHJlbGF0ZWQgdHJh ZmZpYw0KDQpwYXJhbWV0ZXIgcHJvY2Vzc2luZyBub3cgYmUgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50Pw0KDQo+Pg0KDQo+IFtGYXRhaV0gSSBqdXN0IHdhbnRlZCB0byBhdm9pZCB0aGUgb3Zlcmxh cHBlZCB0ZXh0IChhbG1vc3QgdGhlIHNhbWUNCg0KdGV4dCBhcyBSRkM0MzI4KS4gV2lsbCBhY2Nl cHQgeW91ciBzdWdnZXN0aW9uIHRvIGV4cGFuZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KDQo+DQoN Cj4gVGhlcmUgaXMgbm8gQWRzcGVjIGFzc29jaWF0ZWQgd2l0aCB0aGUgT1ROLVRETSBTRU5ERVJf VFNQRUMuIEVpdGhlcg0KDQo+IHRoZSBBZHNwZWMgaXMgb21pdHRlZCBvciBhbiBJbnQtc2VydiBB ZHNwZWMgd2l0aCB0aGUgRGVmYXVsdCBHZW5lcmFsDQoNCj4gQ2hhcmFjdGVyaXphdGlvbiBQYXJh bWV0ZXJzIGFuZCBHdWFyYW50ZWVkIFNlcnZpY2UgZnJhZ21lbnQgaXMgdXNlZCwNCg0KPiBzZWUg W1JGQzIyMTBdLg0KDQo+DQoNCj4gRm9yIGEgcGFydGljdWxhciBzZW5kZXIgaW4gYSBzZXNzaW9u LCB0aGUgY29udGVudHMgb2YgdGhlIEZMT1dTUEVDDQoNCj4gb2JqZWN0IHJlY2VpdmVkIGluIGEg UmVzdiBtZXNzYWdlIFNIT1VMRCBiZSBpZGVudGljYWwgdG8gdGhlIGNvbnRlbnRzDQoNCj4gb2Yg dGhlIFNFTkRFUl9UU1BFQyBvYmplY3QgcmVjZWl2ZWQgaW4gdGhlIGNvcnJlc3BvbmRpbmcgUGF0 aA0KDQo+IG1lc3NhZ2UuIElmIHRoZSBvYmplY3RzIGRvIG5vdCBtYXRjaCwgYSBSZXN2RXJyIG1l c3NhZ2Ugd2l0aCBhDQoNCj4gIlRyYWZmaWMgQ29udHJvbCBFcnJvci9CYWQgRmxvd3NwZWMgdmFs dWUiIGVycm9yIFNIT1VMRCBiZSBnZW5lcmF0ZWQuDQoNCj4NCg0KPiBJbnRlcm1lZGlhdGUgYW5k IGVncmVzcyBub2RlcyBNVVNUIHZlcmlmeSB0aGF0IHRoZSBub2RlIGl0c2VsZiwgYW5kDQoNCj4g dGhlIGludGVyZmFjZXMgb24gd2hpY2ggdGhlIExTUCB3aWxsIGJlIGVzdGFibGlzaGVkLCBjYW4g c3VwcG9ydCB0aGUNCg0KPiByZXF1ZXN0ZWQgU2lnbmFsIFR5cGUsIE5WQywgVG9sZXJhbmNlIGFu ZCBCaXRfUmF0ZSB2YWx1ZXMuIElmIHRoZQ0KDQo+IHJlcXVlc3RlZCB2YWx1ZShzKSBjYW5ub3Qg YmUgc3VwcG9ydGVkLCB0aGUgcmVjZWl2ZXIgbm9kZSBNVVNUDQoNCj4gZ2VuZXJhdGUgYSBQYXRo RXJyIG1lc3NhZ2Ugd2l0aCBhICJUcmFmZmljIENvbnRyb2wgRXJyb3IvU2VydmljZQ0KDQo+IHVu c3VwcG9ydGVkIiBpbmRpY2F0aW9uIChzZWUgW1JGQzIyMDVdKS4NCg0KPg0KDQo+IEluIGFkZGl0 aW9uLCBpZiB0aGUgTVQgZmllbGQgaXMgcmVjZWl2ZWQgd2l0aCBhIHplcm8gdmFsdWUsIHRoZSBu b2RlDQoNCj4gTVVTVCBnZW5lcmF0ZSBhIFBhdGhFcnIgbWVzc2FnZSB3aXRoIGEgIlRyYWZmaWMg Q29udHJvbCBFcnJvci9CYWQNCg0KPiBUc3BlYyB2YWx1ZSIgaW5kaWNhdGlvbiAoc2VlIFtSRkMy MjA1XSkuDQoNCj4NCg0KDQoNCklzIHRoaXMgYSBuZXcgc2VjdGlvbiwgcGVyaGFwcyA1LjM/DQoN Cg0KDQpbRmF0YWldIFllcy4gVHJ5IHRvIGFkZCBhIG5ldyBzZWN0aW9uIHRvIGRlc2NyaWJlIHdo YXQgeW91IHdhbnQuDQoNCg0KDQo+Pg0KDQo+Pj4NCg0KPj4gWy4uLl0NCg0KPj4+DQoNCj4+PiAt IExpbmVzIDMyMC0zMzYsMzM4LTM0NiBhcmUgZXNzZW50aWFsbHkgcmVwZWF0ZWQgaW4gc2VjdGlv bnMgNS4xIGFuZA0KDQo+Pj4gNS4yLCB3aHkgbm90IG1vdmUgdGhpcyB0ZXh0IGludG8gdGhlaXIg cmVzcGVjdGl2ZSBzZWN0aW9ucz8NCg0KPj4+DQoNCj4+IFtGYXRhaV0gQWNjZXB0ZWQgYW5kIHJl ZmluZWQgdGhlIHRleHQuDQoNCj4+DQoNCj4+DQoNCj4+IEkgZG9uJ3Qgc2VlIHdoZXJlIHRoaXMg c3VnZ2VzdGlvbiB3YXMgZm9sbG93ZWQuIEZvciBleGFtcGxlOg0KDQo+Pg0KDQo+PiAyODcgIElu IGNhc2Ugb2YgT0RVZmxleChDQlIpLCB0aGUgQml0X1JhdGUgYW5kIFRvbGVyYW5jZSBmaWVsZHMg TVVTVCBiZQ0KDQo+PiAyODggIHVzZWQgdG9nZXRoZXIgdG8gcmVwcmVzZW50IHRoZSBhY3R1YWwg YmFuZHdpZHRoIG9mIE9EVWZsZXgsIHdoZXJlOg0KDQo+Pg0KDQo+PiBhbmQNCg0KPj4NCg0KPj4g MzIzICBJbiBjYXNlIG9mIE9EVWZsZXgoQ0JSKSwgdGhlIGluZm9ybWF0aW9uIG9mIEJpdF9SYXRl IGFuZA0KDQpUb2xlcmFuY2UgaW4NCg0KPj4gMzI0ICB0aGUgT0RVZmxleCB0cmFmZmljIHBhcmFt ZXRlcnMgTVVTVCBiZSB1c2VkIHRvIGRldGVybWluZSB0aGUgdG90YWwNCg0KPj4gMzI1IG51bWJl ciBvZiB0cmlidXRhcnkgc2xvdHMgTiBpbiB0aGUgSE8gT0RVayBsaW5rIHRvIGJlIHJlc2VydmVk LiBIZXJlOg0KDQo+Pg0KDQo+IFtGYXRhaV0gU29ycnkgSSBzaG91bGQgbm90IHNheSChsEFjY2Vw dGVkIGFuZCByZWZpbmVkIHRoZSB0ZXh0LqGxDQoNCj4gbGFzdCB0aW1lLiBUaGV5IGFyZSBub3Qg cmVwZWF0ZWQuIGhlcmUsIHRoZSB0ZXh0IGp1c3QgZGVzY3JpYmVzIHRoZQ0KDQo+IG1lYW5pbmcg b2YgdGhlIGNvcnJlc3BvbmRpbmcgZmllbGRzIChhcyB3ZSBhbHdheXMgZG8pLCBzbyB0aGUgYWJv dmUNCg0KPiB0ZXh0IHNob3VsZCBiZSB0aGVyZSBpcnJlc3BlY3RpdmVseS4gU2VjdGlvbiA1LjEg JiBzZWN0aW9uIDUuMg0KDQo+IGRlc2NyaWJlIKGwaG93obEgd2l0aCBtb3JlIGRldGFpbCBpbmZv cm1hdGlvbiBpbmNsdWRpbmcgZm9ybXVsYXRpb24sDQoNCj4gVGFibGUgaW5mb3JtYXRpb24gYW5k IGV4YW1wbGUuDQoNCj4NCg0KSWYgdGhlIHRleHQgaW4gdGhlIGVhcmx5IHBhcnQgb2YgNSBpcyBy ZXZpc2VkIGFzIEkgc3VnZ2VzdCBhYm92ZSAoYW5kDQoNCnRoZSBvdGhlciBsaW5lcyBhcmUgbWVy Z2VkIGFzIHN1Z2dlc3RlZCBhYm92ZSkgdGhlbiB0aGlzIGNvbW1lbnQgd2lsbCBiZQ0KDQpyZXNv bHZlZC4NCg0KDQoNCltGYXRhaV0gT0suDQoNCg0KDQo+Pg0KDQo+Pj4NCg0KPj4+IC0gbGluZXMg NDQ1LTQ2ODogV2h5IG5vdCBqdXN0IGNhcnJ5ICJuIiBkaXJlY3RseT8NCg0KPj4+DQoNCj4+IFtG YXRhaV0gdG8gbWFrZSBpdCBjb25zaXN0ZW50IHdpdGggT0RVZmxleChDQlIpLg0KDQo+Pg0KDQo+ PiBHaXZlbiB0aGF0IHRoZSByZWNlbnQgZGVjaXNpb24gdG8gaGF2ZSBhbiBPVE4tVERNIHNwZWNp ZmljIHNldCBvZg0KDQo+PiB0cmFmZmljIHBhcmFtZXRlcnMsIGRvZXNuJ3QgaXQgbm93IG1ha2Ug c2Vuc2UgdG8ganVzdCBjYXJyeSBOIGRpcmVjdGx5Pw0KDQo+Pg0KDQo+IFtGYXRhaV0gTm8uIKGw TqGxIGNhbm5vdCBiZSB1c2VkIGZvciBPRFVmbGV4KENCUikgY2FzZS4NCg0KDQoNCkRvIHlvdSBy ZWFsbHkgbWVhbiAiY2Fubm90Ij8gIEkgbWF5IGJlIG1pc3Npbmcgc29tZXRoaW5nLCBidXQgaXQg d291bGQNCg0Kc2VlbSBsZXNzIGFtYmlndW91cy9wcm9uZSB0byBpbnRlcm9wIGlzc3VlcyBpZiBO IHdhcyBkaXJlY3RseSBjYXJyaWVkLg0KDQoNCg0KW0ZhdGFpXSBNeSBtaXN1bmRlcnN0YW5kaW5n IGhlcmUuIEkgdGhvdWdodCB5b3UgcHJvcG9zZWQgdG8gcmVwbGFjZSChsGJpdCByYXRlobEgd2l0 aCChsE6hsS4NCg0KDQoNCj4gSXQgaXMgYmV0dGVyDQoNCj4gdG8gaGF2ZSBjb25zaXN0ZW50IGZv cm1hdCBhbmQgdGhlIHNhbWUgbWVhbmluZyBvZiBvbmUgZmllbGQgZm9yIGJvdGgNCg0KPiBPRFVm bGV4KENCUikgYW5kIEdGUC4gVGhpcyBpcyB3aHkgd2UgaGF2ZSBzZWN0aW9uIDUuMSAmNS4yIHRv DQoNCj4gZGVzY3JpYmUgdGhlIGNvbXBsZXggc3R1ZmYuDQoNCj4NCg0KDQoNCkkgYWN0dWFsbHkg d2Fzbid0IHN1Z2dlc3RpbmcgdGhhdCBOIGJlIGNhcnJpZWQgaW4gdGhlIGJpdCByYXRlIGZpZWxk Lg0KDQpUaGUgYml0IHJhdGUgZmllbGQgY2FuIGVpdGhlciBiZSBzZXQgYXMgZGVzY3JpYmVkIG9y IHRvIHplcm8gKGkuZS4sDQoNCmlnbm9yZWQpLiAgQXQgdGhlIHRpbWUsIEkgd2FzIHRoaW5raW5n IGFib3V0IGNhcnJ5aW5nIE4gaW4gdGhlIHJlc2VydmVkDQoNCmZpZWxkLiBCdXQgcGVyaGFwcyB0 aGUgcmlnaHQgcGxhY2UgaXMgTVQsIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgcmlnaHQNCg0KKHdv dWxkIGFsd2F5cyBiZSAxIG90aGVyd2lzZSkuIEknbSBvcGVuIHRvIGVpdGhlci4uLg0KDQoNCg0K W0ZhdGFpXSBXaHkgbm90IGp1c3QgdXNlIKGwYml0IHJhdGWhsSBmaWVsZCB0byBjYXJyeSChsE6h sSBiZWNhdXNlIKGwTqGxIGltcGxpZXMgYml0IHJhdGU/IEkgYW0gT0sgaWYgeW91IGxpa2UgdG8g dXNlIGEgbmV3IGZpbGVkIChsaWtlIKGwVFMgTnVtYmVyobEpIHRvIG9jY3VweSB0aGUgcmVzZXJ2 ZWQgZmllbGQgZXZlbiB0aG91Z2ggdGhhdCBJIHByZWZlciB0aGUgb3JpZ2luYWwgYXBwcm9hY2gg KGllLiwgdXNlIKGwYml0IHJhdGWhsSBmaWVsZCB0byBjYXJyeSChsE6hsSkuDQoNCkJUVywgSSBk b26hr3QgdGhpbmsgTVQgaXMgdGhlIHJpZ2h0IHBsYWNlIChpdCB3aWxsIGNhdXNlIGFtYmlndWl0 eSBpZiBNVCBpcyB1c2VkIHRvIGluZGljYXRlIKGwVFMgTnVtYmVyobEpLg0KDQoNCg0KDQoNCj4+ DQoNCj4+IFsuLi5dDQoNCj4+DQoNCj4+Pg0KDQo+Pj4gLSBMaW5lIDU3NjogIlBhZGRlZCBiaXRz IiBzZWVtcyBvZmYsIGhvdyBhYm91dCAiUGFkIGJpdHMiIG9yICJQYWRkaW5nIiwNCg0KPj4NCg0K Pj4gQWdhaW4sIGhvdyBhYm91dCAiUGFkIGJpdHMiIG9yICJQYWRkaW5nIj8NCg0KPj4NCg0KPiBb RmF0YWldIE9LLiBTaG91bGQgdXNlIKGwUGFkIGJpdHOhsSBpbnN0ZWFkIG9mIKGwUGFkZGluZyBi aXRzobENCg0KDQoNCqGwUGFkIGJpdHOhsSBpdCBpcy4uLg0KDQoNCg0KPj4NCg0KPj4+IGFsc28g Yml0cyBhcmVuJ3QgcmVwcmVzZW50ZWQgaW4gbGFiZWwgZm9ybWF0IChsaW5lIDQ5NCkuLCBhbHNv ICJiZWhpbmQiDQoNCj4+PiAtLT4gImFmdGVyIg0KDQo+Pj4NCg0KPj4gW0ZhdGFpXSBBY2NlcHRl ZCBhbmQgdXBkYXRlZC4NCg0KPj4+DQoNCj4+DQoNCj4+IFsuLi5dDQoNCj4+DQoNCj4+Pg0KDQo+ Pj4gLSBMaW5lcyA2NTgtNjYwLiAgVGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiA0MzI4IGlzbid0 IGFjdHVhbGx5DQoNCj4+PiBwcmVzZW50ZWQgaW4gdGhlIHNlY3Rpb24gdGl0bGVkICJsYWJlbCBk aXN0cmlidXRpb24gcHJvY2VkdXJlcyIgKG9yDQoNCj4+PiAicnVsZXMiIGFzIHNlY3Rpb24gNC4y IGlzIGFjdHVhbGx5IHRpdGxlZCksIHNvIHRoaXMgcGFyYWdyYXBoIGRvZXNuJ3QNCg0KPj4+IG1h a2Ugc2Vuc2UuICBJIHN1Z2dlc3QgZWl0aGVyIChhKSBkZWZpbmluZyB0aGUgZnVsbCBzZXQgb2Yg cmVxdWlyZWQNCg0KPj4+IHByb2NlZHVyZXMgaW4gdGhpcyBkb2N1bWVudCwgb3IgKGIpIHJlZmVy cmluZyB0byB0aGUgInJlcXVpcmVkDQoNCj4+PiBwcm9jZXNzaW5nIGRlZmluZWQgaW4gW1JGQzQz MjhdIiBhbmQgb3RoZXIgcmZjcyBhcyBhcHByb3ByaWF0ZS4NCg0KPj4+DQoNCj4+IFtGYXRhaV0g QWNjZXB0ZWQgYW5kIHVwZGF0ZWQgYWNjb3JkaW5nbHkuDQoNCj4+Pg0KDQo+Pj4gLSBMaW5lcyA2 NjItNjY3OiB3aGF0IGFib3V0IGdlbmVyYXRpbmcgdXBzdHJlYW0sIHN1Z2dlc3RlZCwgbGFiZWwg c2V0LA0KDQo+Pj4gZXRjLiAgUGVyaGFwcyB5b3Ugc2hvdWxkIHJlcGhyYXNlIG11Y2ggaW50byBt b3JlIGdlbmVyYWwgcnVsZXMuDQoNCj4+Pg0KDQo+PiBbRmF0YWldIEFjY2VwdGVkIGFuZCB1cGRh dGVkIGFjY29yZGluZ2x5Lg0KDQo+Pj4NCg0KPj4NCg0KPj4gSSB0aGluayBzZWN0aW9uIDYuMiBz dGlsbCBuZWVkcyBhIGJpdCBvZiB3b3JrLg0KDQo+Pg0KDQo+PiBTbyBhcmUgdGhlcmUgcHJvY2Vk dXJlcyB0aGF0IGFuIGluZ3Jlc3MgbXVzdCBmb2xsb3c/DQoNCj4+IEZvciBleGFtcGxlOg0KDQo+ PiAtIFNldHRpbmcgb2YgZmllbGRzIGluIHRoZSBsYWJlbCByZXF1ZXN0IG9iamVjdCwgc3VjaCBh cyB0aGUgT1ROLVRETQ0KDQo+PiBTd2l0Y2hpbmcgVHlwZSBkZWZpbmVkIGluIFtPVE4tT1NQRl0u DQoNCj4+DQoNCj4+IFdoYXQgYWJvdXQgdGhlIGVncmVzcywgYXJlIHRoZXJlIGFueSBzcGVjaWFs IHByb2NlZHVyZXM/DQoNCj4+DQoNCj4+IFRoZSBmaW5hbCB0aHJlZSBwYXJhZ3JhcGhzIG9mIHRo ZSBzZWN0aW9uIGludHJvZHVjZSB1cHN0cmVhbSBiZWhhdmlvcnMNCg0KPj4gKmFmdGVyKiB5b3Un dmUgZGVzY3JpYmVkIHRoZSBkb3duc3RyZWFtIGJlaGF2aW9yIHdpdGhvdXQgc3BlY2lmaWNzIG9m DQoNCj4+IHRoZSBuZXcgdXBzdHJlYW0gYmVoYXZpb3IuIEFzIGEgZ2VuZXJhbCBydWxlIGFuZCBp biB0aGlzIGNhc2UgaW4NCg0KPj4gcGFydGljdWxhciwgSSByZWFsbHkgdGhpbmsgaXQgd291bGQg YmUgYmV0dGVyIHRvIGNvdmVyIHByb2NlZHVyZXMgaW4gdGhlDQoNCj4+IGZvbGxvd2luZyBvcmRl cg0KDQo+PiAtIEluZ3Jlc3MNCg0KPj4gLSBHZW5lcmljIHVwc3RyZWFtDQoNCj4+IC0gR2VuZXJp YyBkb3duc3RyZWFtDQoNCj4+IC0gRWdyZXNzDQoNCj4+DQoNCj4+IEFsc28sIGdlbmVyaWMgc3Rh dGVtZW50cyBzaG91bGQgbm90IHVzZSBjb25mb3JtYW5jZSBsYW5ndWFnZSwNCg0KPj4gcGFydGlj dWxhcmx5IHdoZW4gbW9yZSBkZXRhaWxlZCBydWxlcy9wcm9jZWR1cmVzLCB3aGljaCBpbmNsdWRl IHN1Y2gNCg0KPj4gbGFuZ3VhZ2UsIGZvbGxvdy4NCg0KPj4NCg0KPj4gSWYgeW91J2QgbGlrZSB3 ZSBjYW4gZGlzY3Vzcy9yZXZpZXcgZGV0YWlscyBvbiB0aGUgbGlzdCBvbmNlIHlvdSBoYXZlIGEN Cg0KPj4gcHJvcG9zZWQgcmV2aXNpb24uIChJIHNlZSBhIGJ1bmNoIG9mIG1vcmUgbWlub3IgY29t bWVudHMgb24gdGhpcw0KDQo+PiBzZWN0aW9uLCBidXQgZG9uJ3QgdGhpbmsgaXQgbWFrZXMgc2Vu c2UgdG8gZm9jdXMgb24gdGhlc2UgdW50aWwgdGhlIG1vcmUNCg0KPj4gbWFqb3IgY29tbWVudHMg YXJlIGFkZHJlc3NlZC4pDQoNCj4+DQoNCj4gW0ZhdGFpXSBXaWxsIHJlZmluZSB0aGUgdGV4dCBi YXNlZCBvbiB5b3VyIHN1Z2dlc3Rpb24uIERvIEkgbmVlZCB0bw0KDQo+IGNvcHkgc28gbXVjaCB0 ZXh0IGhlcmUgZm9yIHJldmlldz8NCg0KDQoNCkl0J3MgdXAgdG8geW91LCBidXQgcGVyc29uYWxs eSwgSSB0aGluayBpdCdzIGJldHRlciB0byBkaXNjdXNzIHRoZSB0ZXh0DQoNCm9uIHRoZSBsaXN0 IGZpcnN0IHJhdGhlciB0aGFuIHB1Ymxpc2hpbmcgYW5kIHRoZW4gZGlzY3Vzcy93b3Jkc21pdGgu DQoNCkJ1dCB0aGlzIGlzIGp1c3QgYSBwZXJzb25hbCBwcmVmZXJlbmNlLiAgRWl0aGVyIHdheSB3 b3Jrcy4gKGRyYWZ0DQoNCnJldmlzaW9uIG51bWJlcnMgYXJlIGNoZWFwIGFmdGVyIGFsbC4pDQoN Cg0KDQpbRmF0YWldIE9LLCBJIHdpbGwgaXNzdWUgYSBuZXcgdmVyc2lvbiB0byBjYXB0dXJlIGFs bCB0aGUgdXBkYXRlcyBhbmQgbWFrZSBpdCBlYXN5IGZvciBwZW9wbGUgdG8gY29udmVyZ2UuDQoN Cg0KDQo+Pg0KDQo+Pg0KDQo+PiBbLi4uXQ0KDQo+Pj4NCg0KPj4+IC0gTGluZXMgNjgyLTY4NTog V2hvIGlzIHRoaXMgbGVhcm5pbmcvaWRlbnRpZmljYXRpb24gYWNjb21wbGlzaGVkPw0KDQo+Pj4N Cg0KPj4gW0ZhdGFpXSBBY2NlcHRlZCBhbmQgdXBkYXRlZC4NCg0KPj4+DQoNCj4+PiAtIExpbmVz IDcwMy03MDQ6IElmIHRoaXMgaXMgdGhlIG5vcm1hdGl2ZSBzZWN0aW9uIGRlZmluaW5nIHJlcXVp cmVtZW50DQoNCj4+PiBwcm9jZXNzaW5nLCB0aGUgcHJvY2VkdXJlcyBuZWVkIHRvIGJlIHNwZWxs ZWQgb3V0IGZvciBhbGwgcmVxdWlyZWQNCg0KY2FzZXMuDQoNCj4+Pg0KDQo+PiBbRmF0YWldIEFj Y2VwdGVkIGFuZCB1cGRhdGVkIGFjY29yZGluZ2x5Lg0KDQo+Pj4NCg0KPj4+IC0gTGluZXMgNzA2 LTcwNzogSSB0aGluayB0aGlzIG5lZWRzIHRvIGJlIHJlcGhyYXNlZCB0byBiZSBjbGVhciB3aGF0 DQoNCj4+PiBiZWhhdmlvciBpcyByZXF1aXJlZCBmb3IgYSBub2RlIHRvIGJlIGNvbmZvcm1hbnQg d2l0aCB0aGlzIHNlbnRlbmNlLg0KDQo+Pj4NCg0KPj4gW0ZhdGFpXSBBY2NlcHRlZCBhbmQgcmVm aW5lZCBhY2NvcmRpbmdseS4NCg0KPj4+DQoNCj4+PiAtIExpbmVzIDcxMS03MTQ6IHdoeSAiU0hP VUxEIiB2cyAiTVVTVCI/DQoNCj4+Pg0KDQo+PiBbRmF0YWldIEFjY2VwdGVkIGFuZCB1cGRhdGVk Lg0KDQo+Pj4NCg0KPj4NCg0KPj4gSSdsbCBkZWZlciByZXNwb25zZXMgdG8gdGhlIGRpc2N1c3Np b24gb24gcHJpb3IgY29tbWVudC4NCg0KPj4NCg0KPj4+IC0gTGluZSA3MTI6IEJ5ICJpbnRlZ3Jp dHkgb2YgdGhlIGxhYmVsIiBkbyB5b3UgbWVhbiAiaWYgdGhlIGxhYmVsIGlzDQoNCj4+PiBhY2Nl cHRhYmxlIj8NCg0KPj4+DQoNCj4+IFtGYXRhaV0gWWVzLCBhbmQgdXBkYXRlZC4NCg0KPj4+DQoN Cj4+Pg0KDQo+Pj4gLSBMaW5lIDcyNTogQnkgInJlc2VydmVkIHJlc291cmNlIiBkbyB5b3UgbWVh biAiaW5kaWNhdGVkIHJlc291cmNlIj8NCg0KPj4+DQoNCj4+IFtGYXRhaV0gWWVzLCBhbmQgdXBk YXRlZC4NCg0KPj4+DQoNCj4+PiAtIExpbmUgNzI2OiBEb2VzICJkbyBub3QgbWF0Y2giIG1lYW4g ImluY29uc2lzdGVudCI/DQoNCj4+Pg0KDQo+PiBbRmF0YWldIFllcywgYW5kIHVwZGF0ZWQuDQoN Cj4+DQoNCj4+IFdSVCBsaW5lcyA2MjQtNjI3LCBJIHRoaW5rIHlvdSBzdGlsbCBuZWVkIGFkZGl0 aW9uYWwgc3BlY2lmaWNpdHkNCg0KPj4gZGlmZmVyZW50aWF0ZSB1cHN0cmVhbS9kb3duc3RyZWFt IHJlcXVpcmVkIGJlaGF2aW9yLiBQZXJoYXBzIHNvbWV0aGluZw0KDQo+PiBhbG9uZyB0aGUgbGlu ZXMgb2Y6DQoNCj4+DQoNCj4+ICAgICBXaGVuIGFuIHVwc3RyZWFtIG5vZGUgcmVjZWl2ZXMgYSBS ZXN2IG1lc3NhZ2UgY29udGFpbmluZyBhbg0KDQoNCg0Kcy9hbi9hDQoNCg0KDQo+PiAgICAgTEFC RUwgb2JqZWN0IHdpdGggYW4gT1ROLVRETSBsYWJlbCwgdGhlIG5vZGUgTVVTVCB2ZXJpZnkgdGhh dA0KDQo+PiAgICAgdGhlIGxhYmVsIGlzIGFjY2VwdGFibGUuIElmIHRoZSBsYWJlbCBpcyBub3Qg YWNjZXB0YWJsZSwgdGhlDQoNCj4+ICAgICBub2RlIE1VU1QgZ2VuZXJhdGUgYSBSZXN2RXJyIG1l c3NhZ2Ugd2l0aCBhICJSb3V0aW5nDQoNCj4+ICAgICBwcm9ibGVtL1VuYWNjZXB0YWJsZSBsYWJl bCB2YWx1ZSIgaW5kaWNhdGlvbi4gIFBlciBbUkZDMzQ3M10sDQoNCj4+ICAgICB0aGUgZ2VuZXJh dGVkIFJlc3ZFcnIgbWVzc2FnZSBNQVkgaW5jbHVkZSBhbg0KDQo+PiAgICAgQUNDRVBUQUJMRV9M QUJFTF9TRVQgb2JqZWN0LiAgV2l0aCB0aGUgZXhjZXB0aW9uIG9mIGxhYmVsDQoNCj4+ICAgICBz ZW1hbnRpY3MsIERvd25zdHJlYW0gbm9kZSBwcm9jZXNzaW5nIGEgcmVjZWl2ZWQgUmVzdkVycg0K DQo+PiAgICAgbWVzc2FnZXMgYW5kIG9mIEFDQ0VQVEFCTEVfTEFCRUxfU0VUIG9iamVjdHMgaXMg bm90IG1vZGlmaWVkDQoNCj4+ICAgICBieSB0aGlzIGRvY3VtZW50Lg0KDQo+Pg0KDQo+PiAgICAg U2ltaWxhcmx5LCB3aGVuIGEgZG93bnN0cmVhbSBub2RlIHJlY2VpdmVzIGEgUGF0aCBtZXNzYWdl DQoNCj4+ICAgICBjb250YWluaW5nIGFuIFVQU1RSRUFNX0xBQkVMIG9iamVjdCB3aXRoIGFuIE9U Ti1URE0gbGFiZWwsDQoNCj4+ICAgICB0aGUgbm9kZSBNVVNUIHZlcmlmeSB0aGF0IHRoZSBsYWJl bCBpcyBhY2NlcHRhYmxlLiBJZiB0aGUNCg0KPj4gICAgIGxhYmVsIGlzIG5vdCBhY2NlcHRhYmxl LCB0aGUgbm9kZSBNVVNUIGdlbmVyYXRlIGEgUGF0aEVycg0KDQo+PiAgICAgbWVzc2FnZSB3aXRo IGEgIlJvdXRpbmcgcHJvYmxlbS9VbmFjY2VwdGFibGUgbGFiZWwgdmFsdWUiDQoNCj4+ICAgICBp bmRpY2F0aW9uLiAgUGVyIFtSRkMzNDczXSwgdGhlIGdlbmVyYXRlZCBSZXN2RXJyIG1lc3NhZ2Ug TUFZDQoNCj4+ICAgICBpbmNsdWRlIGFuIEFDQ0VQVEFCTEVfTEFCRUxfU0VUIG9iamVjdC4gIFdp dGggdGhlIGV4Y2VwdGlvbg0KDQo+PiAgICAgb2YgbGFiZWwgc2VtYW50aWNzLCBEb3duc3RyZWFt IG5vZGUgcHJvY2Vzc2luZyByZWNlaXZlZA0KDQo+PiAgICAgUGF0aEVyciBtZXNzYWdlcyBhbmQg b2YgQUNDRVBUQUJMRV9MQUJFTF9TRVQgb2JqZWN0cyBpcyBub3QNCg0KPj4gICAgIG1vZGlmaWVk IGJ5IHRoaXMgZG9jdW1lbnQuDQoNCj4+DQoNCj4+ICAgICBBIHJlY2VpdmVkIGxhYmVsIFNIQUxM IGJlIGNvbnNpZGVyZWQgdW5hY2NlcHRhYmxlIHdoZW4gb25lIG9mDQoNCj4+ICAgICB0aGUgZm9s bG93aW5nIGNhc2VzIG9jY3VyczoNCg0KPj4NCg0KPj4gICAgIC0gVGhlIHJlY2VpdmVkIGxhYmVs IGRvZXNuJ3QgY29uZm9ybSB3aXRoIGxvY2FsIHBvbGljeS4NCg0KPj4NCg0KPiBbRmF0YWldIE9L LiBBY2NlcHQgeW91ciBwcm9wb3NlZCB0ZXh0Lg0KDQo+PiAgICAgLi4uDQoNCj4+DQoNCj4+Pg0K DQo+Pj4gLSBMaW5lIDczMCwgRHJvcCAiQXMiLg0KDQo+Pj4NCg0KPj4gW0ZhdGFpXSBBY2NlcHRl ZCBhbmQgdXBkYXRlZC4NCg0KPj4+DQoNCj4+PiAtIFNlY3Rpb24gNi40OiBNaXNzaW5nIGNvbmZv cm1hbmNlIGxhbmd1YWdlLg0KDQo+Pj4NCg0KPj4gW0ZhdGFpXSBXZW50IHRocm91Z2ggYW5kIHVw ZGF0ZWQuDQoNCj4+DQoNCj4+IE5ldyBsaW5lIDY2MDogICBUaGUgcHJvY2VkdXJlcyBhcmUgc2lt aWxhciB0byBzZWN0aW9uIDYgb2YgW1JGQzYzNDRdLg0KDQo+Pg0KDQo+PiBIZXJldG8sICBJZiB0 aGlzIGlzIHRoZSBub3JtYXRpdmUgc2VjdGlvbiBkZWZpbmluZyByZXF1aXJlZCBwcm9jZXNzaW5n LA0KDQo+PiB0aGUgcHJvY2VkdXJlcyBuZWVkIHRvIGJlIHNwZWxsZWQgb3V0IGZvciBhbGwgcmVx dWlyZWQgY2FzZXMgb3IgcmVmZXIgdG8NCg0KPj4gc3BlY2lmaWMgKGFuZCB1bm1vZGlmaWVkKSBw cm9jZWR1cmVzIHRvIGZvbGxvdyBpbiBhIHJlZmVyZW5jZSBkb2N1bWVudC4NCg0KPj4gU28gZWl0 aGVyIGRlZmluZSB0aGUgcHJvY2Vzc2luZyBvciBzYXkgcHJvY3VyZXMgZGVmaW5lZCBpbiA8YXBw cm9wcmlhdGUNCg0KPj4gcmVmZXJlbmNlPiBhcmUgZm9sbG93ZWQuDQoNCj4+DQoNCj4gW0ZhdGFp XSBPSywgSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gc2F5IKGwVGhlIHByb2NlZHVyZXMgTVVTVCBm b2xsb3cNCg0KPiBTZWN0aW9uIDUgb2YgW1JGQzYzNDRdLqGxDQoNCg0KDQpBcmUgdGhlcmUgYW55 IHByb2NlZHVyZXMgZGVmaW5lZCBpbiBzZWN0aW9uNi4zIHRoYXQgZGlmZmVyL2FkZCB0byA2MzQ0 Pw0KDQpJZiBJJ20gbm90IG1pc3Rha2VuLCB0aGUgb25seSB0aGluZyBpcyB0aGF0IE9EVWZsZXgg c2lnbmFsIHR5cGVzIGNhbm5vdA0KDQp1c2UgIm11bHRpcGxpY2F0aW9uIi4gKFBsZWFzZSBjb25m aXJtLikNCg0KDQoNCkFzc3VtaW5nIEknbSBjb3JyZWN0LCBob3cgYWJvdXQgcmVwbGFjaW5nIHRo ZSBjb250ZW50cyBvZiB0aGUgc2VjdGlvbg0KDQp3aXRoIHNvbWV0aGluZyBhbG9uZyB0aGUgbGlu ZXMgb2Y6DQoNCg0KDQogICBTdXBwb3J0IGZvciBWaXJ0dWFsIENvbmNhdGVuYXRpb24sIGFzIGRl ZmluZWQgYnkgW1JGQzYzNDRdLCBpcyBub3QNCg0KICAgbW9kaWZpZWQgYnkgdGhpcyBkb2N1bWVu dC4gV2l0aCB0aGUgZXhjZXB0aW9uIG9mIE9EVWZsZXggc2lnbmFsDQoNCiAgIHR5cGVzLCBzaWdu YWwgbXVsdGlwbGljYXRpb24gYXMgZGVmaW5lZCBpbiBbUkZDNjM0NF0gYW5kIFtSRkM0MzI4XS4N Cg0KDQoNCltGYXRhaV0gUmlnaHQuIFdpbGwgYWNjZXB0IHlvdXIgcHJvcG9zZWQgdGV4dC4NCg0K DQoNCj4+DQoNCj4+Pg0KDQo+Pj4gLSBMaW5lcyA3NTgtNzU5OiBUaGlzIHJlYWRzIGxpa2UgYW4g aW5mb3JtYXRpdmUgc3RhdGVtZW50LCBidXQgaW5jbHVkZXMNCg0KPj4+IGNvbmZvcm1hbmNlIGxh bmd1YWdlLiAgSG93IGRvZXMgYSBub2RlIGNvbmZvcm0/ICBJIHN1Z2dlc3QgcmVwaHJhc2luZyB0 bw0KDQo+Pj4gYmUgY2xlYXIuDQoNCj4+Pg0KDQo+PiBbRmF0YWldIEFjY2VwdGVkIGFuZCB1cGRh dGVkLg0KDQo+Pj4NCg0KPj4NCg0KPj4gSSB0aGluayB0aGlzIHNlY3Rpb24gc2hvdWxkIGJlIHJl dmlzZWQgdG8gZW5zdXJlIHRoYXQgdGhlDQoNCj4+IHJlc3BvbnNpYmlsaXRpZXMgb2YgZWFjaCB0 eXBlIG9mIHByb2Nlc3Npbmcgbm9kZSAoaW5ncmVzcywgdXBzdHJlYW0sDQoNCj4+IGRvd25zdHJl YW0sIGVncmVzcykgaXMgY2xlYXIuDQoNCj4+DQoNCj4+IEkgZ3Vlc3MsIHdlJ2xsIGhhdmUgYSB0 aHJlYWQgb24gdGhpcyBzZWN0aW9uIHRvby4uLg0KDQo+Pg0KDQo+IFtGYXRhaV0gV2lsbCByZWZp bmUgdGhlIHRleHQgYmFzZWQgb24geW91ciBzdWdnZXN0aW9uLg0KDQoNCg0KZ3JlYXQuDQoNCg0K DQo+Pg0KDQo+PiBbLi4uXQ0KDQo+Pg0KDQo+Pj4NCg0KPj4+IC0gU2VjdGlvbiA5LCBzaG91bGQg YWxzbyByZWZlcmVuY2UgNDMyOCBhbmQgY292ZXIgZGVsdGEgaW4gaW5mb3JtYXRpb24NCg0KPj4+ IGFuZCBhZGRlZCByaXNrcy4NCg0KPj4+DQoNCj4+IFtGYXRhaV0gQWNjZXB0ZWQgYW5kIHVwZGF0 ZWQuDQoNCj4+DQoNCj4+IFdlJ2xsIHNlZSBpZiB0aGlzIGlzIGVub3VnaCB0byBrZWVwIHRoZSBz ZWN1cml0eSByZXZpZXdlcnMgaGFwcHkuLi4NCg0KPj4NCg0KPj4+DQoNCj4+PiAtIFNlY3Rpb24g MTA6IFRoaXMgc2VjdGlvbiBuZWVkcyBzb21lIHdvcmsuICAoSSdtIGFzc3VtaW5nIHlvdXIgZmFt aWxpYXINCg0KPj4+IHdpdGggcmZjNTIyNikuDQoNCj4+Pg0KDQo+PiBbRmF0YWldIEFjY2VwdGVk IGFuZCB1cGRhdGVkLg0KDQo+Pj4NCg0KPj4NCg0KPj4gQmV0dGVyLCBidXQgeW91IHNob3VsZCBh dCBsZWFzdCByZWZlciB0byB0aGUgZXhpc3RpbmcgcmVnaXN0cmllcywNCg0Kd2hpY2ggYWxyZWFk eSBpbmNsdWRlcyBHLVBJRHMgKHNlZQ0KDQo+Pg0KDQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL2dtcGxzLXNpZy1wYXJhbWV0ZXJzL2dtcGxzLXNpZy1wYXJhbWV0ZXJzLnhtbCkNCg0K Pj4NCg0KPj4+IC0gSXMgaXQgdGltZSB0byBjcmVhdGUgYSAiU2lnbmFsIFR5cGUiIHJlZ2lzdHJ5 Pw0KDQo+Pj4NCg0KPj4gW0ZhdGFpXSBXZSBhcmUgbm90IHN1cmUsIGJlY2F1c2Ugbm8gIlNpZ25h bCBUeXBlcyIgaGF2ZSBiZWVuDQoNCnJlZ2lzdGVyZWQgaW4gdGhlIGV4aXN0aW5nIFJGQ3MgKGxp a2UgUkZDMzQ3MywgUkZDNDMyOC4uKS4NCg0KPj4+DQoNCj4+DQoNCj4+IEkgdGhpbmsgaW5jbHVk aW5nIGEgcmVxdWVzdCB0byBlc3RhYmxpc2ggc3VjaCBhIHJlZ2lzdHJ5IGluIHRoaXMNCg0KPj4g ZG9jdW1lbnQgd291bGQgYmUgdXNlZnVsLiAgSXMgYW55b25lIHVwIHRvIHByb3Bvc2luZyB0aGUg cmVxdWlzaXRlIHRleHQ/DQoNCj4+DQoNCj4gW0ZhdGFpXSBPSyB0byByZWdpc3RlciChsFNpZ25h bCBUeXBlobEuDQoNCg0KDQpJcyB0aGlzIGEgcXVlc3Rpb24gb3Igc3RhdGVtZW50Pw0KDQoNCg0K W0ZhdGFpXSBBIHN0YXRlbWVudC4gSSBhbSBwbGFubmluZyB0byByZWdpc3RlciChsFNpZ25hbCBU eXBlobEuIElmIGFueW9uZSBoYXMgYW55IG9waW5pb24gb24gdGhpcyBwb2ludCwgcGxlYXNlIHNo YXJlIHlvdXIgY29tbWVudHMgYmVmb3JlIEkgdXBkYXRlLg0KDQoNCg0KVGhhbmtzLA0KDQpMb3UN Cg0KDQoNCj4+DQoNCj4+ICAgIFZhbHVlICAgIFNpZ25hbCBUeXBlICAgICAgICAgICAgICAgICAg ICAgICAgICAgUmVmZXJlbmNlDQoNCj4+ICAgIC0tLS0tICAgIC0tLS0tLS0tLS0tICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0NCg0KPj4gICAgMCAgICAgICAgTm90IHNp Z25pZmljYW50ICAgICAgICAgICAgICAgICAgICAgIFt0aGlzIGRvY3VtZW50XQ0KDQo+PiAgICAx ICAgICAgICBPRFUxIChpLmUuLCAyLjUgR2JwcykgICAgICAgICAgICAgICAgIFt0aGlzIGRvY3Vt ZW50XQ0KDQo+PiAgICAyICAgICAgICBPRFUyIChpLmUuLCAxMCBHYnBzKSAgICAgICAgICAgICAg ICAgIFt0aGlzIGRvY3VtZW50XQ0KDQo+PiAgICAzICAgICAgICBPRFUzIChpLmUuLCA0MCBHYnBz KSAgICAgICAgICAgICAgICAgIFt0aGlzIGRvY3VtZW50XQ0KDQo+PiAgICA0ICAgICAgICBPRFU0 IChpLmUuLCAxMDAgR2JwcykgICAgICAgICAgICAgICAgIFt0aGlzIGRvY3VtZW50XQ0KDQo+PiAg ICA1ICAgICAgICBSZXNlcnZlZCAoZm9yIGZ1dHVyZSB1c2UpICAgICAgICAgICAgICBbdGhpcyBk b2N1bWVudF0NCg0KPj4gICAgNiAgICAgICAgT3B0aWNhbCBDaGFubmVsIChPY2gpIGF0IDIuNSBH YnBzICAgICAgIFt0aGlzIGRvY3VtZW50XQ0KDQo+PiAgICA3ICAgICAgICBPQ2ggYXQgMTAgR2Jw cyAgICAgICAgICAgICAgICAgICAgICBbdGhpcyBkb2N1bWVudF0NCg0KPj4gICAgOCAgICAgICAg T0NoIGF0IDQwIEdicHMgICAgICAgICAgICAgICAgICAgICAgW3RoaXMgZG9jdW1lbnRdDQoNCj4+ ICAgIDkgICAgICAgIE9DaCBhdCAxMDAgR2JwcyAgICAgICAgICAgICAgICAgICAgIFt0aGlzIGRv Y3VtZW50XQ0KDQo+PiAgICAxMCAgICAgICBPRFUwIChpLmUuLCAxLjI1IEdicHMpICAgICAgICAg ICAgICAgIFt0aGlzIGRvY3VtZW50XQ0KDQo+PiAgICAxMSAgICAgICBPRFUyZSAoaS5lLiwgMTBH YnBzIGZvciBGQzEyMDAgICAgICAgIFt0aGlzIGRvY3VtZW50XQ0KDQo+PiAgICAgICAgICAgICBh bmQgR0UgTEFOKQ0KDQo+PiAgICAxMn4xOSAgICBSZXNlcnZlZCAoZm9yIGZ1dHVyZSB1c2UpICAg ICAgICAgICAgIFt0aGlzIGRvY3VtZW50XQ0KDQo+PiAgICAyMCAgICAgICBPRFVmbGV4KENCUikg KGkuZS4sIDEuMjUqTiBHYnBzKSAgICAgIFt0aGlzIGRvY3VtZW50XQ0KDQo+PiAgICAyMSAgICAg ICBPRFVmbGV4KEdlbmVyaWMgRnJhbWluZyAgICAgICAgICAgIFt0aGlzIGRvY3VtZW50XQ0KDQo+ PiAgICAgICAgICAgICBQcm9jZWR1cmUtRnJhbWVkIChHRlAtRikpLA0KDQo+PiAgICAgICAgICAg ICByZXNpemFibGUgKGkuZS4sIDEuMjUqTiBHYnBzKQ0KDQo+PiAgICAyMiAgICAgICBPRFVmbGV4 KEdGUC1GKSwgbm9uIHJlc2l6YWJsZSAgICAgICAgW3RoaXMgZG9jdW1lbnRdDQoNCj4+ICAgICAg ICAgICAgIChpLmUuLCAxLjI1Kk4gR2JwcykNCg0KPj4gICAgICAgMjN+MjU1ICAgUmVzZXJ2ZWQg KGZvciBmdXR1cmUgdXNlKSAgICAgICAgICAgICBbdGhpcyBkb2N1bWVudF0NCg0KPj4NCg0KPj4N Cg0KPj4gVGhhbmtzLA0KDQo+PiBMb3UNCg0KPj4NCg0KPj4NCg0KPj4+IFRoYXQncyBpdCBvbiB0 aGlzIGRvY3VtZW50Lg0KDQo+Pj4NCg0KPj4+IExvdQ0KDQo+Pj4gLQ0KDQo+Pg0K --_000_F82A4B6D50F9464B8EBA55651F541CF835855DB5SZXEML552MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Lou,

 

Sorry for late response beca= use of my vacation.

 

Please see in-line below.

 

 

 

 

Best Regards

 

Fatai

 

-----Original Message----- From: Lou Berger [mailto:lberger@labn.net]
Sent: Friday, January 04, 2013 5:51 AM
To: Fatai Zhang
Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signal= ing-g709v3-04

 

 

Hi Fatai,<= /p>

    &nbs= p;    Happy new year.  Please see below for responses.<= o:p>

 

On 12/25/2012 3:33 AM, Fatai= Zhang wrote:

> =

> Hi Lou,

> =

> Please see in-line belo= w.

> =

> A new version will be i= ssued after all open issues are resolved.

> =

> =

> =

> =

> =

> Best Regards=

> =

> Fatai=

> =

> =

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

>> From: Lou Berger [m= ailto:lberger@labn.net]

>> Sent: Thursday, Dec= ember 20, 2012 10:12 PM

>> To: Fatai Zhang

>> Cc: CCAMP; draft-ie= tf-ccamp-gmpls-signaling-g709v3@tools.ietf.org

>> Subject: Re: =B4=F0=B8=B4: [CCAMP] WG Last Call comments on

draft-ietf-ccamp-gmpls-signa= ling-g709v3-04

>> 

>> Fatai/Authors,=

>>    &= nbsp;     Thank you for the mail, and sorry about = my delayed response. BTW

>> please feel free to= continue discussing the remaining open issues on the

>> list and reaching c= losure on the list (on specific text/resolutions)

>> prior to publishing= the next rev.

>> 

>> Please see below fo= r inline responses.

>> 

>> On 12/7/2012 4:53 A= M, Fatai Zhang wrote:

>>> Hi Lou,

>>> 

>>> Please see how = the LC comments addressed below.

>>> 

>>> Best Regards

>>> 

>>> Fatai

>>> 

>>> 

>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----

>>> =B7=A2=BC=FE=C8=CB: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] =B4=FA=B1=ED

Lou Berger=

>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10= =D4=C222=C8=D5 10:01

>>> =CA=D5=BC=FE=C8=CB: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org

>>> =D6=F7=CC=E2: = [CCAMP] WG Last Call comments on

draft-ietf-ccamp-gmpls-signa= ling-g709v3-04

>>> 

>>> Authors,

>>>  &nbs= p;  I have the following LC comments:

>>> 

>>> General comment= s:

>>> 

>>> - This document= also needs some addition work on conformance language.

>>> I'll try to poi= nt out cases in the detailed comments below.

>>> 

>> [Fatai] OK. Checked= and refined based on your detailed comments.

>>> 

>> 

>> I think this rev is= an improvement, but there's still more work needed.

>> I have made some sp= ecific comments/suggestions below.

>> 

>>> - Section 5 ess= entially defines a new set of traffic parameters.  Given

>>> the changes, wh= y not ask for a new C-TYPE and not worry about [RFC4328]<= /p>

>>> compatibility/d= escription?

>>> 

>> [Fatai] Accepted to= have a new C-TYPE and updated the text accordingly.

>>> 

>> 

>> Okay.

>> 

>>> Detailed editor= ial and technical comments:

>>> 

>>> - Please verify= that abbreviations are defined before being used .

>>> There are a num= ber of these.

>>> 

>> [Fatai] Went throug= h and updated.

>> 

>> thanks.<= /span>

>> 

>>> 

>>> - Please use a = consistent decimal representation (sometimes commas are

>>> used other time= s periods)

>>> 

>> [Fatai] OK. Commas = are used.

>> 

>> great, although a q= uick skim finds:

>> s/1,301.683.217/1,3= 01,683.217

>> 

>> 

>> 

>>> 

>>> - the reference= s [G709-v1] and [G709-v3] each actually refer to multiple=

>>> documents, each= documented needs to have it's own (correct) reference,

>>> i.g., [G709-v1]= and [G709-v1a1]. The document text will need to be

>>> revisited to en= sure the proper reference is made.

>>> 

>> [Fatai] Accepted an= d used the same approach for framework draft.

>> 

>> great

>> 

>> 

>>> -

>>> 

http://tools.ietf.org/idnits= ?url=3Dhttp://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-04.= txt

>>> shows there are= unresolved nits that need to resolved .

>> 

>> 

http://tools.ietf.org/idnits= ?url=3Dhttp://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-05.= txt

>> still shows a warni= ng, notably:

>> 

>>   &n= bsp;  (Using the creation date from RFC4328, updated by this document,= for

>>   &n= bsp;  RFC5378 checks: 2005-01-17)

>> 

>>   -- The = document seems to lack a disclaimer for pre-RFC5378 work,=

but may

>>   &n= bsp;  have content which was first submitted before 10 November 2008.<= o:p>

If you

>>   &n= bsp;  have contacted all the original authors and they are all willing=

to grant

>>   &n= bsp;  the BCP78 rights to the IETF Trust, then this is fine, and you

can ignore=

>>   &n= bsp;  this comment.  If not, you may need to add the pre-RFC5378<= o:p>

disclaimer.

>>   &n= bsp;  (See the Legal Provisions document at

http://trustee.ietf.org/lice= nse-info for more information.)

>> 

> [Fatai] Will update =A1= =B0Copyright Notice=A1=B1 section.

 

okay

 

>> 

>>> I'm using line<= o:p>

>>> numbers from th= is url in my subsequent comments.

>>> 

>> [...]

>> 

>>> - Section 3.&nb= sp; Perhaps combine with section 1.

>>> 

>> [Fatai] Accepted an= d refined.

>>> 

>> 

>> I don't see where t= his suggestion was followed, but that's okay, it was

>> just a suggestion.<= o:p>

>> 

> [Fatai] OK.<= /span>

>> 

>> [...]

>>> - Section 5: as= suming this is now a new c-type need text for that, as

>>> well as to form= ally defined the fields/field sizes.

>>> 

>> [Fatai] Accepted to= have a new C-TYPE and updated the text accordingly.

>> 

>> Formal field defini= tions are missing and need to be added.

>> 

 

> [Fatai] The format is t= he same as RFC4328. Did you mean that it

> needs =A1=B0Length=A1=B1, = =A1=B0Class-Num=A1=B1 and = =A1=B0C-Type=A1=B1= ? If yes, I will add

> them. If you mean that = it needs text to define all the fields, I

> think the text is alrea= dy there (then this comment may be related

> to your other comments = below).

 

Its important to differentia= te the syntax (i.e., format) from the

semantics (i.e., usage).&nbs= p; How about:

 

Signal Type: 8 bits

   As defined in [= RFC4328] Section 3.2.1, with the following additional

values:

  (insert lines 266-285= )

 

Reserved: 8 bits<= /span>

   As defined in [= RFC4328] Section 3.2.5.

 

Tolerance: 16 bits

   (insert lines 2= 96-298)

 

NVC: 16 bits

   As defined in [= RFC4328] Section 3.2.3.

 

Multiplier (MT): 16 bits

   As defined in [= RFC4328] Section 3.2.4.

 

Bit_Rate: 32 bits=

   (insert lines 2= 90-294)

 

The other parts, lines 287-2= 88, 300-319 should be merged into section 5.1.

&= nbsp;

[Fat= ai] Got it. OK to accept your suggestion and try to update the text in this= way.

 

>> 

>> Also the draft says= :

>> 

>>    N= ote that the error process on the traffic parameters MUST follow the

>>    r= ules defined in Section 6 of [RFC4328].

>> 

>> Given the different= fields, shouldn't any OTN-TDM related traffic

parameter processing now be = defined in this document?

>> 

> [Fatai] I just wanted t= o avoid the overlapped text (almost the same

text as RFC4328). Will accep= t your suggestion to expand the text as follows:

> =

> There is no Adspec asso= ciated with the OTN-TDM SENDER_TSPEC. Either

> the Adspec is omitted o= r an Int-serv Adspec with the Default General

> Characterization Parame= ters and Guaranteed Service fragment is used,

> see [RFC2210].

> =

> For a particular sender= in a session, the contents of the FLOWSPEC

> object received in a Re= sv message SHOULD be identical to the contents

> of the SENDER_TSPEC obj= ect received in the corresponding Path

> message. If the objects= do not match, a ResvErr message with a

> "Traffic Control E= rror/Bad Flowspec value" error SHOULD be generated.<= /p>

> =

> Intermediate and egress= nodes MUST verify that the node itself, and

> the interfaces on which= the LSP will be established, can support the

> requested Signal Type, = NVC, Tolerance and Bit_Rate values. If the

> requested value(s) cann= ot be supported, the receiver node MUST

> generate a PathErr mess= age with a "Traffic Control Error/Service

> unsupported" indic= ation (see [RFC2205]).

> =

> In addition, if the MT = field is received with a zero value, the node

> MUST generate a PathErr= message with a "Traffic Control Error/Bad

> Tspec value" indic= ation (see [RFC2205]).

> =

 

Is this a new section, perha= ps 5.3?

 

[Fat= ai] Yes. Try to add a new section to describe what you want.

&= nbsp;

>> 

>>> 

>> [...]

>>> 

>>> - Lines 320-336= ,338-346 are essentially repeated in sections 5.1 and

>>> 5.2, why not mo= ve this text into their respective sections?

>>> 

>> [Fatai] Accepted an= d refined the text.

>> 

>> 

>> I don't see where t= his suggestion was followed. For example:

>> 

>> 287  In case o= f ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be=

>> 288  used toge= ther to represent the actual bandwidth of ODUflex, where:=

>> 

>> and

>> 

>> 323  In case o= f ODUflex(CBR), the information of Bit_Rate and

Tolerance in

>> 324  the ODUfl= ex traffic parameters MUST be used to determine the total=

>> 325 number of tribu= tary slots N in the HO ODUk link to be reserved. Here:

>> 

> [Fatai] Sorry I should = not say =A1=B0Accepted and refined the text.=A1=B1

> last time. They are not= repeated. here, the text just describes the

> meaning of the correspo= nding fields (as we always do), so the above

> text should be there ir= respectively. Section 5.1 & section 5.2

> describe =A1=B0how=A1=B1 with more detail in= formation including formulation,

> Table information and e= xample.

> =

If the text in the early par= t of 5 is revised as I suggest above (and

the other lines are merged a= s suggested above) then this comment will be

resolved.<= /p>

 

[Fat= ai] OK.=

&= nbsp;

>> 

>>> 

>>> - lines 445-468= : Why not just carry "n" directly?

>>> 

>> [Fatai] to make it = consistent with ODUflex(CBR).

>> 

>> Given that the rece= nt decision to have an OTN-TDM specific set of

>> traffic parameters,= doesn't it now make sense to just carry N directly?

>> 

> [Fatai] No. =A1=B0N=A1=B1 cannot be used for= ODUflex(CBR) case.

 

Do you really mean "can= not"?  I may be missing something, but it would=

seem less ambiguous/prone to= interop issues if N was directly carried.

 

[Fat= ai] My misunderstanding here. I thought you proposed to replace =A1=B0bit = rate=A1=B1= with =A1=B0N=A1=B1.

&= nbsp;

> It is better=

> to have consistent form= at and the same meaning of one field for both

> ODUflex(CBR) and GFP. T= his is why we have section 5.1 &5.2 to

> describe the complex st= uff.

> =

 

I actually wasn't suggesting= that N be carried in the bit rate field.

The bit rate field can eithe= r be set as described or to zero (i.e.,

ignored).  At the time,= I was thinking about carrying N in the reserved

field. But perhaps the right= place is MT, if my understanding is right

(would always be 1 otherwise= ). I'm open to either...

 

[Fat= ai] Why not just use =A1=B0bit = rate=A1=B1= field to carry =A1=B0N=A1=B1 because =A1=B0N=A1=B1 implies bit rate? I am OK if you like to use a new filed (like TS Number=A1=B1) to occupy the reserved field even though that I prefer the original approa= ch (ie., use =A1=B0bit = rate=A1=B1= field to carry =A1=B0N=A1=B1).

BTW,= I don=A1=AFt think MT is the right place (it will cause ambiguity if MT is used to indicate =A1=B0TS Number=A1=B1).

 

&= nbsp;

>> 

>> [...]

>> 

>>> 

>>> - Line 576: &qu= ot;Padded bits" seems off, how about "Pad bits" or "Pad= ding",

>> 

>> Again, how about &q= uot;Pad bits" or "Padding"?

>> 

> [Fatai] OK. Should use = = =A1=B0Pad bits=A1=B1= instead of =A1=B0Padding bits=A1=B1

 

=A1=B0Pad bits=A1=B1 it is..= .

 

>> 

>>> also bits aren'= t represented in label format (line 494)., also "behind"

>>> --> "af= ter"

>>> 

>> [Fatai] Accepted an= d updated.

>>> 

>> 

>> [...]

>> 

>>> 

>>> - Lines 658-660= .  The normative language in 4328 isn't actually

>>> presented in th= e section titled "label distribution procedures" (or

>>> "rules&quo= t; as section 4.2 is actually titled), so this paragraph doesn't=

>>> make sense.&nbs= p; I suggest either (a) defining the full set of required=

>>> procedures in t= his document, or (b) referring to the "required

>>> processing defi= ned in [RFC4328]" and other rfcs as appropriate.

>>> 

>> [Fatai] Accepted an= d updated accordingly.

>>> 

>>> - Lines 662-667= : what about generating upstream, suggested, label set,

>>> etc.  Perh= aps you should rephrase much into more general rules.

>>> 

>> [Fatai] Accepted an= d updated accordingly.

>>> 

>> 

>> I think section 6.2= still needs a bit of work.

>> 

>> So are there proced= ures that an ingress must follow?

>> For example:

>> - Setting of fields= in the label request object, such as the OTN-TDM

>> Switching Type defi= ned in [OTN-OSPF].

>> 

>> What about the egre= ss, are there any special procedures?

>> 

>> The final three par= agraphs of the section introduce upstream behaviors

>> *after* you've desc= ribed the downstream behavior without specifics of

>> the new upstream be= havior. As a general rule and in this case in

>> particular, I reall= y think it would be better to cover procedures in the

>> following order

>> - Ingress

>> - Generic upstream<= o:p>

>> - Generic downstrea= m

>> - Egress=

>> 

>> Also, generic state= ments should not use conformance language,

>> particularly when m= ore detailed rules/procedures, which include such

>> language, follow.

>> 

>> If you'd like we ca= n discuss/review details on the list once you have a

>> proposed revision. = (I see a bunch of more minor comments on this

>> section, but don't = think it makes sense to focus on these until the more

>> major comments are = addressed.)

>> 

> [Fatai] Will refine the= text based on your suggestion. Do I need to

> copy so much text here = for review?

 

It's up to you, but personal= ly, I think it's better to discuss the text

on the list first rather tha= n publishing and then discuss/wordsmith.

But this is just a personal = preference.  Either way works. (draft

revision numbers are cheap a= fter all.)

 

[Fat= ai] OK, I will issue a new version to capture all the updates and make it e= asy for people to converge.

&= nbsp;

>> 

>> 

>> [...]

>>> 

>>> - Lines 682-685= : Who is this learning/identification accomplished?

>>> 

>> [Fatai] Accepted an= d updated.

>>> 

>>> - Lines 703-704= : If this is the normative section defining requirement

>>> processing, the= procedures need to be spelled out for all required

cases.

>>> 

>> [Fatai] Accepted an= d updated accordingly.

>>> 

>>> - Lines 706-707= : I think this needs to be rephrased to be clear what

>>> behavior is req= uired for a node to be conformant with this sentence.

>>> 

>> [Fatai] Accepted an= d refined accordingly.

>>> 

>>> - Lines 711-714= : why "SHOULD" vs "MUST"?

>>> 

>> [Fatai] Accepted an= d updated.

>>> 

>> 

>> I'll defer response= s to the discussion on prior comment.

>> 

>>> - Line 712: By = "integrity of the label" do you mean "if the label is

>>> acceptable"= ;?

>>> 

>> [Fatai] Yes, and up= dated.

>>> 

>>> 

>>> - Line 725: By = "reserved resource" do you mean "indicated resource"?

>>> 

>> [Fatai] Yes, and up= dated.

>>> 

>>> - Line 726: Doe= s "do not match" mean "inconsistent"?=

>>> 

>> [Fatai] Yes, and up= dated.

>> 

>> WRT lines 624-627, = I think you still need additional specificity

>> differentiate upstr= eam/downstream required behavior. Perhaps something

>> along the lines of:=

>> 

>>   &n= bsp; When an upstream node receives a Resv message containing an=

 

s/an/a

 

>>   &n= bsp; LABEL object with an OTN-TDM label, the node MUST verify that

>>   &n= bsp; the label is acceptable. If the label is not acceptable, the

>>   &n= bsp; node MUST generate a ResvErr message with a "Routing

>>   &n= bsp; problem/Unacceptable label value" indication.  Per [RFC3473]= ,

>>   &n= bsp; the generated ResvErr message MAY include an

>>   &n= bsp; ACCEPTABLE_LABEL_SET object.  With the exception of label

>>   &n= bsp; semantics, Downstream node processing a received ResvErr

>>   &n= bsp; messages and of ACCEPTABLE_LABEL_SET objects is not modified

>>   &n= bsp; by this document.

>> 

>>   &n= bsp; Similarly, when a downstream node receives a Path message

>>   &n= bsp; containing an UPSTREAM_LABEL object with an OTN-TDM label,<= /span>

>>   &n= bsp; the node MUST verify that the label is acceptable. If the

>>   &n= bsp; label is not acceptable, the node MUST generate a PathErr

>>   &n= bsp; message with a "Routing problem/Unacceptable label value"

>>   &n= bsp; indication.  Per [RFC3473], the generated ResvErr message MAY

>>   &n= bsp; include an ACCEPTABLE_LABEL_SET object.  With the exception<= /o:p>

>>   &n= bsp; of label semantics, Downstream node processing received

>>   &n= bsp; PathErr messages and of ACCEPTABLE_LABEL_SET objects is not=

>>   &n= bsp; modified by this document.

>> 

>>   &n= bsp; A received label SHALL be considered unacceptable when one of

>>   &n= bsp; the following cases occurs:

>> 

>>   &n= bsp; - The received label doesn't conform with local policy.

>> 

> [Fatai] OK. Accept your= proposed text.

>>   &n= bsp; ...

>> 

>>> 

>>> - Line 730, Dro= p "As".

>>> 

>> [Fatai] Accepted an= d updated.

>>> 

>>> - Section 6.4: = Missing conformance language.

>>> 

>> [Fatai] Went throug= h and updated.

>> 

>> New line 660: =   The procedures are similar to section 6 of [RFC6344].

>> 

>> Hereto,  If th= is is the normative section defining required processing,=

>> the procedures need= to be spelled out for all required cases or refer to

>> specific (and unmod= ified) procedures to follow in a reference document.

>> So either define th= e processing or say procures defined in <appropriate

>> reference> are f= ollowed.

>> 

> [Fatai] OK, I think it = is better to say = =A1=B0The procedures MUST follow

> Section 5 of [RFC6344].= = =A1=B1

 

Are there any procedures def= ined in section6.3 that differ/add to 6344?

If I'm not mistaken, the onl= y thing is that ODUflex signal types cannot

use "multiplication&quo= t;. (Please confirm.)

 

Assuming I'm correct, how ab= out replacing the contents of the section

with something along the lin= es of:

 

   Support for Vir= tual Concatenation, as defined by [RFC6344], is not

   modified by thi= s document. With the exception of ODUflex signal

   types, signal m= ultiplication as defined in [RFC6344] and [RFC4328].

 

[Fat= ai] Right. Will accept your proposed text.

 

>> 

>>> 

>>> - Lines 758-759= : This reads like an informative statement, but includes<= /p>

>>> conformance lan= guage.  How does a node conform?  I suggest rephrasing to

>>> be clear.<= /o:p>

>>> 

>> [Fatai] Accepted an= d updated.

>>> 

>> 

>> I think this sectio= n should be revised to ensure that the

>> responsibilities of= each type of processing node (ingress, upstream,

>> downstream, egress)= is clear.

>> 

>> I guess, we'll have= a thread on this section too...

>> 

> [Fatai] Will refine the= text based on your suggestion.

 

great.

 

>> 

>> [...]

>> 

>>> 

>>> - Section 9, sh= ould also reference 4328 and cover delta in information

>>> and added risks= .

>>> 

>> [Fatai] Accepted an= d updated.

>> 

>> We'll see if this i= s enough to keep the security reviewers happy...

>> 

>>> 

>>> - Section 10: T= his section needs some work.  (I'm assuming your familiar

>>> with rfc5226).<= o:p>

>>> 

>> [Fatai] Accepted an= d updated.

>>> 

>> 

>> Better, but you sho= uld at least refer to the existing registries,

which already includes G-PID= s (see

>> 

http://www.iana.org/assignme= nts/gmpls-sig-parameters/gmpls-sig-parameters.xml)

>> 

>>> - Is it time to= create a "Signal Type" registry?

>>> 

>> [Fatai] We are not = sure, because no "Signal Types" have been

registered in the existing R= FCs (like RFC3473, RFC4328..).

>>> 

>> 

>> I think including a= request to establish such a registry in this

>> document would be u= seful.  Is anyone up to proposing the requisite text?

>> 

> [Fatai] OK to register = = =A1=B0Signal Type=A1=B1.

 

Is this a question or statem= ent?

 

[Fat= ai] A statement. I am planning to register =A1=B0Sign= al Type=A1=B1. If anyone has any opinion on this point, please share your comments before= I update.

&= nbsp;

Thanks,

Lou

 

>> 

>>    V= alue    Signal Type       = ;            &n= bsp;       Reference

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

>>    0=         Not significant   = ;            &n= bsp;      [this document]

>>    1=         ODU1 (i.e., 2.5 Gbps)  = ;            &n= bsp;  [this document]

>>    2=         ODU2 (i.e., 10 Gbps)  =             &nb= sp;   [this document]

>>    3=         ODU3 (i.e., 40 Gbps)  =             &nb= sp;   [this document]

>>    4=         ODU4 (i.e., 100 Gbps)  = ;            &n= bsp;  [this document]

>>    5=         Reserved (for future use) &= nbsp;            [th= is document]

>>    6=         Optical Channel (Och) at 2.5 Gbp= s       [this document]

>>    7=         OCh at 10 Gbps   =             &nb= sp;      [this document]

>>    8=         OCh at 40 Gbps   =             &nb= sp;      [this document]

>>    9=         OCh at 100 Gbps   = ;            &n= bsp;     [this document]

>>    1= 0       ODU0 (i.e., 1.25 Gbps)  &nb= sp;            = [this document]

>>    1= 1       ODU2e (i.e., 10Gbps for FC1200 &= nbsp;      [this document]

>>   &n= bsp;         and GE LAN)=

>>    1= 2~19    Reserved (for future use)    &nb= sp;        [this document]

>>    2= 0       ODUflex(CBR) (i.e., 1.25*N Gbps) = ;     [this document]

>>    2= 1       ODUflex(Generic Framing  &n= bsp;         [this document]

>>   &n= bsp;         Procedure-Framed (GFP-= F)),

>>   &n= bsp;         resizable (i.e., 1.25*= N Gbps)

>>    2= 2       ODUflex(GFP-F), non resizable &n= bsp;      [this document]

>>   &n= bsp;         (i.e., 1.25*N Gbps)

>>   &n= bsp;   23~255   Reserved (for future use)  &n= bsp;          [this document]<= o:p>

>> 

>> 

>> Thanks,<= /span>

>> Lou

>> 

>> 

>>> That's it on th= is document.

>>> 

>>> Lou<= /span>

>>> -

>> 

--_000_F82A4B6D50F9464B8EBA55651F541CF835855DB5SZXEML552MBXchi_-- From ggrammel@juniper.net Tue Jan 15 08:33:09 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBCA21F8623 for ; Tue, 15 Jan 2013 08:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.475 X-Spam-Level: *** X-Spam-Status: No, score=3.475 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 nIZpSoLG4K3Y for ; Tue, 15 Jan 2013 08:33:07 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8B721F8558 for ; Tue, 15 Jan 2013 08:33:07 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUPWEw+bFSz5egMolmtNIOV47QDjkJ3gk@postini.com; Tue, 15 Jan 2013 08:33:07 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Jan 2013 08:29:46 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 15 Jan 2013 08:29:45 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 15 Jan 2013 08:31:36 -0800 Received: from mail257-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 Jan 2013 16:29:37 +0000 Received: from mail257-va3 (localhost [127.0.0.1]) by mail257-va3-R.bigfish.com (Postfix) with ESMTP id 199731A00231 for ; Tue, 15 Jan 2013 16:28:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -30 X-BigFish: PS-30(zzbb2dI98dI9371Ic89bhd6eah168aJ148cI542I1432I4015I14ffIzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL18602eh8275bh8275dhz2dh2a8h668h839h941hd25hf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail257-va3 (localhost.localdomain [127.0.0.1]) by mail257-va3 (MessageSwitch) id 1358267330460061_10289; Tue, 15 Jan 2013 16:28:50 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.254]) by mail257-va3.bigfish.com (Postfix) with ESMTP id 5AB0513C0091; Tue, 15 Jan 2013 16:28:50 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 Jan 2013 16:28:43 +0000 Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.8.162]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0257.004; Tue, 15 Jan 2013 16:28:42 +0000 From: Gert Grammel To: Daniele Ceccarelli , Lou Berger Thread-Topic: [CCAMP] Overlay model framework and context Thread-Index: AQHN3pwCHEOpWQ1fgUqGNU71PXGD15ghwmgAgAAOsACAAALngIAAApeAgCjlR1A= Date: Tue, 15 Jan 2013 16:28:41 +0000 Message-ID: <305443B66F0CD946A3107753337A03111311938B@CH1PRD0511MB431.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE48042C3B@ESESSMB301.ericsson.se> <50CF764E.603@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045007@ESESSMB301.ericsson.se> <50D248B8.1090506@labn.net> <4A1562797D64E44993C5CBF38CF1BE480456A7@ESESSMB301.ericsson.se> <50D32320.3010707@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045B14@ESESSMB301.ericsson.se> <50D331E1.5000703@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045BBA@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48045BBA@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.50] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework and context X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:33:09 -0000 SGkgRGFuaWVsZSwNCg0KVGhlIGxpc3Qgd2Fzbid0IHNvIGJ1c3kgYW55bW9yZSBpbiAyMDEzIGFz IGl0IHdhcyB0aGUgeWVhciBiZWZvcmUuIFdvdWxkIHlvdSBtaW5kIHRvIHN1bW1hcml6ZSB3aGF0 IGlzIHBlcmNlaXZlZCB0aGUgd29yZGluZy9hYmJyZXZpYXRpb25zIHdlIGFyZSBjb252ZXJnaW5n IHRvPyBUaGlzIHdheSB3ZSBjb3VsZCBzdGFydCB1cGRhdGluZyB0aGUgd29yZGluZyBvZiB0aGUg RU5OSSBmcmFtZXdvcmsgZG9jdW1lbnQuDQoNCkJlc3QNCg0KR2VydA0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1w LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWxlIENlY2NhcmVsbGkNClNlbnQ6 IERvbm5lcnN0YWcsIDIwLiBEZXplbWJlciAyMDEyIDE2OjUyDQpUbzogTG91IEJlcmdlcg0KQ2M6 IENDQU1QDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBPdmVybGF5IG1vZGVsIGZyYW1ld29yayBhbmQg Y29udGV4dA0KDQpZb3UgdGhvdWdodCB0aGUgd29ybGQgd2FzIGdyZXksIEkgc3BlbnQgaGFsZiBh biBob3VyIHRvIHdyaXRlIGFuIGVtYWlsIHRyeWluZyB0byBjb252aW5jZSB5b3UgdGhhdCB3b3Js ZCBpcyB3aGl0ZSBhbmQgbm93IHlvdSdyZSBjb252aW5jZWQgdGhhdCB0aGUgd29ybGQgaXMgYmxh Y2shISEgIDopDQoNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogTG91IEJl cmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+U2VudDogZ2lvdmVkqKwgMjAgZGljZW1i cmUgMjAxMiAxNi40Mg0KPlRvOiBEYW5pZWxlIENlY2NhcmVsbGkNCj5DYzogRmF0YWkgWmhhbmc7 IElnb3IgQnJ5c2tpbjsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBDQ0FNUA0KPlN1YmplY3Q6 IFJlOiBbQ0NBTVBdIE92ZXJsYXkgbW9kZWwgZnJhbWV3b3JrIGFuZCBjb250ZXh0DQo+DQo+RGFu aWVsZSwNCj4NCj5UaGUgcGllY2UgdGhhdCdzIG1pc3NpbmcgZnJvbSB5b3VyIG1haWwgaXMgdGhh dCB5b3VyICJ2cG4iIA0KPnRlcm1zIGhhdmUgd2lkZXIgc2NvcGUgdGhhbiBqdXN0IFZQTnMuICBG b3IgZXhhbXBsZSBDRXMsIFBFcywgYWNjZXNzDQo+aW50ZXJmYWNlc3xsaW5rcywgaW50ZXItZG9t YWluIGludGVyZmFjZXN8bGlua3MgaGF2ZSBzY29wZSB3ZWxsIGJleW9uZA0KPlZQTnMuDQo+DQo+ QW4gYWx0ZXJuYXRlIGNvbmNsdXNpb24gKHdoaWNoIHlvdSBoYXZlIG1lIG5vdyBsZWFuaW5nDQo+ dG93YXJkcykgaXMgdGhhdCB3ZSBzaG91bGQganVzdCB1c2UgQ0UgYW5kIFBFIGluIHBsYWNlIG9m IE9FIGFuZCBPQy4NCj4NCj5Mb3UNCj4NCj5PbiAxMi8yMC8yMDEyIDEwOjMyIEFNLCBEYW5pZWxl IENlY2NhcmVsbGkgd3JvdGU6DQo+PiBFeGNlbGxlbnQsDQo+PiANCj4+IFNvIHlvdSdkIGFncmVl IHdpdGggdGhlIGdlbmVyYWwgb3ZlcmxheSBkZWZpbml0aW9ucyBvZiBPQw0KPmFuZCBPRS4gKHdo aWNoIGluIHRoZSBjYXNlIG9mIFZQTnMgd2lsbCBiZSBjYWxsZWQgQ0UgYW5kIFBFKS4NCj4+IA0K Pj4gV2hhdCBhYm91dCBhbiBhbmFsb2dvdXMgYXBwcm9hY2ggd2hlbiB3ZSBtb3ZlIGZyb20gbm9k ZXMgdG8NCj5pbnRlcmZhY2VzL2xpbmtzLiBBIGdlbmVyYWwgbmFtZSBmb3IgdGhlIG92ZXJsYXkg bW9zdCBnZW5lcmFsIGNhc2UgDQo+d2hlcmUgc3BlY2lmaWMgZXhpc2l0bmcgbmFtZXMgY2FuIGJl IHBsYWNlcyAodGhlIGZhbW91cyB1bWJyZWxsYSkuDQo+PiANCj4+IC0gSW4gdGhlIG1vcmUgZ2Vu ZXJpYyBjYXNlIG9mIG92ZXJsYXk6IHRoZSBub2RlcyBhcmUgY2FsbGVkDQo+T0MgYW5kIE9FDQo+ PiBhbmQgdGhlIGludGVyZmFjZSBiZXR3ZWVuIE9DIGFuZCBPRSBpcyBjYWxsZWQgKE9OSSwgT0ks IE9DSSwgeHh4bGluayANCj4+IG9yIHdoYXRldmVyKQ0KPj4gLSBJbiB0aGUgY2FzZSBvZiBpbnRl cmZhY2Ugc3VwcG9ydGluZyBzaWduYWxpbmcgb25seTogVGhlIChPTkksIE9JLCANCj4+IE9DSSwg eHh4bGluayBvciB3aGF0ZXZlcikgaXMgYSBwYXJ0aWN1bGFyIGNhc2Ugb2YgKE9OSSwgT0ksIE9D SSBvcg0KPj4gd2hhdGV2ZXIpIGFuZCBpcyBjYWxsZWQgVU5JLCBhbmQgdGhlIG5vZGVzIGF0IGl0 cyBlbmRzIGFyZSBjYWxsZWQgQ04gDQo+PiBhbmQgRU4gKFJGQzQyMDgpDQo+PiAtIEluIHRoZSBj YXNlIG9mIFZQTnM6IHRoZSAoT05JLCBPSSwgT0NJLCB4eHhsaW5rIG9yDQo+d2hhdGV2ZXIpIGlz IGNhbGxlZCBhY2Nlc3MgbGluayBhbmQgdGhlIG5vZGVzIGFyZSBjYWxsZWQgQ0UgYW5kIFBFLg0K Pj4gDQo+PiBJIHNlZSBubyBvdGhlciB3YXkgb2YgcHV0dGluZyBzb21lIG9yZGVyIGFtb25nIGFs bCB0aGUNCj5hbHJlYWR5IGV4aXN0aW5nIHRlcm1zLg0KPj4gDQo+PiBCUg0KPj4gRGFuaWVsZQ0K Pj4gDQo+PiANCj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTog TG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+Pj4gU2VudDogZ2lvdmVkqKwg MjAgZGljZW1icmUgMjAxMiAxNS4zOQ0KPj4+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGkNCj4+PiBD YzogRmF0YWkgWmhhbmc7IElnb3IgQnJ5c2tpbjsgQkVMT1RUSSwgU0VSR0lPIChTRVJHSU8pOyBD Q0FNUA0KPj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIE92ZXJsYXkgbW9kZWwgZnJhbWV3b3JrIGFu ZCBjb250ZXh0DQo+Pj4NCj4+PiBEYW5pZWxlLA0KPj4+DQo+Pj4gSnVzdCBteSBvcGluaW9uLCBi dXQgSSBzZWUgb3ZlcmxheXMgYXMgdGhlIChtdWNoKSBtb3JlDQo+Z2VuZXJpYyB0ZXJtLiAgDQo+ Pj4gSSB0aGluayBMeFZQTnMgYXJlIHR5cGVzIG9mIG92ZXJsYXlzLCBhcyBhcmUgdHJhZGl0aW9u YWwgbGF5ZXJlZCANCj4+PiBuZXR3b3JrcywgYXMgYXJlIHRoZSB0ZWNobm9sb2dpZXMgdGhhdCBt YXRjaC93aWxsIHJlc3VsdCBmcm9tIA0KPj4+IGRpc2N1c3Npb25zIHRha2luZyBwbGFjZSBpbiB0 aGUgTlZPMyBjb250ZXh0Lg0KPj4+DQo+Pj4gTG91DQo+Pj4NCj4+PiBPbiAxMi8yMC8yMDEyIDU6 MjIgQU0sIERhbmllbGUgQ2VjY2FyZWxsaSB3cm90ZToNCj4+Pj4gSSBwcmVmZXIgdXNpbmcgcmVm ZXJlbmNlIHBvaW50cyBpbnN0ZWFkIG9mIGxpbmtzLg0KPj4+PiBBY2Nlc3MgbGluayBhbmQgaW50 ZXItZG9tYWluIGxpbmtzIG1lYW5zIHRlbnMgb2YgdGhpbmdzIGluDQo+ZGlmZmVyZW50DQo+Pj4+ IGNvbnRleHRzLCB3aGlsZSBlLmcuIFVOSSBtZWFucyBvbmUgc2luZ2xlIHRoaW5nIGFuZCBjbGVh cmx5DQo+Pj4gaWRlbnRpZmllcw0KPj4+PiB0aGUgY29udGV4dC4gQlRXIGl0J3MganVzdCBhIHBy ZWZlcmVuY2UsIEkgZG9uJ3QgbWluZCBob3cgd2UnbGwgDQo+Pj4+IGZpbmFsbHkgY2FsbCBpdC4N Cj4+Pj4NCj4+Pj4gVGhlcmUncyBvbmUgdGhpbmcgSSB3b3VsZCByYXRoZXIgbGlrZSB0byBjbGFy aWZ5IGFuZCBpdCdzIHRoZSANCj4+Pj4gcmVsYXRpb25zaGlwIHdpdGggVlBOcy4gV2UgaGF2ZSB0 d28gb3B0aW9uczoNCj4+Pj4NCj4+Pj4gMSkgSXMgYSBWUE4gYSBwYXJ0aWN1bGFyIGNhc2Ugb2Yg dGhlIG92ZXJsYXkgbW9kZWw/DQo+Pj4+IG9yDQo+Pj4+IDIpIElzIHRoZSBvdmVybGF5IG1vZGVs IGEgcGFydGljdWxhciBjYXNlIG9mIFZQTj8NCj4+Pj4NCj4+Pj4gSSB0aGluayB0aGlzIGNhbiBo ZWxwIGEgbG90IHdpdGggdGVybWlub2xvZ3kuIEkndmUgYWx3YXlzDQo+YXNzdW1lZCAxKQ0KPj4+ PiBidXQgZnJvbSB3aGF0IEkgcmVhZCBJIHRlbmQgdG8gc2VlIHRoYXQgMikgaGFzIHNldmVyYWwg c3VwcG9ydGVycy4NCj4+Pj4NCj4+Pg0KPj4+PiBCUg0KPj4+PiBEYW5pZWxlDQo+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJv bTogRmF0YWkgWmhhbmcgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dDQo+Pj4+PiBTZW50 OiBnaW92ZWSorCAyMCBkaWNlbWJyZSAyMDEyIDIuNDQNCj4+Pj4+IFRvOiBMb3UgQmVyZ2VyOyBJ Z29yIEJyeXNraW47IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgRGFuaWVsZSANCj4+Pj4+IENl Y2NhcmVsbGkNCj4+Pj4+IENjOiBDQ0FNUA0KPj4+Pj4gU3ViamVjdDogtPC4tDogW0NDQU1QXSBP dmVybGF5IG1vZGVsIGZyYW1ld29yayBhbmQgY29udGV4dA0KPj4+Pj4NCj4+Pj4+IEhpIGFsbCwN Cj4+Pj4+DQo+Pj4+PiBTdXBwb3J0Lg0KPj4+Pj4NCj4+Pj4+IFBlb3BsZSBhcmUgbW9yZSBmYW1p bGlhciB3aXRoIHRoZSBleGlzdGluZyB0aGluZ3MgbGlrZQ0KPj4+ICJhY2Nlc3MgbGlua3MiIA0K Pj4+Pj4gYW5kICJpbnRlci1kb21haW4gbGlua3MiIChvciBFLU5OSSBsaW5rcykuDQo+Pj4+Pg0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pg0KPj4+Pj4gRmF0 YWkNCj4+Pj4+DQo+Pj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4+Pj4+ILeivP7IyzogY2NhbXAt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4+ Pj4+IExvdSBCZXJnZXINCj4+Pj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMjDI1SA3OjA4DQo+Pj4+ PiDK1bz+yMs6IElnb3IgQnJ5c2tpbg0KPj4+Pj4gs63LzTogQ0NBTVANCj4+Pj4+INb3zOI6IFJl OiBbQ0NBTVBdIE92ZXJsYXkgbW9kZWwgZnJhbWV3b3JrIGFuZCBjb250ZXh0DQo+Pj4+Pg0KPj4+ Pj4gSWdvciwNCj4+Pj4+DQo+Pj4+PiBZb3Ugc2FpZDoNCj4+Pj4+IElCPj4gSSBsaWtlICJhY2Nl c3MgbGlua3MiIGFuZCAiaW50ZXItZG9tYWluIGxpbmtzIiBiZXR0ZXIuDQo+Pj4+Pg0KPj4+Pj4g VGhpcyB3b3JrcyBmb3IgbWUuDQo+Pj4+Pg0KPj4+Pj4gTG91DQo+Pj4+Pg0KPj4+Pj4gT24gMTIv MTkvMjAxMiAxMjoyNyBQTSwgSWdvciBCcnlza2luIHdyb3RlOg0KPj4+Pj4+IExvdSwgcGxlYXNl IHNlZSBteSBhbnN3ZXJzIHRvIHlvdXIgcXVlc3Rpb25zDQo+Pj4+Pj4NCj4+Pj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXQ0KPj4+Pj4gT24gQmVoYWxmDQo+Pj4+Pj4g T2YgRGFuaWVsZSBDZWNjYXJlbGxpDQo+Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAx OSwgMjAxMiA1OjU3IEFNDQo+Pj4+Pj4gVG86IExvdSBCZXJnZXINCj4+Pj4+PiBDYzogQ0NBTVAN Cj4+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBPdmVybGF5IG1vZGVsIGZyYW1ld29yayBhbmQg Y29udGV4dA0KPj4+Pj4+DQo+Pj4+Pj4gSGkgTG91LA0KPj4+Pj4+DQo+Pj4+Pj4gUGxlc2UgZmlu ZCByZXBsaWVzIGluIGxpbmUuDQo+Pj4+Pj4NCj4+Pj4+PiBCUg0KPj4+Pj4+IERhbmllbGUNCj4+ Pj4+Pg0KPj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBM b3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4+Pj4+Pj4gU2VudDogbHVuZWSo rCAxNyBkaWNlbWJyZSAyMDEyIDIwLjQ1DQo+Pj4+Pj4+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGkN Cj4+Pj4+Pj4gQ2M6IENDQU1QDQo+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIE92ZXJsYXkg bW9kZWwgZnJhbWV3b3JrIGFuZCBjb250ZXh0DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IERh bmllbGUsDQo+Pj4+Pj4+IAlUaGFua3MgZm9yIGdldHRpbmcgdGhpcyBvbi1saXN0IGRpc2N1c3Np b24NCj5nb2luZy4gIEkgaGF2ZSBzb21lDQo+Pj4+Pj4+IGNvbW1lbnRzIGFuZCBxdWVzdGlvbnM6 DQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0gU28gd2hhdCdzIGEgImNsaWVudCBsYXllciBuZXR3b3JrIiBp biB0aGlzIGNvbnRleHQ/ICANCj4+PiBQZXJoYXBzIHlvdQ0KPj4+Pj4+PiBtZWFuIE9DIG9yICIo b3ZlcmxheSkgY3VzdG9tZXIgbGF5ZXIiPw0KPj4+Pj4+DQo+Pj4+Pj4gSUI+PiBDbGllbnQgbGF5 ZXIgaXMgd2hlcmUgT3ZlcmxheSBOZXR3b3JrIHRvcG9sb2d5IGV4aXN0cy4gDQo+Pj4+PiBJdCBp bmNsdWRlczoNCj4+Pj4+PiBhKSBhY2Nlc3MgbGlua3MgKGNvbm5lY3RpbmcgT0NzIHRvIE9FcykN Cj4+Pj4+PiBiKSB2aXJ0dWFsIGxpbmtzIChjb25uZWN0aW5nIE9FIC8gT1ZOcyAoT3ZlcmxheSBW aXJ0dWFsDQo+Pj4+PiBOb2Rlcykgd2l0aGluDQo+Pj4+Pj4gYSBnaXZlbiBzZXJ2ZXIgZG9tYWlu KQ0KPj4+Pj4+IGMpIGludGVyLWRvbWFpbiBsaW5rcyAoY29ubmVjdGluZyBPRSB0byBPRSB0aGF0 IGJlbG9uZyB0bw0KPj4+Pj4gbmVpZ2hib3JpbmcNCj4+Pj4+PiBzZXJ2ZXIgZG9tYWlucykgQWxs IHRocmVlIGNhdGVnb3JpZXMgZXhpc3QgaW4gdGhlIHNhbWUNCj4+PiBjbGllbnQgbGF5ZXINCj4+ Pj4+PiBhbmQgbmFtZWQgZnJvbSB0aGUgc2FtZSBuYW1pbmcgc3BhY2UNCj4+Pj4+Pg0KPj4+Pj4+ IFllcy4gVGhlIHRlcm1zIGNsaWVudCBsYXllciBhbmQgc2VydmVyIGxheWVyIGFyZQ0KPj4+Pj4g cmVtaW5lc2NlbmNlcyB0byBiZSBjb3JyZWN0ZWQuDQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g LSBTbyB3aGF0J3MgYSAic2VydmVyIGxheWVyIG5ldHdvcmsiIGluIHRoaXMgY29udGV4dD8gIA0K Pj4+IFBlcmhhcHMgeW91DQo+Pj4+Pj4+IG1lYW4gT0Ugb3IgIihvdmVybGF5KSBwcm92aWRlciBs YXllciI/DQo+Pj4+Pj4NCj4+Pj4+PiBJQj4+IEl0IGlzIHRoZSBsYXllciB3aGVyZSB0aGUgVU5U IChVbmRlcmxheSBOZXR3b3JrDQo+Pj4+PiBUb3BvbG9neSkgZXhpc3RzDQo+Pj4+Pj4gSUI+PiAo d2hpY2ggbWF5IGJlIGluIHRoZSBzYW1lLCBsb3dlciBvciBoaWdoZXIgbGF5ZXINCj4+Pj4+IG5l dHdvcmsgdGhhbiBvZg0KPj4+Pj4+IElCPj4gdGhlIE9OVCkNCj4+Pj4+Pg0KPj4+Pj4+IEFnYWlu IGNvcnJlY3QNCj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAtIEZvciBPQywgSSdkIHRoaW5nIHJl ZmVycmluZyBiYWNrIHRvIGEgQ0UgaW4gdGhlIFZQTg0KPj4+IGNvbnRleHQsIGFuZA0KPj4+Pj4+ PiBsaWtld2lzZSB0byBhIFBFIGZvciBhbiBPRSwgaXMgaGVscGZ1bCBjb250ZXh0Lg0KPj4+Pj4+ IElCPj4gYWdyZWUNCj4+Pj4+Pg0KPj4+Pj4+IEluIHRoZSBjYXNlIG9mIHRoZSBpbnRlcmZhY2Ug d2UgZ2VuZXJhbGx5IGRlZmluZSB0aGUgT05JIGFzDQo+Pj4+PiBhbiBvdmVybGF5IGludGVyZmFj ZSB0aGF0IGluIGEgcGFydGljdWxhciBjYXNlIGlzIGNhbGxlZCBVTkkuIA0KPj4+Pj4gSSB3b3Vs ZCBhcHBseSB0aGUgc2FtZSBtZXRob2Q6IHRob3NlIG5vZGVzIGFyZSBjYWxsZWQgT3ZlcmxheSAN Cj4+Pj4+IEN1c3RvbWVyIGFuZCBPdmVybGF5IEVkZ2UgYW5kIGluIHRoZSBwYXJ0aWN1bGFyIGNh c2Ugb2YNCj4+PiBWUE5zIHRoZXkgYXJlDQo+Pj4+PiB0aGUgQ0UgYW5kIFBFIHJlc3BlY3RpdmVs eS4gV2hhdCBhYm91dCB0aGF0Pw0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0gQXMgeW91IG1l bnRpb24gaW4gdGhlIEFwcGVuZGl4LCAoZnJvbSB0aGUgT0MgcGVyc3BlY3RpdmUpDQo+Pj4+PiB0 aGVyZSBpcw0KPj4+Pj4+PiBubyBkaWZmZXJlbmNlIGJldHdlZW4gYSB2aXJ0dWFsIGFuZCByZWFs IG5vZGUNCj4+Pj4+PiBJQj4+IEFncmVlDQo+Pj4+Pj4NCj4+Pj4+PiAgKGFuZCBwcmVzdW1hYmx5 IGxpbmsgYXMNCj4+Pj4+Pj4gd2VsbCkuICBHaXZlbiB0aGlzIGFuZCB5b3VyIGNvbW1lbnQgaW4g OCwgdGhhdCB0aGUgT05JDQo+Pj4gY2FuIHRha2UgdGhlDQo+Pj4+Pj4+IGZvcm0gb2YgYSBVTkkg b3IgaW5jbHVkZSBib3RoIHNpZ25hbGluZyBhbmQgcm91dGluZyAoaS5lLiwgYSANCj4+Pj4+Pj4g cGVlci9JLU5OSSBvcg0KPj4+Pj4+PiBFLU5OSSkgd2hhdCB2YWx1ZSBpcyB0aGVyZSBpbiBpbnRy b2R1Y2luZyB0aGUgT05JIHRlcm0/ICANCj4+Pj4+IFNhaWQgYW5vdGhlcg0KPj4+Pj4+PiB3YXks IHRoZXJlJ3Mgbm8gc3BlY2lmaWMgdGVybSBmb3IgdGhlIGludGVyZmFjZSBiZXR3ZWVuIGENCj4+ PiBDRSBhbmQgUEUNCj4+Pj4+Pj4gaW4gTDNWUE5zLCBzbyB3aHkgZG8gd2UgbmVlZCB0byBpbnRy b2R1Y2Ugb25lIGluIHRoaXMgY29udGV4dD8NCj4+Pj4+Pg0KPj4+Pj4+IFdlIGdhdmUgYSBuYW1l IHRvIHRoZSBVTkksIHdoeSBkb24ndCBnaXZpbmcgdG8gdGhlIE9OST8NCj4+Pj4+Pg0KPj4+Pj4+ IElCPj4gQXMgbG9uZyBhcyBpdCBhbGxvd3MgZm9yIGJvdGggb3IgZWl0aGVyIHNpZ25hbGluZw0K Pj4+Pj4gYW5kL29yIHJvdXRpbmcNCj4+Pj4+PiBJQj4+IGV4Y2hhbmdlcw0KPj4+Pj4+DQo+Pj4+ Pj4+DQo+Pj4+Pj4+IEkgdGhpbmsgdGhpcyBzYW1lIGNvbW1lbnQgcHJvYmFibHkgaG9sZHMgZm9y IHRoZSBPLU5OSQ0KPj4+Pj4gKGUuZy4sIHdoYXQncw0KPj4+Pj4+PiB0aGUgbmFtZSBvZiB0aGUg aW50ZXJmYWNlIGJldHdlZW4gcHJvdmlkZXJzIHdoaWNoIHN1cHBvcnQgTDNWUE4gDQo+Pj4+Pj4+ IGhhbmRvZmZzPykuLi4NCj4+Pj4+Pg0KPj4+Pj4+IEkgd291bGQgc3VnZ2VzdCBnaXZpbmcgYSBu YW1lIHRvIHRoYXQgaW50ZXJmYWNlIGFsc28gaW4NCj4+Pj4+IG9yZGVyIHRvIGRpc3Rpbmd1aXNo IGJldHdlZW4gYW4gImludGVybmFsIiBhbmQgYW4gImV4dGVybmFsIiANCj4+Pj4+IGxpbmsgd2hl biBtdWx0aXBsZSBvdmVybGF5IHByb3ZpZGVyIG5ldHdvcmsgZG9tYWlucyBhcmUgcHJlc2VudC4N Cj4+Pj4+Pg0KPj4+Pj4+IElCPj4gSSBsaWtlICJhY2Nlc3MgbGlua3MiIGFuZCAiaW50ZXItZG9t YWluIGxpbmtzIiBiZXR0ZXIuIA0KPj4+Pj4gTm90ZSBhbHNvIHRoYXQgYSAibGluayIgYW5kICJu b2RlIiBhcmUgVEUgdG9wb2xvZ3kgY29uY2VwdHMgYW5kIA0KPj4+Pj4gb3J0aG9nb25hbCB0byBD UCBpbnRlcmZhY2VzICh3aGljaCBhcmUgU2lnbmFsaW5nL1JvdXRpbmcNCj5zcGVha2VycykuDQo+ Pj4+PiBJZiB5b3UgbWVhbiBieSAiaW50ZXJuYWwiIGFuZCAiZXh0ZXJuYWwiIGxpbmtzIHRoZSBD UA0KPmNvbm5lY3Rpdml0eSwNCj4+Pj4+IHRoYW4gSSBhZ3JlZSB3aXRoIHlvdS4NCj4+Pj4+Pg0K Pj4+Pj4+Pg0KPj4+Pj4+PiBNdWNoIHRoYW5rcywNCj4+Pj4+Pj4gTG91DQo+Pj4+Pj4+DQo+Pj4+ Pj4+IE9uIDEyLzE3LzIwMTIgNjoxNyBBTSwgRGFuaWVsZSBDZWNjYXJlbGxpIHdyb3RlOg0KPj4+ Pj4+Pj4gRGVhciBDQ0FNUGVycywNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJbiB0aGUgbGFzdCB3ZWVr cyBzZXZlcmFsIG9mZi1saW5lIGRpc2N1c3Npb25zIG9uIHRoZQ0KPj4+Pj4+PiBPdmVybGF5IG1v ZGVsIGZyYW1ld29yayBhbmQgcmVsYXRlZCB3b3JrcyB0b29rIHBsYWNlLiBTb21lIA0KPj4+Pj4+ PiBkaXNjdXNzaW9ucyBsZWQgdG8gc29tZSBzb3J0IG9mIGFncmVlbWV0IGFtb25nIGEgc21hbGwg Z3JvdXAgb2YgDQo+Pj4+Pj4+IHBlb3BsZSwgc29tZSBvdGhlcnMgdG8gYSBzZXQgYSB2aWFibGUg b3B0aW9ucywgc29tZSBvdGhlcnMNCj4+Pj4+IHRvIHRvdGFsbHkNCj4+Pj4+Pj4gb3BlbiBpc3N1 ZXMuIEkgdHJpZWQgdG8gc3VtbWFyaXplIHRoZSBvdXRwdXQgb2Ygc3VjaA0KPmRpc2N1c3Npb25z DQo+Pj4+Pj4+IGJlbG93IHNvIHRvIHByb2dyZXNzIHRoZSBkaXNjdXNzaW9ucyBpbnRvIGEgc2lu Z2xlIHRocmVhZA0KPj4+Pj4gb24gdGhlIFdHIE1MLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFBsZWFz ZSBub3RlIHRoYXQgdGhlIGFpbSBvZiB0aGlzIG1haWwgaXMgbm90IHRvIHByZXNlbnQgYQ0KPj4+ Pj4+PiB3ZWxsIHNoYXBlZCBhbmQgY29uY2x1c2l2ZSBpZGVhIHRvIHRoZSBXRyBidXQgcmF0aGVy IHRvDQo+Pj4gcHJvdmlkZSB0aGUNCj4+Pj4+Pj4gYmFzaXMgZm9yIHN0YXJ0aW5nIGEgZGlzY3Vz c2lvbiBmcm9tIGEgYmFyZWx5IHNoYXBlZCBpZGVhDQo+Pj4gKHN0ZXAgMSkNCj4+Pj4+Pj4gaW5z dGVhZCBvZiBzdGFydGluZyBpdCBmcm9tIHNjcmF0Y2ggKHN0ZXAgMCkuDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gSW4gYWRkaXRpb24geW91IGNhbiBmaW5kIGF0dGFjaGVkIGEgc2xpZGUgZGVwaWN0aW5n IGENCj4+Pj4+Pj4gcHJvcG9zYWwgb2YgdGhlIG92ZXJsYXkgc2NlbmFyaW8uDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4gRGFuaWVsZQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICsg RGlzY2xhaW1lcjoNCj4+Pj4+Pj4+ICAxLiBQYWNrZXQgb3B0byBpbnRlZ3JhdGlvbiBpcyBvZnRl biBjb25zaWRlcmVkIGJ1dCB0aGUgd29yaw0KPj4+Pj4+PiBjYW4gYmUgZXh0ZW50ZWQgdG8gYW55 IHR5cGUgb2YgU0MuIEVnLiBURE0gb3ZlciBMU0MuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gKyBUZXJt aW5vbG9neToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgMS4gVmlydHVhbCBMaW5rOiBBIHZpcnR1YWwg bGluayBpcyBhIHBvdGVudGlhbCBwYXRoIGJldHdlZW4NCj4+Pj4+Pj4gdHdvIHZpcnR1YWwgb3Ig cmVhbCBuZXR3b3JrIGVsZW1lbnRzIGluIGEgY2xpZW50IGxheWVyDQo+Pj4+PiBuZXR3b3JrICB0 aGF0DQo+Pj4+Pj4+IGlzIG1haW50YWluZWQvY29udHJvbGxlZCBpbiBhbmQgYnkgdGhlIHNlcnZl ciBkb21haW4NCj4+PiBjb250cm9sIHBsYW5lDQo+Pj4+Pj4+IChhbmQgYXMgc3VjaCBjYW5ub3Qg dHJhbnNwb3J0IGFueSB0cmFmZmljL2RhdGEgYW5kDQo+cHJvdGVjdGVkIGZyb20NCj4+Pj4+Pj4g YmVpbmcNCj4+Pj4+Pj4gZGUtcHJvdmlzaW9uZWQpIGFuZCB3aGljaCBjYW4gYmUgaW5zdGFudGlh dGVkIGluIHRoZSBkYXRhDQo+Pj4+PiBwbGFuZSAoYW5kDQo+Pj4+Pj4+IHRoZW4gY2FuIGNhcnJ5 L3RyYW5zcG9ydC9mb3J3YXJkIHRyYWZmaWMvZGF0YSkgcHJlc2VydmluZw0KPj4+Pj4gcHJldmlv dXNseQ0KPj4+Pj4+PiBhZHZlcnRpc2VkIGF0dHJpYnV0ZXMgc3VjaCBhcyBmYXRlIHNoYXJpbmcg aW5mb3JtYXRpb24uDQo+Pj4+Pj4+PiAgMi4gIFZpcnR1YWwgTm9kZTogVmlydHVhbCBub2RlIGlz IGEgY29sbGVjdGlvbiBvZiB6ZXJvIG9yDQo+Pj4+Pj4+IG1vcmUgc2VydmVyIG5ldHdvcmsgIGRv bWFpbiBub2RlcyB0aGF0IGFyZSBjb2xsZWN0aXZlbHkNCj4+PiByZXByZXNlbnRlZA0KPj4+Pj4+ PiB0byB0aGUgY2xpZW50cyBhcyBhIHNpbmdsZSBub2RlIHRoYXQgZXhpc3RzIGluIHRoZSBjbGll bnQgbGF5ZXIgDQo+Pj4+Pj4+IG5ldHdvcmsgYW5kIGlzIGNhcGFibGUgb2YgdGVybWluYXRpbmcg b2YgYWNjZXNzLA0KPmludGVyLWRvbWFpbiBhbmQNCj4+Pj4+Pj4gdmlydHVhbCBsaW5rcy4NCj4+ Pj4+Pj4+ICAzLlZpcnR1YWwgVG9wb2xvZ3k6IFZpcnR1YWwgdG9wb2xvZ3kgaXMgYSBjb2xsZWN0 aW9uIG9mIG9uZQ0KPj4+Pj4+PiBvciBtb3JlIHZpcnR1YWwgb3IgcmVhbCBzZXJ2ZXIgbmV0d29y ayBkb21haW4gbm9kZXMgdGhhdA0KPj4+Pj4gZXhpc3QgaW4gdGhlDQo+Pj4+Pj4+IGNsaWVudCBs YXllciBuZXR3b3JrIGFuZCBhcmUgaW50ZXJjb25uZWN0ZWQgdmlhIDAgb3INCj5tb3JlIHZpcnR1 YWwNCj4+Pj4+Pj4gbGlua3MuDQo+Pj4+Pj4+PiAgNC4gT3ZlcmxheSB0b3BvbG9neTogIGlzIGEg c3VwZXJzZXQgb2YgdmlydHVhbCB0b3BvbG9naWVzDQo+Pj4+Pj4+IHByb3ZpZGVkIGJ5IGVhY2gg b2Ygc2VydmVyIG5ldHdvcmsgZG9tYWlucywgYWNjZXNzIGFuZA0KPj4+IGludGVyLWRvbWFpbg0K Pj4+Pj4+PiBsaW5rcy4NCj4+Pj4+Pj4+ICA1LiBBY2Nlc3MgTGluazogTGluayBiZXR3ZWVuIE9D IGFuZCBPRS4gR01QTFMgcnVucyBvbiB0aGF0DQo+Pj4+Pj4+IGxpbmsuIEl0IGNhbiBzdXBwb3J0 IGFueSBvZiB0aGUgU0NzIHN1cHBvcnRlZCBieSB0aGUgR01QTFMuDQo+Pj4+Pj4+PiAgNi4gT3Zl cmxheSBDdXN0b21lciAoT0MpOiBTb21ldGhpbmcgbGlrZSB0aGUgQ04gaW4gUkZDNDIwOA0KPj4+ Pj4+PiB0ZW1pbm9sb2d5ICBidXQgKGkpIHJlY2VpdmluZyB2aXJ0dWFsIHRvcG9sb2d5IGZyb20g dGhlDQo+Pj4+PiBjb3JlIG5ldHdvcmsNCj4+Pj4+Pj4gYW5kIHJlcXVlc3RpbmcgdGhlIHNldCB1 cCBvZiBvbmUgb2YgdGhlbSBvciAoaWkpIHJlcXVlc3RpbmcgdGhlIA0KPj4+Pj4+PiBjb21wdXRh dGlvbiBhbmQgZXN0YWJsaXNobWVudCBvZiBhIHBhdGggYWNjb3JkaW5nbHkgdG8gZ2llbiANCj4+ Pj4+Pj4gY29uc3RyYWludHMgaW4gdGhlIGNvcmUgbmV0d29yayBhbmQgcmVjZWl2aW5nIHRoZSBw YXJhbWV0ZXJzIA0KPj4+Pj4+PiBjaGFyYWN0ZXJpemluZyBzdWNoIHBhdGguIChpaSkgPT0gVU5J Lg0KPj4+Pj4+Pj4gIDcuIE92ZXJsYXkgRWRnZSAoT0UpOiBTb21ldGhpbmcgbGlrZSB0aGUgRU4g aW4gUkZDNDIwOCBidXQNCj4+Pj4+Pj4gYWJsZSB0byBkZWFsIHdpdGggKGkpIGFuZCAoaWkpIGFi b3ZlLg0KPj4+Pj4+Pj4gIDguIE9OSSA6IE92ZXJsYXkgbmV0d29yayBpbnRlcmZhY2U6IEludGVy ZmFjZSBhbGxvd2luZyBmb3INCj4+Pj4+Pj4gc2lnbmFsaW5nIGFuZCByb3V0aW5nIG1lc3NhZ2Vz IGV4Y2hhbmdlIGJldHdlZW4gT3ZlcmxheQ0KPmFuZCBDb3JlDQo+Pj4+Pj4+IG5ldHdvcmsuIFJv dXRpbmcgaW5mb3JtYXRpb24gY29uc2lzdHMgb24gdmlydHVhbCB0b3BvbG9neSANCj4+Pj4+Pj4g YWR2ZXJ0aXNlbWVudC4gV2hlbiB0aGVyZSBpcyBubyByb3V0aW5nIGFkamFjZW5jeSBhY3Jvc3Mg dGhlIA0KPj4+Pj4+PiBpbnRlcmZhY2UgaXQgaXMgZXF1aXZhbGVudCB0byB0aGUgR01QTFMgVU5J IGRlZmluZWQgaW4gNDIwOC4NCj4+Pj4+Pj4gU2lnbmFsaW5nIG1lc3NhZ2VzIGFyZSBjb21wbGlh bnQgd2l0aCBSRkM0MjA4LiBJbmZvcm1hdGlvbg0KPj4+Pj4gcmVsYXRlZCB0bw0KPj4+Pj4+PiBw YXRoIGNhcmFjaHRlcmlzdGljcywgZS5nLiBURS1tZXRyaWNzLCBjb2xsZWN0ZWQgU1JMRywNCj5w YXRoIGRlbGF5DQo+Pj4+Pj4+IGV0YywgZWl0aGVyIHBhc3NlZCBmcm9tIE9FIHRvIE9DIHZpYSBz aWduYWxpbmcgYWZ0ZXIgdGhlIExTUCANCj4+Pj4+Pj4gZXN0YWJsaXNobWVudCBpbiB0aGUgY29y ZSBuZXR3b3JrIG9yIGZyb20gT0MgdG8gT0UgdG8gYmUNCj4+Pj4+IHVzZWQgYXMgcGF0aA0KPj4+ Pj4+PiBjb21wdXRhdGlvbiBjb25zdHJhaW50cywgZmFsbCB1bmRlciB0aGUgZGVmaW5pdGlvbiBv Zg0KPj4+Pj4gc2lnbmFsaW5nIGluZm8NCj4+Pj4+Pj4gYW5kIG5vdCByb3V0aW5nIGluZm8pLg0K Pj4+Pj4+Pj4gIDkuIE8tTk5JIChuYW1lIHRvIGJlIGZvdW5kLG1heWJlIHJldXNlZCk6IEludGVy ZmFjZSBvbiB0aGUNCj4+Pj4+Pj4gbGlua3MgYmV0d2VlbiBkaWZmZXJlbnQgY29yZSBuZXR3b3Jr cyBpbiB0aGUgb3ZlcmxheSBtb2RlbCANCj4+Pj4+Pj4gZW52aXJvbm1lbnQsIGkuZS4gQmV0d2Vl biBib3JkZXIgT0VzLiBTYW1lIGZlYXR1cmVzIG9mIHRoZQ0KPj4+Pj4gT05JIGFwcGx5DQo+Pj4+ Pj4+IHRvIHRoaXMgaW50ZXJmYWNlLiBDb3VsZCBpdCBiZSBhbiBFLU5OST8gQSBPTkk/IEEgbmV3 IG5hbWUNCj4+Pj4+IGlzIG5lZWRlZD8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiArIFN0YXRlbWVudHMN Cj4+Pj4+Pj4+ICAxLiBJbiB0aGUgY29udGV4dCBvZiBvdmVybGF5IG1vZGVsIHdlIGFyZSBhaW1p bmcgdG8gYnVpbGQNCj4+Pj4+Pj4gYW4gb3ZlcmxheQ0KPj4+Pj4+Pj4gdG9wb2xvZ3kgZm9yIHRo ZSBjbGllbnQgbmV0d29yayBkb21haW5zICAyLiBUaGUgb3ZlcmxheQ0KPj4+Pj4+PiB0b3BvbG9n eSBpcyBjb21wcmlzZWQgb2Y6DQo+Pj4+Pj4+PiAgICAgYSkgYWNjZXNzIGxpbmtzIChsaW5rcyBj b25uZWN0aW5nIGNsaWVudCBORXMgdG8gdGhlDQo+Pj4+Pj4+IHNlcnZlciBuZXR3b3JrIGRvbWFp bnMpLiBUaGV5IGNhbiBiZSBQU0Mgb3IgTFNDLg0KPj4+Pj4+Pj4gICAgIGIpIGludGVyLWRvbWFp biBsaW5rcyAobGlua3MgaW50ZXJjb25uZWN0aW5nIHNlcnZlcg0KPj4+Pj4+PiBuZXR3b3JrIGRv bWFpbnMpICAgDQo+Pj4+Pj4+PiAgICAgYykgdmlydHVhbCB0b3BvbG9neSBwcm92aWRlZCBieSB0 aGUgc2VydmVyIG5ldHdvcmsNCj4+Pj4+Pj4gZG9tYWlucy4gVmlydHVhbCBMaW5rcyArIFZpcnR1 YWwgTm9kZXMgKFRCRCkgKw0KPj4+IENvbm5lY3Rpdml0eSBNYXRyaXgNCj4+Pj4+Pj4gKHdpdGgg YSBzZXQgb2YgcGFyYW1ldGVycyBlLmcuIFNSTEcsIG9wdGljYWwgaW1wYWlybWVudHMsDQo+Pj4g ZGVsYXkgZXRjDQo+Pj4+Pj4+IGZvciBlYWNoIGVudHJ5KSBkZXNjcmliaW5nIGNvbm5lY3Rpdml0 eSBiZXR3ZWVuIGFjY2Vzcw0KPmxpbmtzIGFuZA0KPj4+Pj4+PiB2aXJ0dWFsIGxpbmtzLg0KPj4+ Pj4+Pj4gIDMuIEluIHRoZSBjb250ZXh0IG9mIG92ZXJsYXkgbW9kZWwgd2UgbWFuYWdlICBoaWVy YXJjaHkNCj4+Pj4+IG9mIG92ZXJsYXkNCj4+Pj4+Pj4+IHRvcG9sb2dpZXMgd2l0aCBvdmVybGF5 L3VuZGVybGF5IHJlbGF0aW9uc2hpcHMgIDQuIEluIHRoZQ0KPj4+Pj4gY29udGV4dCBvZg0KPj4+ Pj4+Pj4gb3ZlcmxheSBtb2RlbCBtdWx0aS1sYXllcmluZyBhbmQgaW50ZXItbGF5ZXIgcmVsYXRp b25zaGlwcw0KPj4+Pj4+PiBhcmUgcGVyaXBoZXJhbCBhdCBiZXN0LCBpdCBpcyBhbGwgYWJvdXQg aG9yaXpvbnRhbCBuZXR3b3JrIA0KPj4+Pj4+PiBpbnRlZ3JhdGlvbiA1LiBUaGUgb3ZlcmxheSBt b2RlbCBhc3N1bWVzIG9uZSBpbnN0YW5jZSBmb3INCj4+Pj4+IHRoZSBjbGllbnQNCj4+Pj4+Pj4g bmV0d29yayBhbmQgYSBzZXBhcmF0ZSBpbnN0YW5jZSBmb3IgdGhlIHNlcnZlciBuZXR3b3JrIGFu ZA0KPj4+Pj4gaW4gdGhlIE9OSQ0KPj4+Pj4+PiBjYXNlIHRoZSBzZXJ2ZXIgbmV0d29yayBhbHNv IHN1cnJlcHRpdGlvdXNseQ0KPnBhcnRpY2lwYXRlcyBpbiB0aGUNCj4+Pj4+Pj4gY2xpZW50IG5l dHdvcmsgYnkgaW5qZWN0aW5nIHZpcnR1YWwgdG9wb2xvZ3kNCj5pbmZvcm1hdGlvbiBpbnRvIGl0 Lg0KPj4+Pj4+Pj4gIDYuIEwxVlBOIChhbmQgTHhWUE4pIGluIGdlbmVyYWwgaXMgYSBzZXJ2aWNl IHByb3ZpZGVkIG92ZXINCj4+Pj4+Pj4gdGhlIE9OSSAoaXQgZmFsbHMgdW5kZXIgdGhlIFVOSSBj YXNlIGFzIG5vIHJvdXRpbmcNCj4+PiBhZGphY2VuY3kgaXMgaW4NCj4+Pj4+Pj4gcGxhY2UgYmV0 d2VlbiBPQyBhbmQgT0UpLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICsgT3BlbiBpc3N1ZXMvcXVlc3Rp b25zDQo+Pj4+Pj4+PiAgDQo+Pj4+Pj4+PiAgMS4gUENFLVBDRVAgLSBkbyB3ZSBuZWVkIHRvIGlu Y2x1ZGUgY29uc2lkZXJhdGlvbnMgYWJvdXQNCj4+Pj4+Pj4gUENFIGFuZCBQQ0VQIGludG8gdGhl IG92ZXJsYXkgZnJhbWV3b3JrIGNvbnRleHQ/DQo+Pj4+Pj4+PiAgMi4gQkdQLUxTIG5lZWRzIHRv IGJlIGNvbnNpZGVyZWQgIDMuIFNob3VsZCBwb3RlbnRpYWxzIGJlIA0KPj4+Pj4+Pj4gaW5jbHVk ZWQ/IEUuZy4gSTJSUz8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiArIEFwcGVuZGl4Og0KPj4+Pj4+Pj4g U29tZSBub3RlcyBvbiB0aGUgVmlydHVhbCBOb2RlOg0KPj4+Pj4+Pj4gMS4gICAgICBWaXJ0dWFs IExpbmsgTW9kZWwgYWxvbmcsIHNhZGx5LCBkb2VzIG5vdCBzY2FsZSANCj4+Pj4+Pj4gYmVjYXVz ZSBvZiBOKioyIHByb2JsZW0uIElQIG92ZXIgQVRNIGFuZCBzaW5nbGUtc2VnbWVudCBQV3MNCj4+ Pj4+IGhhdmUgdGhlDQo+Pj4+Pj4+IHNhbWUgaXNzdWUsIHRoYXQncyB3aHkgcGVvcGxlIGludmVu dGVkIG11bHRpLXNlZ21lbnQgUFdzDQo+Pj4+Pj4+PiAyLiAgICAgIFRoZSBvbmx5IHdheSB0byBh dm9pZCBmdWxsLW1lc2ggb2YgVmlydHVhbCBMaW5rcyBpcyANCj4+Pj4+Pj4gYnkgaGF2aW5nIGlu dGVybWVkaWF0ZSBub2RlcyBpbnRlcmNvbm5lY3RpbmcgVmlydHVhbA0KPkxpbmtzIGluIHRoZQ0K Pj4+Pj4+PiBtaWRkbGUgb2YgdGhlIHZpcnR1YWwgdG9wb2xvZ3kNCj4+Pj4+Pj4+IDMuICAgICAg VGhlc2UgaW50ZXJtZWRpYXRlIG5vZGVzIGNhbm5vdCBiZSByZWFsIHNlcnZlciANCj4+Pj4+Pj4g ZG9tYWluIHN3aXRjaGVzLCBiZWNhdXNlLCBnZW5lcmFsbHkgc3BlYWtpbmc6DQo+Pj4+Pj4+PiAg IGEpUmVhbCBzd2l0Y2hlcyBiZWxvbmcgdG8gZGlmZmVyZW50IGxheWVyIG5ldHdvcms7DQo+Pj4+ Pj4+PiAgIGIpUmVhbCBzd2l0Y2hlcyBhcmUgbmFtZWQgZnJvbSBkaWZmZXJlbnQgbmFtaW5nIHNw YWNlDQo+Pj4+Pj4+PiAgIGMpcmVhbCBzd2l0Y2hlcyBpbmRpdmlkdWFsbHkgbWF5IG5vdCBoYXZl IHN1ZmZpY2llbnQNCj4+Pj4+Pj4gcmVzb3VyY2VzIHRvIHRlcm1pbmF0ZSB2aXJ0dWFsIGxpbmtz ICh3aGlsZSBhIGdyb3VwIG9mIHJlYWwNCj4+Pj4+IHN3aXRjaGVzDQo+Pj4+Pj4+IGNvbGxlY3Rp dmVseSB3aWxsIGhhdmUpDQo+Pj4+Pj4+PiAgIGQpUHJlc2VudGluZyBhIGdyb3VwIG9mIHJlYWwg c3dpdGNoZXMgYXMgYSBzaW5nbGUgdmlydHVhbA0KPj4+Pj4+PiBub2RlIGhhdmUgYmV0dGVyIHNj YWxhYmlsaXR5IHF1YWxpdGllcw0KPj4+Pj4+Pj4gNC4gICAgICBFdmVuIGlmIHlvdSBtYXAgYSB2 aXJ0dWFsIG5vZGUgb24gYSBzaW5nbGUgcmVhbCANCj4+Pj4+Pj4gbm9kZSwgeW91IG5lZWQgdG8g a2VlcCBpbiBtaW5kIHRoYXQgcmVhbCBzZXJ2ZXIgZG9tYWluDQo+Pj4+PiBzd2l0Y2hlcyBhcmUs DQo+Pj4+Pj4+IGdlbmVyYWxseSBzcGVha2luZywgYmxvY2tpbmcgc3dpdGNoZXMgYW5kIGFzIHN1 Y2ggbXVzdA0KPj4+IGV4cG9zZSB0aGVpcg0KPj4+Pj4+PiBjb25uZWN0aXZpdHkgbWF0cmljZXMN Cj4+Pj4+Pj4+IDUuICAgICAgSWYgeW91IHdhbnQgdG8gY29tcHV0ZSBTUkxHLWRpc2pvaW50IHBh dGhzIHRoYXQgDQo+Pj4+Pj4+IGNvdWxkIHBvdGVudGlhbGx5IGdvIHRocm91Z2ggYSByZWFsIHNl cnZlciBkb21haW4gc3dpdGNoLCB0aGUgDQo+Pj4+Pj4+IGxhdHRlcidzIGNvbm5lY3Rpdml0eSBt YXRyaXggbXVzdCBleHBvc2UgImludGVybmFsIg0KPj4+IFNSTEdzLCBzbyB0aGF0DQo+Pj4+Pj4+ IHRoZSB0d28gc2VydmljZXMgdHJhdmVyc2luZyB0aGUgc3dpdGNoIHdpbGwgbm90DQo+Pj4gc2lt dWx0YW5lb3VzbHkgZmFpbA0KPj4+Pj4+PiBpZiBhIHNpbmdsZSBpbnRlcm5hbCBlbGVtZW50IHNo YXJlZCBieSB0aGUgc2VydmljZXMgZmFpbHMNCj4+Pj4+Pj4+IDYuICAgICAgSWYgeW91IHdhbGsg dGhyb3VnaCBhbGwgY2FzZXMgdGhhdCBuZWVkIHRvIGJlIA0KPj4+Pj4+PiBhZGRyZXNzZWQgd2hl biB5b3UgYXJlIHRyYWZmaWMgZW5naW5lZXJpbmcgdG9wb2xvZ2llcw0KPj4+IHdpdGggYmxvY2tp bmcNCj4+Pj4+Pj4gc3dpdGNoZXMsIHlvdSB3aWxsIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBpcyBh YnNvbHV0ZWx5IG5vDQo+Pj4+PiBkaWZmZXJlbmNlDQo+Pj4+Pj4+IGJldHdlZW4gYSB2aXJ0dWFs IG5vZGUgYW5kIHJlYWwgYmxvY2tpbmcgcmVhbCBub2RlLg0KPj4+Pj4+Pj4gNy4gICAgICBFdmVu IGluIGNhc2Ugb2YgcHVyZSBWTCBtb2RlbCwgY2xpZW50IE5FcyBjb25uZWN0ZWQgDQo+Pj4+Pj4+ IHRvIHNlcnZlciBuZXR3b3JrIGRvbWFpbiBtdXN0IGJlIHVwZ3JhZGVkIHNvIHRoYXQgdGhleSBj b3VsZCANCj4+Pj4+Pj4gdW5kZXJzdGFuZCB0aGUgY29ubmVjdGl2aXR5IG1hdHJpY2VzIGFkdmVy dGlzZWQgYnkgdGhlDQo+Pj4gYm9yZGVyIG5vZGVzDQo+Pj4+Pj4+IGRlc2NyaWJpbmcgY29ubmVj dGl2aXR5IGNvbnN0cmFpbnRzIGJldHdlZW4gYWNjZXNzIGxpbmtzDQo+Pj4+PiBhbmQgdmlydHVh bA0KPj4+Pj4+PiBsaW5rcyB0aGV5IHRlcm1pbmF0ZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gIA0KPj4+Pj4+Pj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4+ Pj4+Pj4+IERBTklFTEUgQ0VDQ0FSRUxMSQ0KPj4+Pj4+Pj4gU3lzdGVtICYgVGVjaG5vbG9neSAt IFBEVSBPcHRpY2FsICYgTWV0cm8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBWaWEgRS5NZWxlbiwgNzcN Cj4+Pj4+Pj4+IEdlbm92YSwgSXRhbHkNCj4+Pj4+Pj4+IFBob25lICszOTAxMDYwMDI1MTINCj4+ Pj4+Pj4+IE1vYmlsZSArMzkzMzQ2NzI1NzUwDQo+Pj4+Pj4+PiBkYW5pZWxlLmNlY2NhcmVsbGlA ZXJpY3Nzb24uY29tIHd3dy5lcmljc3Nvbi5jb20NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGlzIENv bW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUNCj4+ Pj4+Pj4gZW1haWwgb24NCj4+Pj4+Pj4+IHRoZSBiYXNpcyBvZiB0aGUgdGVybSBzZXQgb3V0IGF0 DQo+Pj4gd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+Pj4+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBDQ0FN UEBpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+ Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcA0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gQ0NBTVAg bWFpbGluZyBsaXN0DQo+Pj4+PiBDQ0FNUEBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pj4NCj4+Pj4NCj4+Pg0KPj4gDQo+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFp bGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcA0K From lberger@labn.net Tue Jan 15 08:35:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E412D21F8870 for ; Tue, 15 Jan 2013 08:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.308 X-Spam-Level: X-Spam-Status: No, score=-101.308 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_93=0.6, MISSING_HEADERS=1.292, 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 ZxcoaI3jPcR2 for ; Tue, 15 Jan 2013 08:35:20 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 2393E21F8869 for ; Tue, 15 Jan 2013 08:35:20 -0800 (PST) Received: (qmail 4764 invoked by uid 0); 15 Jan 2013 16:34:56 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 15 Jan 2013 16:34:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:MIME-Version:From:Date:Message-ID; bh=MNSJTh9vn8Buo/1wCi0w36XW7TZ2EVq91HVARQNMJjc=; b=OYAJEJhbuSeU3qlUOdlFLHScNzt85M7HrxvR/YTbNuY4O11mUXBo3hQbZTTMClVk/a+JbmchtQaDSzObV4fpY9rWZW+MTbu9qMwgJzMFeob6NSZmBZzJW4CstJM0ooVG; Received: from box313.bluehost.com ([69.89.31.113]:39887 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Tv9TT-0006XU-MK for ccamp@ietf.org; Tue, 15 Jan 2013 09:34:55 -0700 Message-ID: <50F58537.3050302@labn.net> Date: Tue, 15 Jan 2013 11:35:03 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 CC: ccamp@ietf.org References: <20130115012259.6D474B1E004@rfc-editor.org> In-Reply-To: <20130115012259.6D474B1E004@rfc-editor.org> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] RFC 6825 on Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:35:21 -0000 Authors, Congratulations on getting this documented completed! I believe it is the longest tenured item that CCAMP has seen. Lou On 1/14/2013 8:22 PM, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6825 > > Title: Traffic Engineering Database Management Information > Base in Support of MPLS-TE/GMPLS > Author: M. Miyazawa, T. Otani, > K. Kumaki, T. Nadeau > Status: Standards Track > Stream: IETF > Date: January 2013 > Mailbox: ma-miyazawa@kddilabs.jp, > Tm-otani@kddi.com, > ke-kumaki@kddi.com, > tnadeau@juniper.net > Pages: 40 > Characters: 72765 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ccamp-gmpls-ted-mib-15.txt > > URL: http://www.rfc-editor.org/rfc/rfc6825.txt > > This memo defines the Management Information Base (MIB) objects for > managing the Traffic Engineering Database (TED) information with > extensions in support of the Multiprotocol Label Switching (MPLS) > with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for > use with network management protocols. [STANDARDS-TRACK] > > This document is a product of the Common Control and Measurement Plane Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Tue Jan 15 08:56:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C1021F8756 for ; Tue, 15 Jan 2013 08:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.822 X-Spam-Level: X-Spam-Status: No, score=-100.822 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_00=-2.599, CN_BODY_35=0.339, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, 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 MDVjSXF-EqNn for ; Tue, 15 Jan 2013 08:56:40 -0800 (PST) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 4E70E21F86D3 for ; Tue, 15 Jan 2013 08:56:40 -0800 (PST) Received: (qmail 17090 invoked by uid 0); 15 Jan 2013 16:56:15 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 15 Jan 2013 16:56:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=6lQE48cM9Jf5wJfbl4e70UGGdo+vDWOoEOGd6qq8BJk=; b=V2asuw7KM2iFBRV6ug8jFvJ2bt8jVZCJ3bDP4te7xQ9Qt4x98acJ4XqyZKCelFT9KOhYFtXEMhnkIXPmk4IgYKuvs8B8ve/o5H+/537jyzhFZML6ykEQd+hOq7JhRxCe; Received: from box313.bluehost.com ([69.89.31.113]:42485 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Tv9o6-0003lD-Nn; Tue, 15 Jan 2013 09:56:15 -0700 Message-ID: <50F58A35.7040806@labn.net> Date: Tue, 15 Jan 2013 11:56:21 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fatai Zhang References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:56:42 -0000 Fatai, Please see below for responses in-line . Lou On 1/15/2013 2:47 AM, Fatai Zhang wrote: > Hi Lou, > > Sorry for late response because of my vacation. > > Please see in-line below. > > > > > Best Regards > > Fatai > > -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, January 04, 2013 5:51 AM >> To: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 >> >> >> Hi Fatai, >> Happy new year. Please see below for responses. >> >> On 12/25/2012 3:33 AM, Fatai Zhang wrote: >>> >>> Hi Lou, >>> >>> Please see in-line below. >>> >>> A new version will be issued after all open issues are resolved. >>> >>> >>> >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> >>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, December 20, 2012 10:12 PM >>>> To: Fatai Zhang >>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: Re: 答复: [CCAMP] WG Last Call comments on >> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>> >>>> Fatai/Authors, >>>> Thank you for the mail, and sorry about my delayed response. BTW >>>> please feel free to continue discussing the remaining open issues on the >>>> list and reaching closure on the list (on specific text/resolutions) >>>> prior to publishing the next rev. >>>> >>>> Please see below for inline responses. >>>> >>>> On 12/7/2012 4:53 AM, Fatai Zhang wrote: >>>>> Hi Lou, >>>>> >>>>> Please see how the LC comments addressed below. >>>>> >>>>> Best Regards >>>>> >>>>> Fatai >>>>> >>>>> >>>>> -----邮件原件----- >>>>> 发件人: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 代表 >> Lou Berger >>>>> 发送时间: 2012年10月22日 10:01 >>>>> 收件人: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> 主题: [CCAMP] WG Last Call comments on >> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>> >>>>> Authors, >>>>> I have the following LC comments: >>>>> >>>>> General comments: >>>>> >>>>> - This document also needs some addition work on conformance language. >>>>> I'll try to point out cases in the detailed comments below. >>>>> >>>> [Fatai] OK. Checked and refined based on your detailed comments. >>>>> >>>> >>>> I think this rev is an improvement, but there's still more work needed. >>>> I have made some specific comments/suggestions below. >>>> >>>>> - Section 5 essentially defines a new set of traffic parameters. Given >>>>> the changes, why not ask for a new C-TYPE and not worry about [RFC4328] >>>>> compatibility/description? >>>>> >>>> [Fatai] Accepted to have a new C-TYPE and updated the text accordingly. >>>>> >>>> >>>> Okay. >>>> >>>>> Detailed editorial and technical comments: >>>>> >>>>> - Please verify that abbreviations are defined before being used . >>>>> There are a number of these. >>>>> >>>> [Fatai] Went through and updated. >>>> >>>> thanks. >>>> >>>>> >>>>> - Please use a consistent decimal representation (sometimes commas are >>>>> used other times periods) >>>>> >>>> [Fatai] OK. Commas are used. >>>> >>>> great, although a quick skim finds: >>>> s/1,301.683.217/1,301,683.217 >>>> >>>> >>>> >>>>> >>>>> - the references [G709-v1] and [G709-v3] each actually refer to multiple >>>>> documents, each documented needs to have it's own (correct) reference, >>>>> i.g., [G709-v1] and [G709-v1a1]. The document text will need to be >>>>> revisited to ensure the proper reference is made. >>>>> >>>> [Fatai] Accepted and used the same approach for framework draft. >>>> >>>> great >>>> >>>> >>>>> - >>>>> >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-04.txt >>>>> shows there are unresolved nits that need to resolved . >>>> >>>> >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-05.txt >>>> still shows a warning, notably: >>>> >>>> (Using the creation date from RFC4328, updated by this document, for >>>> RFC5378 checks: 2005-01-17) >>>> >>>> -- The document seems to lack a disclaimer for pre-RFC5378 work, >> but may >>>> have content which was first submitted before 10 November 2008. >> If you >>>> have contacted all the original authors and they are all willing >> to grant >>>> the BCP78 rights to the IETF Trust, then this is fine, and you >> can ignore >>>> this comment. If not, you may need to add the pre-RFC5378 >> disclaimer. >>>> (See the Legal Provisions document at >> http://trustee.ietf.org/license-info for more information.) >>>> >>> [Fatai] Will update “Copyright Notice” section. >> >> okay >> >>>> >>>>> I'm using line >>>>> numbers from this url in my subsequent comments. >>>>> >>>> [...] >>>> >>>>> - Section 3. Perhaps combine with section 1. >>>>> >>>> [Fatai] Accepted and refined. >>>>> >>>> >>>> I don't see where this suggestion was followed, but that's okay, it was >>>> just a suggestion. >>>> >>> [Fatai] OK. >>>> >>>> [...] >>>>> - Section 5: assuming this is now a new c-type need text for that, as >>>>> well as to formally defined the fields/field sizes. >>>>> >>>> [Fatai] Accepted to have a new C-TYPE and updated the text accordingly. >>>> >>>> Formal field definitions are missing and need to be added. >>>> >> >>> [Fatai] The format is the same as RFC4328. Did you mean that it >>> needs “Length”, “Class-Num” and “C-Type”? If yes, I will add >>> them. If you mean that it needs text to define all the fields, I >>> think the text is already there (then this comment may be related >>> to your other comments below). >> >> Its important to differentiate the syntax (i.e., format) from the >> semantics (i.e., usage). How about: >> >> Signal Type: 8 bits >> As defined in [RFC4328] Section 3.2.1, with the following additional >> values: >> (insert lines 266-285) >> >> Reserved: 8 bits >> As defined in [RFC4328] Section 3.2.5. >> >> Tolerance: 16 bits >> (insert lines 296-298) >> >> NVC: 16 bits >> As defined in [RFC4328] Section 3.2.3. >> >> Multiplier (MT): 16 bits >> As defined in [RFC4328] Section 3.2.4. >> >> Bit_Rate: 32 bits >> (insert lines 290-294) >> >> The other parts, lines 287-288, 300-319 should be merged into section 5.1. >> > [Fatai] Got it. OK to accept your suggestion and try to update the > text in this way. I assume this is a statement not a question. Let me know if there is a question, or discussion point here. >> >>>> >>>> Also the draft says: >>>> >>>> Note that the error process on the traffic parameters MUST follow the >>>> rules defined in Section 6 of [RFC4328]. >>>> >>>> Given the different fields, shouldn't any OTN-TDM related traffic >> parameter processing now be defined in this document? >>>> >>> [Fatai] I just wanted to avoid the overlapped text (almost the same >> text as RFC4328). Will accept your suggestion to expand the text as follows: >>> >>> There is no Adspec associated with the OTN-TDM SENDER_TSPEC. Either >>> the Adspec is omitted or an Int-serv Adspec with the Default General >>> Characterization Parameters and Guaranteed Service fragment is used, >>> see [RFC2210]. >>> >>> For a particular sender in a session, the contents of the FLOWSPEC >>> object received in a Resv message SHOULD be identical to the contents >>> of the SENDER_TSPEC object received in the corresponding Path >>> message. If the objects do not match, a ResvErr message with a >>> "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. >>> >>> Intermediate and egress nodes MUST verify that the node itself, and >>> the interfaces on which the LSP will be established, can support the >>> requested Signal Type, NVC, Tolerance and Bit_Rate values. If the >>> requested value(s) cannot be supported, the receiver node MUST >>> generate a PathErr message with a "Traffic Control Error/Service >>> unsupported" indication (see [RFC2205]). >>> >>> In addition, if the MT field is received with a zero value, the node >>> MUST generate a PathErr message with a "Traffic Control Error/Bad >>> Tspec value" indication (see [RFC2205]). >>> >> >> Is this a new section, perhaps 5.3? >> > [Fatai] Yes. Try to add a new section to describe what you want. Hereto, I assume this is a statement of intent not a question. Let me know if there is a question, or discussion point here. >> >>>> >>>>> >>>> [...] >>>>> >>>>> - Lines 320-336,338-346 are essentially repeated in sections 5.1 and >>>>> 5.2, why not move this text into their respective sections? >>>>> >>>> [Fatai] Accepted and refined the text. >>>> >>>> >>>> I don't see where this suggestion was followed. For example: >>>> >>>> 287 In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be >>>> 288 used together to represent the actual bandwidth of ODUflex, where: >>>> >>>> and >>>> >>>> 323 In case of ODUflex(CBR), the information of Bit_Rate and >> Tolerance in >>>> 324 the ODUflex traffic parameters MUST be used to determine the total >>>> 325 number of tributary slots N in the HO ODUk link to be reserved. Here: >>>> >>> [Fatai] Sorry I should not say “Accepted and refined the text.” >>> last time. They are not repeated. here, the text just describes the >>> meaning of the corresponding fields (as we always do), so the above >>> text should be there irrespectively. Section 5.1 & section 5.2 >>> describe “how” with more detail information including formulation, >>> Table information and example. >>> >> If the text in the early part of 5 is revised as I suggest above (and >> the other lines are merged as suggested above) then this comment will be >> resolved. >> > [Fatai] OK. >> >>>> >>>>> >>>>> - lines 445-468: Why not just carry "n" directly? >>>>> >>>> [Fatai] to make it consistent with ODUflex(CBR). >>>> >>>> Given that the recent decision to have an OTN-TDM specific set of >>>> traffic parameters, doesn't it now make sense to just carry N directly? >>>> >>> [Fatai] No. “N” cannot be used for ODUflex(CBR) case. >> >> Do you really mean "cannot"? I may be missing something, but it would >> seem less ambiguous/prone to interop issues if N was directly carried. >> > [Fatai] My misunderstanding here. I thought you proposed to replace > “bit rate” with “N”. Great. >> >>> It is better >>> to have consistent format and the same meaning of one field for both >>> ODUflex(CBR) and GFP. This is why we have section 5.1 &5.2 to >>> describe the complex stuff. >>> >> >> I actually wasn't suggesting that N be carried in the bit rate field. >> The bit rate field can either be set as described or to zero (i.e., >> ignored). At the time, I was thinking about carrying N in the reserved >> field. But perhaps the right place is MT, if my understanding is right >> (would always be 1 otherwise). I'm open to either... >> > [Fatai] Why not just use “bit rate” field to carry “N” because “N” > implies bit rate? I am OK if you like to use a new filed (like “TS > Number”) to occupy the reserved field even though that I prefer the > original approach (ie., use “bit rate” field to carry “N”). Are you proposing dropping carrying bit rates represented as an IEEE floating point and just carrying N for ODUflex? This seems workable to me, but we should ensure that there are no significant objections. > BTW, I don’t think MT is the right place (it will cause ambiguity if > MT is used to indicate “TS Number”). I'm not sure which case you're referring to, but I don't think we need to worry about it given your proposed encoding. >> >> >>>> >>>> [...] >>>> >>>>> >>>>> - Line 576: "Padded bits" seems off, how about "Pad bits" or "Padding", >>>> >>>> Again, how about "Pad bits" or "Padding"? >>>> >>> [Fatai] OK. Should use “Pad bits” instead of “Padding bits” >> >> “Pad bits” it is... >> >>>> >>>>> also bits aren't represented in label format (line 494)., also "behind" >>>>> --> "after" >>>>> >>>> [Fatai] Accepted and updated. >>>>> >>>> >>>> [...] >>>> >>>>> >>>>> - Lines 658-660. The normative language in 4328 isn't actually >>>>> presented in the section titled "label distribution procedures" (or >>>>> "rules" as section 4.2 is actually titled), so this paragraph doesn't >>>>> make sense. I suggest either (a) defining the full set of required >>>>> procedures in this document, or (b) referring to the "required >>>>> processing defined in [RFC4328]" and other rfcs as appropriate. >>>>> >>>> [Fatai] Accepted and updated accordingly. >>>>> >>>>> - Lines 662-667: what about generating upstream, suggested, label set, >>>>> etc. Perhaps you should rephrase much into more general rules. >>>>> >>>> [Fatai] Accepted and updated accordingly. >>>>> >>>> >>>> I think section 6.2 still needs a bit of work. >>>> >>>> So are there procedures that an ingress must follow? >>>> For example: >>>> - Setting of fields in the label request object, such as the OTN-TDM >>>> Switching Type defined in [OTN-OSPF]. >>>> >>>> What about the egress, are there any special procedures? >>>> >>>> The final three paragraphs of the section introduce upstream behaviors >>>> *after* you've described the downstream behavior without specifics of >>>> the new upstream behavior. As a general rule and in this case in >>>> particular, I really think it would be better to cover procedures in the >>>> following order >>>> - Ingress >>>> - Generic upstream >>>> - Generic downstream >>>> - Egress >>>> >>>> Also, generic statements should not use conformance language, >>>> particularly when more detailed rules/procedures, which include such >>>> language, follow. >>>> >>>> If you'd like we can discuss/review details on the list once you have a >>>> proposed revision. (I see a bunch of more minor comments on this >>>> section, but don't think it makes sense to focus on these until the more >>>> major comments are addressed.) >>>> >>> [Fatai] Will refine the text based on your suggestion. Do I need to >>> copy so much text here for review? >> >> It's up to you, but personally, I think it's better to discuss the text >> on the list first rather than publishing and then discuss/wordsmith. >> But this is just a personal preference. Either way works. (draft >> revision numbers are cheap after all.) >> > [Fatai] OK, I will issue a new version to capture all the updates and > make it easy for people to converge. As you wish. >> >>>> >>>> >>>> [...] >>>>> >>>>> - Lines 682-685: Who is this learning/identification accomplished? >>>>> >>>> [Fatai] Accepted and updated. >>>>> >>>>> - Lines 703-704: If this is the normative section defining requirement >>>>> processing, the procedures need to be spelled out for all required >> cases. >>>>> >>>> [Fatai] Accepted and updated accordingly. >>>>> >>>>> - Lines 706-707: I think this needs to be rephrased to be clear what >>>>> behavior is required for a node to be conformant with this sentence. >>>>> >>>> [Fatai] Accepted and refined accordingly. >>>>> >>>>> - Lines 711-714: why "SHOULD" vs "MUST"? >>>>> >>>> [Fatai] Accepted and updated. >>>>> >>>> >>>> I'll defer responses to the discussion on prior comment. >>>> >>>>> - Line 712: By "integrity of the label" do you mean "if the label is >>>>> acceptable"? >>>>> >>>> [Fatai] Yes, and updated. >>>>> >>>>> >>>>> - Line 725: By "reserved resource" do you mean "indicated resource"? >>>>> >>>> [Fatai] Yes, and updated. >>>>> >>>>> - Line 726: Does "do not match" mean "inconsistent"? >>>>> >>>> [Fatai] Yes, and updated. >>>> >>>> WRT lines 624-627, I think you still need additional specificity >>>> differentiate upstream/downstream required behavior. Perhaps something >>>> along the lines of: >>>> >>>> When an upstream node receives a Resv message containing an >> >> s/an/a >> >>>> LABEL object with an OTN-TDM label, the node MUST verify that >>>> the label is acceptable. If the label is not acceptable, the >>>> node MUST generate a ResvErr message with a "Routing >>>> problem/Unacceptable label value" indication. Per [RFC3473], >>>> the generated ResvErr message MAY include an >>>> ACCEPTABLE_LABEL_SET object. With the exception of label >>>> semantics, Downstream node processing a received ResvErr >>>> messages and of ACCEPTABLE_LABEL_SET objects is not modified >>>> by this document. >>>> >>>> Similarly, when a downstream node receives a Path message >>>> containing an UPSTREAM_LABEL object with an OTN-TDM label, >>>> the node MUST verify that the label is acceptable. If the >>>> label is not acceptable, the node MUST generate a PathErr >>>> message with a "Routing problem/Unacceptable label value" >>>> indication. Per [RFC3473], the generated ResvErr message MAY >>>> include an ACCEPTABLE_LABEL_SET object. With the exception >>>> of label semantics, Downstream node processing received >>>> PathErr messages and of ACCEPTABLE_LABEL_SET objects is not >>>> modified by this document. >>>> >>>> A received label SHALL be considered unacceptable when one of >>>> the following cases occurs: >>>> >>>> - The received label doesn't conform with local policy. >>>> >>> [Fatai] OK. Accept your proposed text. >>>> ... >>>> >>>>> >>>>> - Line 730, Drop "As". >>>>> >>>> [Fatai] Accepted and updated. >>>>> >>>>> - Section 6.4: Missing conformance language. >>>>> >>>> [Fatai] Went through and updated. >>>> >>>> New line 660: The procedures are similar to section 6 of [RFC6344]. >>>> >>>> Hereto, If this is the normative section defining required processing, >>>> the procedures need to be spelled out for all required cases or refer to >>>> specific (and unmodified) procedures to follow in a reference document. >>>> So either define the processing or say procures defined in >>> reference> are followed. >>>> >>> [Fatai] OK, I think it is better to say “The procedures MUST follow >>> Section 5 of [RFC6344].” >> >> Are there any procedures defined in section6.3 that differ/add to 6344? >> If I'm not mistaken, the only thing is that ODUflex signal types cannot >> use "multiplication". (Please confirm.) >> >> Assuming I'm correct, how about replacing the contents of the section >> with something along the lines of: >> >> Support for Virtual Concatenation, as defined by [RFC6344], is not >> modified by this document. With the exception of ODUflex signal >> types, signal multiplication as defined in [RFC6344] and [RFC4328]. s/as/is as >> > [Fatai] Right. Will accept your proposed text. great >> >>>> >>>>> >>>>> - Lines 758-759: This reads like an informative statement, but includes >>>>> conformance language. How does a node conform? I suggest rephrasing to >>>>> be clear. >>>>> >>>> [Fatai] Accepted and updated. >>>>> >>>> >>>> I think this section should be revised to ensure that the >>>> responsibilities of each type of processing node (ingress, upstream, >>>> downstream, egress) is clear. >>>> >>>> I guess, we'll have a thread on this section too... >>>> >>> [Fatai] Will refine the text based on your suggestion. >> >> great. >> >>>> >>>> [...] >>>> >>>>> >>>>> - Section 9, should also reference 4328 and cover delta in information >>>>> and added risks. >>>>> >>>> [Fatai] Accepted and updated. >>>> >>>> We'll see if this is enough to keep the security reviewers happy... >>>> >>>>> >>>>> - Section 10: This section needs some work. (I'm assuming your familiar >>>>> with rfc5226). >>>>> >>>> [Fatai] Accepted and updated. >>>>> >>>> >>>> Better, but you should at least refer to the existing registries, >> which already includes G-PIDs (see >>>> >> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml) >>>> >>>>> - Is it time to create a "Signal Type" registry? >>>>> >>>> [Fatai] We are not sure, because no "Signal Types" have been >> registered in the existing RFCs (like RFC3473, RFC4328..). >>>>> >>>> >>>> I think including a request to establish such a registry in this >>>> document would be useful. Is anyone up to proposing the requisite text? >>>> >>> [Fatai] OK to register “Signal Type”. >> >> Is this a question or statement? >> > [Fatai] A statement. I am planning to register “Signal Type”. great. Thanks, Lou > If anyone has any opinion on this point, please share your comments > before I update. >> >> Thanks, >> Lou >> >>>> >>>> Value Signal Type Reference >>>> ----- ----------- --------- >>>> 0 Not significant [this document] >>>> 1 ODU1 (i.e., 2.5 Gbps) [this document] >>>> 2 ODU2 (i.e., 10 Gbps) [this document] >>>> 3 ODU3 (i.e., 40 Gbps) [this document] >>>> 4 ODU4 (i.e., 100 Gbps) [this document] >>>> 5 Reserved (for future use) [this document] >>>> 6 Optical Channel (Och) at 2.5 Gbps [this document] >>>> 7 OCh at 10 Gbps [this document] >>>> 8 OCh at 40 Gbps [this document] >>>> 9 OCh at 100 Gbps [this document] >>>> 10 ODU0 (i.e., 1.25 Gbps) [this document] >>>> 11 ODU2e (i.e., 10Gbps for FC1200 [this document] >>>> and GE LAN) >>>> 12~19 Reserved (for future use) [this document] >>>> 20 ODUflex(CBR) (i.e., 1.25*N Gbps) [this document] >>>> 21 ODUflex(Generic Framing [this document] >>>> Procedure-Framed (GFP-F)), >>>> resizable (i.e., 1.25*N Gbps) >>>> 22 ODUflex(GFP-F), non resizable [this document] >>>> (i.e., 1.25*N Gbps) >>>> 23~255 Reserved (for future use) [this document] >>>> >>>> >>>> Thanks, >>>> Lou >>>> >>>> >>>>> That's it on this document. >>>>> >>>>> Lou >>>>> - >>>> >> From morita@kddilabs.jp Tue Jan 15 16:28:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD2111E80DE; Tue, 15 Jan 2013 16:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6] 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 75jgsxiis2gJ; Tue, 15 Jan 2013 16:28:55 -0800 (PST) Received: from zen.kddilabs.jp (zen.kddilabs.jp [IPv6:2001:200:601:12::31]) by ietfa.amsl.com (Postfix) with ESMTP id B51DE11E80AE; Tue, 15 Jan 2013 16:28:52 -0800 (PST) Received: from localhost (zen.kddilabs.jp [127.0.0.1]) by zen.kddilabs.jp (Postfix) with ESMTP id AC4AB17480FF; Wed, 16 Jan 2013 09:28:48 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from zen.kddilabs.jp ([127.0.0.1]) by localhost (zen.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2Er1HTO2K-r; Wed, 16 Jan 2013 09:28:47 +0900 (JST) Received: from localhost (pink.lan.kddilabs.jp [172.19.98.9]) by zen.kddilabs.jp (Postfix) with ESMTP id 929E617480FC; Wed, 16 Jan 2013 09:28:47 +0900 (JST) Received: from [172.19.110.31] (dhcp31.wlan.kddilabs.jp [172.19.110.31]) by localhost (Postfix) with ESMTP id 85D9B34E8327; Wed, 16 Jan 2013 09:28:47 +0900 (JST) Message-ID: <50F5F43F.9060609@kddilabs.jp> Date: Wed, 16 Jan 2013 09:28:47 +0900 From: Itsuro Morita User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mpls@ietf.org, ccamp@ietf.org, pce@ietf.org, mpls-tp@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Jan 2013 16:44:27 -0800 Subject: [CCAMP] iPOP2013 1st CFP X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 00:32:55 -0000 (Apologies if you received multiple copies of this message.) Dear CCAMP, PCE, MPLS and MPLS-TP subscribers, iPOP2013 Call for Presentation is now open as follows. The deadline for submitting presentation proposal is February 15th, 2013. Best Regards, iPOP2013 TPC Co-Chair Eiji Oki and Itsuro Morita --------------------------------------------------------------------- Call for Presentation 9th International Conference on IP + Optical Network (iPOP 2013) May 30 - 31, 2013 TKP Otemachi Conference Center, KDDI Otemachi Build., Tokyo, Japan http://www.pilab.jp/ipop2013/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 15, 2013 Notification of acceptance: March 29, 2013 Submission deadline of final presentation slides: April 19, 2013 The Technical Program Committee for iPOP 2013 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not be limited to the following: * Photonic Network for NxGN and NwGN * Multi-layer network (MLN) / Multi-region network (MRN) * Inter-area/Inter-AS network * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS/ASON technologies * GMPLS Network management, OA&M * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Path Computation Element (PCE), Traffic engineering * Application with high-bandwidth demand * L1VPN, Bandwidth on Demand, and Photonic Grid * MPLS and Ethernet networking for Inter-data center connectivity for cloud computing * Carrier Ethernet and MPLS-TP for backhauling * Software Defined Networking * Optical Networking/Switching for Cloud Services * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstracts of 400 words and a maximum of 1 page, including figures and diagrams, speaker$B!G(Bs name, affiliation, and contact information to the Technical Program Committee at ipop2013-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2013/ for more details. From zhangfatai@huawei.com Tue Jan 15 19:16:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB5611E80AD for ; Tue, 15 Jan 2013 19:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.462 X-Spam-Level: X-Spam-Status: No, score=-5.462 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=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 RQLRbCK2NcPV for ; Tue, 15 Jan 2013 19:16:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1750D11E80A2 for ; Tue, 15 Jan 2013 19:16:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOU73812; Wed, 16 Jan 2013 03:16:10 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Jan 2013 03:16:00 +0000 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Jan 2013 03:16:09 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Wed, 16 Jan 2013 11:16:01 +0800 From: Fatai Zhang To: Lou Berger Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 Thread-Index: AQHN4nqPdVRTcHuIFUSv0ekPirccYZg3rcsAgBJvoeCAABn/gIABKi7g Date: Wed, 16 Jan 2013 03:16:00 +0000 Message-ID: References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> <50F58A35.7040806@labn.net> In-Reply-To: <50F58A35.7040806@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF835856301SZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 03:16:17 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF835856301SZXEML552MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lou, To avoid misunderstanding, I would like to clarify more on the following po= int. >>> It is better to have consistent format and the same meaning of one fiel= d for both ODUflex(CBR) and GFP. This is why we have section 5.1 &5.2 to de= scribe the complex stuff. >> I actually wasn't suggesting that N be carried in the bit rate field. >> The bit rate field can either be set as described or to zero (i.e., >> ignored). At the time, I was thinking about carrying N in the reserved >> field. But perhaps the right place is MT, if my understanding is right >> (would always be 1 otherwise). I'm open to either... >> > [Fatai] Why not just use "bit rate" field to carry "N" because "N" > implies bit rate? I am OK if you like to use a new filed (like "TS > Number") to occupy the reserved field even though that I prefer the > original approach (ie., use "bit rate" field to carry "N"). Are you proposing dropping carrying bit rates represented as an IEEE floating point and just carrying N for ODUflex? This seems workable to me, but we should ensure that there are no significant objections. [Fatai] There are two usages for " Bit_Rate " field as described in the lin= es 287-310. (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal bit rate = of ODUflex(CBR) expressed in bytes per second, encoded as a 32-bit IEEE sin= gle precision floating-point number. For this case, we MUST use 32-bit IEEE= floating point instead of "N" (Please see more in section 5.1). (2) For ODUflex(GFP), we can change the text (the lines from 305 to 310)= based on your suggestion, ie., the Bit_Rate field is used to carry "N" to = indicate the nominal bit rate of the ODUflex(GFP). Therefore, I am proposing using one single filed ("Bit_Rate ") for these tw= o cases, in this way, we can leave the "Reserved" bits for future. Hope we are now at the same page. Best Regards Fatai --_000_F82A4B6D50F9464B8EBA55651F541CF835856301SZXEML552MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lou,

 

To avoid misunderstanding, I= would like to clarify more on the following point.

 

 

>>> It is better to= have consistent format and the same meaning of one field for both ODUflex(= CBR) and GFP. This is why we have section 5.1 &5.2 to describe the comp= lex stuff.

>> I actually wasn't s= uggesting that N be carried in the bit rate field.

>> The bit rate field = can either be set as described or to zero (i.e.,

>> ignored).  At = the time, I was thinking about carrying N in the reserved=

>> field. But perhaps = the right place is MT, if my understanding is right

>> (would always be 1 = otherwise). I'm open to either...

>> 

> [Fatai] Why not just us= e “bit rate” field to carry “N” because &= #8220;N”<= /o:p>

> implies bit rate? = I am OK if you like to use a new filed (like &= #8220;TS

> Number”) to occupy the reserved field even though that I prefer t= he

> original approach (ie.,= use “bit rate” field to carry “N”).

 

Are you proposing dropping c= arrying bit rates represented as an IEEE

floating point and just carr= ying N for ODUflex? This seems workable to

me, but we should ensure tha= t there are no significant objections.

 

[Fat= ai] There are two usages for " Bit_Rate " field as described in t= he lines 287-310.

 

(1)    For ODUflex(CBR), the Bit_Rate field indicates the nominal bit rate of ODU= flex(CBR) expressed in bytes per second, encoded as a 32-bit IEEE single pr= ecision floating-point number. For this case, we MUST use 32-bit IEEE floating point instead of R= 20;NR= 21; (Please see more in section 5.1).

 

(2)    For ODUflex(GFP), we can change the text (the lines from 305 to 310) based= on your suggestion, ie., the Bit_Rate field is used to carry R= 20;N”= to indicate the nominal bit rate of the

ODUflex(GFP).

 

Ther= efore, I am proposing using one single filed ("Bit_Rate ") for th= ese two cases, in this way, we can leave the "Reserved" bits for = future.

&= nbsp;

Hope= we are now at the same page.

&= nbsp;

&= nbsp;

Best R= egards

&= nbsp;

Fatai<= o:p>

--_000_F82A4B6D50F9464B8EBA55651F541CF835856301SZXEML552MBXchi_-- From daniele.ceccarelli@ericsson.com Wed Jan 16 00:48:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608DE21F84E0 for ; Wed, 16 Jan 2013 00:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=-3.231, BAYES_00=-2.599, CN_BODY_35=0.339, HELO_EQ_SE=0.35, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 D50Fa0pPOUQ9 for ; Wed, 16 Jan 2013 00:48:03 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 69D9A21F84C6 for ; Wed, 16 Jan 2013 00:47:59 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-bb-50f6693d697d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B6.AD.19728.D3966F05; Wed, 16 Jan 2013 09:47:57 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 09:47:57 +0100 From: Daniele Ceccarelli To: Gert Grammel , Lou Berger Thread-Topic: [CCAMP] Overlay model framework and context Thread-Index: Ac3cSA0EmhmMt2XQR3eDsLDm5eAESgAPpvQAAFPqDzAAC9tFgAAL4JUAAAV55wAAE0X84AAHy6cAAAMVafD///jrgP//7dYAgCj7tID//t4aMA== Date: Wed, 16 Jan 2013 08:47:57 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806BF0C@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48042C3B@ESESSMB301.ericsson.se> <50CF764E.603@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045007@ESESSMB301.ericsson.se> <50D248B8.1090506@labn.net> <4A1562797D64E44993C5CBF38CF1BE480456A7@ESESSMB301.ericsson.se> <50D32320.3010707@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045B14@ESESSMB301.ericsson.se> <50D331E1.5000703@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045BBA@ESESSMB301.ericsson.se> <305443B66F0CD946A3107753337A03111311938B@CH1PRD0511MB431.namprd05.prod.outlook.com> In-Reply-To: <305443B66F0CD946A3107753337A03111311938B@CH1PRD0511MB431.namprd05.prod.outlook.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvja5t5rcAg5ffzCyezLnBYrFk1zIW i47mtywOzB5Llvxk8rjedJXd48OmZrYA5igum5TUnMyy1CJ9uwSujMfTnrMU9F1irGhu+8na wHjnDGMXIyeHhICJxMpJT6BsMYkL99azgdhCAocYJW71B3YxcgHZixklzh+6xtrFyMHBJmAl 8eSQD0iNiICbRM+ms8wgNrOAlMTdW11gc4QFLCTWrj3ICFFjKdG0ejorhF0nsX7XZ7B6FgFV iTOP54LZvALeEk9mdbNC7NrFKrHw5GKwBk6BRImTm7vYQWxGAVmJCbsXMUIsE5e49WQ+E8TR AhJL9pxnhrBFJV4+/scKYStK7DzbDnWclsS8ht9MELaixJTuh+wQiwUlTs58wjKBUWwWkrGz kLTMQtIyC0nLAkaWVYzsuYmZOenlRpsYgbFzcMtv1R2Md86JHGKU5mBREucNd70QICSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoFRKMDb/H+z5hseqyX6zzOFqxncDV0KvUIMljxlW3VBd9bp kvpuzl6nJuZNXruabqudOl8atTFL6ma4M5fTCWb5GCHtzyvWXjxuMdG7Qjr2dLlyHidfrGz/ 5/mXQh/Myp0UeIb1VtLdGP8/ovXbn+nIXGw5zDh5Sc2Z/Ei9havSbzPEPdAXXqnEUpyRaKjF XFScCACwFWOBawIAAA== Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework and context X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 08:48:04 -0000 SGkgR2VydCwNCg0KSSdtIHdvcmtpbmcgb24gaXQuLi5pbiB0aGVzZSBkYXlzIHRoZSBsaXN0IHdh cyBub3QgYnVzeSBvbiB0aGUgb3ZlcmxheSBidXQgd2FzIG9uIHRoZSBPVE4gOi0pDQoNCkl0IHdp bGwgYmUgYXZhaWxhYmxlIGFsIGxhdGVzdCB0b21vcnJvdy4NCg0KQ2lhbw0KRGFuaWVsZQ0KDQo+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBHZXJ0IEdyYW1tZWwgW21haWx0bzpn Z3JhbW1lbEBqdW5pcGVyLm5ldF0gDQo+U2VudDogbWFydGVkqKwgMTUgZ2VubmFpbyAyMDEzIDE3 LjI5DQo+VG86IERhbmllbGUgQ2VjY2FyZWxsaTsgTG91IEJlcmdlcg0KPkNjOiBDQ0FNUA0KPlN1 YmplY3Q6IFJFOiBbQ0NBTVBdIE92ZXJsYXkgbW9kZWwgZnJhbWV3b3JrIGFuZCBjb250ZXh0DQo+ DQo+SGkgRGFuaWVsZSwNCj4NCj5UaGUgbGlzdCB3YXNuJ3Qgc28gYnVzeSBhbnltb3JlIGluIDIw MTMgYXMgaXQgd2FzIHRoZSB5ZWFyIA0KPmJlZm9yZS4gV291bGQgeW91IG1pbmQgdG8gc3VtbWFy aXplIHdoYXQgaXMgcGVyY2VpdmVkIHRoZSANCj53b3JkaW5nL2FiYnJldmlhdGlvbnMgd2UgYXJl IGNvbnZlcmdpbmcgdG8/IFRoaXMgd2F5IHdlIGNvdWxkIA0KPnN0YXJ0IHVwZGF0aW5nIHRoZSB3 b3JkaW5nIG9mIHRoZSBFTk5JIGZyYW1ld29yayBkb2N1bWVudC4NCj4NCj5CZXN0DQo+DQo+R2Vy dA0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogY2NhbXAtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIA0KPk9uIEJlaGFsZiBPZiBE YW5pZWxlIENlY2NhcmVsbGkNCj5TZW50OiBEb25uZXJzdGFnLCAyMC4gRGV6ZW1iZXIgMjAxMiAx Njo1Mg0KPlRvOiBMb3UgQmVyZ2VyDQo+Q2M6IENDQU1QDQo+U3ViamVjdDogUmU6IFtDQ0FNUF0g T3ZlcmxheSBtb2RlbCBmcmFtZXdvcmsgYW5kIGNvbnRleHQNCj4NCj5Zb3UgdGhvdWdodCB0aGUg d29ybGQgd2FzIGdyZXksIEkgc3BlbnQgaGFsZiBhbiBob3VyIHRvIHdyaXRlIA0KPmFuIGVtYWls IHRyeWluZyB0byBjb252aW5jZSB5b3UgdGhhdCB3b3JsZCBpcyB3aGl0ZSBhbmQgbm93IA0KPnlv dSdyZSBjb252aW5jZWQgdGhhdCB0aGUgd29ybGQgaXMgYmxhY2shISEgIDopDQo+DQo+DQo+Pi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVy Z2VyQGxhYm4ubmV0XQ0KPj5TZW50OiBnaW92ZWSorCAyMCBkaWNlbWJyZSAyMDEyIDE2LjQyDQo+ PlRvOiBEYW5pZWxlIENlY2NhcmVsbGkNCj4+Q2M6IEZhdGFpIFpoYW5nOyBJZ29yIEJyeXNraW47 IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgQ0NBTVANCj4+U3ViamVjdDogUmU6IFtDQ0FNUF0g T3ZlcmxheSBtb2RlbCBmcmFtZXdvcmsgYW5kIGNvbnRleHQNCj4+DQo+PkRhbmllbGUsDQo+Pg0K Pj5UaGUgcGllY2UgdGhhdCdzIG1pc3NpbmcgZnJvbSB5b3VyIG1haWwgaXMgdGhhdCB5b3VyICJ2 cG4iIA0KPj50ZXJtcyBoYXZlIHdpZGVyIHNjb3BlIHRoYW4ganVzdCBWUE5zLiAgRm9yIGV4YW1w bGUgQ0VzLCBQRXMsIGFjY2Vzcw0KPj5pbnRlcmZhY2VzfGxpbmtzLCBpbnRlci1kb21haW4gaW50 ZXJmYWNlc3xsaW5rcyBoYXZlIHNjb3BlIHdlbGwgYmV5b25kDQo+PlZQTnMuDQo+Pg0KPj5BbiBh bHRlcm5hdGUgY29uY2x1c2lvbiAod2hpY2ggeW91IGhhdmUgbWUgbm93IGxlYW5pbmcNCj4+dG93 YXJkcykgaXMgdGhhdCB3ZSBzaG91bGQganVzdCB1c2UgQ0UgYW5kIFBFIGluIHBsYWNlIG9mIE9F IGFuZCBPQy4NCj4+DQo+PkxvdQ0KPj4NCj4+T24gMTIvMjAvMjAxMiAxMDozMiBBTSwgRGFuaWVs ZSBDZWNjYXJlbGxpIHdyb3RlOg0KPj4+IEV4Y2VsbGVudCwNCj4+PiANCj4+PiBTbyB5b3UnZCBh Z3JlZSB3aXRoIHRoZSBnZW5lcmFsIG92ZXJsYXkgZGVmaW5pdGlvbnMgb2YgT0MNCj4+YW5kIE9F LiAod2hpY2ggaW4gdGhlIGNhc2Ugb2YgVlBOcyB3aWxsIGJlIGNhbGxlZCBDRSBhbmQgUEUpLg0K Pj4+IA0KPj4+IFdoYXQgYWJvdXQgYW4gYW5hbG9nb3VzIGFwcHJvYWNoIHdoZW4gd2UgbW92ZSBm cm9tIG5vZGVzIHRvDQo+PmludGVyZmFjZXMvbGlua3MuIEEgZ2VuZXJhbCBuYW1lIGZvciB0aGUg b3ZlcmxheSBtb3N0IGdlbmVyYWwgY2FzZSANCj4+d2hlcmUgc3BlY2lmaWMgZXhpc2l0bmcgbmFt ZXMgY2FuIGJlIHBsYWNlcyAodGhlIGZhbW91cyB1bWJyZWxsYSkuDQo+Pj4gDQo+Pj4gLSBJbiB0 aGUgbW9yZSBnZW5lcmljIGNhc2Ugb2Ygb3ZlcmxheTogdGhlIG5vZGVzIGFyZSBjYWxsZWQNCj4+ T0MgYW5kIE9FDQo+Pj4gYW5kIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBPQyBhbmQgT0UgaXMgY2Fs bGVkIChPTkksIE9JLCANCj5PQ0ksIHh4eGxpbmsgDQo+Pj4gb3Igd2hhdGV2ZXIpDQo+Pj4gLSBJ biB0aGUgY2FzZSBvZiBpbnRlcmZhY2Ugc3VwcG9ydGluZyBzaWduYWxpbmcgb25seTogVGhlIChP TkksIE9JLCANCj4+PiBPQ0ksIHh4eGxpbmsgb3Igd2hhdGV2ZXIpIGlzIGEgcGFydGljdWxhciBj YXNlIG9mIChPTkksIE9JLCBPQ0kgb3INCj4+PiB3aGF0ZXZlcikgYW5kIGlzIGNhbGxlZCBVTkks IGFuZCB0aGUgbm9kZXMgYXQgaXRzIGVuZHMgYXJlIA0KPmNhbGxlZCBDTiANCj4+PiBhbmQgRU4g KFJGQzQyMDgpDQo+Pj4gLSBJbiB0aGUgY2FzZSBvZiBWUE5zOiB0aGUgKE9OSSwgT0ksIE9DSSwg eHh4bGluayBvcg0KPj53aGF0ZXZlcikgaXMgY2FsbGVkIGFjY2VzcyBsaW5rIGFuZCB0aGUgbm9k ZXMgYXJlIGNhbGxlZCBDRSBhbmQgUEUuDQo+Pj4gDQo+Pj4gSSBzZWUgbm8gb3RoZXIgd2F5IG9m IHB1dHRpbmcgc29tZSBvcmRlciBhbW9uZyBhbGwgdGhlDQo+PmFscmVhZHkgZXhpc3RpbmcgdGVy bXMuDQo+Pj4gDQo+Pj4gQlINCj4+PiBEYW5pZWxlDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzps YmVyZ2VyQGxhYm4ubmV0XQ0KPj4+PiBTZW50OiBnaW92ZWSorCAyMCBkaWNlbWJyZSAyMDEyIDE1 LjM5DQo+Pj4+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGkNCj4+Pj4gQ2M6IEZhdGFpIFpoYW5nOyBJ Z29yIEJyeXNraW47IEJFTE9UVEksIFNFUkdJTyAoU0VSR0lPKTsgQ0NBTVANCj4+Pj4gU3ViamVj dDogUmU6IFtDQ0FNUF0gT3ZlcmxheSBtb2RlbCBmcmFtZXdvcmsgYW5kIGNvbnRleHQNCj4+Pj4N Cj4+Pj4gRGFuaWVsZSwNCj4+Pj4NCj4+Pj4gSnVzdCBteSBvcGluaW9uLCBidXQgSSBzZWUgb3Zl cmxheXMgYXMgdGhlIChtdWNoKSBtb3JlDQo+PmdlbmVyaWMgdGVybS4gIA0KPj4+PiBJIHRoaW5r IEx4VlBOcyBhcmUgdHlwZXMgb2Ygb3ZlcmxheXMsIGFzIGFyZSB0cmFkaXRpb25hbCBsYXllcmVk IA0KPj4+PiBuZXR3b3JrcywgYXMgYXJlIHRoZSB0ZWNobm9sb2dpZXMgdGhhdCBtYXRjaC93aWxs IHJlc3VsdCBmcm9tIA0KPj4+PiBkaXNjdXNzaW9ucyB0YWtpbmcgcGxhY2UgaW4gdGhlIE5WTzMg Y29udGV4dC4NCj4+Pj4NCj4+Pj4gTG91DQo+Pj4+DQo+Pj4+IE9uIDEyLzIwLzIwMTIgNToyMiBB TSwgRGFuaWVsZSBDZWNjYXJlbGxpIHdyb3RlOg0KPj4+Pj4gSSBwcmVmZXIgdXNpbmcgcmVmZXJl bmNlIHBvaW50cyBpbnN0ZWFkIG9mIGxpbmtzLg0KPj4+Pj4gQWNjZXNzIGxpbmsgYW5kIGludGVy LWRvbWFpbiBsaW5rcyBtZWFucyB0ZW5zIG9mIHRoaW5ncyBpbg0KPj5kaWZmZXJlbnQNCj4+Pj4+ IGNvbnRleHRzLCB3aGlsZSBlLmcuIFVOSSBtZWFucyBvbmUgc2luZ2xlIHRoaW5nIGFuZCBjbGVh cmx5DQo+Pj4+IGlkZW50aWZpZXMNCj4+Pj4+IHRoZSBjb250ZXh0LiBCVFcgaXQncyBqdXN0IGEg cHJlZmVyZW5jZSwgSSBkb24ndCBtaW5kIGhvdyB3ZSdsbCANCj4+Pj4+IGZpbmFsbHkgY2FsbCBp dC4NCj4+Pj4+DQo+Pj4+PiBUaGVyZSdzIG9uZSB0aGluZyBJIHdvdWxkIHJhdGhlciBsaWtlIHRv IGNsYXJpZnkgYW5kIGl0J3MgdGhlIA0KPj4+Pj4gcmVsYXRpb25zaGlwIHdpdGggVlBOcy4gV2Ug aGF2ZSB0d28gb3B0aW9uczoNCj4+Pj4+DQo+Pj4+PiAxKSBJcyBhIFZQTiBhIHBhcnRpY3VsYXIg Y2FzZSBvZiB0aGUgb3ZlcmxheSBtb2RlbD8NCj4+Pj4+IG9yDQo+Pj4+PiAyKSBJcyB0aGUgb3Zl cmxheSBtb2RlbCBhIHBhcnRpY3VsYXIgY2FzZSBvZiBWUE4/DQo+Pj4+Pg0KPj4+Pj4gSSB0aGlu ayB0aGlzIGNhbiBoZWxwIGEgbG90IHdpdGggdGVybWlub2xvZ3kuIEkndmUgYWx3YXlzDQo+PmFz c3VtZWQgMSkNCj4+Pj4+IGJ1dCBmcm9tIHdoYXQgSSByZWFkIEkgdGVuZCB0byBzZWUgdGhhdCAy KSBoYXMgc2V2ZXJhbCBzdXBwb3J0ZXJzLg0KPj4+Pj4NCj4+Pj4NCj4+Pj4+IEJSDQo+Pj4+PiBE YW5pZWxlDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogRmF0YWkgWmhhbmcgW21haWx0bzp6aGFuZ2ZhdGFp QGh1YXdlaS5jb21dDQo+Pj4+Pj4gU2VudDogZ2lvdmVkqKwgMjAgZGljZW1icmUgMjAxMiAyLjQ0 DQo+Pj4+Pj4gVG86IExvdSBCZXJnZXI7IElnb3IgQnJ5c2tpbjsgQkVMT1RUSSwgU0VSR0lPIChT RVJHSU8pOyBEYW5pZWxlIA0KPj4+Pj4+IENlY2NhcmVsbGkNCj4+Pj4+PiBDYzogQ0NBTVANCj4+ Pj4+PiBTdWJqZWN0OiC08Li0OiBbQ0NBTVBdIE92ZXJsYXkgbW9kZWwgZnJhbWV3b3JrIGFuZCBj b250ZXh0DQo+Pj4+Pj4NCj4+Pj4+PiBIaSBhbGwsDQo+Pj4+Pj4NCj4+Pj4+PiBTdXBwb3J0Lg0K Pj4+Pj4+DQo+Pj4+Pj4gUGVvcGxlIGFyZSBtb3JlIGZhbWlsaWFyIHdpdGggdGhlIGV4aXN0aW5n IHRoaW5ncyBsaWtlDQo+Pj4+ICJhY2Nlc3MgbGlua3MiIA0KPj4+Pj4+IGFuZCAiaW50ZXItZG9t YWluIGxpbmtzIiAob3IgRS1OTkkgbGlua3MpLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4NCj4+Pj4+PiBGYXRhaQ0KPj4+Pj4+DQo+ Pj4+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+Pj4+Pj4gt6K8/sjLOiBjY2FtcC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0KPj4+Pj4+IExvdSBC ZXJnZXINCj4+Pj4+PiC3osvNyrG85DogMjAxMsTqMTLUwjIwyNUgNzowOA0KPj4+Pj4+IMrVvP7I yzogSWdvciBCcnlza2luDQo+Pj4+Pj4gs63LzTogQ0NBTVANCj4+Pj4+PiDW98ziOiBSZTogW0ND QU1QXSBPdmVybGF5IG1vZGVsIGZyYW1ld29yayBhbmQgY29udGV4dA0KPj4+Pj4+DQo+Pj4+Pj4g SWdvciwNCj4+Pj4+Pg0KPj4+Pj4+IFlvdSBzYWlkOg0KPj4+Pj4+IElCPj4gSSBsaWtlICJhY2Nl c3MgbGlua3MiIGFuZCAiaW50ZXItZG9tYWluIGxpbmtzIiBiZXR0ZXIuDQo+Pj4+Pj4NCj4+Pj4+ PiBUaGlzIHdvcmtzIGZvciBtZS4NCj4+Pj4+Pg0KPj4+Pj4+IExvdQ0KPj4+Pj4+DQo+Pj4+Pj4g T24gMTIvMTkvMjAxMiAxMjoyNyBQTSwgSWdvciBCcnlza2luIHdyb3RlOg0KPj4+Pj4+PiBMb3Us IHBsZWFzZSBzZWUgbXkgYW5zd2VycyB0byB5b3VyIHF1ZXN0aW9ucw0KPj4+Pj4+Pg0KPj4+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBjY2FtcC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10NCj4+Pj4+PiBPbiBCZWhh bGYNCj4+Pj4+Pj4gT2YgRGFuaWVsZSBDZWNjYXJlbGxpDQo+Pj4+Pj4+IFNlbnQ6IFdlZG5lc2Rh eSwgRGVjZW1iZXIgMTksIDIwMTIgNTo1NyBBTQ0KPj4+Pj4+PiBUbzogTG91IEJlcmdlcg0KPj4+ Pj4+PiBDYzogQ0NBTVANCj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gT3ZlcmxheSBtb2Rl bCBmcmFtZXdvcmsgYW5kIGNvbnRleHQNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSGkgTG91LA0KPj4+Pj4+ Pg0KPj4+Pj4+PiBQbGVzZSBmaW5kIHJlcGxpZXMgaW4gbGluZS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g QlINCj4+Pj4+Pj4gRGFuaWVsZQ0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj4+Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4u bmV0XQ0KPj4+Pj4+Pj4gU2VudDogbHVuZWSorCAxNyBkaWNlbWJyZSAyMDEyIDIwLjQ1DQo+Pj4+ Pj4+PiBUbzogRGFuaWVsZSBDZWNjYXJlbGxpDQo+Pj4+Pj4+PiBDYzogQ0NBTVANCj4+Pj4+Pj4+ IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIE92ZXJsYXkgbW9kZWwgZnJhbWV3b3JrIGFuZCBjb250ZXh0 DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IERhbmllbGUsDQo+Pj4+Pj4+PiAJVGhhbmtz IGZvciBnZXR0aW5nIHRoaXMgb24tbGlzdCBkaXNjdXNzaW9uDQo+PmdvaW5nLiAgSSBoYXZlIHNv bWUNCj4+Pj4+Pj4+IGNvbW1lbnRzIGFuZCBxdWVzdGlvbnM6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g LSBTbyB3aGF0J3MgYSAiY2xpZW50IGxheWVyIG5ldHdvcmsiIGluIHRoaXMgY29udGV4dD8gIA0K Pj4+PiBQZXJoYXBzIHlvdQ0KPj4+Pj4+Pj4gbWVhbiBPQyBvciAiKG92ZXJsYXkpIGN1c3RvbWVy IGxheWVyIj8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSUI+PiBDbGllbnQgbGF5ZXIgaXMgd2hlcmUgT3Zl cmxheSBOZXR3b3JrIHRvcG9sb2d5IGV4aXN0cy4gDQo+Pj4+Pj4gSXQgaW5jbHVkZXM6DQo+Pj4+ Pj4+IGEpIGFjY2VzcyBsaW5rcyAoY29ubmVjdGluZyBPQ3MgdG8gT0VzKQ0KPj4+Pj4+PiBiKSB2 aXJ0dWFsIGxpbmtzIChjb25uZWN0aW5nIE9FIC8gT1ZOcyAoT3ZlcmxheSBWaXJ0dWFsDQo+Pj4+ Pj4gTm9kZXMpIHdpdGhpbg0KPj4+Pj4+PiBhIGdpdmVuIHNlcnZlciBkb21haW4pDQo+Pj4+Pj4+ IGMpIGludGVyLWRvbWFpbiBsaW5rcyAoY29ubmVjdGluZyBPRSB0byBPRSB0aGF0IGJlbG9uZyB0 bw0KPj4+Pj4+IG5laWdoYm9yaW5nDQo+Pj4+Pj4+IHNlcnZlciBkb21haW5zKSBBbGwgdGhyZWUg Y2F0ZWdvcmllcyBleGlzdCBpbiB0aGUgc2FtZQ0KPj4+PiBjbGllbnQgbGF5ZXINCj4+Pj4+Pj4g YW5kIG5hbWVkIGZyb20gdGhlIHNhbWUgbmFtaW5nIHNwYWNlDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFll cy4gVGhlIHRlcm1zIGNsaWVudCBsYXllciBhbmQgc2VydmVyIGxheWVyIGFyZQ0KPj4+Pj4+IHJl bWluZXNjZW5jZXMgdG8gYmUgY29ycmVjdGVkLg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IC0gU28gd2hhdCdzIGEgInNlcnZlciBsYXllciBuZXR3b3JrIiBpbiB0aGlzIGNvbnRleHQ/ICAN Cj4+Pj4gUGVyaGFwcyB5b3UNCj4+Pj4+Pj4+IG1lYW4gT0Ugb3IgIihvdmVybGF5KSBwcm92aWRl ciBsYXllciI/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IElCPj4gSXQgaXMgdGhlIGxheWVyIHdoZXJlIHRo ZSBVTlQgKFVuZGVybGF5IE5ldHdvcmsNCj4+Pj4+PiBUb3BvbG9neSkgZXhpc3RzDQo+Pj4+Pj4+ IElCPj4gKHdoaWNoIG1heSBiZSBpbiB0aGUgc2FtZSwgbG93ZXIgb3IgaGlnaGVyIGxheWVyDQo+ Pj4+Pj4gbmV0d29yayB0aGFuIG9mDQo+Pj4+Pj4+IElCPj4gdGhlIE9OVCkNCj4+Pj4+Pj4NCj4+ Pj4+Pj4gQWdhaW4gY29ycmVjdA0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IC0gRm9yIE9D LCBJJ2QgdGhpbmcgcmVmZXJyaW5nIGJhY2sgdG8gYSBDRSBpbiB0aGUgVlBODQo+Pj4+IGNvbnRl eHQsIGFuZA0KPj4+Pj4+Pj4gbGlrZXdpc2UgdG8gYSBQRSBmb3IgYW4gT0UsIGlzIGhlbHBmdWwg Y29udGV4dC4NCj4+Pj4+Pj4gSUI+PiBhZ3JlZQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBJbiB0aGUgY2Fz ZSBvZiB0aGUgaW50ZXJmYWNlIHdlIGdlbmVyYWxseSBkZWZpbmUgdGhlIE9OSSBhcw0KPj4+Pj4+ IGFuIG92ZXJsYXkgaW50ZXJmYWNlIHRoYXQgaW4gYSBwYXJ0aWN1bGFyIGNhc2UgaXMgY2FsbGVk IFVOSS4gDQo+Pj4+Pj4gSSB3b3VsZCBhcHBseSB0aGUgc2FtZSBtZXRob2Q6IHRob3NlIG5vZGVz IGFyZSBjYWxsZWQgT3ZlcmxheSANCj4+Pj4+PiBDdXN0b21lciBhbmQgT3ZlcmxheSBFZGdlIGFu ZCBpbiB0aGUgcGFydGljdWxhciBjYXNlIG9mDQo+Pj4+IFZQTnMgdGhleSBhcmUNCj4+Pj4+PiB0 aGUgQ0UgYW5kIFBFIHJlc3BlY3RpdmVseS4gV2hhdCBhYm91dCB0aGF0Pw0KPj4+Pj4+Pg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IC0gQXMgeW91IG1lbnRpb24gaW4gdGhlIEFwcGVuZGl4LCAoZnJvbSB0 aGUgT0MgcGVyc3BlY3RpdmUpDQo+Pj4+Pj4gdGhlcmUgaXMNCj4+Pj4+Pj4+IG5vIGRpZmZlcmVu Y2UgYmV0d2VlbiBhIHZpcnR1YWwgYW5kIHJlYWwgbm9kZQ0KPj4+Pj4+PiBJQj4+IEFncmVlDQo+ Pj4+Pj4+DQo+Pj4+Pj4+ICAoYW5kIHByZXN1bWFibHkgbGluayBhcw0KPj4+Pj4+Pj4gd2VsbCku ICBHaXZlbiB0aGlzIGFuZCB5b3VyIGNvbW1lbnQgaW4gOCwgdGhhdCB0aGUgT05JDQo+Pj4+IGNh biB0YWtlIHRoZQ0KPj4+Pj4+Pj4gZm9ybSBvZiBhIFVOSSBvciBpbmNsdWRlIGJvdGggc2lnbmFs aW5nIGFuZCByb3V0aW5nIChpLmUuLCBhIA0KPj4+Pj4+Pj4gcGVlci9JLU5OSSBvcg0KPj4+Pj4+ Pj4gRS1OTkkpIHdoYXQgdmFsdWUgaXMgdGhlcmUgaW4gaW50cm9kdWNpbmcgdGhlIE9OSSB0ZXJt PyAgDQo+Pj4+Pj4gU2FpZCBhbm90aGVyDQo+Pj4+Pj4+PiB3YXksIHRoZXJlJ3Mgbm8gc3BlY2lm aWMgdGVybSBmb3IgdGhlIGludGVyZmFjZSBiZXR3ZWVuIGENCj4+Pj4gQ0UgYW5kIFBFDQo+Pj4+ Pj4+PiBpbiBMM1ZQTnMsIHNvIHdoeSBkbyB3ZSBuZWVkIHRvIGludHJvZHVjZSBvbmUgaW4gdGhp cyBjb250ZXh0Pw0KPj4+Pj4+Pg0KPj4+Pj4+PiBXZSBnYXZlIGEgbmFtZSB0byB0aGUgVU5JLCB3 aHkgZG9uJ3QgZ2l2aW5nIHRvIHRoZSBPTkk/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IElCPj4gQXMgbG9u ZyBhcyBpdCBhbGxvd3MgZm9yIGJvdGggb3IgZWl0aGVyIHNpZ25hbGluZw0KPj4+Pj4+IGFuZC9v ciByb3V0aW5nDQo+Pj4+Pj4+IElCPj4gZXhjaGFuZ2VzDQo+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gSSB0aGluayB0aGlzIHNhbWUgY29tbWVudCBwcm9iYWJseSBob2xkcyBmb3IgdGhlIE8t Tk5JDQo+Pj4+Pj4gKGUuZy4sIHdoYXQncw0KPj4+Pj4+Pj4gdGhlIG5hbWUgb2YgdGhlIGludGVy ZmFjZSBiZXR3ZWVuIHByb3ZpZGVycyB3aGljaCANCj5zdXBwb3J0IEwzVlBOIA0KPj4+Pj4+Pj4g aGFuZG9mZnM/KS4uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJIHdvdWxkIHN1Z2dlc3QgZ2l2aW5nIGEg bmFtZSB0byB0aGF0IGludGVyZmFjZSBhbHNvIGluDQo+Pj4+Pj4gb3JkZXIgdG8gZGlzdGluZ3Vp c2ggYmV0d2VlbiBhbiAiaW50ZXJuYWwiIGFuZCBhbiAiZXh0ZXJuYWwiIA0KPj4+Pj4+IGxpbmsg d2hlbiBtdWx0aXBsZSBvdmVybGF5IHByb3ZpZGVyIG5ldHdvcmsgZG9tYWlucyBhcmUgcHJlc2Vu dC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSUI+PiBJIGxpa2UgImFjY2VzcyBsaW5rcyIgYW5kICJpbnRl ci1kb21haW4gbGlua3MiIGJldHRlci4gDQo+Pj4+Pj4gTm90ZSBhbHNvIHRoYXQgYSAibGluayIg YW5kICJub2RlIiBhcmUgVEUgdG9wb2xvZ3kgY29uY2VwdHMgYW5kIA0KPj4+Pj4+IG9ydGhvZ29u YWwgdG8gQ1AgaW50ZXJmYWNlcyAod2hpY2ggYXJlIFNpZ25hbGluZy9Sb3V0aW5nDQo+PnNwZWFr ZXJzKS4NCj4+Pj4+PiBJZiB5b3UgbWVhbiBieSAiaW50ZXJuYWwiIGFuZCAiZXh0ZXJuYWwiIGxp bmtzIHRoZSBDUA0KPj5jb25uZWN0aXZpdHksDQo+Pj4+Pj4gdGhhbiBJIGFncmVlIHdpdGggeW91 Lg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE11Y2ggdGhhbmtzLA0KPj4+Pj4+Pj4gTG91 DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gMTIvMTcvMjAxMiA2OjE3IEFNLCBEYW5pZWxlIENlY2Nh cmVsbGkgd3JvdGU6DQo+Pj4+Pj4+Pj4gRGVhciBDQ0FNUGVycywNCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+IEluIHRoZSBsYXN0IHdlZWtzIHNldmVyYWwgb2ZmLWxpbmUgZGlzY3Vzc2lvbnMgb24gdGhl DQo+Pj4+Pj4+PiBPdmVybGF5IG1vZGVsIGZyYW1ld29yayBhbmQgcmVsYXRlZCB3b3JrcyB0b29r IHBsYWNlLiBTb21lIA0KPj4+Pj4+Pj4gZGlzY3Vzc2lvbnMgbGVkIHRvIHNvbWUgc29ydCBvZiBh Z3JlZW1ldCBhbW9uZyBhIHNtYWxsIA0KPmdyb3VwIG9mIA0KPj4+Pj4+Pj4gcGVvcGxlLCBzb21l IG90aGVycyB0byBhIHNldCBhIHZpYWJsZSBvcHRpb25zLCBzb21lIG90aGVycw0KPj4+Pj4+IHRv IHRvdGFsbHkNCj4+Pj4+Pj4+IG9wZW4gaXNzdWVzLiBJIHRyaWVkIHRvIHN1bW1hcml6ZSB0aGUg b3V0cHV0IG9mIHN1Y2gNCj4+ZGlzY3Vzc2lvbnMNCj4+Pj4+Pj4+IGJlbG93IHNvIHRvIHByb2dy ZXNzIHRoZSBkaXNjdXNzaW9ucyBpbnRvIGEgc2luZ2xlIHRocmVhZA0KPj4+Pj4+IG9uIHRoZSBX RyBNTC4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgdGhlIGFpbSBvZiB0 aGlzIG1haWwgaXMgbm90IHRvIHByZXNlbnQgYQ0KPj4+Pj4+Pj4gd2VsbCBzaGFwZWQgYW5kIGNv bmNsdXNpdmUgaWRlYSB0byB0aGUgV0cgYnV0IHJhdGhlciB0bw0KPj4+PiBwcm92aWRlIHRoZQ0K Pj4+Pj4+Pj4gYmFzaXMgZm9yIHN0YXJ0aW5nIGEgZGlzY3Vzc2lvbiBmcm9tIGEgYmFyZWx5IHNo YXBlZCBpZGVhDQo+Pj4+IChzdGVwIDEpDQo+Pj4+Pj4+PiBpbnN0ZWFkIG9mIHN0YXJ0aW5nIGl0 IGZyb20gc2NyYXRjaCAoc3RlcCAwKS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEluIGFkZGl0aW9u IHlvdSBjYW4gZmluZCBhdHRhY2hlZCBhIHNsaWRlIGRlcGljdGluZyBhDQo+Pj4+Pj4+PiBwcm9w b3NhbCBvZiB0aGUgb3ZlcmxheSBzY2VuYXJpby4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoYW5r cywNCj4+Pj4+Pj4+PiBEYW5pZWxlDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiArIERpc2NsYWltZXI6 DQo+Pj4+Pj4+Pj4gIDEuIFBhY2tldCBvcHRvIGludGVncmF0aW9uIGlzIG9mdGVuIGNvbnNpZGVy ZWQgYnV0IHRoZSB3b3JrDQo+Pj4+Pj4+PiBjYW4gYmUgZXh0ZW50ZWQgdG8gYW55IHR5cGUgb2Yg U0MuIEVnLiBURE0gb3ZlciBMU0MuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiArIFRlcm1pbm9sb2d5 Og0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gIDEuIFZpcnR1YWwgTGluazogQSB2aXJ0dWFsIGxpbmsg aXMgYSBwb3RlbnRpYWwgcGF0aCBiZXR3ZWVuDQo+Pj4+Pj4+PiB0d28gdmlydHVhbCBvciByZWFs IG5ldHdvcmsgZWxlbWVudHMgaW4gYSBjbGllbnQgbGF5ZXINCj4+Pj4+PiBuZXR3b3JrICB0aGF0 DQo+Pj4+Pj4+PiBpcyBtYWludGFpbmVkL2NvbnRyb2xsZWQgaW4gYW5kIGJ5IHRoZSBzZXJ2ZXIg ZG9tYWluDQo+Pj4+IGNvbnRyb2wgcGxhbmUNCj4+Pj4+Pj4+IChhbmQgYXMgc3VjaCBjYW5ub3Qg dHJhbnNwb3J0IGFueSB0cmFmZmljL2RhdGEgYW5kDQo+PnByb3RlY3RlZCBmcm9tDQo+Pj4+Pj4+ PiBiZWluZw0KPj4+Pj4+Pj4gZGUtcHJvdmlzaW9uZWQpIGFuZCB3aGljaCBjYW4gYmUgaW5zdGFu dGlhdGVkIGluIHRoZSBkYXRhDQo+Pj4+Pj4gcGxhbmUgKGFuZA0KPj4+Pj4+Pj4gdGhlbiBjYW4g Y2FycnkvdHJhbnNwb3J0L2ZvcndhcmQgdHJhZmZpYy9kYXRhKSBwcmVzZXJ2aW5nDQo+Pj4+Pj4g cHJldmlvdXNseQ0KPj4+Pj4+Pj4gYWR2ZXJ0aXNlZCBhdHRyaWJ1dGVzIHN1Y2ggYXMgZmF0ZSBz aGFyaW5nIGluZm9ybWF0aW9uLg0KPj4+Pj4+Pj4+ICAyLiAgVmlydHVhbCBOb2RlOiBWaXJ0dWFs IG5vZGUgaXMgYSBjb2xsZWN0aW9uIG9mIHplcm8gb3INCj4+Pj4+Pj4+IG1vcmUgc2VydmVyIG5l dHdvcmsgIGRvbWFpbiBub2RlcyB0aGF0IGFyZSBjb2xsZWN0aXZlbHkNCj4+Pj4gcmVwcmVzZW50 ZWQNCj4+Pj4+Pj4+IHRvIHRoZSBjbGllbnRzIGFzIGEgc2luZ2xlIG5vZGUgdGhhdCBleGlzdHMg aW4gdGhlIA0KPmNsaWVudCBsYXllciANCj4+Pj4+Pj4+IG5ldHdvcmsgYW5kIGlzIGNhcGFibGUg b2YgdGVybWluYXRpbmcgb2YgYWNjZXNzLA0KPj5pbnRlci1kb21haW4gYW5kDQo+Pj4+Pj4+PiB2 aXJ0dWFsIGxpbmtzLg0KPj4+Pj4+Pj4+ICAzLlZpcnR1YWwgVG9wb2xvZ3k6IFZpcnR1YWwgdG9w b2xvZ3kgaXMgYSBjb2xsZWN0aW9uIG9mIG9uZQ0KPj4+Pj4+Pj4gb3IgbW9yZSB2aXJ0dWFsIG9y IHJlYWwgc2VydmVyIG5ldHdvcmsgZG9tYWluIG5vZGVzIHRoYXQNCj4+Pj4+PiBleGlzdCBpbiB0 aGUNCj4+Pj4+Pj4+IGNsaWVudCBsYXllciBuZXR3b3JrIGFuZCBhcmUgaW50ZXJjb25uZWN0ZWQg dmlhIDAgb3INCj4+bW9yZSB2aXJ0dWFsDQo+Pj4+Pj4+PiBsaW5rcy4NCj4+Pj4+Pj4+PiAgNC4g T3ZlcmxheSB0b3BvbG9neTogIGlzIGEgc3VwZXJzZXQgb2YgdmlydHVhbCB0b3BvbG9naWVzDQo+ Pj4+Pj4+PiBwcm92aWRlZCBieSBlYWNoIG9mIHNlcnZlciBuZXR3b3JrIGRvbWFpbnMsIGFjY2Vz cyBhbmQNCj4+Pj4gaW50ZXItZG9tYWluDQo+Pj4+Pj4+PiBsaW5rcy4NCj4+Pj4+Pj4+PiAgNS4g QWNjZXNzIExpbms6IExpbmsgYmV0d2VlbiBPQyBhbmQgT0UuIEdNUExTIHJ1bnMgb24gdGhhdA0K Pj4+Pj4+Pj4gbGluay4gSXQgY2FuIHN1cHBvcnQgYW55IG9mIHRoZSBTQ3Mgc3VwcG9ydGVkIGJ5 IHRoZSBHTVBMUy4NCj4+Pj4+Pj4+PiAgNi4gT3ZlcmxheSBDdXN0b21lciAoT0MpOiBTb21ldGhp bmcgbGlrZSB0aGUgQ04gaW4gUkZDNDIwOA0KPj4+Pj4+Pj4gdGVtaW5vbG9neSAgYnV0IChpKSBy ZWNlaXZpbmcgdmlydHVhbCB0b3BvbG9neSBmcm9tIHRoZQ0KPj4+Pj4+IGNvcmUgbmV0d29yaw0K Pj4+Pj4+Pj4gYW5kIHJlcXVlc3RpbmcgdGhlIHNldCB1cCBvZiBvbmUgb2YgdGhlbSBvciAoaWkp IA0KPnJlcXVlc3RpbmcgdGhlIA0KPj4+Pj4+Pj4gY29tcHV0YXRpb24gYW5kIGVzdGFibGlzaG1l bnQgb2YgYSBwYXRoIGFjY29yZGluZ2x5IHRvIGdpZW4gDQo+Pj4+Pj4+PiBjb25zdHJhaW50cyBp biB0aGUgY29yZSBuZXR3b3JrIGFuZCByZWNlaXZpbmcgdGhlIHBhcmFtZXRlcnMgDQo+Pj4+Pj4+ PiBjaGFyYWN0ZXJpemluZyBzdWNoIHBhdGguIChpaSkgPT0gVU5JLg0KPj4+Pj4+Pj4+ICA3LiBP dmVybGF5IEVkZ2UgKE9FKTogU29tZXRoaW5nIGxpa2UgdGhlIEVOIGluIFJGQzQyMDggYnV0DQo+ Pj4+Pj4+PiBhYmxlIHRvIGRlYWwgd2l0aCAoaSkgYW5kIChpaSkgYWJvdmUuDQo+Pj4+Pj4+Pj4g IDguIE9OSSA6IE92ZXJsYXkgbmV0d29yayBpbnRlcmZhY2U6IEludGVyZmFjZSBhbGxvd2luZyBm b3INCj4+Pj4+Pj4+IHNpZ25hbGluZyBhbmQgcm91dGluZyBtZXNzYWdlcyBleGNoYW5nZSBiZXR3 ZWVuIE92ZXJsYXkNCj4+YW5kIENvcmUNCj4+Pj4+Pj4+IG5ldHdvcmsuIFJvdXRpbmcgaW5mb3Jt YXRpb24gY29uc2lzdHMgb24gdmlydHVhbCB0b3BvbG9neSANCj4+Pj4+Pj4+IGFkdmVydGlzZW1l bnQuIFdoZW4gdGhlcmUgaXMgbm8gcm91dGluZyBhZGphY2VuY3kgYWNyb3NzIHRoZSANCj4+Pj4+ Pj4+IGludGVyZmFjZSBpdCBpcyBlcXVpdmFsZW50IHRvIHRoZSBHTVBMUyBVTkkgZGVmaW5lZCBp biA0MjA4Lg0KPj4+Pj4+Pj4gU2lnbmFsaW5nIG1lc3NhZ2VzIGFyZSBjb21wbGlhbnQgd2l0aCBS RkM0MjA4LiBJbmZvcm1hdGlvbg0KPj4+Pj4+IHJlbGF0ZWQgdG8NCj4+Pj4+Pj4+IHBhdGggY2Fy YWNodGVyaXN0aWNzLCBlLmcuIFRFLW1ldHJpY3MsIGNvbGxlY3RlZCBTUkxHLA0KPj5wYXRoIGRl bGF5DQo+Pj4+Pj4+PiBldGMsIGVpdGhlciBwYXNzZWQgZnJvbSBPRSB0byBPQyB2aWEgc2lnbmFs aW5nIGFmdGVyIHRoZSBMU1AgDQo+Pj4+Pj4+PiBlc3RhYmxpc2htZW50IGluIHRoZSBjb3JlIG5l dHdvcmsgb3IgZnJvbSBPQyB0byBPRSB0byBiZQ0KPj4+Pj4+IHVzZWQgYXMgcGF0aA0KPj4+Pj4+ Pj4gY29tcHV0YXRpb24gY29uc3RyYWludHMsIGZhbGwgdW5kZXIgdGhlIGRlZmluaXRpb24gb2YN Cj4+Pj4+PiBzaWduYWxpbmcgaW5mbw0KPj4+Pj4+Pj4gYW5kIG5vdCByb3V0aW5nIGluZm8pLg0K Pj4+Pj4+Pj4+ICA5LiBPLU5OSSAobmFtZSB0byBiZSBmb3VuZCxtYXliZSByZXVzZWQpOiBJbnRl cmZhY2Ugb24gdGhlDQo+Pj4+Pj4+PiBsaW5rcyBiZXR3ZWVuIGRpZmZlcmVudCBjb3JlIG5ldHdv cmtzIGluIHRoZSBvdmVybGF5IG1vZGVsIA0KPj4+Pj4+Pj4gZW52aXJvbm1lbnQsIGkuZS4gQmV0 d2VlbiBib3JkZXIgT0VzLiBTYW1lIGZlYXR1cmVzIG9mIHRoZQ0KPj4+Pj4+IE9OSSBhcHBseQ0K Pj4+Pj4+Pj4gdG8gdGhpcyBpbnRlcmZhY2UuIENvdWxkIGl0IGJlIGFuIEUtTk5JPyBBIE9OST8g QSBuZXcgbmFtZQ0KPj4+Pj4+IGlzIG5lZWRlZD8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICsgU3Rh dGVtZW50cw0KPj4+Pj4+Pj4+ICAxLiBJbiB0aGUgY29udGV4dCBvZiBvdmVybGF5IG1vZGVsIHdl IGFyZSBhaW1pbmcgdG8gYnVpbGQNCj4+Pj4+Pj4+IGFuIG92ZXJsYXkNCj4+Pj4+Pj4+PiB0b3Bv bG9neSBmb3IgdGhlIGNsaWVudCBuZXR3b3JrIGRvbWFpbnMgIDIuIFRoZSBvdmVybGF5DQo+Pj4+ Pj4+PiB0b3BvbG9neSBpcyBjb21wcmlzZWQgb2Y6DQo+Pj4+Pj4+Pj4gICAgIGEpIGFjY2VzcyBs aW5rcyAobGlua3MgY29ubmVjdGluZyBjbGllbnQgTkVzIHRvIHRoZQ0KPj4+Pj4+Pj4gc2VydmVy IG5ldHdvcmsgZG9tYWlucykuIFRoZXkgY2FuIGJlIFBTQyBvciBMU0MuDQo+Pj4+Pj4+Pj4gICAg IGIpIGludGVyLWRvbWFpbiBsaW5rcyAobGlua3MgaW50ZXJjb25uZWN0aW5nIHNlcnZlcg0KPj4+ Pj4+Pj4gbmV0d29yayBkb21haW5zKSAgIA0KPj4+Pj4+Pj4+ICAgICBjKSB2aXJ0dWFsIHRvcG9s b2d5IHByb3ZpZGVkIGJ5IHRoZSBzZXJ2ZXIgbmV0d29yaw0KPj4+Pj4+Pj4gZG9tYWlucy4gVmly dHVhbCBMaW5rcyArIFZpcnR1YWwgTm9kZXMgKFRCRCkgKw0KPj4+PiBDb25uZWN0aXZpdHkgTWF0 cml4DQo+Pj4+Pj4+PiAod2l0aCBhIHNldCBvZiBwYXJhbWV0ZXJzIGUuZy4gU1JMRywgb3B0aWNh bCBpbXBhaXJtZW50cywNCj4+Pj4gZGVsYXkgZXRjDQo+Pj4+Pj4+PiBmb3IgZWFjaCBlbnRyeSkg ZGVzY3JpYmluZyBjb25uZWN0aXZpdHkgYmV0d2VlbiBhY2Nlc3MNCj4+bGlua3MgYW5kDQo+Pj4+ Pj4+PiB2aXJ0dWFsIGxpbmtzLg0KPj4+Pj4+Pj4+ICAzLiBJbiB0aGUgY29udGV4dCBvZiBvdmVy bGF5IG1vZGVsIHdlIG1hbmFnZSAgaGllcmFyY2h5DQo+Pj4+Pj4gb2Ygb3ZlcmxheQ0KPj4+Pj4+ Pj4+IHRvcG9sb2dpZXMgd2l0aCBvdmVybGF5L3VuZGVybGF5IHJlbGF0aW9uc2hpcHMgIDQuIElu IHRoZQ0KPj4+Pj4+IGNvbnRleHQgb2YNCj4+Pj4+Pj4+PiBvdmVybGF5IG1vZGVsIG11bHRpLWxh eWVyaW5nIGFuZCBpbnRlci1sYXllciByZWxhdGlvbnNoaXBzDQo+Pj4+Pj4+PiBhcmUgcGVyaXBo ZXJhbCBhdCBiZXN0LCBpdCBpcyBhbGwgYWJvdXQgaG9yaXpvbnRhbCBuZXR3b3JrIA0KPj4+Pj4+ Pj4gaW50ZWdyYXRpb24gNS4gVGhlIG92ZXJsYXkgbW9kZWwgYXNzdW1lcyBvbmUgaW5zdGFuY2Ug Zm9yDQo+Pj4+Pj4gdGhlIGNsaWVudA0KPj4+Pj4+Pj4gbmV0d29yayBhbmQgYSBzZXBhcmF0ZSBp bnN0YW5jZSBmb3IgdGhlIHNlcnZlciBuZXR3b3JrIGFuZA0KPj4+Pj4+IGluIHRoZSBPTkkNCj4+ Pj4+Pj4+IGNhc2UgdGhlIHNlcnZlciBuZXR3b3JrIGFsc28gc3VycmVwdGl0aW91c2x5DQo+PnBh cnRpY2lwYXRlcyBpbiB0aGUNCj4+Pj4+Pj4+IGNsaWVudCBuZXR3b3JrIGJ5IGluamVjdGluZyB2 aXJ0dWFsIHRvcG9sb2d5DQo+PmluZm9ybWF0aW9uIGludG8gaXQuDQo+Pj4+Pj4+Pj4gIDYuIEwx VlBOIChhbmQgTHhWUE4pIGluIGdlbmVyYWwgaXMgYSBzZXJ2aWNlIHByb3ZpZGVkIG92ZXINCj4+ Pj4+Pj4+IHRoZSBPTkkgKGl0IGZhbGxzIHVuZGVyIHRoZSBVTkkgY2FzZSBhcyBubyByb3V0aW5n DQo+Pj4+IGFkamFjZW5jeSBpcyBpbg0KPj4+Pj4+Pj4gcGxhY2UgYmV0d2VlbiBPQyBhbmQgT0Up Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gKyBPcGVuIGlzc3Vlcy9xdWVzdGlvbnMNCj4+Pj4+Pj4+ PiAgDQo+Pj4+Pj4+Pj4gIDEuIFBDRS1QQ0VQIC0gZG8gd2UgbmVlZCB0byBpbmNsdWRlIGNvbnNp ZGVyYXRpb25zIGFib3V0DQo+Pj4+Pj4+PiBQQ0UgYW5kIFBDRVAgaW50byB0aGUgb3ZlcmxheSBm cmFtZXdvcmsgY29udGV4dD8NCj4+Pj4+Pj4+PiAgMi4gQkdQLUxTIG5lZWRzIHRvIGJlIGNvbnNp ZGVyZWQgIDMuIFNob3VsZCBwb3RlbnRpYWxzIGJlIA0KPj4+Pj4+Pj4+IGluY2x1ZGVkPyBFLmcu IEkyUlM/DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiArIEFwcGVuZGl4Og0KPj4+Pj4+Pj4+IFNvbWUg bm90ZXMgb24gdGhlIFZpcnR1YWwgTm9kZToNCj4+Pj4+Pj4+PiAxLiAgICAgIFZpcnR1YWwgTGlu ayBNb2RlbCBhbG9uZywgc2FkbHksIGRvZXMgbm90IHNjYWxlIA0KPj4+Pj4+Pj4gYmVjYXVzZSBv ZiBOKioyIHByb2JsZW0uIElQIG92ZXIgQVRNIGFuZCBzaW5nbGUtc2VnbWVudCBQV3MNCj4+Pj4+ PiBoYXZlIHRoZQ0KPj4+Pj4+Pj4gc2FtZSBpc3N1ZSwgdGhhdCdzIHdoeSBwZW9wbGUgaW52ZW50 ZWQgbXVsdGktc2VnbWVudCBQV3MNCj4+Pj4+Pj4+PiAyLiAgICAgIFRoZSBvbmx5IHdheSB0byBh dm9pZCBmdWxsLW1lc2ggb2YgVmlydHVhbCBMaW5rcyBpcyANCj4+Pj4+Pj4+IGJ5IGhhdmluZyBp bnRlcm1lZGlhdGUgbm9kZXMgaW50ZXJjb25uZWN0aW5nIFZpcnR1YWwNCj4+TGlua3MgaW4gdGhl DQo+Pj4+Pj4+PiBtaWRkbGUgb2YgdGhlIHZpcnR1YWwgdG9wb2xvZ3kNCj4+Pj4+Pj4+PiAzLiAg ICAgIFRoZXNlIGludGVybWVkaWF0ZSBub2RlcyBjYW5ub3QgYmUgcmVhbCBzZXJ2ZXIgDQo+Pj4+ Pj4+PiBkb21haW4gc3dpdGNoZXMsIGJlY2F1c2UsIGdlbmVyYWxseSBzcGVha2luZzoNCj4+Pj4+ Pj4+PiAgIGEpUmVhbCBzd2l0Y2hlcyBiZWxvbmcgdG8gZGlmZmVyZW50IGxheWVyIG5ldHdvcms7 DQo+Pj4+Pj4+Pj4gICBiKVJlYWwgc3dpdGNoZXMgYXJlIG5hbWVkIGZyb20gZGlmZmVyZW50IG5h bWluZyBzcGFjZQ0KPj4+Pj4+Pj4+ICAgYylyZWFsIHN3aXRjaGVzIGluZGl2aWR1YWxseSBtYXkg bm90IGhhdmUgc3VmZmljaWVudA0KPj4+Pj4+Pj4gcmVzb3VyY2VzIHRvIHRlcm1pbmF0ZSB2aXJ0 dWFsIGxpbmtzICh3aGlsZSBhIGdyb3VwIG9mIHJlYWwNCj4+Pj4+PiBzd2l0Y2hlcw0KPj4+Pj4+ Pj4gY29sbGVjdGl2ZWx5IHdpbGwgaGF2ZSkNCj4+Pj4+Pj4+PiAgIGQpUHJlc2VudGluZyBhIGdy b3VwIG9mIHJlYWwgc3dpdGNoZXMgYXMgYSBzaW5nbGUgdmlydHVhbA0KPj4+Pj4+Pj4gbm9kZSBo YXZlIGJldHRlciBzY2FsYWJpbGl0eSBxdWFsaXRpZXMNCj4+Pj4+Pj4+PiA0LiAgICAgIEV2ZW4g aWYgeW91IG1hcCBhIHZpcnR1YWwgbm9kZSBvbiBhIHNpbmdsZSByZWFsIA0KPj4+Pj4+Pj4gbm9k ZSwgeW91IG5lZWQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgcmVhbCBzZXJ2ZXIgZG9tYWluDQo+Pj4+ Pj4gc3dpdGNoZXMgYXJlLA0KPj4+Pj4+Pj4gZ2VuZXJhbGx5IHNwZWFraW5nLCBibG9ja2luZyBz d2l0Y2hlcyBhbmQgYXMgc3VjaCBtdXN0DQo+Pj4+IGV4cG9zZSB0aGVpcg0KPj4+Pj4+Pj4gY29u bmVjdGl2aXR5IG1hdHJpY2VzDQo+Pj4+Pj4+Pj4gNS4gICAgICBJZiB5b3Ugd2FudCB0byBjb21w dXRlIFNSTEctZGlzam9pbnQgcGF0aHMgdGhhdCANCj4+Pj4+Pj4+IGNvdWxkIHBvdGVudGlhbGx5 IGdvIHRocm91Z2ggYSByZWFsIHNlcnZlciBkb21haW4gc3dpdGNoLCB0aGUgDQo+Pj4+Pj4+PiBs YXR0ZXIncyBjb25uZWN0aXZpdHkgbWF0cml4IG11c3QgZXhwb3NlICJpbnRlcm5hbCINCj4+Pj4g U1JMR3MsIHNvIHRoYXQNCj4+Pj4+Pj4+IHRoZSB0d28gc2VydmljZXMgdHJhdmVyc2luZyB0aGUg c3dpdGNoIHdpbGwgbm90DQo+Pj4+IHNpbXVsdGFuZW91c2x5IGZhaWwNCj4+Pj4+Pj4+IGlmIGEg c2luZ2xlIGludGVybmFsIGVsZW1lbnQgc2hhcmVkIGJ5IHRoZSBzZXJ2aWNlcyBmYWlscw0KPj4+ Pj4+Pj4+IDYuICAgICAgSWYgeW91IHdhbGsgdGhyb3VnaCBhbGwgY2FzZXMgdGhhdCBuZWVkIHRv IGJlIA0KPj4+Pj4+Pj4gYWRkcmVzc2VkIHdoZW4geW91IGFyZSB0cmFmZmljIGVuZ2luZWVyaW5n IHRvcG9sb2dpZXMNCj4+Pj4gd2l0aCBibG9ja2luZw0KPj4+Pj4+Pj4gc3dpdGNoZXMsIHlvdSB3 aWxsIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBpcyBhYnNvbHV0ZWx5IG5vDQo+Pj4+Pj4gZGlmZmVy ZW5jZQ0KPj4+Pj4+Pj4gYmV0d2VlbiBhIHZpcnR1YWwgbm9kZSBhbmQgcmVhbCBibG9ja2luZyBy ZWFsIG5vZGUuDQo+Pj4+Pj4+Pj4gNy4gICAgICBFdmVuIGluIGNhc2Ugb2YgcHVyZSBWTCBtb2Rl bCwgY2xpZW50IE5FcyBjb25uZWN0ZWQgDQo+Pj4+Pj4+PiB0byBzZXJ2ZXIgbmV0d29yayBkb21h aW4gbXVzdCBiZSB1cGdyYWRlZCBzbyB0aGF0IHRoZXkgY291bGQgDQo+Pj4+Pj4+PiB1bmRlcnN0 YW5kIHRoZSBjb25uZWN0aXZpdHkgbWF0cmljZXMgYWR2ZXJ0aXNlZCBieSB0aGUNCj4+Pj4gYm9y ZGVyIG5vZGVzDQo+Pj4+Pj4+PiBkZXNjcmliaW5nIGNvbm5lY3Rpdml0eSBjb25zdHJhaW50cyBi ZXR3ZWVuIGFjY2VzcyBsaW5rcw0KPj4+Pj4+IGFuZCB2aXJ0dWFsDQo+Pj4+Pj4+PiBsaW5rcyB0 aGV5IHRlcm1pbmF0ZS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gIA0KPj4+Pj4+ Pj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Pj4+Pj4+Pj4gREFOSUVM RSBDRUNDQVJFTExJDQo+Pj4+Pj4+Pj4gU3lzdGVtICYgVGVjaG5vbG9neSAtIFBEVSBPcHRpY2Fs ICYgTWV0cm8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFZpYSBFLk1lbGVuLCA3Nw0KPj4+Pj4+Pj4+ IEdlbm92YSwgSXRhbHkNCj4+Pj4+Pj4+PiBQaG9uZSArMzkwMTA2MDAyNTEyDQo+Pj4+Pj4+Pj4g TW9iaWxlICszOTMzNDY3MjU3NTANCj4+Pj4+Pj4+PiBkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nz b24uY29tIHd3dy5lcmljc3Nvbi5jb20NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoaXMgQ29tbXVu aWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZQ0KPj4+Pj4+ Pj4gZW1haWwgb24NCj4+Pj4+Pj4+PiB0aGUgYmFzaXMgb2YgdGhlIHRlcm0gc2V0IG91dCBhdA0K Pj4+PiB3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXINCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+ IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBDQ0FNUCBtYWlsaW5n IGxpc3QNCj4+Pj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+ Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4+Pj4N Cj4+Pj4+DQo+Pj4+DQo+Pj4gDQo+Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Q0NBTVAgbWFpbGluZyBsaXN0DQo+Q0NBTVBAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ From daniele.ceccarelli@ericsson.com Wed Jan 16 07:33:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AB221F8934 for ; Wed, 16 Jan 2013 07:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.17 X-Spam-Level: X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, 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 FpLHHblX9MRm for ; Wed, 16 Jan 2013 07:33:14 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C64F521F8910 for ; Wed, 16 Jan 2013 07:33:13 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-a6-50f6c838df19 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AC.D2.19728.838C6F05; Wed, 16 Jan 2013 16:33:12 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 16:33:12 +0100 From: Daniele Ceccarelli To: CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQ== Date: Wed, 16 Jan 2013 15:33:11 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvja7FiW8BBttO21g8mXODxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGWd+Fhd0WlVM+2DZwHhNr4uRg0NCwESi62ZAFyMnkCkmceHe erYuRi4OIYFDjBIzp/yEchYzSnRuOM8C0sAmYCXx5JAPSIOIgJTEzX232EFsYQFlibtLprNC xDUkbh/uZwcpFxHQk1h82R4kzCKgKnF0zjNmEJtXwFti++aPbCA2o4CsxITdixhBbGYBcYlb T+YzQdwjILFkz3lmCFtU4uXjf6wQtqLEzrPtzBD1OhILdn9ig7C1JZYtfA01X1Di5MwnLBMY hWchGTsLScssJC2zkLQsYGRZxciem5iZk15utIkRGL4Ht/xW3cF455zIIUZpDhYlcd5w1wsB QgLpiSWp2ampBalF8UWlOanFhxiZODilGhgXW39lkFKe0rG97MYinsinL6f1d/eF1m2XPbU1 0nBR55zT70PX9Lvtifij9Luw+XfK2bthPLM8TbT/cazo3Vl240rttGVdcUda9zd9/BZkxpvt s3zuG++FB3VO57Zds69782+j0/H/OZoaE4/5bnywZq3L5Psvnu+V/Pvk/bwvFbLpbXdvl/tF KrEUZyQaajEXFScCAAOiRAktAgAA Subject: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 15:33:15 -0000 Dear overlayers, Please find below a new version (v2) of the framework summary reflecting th= e latest discussions. Again i hope i've captured all the comments around, s= orry if anything is missing, in case just let me know what i missed. BR Daniele + Disclaimer: 1. Packet opto integration is often considered but the work can be extente= d to any type of SC. Eg. TDM over LSC. + Terminology: 1. Virtual Link: A virtual link is a potential path between two virtual or= real network elements in a provider layer network that is maintained/controlled in and= by the provider domain control plane (and as such cannot transport any traffic/data and pr= otected from being de-provisioned) and which can be instantiated in the data plane (and then = can=20 carry/transport/forward traffic/data) preserving previously advertised att= ributes such as=20 fate sharing information. 2. Virtual Node: Virtual node is a collection of zero or more provider ne= twork domain nodes that are collectively represented to the clients as a single node th= at=20 exists in the customer layer network and is capable of terminating of acce= ss, inter-domain and virtual links. 3. Virtual Topology: Virtual topology is a collection of one or more virtu= al or real provider network domain nodes that exist in the customer layer network and are inte= rconnected via 0 or more virtual links. 4. Overlay topology: is a superset of virtual topologies provided by each= of provider network domains, access and inter-domain links. 5. Access Link: Link between OC and OE. GMPLS runs on that link. It can su= pport any of the SCs supported by the GMPLS. 6. CE (customer Edge): Something like the CN in RFC4208 teminology but (i= ) receiving=20 virtual topology from the provider network and requesting the set up of on= e of them or (ii) requesting the computation and establishment of a path accordingly to= given constraints in the provider network and receiving the parameters characterizing such p= ath. (ii) =3D=3D UNI. 7. PE (provider Edge): Something like the EN in RFC4208 but able to deal w= ith (i) and (ii) above. 8. PE-CE interface (former ONI) : Interface allowing for signaling and rou= ting messages exchange between customer overlay and provider network. Routing informatio= n consists on virtual topology advertisement. When there is no routing adjacency across = the interface it is equivalent to the GMPLS UNI defined in 4208. Signaling messages are = compliant with RFC4208. Information related to path carachteristics, e.g. TE-metrics, col= lected SRLG, path delay etc, either passed from CE to PE via signaling after the LSP es= tablishment in the core network or from CE to PE to be used as path computation constr= aints, fall under the definition of signaling info and not routing info). 9. CE-CE (former O-NNI): Interface on the links between different provider= networks in the overlay model environment. Same features of the CE-PE apply to this= interface.=20 + Statements 1. In the context of overlay model we are aiming to build an overlay topol= ogy for the customer network domains =20 2. The overlay topology is comprised of: a) access links (links connecting client NEs to the provider network do= mains). They can be PSC or LSC. b) inter-domain links (links interconnecting server network domains) c) virtual topology provided by the provider network domains. Virtual L= inks + Virtual Nodes (TBD) + Connectivity Matrix (with a set of parameters e.g.= SRLG, optical impairments, delay etc for each entry) describing connectivity bet= ween access links and virtual links. 3. In the context of overlay model we manage hierarchy of overlay topolo= gies with overlay/underlay relationships =20 4. In the context of overlay model multi-layering and inter-layer relation= ships are peripheral at best, it is all about horizontal network integration =20 5. The overlay model assumes one CP instance for the customer network and = a separate instance for the provider network and in the CE-PE interface case the prov= ider network also surreptitiously participates in the customer network by injec= ting virtual topology information into it. 6. L1VPN (and LxVPN) in general is a type of service provided over the CE-= PE interface (it falls under the UNI case as no routing adjacency is in place between C= E and PE). + Advertisement models (to be detailed in dedicated document/documents) The CE-PE interface in the overlay model context foresees two types of adv= ertisement models.(names still to be agreed) A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and augmented by a number of actived draft (references to various drafts to be added). The Augmented UNI is a particular type of CE-PE interface where only signa= ling messages are exchanged between CE and PE. Messages from CE to PE can include a set of parameters to be used by the PE as path computation constraints when computing a path in the provider domain network, while messages from = PE to CE can include a set of parameters qualifying the LSP being established= , like for example SRLG, delay, loss etc. B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply called wit= h the general CE-PE interface term?) allowing the establishment of signaling and= routing adjacency between CE and PE. Routing info passed from PE to CE comprise overlay topo= logy information including (but not limited to) virtual links, connectivity matrices and access links= with parameters qualifying each of them in terms of e.g. SRLG, loss, delay etc. Signaling information= and procedures are compliant with RFC4208. + Open issues/questions 1. PCE-PCEP - do we need to include considerations about PCE and PCEP into= the overlay framework context? 2. BGP-LS needs to be considered 3. Should potentials be included? E.g. I2RS? 4. Virtual links: wouldn't a different definition of virtual links avoid t= he advertisement of connectivity matrices (this is out of the fwk scope but= within the advertisement models one)? Take this example: PE1-----CE1 CE2-----PE2 CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 i.e. There are 2 VL connecting CE1 and CE2 that could be available for PE1 = and PE2 to set up an adjacency in the customer domain. CE1 and/or CE2 can b= e blocking nodes so VL1 and/or VL2 are available only depending on the conn= ectivity matrices of CE1 and CE2. Hence PEs need to be aware of both VL and= connectivity matrices. My point is: if CE1 advertises to PE1 only the VL t= hat his connectivity matrix allows to be connected to PE1 (e.g. VL1 only) a= nd not all of them, it should be possible to avoid the connectivity matrice= s advertisement.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DANIELE CECCARELLI =20 System & Technology - PDU Optical & Metro=20 Via E.Melen, 77 Genova, Italy Phone +390106002512 Mobile +393346725750 daniele.ceccarelli@ericsson.com www.ericsson.com =20 This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer =20 From IBryskin@advaoptical.com Wed Jan 16 09:50:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D3421F8B8C for ; Wed, 16 Jan 2013 09:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 v1Bd-0mJHIvK for ; Wed, 16 Jan 2013 09:50:02 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7507021F8B8A for ; Wed, 16 Jan 2013 09:50:00 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0GHnt8O017959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jan 2013 18:49:56 +0100 Received: from MUC-SRV-MBX1.advaoptical.com (172.20.1.95) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Wed, 16 Jan 2013 18:49:55 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 16 Jan 2013 18:49:43 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0099.000; Wed, 16 Jan 2013 12:49:42 -0500 From: Igor Bryskin To: Daniele Ceccarelli , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAEislQ Date: Wed, 16 Jan 2013 17:49:41 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-16_06:2013-01-16, 2013-01-16, 1970-01-01 signatures=0 Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 17:50:03 -0000 Daniel, One correction: VN may represent a fraction of a real node. This makes possible for the net= work to advertise a blocking PE as a set of non-blocking PE and thus allevi= ate the client path computer from dealing with blocking PEs. Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli Sent: Wednesday, January 16, 2013 10:33 AM To: CCAMP Subject: [CCAMP] Overlay model framework v2 Dear overlayers, Please find below a new version (v2) of the framework summary reflecting th= e latest discussions. Again i hope i've captured all the comments around, s= orry if anything is missing, in case just let me know what i missed. BR Daniele + Disclaimer: 1. Packet opto integration is often considered but the work can be extente= d to any type of SC. Eg. TDM over LSC. + Terminology: 1. Virtual Link: A virtual link is a potential path between two virtual or= real network elements in a provider layer network that is maintained/con= trolled in and by the provider domain control plane (and as such cannot tr= ansport any traffic/data and protected from being de-provisioned) and which can be instantiated in the data plane (and then = can carry/transport/forward traffic/data) preserving previously advertised= attributes such as fate sharing information. 2. Virtual Node: Virtual node is a collection of zero or more provider ne= twork domain nodes that are collectively represented to the clients as a s= ingle node that exists in the customer layer network and is capable of ter= minating of access, inter-domain and virtual links. 3. Virtual Topology: Virtual topology is a collection of one or more virtu= al or real provider network domain nodes that exist in the customer layer = network and are interconnected via 0 or more virtual links. 4. Overlay topology: is a superset of virtual topologies provided by each= of provider network domains, access and inter-domain links. 5. Access Link: Link between OC and OE. GMPLS runs on that link. It can su= pport any of the SCs supported by the GMPLS. 6. CE (customer Edge): Something like the CN in RFC4208 teminology but (i= ) receiving virtual topology from the provider network and requesting the = set up of one of them or (ii) requesting the computation and establishment of a path accordingly to= given constraints in the provider network and receiving the parameters ch= aracterizing such path. (ii) =3D=3D UNI. 7. PE (provider Edge): Something like the EN in RFC4208 but able to deal w= ith (i) and (ii) above. 8. PE-CE interface (former ONI) : Interface allowing for signaling and rou= ting messages exchange between customer overlay and provider network. Rout= ing information consists on virtual topology advertisement. When there is = no routing adjacency across the interface it is equivalent to the GMPLS UN= I defined in 4208. Signaling messages are compliant with RFC4208. Informat= ion related to path carachteristics, e.g. TE-metrics, collected SRLG, path= delay etc, either passed from CE to PE via signaling after the LSP establi= shment in the core network or from CE to PE to be used as path computation= constraints, fall under the definition of signaling info and not routing = info). 9. CE-CE (former O-NNI): Interface on the links between different provider= networks in the overlay model environment. Same features of the CE-PE app= ly to this interface.=20 + Statements 1. In the context of overlay model we are aiming to build an overlay topol= ogy for the customer network domains 2. The overlay topology is comprised= of: a) access links (links connecting client NEs to the provider network do= mains). They can be PSC or LSC. b) inter-domain links (links interconnecting server network domains) c) virtual topology provided by the provider network domains. Virtual L= inks + Virtual Nodes (TBD) + Connectivity Matrix (with a set of parameters= e.g. SRLG, optical impairments, delay etc for each entry) describing conn= ectivity between access links and virtual links. 3. In the context of overlay model we manage hierarchy of overlay topolo= gies with overlay/underlay relationships 4. In the context of overlay mod= el multi-layering and inter-layer relationships are peripheral at best, it is all about horizontal network integration =20 5. The overlay model assumes one CP instance for the customer network and = a separate instance for the provider network and in the CE-PE interface ca= se the provider network also surreptitiously participates in the customer = network by injecting virtual topology information into it. 6. L1VPN (and LxVPN) in general is a type of service provided over the CE-= PE interface (it falls under the UNI case as no routing adjacency is in pl= ace between CE and PE). + Advertisement models (to be detailed in dedicated document/documents) The CE-PE interface in the overlay model context foresees two types of adv= ertisement models.(names still to be agreed) A. Augmented UNI: The GMPLS U= NI is defined in RFC4208 and augmented by a number of actived draft (refer= ences to various drafts to be added). The Augmented UNI is a particular type of CE-PE interface where only signa= ling messages are exchanged between CE and PE. Messages from CE to PE can = include a set of parameters to be used by the PE as path computation const= raints when computing a path in the provider domain network, while message= s from PE to CE can include a set of parameters qualifying the LSP being e= stablished, like for example SRLG, delay, loss etc. B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply called wit= h the general CE-PE interface term?) allowing the establishment of signali= ng and routing adjacency between CE and PE. Routing info passed from PE to= CE comprise overlay topology information including (but not limited to) v= irtual links, connectivity matrices and access links with parameters qualif= ying each of them in terms of e.g. SRLG, loss, delay etc. Signaling inform= ation and procedures are compliant with RFC4208. + Open issues/questions 1. PCE-PCEP - do we need to include considerations about PCE and PCEP into= the overlay framework context? 2. BGP-LS needs to be considered 3. Should potentials be included? E.g. I2RS? 4. Virtual links: wouldn't a different definition of virtual links avoid t= he advertisement of connectivity matrices (this is out of the fwk scope but= within the advertisement models one)? Take this example: PE1-----CE1 CE2-----PE2 CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 i.e. There are 2 VL connecting CE1 and CE2 that could be available for PE1 = and PE2 to set up an adjacency in the customer domain. CE1 and/or CE2 can b= e blocking nodes so VL1 and/or VL2 are available only depending on the conn= ectivity matrices of CE1 and CE2. Hence PEs need to be aware of both VL and= connectivity matrices. My point is: if CE1 advertises to PE1 only the VL t= hat his connectivity matrix allows to be connected to PE1 (e.g. VL1 only) a= nd not all of them, it should be possible to avoid the connectivity matrice= s advertisement.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DANIELE CECCARELLI System & Technology - PDU Optical & Metro=20 Via E.Melen, 77 Genova, Italy Phone +390106002512 Mobile +393346725750 daniele.ceccarelli@ericsson.com www.ericsson.com =20 This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer =20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From ggrammel@juniper.net Wed Jan 16 12:17:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0BF21F8B47 for ; Wed, 16 Jan 2013 12:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 U1-yEV4uH0QU for ; Wed, 16 Jan 2013 12:17:18 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 87D5221F8B45 for ; Wed, 16 Jan 2013 12:17:18 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUPcKzowTQAuyEQFsN4NBs/r1oqd37ybU@postini.com; Wed, 16 Jan 2013 12:17:18 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 Jan 2013 12:14:57 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 16 Jan 2013 12:14:56 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.12) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 16 Jan 2013 12:16:44 -0800 Received: from mail240-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 16 Jan 2013 20:14:55 +0000 Received: from mail240-tx2 (localhost [127.0.0.1]) by mail240-tx2-R.bigfish.com (Postfix) with ESMTP id 9D37E32034E for ; Wed, 16 Jan 2013 20:14:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zz9371Id6eah168aJ542Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL18602eh8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail240-tx2 (localhost.localdomain [127.0.0.1]) by mail240-tx2 (MessageSwitch) id 1358367293314887_32165; Wed, 16 Jan 2013 20:14:53 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.240]) by mail240-tx2.bigfish.com (Postfix) with ESMTP id 45DB742006D; Wed, 16 Jan 2013 20:14:53 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 16 Jan 2013 20:14:52 +0000 Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.8.191]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0257.004; Wed, 16 Jan 2013 20:14:52 +0000 From: Gert Grammel To: Igor Bryskin , Daniele Ceccarelli , CCAMP Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: AQHN9CYjMiKiFFB7rkm35jsxXhuK6g== Date: Wed, 16 Jan 2013 20:14:51 +0000 Message-ID: <305443B66F0CD946A3107753337A031113124C5A@CH1PRD0511MB431.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 20:17:19 -0000 Agree with Igor :-) Gert ________________________________________ From: ccamp-bounces@ietf.org on behalf of Igor Bryskin Sent: Wednesday, January 16, 2013 6:49:41 PM To: Daniele Ceccarelli; CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Daniel, One correction: VN may represent a fraction of a real node. This makes possible for the net= work to advertise a blocking PE as a set of non-blocking PE and thus allevi= ate the client path computer from dealing with blocking PEs. Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli Sent: Wednesday, January 16, 2013 10:33 AM To: CCAMP Subject: [CCAMP] Overlay model framework v2 Dear overlayers, Please find below a new version (v2) of the framework summary reflecting th= e latest discussions. Again i hope i've captured all the comments around, s= orry if anything is missing, in case just let me know what i missed. BR Daniele + Disclaimer: 1. Packet opto integration is often considered but the work can be extente= d to any type of SC. Eg. TDM over LSC. + Terminology: 1. Virtual Link: A virtual link is a potential path between two virtual or= real network elements in a provider layer network that is maintained/con= trolled in and by the provider domain control plane (and as such cannot tr= ansport any traffic/data and protected from being de-provisioned) and which can be instantiated in the data plane (and then = can carry/transport/forward traffic/data) preserving previously advertised= attributes such as fate sharing information. 2. Virtual Node: Virtual node is a collection of zero or more provider ne= twork domain nodes that are collectively represented to the clients as a s= ingle node that exists in the customer layer network and is capable of ter= minating of access, inter-domain and virtual links. 3. Virtual Topology: Virtual topology is a collection of one or more virtu= al or real provider network domain nodes that exist in the customer layer = network and are interconnected via 0 or more virtual links. 4. Overlay topology: is a superset of virtual topologies provided by each= of provider network domains, access and inter-domain links. 5. Access Link: Link between OC and OE. GMPLS runs on that link. It can su= pport any of the SCs supported by the GMPLS. 6. CE (customer Edge): Something like the CN in RFC4208 teminology but (i= ) receiving virtual topology from the provider network and requesting the = set up of one of them or (ii) requesting the computation and establishment of a path accordingly to= given constraints in the provider network and receiving the parameters ch= aracterizing such path. (ii) =3D=3D UNI. 7. PE (provider Edge): Something like the EN in RFC4208 but able to deal w= ith (i) and (ii) above. 8. PE-CE interface (former ONI) : Interface allowing for signaling and rou= ting messages exchange between customer overlay and provider network. Rout= ing information consists on virtual topology advertisement. When there is = no routing adjacency across the interface it is equivalent to the GMPLS UN= I defined in 4208. Signaling messages are compliant with RFC4208. Informat= ion related to path carachteristics, e.g. TE-metrics, collected SRLG, path= delay etc, either passed from CE to PE via signaling after the LSP establi= shment in the core network or from CE to PE to be used as path computation= constraints, fall under the definition of signaling info and not routing = info). 9. CE-CE (former O-NNI): Interface on the links between different provider= networks in the overlay model environment. Same features of the CE-PE app= ly to this interface. + Statements 1. In the context of overlay model we are aiming to build an overlay topol= ogy for the customer network domains 2. The overlay topology is comprised= of: a) access links (links connecting client NEs to the provider network do= mains). They can be PSC or LSC. b) inter-domain links (links interconnecting server network domains) c) virtual topology provided by the provider network domains. Virtual L= inks + Virtual Nodes (TBD) + Connectivity Matrix (with a set of parameters= e.g. SRLG, optical impairments, delay etc for each entry) describing conn= ectivity between access links and virtual links. 3. In the context of overlay model we manage hierarchy of overlay topolo= gies with overlay/underlay relationships 4. In the context of overlay mod= el multi-layering and inter-layer relationships are peripheral at best, it is all about horizontal network integration 5. The overlay model assumes one CP instance for the customer network and = a separate instance for the provider network and in the CE-PE interface ca= se the provider network also surreptitiously participates in the customer = network by injecting virtual topology information into it. 6. L1VPN (and LxVPN) in general is a type of service provided over the CE-= PE interface (it falls under the UNI case as no routing adjacency is in pl= ace between CE and PE). + Advertisement models (to be detailed in dedicated document/documents) The CE-PE interface in the overlay model context foresees two types of adv= ertisement models.(names still to be agreed) A. Augmented UNI: The GMPLS U= NI is defined in RFC4208 and augmented by a number of actived draft (refer= ences to various drafts to be added). The Augmented UNI is a particular type of CE-PE interface where only signa= ling messages are exchanged between CE and PE. Messages from CE to PE can = include a set of parameters to be used by the PE as path computation const= raints when computing a path in the provider domain network, while message= s from PE to CE can include a set of parameters qualifying the LSP being e= stablished, like for example SRLG, delay, loss etc. B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply called wit= h the general CE-PE interface term?) allowing the establishment of signali= ng and routing adjacency between CE and PE. Routing info passed from PE to= CE comprise overlay topology information including (but not limited to) v= irtual links, connectivity matrices and access links with parameters qualif= ying each of them in terms of e.g. SRLG, loss, delay etc. Signaling inform= ation and procedures are compliant with RFC4208. + Open issues/questions 1. PCE-PCEP - do we need to include considerations about PCE and PCEP into= the overlay framework context? 2. BGP-LS needs to be considered 3. Should potentials be included? E.g. I2RS? 4. Virtual links: wouldn't a different definition of virtual links avoid t= he advertisement of connectivity matrices (this is out of the fwk scope but= within the advertisement models one)? Take this example: PE1-----CE1 CE2-----PE2 CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 i.e. There are 2 VL connecting CE1 and CE2 that could be available for PE1 = and PE2 to set up an adjacency in the customer domain. CE1 and/or CE2 can b= e blocking nodes so VL1 and/or VL2 are available only depending on the conn= ectivity matrices of CE1 and CE2. Hence PEs need to be aware of both VL and= connectivity matrices. My point is: if CE1 advertises to PE1 only the VL t= hat his connectivity matrix allows to be connected to PE1 (e.g. VL1 only) a= nd not all of them, it should be possible to avoid the connectivity matrice= s advertisement. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DANIELE CECCARELLI System & Technology - PDU Optical & Metro Via E.Melen, 77 Genova, Italy Phone +390106002512 Mobile +393346725750 daniele.ceccarelli@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Dieter.Beller@alcatel-lucent.com Wed Jan 16 14:21:39 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A1721F88E3 for ; Wed, 16 Jan 2013 14:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.541 X-Spam-Level: X-Spam-Status: No, score=-4.541 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_HTML_ONLY=1.457, 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 1qFYZb7cy5V8 for ; Wed, 16 Jan 2013 14:21:36 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF821F88EA for ; Wed, 16 Jan 2013 14:21:36 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r0GMLQBa022290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jan 2013 16:21:28 -0600 (CST) Received: from destgsu0709.de.alcatel-lucent.com (slsv7at.de.alcatel-lucent.com [149.204.245.107]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r0GMLPDQ000686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2013 23:21:26 +0100 Received: from [135.244.176.10] (beller.lra.lucent.com [135.244.176.10]) (authenticated bits=0) by destgsu0709.de.alcatel-lucent.com (8.14.3/8.13.8) with ESMTP id r0GMLKdO015031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2013 23:21:24 +0100 (CET) Message-ID: <50F727E0.4060905@alcatel-lucent.com> Date: Wed, 16 Jan 2013 23:21:20 +0100 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Igor Bryskin References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> In-Reply-To: Content-Type: multipart/related; boundary="------------060007030404020301010807" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 22:21:40 -0000 This is a multi-part message in MIME format. --------------060007030404020301010807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Igor,
On 16.01.2013 18:49, Igor Bryskin wrote:
Daniel,
One correction:
VN may represent a fraction of a real node. This makes possible for the network to advertise a blocking PE as a set of non-blocking PE and thus alleviate the client path computer from dealing with blocking PEs.
why do you prefer to use the term Virtual Node for the non-blocking sub-nodes that compose
a larger blocking node. Representing the sub-nodes in the topological view is IMHO more the
representation of the real entities rather than virtual ones and provides a white box view of that
node instead of a black box view.


Thanks,
Dieter

Igor

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, January 16, 2013 10:33 AM
To: CCAMP
Subject: [CCAMP] Overlay model framework v2

Dear overlayers,

Please find below a new version (v2) of the framework summary reflecting the latest discussions. Again i hope i've captured all the comments around, sorry if anything is missing, in case just let me know what i missed.

BR
Daniele


+ Disclaimer:
 1. Packet opto integration is often considered but the work can be extented to any type of SC. Eg. TDM over LSC.

+ Terminology:
 1. Virtual Link: A virtual link is a potential path between two virtual or real network  elements in a provider layer network  that is maintained/controlled in and by the provider  domain control plane (and as such cannot transport any traffic/data and protected from being
 de-provisioned) and which can be instantiated in the data plane (and then can  carry/transport/forward traffic/data) preserving previously advertised attributes such as  fate sharing information.
 2.  Virtual Node: Virtual node is a collection of zero or more provider network domain  nodes that are collectively represented to the clients as a single node that  exists in the customer layer network and is capable of terminating of access,  inter-domain and virtual links.
 3. Virtual Topology: Virtual topology is a collection of one or more virtual or real provider  network domain nodes that exist in the customer layer network and are interconnected  via 0 or more virtual links.
 4. Overlay topology:  is a superset of virtual topologies provided by each of  provider network domains, access and inter-domain links.
 5. Access Link: Link between OC and OE. GMPLS runs on that link. It can support  any of the SCs supported by the GMPLS.
 6. CE (customer Edge): Something like the CN in RFC4208 teminology  but (i) receiving  virtual topology from the provider network and requesting the set up of one of them or
 (ii) requesting the computation and establishment of a path accordingly to given constraints  in the provider network and receiving the parameters characterizing such path. (ii) == UNI.
 7. PE (provider Edge): Something like the EN in RFC4208 but able to deal with (i) and (ii) above.
 8. PE-CE interface (former ONI) : Interface allowing for signaling and routing messages  exchange between customer overlay and provider network. Routing information consists on  virtual topology advertisement. When there is no routing adjacency across the interface  it is equivalent to the GMPLS UNI defined in 4208. Signaling messages are compliant with  RFC4208. Information related to path carachteristics, e.g. TE-metrics, collected SRLG,  path delay etc, either passed from CE to PE via signaling after the LSP establishment  in the core network or from CE to PE to be used as path computation constraints, fall  under the definition of signaling info and not routing info).
 9. CE-CE (former O-NNI): Interface on the links between different provider networks  in the overlay model environment. Same features of the CE-PE apply to this interface. 

+ Statements
 1. In the context of overlay model we are aiming to build an overlay topology for  the customer network domains  2. The overlay topology is comprised of:
    a) access links (links connecting client NEs to the provider network domains).
 They can be PSC or LSC.
    b) inter-domain links (links interconnecting server network domains)
    c) virtual topology provided by the provider network domains. Virtual Links  + Virtual Nodes (TBD) + Connectivity Matrix (with a set of parameters e.g. SRLG,  optical impairments, delay etc for each entry) describing connectivity between access links and virtual links.
 3. In the context of overlay model we manage  hierarchy  of overlay topologies  with overlay/underlay relationships  4. In the context of overlay model multi-layering and inter-layer relationships
 are peripheral at best, it is all about horizontal network integration   
 5. The overlay model assumes one CP instance for the customer network and a separate  instance for the provider network and in the CE-PE interface case the provider  network also surreptitiously participates in the customer network by injecting  virtual topology information into it.
 6. L1VPN (and LxVPN) in general is a type of service provided over the CE-PE interface  (it falls under the UNI case as no routing adjacency is in place between CE and PE).


+ Advertisement models (to be detailed in dedicated document/documents)
 The CE-PE interface in the overlay model context foresees two types of advertisement  models.(names still to be agreed) A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and augmented by  a number of actived draft (references to various drafts to be added).
 The Augmented UNI is a particular type of CE-PE interface where only signaling messages  are exchanged between CE and PE. Messages from CE to PE can include  a set of parameters to be used by the PE as path computation constraints  when computing a path in the provider domain network, while messages from PE  to CE can include a set of parameters qualifying the LSP being established,  like for example SRLG, delay, loss etc.
B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply called with the  general CE-PE interface term?) allowing the establishment of signaling and routing adjacency  between CE and PE. Routing info passed from PE to CE comprise overlay topology information including  (but not limited to) virtual links, connectivity matrices and access links with parameters qualifying  each of them in terms of e.g. SRLG, loss, delay etc. Signaling information and procedures are  compliant with RFC4208.

+ Open issues/questions
 1. PCE-PCEP - do we need to include considerations about PCE and PCEP into the overlay framework context?
 2. BGP-LS needs to be considered
 3. Should potentials be included? E.g. I2RS?
 4. Virtual links: wouldn't a different definition of virtual links avoid the advertisement of connectivity matrices (this is out of the fwk scope but within the advertisement models one)?
Take this example:
PE1-----CE1               CE2-----PE2
        CE1======VL1======CE2
        CE1======VL2======CE2
i.e. There are 2 VL connecting CE1 and CE2 that could be available for PE1 and PE2 to set up an adjacency in the customer domain. CE1 and/or CE2 can be blocking nodes so VL1 and/or VL2 are available only depending on the connectivity matrices of CE1 and CE2. Hence PEs need to be aware of both VL and connectivity matrices. My point is: if CE1 advertises to PE1 only the VL that his connectivity matrix allows to be connected to PE1 (e.g. VL1 only) and not all of them, it should be possible to avoid the connectivity matrices advertisement. 

 
===================================
DANIELE CECCARELLI
System & Technology - PDU Optical & Metro 

Via E.Melen, 77
Genova, Italy
Phone +390106002512
Mobile +393346725750
daniele.ceccarelli@ericsson.com
www.ericsson.com  

This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer  

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

--

DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub · Dr. Rainer Fechner · Andreas Gehe

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.
--------------060007030404020301010807 Content-Type: image/jpeg; name="Corporate-sig-logo.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Corporate-sig-logo.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoL EAACAQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOh sfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5 OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX 2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRx CEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVW N4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiI mKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A3+Pfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69 1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvnsm0T1ExVp4aKgx+P pIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBVRQWdjhVBPl09 bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnDsnYeNhlS t353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs6eNO xxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ 7Acje43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BIN KHjT7QSPl1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3 PH4/Pq/b0eT0e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT 51rSnRWch3x82aXqD5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7 jxFdV1j4TJaq6J6L7a/lkQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1 +i9/YvC0VVt7r6j2f9umY7C/jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4K Yys7u617g3DtL45dIN8iev44/kN1HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWp jPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72i yUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfPqn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0d L3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkFWRjEDeM1aInut0WtK46Hyr7F+REPyX2R 1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvWb0i7jz1LWYYx1K5iFkpWMrKQhgZZ PdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh1/HTdgdV0u+MRhIO0YOz5aBN t4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0HFV/Gyr6SrN75T5Mnsfb0 E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/In5+r8YMp2ZT/AAAo JPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6Pfut0WtK4+zox q9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNESRCCZCQv utUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9ppiTtr KyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y 8h8B8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm 1HVSyx+/dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr 5+uzTrn9ttjaeJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b3 10AfkPsCeDoPqKv3bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaH yVl787t2HP8AGeli6R2R1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoW YI8c6BPdaoKcc9BLi++PnVU9IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq 0W8o6WTC9mVWJ29j8dkP4JjmWtL5E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11t fcXx07THcm1UqPkPv7J7Xq8luHYNbtE0L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q9 5/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Ti z91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZn ObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8AY6S1D3l8yKjY/wAOs3UfC+Cm3h3H urA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0zOT4L+V1ce63Rc5+zrXk/m+/N PFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27fkrt/dO69n7RzOydsQYf 4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQveG1+kG+YX8475J7R HyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWqqJI09+69QUqR Wi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou3N0bl7bh 7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP/n3f If4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D 2f1juzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1q iUOe2or506MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7ox c9PgMzNkcNHFkIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi0 6hgjpyeOGOR0t38SEEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2f Uz/7L/2dlPieazAU9AaOT+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z 9H8DvlB/M/h762NkqPau5e3uv9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7c FNU1VJjK2i/ap6emp5EqT7reldQT+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F /HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0 w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cu LyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7/hQ7W75qfjn8beq9vy1mal7A7yo6KvpK KlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+8sfulw7fFzVu283xVTabWSHbgiNI pkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt742fyrYqvMb7+RvyK33s7fPy0o NgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHkq9o6Srnp8od3vMvNvOF3 vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXbS7xhbWJSI9Qr8u0c Kk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5Jtr9LVf9/cbi 8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WVoZGuKSXY 8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv/u5/ EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r 3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf uvde9+691737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7Ahl pnTdC5HaVFFjpVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w 8FNt+u3vjtqYfY2O3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjN z7Oqcl8PuhpZthbewm09sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63 rb1PSw3N8BfhPvPcvbe8N2fFforce5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3 FUlcKtl+7NZSQTmQywxuvuvam9TjpWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP 2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7i fx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/ g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSxHX2Dx22tgxYlkpBTRVmx9vYejosPVtG1 XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+3Oz9uZ/aXY2+JuvduT5TfO392U70 m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnTL13/AC+vhL1NjosR1z8Yen9p 4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4o8aaiT7dYw7X91ssx4np T9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ33Xzz0xqTuyh2hQxY pK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7LVQlpsPg947Zo 6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBcotNTQuQSV BoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ2D2x HndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3 b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U 49O+U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN 25jcvXfa4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMi apnXUqqFLJErN1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h /wANi+4/0ufxn++n9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sN WPpdHg+Bq4avB/Hpp4v6mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697 917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X uve/de697917r3v3XugA+RP/AB59D/zID/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/ ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8A N3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/an4/9v8X59C17IumOv//Z --------------060007030404020301010807-- From SBardalai@infinera.com Wed Jan 16 14:47:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CB611E80B8 for ; Wed, 16 Jan 2013 14:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 BLZO8B4AJ9IW for ; Wed, 16 Jan 2013 14:47:37 -0800 (PST) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2033211E809A for ; Wed, 16 Jan 2013 14:47:37 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 14:47:36 -0800 From: Snigdho Bardalai To: Daniele Ceccarelli , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAOJ5ug Date: Wed, 16 Jan 2013 22:47:35 +0000 Message-ID: <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 22:47:38 -0000 Hi Daniele, A few comments. Please see in-line. Thanks Snigdho > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Daniele Ceccarelli > Sent: Wednesday, January 16, 2013 7:33 AM > To: CCAMP > Subject: [CCAMP] Overlay model framework v2 >=20 > Dear overlayers, >=20 > Please find below a new version (v2) of the framework summary > reflecting the latest discussions. Again i hope i've captured all the > comments around, sorry if anything is missing, in case just let me know > what i missed. >=20 > BR > Daniele >=20 >=20 > + Disclaimer: > 1. Packet opto integration is often considered but the work can be > extented to any type of SC. Eg. TDM over LSC. >=20 > + Terminology: > 1. Virtual Link: A virtual link is a potential path between two > virtual or real network elements in a provider layer network that is > maintained/controlled in and by the provider domain control plane (and > as such cannot transport any traffic/data and protected from being > de-provisioned) and which can be instantiated in the data plane (and > then can carry/transport/forward traffic/data) preserving previously > advertised attributes such as fate sharing information. > 2. Virtual Node: Virtual node is a collection of zero or more > provider network domain nodes that are collectively represented to the > clients as a single node that exists in the customer layer network and > is capable of terminating of access, inter-domain and virtual links. [SCB] Agree with Igor's comment - a virtual node can be a combination of mu= ltiple nodes or a part of the single node, but to the customer node this is= transparent. > 3. Virtual Topology: Virtual topology is a collection of one or more > virtual or real provider network domain nodes that exist in the > customer layer network and are interconnected via 0 or more virtual > links. [SCB] Since the topology advertised by the provider network can contain rea= l or virtual elements, why do we call it "virtual topology"? Should it simp= ly be called "provider topology"? And then specify that it may contain both= virtual or real elements. > 4. Overlay topology: is a superset of virtual topologies provided by > each of provider network domains, access and inter-domain links. [SCB] A more concise definition for the overlay topology is - CE nodes + Ac= cess-links + provider topology as advertised by the provider network. > 5. Access Link: Link between OC and OE. GMPLS runs on that link. It > can support any of the SCs supported by the GMPLS. > 6. CE (customer Edge): Something like the CN in RFC4208 teminology > but (i) receiving virtual topology from the provider network and > requesting the set up of one of them or > (ii) requesting the computation and establishment of a path > accordingly to given constraints in the provider network and receiving > the parameters characterizing such path. (ii) =3D=3D UNI. > 7. PE (provider Edge): Something like the EN in RFC4208 but able to > deal with (i) and (ii) above. > 8. PE-CE interface (former ONI) : Interface allowing for signaling and > routing messages exchange between customer overlay and provider > network. Routing information consists on virtual topology > advertisement. When there is no routing adjacency across the interface > it is equivalent to the GMPLS UNI defined in 4208. Signaling messages > are compliant with RFC4208. Information related to path > carachteristics, e.g. TE-metrics, collected SRLG, path delay etc, > either passed from CE to PE via signaling after the LSP establishment > in the core network or from CE to PE to be used as path computation > constraints, fall under the definition of signaling info and not > routing info). > 9. CE-CE (former O-NNI): Interface on the links between different > provider networks in the overlay model environment. Same features of > the CE-PE apply to this interface. [SCB] Is this "PE-PE" instead of "CE-CE"?=20 >=20 > + Statements > 1. In the context of overlay model we are aiming to build an overlay > topology for the customer network domains 2. The overlay topology is > comprised of: > a) access links (links connecting client NEs to the provider > network domains). > They can be PSC or LSC. > b) inter-domain links (links interconnecting server network > domains) > c) virtual topology provided by the provider network domains. > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a set > of parameters e.g. SRLG, optical impairments, delay etc for each > entry) describing connectivity between access links and virtual links. > 3. In the context of overlay model we manage hierarchy of overlay > topologies with overlay/underlay relationships 4. In the context of > overlay model multi-layering and inter-layer relationships > are peripheral at best, it is all about horizontal network integration > 5. The overlay model assumes one CP instance for the customer network > and a separate instance for the provider network and in the CE-PE > interface case the provider network also surreptitiously participates > in the customer network by injecting virtual topology information into > it. [SCB] Specific implementations may or may not have a single instance for th= e provider and the overlay. > 6. L1VPN (and LxVPN) in general is a type of service provided over the > CE-PE interface (it falls under the UNI case as no routing adjacency > is in place between CE and PE). >=20 >=20 > + Advertisement models (to be detailed in dedicated document/documents) > The CE-PE interface in the overlay model context foresees two types of > advertisement models.(names still to be agreed) A. Augmented UNI: The > GMPLS UNI is defined in RFC4208 and augmented by a number of actived > draft (references to various drafts to be added). > The Augmented UNI is a particular type of CE-PE interface where only > signaling messages are exchanged between CE and PE. Messages from CE > to PE can include a set of parameters to be used by the PE as path > computation constraints when computing a path in the provider domain > network, while messages from PE to CE can include a set of parameters > qualifying the LSP being established, like for example SRLG, delay, > loss etc. > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply called > with the general CE-PE interface term?) allowing the establishment of > signaling and routing adjacency between CE and PE. Routing info passed > from PE to CE comprise overlay topology information including (but not > limited to) virtual links, connectivity matrices and access links with > parameters qualifying each of them in terms of e.g. SRLG, loss, delay > etc. Signaling information and procedures are compliant with RFC4208. >=20 > + Open issues/questions > 1. PCE-PCEP - do we need to include considerations about PCE and PCEP > into the overlay framework context? [SCB] IMO - this should be described in the overlay framework document to e= stablish the context. > 2. BGP-LS needs to be considered > 3. Should potentials be included? E.g. I2RS? > 4. Virtual links: wouldn't a different definition of virtual links > avoid the advertisement of connectivity matrices (this is out of the > fwk scope but within the advertisement models one)? > Take this example: > PE1-----CE1 CE2-----PE2 > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 > i.e. There are 2 VL connecting CE1 and CE2 that could be available for > PE1 and PE2 to set up an adjacency in the customer domain. CE1 and/or > CE2 can be blocking nodes so VL1 and/or VL2 are available only > depending on the connectivity matrices of CE1 and CE2. Hence PEs need > to be aware of both VL and connectivity matrices. My point is: if CE1 > advertises to PE1 only the VL that his connectivity matrix allows to be > connected to PE1 (e.g. VL1 only) and not all of them, it should be > possible to avoid the connectivity matrices advertisement. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > DANIELE CECCARELLI > System & Technology - PDU Optical & Metro >=20 > Via E.Melen, 77 > Genova, Italy > Phone +390106002512 > Mobile +393346725750 > daniele.ceccarelli@ericsson.com > www.ericsson.com >=20 > This Communication is Confidential. We only send and receive email on > the basis of the term set out at www.ericsson.com/email_disclaimer >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Wed Jan 16 14:55:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D28B1F0CF5 for ; Wed, 16 Jan 2013 14:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 hsUeUq6tf9SB for ; Wed, 16 Jan 2013 14:55:34 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0271D1F0CB3 for ; Wed, 16 Jan 2013 14:55:33 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0GMtNEx027933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jan 2013 23:55:23 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Wed, 16 Jan 2013 23:55:22 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0099.000; Wed, 16 Jan 2013 17:55:21 -0500 From: Igor Bryskin To: Dieter Beller Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAEislQABQwtAAACj9HsA== Date: Wed, 16 Jan 2013 22:55:20 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F727E0.4060905@alcatel-lucent.com> In-Reply-To: <50F727E0.4060905@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.81] Content-Type: multipart/related; boundary="_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A19106FE0atlsrvmail10atl_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-16_08:2013-01-16, 2013-01-16, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 22:55:36 -0000 --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A19106FE0atlsrvmail10atl_ Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19106FE0atlsrvmail10atl_" --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19106FE0atlsrvmail10atl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dieter, I like the term Virtual Node to distinguish it from the real provider netwo= rk node. The Virtual Topology presented by the provider network to the clie= nts is comprised of Virtual Nodes (interconnected via Virtual Links) becaus= e: a) The nodes/links exist in the client layer; b) The nodes/links are named from the client naming space Whether a given VN represents multiple provider real nodes, exactly one rea= l node, a fraction of one node or 5.75 nodes is immaterial. Furthermore, VN associated with a non-blocking part of a blocking switch is= a representation of the said non-blocking part in a Virtual Topology. Beca= use Virtual Topologies are, generally speaking, different for different set= of clients, the VNs representing the same non-blocking part of a real prov= ider switch is also different in different Virtual Topologies. Igor From: Dieter Beller [mailto:Dieter.Beller@alcatel-lucent.com] Sent: Wednesday, January 16, 2013 5:21 PM To: Igor Bryskin Cc: Daniele Ceccarelli; CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Hi Igor, On 16.01.2013 18:49, Igor Bryskin wrote: Daniel, One correction: VN may represent a fraction of a real node. This makes possible for the net= work to advertise a blocking PE as a set of non-blocking PE and thus allevi= ate the client path computer from dealing with blocking PEs. why do you prefer to use the term Virtual Node for the non-blocking sub-nod= es that compose a larger blocking node. Representing the sub-nodes in the topological view = is IMHO more the representation of the real entities rather than virtual ones and provides a= white box view of that node instead of a black box view. Thanks, Dieter Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Wednesday, January 16, 2013 10:33 AM To: CCAMP Subject: [CCAMP] Overlay model framework v2 Dear overlayers, Please find below a new version (v2) of the framework summary reflecting th= e latest discussions. Again i hope i've captured all the comments around, s= orry if anything is missing, in case just let me know what i missed. BR Daniele + Disclaimer: 1. Packet opto integration is often considered but the work can be extente= d to any type of SC. Eg. TDM over LSC. + Terminology: 1. Virtual Link: A virtual link is a potential path between two virtual or= real network elements in a provider layer network that is maintained/con= trolled in and by the provider domain control plane (and as such cannot tr= ansport any traffic/data and protected from being de-provisioned) and which can be instantiated in the data plane (and then = can carry/transport/forward traffic/data) preserving previously advertised= attributes such as fate sharing information. 2. Virtual Node: Virtual node is a collection of zero or more provider ne= twork domain nodes that are collectively represented to the clients as a s= ingle node that exists in the customer layer network and is capable of ter= minating of access, inter-domain and virtual links. 3. Virtual Topology: Virtual topology is a collection of one or more virtu= al or real provider network domain nodes that exist in the customer layer = network and are interconnected via 0 or more virtual links. 4. Overlay topology: is a superset of virtual topologies provided by each= of provider network domains, access and inter-domain links. 5. Access Link: Link between OC and OE. GMPLS runs on that link. It can su= pport any of the SCs supported by the GMPLS. 6. CE (customer Edge): Something like the CN in RFC4208 teminology but (i= ) receiving virtual topology from the provider network and requesting the = set up of one of them or (ii) requesting the computation and establishment of a path accordingly to= given constraints in the provider network and receiving the parameters ch= aracterizing such path. (ii) =3D=3D UNI. 7. PE (provider Edge): Something like the EN in RFC4208 but able to deal w= ith (i) and (ii) above. 8. PE-CE interface (former ONI) : Interface allowing for signaling and rou= ting messages exchange between customer overlay and provider network. Rout= ing information consists on virtual topology advertisement. When there is = no routing adjacency across the interface it is equivalent to the GMPLS UN= I defined in 4208. Signaling messages are compliant with RFC4208. Informat= ion related to path carachteristics, e.g. TE-metrics, collected SRLG, path= delay etc, either passed from CE to PE via signaling after the LSP establi= shment in the core network or from CE to PE to be used as path computation= constraints, fall under the definition of signaling info and not routing = info). 9. CE-CE (former O-NNI): Interface on the links between different provider= networks in the overlay model environment. Same features of the CE-PE app= ly to this interface. + Statements 1. In the context of overlay model we are aiming to build an overlay topol= ogy for the customer network domains 2. The overlay topology is comprised= of: a) access links (links connecting client NEs to the provider network do= mains). They can be PSC or LSC. b) inter-domain links (links interconnecting server network domains) c) virtual topology provided by the provider network domains. Virtual L= inks + Virtual Nodes (TBD) + Connectivity Matrix (with a set of parameters= e.g. SRLG, optical impairments, delay etc for each entry) describing conn= ectivity between access links and virtual links. 3. In the context of overlay model we manage hierarchy of overlay topolo= gies with overlay/underlay relationships 4. In the context of overlay mod= el multi-layering and inter-layer relationships are peripheral at best, it is all about horizontal network integration 5. The overlay model assumes one CP instance for the customer network and = a separate instance for the provider network and in the CE-PE interface ca= se the provider network also surreptitiously participates in the customer = network by injecting virtual topology information into it. 6. L1VPN (and LxVPN) in general is a type of service provided over the CE-= PE interface (it falls under the UNI case as no routing adjacency is in pl= ace between CE and PE). + Advertisement models (to be detailed in dedicated document/documents) The CE-PE interface in the overlay model context foresees two types of adv= ertisement models.(names still to be agreed) A. Augmented UNI: The GMPLS U= NI is defined in RFC4208 and augmented by a number of actived draft (refer= ences to various drafts to be added). The Augmented UNI is a particular type of CE-PE interface where only signa= ling messages are exchanged between CE and PE. Messages from CE to PE can = include a set of parameters to be used by the PE as path computation const= raints when computing a path in the provider domain network, while message= s from PE to CE can include a set of parameters qualifying the LSP being e= stablished, like for example SRLG, delay, loss etc. B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply called wit= h the general CE-PE interface term?) allowing the establishment of signali= ng and routing adjacency between CE and PE. Routing info passed from PE to= CE comprise overlay topology information including (but not limited to) v= irtual links, connectivity matrices and access links with parameters qualif= ying each of them in terms of e.g. SRLG, loss, delay etc. Signaling inform= ation and procedures are compliant with RFC4208. + Open issues/questions 1. PCE-PCEP - do we need to include considerations about PCE and PCEP into= the overlay framework context? 2. BGP-LS needs to be considered 3. Should potentials be included? E.g. I2RS? 4. Virtual links: wouldn't a different definition of virtual links avoid t= he advertisement of connectivity matrices (this is out of the fwk scope but= within the advertisement models one)? Take this example: PE1-----CE1 CE2-----PE2 CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 i.e. There are 2 VL connecting CE1 and CE2 that could be available for PE1 = and PE2 to set up an adjacency in the customer domain. CE1 and/or CE2 can b= e blocking nodes so VL1 and/or VL2 are available only depending on the conn= ectivity matrices of CE1 and CE2. Hence PEs need to be aware of both VL and= connectivity matrices. My point is: if CE1 advertises to PE1 only the VL t= hat his connectivity matrix allows to be connected to PE1 (e.g. VL1 only) a= nd not all of them, it should be possible to avoid the connectivity matrice= s advertisement. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DANIELE CECCARELLI System & Technology - PDU Optical & Metro Via E.Melen, 77 Genova, Italy Phone +390106002512 Mobile +393346725750 daniele.ceccarelli@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- [cid:image001.jpg@01CDF40F.494E2FC0] DIETER BELLER ALCATEL-LUCENT DEUTSCHLAND AG PROJECT MANAGER ASON/GMPLS CONTROL PLANE CORE NETWORKS BUSINESS DIVISION OPTICS BU, SWITCHING R&D Lorenzstrasse 10 70435 Stuttgart, Germany Phone: +49 711 821 43125 Mobil: +49 175 7266874 Dieter.Beller@alcatel-lucent.com Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub = =B7 Dr. Rainer Fechner =B7 Andreas Gehe This e-mail and its attachments, if any, may contain confidential informati= on. If you have received this e-mail in error, please notify us and delete or d= estroy the e-mail and its attachments, if any, immediately. If you have received this e-mail in error, you must not forward or make use= of the e-mail and its attachments, if any. --_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19106FE0atlsrvmail10atl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dieter,=

 <= /p>

I like the term Virtual N= ode to distinguish it from the real provider network node. The Virtual Topo= logy presented by the provider network to the clients is comprised of Virtual Nodes (interconnected via Virtual Links) because:

a) = ;     The nodes/links e= xist in the client layer;

b) = ;     The nodes/links a= re named from the client naming space

Whether a given VN repres= ents multiple provider real nodes, exactly one real node, a fraction of one= node or 5.75 nodes is immaterial.

Furthermore, VN associate= d with a non-blocking part of a blocking switch is a representation of the = said non-blocking part in a Virtual Topology. Because Virtual Topologies are, generally speaking, different for different set of clients= , the VNs representing the same non-blocking part of a real provider switch= is also different in different Virtual Topologies.

 <= /p>

Igor

 <= /p>

 <= /p>

From: Dieter Beller [mailto:Dieter.Beller@alcatel-lucen= t.com]
Sent: Wednesday, January 16, 2013 5:21 PM
To: Igor Bryskin
Cc: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

 

Hi Igor,=

On 16.01.2013 18:49, Igor Bryskin wrote:<= /p> 

Daniel,
One correction:
VN may represent a fraction of a real node. This makes possible for th=
e network to advertise a blocking PE as a set of non-blocking PE and thus a=
lleviate the client path computer from dealing with blocking PEs.

why do you prefer to use the term Virtual Node for t= he non-blocking sub-nodes that compose
a larger blocking node. Representing the sub-nodes in the topological view = is IMHO more the
representation of the real entities rather than virtual ones and provides a= white box view of that
node instead of a black box view.


Thanks,
Dieter

 
 
Igor
 
-----Original Message-----
From: ccamp-bounces@ietf.org=
 [mailto:ccamp-bounces@ietf.o=
rg] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, January 16, 2013 10:33 AM
To: CCAMP
Subject: [CCAMP] Overlay model framework v2
 
Dear overlayers,
 
Please find below a new version (v2) of the framework summary reflecti=
ng the latest discussions. Again i hope i've captured all the comments arou=
nd, sorry if anything is missing, in case just let me know what i missed.
 
BR
Daniele
 
 
+ Disclaimer:
 1. Packet opto integration is often considered but the work can be ex=
tented to any type of SC. Eg. TDM over LSC.
 
+ Terminology:
 1. Virtual Link: A virtual link is a potential path between two virtu=
al or real network  elements in a provider layer network  that is=
 maintained/controlled in and by the provider  domain control plane (a=
nd as such cannot transport any traffic/data and protected from being<=
/o:p>
 de-provisioned) and which can be instantiated in the data plane (and =
then can  carry/transport/forward traffic/data) preserving previously =
advertised attributes such as  fate sharing information.

 2.  Virtual Node: Virtual node is a collection of zero or more p=
rovider network domain  nodes that are collectively represented to the=
 clients as a single node that  exists in the customer layer network a=
nd is capable of terminating of access,  inter-domain and virtual link=
s.


 3. Virtual Topology: Virtual topology is a collection of one or more =
virtual or real provider  network domain nodes that exist in the custo=
mer layer network and are interconnected  via 0 or more virtual links.=



 4. Overlay topology:  is a superset of virtual topologies provid=
ed by each of  provider network domains, access and inter-domain links=
.


 5. Access Link: Link between OC and OE. GMPLS runs on that link. It c=
an support  any of the SCs supported by the GMPLS.


 6. CE (customer Edge): Something like the CN in RFC4208 teminology&nb=
sp; but (i) receiving  virtual topology from the provider network and =
requesting the set up of one of them or


 (ii) requesting the computation and establishment of a path according=
ly to given constraints  in the provider network and receiving the par=
ameters characterizing such path. (ii) =3D=3D UNI.


 7. PE (provider Edge): Something like the EN in RFC4208 but able to d=
eal with (i) and (ii) above.


 8. PE-CE interface (former ONI) : Interface allowing for signaling an=
d routing messages  exchange between customer overlay and provider net=
work. Routing information consists on  virtual topology advertisement.=
 When there is no routing adjacency across the interface  it is equiva=
lent to the GMPLS UNI defined in 4208. Signaling messages are compliant wit=
h  RFC4208. Information related to path carachteristics, e.g. TE-metri=
cs, collected SRLG,  path delay etc, either passed from CE to PE via s=
ignaling after the LSP establishment  in the core network or from CE t=
o PE to be used as path computation constraints, fall  under the defin=
ition of signaling info and not routing info).


 9. CE-CE (former O-NNI): Interface on the links between different pro=
vider networks  in the overlay model environment. Same features of the=
 CE-PE apply to this interface. 


 


+ Statements


 1. In the context of overlay model we are aiming to build an overlay =
topology for  the customer network domains  2. The overlay topolo=
gy is comprised of:


    a) access links (links connecting client NEs to the=
 provider network domains).


 They can be PSC or LSC.


    b) inter-domain links (links interconnecting server=
 network domains)


    c) virtual topology provided by the provider networ=
k domains. Virtual Links  + Virtual Nodes (TBD) + Connectivity=
 Matrix (with a set of parameters e.g. SRLG,  optical impairments, del=
ay etc for each entry) describing connectivity between access links and vir=
tual links.


 3. In the context of overlay model we manage  hierarchy  of=
 overlay topologies  with overlay/underlay relationships  4. In t=
he context of overlay model multi-layering and inter-layer relationships


 are peripheral at best, it is all about horizontal network integratio=
n   


 5. The overlay model assumes one CP instance for the customer ne=
twork and a separate  instance for the provider network and in the CE-=
PE interface case the provider  network also surreptitiously participa=
tes in the customer network by injecting  virtual topology information=
 into it.


 6. L1VPN (and LxVPN) in general is a type of service provided over th=
e CE-PE interface  (it falls under the UNI case as no routing adjacenc=
y is in place between CE and PE).


 


 


+ Advertisement models (to be detailed in dedicated document/docum=
ents)


 The CE-PE interface in the overlay model context foresees two types o=
f advertisement  models.(names still to be agreed) A. Augmented UNI: T=
he GMPLS UNI is defined in RFC4208 and augmented by  a number of activ=
ed draft (references to various drafts to be added).


 The Augmented UNI is a particular type of CE-PE interface where only =
signaling messages  are exchanged between CE and PE. Messages from CE =
to PE can include  a set of parameters to be used by the PE as path co=
mputation constraints  when computing a path in the provider domain ne=
twork, while messages from PE  to CE can include a set of parameters q=
ualifying the LSP being established,  like for example SRLG, delay, lo=
ss etc.


B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply calle=
d with the  general CE-PE interface term?) allowing the establishment =
of signaling and routing adjacency  between CE and PE. Routing info pa=
ssed from PE to CE comprise overlay topology information including  (b=
ut not limited to) virtual links, connectivity matrices and access links wi=
th parameters qualifying  each of them in terms of e.g. SRLG, loss, de=
lay etc. Signaling information and procedures are  compliant with RFC4=
208.


 


+ Open issues/questions


 1. PCE-PCEP - do we need to include considerations about PCE and PCEP=
 into the overlay framework context?


 2. BGP-LS needs to be considered


 3. Should potentials be included? E.g. I2RS?


 4. Virtual links: wouldn't a different definition of virtual links av=
oid the advertisement of connectivity matrices (this is out of the fwk scop=
e but within the advertisement models one)?


Take this example:


PE1-----CE1          =
;     CE2-----PE2


        CE1=3D=3D=3D=3D=3D=3DVL1=3D=
=3D=3D=3D=3D=3DCE2


        CE1=3D=3D=3D=3D=3D=3DVL2=3D=
=3D=3D=3D=3D=3DCE2


i.e. There are 2 VL connecting CE1 and CE2 that could be available for=
 PE1 and PE2 to set up an adjacency in the customer domain. CE1 and/or CE2 =
can be blocking nodes so VL1 and/or VL2 are available only depending on the=
 connectivity matrices of CE1 and CE2. Hence PEs need to be aware of both V=
L and connectivity matrices. My point is: if CE1 advertises to PE1 only the=
 VL that his connectivity matrix allows to be connected to PE1 (e.g. VL1 on=
ly) and not all of them, it should be possible to avoid the connectivity ma=
trices advertisement. 


 


 


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


DANIELE CECCARELLI


System & Technology - PDU Optical & Metro 


 


Via E.Melen, 77


Genova, Italy


Phone +390106002512


Mobile +393346725750


daniele.ceccarelli@=
ericsson.com


www.ericsson.com  


 


This Communication is Confidential. We only send and receive email on =
the basis of the term set out at www.ericsson.com/email_disclaimer  


 


_______________________________________________


CCAMP mailing list


CCAMP@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ccamp


_______________________________________________


CCAMP mailing list


CCAMP@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ccamp


 




-- 






DIETER BELLER







ALCATEL-LUCENT DEUTSCHLAND=
 AG


PROJECT MANAGER ASON/GMPLS CONTROL PLANE 

CORE NETWORKS BUSINESS DIVISION 

OPTICS BU, SWITCHING R&D 



Lorenzstrasse 10 

70435 Stuttgart, Germany 

Phone: +49 711 821 43125 

Mobil: +49 175 7266874 





 




Alcatel-Lucent Deutschland AG


Domicile of the Company: Stuttgart =B7 Local Court Stuttgart HRB 4026 

Chairman of the Supervisory Board: Michael Oppenhoff 

Board of Management: Wilhelm Dresselhaus (Chairman) =B7 Hans-J=F6rg Daub =
=B7 Dr. Rainer Fechner =B7 Andreas Gehe




This e-mail and its attachments, if any, may contain confidential informati=
on.

If you have received this e-mail in error, please notify us and delete or d=
estroy the e-mail and its attachments, if any, immediately.


If you have received this e-mail in error, you must not forward or make use=
 of the e-mail and its attachments, if any.
--_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A19106FE0atlsrvmail10atl_-- --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A19106FE0atlsrvmail10atl_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=5715; creation-date="Wed, 16 Jan 2013 22:55:19 GMT"; modification-date="Wed, 16 Jan 2013 22:55:19 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAGAgMBAAAAAAAAAAAA AAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoLEAACAQMEAQMDAgMDAwIG CXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOhsfAmNHIKGcHRNSfhUzaC8ZKi RFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5OkhJSlhZWmdoaWp2d3h5eoWGh4iJ ipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX2Nna5OXm5+jp6vT19vf4+foRAAIBAwIE BAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRxCEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMY Y0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4 doaWprbG1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq +v/aAAwDAQACEQMRAD8A3+Pfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691 737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvn sm0T1ExVp4aKgx+PpIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBV RQWdjhVBPl09bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnD snYeNhlSt353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs 6eNOxxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ7Acj e43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BINKHjT7QSP l1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3PH4/Pq/b0eT0 e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT51rSnRWch3x82aXq D5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7jxFdV1j4TJaq6J6L7a/l kQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1+i9/YvC0VVt7r6j2f9umY7C/ jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4KYys7u617g3DtL45dIN8iev44/kN1 HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWpjPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN 0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72iyUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfP qn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0dL3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkF WRjEDeM1aInut0WtK46Hyr7F+REPyX2R1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvW b0i7jz1LWYYx1K5iFkpWMrKQhgZZPdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh 1/HTdgdV0u+MRhIO0YOz5aBNt4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0H FV/Gyr6SrN75T5Mnsfb0E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/I n5+r8YMp2ZT/AAAoJPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6P fut0WtK4+zoxq9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNE SRCCZCQvutUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9pp iTtrKyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y8h8B 8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm1HVSyx+/ dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr5+uzTrn9ttja eJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b310AfkPsCeDoPqKv3 bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaHyVl787t2HP8AGeli6R2R 1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoWYI8c6BPdaoKcc9BLi++PnVU9 IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq0W8o6WTC9mVWJ29j8dkP4JjmWtL5 E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11tfcXx07THcm1UqPkPv7J7Xq8luHYNbtE0 L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q95/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2 M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Tiz91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx 8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZnObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8A Y6S1D3l8yKjY/wAOs3UfC+Cm3h3HurA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0z OT4L+V1ce63Rc5+zrXk/m+/NPFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27 fkrt/dO69n7RzOydsQYf4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQv eG1+kG+YX8475J7RHyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWq qJI09+69QUqRWi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou 3N0bl7bh7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP /n3fIf4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D2f1j uzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1qiUOe2or5 06MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7oxc9PgMzNkcNHF kIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi06hgjpyeOGOR0t38S EEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2fUz/7L/2dlPieazAU9AaO T+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z9H8DvlB/M/h762NkqPau5e3u v9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7cFNU1VJjK2i/ap6emp5EqT7reldQT +fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F/HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM /tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+ SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cuLyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7 /hQ7W75qfjn8beq9vy1mal7A7yo6KvpKKlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+ 8sfulw7fFzVu283xVTabWSHbgiNIpkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt74 2fyrYqvMb7+RvyK33s7fPy0oNgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHk q9o6Srnp8od3vMvNvOF3vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXb S7xhbWJSI9Qr8u0cKk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5 Jtr9LVf9/cbi8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WV oZGuKSXY8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv /u5/EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r3Xvf uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69 1737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7AhlpnTdC5HaVFFj pVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w8FNt+u3vjtqYfY2O 3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjNz7Oqcl8PuhpZthbewm09 sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63rb1PSw3N8BfhPvPcvbe8N2fF force5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3FUlcKtl+7NZSQTmQywxuvuvam9Tj pWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2 MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7ifx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/ AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSx HX2Dx22tgxYlkpBTRVmx9vYejosPVtG1XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+ 3Oz9uZ/aXY2+JuvduT5TfO392U70m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnT L13/AC+vhL1NjosR1z8Yen9p4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4 o8aaiT7dYw7X91ssx4npT9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ3 3Xzz0xqTuyh2hQxYpK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7L VQlpsPg947Zo6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBco tNTQuQSVBoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ 2D2xHndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3 b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U49O+ U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN25jcvXfa 4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMiapnXUqqFLJEr N1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h/wANi+4/0ufxn++n 9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sNWPpdHg+Bq4avB/Hpp4v6 mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697917r3v3Xuve/de697917r3v3 Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6 97917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3XugA+RP/AB59D/zI D/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9 J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8AN3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/a n4/9v8X59C17IumOv//Z --_004_CDAC6F6F5401B245A2C68D0CF8AFDF0A19106FE0atlsrvmail10atl_-- From IBryskin@advaoptical.com Wed Jan 16 15:04:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6FB11E80A6 for ; Wed, 16 Jan 2013 15:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 C0nU1yzAqZ2d for ; Wed, 16 Jan 2013 15:04:22 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDB111E80DC for ; Wed, 16 Jan 2013 15:04:21 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0GN4J5t011635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 00:04:19 +0100 Received: from MUC-SRV-MBX2.advaoptical.com (172.20.1.96) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 17 Jan 2013 00:04:19 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 17 Jan 2013 00:04:19 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0099.000; Wed, 16 Jan 2013 18:04:17 -0500 From: Igor Bryskin To: Snigdho Bardalai , Daniele Ceccarelli , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAOJ5ugAAF4jxA= Date: Wed, 16 Jan 2013 23:04:16 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> In-Reply-To: <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-16_09:2013-01-16, 2013-01-16, 1970-01-01 signatures=0 Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 23:04:23 -0000 Snigdho, > 3. Virtual Topology: Virtual topology is a collection of one or more=20 > virtual or real provider network domain nodes that exist in the=20 > customer layer network and are interconnected via 0 or more virtual=20 > links. [SCB] Since the topology advertised by the provider network can contain rea= l or virtual elements, why do we call it "virtual topology"? Should it simp= ly be called "provider topology"? And then specify that it may contain both= virtual or real elements. Virtual topology includes only virtual nodes. Even when we are considering = real PEs terminating VLs, we must treat the PEs in the context of Virtual T= opology as VNs since they must be named from the client naming space. Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of S= nigdho Bardalai Sent: Wednesday, January 16, 2013 5:48 PM To: Daniele Ceccarelli; CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Hi Daniele, A few comments. Please see in-line. Thanks Snigdho > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=20 > Of Daniele Ceccarelli > Sent: Wednesday, January 16, 2013 7:33 AM > To: CCAMP > Subject: [CCAMP] Overlay model framework v2 >=20 > Dear overlayers, >=20 > Please find below a new version (v2) of the framework summary=20 > reflecting the latest discussions. Again i hope i've captured all the=20 > comments around, sorry if anything is missing, in case just let me=20 > know what i missed. >=20 > BR > Daniele >=20 >=20 > + Disclaimer: > 1. Packet opto integration is often considered but the work can be=20 > extented to any type of SC. Eg. TDM over LSC. >=20 > + Terminology: > 1. Virtual Link: A virtual link is a potential path between two=20 > virtual or real network elements in a provider layer network that is=20 > maintained/controlled in and by the provider domain control plane=20 > (and as such cannot transport any traffic/data and protected from=20 > being > de-provisioned) and which can be instantiated in the data plane (and=20 > then can carry/transport/forward traffic/data) preserving previously=20 > advertised attributes such as fate sharing information. > 2. Virtual Node: Virtual node is a collection of zero or more=20 > provider network domain nodes that are collectively represented to=20 > the clients as a single node that exists in the customer layer=20 > network and is capable of terminating of access, inter-domain and virtua= l links. [SCB] Agree with Igor's comment - a virtual node can be a combination of mu= ltiple nodes or a part of the single node, but to the customer node this is= transparent. > 3. Virtual Topology: Virtual topology is a collection of one or more=20 > virtual or real provider network domain nodes that exist in the=20 > customer layer network and are interconnected via 0 or more virtual=20 > links. [SCB] Since the topology advertised by the provider network can contain rea= l or virtual elements, why do we call it "virtual topology"? Should it simp= ly be called "provider topology"? And then specify that it may contain both= virtual or real elements. > 4. Overlay topology: is a superset of virtual topologies provided by=20 > each of provider network domains, access and inter-domain links. [SCB] A more concise definition for the overlay topology is - CE nodes + Ac= cess-links + provider topology as advertised by the provider network. > 5. Access Link: Link between OC and OE. GMPLS runs on that link. It=20 > can support any of the SCs supported by the GMPLS. > 6. CE (customer Edge): Something like the CN in RFC4208 teminology=20 > but (i) receiving virtual topology from the provider network and=20 > requesting the set up of one of them or > (ii) requesting the computation and establishment of a path=20 > accordingly to given constraints in the provider network and=20 > receiving the parameters characterizing such path. (ii) =3D=3D UNI. > 7. PE (provider Edge): Something like the EN in RFC4208 but able to=20 > deal with (i) and (ii) above. > 8. PE-CE interface (former ONI) : Interface allowing for signaling=20 > and routing messages exchange between customer overlay and provider=20 > network. Routing information consists on virtual topology=20 > advertisement. When there is no routing adjacency across the interface=20 > it is equivalent to the GMPLS UNI defined in 4208. Signaling messages=20 > are compliant with RFC4208. Information related to path=20 > carachteristics, e.g. TE-metrics, collected SRLG, path delay etc,=20 > either passed from CE to PE via signaling after the LSP establishment=20 > in the core network or from CE to PE to be used as path computation=20 > constraints, fall under the definition of signaling info and not=20 > routing info). > 9. CE-CE (former O-NNI): Interface on the links between different=20 > provider networks in the overlay model environment. Same features of=20 > the CE-PE apply to this interface. [SCB] Is this "PE-PE" instead of "CE-CE"?=20 >=20 > + Statements > 1. In the context of overlay model we are aiming to build an overlay=20 > topology for the customer network domains 2. The overlay topology is=20 > comprised of: > a) access links (links connecting client NEs to the provider=20 > network domains). > They can be PSC or LSC. > b) inter-domain links (links interconnecting server network > domains) > c) virtual topology provided by the provider network domains. > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a set=20 > of parameters e.g. SRLG, optical impairments, delay etc for each > entry) describing connectivity between access links and virtual links. > 3. In the context of overlay model we manage hierarchy of overlay=20 > topologies with overlay/underlay relationships 4. In the context of=20 > overlay model multi-layering and inter-layer relationships are=20 > peripheral at best, it is all about horizontal network integration 5.=20 > The overlay model assumes one CP instance for the customer network and=20 > a separate instance for the provider network and in the CE-PE=20 > interface case the provider network also surreptitiously participates=20 > in the customer network by injecting virtual topology information=20 > into it. [SCB] Specific implementations may or may not have a single instance for th= e provider and the overlay. > 6. L1VPN (and LxVPN) in general is a type of service provided over=20 > the CE-PE interface (it falls under the UNI case as no routing=20 > adjacency is in place between CE and PE). >=20 >=20 > + Advertisement models (to be detailed in dedicated=20 > + document/documents) > The CE-PE interface in the overlay model context foresees two types=20 > of advertisement models.(names still to be agreed) A. Augmented UNI:=20 > The GMPLS UNI is defined in RFC4208 and augmented by a number of=20 > actived draft (references to various drafts to be added). > The Augmented UNI is a particular type of CE-PE interface where only=20 > signaling messages are exchanged between CE and PE. Messages from CE=20 > to PE can include a set of parameters to be used by the PE as path=20 > computation constraints when computing a path in the provider domain=20 > network, while messages from PE to CE can include a set of parameters=20 > qualifying the LSP being established, like for example SRLG, delay,=20 > loss etc. > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 > called with the general CE-PE interface term?) allowing the=20 > establishment of signaling and routing adjacency between CE and PE.=20 > Routing info passed from PE to CE comprise overlay topology=20 > information including (but not limited to) virtual links,=20 > connectivity matrices and access links with parameters qualifying =20 > each of them in terms of e.g. SRLG, loss, delay etc. Signaling informatio= n and procedures are compliant with RFC4208. >=20 > + Open issues/questions > 1. PCE-PCEP - do we need to include considerations about PCE and PCEP=20 > into the overlay framework context? [SCB] IMO - this should be described in the overlay framework document to e= stablish the context. > 2. BGP-LS needs to be considered > 3. Should potentials be included? E.g. I2RS? > 4. Virtual links: wouldn't a different definition of virtual links=20 > avoid the advertisement of connectivity matrices (this is out of the=20 > fwk scope but within the advertisement models one)? > Take this example: > PE1-----CE1 CE2-----PE2 > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 > i.e. There are 2 VL connecting CE1 and CE2 that could be available for > PE1 and PE2 to set up an adjacency in the customer domain. CE1 and/or > CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 > depending on the connectivity matrices of CE1 and CE2. Hence PEs need=20 > to be aware of both VL and connectivity matrices. My point is: if CE1=20 > advertises to PE1 only the VL that his connectivity matrix allows to=20 > be connected to PE1 (e.g. VL1 only) and not all of them, it should be=20 > possible to avoid the connectivity matrices advertisement. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > DANIELE CECCARELLI > System & Technology - PDU Optical & Metro >=20 > Via E.Melen, 77 > Genova, Italy > Phone +390106002512 > Mobile +393346725750 > daniele.ceccarelli@ericsson.com > www.ericsson.com >=20 > This Communication is Confidential. We only send and receive email on=20 > the basis of the term set out at www.ericsson.com/email_disclaimer >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From SBardalai@infinera.com Wed Jan 16 20:28:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCEF21F8619 for ; Wed, 16 Jan 2013 20:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 ApyAkPiQd-KW for ; Wed, 16 Jan 2013 20:28:15 -0800 (PST) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id DFAAD21F8615 for ; Wed, 16 Jan 2013 20:28:15 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 20:28:14 -0800 From: Snigdho Bardalai To: Igor Bryskin , Daniele Ceccarelli , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAOJ5ugAAF4jxAAC1ZqcA== Date: Thu, 17 Jan 2013 04:28:13 +0000 Message-ID: <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 04:28:17 -0000 Hi Igor, Not sure if the case you are citing qualifies a real node or link to be cal= led virtual. The client space name is simply an alias. Regards Snigdho > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Wednesday, January 16, 2013 3:04 PM > To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP > Subject: RE: Overlay model framework v2 >=20 > Snigdho, >=20 > > 3. Virtual Topology: Virtual topology is a collection of one or more > > virtual or real provider network domain nodes that exist in the > > customer layer network and are interconnected via 0 or more virtual > > links. >=20 > [SCB] Since the topology advertised by the provider network can contain > real or virtual elements, why do we call it "virtual topology"? Should > it simply be called "provider topology"? And then specify that it may > contain both virtual or real elements. >=20 > Virtual topology includes only virtual nodes. Even when we are > considering real PEs terminating VLs, we must treat the PEs in the > context of Virtual Topology as VNs since they must be named from the > client naming space. >=20 > Igor >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Snigdho Bardalai > Sent: Wednesday, January 16, 2013 5:48 PM > To: Daniele Ceccarelli; CCAMP > Subject: Re: [CCAMP] Overlay model framework v2 >=20 > Hi Daniele, >=20 > A few comments. Please see in-line. >=20 > Thanks > Snigdho >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Daniele Ceccarelli > > Sent: Wednesday, January 16, 2013 7:33 AM > > To: CCAMP > > Subject: [CCAMP] Overlay model framework v2 > > > > Dear overlayers, > > > > Please find below a new version (v2) of the framework summary > > reflecting the latest discussions. Again i hope i've captured all the > > comments around, sorry if anything is missing, in case just let me > > know what i missed. > > > > BR > > Daniele > > > > > > + Disclaimer: > > 1. Packet opto integration is often considered but the work can be > > extented to any type of SC. Eg. TDM over LSC. > > > > + Terminology: > > 1. Virtual Link: A virtual link is a potential path between two > > virtual or real network elements in a provider layer network that > is > > maintained/controlled in and by the provider domain control plane > > (and as such cannot transport any traffic/data and protected from > > being > > de-provisioned) and which can be instantiated in the data plane (and > > then can carry/transport/forward traffic/data) preserving previously > > advertised attributes such as fate sharing information. > > 2. Virtual Node: Virtual node is a collection of zero or more > > provider network domain nodes that are collectively represented to > > the clients as a single node that exists in the customer layer > > network and is capable of terminating of access, inter-domain and > virtual links. >=20 > [SCB] Agree with Igor's comment - a virtual node can be a combination > of multiple nodes or a part of the single node, but to the customer > node this is transparent. >=20 > > 3. Virtual Topology: Virtual topology is a collection of one or more > > virtual or real provider network domain nodes that exist in the > > customer layer network and are interconnected via 0 or more virtual > > links. >=20 > [SCB] Since the topology advertised by the provider network can contain > real or virtual elements, why do we call it "virtual topology"? Should > it simply be called "provider topology"? And then specify that it may > contain both virtual or real elements. >=20 > > 4. Overlay topology: is a superset of virtual topologies provided > by > > each of provider network domains, access and inter-domain links. >=20 > [SCB] A more concise definition for the overlay topology is - CE nodes > + Access-links + provider topology as advertised by the provider > network. >=20 > > 5. Access Link: Link between OC and OE. GMPLS runs on that link. It > > can support any of the SCs supported by the GMPLS. > > 6. CE (customer Edge): Something like the CN in RFC4208 teminology > > but (i) receiving virtual topology from the provider network and > > requesting the set up of one of them or > > (ii) requesting the computation and establishment of a path > > accordingly to given constraints in the provider network and > > receiving the parameters characterizing such path. (ii) =3D=3D UNI. > > 7. PE (provider Edge): Something like the EN in RFC4208 but able to > > deal with (i) and (ii) above. > > 8. PE-CE interface (former ONI) : Interface allowing for signaling > > and routing messages exchange between customer overlay and provider > > network. Routing information consists on virtual topology > > advertisement. When there is no routing adjacency across the > interface > > it is equivalent to the GMPLS UNI defined in 4208. Signaling messages > > are compliant with RFC4208. Information related to path > > carachteristics, e.g. TE-metrics, collected SRLG, path delay etc, > > either passed from CE to PE via signaling after the LSP establishment > > in the core network or from CE to PE to be used as path computation > > constraints, fall under the definition of signaling info and not > > routing info). > > 9. CE-CE (former O-NNI): Interface on the links between different > > provider networks in the overlay model environment. Same features of > > the CE-PE apply to this interface. >=20 > [SCB] Is this "PE-PE" instead of "CE-CE"? >=20 > > > > + Statements > > 1. In the context of overlay model we are aiming to build an overlay > > topology for the customer network domains 2. The overlay topology > is > > comprised of: > > a) access links (links connecting client NEs to the provider > > network domains). > > They can be PSC or LSC. > > b) inter-domain links (links interconnecting server network > > domains) > > c) virtual topology provided by the provider network domains. > > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a > set > > of parameters e.g. SRLG, optical impairments, delay etc for each > > entry) describing connectivity between access links and virtual > links. > > 3. In the context of overlay model we manage hierarchy of overlay > > topologies with overlay/underlay relationships 4. In the context of > > overlay model multi-layering and inter-layer relationships are > > peripheral at best, it is all about horizontal network integration > 5. > > The overlay model assumes one CP instance for the customer network > and > > a separate instance for the provider network and in the CE-PE > > interface case the provider network also surreptitiously > participates > > in the customer network by injecting virtual topology information > > into it. >=20 > [SCB] Specific implementations may or may not have a single instance > for the provider and the overlay. >=20 > > 6. L1VPN (and LxVPN) in general is a type of service provided over > > the CE-PE interface (it falls under the UNI case as no routing > > adjacency is in place between CE and PE). >=20 > > > > > > + Advertisement models (to be detailed in dedicated > > + document/documents) > > The CE-PE interface in the overlay model context foresees two types > > of advertisement models.(names still to be agreed) A. Augmented UNI: > > The GMPLS UNI is defined in RFC4208 and augmented by a number of > > actived draft (references to various drafts to be added). > > The Augmented UNI is a particular type of CE-PE interface where only > > signaling messages are exchanged between CE and PE. Messages from CE > > to PE can include a set of parameters to be used by the PE as path > > computation constraints when computing a path in the provider domain > > network, while messages from PE to CE can include a set of > parameters > > qualifying the LSP being established, like for example SRLG, delay, > > loss etc. > > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply > > called with the general CE-PE interface term?) allowing the > > establishment of signaling and routing adjacency between CE and PE. > > Routing info passed from PE to CE comprise overlay topology > > information including (but not limited to) virtual links, > > connectivity matrices and access links with parameters qualifying > each > > of them in terms of e.g. SRLG, loss, delay etc. Signaling information > and procedures are compliant with RFC4208. > > > > + Open issues/questions > > 1. PCE-PCEP - do we need to include considerations about PCE and > PCEP > > into the overlay framework context? >=20 > [SCB] IMO - this should be described in the overlay framework document > to establish the context. >=20 > > 2. BGP-LS needs to be considered > > 3. Should potentials be included? E.g. I2RS? > > 4. Virtual links: wouldn't a different definition of virtual links > > avoid the advertisement of connectivity matrices (this is out of the > > fwk scope but within the advertisement models one)? > > Take this example: > > PE1-----CE1 CE2-----PE2 > > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 > > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 > > i.e. There are 2 VL connecting CE1 and CE2 that could be available > for > > PE1 and PE2 to set up an adjacency in the customer domain. CE1 and/or > > CE2 can be blocking nodes so VL1 and/or VL2 are available only > > depending on the connectivity matrices of CE1 and CE2. Hence PEs need > > to be aware of both VL and connectivity matrices. My point is: if CE1 > > advertises to PE1 only the VL that his connectivity matrix allows to > > be connected to PE1 (e.g. VL1 only) and not all of them, it should be > > possible to avoid the connectivity matrices advertisement. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > DANIELE CECCARELLI > > System & Technology - PDU Optical & Metro > > > > Via E.Melen, 77 > > Genova, Italy > > Phone +390106002512 > > Mobile +393346725750 > > daniele.ceccarelli@ericsson.com > > www.ericsson.com > > > > This Communication is Confidential. We only send and receive email on > > the basis of the term set out at www.ericsson.com/email_disclaimer > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Thu Jan 17 06:38:39 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CE321F8623 for ; Thu, 17 Jan 2013 06:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.239 X-Spam-Level: X-Spam-Status: No, score=-5.239 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, 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 0E9GPZcppHTW for ; Thu, 17 Jan 2013 06:38:38 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07EFA21F8650 for ; Thu, 17 Jan 2013 06:38:37 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-95-50f80cec9d01 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 94.F4.10459.CEC08F05; Thu, 17 Jan 2013 15:38:37 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 15:38:36 +0100 From: Daniele Ceccarelli To: Igor Bryskin , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRwFLO6lqWmk6S/LNDTw8InAACrBmAAC2yo4A= Date: Thu, 17 Jan 2013 14:38:36 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806CAD1@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje5bnh8BBndvMlo8mXODxeJUTzuj A5PH2QV/WD2WLPnJFMAUxWWTkpqTWZZapG+XwJXxcuId1oJm54pnd+YwNjBONe9i5OSQEDCR 2LxiPhuELSZx4d56IJuLQ0jgEKPE9u3LGCGcxYwS7U+esXQxcnCwCVhJPDnkA9IgIuAs8fLF A3aQsLCAusSD6+oQYQ2J24f72SFsK4llW26BzWcRUJW4euAPC4jNK+At8XjqKajxsxklZp+/ A9bAKRAlsf/7W7AiRgFZiQm7FzGC2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1ghbEWJj6/2 QdXrSdyYOoUNwtaWWLbwNTPEYkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSN7bmJmTnq5 4SZGYCwc3PJbdwfjqXMihxilOViUxHnDXC8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAU nSyrunZj/8yTe3YKPv+WdDklfEqHxObCllWMEe0cc677zPJkuR7J/vBoe2bJfecPymuDF6wP bX22x7t5yVzNbYrCkypeJfIcfbb6qo4Me7mA8sobK9PDwoVn/buUtW7fTPdo9b0rQiIOMPLV iOjeP/Rj7zVBm5p228W1xROYbdOm5B31+fVRiaU4I9FQi7moOBEA7hIadlMCAAA= Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 14:38:39 -0000 Ok, sounds good. BR Daniele=20 >-----Original Message----- >From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 >Sent: mercoled=EC 16 gennaio 2013 18.50 >To: Daniele Ceccarelli; CCAMP >Subject: RE: Overlay model framework v2 > >Daniel, >One correction: >VN may represent a fraction of a real node. This makes=20 >possible for the network to advertise a blocking PE as a set=20 >of non-blocking PE and thus alleviate the client path computer=20 >from dealing with blocking PEs. > >Igor > >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf Of Daniele Ceccarelli >Sent: Wednesday, January 16, 2013 10:33 AM >To: CCAMP >Subject: [CCAMP] Overlay model framework v2 > >Dear overlayers, > >Please find below a new version (v2) of the framework summary=20 >reflecting the latest discussions. Again i hope i've captured=20 >all the comments around, sorry if anything is missing, in case=20 >just let me know what i missed. > >BR >Daniele > > >+ Disclaimer: > 1. Packet opto integration is often considered but the work=20 >can be extented to any type of SC. Eg. TDM over LSC. > >+ Terminology: > 1. Virtual Link: A virtual link is a potential path between=20 >two virtual or real network elements in a provider layer=20 >network that is maintained/controlled in and by the provider =20 >domain control plane (and as such cannot transport any=20 >traffic/data and protected from being > de-provisioned) and which can be instantiated in the data=20 >plane (and then can carry/transport/forward traffic/data)=20 >preserving previously advertised attributes such as fate=20 >sharing information. > 2. Virtual Node: Virtual node is a collection of zero or=20 >more provider network domain nodes that are collectively=20 >represented to the clients as a single node that exists in=20 >the customer layer network and is capable of terminating of=20 >access, inter-domain and virtual links. > 3. Virtual Topology: Virtual topology is a collection of one=20 >or more virtual or real provider network domain nodes that=20 >exist in the customer layer network and are interconnected =20 >via 0 or more virtual links. > 4. Overlay topology: is a superset of virtual topologies=20 >provided by each of provider network domains, access and=20 >inter-domain links. > 5. Access Link: Link between OC and OE. GMPLS runs on that=20 >link. It can support any of the SCs supported by the GMPLS. > 6. CE (customer Edge): Something like the CN in RFC4208=20 >teminology but (i) receiving virtual topology from the=20 >provider network and requesting the set up of one of them or > (ii) requesting the computation and establishment of a path=20 >accordingly to given constraints in the provider network and=20 >receiving the parameters characterizing such path. (ii) =3D=3D UNI. > 7. PE (provider Edge): Something like the EN in RFC4208 but=20 >able to deal with (i) and (ii) above. > 8. PE-CE interface (former ONI) : Interface allowing for=20 >signaling and routing messages exchange between customer=20 >overlay and provider network. Routing information consists on =20 >virtual topology advertisement. When there is no routing=20 >adjacency across the interface it is equivalent to the GMPLS=20 >UNI defined in 4208. Signaling messages are compliant with =20 >RFC4208. Information related to path carachteristics, e.g.=20 >TE-metrics, collected SRLG, path delay etc, either passed=20 >from CE to PE via signaling after the LSP establishment in=20 >the core network or from CE to PE to be used as path=20 >computation constraints, fall under the definition of=20 >signaling info and not routing info). > 9. CE-CE (former O-NNI): Interface on the links between=20 >different provider networks in the overlay model environment.=20 >Same features of the CE-PE apply to this interface.=20 > >+ Statements > 1. In the context of overlay model we are aiming to build an=20 >overlay topology for the customer network domains 2. The=20 >overlay topology is comprised of: > a) access links (links connecting client NEs to the=20 >provider network domains). > They can be PSC or LSC. > b) inter-domain links (links interconnecting server=20 >network domains) > c) virtual topology provided by the provider network=20 >domains. Virtual Links + Virtual Nodes (TBD) + Connectivity=20 >Matrix (with a set of parameters e.g. SRLG, optical=20 >impairments, delay etc for each entry) describing connectivity=20 >between access links and virtual links. > 3. In the context of overlay model we manage hierarchy of=20 >overlay topologies with overlay/underlay relationships 4. In=20 >the context of overlay model multi-layering and inter-layer=20 >relationships > are peripheral at best, it is all about horizontal network=20 >integration =20 > 5. The overlay model assumes one CP instance for the customer=20 >network and a separate instance for the provider network and=20 >in the CE-PE interface case the provider network also=20 >surreptitiously participates in the customer network by=20 >injecting virtual topology information into it. > 6. L1VPN (and LxVPN) in general is a type of service provided=20 >over the CE-PE interface (it falls under the UNI case as no=20 >routing adjacency is in place between CE and PE). > > >+ Advertisement models (to be detailed in dedicated document/documents) > The CE-PE interface in the overlay model context foresees two=20 >types of advertisement models.(names still to be agreed) A.=20 >Augmented UNI: The GMPLS UNI is defined in RFC4208 and=20 >augmented by a number of actived draft (references to various=20 >drafts to be added). > The Augmented UNI is a particular type of CE-PE interface=20 >where only signaling messages are exchanged between CE and=20 >PE. Messages from CE to PE can include a set of parameters to=20 >be used by the PE as path computation constraints when=20 >computing a path in the provider domain network, while=20 >messages from PE to CE can include a set of parameters=20 >qualifying the LSP being established, like for example SRLG,=20 >delay, loss etc. >B. ONI: The GMPLS ONI is a CE-PE interface (this could be=20 >simply called with the general CE-PE interface term?)=20 >allowing the establishment of signaling and routing adjacency =20 >between CE and PE. Routing info passed from PE to CE comprise=20 >overlay topology information including (but not limited to)=20 >virtual links, connectivity matrices and access links with=20 >parameters qualifying each of them in terms of e.g. SRLG,=20 >loss, delay etc. Signaling information and procedures are =20 >compliant with RFC4208. > >+ Open issues/questions > 1. PCE-PCEP - do we need to include considerations about PCE=20 >and PCEP into the overlay framework context? > 2. BGP-LS needs to be considered > 3. Should potentials be included? E.g. I2RS? > 4. Virtual links: wouldn't a different definition of virtual=20 >links avoid the advertisement of connectivity matrices (this=20 >is out of the fwk scope but within the advertisement models one)? >Take this example: >PE1-----CE1 CE2-----PE2 > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >i.e. There are 2 VL connecting CE1 and CE2 that could be=20 >available for PE1 and PE2 to set up an adjacency in the=20 >customer domain. CE1 and/or CE2 can be blocking nodes so VL1=20 >and/or VL2 are available only depending on the connectivity=20 >matrices of CE1 and CE2. Hence PEs need to be aware of both VL=20 >and connectivity matrices. My point is: if CE1 advertises to=20 >PE1 only the VL that his connectivity matrix allows to be=20 >connected to PE1 (e.g. VL1 only) and not all of them, it=20 >should be possible to avoid the connectivity matrices advertisement.=20 > >=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >DANIELE CECCARELLI >System & Technology - PDU Optical & Metro=20 > >Via E.Melen, 77 >Genova, Italy >Phone +390106002512 >Mobile +393346725750 >daniele.ceccarelli@ericsson.com >www.ericsson.com =20 > >This Communication is Confidential. We only send and receive=20 >email on the basis of the term set out at=20 >www.ericsson.com/email_disclaimer =20 > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >= From daniele.ceccarelli@ericsson.com Thu Jan 17 06:52:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A34821F84DA for ; Thu, 17 Jan 2013 06:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.29 X-Spam-Level: X-Spam-Status: No, score=-5.29 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, 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 QlW3R8f+wYe1 for ; Thu, 17 Jan 2013 06:52:42 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 93B5F21F8464 for ; Thu, 17 Jan 2013 06:52:41 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-9d-50f81038ffb1 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DF.1B.32353.83018F05; Thu, 17 Jan 2013 15:52:40 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 15:52:40 +0100 From: Daniele Ceccarelli To: Snigdho Bardalai , Igor Bryskin , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRwFLO6lqWmk6S/LNDTw8InAANE4iAAACVKQAAC1BWgAAXfYXg Date: Thu, 17 Jan 2013 14:52:39 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> In-Reply-To: <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvja6FwI8Ag22n9S2ezLnBYnGqp53R Ylf/P0YHZo+zC/6weixZ8pPJ49KLQ2wBzFFcNimpOZllqUX6dglcGWeeZhZ8TaiY9XANUwPj Md8uRg4OCQETiR1/ErsYOYFMMYkL99azdTFycQgJHGKUWHLlIDOEs5hR4uOdKawgDWwCVhJP DvmANIgIFEj8e3WHDSQsLKAu8eC6OkRYQ+L24X52CNtNYuesc2wgNouAqsTsz++YQGxeAW+J 9iuH2SHGr2aSWNTykwlkDqdAkMT8CykgNYwCshITdi9iBLGZBcQlbj2ZzwRxp4DEkj3nmSFs UYmXj/+xQtiKEh9f7YOq15O4MXUKG4StLbFs4WtmiL2CEidnPmGZwCg6C8nYWUhaZiFpmYWk ZQEjyypG9tzEzJz0cvNNjMDIOLjlt8EOxk33xQ4xSnOwKInzhrteCBASSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXAqMVR8cPYXZr1zpQffxS4z0RqciZJZKkatTh9PTbtUMlao6qKJcdU1NY6 V7HsdjfOazkfKPVp0f/qW3POathoZQbE5pQe1W7q1vyzuG1u/8nC+P37OWPnzI3w+bPDd8OW TSdfybgxGy7yXjTZTHmbYEmBWNeHbJ0r82ylOKqtZZs2ON394HdEiaU4I9FQi7moOBEAlem9 0VoCAAA= Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 14:52:43 -0000 Igor, Snigdho, I agree with Snigdho. Why don't we call it provider topology (or whatever) = if it includes both virtual links/nodes and real links/nodes? I don't think= it has anything to deal with naming space. Further replies in line I'd like to have feedbacks from you and all on Open Issue 4. That's an adve= rtisement models draft issue but it's something that i can't really underst= and yet. BR Daniele >-----Original Message----- >From: Snigdho Bardalai [mailto:SBardalai@infinera.com]=20 >Sent: gioved=EC 17 gennaio 2013 5.28 >To: Igor Bryskin; Daniele Ceccarelli; CCAMP >Subject: RE: Overlay model framework v2 > >Hi Igor, > >Not sure if the case you are citing qualifies a real node or=20 >link to be called virtual. The client space name is simply an alias. > >Regards >Snigdho > >> -----Original Message----- >> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >> Sent: Wednesday, January 16, 2013 3:04 PM >> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >> Subject: RE: Overlay model framework v2 >>=20 >> Snigdho, >>=20 >> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >> > more virtual or real provider network domain nodes that exist in=20 >> > the customer layer network and are interconnected via 0 or more=20 >> > virtual links. >>=20 >> [SCB] Since the topology advertised by the provider network can=20 >> contain real or virtual elements, why do we call it "virtual=20 >> topology"? Should it simply be called "provider topology"? And then=20 >> specify that it may contain both virtual or real elements. >>=20 >> Virtual topology includes only virtual nodes. Even when we are=20 >> considering real PEs terminating VLs, we must treat the PEs in the=20 >> context of Virtual Topology as VNs since they must be named from the=20 >> client naming space. >>=20 >> Igor >>=20 >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf=20 >> Of Snigdho Bardalai >> Sent: Wednesday, January 16, 2013 5:48 PM >> To: Daniele Ceccarelli; CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >>=20 >> Hi Daniele, >>=20 >> A few comments. Please see in-line. >>=20 >> Thanks >> Snigdho >>=20 >> > -----Original Message----- >> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> Behalf >> > Of Daniele Ceccarelli >> > Sent: Wednesday, January 16, 2013 7:33 AM >> > To: CCAMP >> > Subject: [CCAMP] Overlay model framework v2 >> > >> > Dear overlayers, >> > >> > Please find below a new version (v2) of the framework summary=20 >> > reflecting the latest discussions. Again i hope i've captured all=20 >> > the comments around, sorry if anything is missing, in case=20 >just let=20 >> > me know what i missed. >> > >> > BR >> > Daniele >> > >> > >> > + Disclaimer: >> > 1. Packet opto integration is often considered but the=20 >work can be=20 >> > extented to any type of SC. Eg. TDM over LSC. >> > >> > + Terminology: >> > 1. Virtual Link: A virtual link is a potential path between two=20 >> > virtual or real network elements in a provider layer network that >> is >> > maintained/controlled in and by the provider domain control plane=20 >> > (and as such cannot transport any traffic/data and protected from=20 >> > being >> > de-provisioned) and which can be instantiated in the data plane=20 >> > (and then can carry/transport/forward traffic/data) preserving=20 >> > previously advertised attributes such as fate sharing information. >> > 2. Virtual Node: Virtual node is a collection of zero or more=20 >> > provider network domain nodes that are collectively=20 >represented to=20 >> > the clients as a single node that exists in the customer layer=20 >> > network and is capable of terminating of access, inter-domain and >> virtual links. >>=20 >> [SCB] Agree with Igor's comment - a virtual node can be a=20 >combination=20 >> of multiple nodes or a part of the single node, but to the customer=20 >> node this is transparent. Yes, agree. >>=20 >> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >> > more virtual or real provider network domain nodes that exist in=20 >> > the customer layer network and are interconnected via 0 or more=20 >> > virtual links. >>=20 >> [SCB] Since the topology advertised by the provider network can=20 >> contain real or virtual elements, why do we call it "virtual=20 >> topology"? Should it simply be called "provider topology"? And then=20 >> specify that it may contain both virtual or real elements. See above >>=20 >> > 4. Overlay topology: is a superset of virtual topologies provided >> by >> > each of provider network domains, access and inter-domain links. >>=20 >> [SCB] A more concise definition for the overlay topology is=20 >- CE nodes >> + Access-links + provider topology as advertised by the provider >> network. We wanted to include also the possiblity of having multiple provider domain= s. >>=20 >> > 5. Access Link: Link between OC and OE. GMPLS runs on=20 >that link. It=20 >> > can support any of the SCs supported by the GMPLS. >> > 6. CE (customer Edge): Something like the CN in RFC4208=20 >teminology=20 >> > but (i) receiving virtual topology from the provider network and=20 >> > requesting the set up of one of them or >> > (ii) requesting the computation and establishment of a path=20 >> > accordingly to given constraints in the provider network and=20 >> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >> > 7. PE (provider Edge): Something like the EN in RFC4208=20 >but able to=20 >> > deal with (i) and (ii) above. >> > 8. PE-CE interface (former ONI) : Interface allowing for=20 >signaling=20 >> > and routing messages exchange between customer overlay=20 >and provider=20 >> > network. Routing information consists on virtual topology=20 >> > advertisement. When there is no routing adjacency across the >> interface >> > it is equivalent to the GMPLS UNI defined in 4208. Signaling=20 >> > messages are compliant with RFC4208. Information related to path=20 >> > carachteristics, e.g. TE-metrics, collected SRLG, path delay etc,=20 >> > either passed from CE to PE via signaling after the LSP=20 >> > establishment in the core network or from CE to PE to be used as=20 >> > path computation constraints, fall under the definition of=20 >> > signaling info and not routing info). >> > 9. CE-CE (former O-NNI): Interface on the links between different=20 >> > provider networks in the overlay model environment. Same features=20 >> > of the CE-PE apply to this interface. >>=20 >> [SCB] Is this "PE-PE" instead of "CE-CE"? Oooops! Definitely. >>=20 >> > >> > + Statements >> > 1. In the context of overlay model we are aiming to build an=20 >> > overlay topology for the customer network domains 2. The overlay=20 >> > topology >> is >> > comprised of: >> > a) access links (links connecting client NEs to the provider=20 >> > network domains). >> > They can be PSC or LSC. >> > b) inter-domain links (links interconnecting server network >> > domains) >> > c) virtual topology provided by the provider network domains. >> > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a >> set >> > of parameters e.g. SRLG, optical impairments, delay etc for each >> > entry) describing connectivity between access links and virtual >> links. >> > 3. In the context of overlay model we manage hierarchy =20 >of overlay=20 >> > topologies with overlay/underlay relationships 4. In the context=20 >> > of overlay model multi-layering and inter-layer relationships are=20 >> > peripheral at best, it is all about horizontal network integration >> 5. >> > The overlay model assumes one CP instance for the customer network >> and >> > a separate instance for the provider network and in the CE-PE=20 >> > interface case the provider network also surreptitiously >> participates >> > in the customer network by injecting virtual topology information=20 >> > into it. >>=20 >> [SCB] Specific implementations may or may not have a single instance=20 >> for the provider and the overlay. Mmm, that's true. It MUST work with two different instances but no one prev= ents it to work with a single one. >>=20 >> > 6. L1VPN (and LxVPN) in general is a type of service=20 >provided over=20 >> > the CE-PE interface (it falls under the UNI case as no routing=20 >> > adjacency is in place between CE and PE). >>=20 >> > >> > >> > + Advertisement models (to be detailed in dedicated >> > + document/documents) >> > The CE-PE interface in the overlay model context foresees=20 >two types=20 >> > of advertisement models.(names still to be agreed) A.=20 >Augmented UNI: >> > The GMPLS UNI is defined in RFC4208 and augmented by a number of=20 >> > actived draft (references to various drafts to be added). >> > The Augmented UNI is a particular type of CE-PE interface where=20 >> > only signaling messages are exchanged between CE and PE. Messages=20 >> > from CE to PE can include a set of parameters to be used=20 >by the PE=20 >> > as path computation constraints when computing a path in the=20 >> > provider domain network, while messages from PE to CE can=20 >include a=20 >> > set of >> parameters >> > qualifying the LSP being established, like for example=20 >SRLG, delay,=20 >> > loss etc. >> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >> > called with the general CE-PE interface term?) allowing the=20 >> > establishment of signaling and routing adjacency between=20 >CE and PE. >> > Routing info passed from PE to CE comprise overlay topology=20 >> > information including (but not limited to) virtual links,=20 >> > connectivity matrices and access links with parameters qualifying >> each >> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=20 >> > information >> and procedures are compliant with RFC4208. >> > >> > + Open issues/questions >> > 1. PCE-PCEP - do we need to include considerations about PCE and >> PCEP >> > into the overlay framework context? >>=20 >> [SCB] IMO - this should be described in the overlay=20 >framework document=20 >> to establish the context. +1 >>=20 >> > 2. BGP-LS needs to be considered >> > 3. Should potentials be included? E.g. I2RS? >> > 4. Virtual links: wouldn't a different definition of=20 >virtual links=20 >> > avoid the advertisement of connectivity matrices (this is=20 >out of the=20 >> > fwk scope but within the advertisement models one)? >> > Take this example: >> > PE1-----CE1 CE2-----PE2 >> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >> > i.e. There are 2 VL connecting CE1 and CE2 that could be available >> for >> > PE1 and PE2 to set up an adjacency in the customer domain. CE1=20 >> > and/or >> > CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >> > depending on the connectivity matrices of CE1 and CE2. Hence PEs=20 >> > need to be aware of both VL and connectivity matrices. My=20 >point is:=20 >> > if CE1 advertises to PE1 only the VL that his connectivity matrix=20 >> > allows to be connected to PE1 (e.g. VL1 only) and not all of them,=20 >> > it should be possible to avoid the connectivity matrices=20 >advertisement. >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > DANIELE CECCARELLI >> > System & Technology - PDU Optical & Metro >> > >> > Via E.Melen, 77 >> > Genova, Italy >> > Phone +390106002512 >> > Mobile +393346725750 >> > daniele.ceccarelli@ericsson.com >> > www.ericsson.com >> > >> > This Communication is Confidential. We only send and receive email=20 >> > on the basis of the term set out at=20 >> > www.ericsson.com/email_disclaimer >> > >> > _______________________________________________ >> > CCAMP mailing list >> > CCAMP@ietf.org >> > https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >= From IBryskin@advaoptical.com Thu Jan 17 07:29:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF8521F8484 for ; Thu, 17 Jan 2013 07:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 f4C2Jg4rUueB for ; Thu, 17 Jan 2013 07:29:35 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9845D21F8487 for ; Thu, 17 Jan 2013 07:29:34 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0HFTQhQ004466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 16:29:26 +0100 Received: from MUC-SRV-MBX1.advaoptical.com (172.20.1.95) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 17 Jan 2013 16:29:26 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 17 Jan 2013 16:29:25 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Thu, 17 Jan 2013 10:29:24 -0500 From: Igor Bryskin To: Daniele Ceccarelli , Snigdho Bardalai , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAOJ5ugAAF4jxAAC1ZqcAAgY/iAAAnZVHA= Date: Thu, 17 Jan 2013 15:29:23 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-17_06:2013-01-17, 2013-01-17, 1970-01-01 signatures=0 Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 15:29:36 -0000 Daniele, We want to separate a Virtual Topology advertised to the clients (which is,= generally speaking, different for different sets of clients) from provider= real topology, which must be concealed from the clients. I disagree with Snigdho, when he is saying that a PE just has multiple alia= ses (one from each client name space). There is much more to this. The way = I see it a PE contributes differently to different Virtual Topologies (each= time with a different ID, sometimes as a whole, sometimes as split into se= veral VNs, sometimes as a part of a large VN, possibly with a separate conn= ectivity matrix. it also, depending on Virtual Topology, presents itself as= switch of a different layer network, and so forth). Therefore, PE in the c= ontext of Virtual Topology is always a Virtual Node, even when it is mapped= 1:1 onto real provider switch. In general, only VN can terminate a VL. Igor -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]=20 Sent: Thursday, January 17, 2013 9:53 AM To: Snigdho Bardalai; Igor Bryskin; CCAMP Subject: RE: Overlay model framework v2 Igor, Snigdho, I agree with Snigdho. Why don't we call it provider topology (or whatever) = if it includes both virtual links/nodes and real links/nodes? I don't think= it has anything to deal with naming space. Further replies in line I'd like to have feedbacks from you and all on Open Issue 4. That's an adve= rtisement models draft issue but it's something that i can't really underst= and yet. BR Daniele >-----Original Message----- >From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >Sent: gioved=EC 17 gennaio 2013 5.28 >To: Igor Bryskin; Daniele Ceccarelli; CCAMP >Subject: RE: Overlay model framework v2 > >Hi Igor, > >Not sure if the case you are citing qualifies a real node or link to be=20 >called virtual. The client space name is simply an alias. > >Regards >Snigdho > >> -----Original Message----- >> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >> Sent: Wednesday, January 16, 2013 3:04 PM >> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >> Subject: RE: Overlay model framework v2 >>=20 >> Snigdho, >>=20 >> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >> > more virtual or real provider network domain nodes that exist in=20 >> > the customer layer network and are interconnected via 0 or more=20 >> > virtual links. >>=20 >> [SCB] Since the topology advertised by the provider network can=20 >> contain real or virtual elements, why do we call it "virtual=20 >> topology"? Should it simply be called "provider topology"? And then=20 >> specify that it may contain both virtual or real elements. >>=20 >> Virtual topology includes only virtual nodes. Even when we are=20 >> considering real PEs terminating VLs, we must treat the PEs in the=20 >> context of Virtual Topology as VNs since they must be named from the=20 >> client naming space. >>=20 >> Igor >>=20 >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >On Behalf >> Of Snigdho Bardalai >> Sent: Wednesday, January 16, 2013 5:48 PM >> To: Daniele Ceccarelli; CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >>=20 >> Hi Daniele, >>=20 >> A few comments. Please see in-line. >>=20 >> Thanks >> Snigdho >>=20 >> > -----Original Message----- >> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> Behalf >> > Of Daniele Ceccarelli >> > Sent: Wednesday, January 16, 2013 7:33 AM >> > To: CCAMP >> > Subject: [CCAMP] Overlay model framework v2 >> > >> > Dear overlayers, >> > >> > Please find below a new version (v2) of the framework summary=20 >> > reflecting the latest discussions. Again i hope i've captured all=20 >> > the comments around, sorry if anything is missing, in case >just let >> > me know what i missed. >> > >> > BR >> > Daniele >> > >> > >> > + Disclaimer: >> > 1. Packet opto integration is often considered but the >work can be >> > extented to any type of SC. Eg. TDM over LSC. >> > >> > + Terminology: >> > 1. Virtual Link: A virtual link is a potential path between two=20 >> > virtual or real network elements in a provider layer network that >> is >> > maintained/controlled in and by the provider domain control plane=20 >> > (and as such cannot transport any traffic/data and protected from=20 >> > being >> > de-provisioned) and which can be instantiated in the data plane=20 >> > (and then can carry/transport/forward traffic/data) preserving=20 >> > previously advertised attributes such as fate sharing information. >> > 2. Virtual Node: Virtual node is a collection of zero or more=20 >> > provider network domain nodes that are collectively >represented to >> > the clients as a single node that exists in the customer layer=20 >> > network and is capable of terminating of access, inter-domain and >> virtual links. >>=20 >> [SCB] Agree with Igor's comment - a virtual node can be a >combination >> of multiple nodes or a part of the single node, but to the customer=20 >> node this is transparent. Yes, agree. >>=20 >> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >> > more virtual or real provider network domain nodes that exist in=20 >> > the customer layer network and are interconnected via 0 or more=20 >> > virtual links. >>=20 >> [SCB] Since the topology advertised by the provider network can=20 >> contain real or virtual elements, why do we call it "virtual=20 >> topology"? Should it simply be called "provider topology"? And then=20 >> specify that it may contain both virtual or real elements. See above >>=20 >> > 4. Overlay topology: is a superset of virtual topologies provided >> by >> > each of provider network domains, access and inter-domain links. >>=20 >> [SCB] A more concise definition for the overlay topology is >- CE nodes >> + Access-links + provider topology as advertised by the provider >> network. We wanted to include also the possiblity of having multiple provider domain= s. >>=20 >> > 5. Access Link: Link between OC and OE. GMPLS runs on >that link. It >> > can support any of the SCs supported by the GMPLS. >> > 6. CE (customer Edge): Something like the CN in RFC4208 >teminology >> > but (i) receiving virtual topology from the provider network and=20 >> > requesting the set up of one of them or >> > (ii) requesting the computation and establishment of a path=20 >> > accordingly to given constraints in the provider network and=20 >> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >> > 7. PE (provider Edge): Something like the EN in RFC4208 >but able to >> > deal with (i) and (ii) above. >> > 8. PE-CE interface (former ONI) : Interface allowing for >signaling >> > and routing messages exchange between customer overlay >and provider >> > network. Routing information consists on virtual topology=20 >> > advertisement. When there is no routing adjacency across the >> interface >> > it is equivalent to the GMPLS UNI defined in 4208. Signaling=20 >> > messages are compliant with RFC4208. Information related to path=20 >> > carachteristics, e.g. TE-metrics, collected SRLG, path delay etc,=20 >> > either passed from CE to PE via signaling after the LSP=20 >> > establishment in the core network or from CE to PE to be used as=20 >> > path computation constraints, fall under the definition of=20 >> > signaling info and not routing info). >> > 9. CE-CE (former O-NNI): Interface on the links between different=20 >> > provider networks in the overlay model environment. Same features=20 >> > of the CE-PE apply to this interface. >>=20 >> [SCB] Is this "PE-PE" instead of "CE-CE"? Oooops! Definitely. >>=20 >> > >> > + Statements >> > 1. In the context of overlay model we are aiming to build an=20 >> > overlay topology for the customer network domains 2. The overlay=20 >> > topology >> is >> > comprised of: >> > a) access links (links connecting client NEs to the provider=20 >> > network domains). >> > They can be PSC or LSC. >> > b) inter-domain links (links interconnecting server network >> > domains) >> > c) virtual topology provided by the provider network domains. >> > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a >> set >> > of parameters e.g. SRLG, optical impairments, delay etc for each >> > entry) describing connectivity between access links and virtual >> links. >> > 3. In the context of overlay model we manage hierarchy >of overlay >> > topologies with overlay/underlay relationships 4. In the context=20 >> > of overlay model multi-layering and inter-layer relationships are=20 >> > peripheral at best, it is all about horizontal network integration >> 5. >> > The overlay model assumes one CP instance for the customer network >> and >> > a separate instance for the provider network and in the CE-PE=20 >> > interface case the provider network also surreptitiously >> participates >> > in the customer network by injecting virtual topology information=20 >> > into it. >>=20 >> [SCB] Specific implementations may or may not have a single instance=20 >> for the provider and the overlay. Mmm, that's true. It MUST work with two different instances but no one prev= ents it to work with a single one. >>=20 >> > 6. L1VPN (and LxVPN) in general is a type of service >provided over >> > the CE-PE interface (it falls under the UNI case as no routing=20 >> > adjacency is in place between CE and PE). >>=20 >> > >> > >> > + Advertisement models (to be detailed in dedicated >> > + document/documents) >> > The CE-PE interface in the overlay model context foresees >two types >> > of advertisement models.(names still to be agreed) A.=20 >Augmented UNI: >> > The GMPLS UNI is defined in RFC4208 and augmented by a number of=20 >> > actived draft (references to various drafts to be added). >> > The Augmented UNI is a particular type of CE-PE interface where=20 >> > only signaling messages are exchanged between CE and PE. Messages=20 >> > from CE to PE can include a set of parameters to be used >by the PE >> > as path computation constraints when computing a path in the=20 >> > provider domain network, while messages from PE to CE can >include a >> > set of >> parameters >> > qualifying the LSP being established, like for example >SRLG, delay, >> > loss etc. >> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >> > called with the general CE-PE interface term?) allowing the=20 >> > establishment of signaling and routing adjacency between >CE and PE. >> > Routing info passed from PE to CE comprise overlay topology=20 >> > information including (but not limited to) virtual links,=20 >> > connectivity matrices and access links with parameters qualifying >> each >> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=20 >> > information >> and procedures are compliant with RFC4208. >> > >> > + Open issues/questions >> > 1. PCE-PCEP - do we need to include considerations about PCE and >> PCEP >> > into the overlay framework context? >>=20 >> [SCB] IMO - this should be described in the overlay >framework document >> to establish the context. +1 >>=20 >> > 2. BGP-LS needs to be considered >> > 3. Should potentials be included? E.g. I2RS? >> > 4. Virtual links: wouldn't a different definition of=20 >virtual links=20 >> > avoid the advertisement of connectivity matrices (this is=20 >out of the=20 >> > fwk scope but within the advertisement models one)? >> > Take this example: >> > PE1-----CE1 CE2-----PE2 >> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >> > i.e. There are 2 VL connecting CE1 and CE2 that could be available >> for >> > PE1 and PE2 to set up an adjacency in the customer domain. CE1=20 >> > and/or >> > CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >> > depending on the connectivity matrices of CE1 and CE2. Hence PEs=20 >> > need to be aware of both VL and connectivity matrices. My=20 >point is:=20 >> > if CE1 advertises to PE1 only the VL that his connectivity matrix=20 >> > allows to be connected to PE1 (e.g. VL1 only) and not all of them,=20 >> > it should be possible to avoid the connectivity matrices=20 >advertisement. >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > DANIELE CECCARELLI >> > System & Technology - PDU Optical & Metro >> > >> > Via E.Melen, 77 >> > Genova, Italy >> > Phone +390106002512 >> > Mobile +393346725750 >> > daniele.ceccarelli@ericsson.com >> > www.ericsson.com >> > >> > This Communication is Confidential. We only send and receive email=20 >> > on the basis of the term set out at=20 >> > www.ericsson.com/email_disclaimer >> > >> > _______________________________________________ >> > CCAMP mailing list >> > CCAMP@ietf.org >> > https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > From vishnupavan@gmail.com Thu Jan 17 08:09:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4761821F86D4 for ; Thu, 17 Jan 2013 08:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 dESLAttkp9f9 for ; Thu, 17 Jan 2013 08:09:05 -0800 (PST) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id 79F6021F86A3 for ; Thu, 17 Jan 2013 08:09:04 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id jm19so1465284bkc.8 for ; Thu, 17 Jan 2013 08:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GTd7YOzAmN0VvZAxiG10Rq8vDYCygtsHQLzgQCGy0Nw=; b=KwrzbvTloTs80QWI/GGfmjLRnE2C1uo9+JyL3qg8cGJjwNr++eSw0deOwB2BM49RpI 5HrrB5W3qnoZkNeFiWFL1Nf5wwDhQrUBjC6cpFdCd251XjYXqTudMzC9Uhg5LQWW6Yx0 GD7Sgtubu3FjPGS+NI4PnfxQlw9kxrV+9k0TfF/lVEcEIfDVtfc5MwTyu8EU4LnEbj6a U/aJZ3CrPa9WYoTozUvNJBIyPLhoReBxEujnDGr5wFAanDgBDKaAjAx1oCe945Dx2hZx ejBCdL9Grd181bu7BGovzlVJE8Eikp/9Wo4QA89Kn5mYsKv41eN5dnlsK+hLZ8Z292QS EB9A== MIME-Version: 1.0 X-Received: by 10.204.147.132 with SMTP id l4mr1748433bkv.20.1358438943558; Thu, 17 Jan 2013 08:09:03 -0800 (PST) Received: by 10.204.170.139 with HTTP; Thu, 17 Jan 2013 08:09:03 -0800 (PST) In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> Date: Thu, 17 Jan 2013 11:09:03 -0500 Message-ID: From: Vishnu Pavan Beeram To: Daniele Ceccarelli Content-Type: multipart/alternative; boundary=0015174c4322ae0e2b04d37e3652 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:09:07 -0000 --0015174c4322ae0e2b04d37e3652 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniele, Hi! > I agree with Snigdho. Why don't we call it provider topology (or whatever= ) > if it includes both virtual links/nodes and real links/nodes? I don't thi= nk > it has anything to deal with naming space. > I (personally) don't see any confusion with using the term "Virtual Topology" even if the topology includes VNs that represent fractions of a real node. If there are still some strong reservations, I wouldn't want to use the term "Provider Topology" as the alternative (look for other terms - "Exported Provider Topology" (or) "Summarized Provider Topology" or whatever). > > I'd like to have feedbacks from you and all on Open Issue 4. That's an > advertisement models draft issue but it's something that i can't really > understand yet. > > I think you have "CEs" and "PEs" mixed up in your example. If the notations are interchanged, your example topology would look like the following: =3D=3D=3D=3DVL1=3D=3D=3D=3D CE1-----PE1 PE2-----CE2 =3D=3D=3D=3DVL2=3D=3D=3D=3D If you have just one access-link between each CE-PE pair, then it might be ok for the PE node to advertise only the VL(s) that can be switched onto from the single access-link (and hide all other VLs). But consider the case where you have more than one access-link between each CE-PE pair as shown below. =3D=3DAL1=3D=3D =3D=3D=3D=3DVL1=3D=3D=3D=3D =3D=3DAL3= =3D=3D CE1 PE1 PE2 CE2 =3D=3DAL2=3D=3D =3D=3D=3D=3DVL2=3D=3D=3D=3D =3D=3DAL4= =3D=3D Say the connectivity constraints only allow the paths {AL1, VL2, AL3} and {AL2, VL1,AL4} to be provisioned. For this particular exported provider topology, advertising the "connectivity constraints" is a MUST. But if the provider topology is exported to the client as shown below, there wouldn't be a need to advertise the "connectivity constraints". Each PE node is broken down into 2 Virtual entities. =3D=3DAL1=3D=3DVN1=3D=3D=3D=3DVL2=3D=3D=3D=3DVN3=3D=3DAL3=3D=3D CE1 CE2 =3D=3DAL2=3D=3DVN2=3D=3D=3D=3DVL1=3D=3D=3D=3DVN4=3D=3DAL4=3D=3D The manner in which the provider topology gets exported (operator choice) to the client would determine what TE attributes get/don't get advertised. Hope that helps, -Pavan > > >-----Original Message----- > >From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > >Sent: gioved=EC 17 gennaio 2013 5.28 > >To: Igor Bryskin; Daniele Ceccarelli; CCAMP > >Subject: RE: Overlay model framework v2 > > > >Hi Igor, > > > >Not sure if the case you are citing qualifies a real node or > >link to be called virtual. The client space name is simply an alias. > > > >Regards > >Snigdho > > > >> -----Original Message----- > >> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >> Sent: Wednesday, January 16, 2013 3:04 PM > >> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP > >> Subject: RE: Overlay model framework v2 > >> > >> Snigdho, > >> > >> > 3. Virtual Topology: Virtual topology is a collection of one or > >> > more virtual or real provider network domain nodes that exist in > >> > the customer layer network and are interconnected via 0 or more > >> > virtual links. > >> > >> [SCB] Since the topology advertised by the provider network can > >> contain real or virtual elements, why do we call it "virtual > >> topology"? Should it simply be called "provider topology"? And then > >> specify that it may contain both virtual or real elements. > >> > >> Virtual topology includes only virtual nodes. Even when we are > >> considering real PEs terminating VLs, we must treat the PEs in the > >> context of Virtual Topology as VNs since they must be named from the > >> client naming space. > >> > >> Igor > >> > >> > >> -----Original Message----- > >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > >On Behalf > >> Of Snigdho Bardalai > >> Sent: Wednesday, January 16, 2013 5:48 PM > >> To: Daniele Ceccarelli; CCAMP > >> Subject: Re: [CCAMP] Overlay model framework v2 > >> > >> Hi Daniele, > >> > >> A few comments. Please see in-line. > >> > >> Thanks > >> Snigdho > >> > >> > -----Original Message----- > >> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >> Behalf > >> > Of Daniele Ceccarelli > >> > Sent: Wednesday, January 16, 2013 7:33 AM > >> > To: CCAMP > >> > Subject: [CCAMP] Overlay model framework v2 > >> > > >> > Dear overlayers, > >> > > >> > Please find below a new version (v2) of the framework summary > >> > reflecting the latest discussions. Again i hope i've captured all > >> > the comments around, sorry if anything is missing, in case > >just let > >> > me know what i missed. > >> > > >> > BR > >> > Daniele > >> > > >> > > >> > + Disclaimer: > >> > 1. Packet opto integration is often considered but the > >work can be > >> > extented to any type of SC. Eg. TDM over LSC. > >> > > >> > + Terminology: > >> > 1. Virtual Link: A virtual link is a potential path between two > >> > virtual or real network elements in a provider layer network that > >> is > >> > maintained/controlled in and by the provider domain control plane > >> > (and as such cannot transport any traffic/data and protected from > >> > being > >> > de-provisioned) and which can be instantiated in the data plane > >> > (and then can carry/transport/forward traffic/data) preserving > >> > previously advertised attributes such as fate sharing information. > >> > 2. Virtual Node: Virtual node is a collection of zero or more > >> > provider network domain nodes that are collectively > >represented to > >> > the clients as a single node that exists in the customer layer > >> > network and is capable of terminating of access, inter-domain and > >> virtual links. > >> > >> [SCB] Agree with Igor's comment - a virtual node can be a > >combination > >> of multiple nodes or a part of the single node, but to the customer > >> node this is transparent. > > Yes, agree. > > >> > >> > 3. Virtual Topology: Virtual topology is a collection of one or > >> > more virtual or real provider network domain nodes that exist in > >> > the customer layer network and are interconnected via 0 or more > >> > virtual links. > >> > >> [SCB] Since the topology advertised by the provider network can > >> contain real or virtual elements, why do we call it "virtual > >> topology"? Should it simply be called "provider topology"? And then > >> specify that it may contain both virtual or real elements. > > See above > > >> > >> > 4. Overlay topology: is a superset of virtual topologies provided > >> by > >> > each of provider network domains, access and inter-domain links. > >> > >> [SCB] A more concise definition for the overlay topology is > >- CE nodes > >> + Access-links + provider topology as advertised by the provider > >> network. > > We wanted to include also the possiblity of having multiple provider > domains. > > >> > >> > 5. Access Link: Link between OC and OE. GMPLS runs on > >that link. It > >> > can support any of the SCs supported by the GMPLS. > >> > 6. CE (customer Edge): Something like the CN in RFC4208 > >teminology > >> > but (i) receiving virtual topology from the provider network and > >> > requesting the set up of one of them or > >> > (ii) requesting the computation and establishment of a path > >> > accordingly to given constraints in the provider network and > >> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. > >> > 7. PE (provider Edge): Something like the EN in RFC4208 > >but able to > >> > deal with (i) and (ii) above. > >> > 8. PE-CE interface (former ONI) : Interface allowing for > >signaling > >> > and routing messages exchange between customer overlay > >and provider > >> > network. Routing information consists on virtual topology > >> > advertisement. When there is no routing adjacency across the > >> interface > >> > it is equivalent to the GMPLS UNI defined in 4208. Signaling > >> > messages are compliant with RFC4208. Information related to path > >> > carachteristics, e.g. TE-metrics, collected SRLG, path delay etc, > >> > either passed from CE to PE via signaling after the LSP > >> > establishment in the core network or from CE to PE to be used as > >> > path computation constraints, fall under the definition of > >> > signaling info and not routing info). > >> > 9. CE-CE (former O-NNI): Interface on the links between different > >> > provider networks in the overlay model environment. Same features > >> > of the CE-PE apply to this interface. > >> > >> [SCB] Is this "PE-PE" instead of "CE-CE"? > > Oooops! Definitely. > > >> > >> > > >> > + Statements > >> > 1. In the context of overlay model we are aiming to build an > >> > overlay topology for the customer network domains 2. The overlay > >> > topology > >> is > >> > comprised of: > >> > a) access links (links connecting client NEs to the provider > >> > network domains). > >> > They can be PSC or LSC. > >> > b) inter-domain links (links interconnecting server network > >> > domains) > >> > c) virtual topology provided by the provider network domains. > >> > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a > >> set > >> > of parameters e.g. SRLG, optical impairments, delay etc for each > >> > entry) describing connectivity between access links and virtual > >> links. > >> > 3. In the context of overlay model we manage hierarchy > >of overlay > >> > topologies with overlay/underlay relationships 4. In the context > >> > of overlay model multi-layering and inter-layer relationships are > >> > peripheral at best, it is all about horizontal network integration > >> 5. > >> > The overlay model assumes one CP instance for the customer network > >> and > >> > a separate instance for the provider network and in the CE-PE > >> > interface case the provider network also surreptitiously > >> participates > >> > in the customer network by injecting virtual topology information > >> > into it. > >> > >> [SCB] Specific implementations may or may not have a single instance > >> for the provider and the overlay. > > Mmm, that's true. It MUST work with two different instances but no one > prevents it to work with a single one. > > >> > >> > 6. L1VPN (and LxVPN) in general is a type of service > >provided over > >> > the CE-PE interface (it falls under the UNI case as no routing > >> > adjacency is in place between CE and PE). > >> > >> > > >> > > >> > + Advertisement models (to be detailed in dedicated > >> > + document/documents) > >> > The CE-PE interface in the overlay model context foresees > >two types > >> > of advertisement models.(names still to be agreed) A. > >Augmented UNI: > >> > The GMPLS UNI is defined in RFC4208 and augmented by a number of > >> > actived draft (references to various drafts to be added). > >> > The Augmented UNI is a particular type of CE-PE interface where > >> > only signaling messages are exchanged between CE and PE. Messages > >> > from CE to PE can include a set of parameters to be used > >by the PE > >> > as path computation constraints when computing a path in the > >> > provider domain network, while messages from PE to CE can > >include a > >> > set of > >> parameters > >> > qualifying the LSP being established, like for example > >SRLG, delay, > >> > loss etc. > >> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply > >> > called with the general CE-PE interface term?) allowing the > >> > establishment of signaling and routing adjacency between > >CE and PE. > >> > Routing info passed from PE to CE comprise overlay topology > >> > information including (but not limited to) virtual links, > >> > connectivity matrices and access links with parameters qualifying > >> each > >> > of them in terms of e.g. SRLG, loss, delay etc. Signaling > >> > information > >> and procedures are compliant with RFC4208. > >> > > >> > + Open issues/questions > >> > 1. PCE-PCEP - do we need to include considerations about PCE and > >> PCEP > >> > into the overlay framework context? > >> > >> [SCB] IMO - this should be described in the overlay > >framework document > >> to establish the context. > > +1 > > >> > >> > 2. BGP-LS needs to be considered > >> > 3. Should potentials be included? E.g. I2RS? > >> > 4. Virtual links: wouldn't a different definition of > >virtual links > >> > avoid the advertisement of connectivity matrices (this is > >out of the > >> > fwk scope but within the advertisement models one)? > >> > Take this example: > >> > PE1-----CE1 CE2-----PE2 > >> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 > >> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 > >> > i.e. There are 2 VL connecting CE1 and CE2 that could be available > >> for > >> > PE1 and PE2 to set up an adjacency in the customer domain. CE1 > >> > and/or > >> > CE2 can be blocking nodes so VL1 and/or VL2 are available only > >> > depending on the connectivity matrices of CE1 and CE2. Hence PEs > >> > need to be aware of both VL and connectivity matrices. My > >point is: > >> > if CE1 advertises to PE1 only the VL that his connectivity matrix > >> > allows to be connected to PE1 (e.g. VL1 only) and not all of them, > >> > it should be possible to avoid the connectivity matrices > >advertisement. > >> > > >> > > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > DANIELE CECCARELLI > >> > System & Technology - PDU Optical & Metro > >> > > >> > Via E.Melen, 77 > >> > Genova, Italy > >> > Phone +390106002512 > >> > Mobile +393346725750 > >> > daniele.ceccarelli@ericsson.com > >> > www.ericsson.com > >> > > >> > This Communication is Confidential. We only send and receive email > >> > on the basis of the term set out at > >> > www.ericsson.com/email_disclaimer > >> > > >> > _______________________________________________ > >> > CCAMP mailing list > >> > CCAMP@ietf.org > >> > https://www.ietf.org/mailman/listinfo/ccamp > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --0015174c4322ae0e2b04d37e3652 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Daniele, Hi!


I agree with Snigdho. Why don't we call it provider topology (or whatev= er) if it includes both virtual links/nodes and real links/nodes? I don'= ;t think it has anything to deal with naming space.

I (personally) don't see any confusion with using the te= rm "Virtual Topology" even if the topology includes VNs that repr= esent fractions of a real node. If there are still some strong reservations= , I wouldn't want to use the term "Provider Topology" as the = alternative (look for other terms - "Exported Provider Topology" = (or) "Summarized Provider Topology" or whatever).
=A0

I'd like to have feedbacks from you and all on Open Issue 4. That&#= 39;s an advertisement models draft issue but it's something that i can&= #39;t really understand yet.


I think you have "CEs" and "PEs" mixed up in your examp= le. If the notations are interchanged, your example topology would look lik= e the following:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =3D=3D=3D=3DVL1=3D=3D=3D=3D
CE1-----PE1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PE2-= ----CE2
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D=3D= =3D=3DVL2=3D=3D=3D=3D

If you have just one a= ccess-link between each CE-PE pair, then it might be ok for the PE node to = advertise only the VL(s) that can be switched onto from the single access-l= ink (and hide all other VLs). But consider the case where you have more tha= n one access-link between each CE-PE pair as shown below. =A0

=A0 =A0 =A0 =A0 =3D=3DAL1=3D=3D =A0 =A0 =A0= =A0 =3D=3D=3D=3DVL1=3D=3D=3D=3D =A0 =A0 =A0 =3D=3DAL3=3D=3D
CE1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PE1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0PE2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CE2
=A0 = =A0 =A0 =A0 =3D=3DAL2=3D=3D =A0 =A0 =A0 =A0 =3D=3D=3D=3DVL2=3D=3D=3D=3D =A0= =A0 =A0 =3D=3DAL4=3D=3D

Say the connectivity constraints only allow= the paths {AL1, VL2, AL3} and {AL2, VL1,AL4} to be provisioned. For this p= articular exported provider topology, advertising the "connectivity co= nstraints" is a MUST.

But if the provider topology is expor= ted to the client as shown below, there wouldn't be a need to advertise= the "connectivity constraints". Each PE node is broken down into= 2 Virtual entities.

=A0 =A0 =A0 =A0 =3D=3DAL1=3D=3DVN1=3D= =3D=3D=3DVL2=3D=3D=3D=3DVN3=3D=3DAL3=3D=3D
CE1 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CE2
=A0 = =A0 =A0 =A0 =3D=3DAL2=3D=3DVN2=3D=3D=3D=3DVL1=3D=3D=3D=3DVN4=3D=3DAL4=3D=3D=

The manner in which the provider topo= logy gets exported (operator choice) to the client would determine what TE = attributes get/don't get advertised.

Hope that helps,
-Pavan=A0

>-----Original Message-----
>From: Snigdho Bardalai [mailto:SBardalai@infinera.com]
>Sent: gioved=EC 17 gennaio 2013 5.28
>To: Igor Bryskin; Daniele Ceccarelli; CCAMP
>Subject: RE: Overlay model framework v2
>
>Hi Igor,
>
>Not sure if the case you are citing qualifies a real node or
>link to be called virtual. The client space name is simply an alias. >
>Regards
>Snigdho
>
>> -----Original Message-----
>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
>> Sent: Wednesday, January 16, 2013 3:04 PM
>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP
>> Subject: RE: Overlay model framework v2
>>
>> Snigdho,
>>
>> > =A03. Virtual Topology: Virtual topology is a collection of o= ne or
>> > more virtual or real provider =A0network domain nodes that ex= ist in
>> > the customer layer network and are interconnected =A0via 0 or= more
>> > virtual links.
>>
>> [SCB] Since the topology advertised by the provider network can >> contain real or virtual elements, why do we call it "virtual<= br> >> topology"? Should it simply be called "provider topology= "? And then
>> specify that it may contain both virtual or real elements.
>>
>> Virtual topology includes only virtual nodes. Even when we are
>> considering real PEs terminating VLs, we must treat the PEs in the=
>> context of Virtual Topology as VNs since they must be named from t= he
>> client naming space.
>>
>> Igor
>>
>>
>> -----Original Message-----
>> From: = ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
>On Behalf
>> Of Snigdho Bardalai
>> Sent: Wednesday, January 16, 2013 5:48 PM
>> To: Daniele Ceccarelli; CCAMP
>> Subject: Re: [CCAMP] Overlay model framework v2
>>
>> Hi Daniele,
>>
>> A few comments. Please see in-line.
>>
>> Thanks
>> Snigdho
>>
>> > -----Original Message-----
>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>> Behalf
>> > Of Daniele Ceccarelli
>> > Sent: Wednesday, January 16, 2013 7:33 AM
>> > To: CCAMP
>> > Subject: [CCAMP] Overlay model framework v2
>> >
>> > Dear overlayers,
>> >
>> > Please find below a new version (v2) of the framework summary=
>> > reflecting the latest discussions. Again i hope i've capt= ured all
>> > the comments around, sorry if anything is missing, in case >just let
>> > me know what i missed.
>> >
>> > BR
>> > Daniele
>> >
>> >
>> > + Disclaimer:
>> > =A01. Packet opto integration is often considered but the
>work can be
>> > extented to any type of SC. Eg. TDM over LSC.
>> >
>> > + Terminology:
>> > =A01. Virtual Link: A virtual link is a potential path betwee= n two
>> > virtual or real network =A0elements in a provider layer netwo= rk =A0that
>> is
>> > maintained/controlled in and by the provider =A0domain contro= l plane
>> > (and as such cannot transport any traffic/data and protected = from
>> > being
>> > =A0de-provisioned) and which can be instantiated in the data = plane
>> > (and then can =A0carry/transport/forward traffic/data) preser= ving
>> > previously advertised attributes such as =A0fate sharing info= rmation.
>> > =A02. =A0Virtual Node: Virtual node is a collection of zero o= r more
>> > provider network domain =A0nodes that are collectively
>represented to
>> > the clients as a single node that =A0exists in the customer l= ayer
>> > network and is capable of terminating of access, =A0inter-dom= ain and
>> virtual links.
>>
>> [SCB] Agree with Igor's comment - a virtual node can be a
>combination
>> of multiple nodes or a part of the single node, but to the custome= r
>> node this is transparent.

Yes, agree.

>>
>> > =A03. Virtual Topology: Virtual topology is a collection of o= ne or
>> > more virtual or real provider =A0network domain nodes that ex= ist in
>> > the customer layer network and are interconnected =A0via 0 or= more
>> > virtual links.
>>
>> [SCB] Since the topology advertised by the provider network can >> contain real or virtual elements, why do we call it "virtual<= br> >> topology"? Should it simply be called "provider topology= "? And then
>> specify that it may contain both virtual or real elements.

See above

>>
>> > =A04. Overlay topology: =A0is a superset of virtual topologie= s provided
>> by
>> > each of =A0provider network domains, access and inter-domain = links.
>>
>> [SCB] A more concise definition for the overlay topology is
>- CE nodes
>> + Access-links + provider topology as advertised by the provider >> network.

We wanted to include also the possiblity of having multiple provider = domains.

>>
>> > =A05. Access Link: Link between OC and OE. GMPLS runs on
>that link. It
>> > can support =A0any of the SCs supported by the GMPLS.
>> > =A06. CE (customer Edge): Something like the CN in RFC4208 >teminology
>> > but (i) receiving =A0virtual topology from the provider netwo= rk and
>> > requesting the set up of one of them or
>> > =A0(ii) requesting the computation and establishment of a pat= h
>> > accordingly to given constraints =A0in the provider network a= nd
>> > receiving the parameters characterizing such path. (ii) =3D= =3D UNI.
>> > =A07. PE (provider Edge): Something like the EN in RFC4208 >but able to
>> > deal with (i) and (ii) above.
>> > =A08. PE-CE interface (former ONI) : Interface allowing for >signaling
>> > and routing messages =A0exchange between customer overlay
>and provider
>> > network. Routing information consists on =A0virtual topology<= br> >> > advertisement. When there is no routing adjacency across the<= br> >> interface
>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling<= br> >> > messages are compliant with =A0RFC4208. Information related t= o path
>> > carachteristics, e.g. TE-metrics, collected SRLG, =A0path del= ay etc,
>> > either passed from CE to PE via signaling after the LSP
>> > establishment in the core network or from CE to PE to be used= as
>> > path computation constraints, fall =A0under the definition of=
>> > signaling info and not routing info).
>> > =A09. CE-CE (former O-NNI): Interface on the links between di= fferent
>> > provider networks =A0in the overlay model environment. Same f= eatures
>> > of the CE-PE apply to this interface.
>>
>> [SCB] Is this "PE-PE" instead of "CE-CE"?

Oooops! Definitely.

>>
>> >
>> > + Statements
>> > =A01. In the context of overlay model we are aiming to build = an
>> > overlay topology for =A0the customer network domains =A02. Th= e overlay
>> > topology
>> is
>> > comprised of:
>> > =A0 =A0 a) access links (links connecting client NEs to the p= rovider
>> > network domains).
>> > =A0They can be PSC or LSC.
>> > =A0 =A0 b) inter-domain links (links interconnecting server n= etwork
>> > domains)
>> > =A0 =A0 c) virtual topology provided by the provider network = domains.
>> > Virtual Links =A0+ Virtual Nodes (TBD) + Connectivity Matrix = (with a
>> set
>> > of parameters e.g. SRLG, =A0optical impairments, delay etc fo= r each
>> > entry) describing connectivity between access links and virtu= al
>> links.
>> > =A03. In the context of overlay model we manage =A0hierarchy<= br> >of overlay
>> > topologies =A0with overlay/underlay relationships =A04. In th= e context
>> > of overlay model multi-layering and inter-layer relationships= =A0are
>> > peripheral at best, it is all about horizontal network integr= ation
>> 5.
>> > The overlay model assumes one CP instance for the customer ne= twork
>> and
>> > a separate =A0instance for the provider network and in the CE= -PE
>> > interface case the provider =A0network also surreptitiously >> participates
>> > in the customer network by injecting =A0virtual topology info= rmation
>> > into it.
>>
>> [SCB] Specific implementations may or may not have a single instan= ce
>> for the provider and the overlay.

Mmm, that's true. It MUST work with two different instances= but no one prevents it to work with a single one.

>>
>> > =A06. L1VPN (and LxVPN) in general is a type of service
>provided over
>> > the CE-PE interface =A0(it falls under the UNI case as no rou= ting
>> > adjacency is in place between CE and PE).
>>
>> >
>> >
>> > + Advertisement models (to be detailed in dedicated
>> > + document/documents)
>> > =A0The CE-PE interface in the overlay model context foresees<= br> >two types
>> > of advertisement =A0models.(names still to be agreed) A.
>Augmented UNI:
>> > The GMPLS UNI is defined in RFC4208 and augmented by =A0a num= ber of
>> > actived draft (references to various drafts to be added).
>> > =A0The Augmented UNI is a particular type of CE-PE interface = where
>> > only signaling messages =A0are exchanged between CE and PE. M= essages
>> > from CE to PE can include =A0a set of parameters to be used >by the PE
>> > as path computation constraints =A0when computing a path in t= he
>> > provider domain network, while messages from PE =A0to CE can<= br> >include a
>> > set of
>> parameters
>> > qualifying the LSP being established, =A0like for example
>SRLG, delay,
>> > loss etc.
>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be sim= ply
>> > called with the =A0general CE-PE interface term?) allowing th= e
>> > establishment of signaling and routing adjacency =A0between >CE and PE.
>> > Routing info passed from PE to CE comprise overlay topology >> > information including =A0(but not limited to) virtual links,<= br> >> > connectivity matrices and access links with parameters qualif= ying
>> each
>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling
>> > information
>> and procedures are =A0compliant with RFC4208.
>> >
>> > + Open issues/questions
>> > =A01. PCE-PCEP - do we need to include considerations about P= CE and
>> PCEP
>> > into the overlay framework context?
>>
>> [SCB] IMO - this should be described in the overlay
>framework document
>> to establish the context.

+1

>>
>> > =A02. BGP-LS needs to be considered
>> > =A03. Should potentials be included? E.g. I2RS?
>> > =A04. Virtual links: wouldn't a different definition of >virtual links
>> > avoid the advertisement of connectivity matrices (this is
>out of the
>> > fwk scope but within the advertisement models one)?
>> > Take this example:
>> > PE1-----CE1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CE2-----PE2
>> > =A0 =A0 =A0 =A0 CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2=
>> > =A0 =A0 =A0 =A0 CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2=
>> > i.e. There are 2 VL connecting CE1 and CE2 that could be avai= lable
>> for
>> > PE1 and PE2 to set up an adjacency in the customer domain. CE= 1
>> > and/or
>> > CE2 can be blocking nodes so VL1 and/or VL2 are available onl= y
>> > depending on the connectivity matrices of CE1 and CE2. Hence = PEs
>> > need to be aware of both VL and connectivity matrices. My
>point is:
>> > if CE1 advertises to PE1 only the VL that his connectivity ma= trix
>> > allows to be connected to PE1 (e.g. VL1 only) and not all of = them,
>> > it should be possible to avoid the connectivity matrices
>advertisement.
>> >
>> >
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> > DANIELE CECCARELLI
>> > System & Technology - PDU Optical & Metro
>> >
>> > Via E.Melen, 77
>> > Genova, Italy
>> > Phone +390106002512
>> > Mobile +393346725750
>> > daniele.ceccarelli@ericsson.com
>> > www.eri= csson.com
>> >
>> > This Communication is Confidential. We only send and receive = email
>> > on the basis of the term set out at
>> > www.ericsson.com/email_disclaimer
>> >
>> > _______________________________________________
>> > CCAMP mailing list
>> > CCAMP@iet= f.org
>> > https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org=
>> https://www.ietf.org/mailman/listinfo/ccamp
>
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--0015174c4322ae0e2b04d37e3652-- From daniele.ceccarelli@ericsson.com Thu Jan 17 08:10:24 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B9E21F879A for ; Thu, 17 Jan 2013 08:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.33 X-Spam-Level: X-Spam-Status: No, score=-5.33 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, 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 HU2cSestPuZ2 for ; Thu, 17 Jan 2013 08:10:23 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEEF21F85C2 for ; Thu, 17 Jan 2013 08:10:22 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-40-50f8226c4ff7 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 47.68.19728.C6228F05; Thu, 17 Jan 2013 17:10:21 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 17:10:20 +0100 From: Daniele Ceccarelli To: Igor Bryskin , Snigdho Bardalai , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRwFLO6lqWmk6S/LNDTw8InAANE4iAAACVKQAAC1BWgAAXfYXg///8zoD//+ZBsA== Date: Thu, 17 Jan 2013 16:10:19 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvjW6u0o8Ag32tvBZP5txgsTjV085o sav/H6MDs8fZBX9YPZYs+cnkcenFIbYA5igum5TUnMyy1CJ9uwSujHVL/7MVvCqtOHV6C2sD 4/+4LkZODgkBE4nPE84yQdhiEhfurWfrYuTiEBI4xCixb2oLlLOYUaK97zNLFyMHB5uAlcST Qz4gDSICBRJzD+xgBAkLC6hLPLiuDhHWkLh9uJ8dwg6TOD/vKSOIzSKgKjHhXycziM0r4C2x 59FWqPF7mSUuz54JNodTIEriRHsWSA2jgKzEhN2LwHqZBcQlbj2ZD3WngMSSPeeZIWxRiZeP /7GCtEoIKEos75eDKNeTuDF1ChuErS2xbOFrqLWCEidnPmGZwCg6C8nUWUhaZiFpmYWkZQEj yypG9tzEzJz0cqNNjMDYOLjlt+oOxjvnRA4xSnOwKInzhrteCBASSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAWCImIN23XU6rOF/vZsuxj3uSnqirLdzWMH/HPr6QxzeZFfk72bnEYvt/f7Ve Fm0e83Gbbrz18sDkXrm38QxlDJMWrb1/qqrS1I3xcrLlddmAe315xWcex3h9eJAvtvvs+k1P 2i6vSYv2CpEOPiLK41BsKZWxJPM+/3a+3pvcJ9zT32zZ2flYiaU4I9FQi7moOBEAWtz6ZFsC AAA= Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:10:24 -0000 What you say is more than true but orthogonal to my point :-) It's only a matter of terminology. We defined: > 3. Virtual Topology: Virtual topology is a collection of one or=20 > more virtual or real provider network domain nodes that exist in=20 > the customer layer network and are interconnected via 0 or more=20 > virtual links. If we call it "Virtual Topology", the first thing that comes to the minds i= s: its only a collection of virtual links and virtual nodes. Snigdho's proposal was to call it differently so to better identify the fac= t that it includes both virtual and real links/nodes, that's it. The name he proposed, however, is again misleading, because calling it "pro= vider topology" makes me (and you) thinking of just real links/nodes, doesn= 't it? I would suggest not to use either of the terms as both are misleading. Mayb= e something like "exported topology", "CE-PE tology" or whatever. Daniele=20 >-----Original Message----- >From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 >Sent: gioved=EC 17 gennaio 2013 16.29 >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >Daniele, > >We want to separate a Virtual Topology advertised to the=20 >clients (which is, generally speaking, different for different=20 >sets of clients) from provider real topology, which must be=20 >concealed from the clients. >I disagree with Snigdho, when he is saying that a PE just has=20 >multiple aliases (one from each client name space). There is=20 >much more to this. The way I see it a PE contributes=20 >differently to different Virtual Topologies (each time with a=20 >different ID, sometimes as a whole, sometimes as split into=20 >several VNs, sometimes as a part of a large VN, possibly with=20 >a separate connectivity matrix. it also, depending on Virtual=20 >Topology, presents itself as switch of a different layer=20 >network, and so forth). Therefore, PE in the context of=20 >Virtual Topology is always a Virtual Node, even when it is=20 >mapped 1:1 onto real provider switch. In general, only VN can=20 >terminate a VL. > >Igor > >-----Original Message----- >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >Sent: Thursday, January 17, 2013 9:53 AM >To: Snigdho Bardalai; Igor Bryskin; CCAMP >Subject: RE: Overlay model framework v2 > >Igor, Snigdho, > >I agree with Snigdho. Why don't we call it provider topology=20 >(or whatever) if it includes both virtual links/nodes and real=20 >links/nodes? I don't think it has anything to deal with naming space. > >Further replies in line > >I'd like to have feedbacks from you and all on Open Issue 4.=20 >That's an advertisement models draft issue but it's something=20 >that i can't really understand yet. > >BR >Daniele > >>-----Original Message----- >>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >>Sent: gioved=EC 17 gennaio 2013 5.28 >>To: Igor Bryskin; Daniele Ceccarelli; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Hi Igor, >> >>Not sure if the case you are citing qualifies a real node or=20 >link to be=20 >>called virtual. The client space name is simply an alias. >> >>Regards >>Snigdho >> >>> -----Original Message----- >>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>> Sent: Wednesday, January 16, 2013 3:04 PM >>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >>> Subject: RE: Overlay model framework v2 >>>=20 >>> Snigdho, >>>=20 >>> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >>> > more virtual or real provider network domain nodes that exist in=20 >>> > the customer layer network and are interconnected via 0 or more=20 >>> > virtual links. >>>=20 >>> [SCB] Since the topology advertised by the provider network can=20 >>> contain real or virtual elements, why do we call it "virtual=20 >>> topology"? Should it simply be called "provider topology"? And then=20 >>> specify that it may contain both virtual or real elements. >>>=20 >>> Virtual topology includes only virtual nodes. Even when we are=20 >>> considering real PEs terminating VLs, we must treat the PEs in the=20 >>> context of Virtual Topology as VNs since they must be named=20 >from the=20 >>> client naming space. >>>=20 >>> Igor >>>=20 >>>=20 >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>On Behalf >>> Of Snigdho Bardalai >>> Sent: Wednesday, January 16, 2013 5:48 PM >>> To: Daniele Ceccarelli; CCAMP >>> Subject: Re: [CCAMP] Overlay model framework v2 >>>=20 >>> Hi Daniele, >>>=20 >>> A few comments. Please see in-line. >>>=20 >>> Thanks >>> Snigdho >>>=20 >>> > -----Original Message----- >>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf >>> > Of Daniele Ceccarelli >>> > Sent: Wednesday, January 16, 2013 7:33 AM >>> > To: CCAMP >>> > Subject: [CCAMP] Overlay model framework v2 >>> > >>> > Dear overlayers, >>> > >>> > Please find below a new version (v2) of the framework summary=20 >>> > reflecting the latest discussions. Again i hope i've captured all=20 >>> > the comments around, sorry if anything is missing, in case >>just let >>> > me know what i missed. >>> > >>> > BR >>> > Daniele >>> > >>> > >>> > + Disclaimer: >>> > 1. Packet opto integration is often considered but the >>work can be >>> > extented to any type of SC. Eg. TDM over LSC. >>> > >>> > + Terminology: >>> > 1. Virtual Link: A virtual link is a potential path between two=20 >>> > virtual or real network elements in a provider layer=20 >network that >>> is >>> > maintained/controlled in and by the provider domain=20 >control plane=20 >>> > (and as such cannot transport any traffic/data and protected from=20 >>> > being >>> > de-provisioned) and which can be instantiated in the data plane=20 >>> > (and then can carry/transport/forward traffic/data) preserving=20 >>> > previously advertised attributes such as fate sharing=20 >information. >>> > 2. Virtual Node: Virtual node is a collection of zero or more=20 >>> > provider network domain nodes that are collectively >>represented to >>> > the clients as a single node that exists in the customer layer=20 >>> > network and is capable of terminating of access, inter-domain and >>> virtual links. >>>=20 >>> [SCB] Agree with Igor's comment - a virtual node can be a >>combination >>> of multiple nodes or a part of the single node, but to the customer=20 >>> node this is transparent. > >Yes, agree. > >>>=20 >>> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >>> > more virtual or real provider network domain nodes that exist in=20 >>> > the customer layer network and are interconnected via 0 or more=20 >>> > virtual links. >>>=20 >>> [SCB] Since the topology advertised by the provider network can=20 >>> contain real or virtual elements, why do we call it "virtual=20 >>> topology"? Should it simply be called "provider topology"? And then=20 >>> specify that it may contain both virtual or real elements. > >See above > >>>=20 >>> > 4. Overlay topology: is a superset of virtual=20 >topologies provided >>> by >>> > each of provider network domains, access and inter-domain links. >>>=20 >>> [SCB] A more concise definition for the overlay topology is >>- CE nodes >>> + Access-links + provider topology as advertised by the provider >>> network. > >We wanted to include also the possiblity of having multiple=20 >provider domains. > >>>=20 >>> > 5. Access Link: Link between OC and OE. GMPLS runs on >>that link. It >>> > can support any of the SCs supported by the GMPLS. >>> > 6. CE (customer Edge): Something like the CN in RFC4208 >>teminology >>> > but (i) receiving virtual topology from the provider network and=20 >>> > requesting the set up of one of them or >>> > (ii) requesting the computation and establishment of a path=20 >>> > accordingly to given constraints in the provider network and=20 >>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >>> > 7. PE (provider Edge): Something like the EN in RFC4208 >>but able to >>> > deal with (i) and (ii) above. >>> > 8. PE-CE interface (former ONI) : Interface allowing for >>signaling >>> > and routing messages exchange between customer overlay >>and provider >>> > network. Routing information consists on virtual topology=20 >>> > advertisement. When there is no routing adjacency across the >>> interface >>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling=20 >>> > messages are compliant with RFC4208. Information related to path=20 >>> > carachteristics, e.g. TE-metrics, collected SRLG, path=20 >delay etc,=20 >>> > either passed from CE to PE via signaling after the LSP=20 >>> > establishment in the core network or from CE to PE to be used as=20 >>> > path computation constraints, fall under the definition of=20 >>> > signaling info and not routing info). >>> > 9. CE-CE (former O-NNI): Interface on the links between=20 >different=20 >>> > provider networks in the overlay model environment. Same=20 >features=20 >>> > of the CE-PE apply to this interface. >>>=20 >>> [SCB] Is this "PE-PE" instead of "CE-CE"? > >Oooops! Definitely. > >>>=20 >>> > >>> > + Statements >>> > 1. In the context of overlay model we are aiming to build an=20 >>> > overlay topology for the customer network domains 2.=20 >The overlay=20 >>> > topology >>> is >>> > comprised of: >>> > a) access links (links connecting client NEs to the provider=20 >>> > network domains). >>> > They can be PSC or LSC. >>> > b) inter-domain links (links interconnecting server network >>> > domains) >>> > c) virtual topology provided by the provider network domains. >>> > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a >>> set >>> > of parameters e.g. SRLG, optical impairments, delay etc for each >>> > entry) describing connectivity between access links and virtual >>> links. >>> > 3. In the context of overlay model we manage hierarchy >>of overlay >>> > topologies with overlay/underlay relationships 4. In=20 >the context=20 >>> > of overlay model multi-layering and inter-layer=20 >relationships are=20 >>> > peripheral at best, it is all about horizontal network integration >>> 5. >>> > The overlay model assumes one CP instance for the customer network >>> and >>> > a separate instance for the provider network and in the CE-PE=20 >>> > interface case the provider network also surreptitiously >>> participates >>> > in the customer network by injecting virtual topology=20 >information=20 >>> > into it. >>>=20 >>> [SCB] Specific implementations may or may not have a single=20 >instance=20 >>> for the provider and the overlay. > >Mmm, that's true. It MUST work with two different instances=20 >but no one prevents it to work with a single one. > >>>=20 >>> > 6. L1VPN (and LxVPN) in general is a type of service >>provided over >>> > the CE-PE interface (it falls under the UNI case as no routing=20 >>> > adjacency is in place between CE and PE). >>>=20 >>> > >>> > >>> > + Advertisement models (to be detailed in dedicated >>> > + document/documents) >>> > The CE-PE interface in the overlay model context foresees >>two types >>> > of advertisement models.(names still to be agreed) A.=20 >>Augmented UNI: >>> > The GMPLS UNI is defined in RFC4208 and augmented by a number of=20 >>> > actived draft (references to various drafts to be added). >>> > The Augmented UNI is a particular type of CE-PE interface where=20 >>> > only signaling messages are exchanged between CE and PE.=20 >Messages=20 >>> > from CE to PE can include a set of parameters to be used >>by the PE >>> > as path computation constraints when computing a path in the=20 >>> > provider domain network, while messages from PE to CE can >>include a >>> > set of >>> parameters >>> > qualifying the LSP being established, like for example >>SRLG, delay, >>> > loss etc. >>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >>> > called with the general CE-PE interface term?) allowing the=20 >>> > establishment of signaling and routing adjacency between >>CE and PE. >>> > Routing info passed from PE to CE comprise overlay topology=20 >>> > information including (but not limited to) virtual links,=20 >>> > connectivity matrices and access links with parameters qualifying >>> each >>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=20 >>> > information >>> and procedures are compliant with RFC4208. >>> > >>> > + Open issues/questions >>> > 1. PCE-PCEP - do we need to include considerations about PCE and >>> PCEP >>> > into the overlay framework context? >>>=20 >>> [SCB] IMO - this should be described in the overlay >>framework document >>> to establish the context. > >+1 > >>>=20 >>> > 2. BGP-LS needs to be considered >>> > 3. Should potentials be included? E.g. I2RS? >>> > 4. Virtual links: wouldn't a different definition of >>virtual links >>> > avoid the advertisement of connectivity matrices (this is >>out of the >>> > fwk scope but within the advertisement models one)? >>> > Take this example: >>> > PE1-----CE1 CE2-----PE2 >>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>> > i.e. There are 2 VL connecting CE1 and CE2 that could be available >>> for >>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1=20 >>> > and/or >>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>> > depending on the connectivity matrices of CE1 and CE2. Hence PEs=20 >>> > need to be aware of both VL and connectivity matrices. My >>point is:=20 >>> > if CE1 advertises to PE1 only the VL that his connectivity matrix=20 >>> > allows to be connected to PE1 (e.g. VL1 only) and not all=20 >of them,=20 >>> > it should be possible to avoid the connectivity matrices >>advertisement. >>> > >>> > >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > DANIELE CECCARELLI >>> > System & Technology - PDU Optical & Metro >>> > >>> > Via E.Melen, 77 >>> > Genova, Italy >>> > Phone +390106002512 >>> > Mobile +393346725750 >>> > daniele.ceccarelli@ericsson.com >>> > www.ericsson.com >>> > >>> > This Communication is Confidential. We only send and=20 >receive email=20 >>> > on the basis of the term set out at=20 >>> > www.ericsson.com/email_disclaimer >>> > >>> > _______________________________________________ >>> > CCAMP mailing list >>> > CCAMP@ietf.org >>> > https://www.ietf.org/mailman/listinfo/ccamp >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >= From IBryskin@advaoptical.com Thu Jan 17 08:23:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B138B21F877A for ; Thu, 17 Jan 2013 08:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 wY+DPwQOHlsf for ; Thu, 17 Jan 2013 08:23:34 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 509D221F8778 for ; Thu, 17 Jan 2013 08:23:33 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0HGNS7K008713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 17:23:28 +0100 Received: from MUC-SRV-MBX2.advaoptical.com (172.20.1.96) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 17 Jan 2013 17:23:28 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 17 Jan 2013 17:23:15 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Thu, 17 Jan 2013 11:23:13 -0500 From: Igor Bryskin To: Daniele Ceccarelli , Snigdho Bardalai , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAOJ5ugAAF4jxAAC1ZqcAAgY/iAAAnZVHD//8bogIAAUn/A Date: Thu, 17 Jan 2013 16:23:12 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-17_06:2013-01-17, 2013-01-17, 1970-01-01 signatures=0 Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:23:36 -0000 Daniele, What I was saying is that the definition: > 3. Virtual Topology: Virtual topology is a collection of one or more=20 > virtual or real provider network domain nodes that exist in the=20 > customer layer network and are interconnected via 0 or more virtual=20 > links. Is not correct. It should say IMO: 3. Virtual Topology: Virtual topology is a collection of one or more=20 virtual nodes, supported by one or more provider network domains, which exi= st in the customer layer network and are interconnected via 0 or more vir= tual links, supported by one or more provider network domains -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]=20 Sent: Thursday, January 17, 2013 11:10 AM To: Igor Bryskin; Snigdho Bardalai; CCAMP Subject: RE: Overlay model framework v2 What you say is more than true but orthogonal to my point :-) It's only a matter of terminology. We defined: > 3. Virtual Topology: Virtual topology is a collection of one or more=20 > virtual or real provider network domain nodes that exist in the=20 > customer layer network and are interconnected via 0 or more virtual=20 > links. If we call it "Virtual Topology", the first thing that comes to the minds i= s: its only a collection of virtual links and virtual nodes. Snigdho's proposal was to call it differently so to better identify the fac= t that it includes both virtual and real links/nodes, that's it. The name he proposed, however, is again misleading, because calling it "pro= vider topology" makes me (and you) thinking of just real links/nodes, doesn= 't it? I would suggest not to use either of the terms as both are misleading. Mayb= e something like "exported topology", "CE-PE tology" or whatever. Daniele=20 >-----Original Message----- >From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >Sent: gioved=EC 17 gennaio 2013 16.29 >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >Daniele, > >We want to separate a Virtual Topology advertised to the clients (which=20 >is, generally speaking, different for different sets of clients) from=20 >provider real topology, which must be concealed from the clients. >I disagree with Snigdho, when he is saying that a PE just has multiple=20 >aliases (one from each client name space). There is much more to this.=20 >The way I see it a PE contributes differently to different Virtual=20 >Topologies (each time with a different ID, sometimes as a whole,=20 >sometimes as split into several VNs, sometimes as a part of a large VN,=20 >possibly with a separate connectivity matrix. it also, depending on=20 >Virtual Topology, presents itself as switch of a different layer=20 >network, and so forth). Therefore, PE in the context of Virtual=20 >Topology is always a Virtual Node, even when it is mapped 1:1 onto real=20 >provider switch. In general, only VN can terminate a VL. > >Igor > >-----Original Message----- >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >Sent: Thursday, January 17, 2013 9:53 AM >To: Snigdho Bardalai; Igor Bryskin; CCAMP >Subject: RE: Overlay model framework v2 > >Igor, Snigdho, > >I agree with Snigdho. Why don't we call it provider topology=20 >(or whatever) if it includes both virtual links/nodes and real=20 >links/nodes? I don't think it has anything to deal with naming space. > >Further replies in line > >I'd like to have feedbacks from you and all on Open Issue 4.=20 >That's an advertisement models draft issue but it's something=20 >that i can't really understand yet. > >BR >Daniele > >>-----Original Message----- >>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >>Sent: gioved=EC 17 gennaio 2013 5.28 >>To: Igor Bryskin; Daniele Ceccarelli; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Hi Igor, >> >>Not sure if the case you are citing qualifies a real node or=20 >link to be=20 >>called virtual. The client space name is simply an alias. >> >>Regards >>Snigdho >> >>> -----Original Message----- >>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>> Sent: Wednesday, January 16, 2013 3:04 PM >>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >>> Subject: RE: Overlay model framework v2 >>>=20 >>> Snigdho, >>>=20 >>> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >>> > more virtual or real provider network domain nodes that exist in=20 >>> > the customer layer network and are interconnected via 0 or more=20 >>> > virtual links. >>>=20 >>> [SCB] Since the topology advertised by the provider network can=20 >>> contain real or virtual elements, why do we call it "virtual=20 >>> topology"? Should it simply be called "provider topology"? And then=20 >>> specify that it may contain both virtual or real elements. >>>=20 >>> Virtual topology includes only virtual nodes. Even when we are=20 >>> considering real PEs terminating VLs, we must treat the PEs in the=20 >>> context of Virtual Topology as VNs since they must be named=20 >from the=20 >>> client naming space. >>>=20 >>> Igor >>>=20 >>>=20 >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>On Behalf >>> Of Snigdho Bardalai >>> Sent: Wednesday, January 16, 2013 5:48 PM >>> To: Daniele Ceccarelli; CCAMP >>> Subject: Re: [CCAMP] Overlay model framework v2 >>>=20 >>> Hi Daniele, >>>=20 >>> A few comments. Please see in-line. >>>=20 >>> Thanks >>> Snigdho >>>=20 >>> > -----Original Message----- >>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf >>> > Of Daniele Ceccarelli >>> > Sent: Wednesday, January 16, 2013 7:33 AM >>> > To: CCAMP >>> > Subject: [CCAMP] Overlay model framework v2 >>> > >>> > Dear overlayers, >>> > >>> > Please find below a new version (v2) of the framework summary=20 >>> > reflecting the latest discussions. Again i hope i've captured all=20 >>> > the comments around, sorry if anything is missing, in case >>just let >>> > me know what i missed. >>> > >>> > BR >>> > Daniele >>> > >>> > >>> > + Disclaimer: >>> > 1. Packet opto integration is often considered but the >>work can be >>> > extented to any type of SC. Eg. TDM over LSC. >>> > >>> > + Terminology: >>> > 1. Virtual Link: A virtual link is a potential path between two=20 >>> > virtual or real network elements in a provider layer=20 >network that >>> is >>> > maintained/controlled in and by the provider domain=20 >control plane=20 >>> > (and as such cannot transport any traffic/data and protected from=20 >>> > being >>> > de-provisioned) and which can be instantiated in the data plane=20 >>> > (and then can carry/transport/forward traffic/data) preserving=20 >>> > previously advertised attributes such as fate sharing=20 >information. >>> > 2. Virtual Node: Virtual node is a collection of zero or more=20 >>> > provider network domain nodes that are collectively >>represented to >>> > the clients as a single node that exists in the customer layer=20 >>> > network and is capable of terminating of access, inter-domain and >>> virtual links. >>>=20 >>> [SCB] Agree with Igor's comment - a virtual node can be a >>combination >>> of multiple nodes or a part of the single node, but to the customer=20 >>> node this is transparent. > >Yes, agree. > >>>=20 >>> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >>> > more virtual or real provider network domain nodes that exist in=20 >>> > the customer layer network and are interconnected via 0 or more=20 >>> > virtual links. >>>=20 >>> [SCB] Since the topology advertised by the provider network can=20 >>> contain real or virtual elements, why do we call it "virtual=20 >>> topology"? Should it simply be called "provider topology"? And then=20 >>> specify that it may contain both virtual or real elements. > >See above > >>>=20 >>> > 4. Overlay topology: is a superset of virtual=20 >topologies provided >>> by >>> > each of provider network domains, access and inter-domain links. >>>=20 >>> [SCB] A more concise definition for the overlay topology is >>- CE nodes >>> + Access-links + provider topology as advertised by the provider >>> network. > >We wanted to include also the possiblity of having multiple=20 >provider domains. > >>>=20 >>> > 5. Access Link: Link between OC and OE. GMPLS runs on >>that link. It >>> > can support any of the SCs supported by the GMPLS. >>> > 6. CE (customer Edge): Something like the CN in RFC4208 >>teminology >>> > but (i) receiving virtual topology from the provider network and=20 >>> > requesting the set up of one of them or >>> > (ii) requesting the computation and establishment of a path=20 >>> > accordingly to given constraints in the provider network and=20 >>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >>> > 7. PE (provider Edge): Something like the EN in RFC4208 >>but able to >>> > deal with (i) and (ii) above. >>> > 8. PE-CE interface (former ONI) : Interface allowing for >>signaling >>> > and routing messages exchange between customer overlay >>and provider >>> > network. Routing information consists on virtual topology=20 >>> > advertisement. When there is no routing adjacency across the >>> interface >>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling=20 >>> > messages are compliant with RFC4208. Information related to path=20 >>> > carachteristics, e.g. TE-metrics, collected SRLG, path=20 >delay etc,=20 >>> > either passed from CE to PE via signaling after the LSP=20 >>> > establishment in the core network or from CE to PE to be used as=20 >>> > path computation constraints, fall under the definition of=20 >>> > signaling info and not routing info). >>> > 9. CE-CE (former O-NNI): Interface on the links between=20 >different=20 >>> > provider networks in the overlay model environment. Same=20 >features=20 >>> > of the CE-PE apply to this interface. >>>=20 >>> [SCB] Is this "PE-PE" instead of "CE-CE"? > >Oooops! Definitely. > >>>=20 >>> > >>> > + Statements >>> > 1. In the context of overlay model we are aiming to build an=20 >>> > overlay topology for the customer network domains 2.=20 >The overlay=20 >>> > topology >>> is >>> > comprised of: >>> > a) access links (links connecting client NEs to the provider=20 >>> > network domains). >>> > They can be PSC or LSC. >>> > b) inter-domain links (links interconnecting server network >>> > domains) >>> > c) virtual topology provided by the provider network domains. >>> > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a >>> set >>> > of parameters e.g. SRLG, optical impairments, delay etc for each >>> > entry) describing connectivity between access links and virtual >>> links. >>> > 3. In the context of overlay model we manage hierarchy >>of overlay >>> > topologies with overlay/underlay relationships 4. In=20 >the context=20 >>> > of overlay model multi-layering and inter-layer=20 >relationships are=20 >>> > peripheral at best, it is all about horizontal network integration >>> 5. >>> > The overlay model assumes one CP instance for the customer network >>> and >>> > a separate instance for the provider network and in the CE-PE=20 >>> > interface case the provider network also surreptitiously >>> participates >>> > in the customer network by injecting virtual topology=20 >information=20 >>> > into it. >>>=20 >>> [SCB] Specific implementations may or may not have a single=20 >instance=20 >>> for the provider and the overlay. > >Mmm, that's true. It MUST work with two different instances=20 >but no one prevents it to work with a single one. > >>>=20 >>> > 6. L1VPN (and LxVPN) in general is a type of service >>provided over >>> > the CE-PE interface (it falls under the UNI case as no routing=20 >>> > adjacency is in place between CE and PE). >>>=20 >>> > >>> > >>> > + Advertisement models (to be detailed in dedicated >>> > + document/documents) >>> > The CE-PE interface in the overlay model context foresees >>two types >>> > of advertisement models.(names still to be agreed) A.=20 >>Augmented UNI: >>> > The GMPLS UNI is defined in RFC4208 and augmented by a number of=20 >>> > actived draft (references to various drafts to be added). >>> > The Augmented UNI is a particular type of CE-PE interface where=20 >>> > only signaling messages are exchanged between CE and PE.=20 >Messages=20 >>> > from CE to PE can include a set of parameters to be used >>by the PE >>> > as path computation constraints when computing a path in the=20 >>> > provider domain network, while messages from PE to CE can >>include a >>> > set of >>> parameters >>> > qualifying the LSP being established, like for example >>SRLG, delay, >>> > loss etc. >>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >>> > called with the general CE-PE interface term?) allowing the=20 >>> > establishment of signaling and routing adjacency between >>CE and PE. >>> > Routing info passed from PE to CE comprise overlay topology=20 >>> > information including (but not limited to) virtual links,=20 >>> > connectivity matrices and access links with parameters qualifying >>> each >>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=20 >>> > information >>> and procedures are compliant with RFC4208. >>> > >>> > + Open issues/questions >>> > 1. PCE-PCEP - do we need to include considerations about PCE and >>> PCEP >>> > into the overlay framework context? >>>=20 >>> [SCB] IMO - this should be described in the overlay >>framework document >>> to establish the context. > >+1 > >>>=20 >>> > 2. BGP-LS needs to be considered >>> > 3. Should potentials be included? E.g. I2RS? >>> > 4. Virtual links: wouldn't a different definition of >>virtual links >>> > avoid the advertisement of connectivity matrices (this is >>out of the >>> > fwk scope but within the advertisement models one)? >>> > Take this example: >>> > PE1-----CE1 CE2-----PE2 >>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>> > i.e. There are 2 VL connecting CE1 and CE2 that could be available >>> for >>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1=20 >>> > and/or >>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>> > depending on the connectivity matrices of CE1 and CE2. Hence PEs=20 >>> > need to be aware of both VL and connectivity matrices. My >>point is:=20 >>> > if CE1 advertises to PE1 only the VL that his connectivity matrix=20 >>> > allows to be connected to PE1 (e.g. VL1 only) and not all=20 >of them,=20 >>> > it should be possible to avoid the connectivity matrices >>advertisement. >>> > >>> > >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > DANIELE CECCARELLI >>> > System & Technology - PDU Optical & Metro >>> > >>> > Via E.Melen, 77 >>> > Genova, Italy >>> > Phone +390106002512 >>> > Mobile +393346725750 >>> > daniele.ceccarelli@ericsson.com >>> > www.ericsson.com >>> > >>> > This Communication is Confidential. We only send and=20 >receive email=20 >>> > on the basis of the term set out at=20 >>> > www.ericsson.com/email_disclaimer >>> > >>> > _______________________________________________ >>> > CCAMP mailing list >>> > CCAMP@ietf.org >>> > https://www.ietf.org/mailman/listinfo/ccamp >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> > From vishnupavan@gmail.com Thu Jan 17 08:24:05 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A23621F856D for ; Thu, 17 Jan 2013 08:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 sL9IsEzEQvXG for ; Thu, 17 Jan 2013 08:24:01 -0800 (PST) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7B121F8792 for ; Thu, 17 Jan 2013 08:24:00 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id jc3so1458791bkc.7 for ; Thu, 17 Jan 2013 08:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LYIWKOHtadUl+0kblls7llyx8Kfg0CnUfBvpGC50xD0=; b=Sc7bw+p0I16M2AVspIXgpsPvAKDkJ6JRTPlWn3+G8pHgFU2sC4Dxboyb3HcgHArmvW srIeqOQ6LeY30qrpTEaDqw9FHcFx9Thuo7y5AX4UhqhU6mpQIQ5LoCNJFmqLsk4sOScQ 179QKVUdPnuo9sGeHJbPmIYrSK3dmXn+istUTmTL3tTBRQT9GHE1jr8I4faxfAoP954M oZZzBHf6IuRHC4lDYhst494RGCxXIuDl9MDMJfPQT0Uw3MX4FdkFzbjSJEac8Xh8QN4Y /TSivRDRf0WQ6EODfRiyWpOMCI1w/O3o2NvaVV2M4NxnZMAsoY82z/rGb38oeFNppd1H wnFw== MIME-Version: 1.0 X-Received: by 10.204.7.145 with SMTP id d17mr1708385bkd.84.1358439839604; Thu, 17 Jan 2013 08:23:59 -0800 (PST) Received: by 10.204.170.139 with HTTP; Thu, 17 Jan 2013 08:23:59 -0800 (PST) In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> Date: Thu, 17 Jan 2013 11:23:59 -0500 Message-ID: From: Vishnu Pavan Beeram To: Daniele Ceccarelli Content-Type: multipart/alternative; boundary=0015175885ea16a0d504d37e6cbc Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:24:05 -0000 --0015175885ea16a0d504d37e6cbc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniele, Hi! >> What you say is more than true but orthogonal to my point :-) I'm not sure what is orthogonal to your point. I was trying to make 2 points. - One was with respect to the "Virtual Topology" definition and I think we are more or less in sync with that. - The second point (example) was an attempt (guess I failed) to address your open-issue-4. I guess you would need to elaborate a bit more on that issue. I don't see how you can change the definition of the VL to avoid advertising the "connectivity constraints". Regards, -Pavan > It's only a matter of terminology. We defined: > > > 3. Virtual Topology: Virtual topology is a collection of one or > > more virtual or real provider network domain nodes that exist in > > the customer layer network and are interconnected via 0 or more > > virtual links. > > If we call it "Virtual Topology", the first thing that comes to the minds > is: its only a collection of virtual links and virtual nodes. > Snigdho's proposal was to call it differently so to better identify the > fact that it includes both virtual and real links/nodes, that's it. > The name he proposed, however, is again misleading, because calling it > "provider topology" makes me (and you) thinking of just real links/nodes, > doesn't it? > > I would suggest not to use either of the terms as both are misleading. > Maybe something like "exported topology", "CE-PE tology" or whatever. > > Daniele > > >-----Original Message----- > >From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >Sent: gioved=EC 17 gennaio 2013 16.29 > >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP > >Subject: RE: Overlay model framework v2 > > > >Daniele, > > > >We want to separate a Virtual Topology advertised to the > >clients (which is, generally speaking, different for different > >sets of clients) from provider real topology, which must be > >concealed from the clients. > >I disagree with Snigdho, when he is saying that a PE just has > >multiple aliases (one from each client name space). There is > >much more to this. The way I see it a PE contributes > >differently to different Virtual Topologies (each time with a > >different ID, sometimes as a whole, sometimes as split into > >several VNs, sometimes as a part of a large VN, possibly with > >a separate connectivity matrix. it also, depending on Virtual > >Topology, presents itself as switch of a different layer > >network, and so forth). Therefore, PE in the context of > >Virtual Topology is always a Virtual Node, even when it is > >mapped 1:1 onto real provider switch. In general, only VN can > >terminate a VL. > > > >Igor > > > >-----Original Message----- > >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > >Sent: Thursday, January 17, 2013 9:53 AM > >To: Snigdho Bardalai; Igor Bryskin; CCAMP > >Subject: RE: Overlay model framework v2 > > > >Igor, Snigdho, > > > >I agree with Snigdho. Why don't we call it provider topology > >(or whatever) if it includes both virtual links/nodes and real > >links/nodes? I don't think it has anything to deal with naming space. > > > >Further replies in line > > > >I'd like to have feedbacks from you and all on Open Issue 4. > >That's an advertisement models draft issue but it's something > >that i can't really understand yet. > > > >BR > >Daniele > > > >>-----Original Message----- > >>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > >>Sent: gioved=EC 17 gennaio 2013 5.28 > >>To: Igor Bryskin; Daniele Ceccarelli; CCAMP > >>Subject: RE: Overlay model framework v2 > >> > >>Hi Igor, > >> > >>Not sure if the case you are citing qualifies a real node or > >link to be > >>called virtual. The client space name is simply an alias. > >> > >>Regards > >>Snigdho > >> > >>> -----Original Message----- > >>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >>> Sent: Wednesday, January 16, 2013 3:04 PM > >>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP > >>> Subject: RE: Overlay model framework v2 > >>> > >>> Snigdho, > >>> > >>> > 3. Virtual Topology: Virtual topology is a collection of one or > >>> > more virtual or real provider network domain nodes that exist in > >>> > the customer layer network and are interconnected via 0 or more > >>> > virtual links. > >>> > >>> [SCB] Since the topology advertised by the provider network can > >>> contain real or virtual elements, why do we call it "virtual > >>> topology"? Should it simply be called "provider topology"? And then > >>> specify that it may contain both virtual or real elements. > >>> > >>> Virtual topology includes only virtual nodes. Even when we are > >>> considering real PEs terminating VLs, we must treat the PEs in the > >>> context of Virtual Topology as VNs since they must be named > >from the > >>> client naming space. > >>> > >>> Igor > >>> > >>> > >>> -----Original Message----- > >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > >>On Behalf > >>> Of Snigdho Bardalai > >>> Sent: Wednesday, January 16, 2013 5:48 PM > >>> To: Daniele Ceccarelli; CCAMP > >>> Subject: Re: [CCAMP] Overlay model framework v2 > >>> > >>> Hi Daniele, > >>> > >>> A few comments. Please see in-line. > >>> > >>> Thanks > >>> Snigdho > >>> > >>> > -----Original Message----- > >>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >>> Behalf > >>> > Of Daniele Ceccarelli > >>> > Sent: Wednesday, January 16, 2013 7:33 AM > >>> > To: CCAMP > >>> > Subject: [CCAMP] Overlay model framework v2 > >>> > > >>> > Dear overlayers, > >>> > > >>> > Please find below a new version (v2) of the framework summary > >>> > reflecting the latest discussions. Again i hope i've captured all > >>> > the comments around, sorry if anything is missing, in case > >>just let > >>> > me know what i missed. > >>> > > >>> > BR > >>> > Daniele > >>> > > >>> > > >>> > + Disclaimer: > >>> > 1. Packet opto integration is often considered but the > >>work can be > >>> > extented to any type of SC. Eg. TDM over LSC. > >>> > > >>> > + Terminology: > >>> > 1. Virtual Link: A virtual link is a potential path between two > >>> > virtual or real network elements in a provider layer > >network that > >>> is > >>> > maintained/controlled in and by the provider domain > >control plane > >>> > (and as such cannot transport any traffic/data and protected from > >>> > being > >>> > de-provisioned) and which can be instantiated in the data plane > >>> > (and then can carry/transport/forward traffic/data) preserving > >>> > previously advertised attributes such as fate sharing > >information. > >>> > 2. Virtual Node: Virtual node is a collection of zero or more > >>> > provider network domain nodes that are collectively > >>represented to > >>> > the clients as a single node that exists in the customer layer > >>> > network and is capable of terminating of access, inter-domain and > >>> virtual links. > >>> > >>> [SCB] Agree with Igor's comment - a virtual node can be a > >>combination > >>> of multiple nodes or a part of the single node, but to the customer > >>> node this is transparent. > > > >Yes, agree. > > > >>> > >>> > 3. Virtual Topology: Virtual topology is a collection of one or > >>> > more virtual or real provider network domain nodes that exist in > >>> > the customer layer network and are interconnected via 0 or more > >>> > virtual links. > >>> > >>> [SCB] Since the topology advertised by the provider network can > >>> contain real or virtual elements, why do we call it "virtual > >>> topology"? Should it simply be called "provider topology"? And then > >>> specify that it may contain both virtual or real elements. > > > >See above > > > >>> > >>> > 4. Overlay topology: is a superset of virtual > >topologies provided > >>> by > >>> > each of provider network domains, access and inter-domain links. > >>> > >>> [SCB] A more concise definition for the overlay topology is > >>- CE nodes > >>> + Access-links + provider topology as advertised by the provider > >>> network. > > > >We wanted to include also the possiblity of having multiple > >provider domains. > > > >>> > >>> > 5. Access Link: Link between OC and OE. GMPLS runs on > >>that link. It > >>> > can support any of the SCs supported by the GMPLS. > >>> > 6. CE (customer Edge): Something like the CN in RFC4208 > >>teminology > >>> > but (i) receiving virtual topology from the provider network and > >>> > requesting the set up of one of them or > >>> > (ii) requesting the computation and establishment of a path > >>> > accordingly to given constraints in the provider network and > >>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. > >>> > 7. PE (provider Edge): Something like the EN in RFC4208 > >>but able to > >>> > deal with (i) and (ii) above. > >>> > 8. PE-CE interface (former ONI) : Interface allowing for > >>signaling > >>> > and routing messages exchange between customer overlay > >>and provider > >>> > network. Routing information consists on virtual topology > >>> > advertisement. When there is no routing adjacency across the > >>> interface > >>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling > >>> > messages are compliant with RFC4208. Information related to path > >>> > carachteristics, e.g. TE-metrics, collected SRLG, path > >delay etc, > >>> > either passed from CE to PE via signaling after the LSP > >>> > establishment in the core network or from CE to PE to be used as > >>> > path computation constraints, fall under the definition of > >>> > signaling info and not routing info). > >>> > 9. CE-CE (former O-NNI): Interface on the links between > >different > >>> > provider networks in the overlay model environment. Same > >features > >>> > of the CE-PE apply to this interface. > >>> > >>> [SCB] Is this "PE-PE" instead of "CE-CE"? > > > >Oooops! Definitely. > > > >>> > >>> > > >>> > + Statements > >>> > 1. In the context of overlay model we are aiming to build an > >>> > overlay topology for the customer network domains 2. > >The overlay > >>> > topology > >>> is > >>> > comprised of: > >>> > a) access links (links connecting client NEs to the provider > >>> > network domains). > >>> > They can be PSC or LSC. > >>> > b) inter-domain links (links interconnecting server network > >>> > domains) > >>> > c) virtual topology provided by the provider network domains. > >>> > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a > >>> set > >>> > of parameters e.g. SRLG, optical impairments, delay etc for each > >>> > entry) describing connectivity between access links and virtual > >>> links. > >>> > 3. In the context of overlay model we manage hierarchy > >>of overlay > >>> > topologies with overlay/underlay relationships 4. In > >the context > >>> > of overlay model multi-layering and inter-layer > >relationships are > >>> > peripheral at best, it is all about horizontal network integration > >>> 5. > >>> > The overlay model assumes one CP instance for the customer network > >>> and > >>> > a separate instance for the provider network and in the CE-PE > >>> > interface case the provider network also surreptitiously > >>> participates > >>> > in the customer network by injecting virtual topology > >information > >>> > into it. > >>> > >>> [SCB] Specific implementations may or may not have a single > >instance > >>> for the provider and the overlay. > > > >Mmm, that's true. It MUST work with two different instances > >but no one prevents it to work with a single one. > > > >>> > >>> > 6. L1VPN (and LxVPN) in general is a type of service > >>provided over > >>> > the CE-PE interface (it falls under the UNI case as no routing > >>> > adjacency is in place between CE and PE). > >>> > >>> > > >>> > > >>> > + Advertisement models (to be detailed in dedicated > >>> > + document/documents) > >>> > The CE-PE interface in the overlay model context foresees > >>two types > >>> > of advertisement models.(names still to be agreed) A. > >>Augmented UNI: > >>> > The GMPLS UNI is defined in RFC4208 and augmented by a number of > >>> > actived draft (references to various drafts to be added). > >>> > The Augmented UNI is a particular type of CE-PE interface where > >>> > only signaling messages are exchanged between CE and PE. > >Messages > >>> > from CE to PE can include a set of parameters to be used > >>by the PE > >>> > as path computation constraints when computing a path in the > >>> > provider domain network, while messages from PE to CE can > >>include a > >>> > set of > >>> parameters > >>> > qualifying the LSP being established, like for example > >>SRLG, delay, > >>> > loss etc. > >>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply > >>> > called with the general CE-PE interface term?) allowing the > >>> > establishment of signaling and routing adjacency between > >>CE and PE. > >>> > Routing info passed from PE to CE comprise overlay topology > >>> > information including (but not limited to) virtual links, > >>> > connectivity matrices and access links with parameters qualifying > >>> each > >>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling > >>> > information > >>> and procedures are compliant with RFC4208. > >>> > > >>> > + Open issues/questions > >>> > 1. PCE-PCEP - do we need to include considerations about PCE and > >>> PCEP > >>> > into the overlay framework context? > >>> > >>> [SCB] IMO - this should be described in the overlay > >>framework document > >>> to establish the context. > > > >+1 > > > >>> > >>> > 2. BGP-LS needs to be considered > >>> > 3. Should potentials be included? E.g. I2RS? > >>> > 4. Virtual links: wouldn't a different definition of > >>virtual links > >>> > avoid the advertisement of connectivity matrices (this is > >>out of the > >>> > fwk scope but within the advertisement models one)? > >>> > Take this example: > >>> > PE1-----CE1 CE2-----PE2 > >>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 > >>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 > >>> > i.e. There are 2 VL connecting CE1 and CE2 that could be available > >>> for > >>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1 > >>> > and/or > >>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only > >>> > depending on the connectivity matrices of CE1 and CE2. Hence PEs > >>> > need to be aware of both VL and connectivity matrices. My > >>point is: > >>> > if CE1 advertises to PE1 only the VL that his connectivity matrix > >>> > allows to be connected to PE1 (e.g. VL1 only) and not all > >of them, > >>> > it should be possible to avoid the connectivity matrices > >>advertisement. > >>> > > >>> > > >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > DANIELE CECCARELLI > >>> > System & Technology - PDU Optical & Metro > >>> > > >>> > Via E.Melen, 77 > >>> > Genova, Italy > >>> > Phone +390106002512 > >>> > Mobile +393346725750 > >>> > daniele.ceccarelli@ericsson.com > >>> > www.ericsson.com > >>> > > >>> > This Communication is Confidential. We only send and > >receive email > >>> > on the basis of the term set out at > >>> > www.ericsson.com/email_disclaimer > >>> > > >>> > _______________________________________________ > >>> > CCAMP mailing list > >>> > CCAMP@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/ccamp > >>> _______________________________________________ > >>> CCAMP mailing list > >>> CCAMP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ccamp > >> > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --0015175885ea16a0d504d37e6cbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Daniele, Hi!


>> What you say is more than true but orthogonal to = my point :-)

I'm not sure what is orthogonal to your point.=A0
I was trying to make 2 points.=A0
- One was with respect to the "Virtual Topology"= ; definition and I think we are more or less in sync with that.=A0
- The second point (example) was an attempt (guess I failed) to address you= r open-issue-4. I guess you would need to elaborate a bit more on that issu= e. I don't see how you can change the definition of the VL to avoid adv= ertising the "connectivity constraints".

Regards,
-Pavan


It's only a matter of terminology. We defined:

> =A03. Virtual Topology: Virtual topology is a collection of one or
> more virtual or real provider =A0network domain nodes that exist in > the customer layer network and are interconnected =A0via 0 or more
> virtual links.

If we call it "Virtual Topology", the first thing that come= s to the minds is: its only a collection of virtual links and virtual nodes= .
Snigdho's proposal was to call it differently so to better identify the= fact that it includes both virtual and real links/nodes, that's it. The name he proposed, however, is again misleading, because calling it &quo= t;provider topology" makes me (and you) thinking of just real links/no= des, doesn't it?

I would suggest not to use either of the terms as both are misleading. Mayb= e something like "exported topology", "CE-PE tology" or= whatever.

Daniele

>-----Original Message-----
>From: Igor Bryskin [mailto:= IBryskin@advaoptical.com]
>Sent: gioved=EC 17 gennai= o 2013 16.29
>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP
>Subject: RE: Overlay model framework v2
>
>Daniele,
>
>We want to separate a Virtual Topology advertised to the
>clients (which is, generally speaking, different for different
>sets of clients) from provider real topology, which must be
>concealed from the clients.
>I disagree with Snigdho, when he is saying that a PE just has
>multiple aliases (one from each client name space). There is
>much more to this. The way I see it a PE contributes
>differently to different Virtual Topologies (each time with a
>different ID, sometimes as a whole, sometimes as split into
>several VNs, sometimes as a part of a large VN, possibly with
>a separate connectivity matrix. it also, depending on Virtual
>Topology, presents itself as switch of a different layer
>network, and so forth). Therefore, PE in the context of
>Virtual Topology is always a Virtual Node, even when it is
>mapped 1:1 onto real provider switch. In general, only VN can
>terminate a VL.
>
>Igor
>
>-----Original Message-----
>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
>Sent: Thursday, January 17, 2013 9:53 AM
>To: Snigdho Bardalai; Igor Bryskin; CCAMP
>Subject: RE: Overlay model framework v2
>
>Igor, Snigdho,
>
>I agree with Snigdho. Why don't we call it provider topology
>(or whatever) if it includes both virtual links/nodes and real
>links/nodes? I don't think it has anything to deal with naming spac= e.
>
>Further replies in line
>
>I'd like to have feedbacks from you and all on Open Issue 4.
>That's an advertisement models draft issue but it's something >that i can't really understand yet.
>
>BR
>Daniele
>
>>-----Original Message-----
>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com]
>>Sent: gioved=EC 17 gennaio 2013 5.28
>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP
>>Subject: RE: Overlay model framework v2
>>
>>Hi Igor,
>>
>>Not sure if the case you are citing qualifies a real node or
>link to be
>>called virtual. The client space name is simply an alias.
>>
>>Regards
>>Snigdho
>>
>>> -----Original Message-----
>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
>>> Sent: Wednesday, January 16, 2013 3:04 PM
>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP
>>> Subject: RE: Overlay model framework v2
>>>
>>> Snigdho,
>>>
>>> > =A03. Virtual Topology: Virtual topology is a collection = of one or
>>> > more virtual or real provider =A0network domain nodes tha= t exist in
>>> > the customer layer network and are interconnected =A0via = 0 or more
>>> > virtual links.
>>>
>>> [SCB] Since the topology advertised by the provider network ca= n
>>> contain real or virtual elements, why do we call it "virt= ual
>>> topology"? Should it simply be called "provider topo= logy"? And then
>>> specify that it may contain both virtual or real elements.
>>>
>>> Virtual topology includes only virtual nodes. Even when we are=
>>> considering real PEs terminating VLs, we must treat the PEs in= the
>>> context of Virtual Topology as VNs since they must be named >from the
>>> client naming space.
>>>
>>> Igor
>>>
>>>
>>> -----Original Message-----
>>> From: ccamp-bounces@= ietf.org [mailto:ccamp-bounce= s@ietf.org]
>>On Behalf
>>> Of Snigdho Bardalai
>>> Sent: Wednesday, January 16, 2013 5:48 PM
>>> To: Daniele Ceccarelli; CCAMP
>>> Subject: Re: [CCAMP] Overlay model framework v2
>>>
>>> Hi Daniele,
>>>
>>> A few comments. Please see in-line.
>>>
>>> Thanks
>>> Snigdho
>>>
>>> > -----Original Message-----
>>> > From: ccamp-bou= nces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On
>>> Behalf
>>> > Of Daniele Ceccarelli
>>> > Sent: Wednesday, January 16, 2013 7:33 AM
>>> > To: CCAMP
>>> > Subject: [CCAMP] Overlay model framework v2
>>> >
>>> > Dear overlayers,
>>> >
>>> > Please find below a new version (v2) of the framework sum= mary
>>> > reflecting the latest discussions. Again i hope i've = captured all
>>> > the comments around, sorry if anything is missing, in cas= e
>>just let
>>> > me know what i missed.
>>> >
>>> > BR
>>> > Daniele
>>> >
>>> >
>>> > + Disclaimer:
>>> > =A01. Packet opto integration is often considered but the=
>>work can be
>>> > extented to any type of SC. Eg. TDM over LSC.
>>> >
>>> > + Terminology:
>>> > =A01. Virtual Link: A virtual link is a potential path be= tween two
>>> > virtual or real network =A0elements in a provider layer >network =A0that
>>> is
>>> > maintained/controlled in and by the provider =A0domain >control plane
>>> > (and as such cannot transport any traffic/data and protec= ted from
>>> > being
>>> > =A0de-provisioned) and which can be instantiated in the d= ata plane
>>> > (and then can =A0carry/transport/forward traffic/data) pr= eserving
>>> > previously advertised attributes such as =A0fate sharing<= br> >information.
>>> > =A02. =A0Virtual Node: Virtual node is a collection of ze= ro or more
>>> > provider network domain =A0nodes that are collectively >>represented to
>>> > the clients as a single node that =A0exists in the custom= er layer
>>> > network and is capable of terminating of access, =A0inter= -domain and
>>> virtual links.
>>>
>>> [SCB] Agree with Igor's comment - a virtual node can be a<= br> >>combination
>>> of multiple nodes or a part of the single node, but to the cus= tomer
>>> node this is transparent.
>
>Yes, agree.
>
>>>
>>> > =A03. Virtual Topology: Virtual topology is a collection = of one or
>>> > more virtual or real provider =A0network domain nodes tha= t exist in
>>> > the customer layer network and are interconnected =A0via = 0 or more
>>> > virtual links.
>>>
>>> [SCB] Since the topology advertised by the provider network ca= n
>>> contain real or virtual elements, why do we call it "virt= ual
>>> topology"? Should it simply be called "provider topo= logy"? And then
>>> specify that it may contain both virtual or real elements.
>
>See above
>
>>>
>>> > =A04. Overlay topology: =A0is a superset of virtual
>topologies provided
>>> by
>>> > each of =A0provider network domains, access and inter-dom= ain links.
>>>
>>> [SCB] A more concise definition for the overlay topology is >>- CE nodes
>>> + Access-links + provider topology as advertised by the provid= er
>>> network.
>
>We wanted to include also the possiblity of having multiple
>provider domains.
>
>>>
>>> > =A05. Access Link: Link between OC and OE. GMPLS runs on<= br> >>that link. It
>>> > can support =A0any of the SCs supported by the GMPLS.
>>> > =A06. CE (customer Edge): Something like the CN in RFC420= 8
>>teminology
>>> > but (i) receiving =A0virtual topology from the provider n= etwork and
>>> > requesting the set up of one of them or
>>> > =A0(ii) requesting the computation and establishment of a= path
>>> > accordingly to given constraints =A0in the provider netwo= rk and
>>> > receiving the parameters characterizing such path. (ii) = =3D=3D UNI.
>>> > =A07. PE (provider Edge): Something like the EN in RFC420= 8
>>but able to
>>> > deal with (i) and (ii) above.
>>> > =A08. PE-CE interface (former ONI) : Interface allowing f= or
>>signaling
>>> > and routing messages =A0exchange between customer overlay=
>>and provider
>>> > network. Routing information consists on =A0virtual topol= ogy
>>> > advertisement. When there is no routing adjacency across = the
>>> interface
>>> > it is equivalent to the GMPLS UNI defined in 4208. Signal= ing
>>> > messages are compliant with =A0RFC4208. Information relat= ed to path
>>> > carachteristics, e.g. TE-metrics, collected SRLG, =A0path=
>delay etc,
>>> > either passed from CE to PE via signaling after the LSP >>> > establishment in the core network or from CE to PE to be = used as
>>> > path computation constraints, fall =A0under the definitio= n of
>>> > signaling info and not routing info).
>>> > =A09. CE-CE (former O-NNI): Interface on the links betwee= n
>different
>>> > provider networks =A0in the overlay model environment. Sa= me
>features
>>> > of the CE-PE apply to this interface.
>>>
>>> [SCB] Is this "PE-PE" instead of "CE-CE"?<= br> >
>Oooops! Definitely.
>
>>>
>>> >
>>> > + Statements
>>> > =A01. In the context of overlay model we are aiming to bu= ild an
>>> > overlay topology for =A0the customer network domains =A02= .
>The overlay
>>> > topology
>>> is
>>> > comprised of:
>>> > =A0 =A0 a) access links (links connecting client NEs to t= he provider
>>> > network domains).
>>> > =A0They can be PSC or LSC.
>>> > =A0 =A0 b) inter-domain links (links interconnecting serv= er network
>>> > domains)
>>> > =A0 =A0 c) virtual topology provided by the provider netw= ork domains.
>>> > Virtual Links =A0+ Virtual Nodes (TBD) + Connectivity Mat= rix (with a
>>> set
>>> > of parameters e.g. SRLG, =A0optical impairments, delay et= c for each
>>> > entry) describing connectivity between access links and v= irtual
>>> links.
>>> > =A03. In the context of overlay model we manage =A0hierar= chy
>>of overlay
>>> > topologies =A0with overlay/underlay relationships =A04. I= n
>the context
>>> > of overlay model multi-layering and inter-layer
>relationships =A0are
>>> > peripheral at best, it is all about horizontal network in= tegration
>>> 5.
>>> > The overlay model assumes one CP instance for the custome= r network
>>> and
>>> > a separate =A0instance for the provider network and in th= e CE-PE
>>> > interface case the provider =A0network also surreptitious= ly
>>> participates
>>> > in the customer network by injecting =A0virtual topology<= br> >information
>>> > into it.
>>>
>>> [SCB] Specific implementations may or may not have a single >instance
>>> for the provider and the overlay.
>
>Mmm, that's true. It MUST work with two different instances
>but no one prevents it to work with a single one.
>
>>>
>>> > =A06. L1VPN (and LxVPN) in general is a type of service >>provided over
>>> > the CE-PE interface =A0(it falls under the UNI case as no= routing
>>> > adjacency is in place between CE and PE).
>>>
>>> >
>>> >
>>> > + Advertisement models (to be detailed in dedicated
>>> > + document/documents)
>>> > =A0The CE-PE interface in the overlay model context fores= ees
>>two types
>>> > of advertisement =A0models.(names still to be agreed) A.<= br> >>Augmented UNI:
>>> > The GMPLS UNI is defined in RFC4208 and augmented by =A0a= number of
>>> > actived draft (references to various drafts to be added).=
>>> > =A0The Augmented UNI is a particular type of CE-PE interf= ace where
>>> > only signaling messages =A0are exchanged between CE and P= E.
>Messages
>>> > from CE to PE can include =A0a set of parameters to be us= ed
>>by the PE
>>> > as path computation constraints =A0when computing a path = in the
>>> > provider domain network, while messages from PE =A0to CE = can
>>include a
>>> > set of
>>> parameters
>>> > qualifying the LSP being established, =A0like for example=
>>SRLG, delay,
>>> > loss etc.
>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be= simply
>>> > called with the =A0general CE-PE interface term?) allowin= g the
>>> > establishment of signaling and routing adjacency =A0betwe= en
>>CE and PE.
>>> > Routing info passed from PE to CE comprise overlay topolo= gy
>>> > information including =A0(but not limited to) virtual lin= ks,
>>> > connectivity matrices and access links with parameters qu= alifying
>>> each
>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=
>>> > information
>>> and procedures are =A0compliant with RFC4208.
>>> >
>>> > + Open issues/questions
>>> > =A01. PCE-PCEP - do we need to include considerations abo= ut PCE and
>>> PCEP
>>> > into the overlay framework context?
>>>
>>> [SCB] IMO - this should be described in the overlay
>>framework document
>>> to establish the context.
>
>+1
>
>>>
>>> > =A02. BGP-LS needs to be considered
>>> > =A03. Should potentials be included? E.g. I2RS?
>>> > =A04. Virtual links: wouldn't a different definition = of
>>virtual links
>>> > avoid the advertisement of connectivity matrices (this is=
>>out of the
>>> > fwk scope but within the advertisement models one)?
>>> > Take this example:
>>> > PE1-----CE1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CE2-----PE2
>>> > =A0 =A0 =A0 =A0 CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D= =3DCE2
>>> > =A0 =A0 =A0 =A0 CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D= =3DCE2
>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be = available
>>> for
>>> > PE1 and PE2 to set up an adjacency in the customer domain= . CE1
>>> > and/or
>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available= only
>>> > depending on the connectivity matrices of CE1 and CE2. He= nce PEs
>>> > need to be aware of both VL and connectivity matrices. My=
>>point is:
>>> > if CE1 advertises to PE1 only the VL that his connectivit= y matrix
>>> > allows to be connected to PE1 (e.g. VL1 only) and not all=
>of them,
>>> > it should be possible to avoid the connectivity matrices<= br> >>advertisement.
>>> >
>>> >
>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> > DANIELE CECCARELLI
>>> > System & Technology - PDU Optical & Metro
>>> >
>>> > Via E.Melen, 77
>>> > Genova, Italy
>>> > Phone +390106002512
>>> > Mobile +393346725750
>>> > daniel= e.ceccarelli@ericsson.com
>>> > www= .ericsson.com
>>> >
>>> > This Communication is Confidential. We only send and
>receive email
>>> > on the basis of the term set out at
>>> > www.ericsson.com/email_disclaimer
>>> >
>>> > _______________________________________________
>>> > CCAMP mailing list
>>> > CCAMP@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/ccamp
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--0015175885ea16a0d504d37e6cbc-- From vishnupavan@gmail.com Thu Jan 17 08:30:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5561221F8783 for ; Thu, 17 Jan 2013 08:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 r6AjGcArnFxi for ; Thu, 17 Jan 2013 08:30:53 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id 82D2F21F872E for ; Thu, 17 Jan 2013 08:30:52 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id ji2so1505149bkc.1 for ; Thu, 17 Jan 2013 08:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xVt9JuV8A72SQBsZLhib9VUOTD3CtbSgHJCUVlNskV4=; b=iLeSKifPnXzJXGGpdBL4pk6/mmIBIzEzSXXAIZoj4H78+HQPhD0bQEL4zx3AIiWP3n nOXJonMhzfQ3AcU9tHq+iBD4wKqR30PbXQAAb3mvm4RSU3Mgn5F+QE5gBOrHuPcWbFaX mao0GLOlwwB1Np6uW7sbx9yfdJW6QVxNcA6yUnXWZZmL2nDWYLyDauMFxWexF7YU0bhV xuUxH5RhVu8BrRDvbfp78mBYLywYhh28+6n+fTMzwDMMHtqAUkQM3XyscQohqzdkrUxG g5cpMuBWAA/gVawGMPj3VXZ9lnMAHaNv38C5FyvsCPNlkeG5+8xu1HVTcRzVWpC0f2OE WTag== MIME-Version: 1.0 X-Received: by 10.204.7.92 with SMTP id c28mr1687620bkc.86.1358440251506; Thu, 17 Jan 2013 08:30:51 -0800 (PST) Received: by 10.204.170.139 with HTTP; Thu, 17 Jan 2013 08:30:51 -0800 (PST) In-Reply-To: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> Date: Thu, 17 Jan 2013 11:30:51 -0500 Message-ID: From: Vishnu Pavan Beeram To: Daniele Ceccarelli Content-Type: multipart/alternative; boundary=00151758858ca3bfae04d37e845e Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:30:55 -0000 --00151758858ca3bfae04d37e845e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniele, Just realized that your previous response was directed to Igor :) Ignore my last email.. -Pavan On Thu, Jan 17, 2013 at 11:23 AM, Vishnu Pavan Beeram wrote: > Daniele, Hi! > > > >> What you say is more than true but orthogonal to my point :-) > > I'm not sure what is orthogonal to your point. > I was trying to make 2 points. > - One was with respect to the "Virtual Topology" definition and I think w= e > are more or less in sync with that. > - The second point (example) was an attempt (guess I failed) to address > your open-issue-4. I guess you would need to elaborate a bit more on that > issue. I don't see how you can change the definition of the VL to avoid > advertising the "connectivity constraints". > > Regards, > -Pavan > > >> It's only a matter of terminology. We defined: >> >> > 3. Virtual Topology: Virtual topology is a collection of one or >> > more virtual or real provider network domain nodes that exist in >> > the customer layer network and are interconnected via 0 or more >> > virtual links. >> >> If we call it "Virtual Topology", the first thing that comes to the mind= s >> is: its only a collection of virtual links and virtual nodes. >> Snigdho's proposal was to call it differently so to better identify the >> fact that it includes both virtual and real links/nodes, that's it. >> The name he proposed, however, is again misleading, because calling it >> "provider topology" makes me (and you) thinking of just real links/nodes= , >> doesn't it? >> >> I would suggest not to use either of the terms as both are misleading. >> Maybe something like "exported topology", "CE-PE tology" or whatever. >> >> Daniele >> >> >-----Original Message----- >> >From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >> >Sent: gioved=EC 17 gennaio 2013 16.29 >> >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >> >Subject: RE: Overlay model framework v2 >> > >> >Daniele, >> > >> >We want to separate a Virtual Topology advertised to the >> >clients (which is, generally speaking, different for different >> >sets of clients) from provider real topology, which must be >> >concealed from the clients. >> >I disagree with Snigdho, when he is saying that a PE just has >> >multiple aliases (one from each client name space). There is >> >much more to this. The way I see it a PE contributes >> >differently to different Virtual Topologies (each time with a >> >different ID, sometimes as a whole, sometimes as split into >> >several VNs, sometimes as a part of a large VN, possibly with >> >a separate connectivity matrix. it also, depending on Virtual >> >Topology, presents itself as switch of a different layer >> >network, and so forth). Therefore, PE in the context of >> >Virtual Topology is always a Virtual Node, even when it is >> >mapped 1:1 onto real provider switch. In general, only VN can >> >terminate a VL. >> > >> >Igor >> > >> >-----Original Message----- >> >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >> >Sent: Thursday, January 17, 2013 9:53 AM >> >To: Snigdho Bardalai; Igor Bryskin; CCAMP >> >Subject: RE: Overlay model framework v2 >> > >> >Igor, Snigdho, >> > >> >I agree with Snigdho. Why don't we call it provider topology >> >(or whatever) if it includes both virtual links/nodes and real >> >links/nodes? I don't think it has anything to deal with naming space. >> > >> >Further replies in line >> > >> >I'd like to have feedbacks from you and all on Open Issue 4. >> >That's an advertisement models draft issue but it's something >> >that i can't really understand yet. >> > >> >BR >> >Daniele >> > >> >>-----Original Message----- >> >>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >> >>Sent: gioved=EC 17 gennaio 2013 5.28 >> >>To: Igor Bryskin; Daniele Ceccarelli; CCAMP >> >>Subject: RE: Overlay model framework v2 >> >> >> >>Hi Igor, >> >> >> >>Not sure if the case you are citing qualifies a real node or >> >link to be >> >>called virtual. The client space name is simply an alias. >> >> >> >>Regards >> >>Snigdho >> >> >> >>> -----Original Message----- >> >>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >> >>> Sent: Wednesday, January 16, 2013 3:04 PM >> >>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >> >>> Subject: RE: Overlay model framework v2 >> >>> >> >>> Snigdho, >> >>> >> >>> > 3. Virtual Topology: Virtual topology is a collection of one or >> >>> > more virtual or real provider network domain nodes that exist in >> >>> > the customer layer network and are interconnected via 0 or more >> >>> > virtual links. >> >>> >> >>> [SCB] Since the topology advertised by the provider network can >> >>> contain real or virtual elements, why do we call it "virtual >> >>> topology"? Should it simply be called "provider topology"? And then >> >>> specify that it may contain both virtual or real elements. >> >>> >> >>> Virtual topology includes only virtual nodes. Even when we are >> >>> considering real PEs terminating VLs, we must treat the PEs in the >> >>> context of Virtual Topology as VNs since they must be named >> >from the >> >>> client naming space. >> >>> >> >>> Igor >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >> >>On Behalf >> >>> Of Snigdho Bardalai >> >>> Sent: Wednesday, January 16, 2013 5:48 PM >> >>> To: Daniele Ceccarelli; CCAMP >> >>> Subject: Re: [CCAMP] Overlay model framework v2 >> >>> >> >>> Hi Daniele, >> >>> >> >>> A few comments. Please see in-line. >> >>> >> >>> Thanks >> >>> Snigdho >> >>> >> >>> > -----Original Message----- >> >>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> >>> Behalf >> >>> > Of Daniele Ceccarelli >> >>> > Sent: Wednesday, January 16, 2013 7:33 AM >> >>> > To: CCAMP >> >>> > Subject: [CCAMP] Overlay model framework v2 >> >>> > >> >>> > Dear overlayers, >> >>> > >> >>> > Please find below a new version (v2) of the framework summary >> >>> > reflecting the latest discussions. Again i hope i've captured all >> >>> > the comments around, sorry if anything is missing, in case >> >>just let >> >>> > me know what i missed. >> >>> > >> >>> > BR >> >>> > Daniele >> >>> > >> >>> > >> >>> > + Disclaimer: >> >>> > 1. Packet opto integration is often considered but the >> >>work can be >> >>> > extented to any type of SC. Eg. TDM over LSC. >> >>> > >> >>> > + Terminology: >> >>> > 1. Virtual Link: A virtual link is a potential path between two >> >>> > virtual or real network elements in a provider layer >> >network that >> >>> is >> >>> > maintained/controlled in and by the provider domain >> >control plane >> >>> > (and as such cannot transport any traffic/data and protected from >> >>> > being >> >>> > de-provisioned) and which can be instantiated in the data plane >> >>> > (and then can carry/transport/forward traffic/data) preserving >> >>> > previously advertised attributes such as fate sharing >> >information. >> >>> > 2. Virtual Node: Virtual node is a collection of zero or more >> >>> > provider network domain nodes that are collectively >> >>represented to >> >>> > the clients as a single node that exists in the customer layer >> >>> > network and is capable of terminating of access, inter-domain and >> >>> virtual links. >> >>> >> >>> [SCB] Agree with Igor's comment - a virtual node can be a >> >>combination >> >>> of multiple nodes or a part of the single node, but to the customer >> >>> node this is transparent. >> > >> >Yes, agree. >> > >> >>> >> >>> > 3. Virtual Topology: Virtual topology is a collection of one or >> >>> > more virtual or real provider network domain nodes that exist in >> >>> > the customer layer network and are interconnected via 0 or more >> >>> > virtual links. >> >>> >> >>> [SCB] Since the topology advertised by the provider network can >> >>> contain real or virtual elements, why do we call it "virtual >> >>> topology"? Should it simply be called "provider topology"? And then >> >>> specify that it may contain both virtual or real elements. >> > >> >See above >> > >> >>> >> >>> > 4. Overlay topology: is a superset of virtual >> >topologies provided >> >>> by >> >>> > each of provider network domains, access and inter-domain links. >> >>> >> >>> [SCB] A more concise definition for the overlay topology is >> >>- CE nodes >> >>> + Access-links + provider topology as advertised by the provider >> >>> network. >> > >> >We wanted to include also the possiblity of having multiple >> >provider domains. >> > >> >>> >> >>> > 5. Access Link: Link between OC and OE. GMPLS runs on >> >>that link. It >> >>> > can support any of the SCs supported by the GMPLS. >> >>> > 6. CE (customer Edge): Something like the CN in RFC4208 >> >>teminology >> >>> > but (i) receiving virtual topology from the provider network and >> >>> > requesting the set up of one of them or >> >>> > (ii) requesting the computation and establishment of a path >> >>> > accordingly to given constraints in the provider network and >> >>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI= . >> >>> > 7. PE (provider Edge): Something like the EN in RFC4208 >> >>but able to >> >>> > deal with (i) and (ii) above. >> >>> > 8. PE-CE interface (former ONI) : Interface allowing for >> >>signaling >> >>> > and routing messages exchange between customer overlay >> >>and provider >> >>> > network. Routing information consists on virtual topology >> >>> > advertisement. When there is no routing adjacency across the >> >>> interface >> >>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling >> >>> > messages are compliant with RFC4208. Information related to path >> >>> > carachteristics, e.g. TE-metrics, collected SRLG, path >> >delay etc, >> >>> > either passed from CE to PE via signaling after the LSP >> >>> > establishment in the core network or from CE to PE to be used as >> >>> > path computation constraints, fall under the definition of >> >>> > signaling info and not routing info). >> >>> > 9. CE-CE (former O-NNI): Interface on the links between >> >different >> >>> > provider networks in the overlay model environment. Same >> >features >> >>> > of the CE-PE apply to this interface. >> >>> >> >>> [SCB] Is this "PE-PE" instead of "CE-CE"? >> > >> >Oooops! Definitely. >> > >> >>> >> >>> > >> >>> > + Statements >> >>> > 1. In the context of overlay model we are aiming to build an >> >>> > overlay topology for the customer network domains 2. >> >The overlay >> >>> > topology >> >>> is >> >>> > comprised of: >> >>> > a) access links (links connecting client NEs to the provider >> >>> > network domains). >> >>> > They can be PSC or LSC. >> >>> > b) inter-domain links (links interconnecting server network >> >>> > domains) >> >>> > c) virtual topology provided by the provider network domains. >> >>> > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a >> >>> set >> >>> > of parameters e.g. SRLG, optical impairments, delay etc for each >> >>> > entry) describing connectivity between access links and virtual >> >>> links. >> >>> > 3. In the context of overlay model we manage hierarchy >> >>of overlay >> >>> > topologies with overlay/underlay relationships 4. In >> >the context >> >>> > of overlay model multi-layering and inter-layer >> >relationships are >> >>> > peripheral at best, it is all about horizontal network integration >> >>> 5. >> >>> > The overlay model assumes one CP instance for the customer network >> >>> and >> >>> > a separate instance for the provider network and in the CE-PE >> >>> > interface case the provider network also surreptitiously >> >>> participates >> >>> > in the customer network by injecting virtual topology >> >information >> >>> > into it. >> >>> >> >>> [SCB] Specific implementations may or may not have a single >> >instance >> >>> for the provider and the overlay. >> > >> >Mmm, that's true. It MUST work with two different instances >> >but no one prevents it to work with a single one. >> > >> >>> >> >>> > 6. L1VPN (and LxVPN) in general is a type of service >> >>provided over >> >>> > the CE-PE interface (it falls under the UNI case as no routing >> >>> > adjacency is in place between CE and PE). >> >>> >> >>> > >> >>> > >> >>> > + Advertisement models (to be detailed in dedicated >> >>> > + document/documents) >> >>> > The CE-PE interface in the overlay model context foresees >> >>two types >> >>> > of advertisement models.(names still to be agreed) A. >> >>Augmented UNI: >> >>> > The GMPLS UNI is defined in RFC4208 and augmented by a number of >> >>> > actived draft (references to various drafts to be added). >> >>> > The Augmented UNI is a particular type of CE-PE interface where >> >>> > only signaling messages are exchanged between CE and PE. >> >Messages >> >>> > from CE to PE can include a set of parameters to be used >> >>by the PE >> >>> > as path computation constraints when computing a path in the >> >>> > provider domain network, while messages from PE to CE can >> >>include a >> >>> > set of >> >>> parameters >> >>> > qualifying the LSP being established, like for example >> >>SRLG, delay, >> >>> > loss etc. >> >>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >> >>> > called with the general CE-PE interface term?) allowing the >> >>> > establishment of signaling and routing adjacency between >> >>CE and PE. >> >>> > Routing info passed from PE to CE comprise overlay topology >> >>> > information including (but not limited to) virtual links, >> >>> > connectivity matrices and access links with parameters qualifying >> >>> each >> >>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling >> >>> > information >> >>> and procedures are compliant with RFC4208. >> >>> > >> >>> > + Open issues/questions >> >>> > 1. PCE-PCEP - do we need to include considerations about PCE and >> >>> PCEP >> >>> > into the overlay framework context? >> >>> >> >>> [SCB] IMO - this should be described in the overlay >> >>framework document >> >>> to establish the context. >> > >> >+1 >> > >> >>> >> >>> > 2. BGP-LS needs to be considered >> >>> > 3. Should potentials be included? E.g. I2RS? >> >>> > 4. Virtual links: wouldn't a different definition of >> >>virtual links >> >>> > avoid the advertisement of connectivity matrices (this is >> >>out of the >> >>> > fwk scope but within the advertisement models one)? >> >>> > Take this example: >> >>> > PE1-----CE1 CE2-----PE2 >> >>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >> >>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >> >>> > i.e. There are 2 VL connecting CE1 and CE2 that could be available >> >>> for >> >>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1 >> >>> > and/or >> >>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only >> >>> > depending on the connectivity matrices of CE1 and CE2. Hence PEs >> >>> > need to be aware of both VL and connectivity matrices. My >> >>point is: >> >>> > if CE1 advertises to PE1 only the VL that his connectivity matrix >> >>> > allows to be connected to PE1 (e.g. VL1 only) and not all >> >of them, >> >>> > it should be possible to avoid the connectivity matrices >> >>advertisement. >> >>> > >> >>> > >> >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>> > DANIELE CECCARELLI >> >>> > System & Technology - PDU Optical & Metro >> >>> > >> >>> > Via E.Melen, 77 >> >>> > Genova, Italy >> >>> > Phone +390106002512 >> >>> > Mobile +393346725750 >> >>> > daniele.ceccarelli@ericsson.com >> >>> > www.ericsson.com >> >>> > >> >>> > This Communication is Confidential. We only send and >> >receive email >> >>> > on the basis of the term set out at >> >>> > www.ericsson.com/email_disclaimer >> >>> > >> >>> > _______________________________________________ >> >>> > CCAMP mailing list >> >>> > CCAMP@ietf.org >> >>> > https://www.ietf.org/mailman/listinfo/ccamp >> >>> _______________________________________________ >> >>> CCAMP mailing list >> >>> CCAMP@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> > >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > > --00151758858ca3bfae04d37e845e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Daniele,=A0
Just realized that your previous response = was directed to Igor :)=A0

Ignore my last email..<= /div>
-Pavan

=
On Thu, Jan 17, 2013 at 11:23 AM, Vishnu Pavan Beeram <= ;vishnupavan@gma= il.com> wrote:
Daniele, Hi!
<= br>
>> What you say is more than true b= ut orthogonal to my point :-)

I'm not sure what is orthogonal to your point.=A0
I was trying to make 2 points.=A0
- One was with respect to the "Virtual Topology"= ; definition and I think we are more or less in sync with that.=A0
- The second point (example) was an attempt (guess I failed) to address you= r open-issue-4. I guess you would need to elaborate a bit more on that issu= e. I don't see how you can change the definition of the VL to avoid adv= ertising the "connectivity constraints".

Regards,
-Pavan


It's only a matter of terminology. We defined:

> =A03. Virtual Topology: Virtual topology is a collection of one or
> more virtual or real provider =A0network domain nodes that exist in > the customer layer network and are interconnected =A0via 0 or more
> virtual links.

If we call it "Virtual Topology", the first thing that come= s to the minds is: its only a collection of virtual links and virtual nodes= .
Snigdho's proposal was to call it differently so to better identify the= fact that it includes both virtual and real links/nodes, that's it. The name he proposed, however, is again misleading, because calling it &quo= t;provider topology" makes me (and you) thinking of just real links/no= des, doesn't it?

I would suggest not to use either of the terms as both are misleading. Mayb= e something like "exported topology", "CE-PE tology" or= whatever.

Daniele

>-----Original Message-----
>From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
>Sent: gioved=EC 17 gennaio 2013 16.29
>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP
>Subject: RE: Overlay model framework v2
>
>Daniele,
>
>We want to separate a Virtual Topology advertised to the
>clients (which is, generally speaking, different for different
>sets of clients) from provider real topology, which must be
>concealed from the clients.
>I disagree with Snigdho, when he is saying that a PE just has
>multiple aliases (one from each client name space). There is
>much more to this. The way I see it a PE contributes
>differently to different Virtual Topologies (each time with a
>different ID, sometimes as a whole, sometimes as split into
>several VNs, sometimes as a part of a large VN, possibly with
>a separate connectivity matrix. it also, depending on Virtual
>Topology, presents itself as switch of a different layer
>network, and so forth). Therefore, PE in the context of
>Virtual Topology is always a Virtual Node, even when it is
>mapped 1:1 onto real provider switch. In general, only VN can
>terminate a VL.
>
>Igor
>
>-----Original Message-----
>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
>Sent: Thursday, January 17, 2013 9:53 AM
>To: Snigdho Bardalai; Igor Bryskin; CCAMP
>Subject: RE: Overlay model framework v2
>
>Igor, Snigdho,
>
>I agree with Snigdho. Why don't we call it provider topology
>(or whatever) if it includes both virtual links/nodes and real
>links/nodes? I don't think it has anything to deal with naming spac= e.
>
>Further replies in line
>
>I'd like to have feedbacks from you and all on Open Issue 4.
>That's an advertisement models draft issue but it's something >that i can't really understand yet.
>
>BR
>Daniele
>
>>-----Original Message-----
>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com]
>>Sent: gioved=EC 17 gennaio 2013 5.28
>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP
>>Subject: RE: Overlay model framework v2
>>
>>Hi Igor,
>>
>>Not sure if the case you are citing qualifies a real node or
>link to be
>>called virtual. The client space name is simply an alias.
>>
>>Regards
>>Snigdho
>>
>>> -----Original Message-----
>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
>>> Sent: Wednesday, January 16, 2013 3:04 PM
>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP
>>> Subject: RE: Overlay model framework v2
>>>
>>> Snigdho,
>>>
>>> > =A03. Virtual Topology: Virtual topology is a collection = of one or
>>> > more virtual or real provider =A0network domain nodes tha= t exist in
>>> > the customer layer network and are interconnected =A0via = 0 or more
>>> > virtual links.
>>>
>>> [SCB] Since the topology advertised by the provider network ca= n
>>> contain real or virtual elements, why do we call it "virt= ual
>>> topology"? Should it simply be called "provider topo= logy"? And then
>>> specify that it may contain both virtual or real elements.
>>>
>>> Virtual topology includes only virtual nodes. Even when we are=
>>> considering real PEs terminating VLs, we must treat the PEs in= the
>>> context of Virtual Topology as VNs since they must be named >from the
>>> client naming space.
>>>
>>> Igor
>>>
>>>
>>> -----Original Message-----
>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
>>On Behalf
>>> Of Snigdho Bardalai
>>> Sent: Wednesday, January 16, 2013 5:48 PM
>>> To: Daniele Ceccarelli; CCAMP
>>> Subject: Re: [CCAMP] Overlay model framework v2
>>>
>>> Hi Daniele,
>>>
>>> A few comments. Please see in-line.
>>>
>>> Thanks
>>> Snigdho
>>>
>>> > -----Original Message-----
>>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>> Behalf
>>> > Of Daniele Ceccarelli
>>> > Sent: Wednesday, January 16, 2013 7:33 AM
>>> > To: CCAMP
>>> > Subject: [CCAMP] Overlay model framework v2
>>> >
>>> > Dear overlayers,
>>> >
>>> > Please find below a new version (v2) of the framework sum= mary
>>> > reflecting the latest discussions. Again i hope i've = captured all
>>> > the comments around, sorry if anything is missing, in cas= e
>>just let
>>> > me know what i missed.
>>> >
>>> > BR
>>> > Daniele
>>> >
>>> >
>>> > + Disclaimer:
>>> > =A01. Packet opto integration is often considered but the=
>>work can be
>>> > extented to any type of SC. Eg. TDM over LSC.
>>> >
>>> > + Terminology:
>>> > =A01. Virtual Link: A virtual link is a potential path be= tween two
>>> > virtual or real network =A0elements in a provider layer >network =A0that
>>> is
>>> > maintained/controlled in and by the provider =A0domain >control plane
>>> > (and as such cannot transport any traffic/data and protec= ted from
>>> > being
>>> > =A0de-provisioned) and which can be instantiated in the d= ata plane
>>> > (and then can =A0carry/transport/forward traffic/data) pr= eserving
>>> > previously advertised attributes such as =A0fate sharing<= br> >information.
>>> > =A02. =A0Virtual Node: Virtual node is a collection of ze= ro or more
>>> > provider network domain =A0nodes that are collectively >>represented to
>>> > the clients as a single node that =A0exists in the custom= er layer
>>> > network and is capable of terminating of access, =A0inter= -domain and
>>> virtual links.
>>>
>>> [SCB] Agree with Igor's comment - a virtual node can be a<= br> >>combination
>>> of multiple nodes or a part of the single node, but to the cus= tomer
>>> node this is transparent.
>
>Yes, agree.
>
>>>
>>> > =A03. Virtual Topology: Virtual topology is a collection = of one or
>>> > more virtual or real provider =A0network domain nodes tha= t exist in
>>> > the customer layer network and are interconnected =A0via = 0 or more
>>> > virtual links.
>>>
>>> [SCB] Since the topology advertised by the provider network ca= n
>>> contain real or virtual elements, why do we call it "virt= ual
>>> topology"? Should it simply be called "provider topo= logy"? And then
>>> specify that it may contain both virtual or real elements.
>
>See above
>
>>>
>>> > =A04. Overlay topology: =A0is a superset of virtual
>topologies provided
>>> by
>>> > each of =A0provider network domains, access and inter-dom= ain links.
>>>
>>> [SCB] A more concise definition for the overlay topology is >>- CE nodes
>>> + Access-links + provider topology as advertised by the provid= er
>>> network.
>
>We wanted to include also the possiblity of having multiple
>provider domains.
>
>>>
>>> > =A05. Access Link: Link between OC and OE. GMPLS runs on<= br> >>that link. It
>>> > can support =A0any of the SCs supported by the GMPLS.
>>> > =A06. CE (customer Edge): Something like the CN in RFC420= 8
>>teminology
>>> > but (i) receiving =A0virtual topology from the provider n= etwork and
>>> > requesting the set up of one of them or
>>> > =A0(ii) requesting the computation and establishment of a= path
>>> > accordingly to given constraints =A0in the provider netwo= rk and
>>> > receiving the parameters characterizing such path. (ii) = =3D=3D UNI.
>>> > =A07. PE (provider Edge): Something like the EN in RFC420= 8
>>but able to
>>> > deal with (i) and (ii) above.
>>> > =A08. PE-CE interface (former ONI) : Interface allowing f= or
>>signaling
>>> > and routing messages =A0exchange between customer overlay=
>>and provider
>>> > network. Routing information consists on =A0virtual topol= ogy
>>> > advertisement. When there is no routing adjacency across = the
>>> interface
>>> > it is equivalent to the GMPLS UNI defined in 4208. Signal= ing
>>> > messages are compliant with =A0RFC4208. Information relat= ed to path
>>> > carachteristics, e.g. TE-metrics, collected SRLG, =A0path=
>delay etc,
>>> > either passed from CE to PE via signaling after the LSP >>> > establishment in the core network or from CE to PE to be = used as
>>> > path computation constraints, fall =A0under the definitio= n of
>>> > signaling info and not routing info).
>>> > =A09. CE-CE (former O-NNI): Interface on the links betwee= n
>different
>>> > provider networks =A0in the overlay model environment. Sa= me
>features
>>> > of the CE-PE apply to this interface.
>>>
>>> [SCB] Is this "PE-PE" instead of "CE-CE"?<= br> >
>Oooops! Definitely.
>
>>>
>>> >
>>> > + Statements
>>> > =A01. In the context of overlay model we are aiming to bu= ild an
>>> > overlay topology for =A0the customer network domains =A02= .
>The overlay
>>> > topology
>>> is
>>> > comprised of:
>>> > =A0 =A0 a) access links (links connecting client NEs to t= he provider
>>> > network domains).
>>> > =A0They can be PSC or LSC.
>>> > =A0 =A0 b) inter-domain links (links interconnecting serv= er network
>>> > domains)
>>> > =A0 =A0 c) virtual topology provided by the provider netw= ork domains.
>>> > Virtual Links =A0+ Virtual Nodes (TBD) + Connectivity Mat= rix (with a
>>> set
>>> > of parameters e.g. SRLG, =A0optical impairments, delay et= c for each
>>> > entry) describing connectivity between access links and v= irtual
>>> links.
>>> > =A03. In the context of overlay model we manage =A0hierar= chy
>>of overlay
>>> > topologies =A0with overlay/underlay relationships =A04. I= n
>the context
>>> > of overlay model multi-layering and inter-layer
>relationships =A0are
>>> > peripheral at best, it is all about horizontal network in= tegration
>>> 5.
>>> > The overlay model assumes one CP instance for the custome= r network
>>> and
>>> > a separate =A0instance for the provider network and in th= e CE-PE
>>> > interface case the provider =A0network also surreptitious= ly
>>> participates
>>> > in the customer network by injecting =A0virtual topology<= br> >information
>>> > into it.
>>>
>>> [SCB] Specific implementations may or may not have a single >instance
>>> for the provider and the overlay.
>
>Mmm, that's true. It MUST work with two different instances
>but no one prevents it to work with a single one.
>
>>>
>>> > =A06. L1VPN (and LxVPN) in general is a type of service >>provided over
>>> > the CE-PE interface =A0(it falls under the UNI case as no= routing
>>> > adjacency is in place between CE and PE).
>>>
>>> >
>>> >
>>> > + Advertisement models (to be detailed in dedicated
>>> > + document/documents)
>>> > =A0The CE-PE interface in the overlay model context fores= ees
>>two types
>>> > of advertisement =A0models.(names still to be agreed) A.<= br> >>Augmented UNI:
>>> > The GMPLS UNI is defined in RFC4208 and augmented by =A0a= number of
>>> > actived draft (references to various drafts to be added).=
>>> > =A0The Augmented UNI is a particular type of CE-PE interf= ace where
>>> > only signaling messages =A0are exchanged between CE and P= E.
>Messages
>>> > from CE to PE can include =A0a set of parameters to be us= ed
>>by the PE
>>> > as path computation constraints =A0when computing a path = in the
>>> > provider domain network, while messages from PE =A0to CE = can
>>include a
>>> > set of
>>> parameters
>>> > qualifying the LSP being established, =A0like for example=
>>SRLG, delay,
>>> > loss etc.
>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be= simply
>>> > called with the =A0general CE-PE interface term?) allowin= g the
>>> > establishment of signaling and routing adjacency =A0betwe= en
>>CE and PE.
>>> > Routing info passed from PE to CE comprise overlay topolo= gy
>>> > information including =A0(but not limited to) virtual lin= ks,
>>> > connectivity matrices and access links with parameters qu= alifying
>>> each
>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=
>>> > information
>>> and procedures are =A0compliant with RFC4208.
>>> >
>>> > + Open issues/questions
>>> > =A01. PCE-PCEP - do we need to include considerations abo= ut PCE and
>>> PCEP
>>> > into the overlay framework context?
>>>
>>> [SCB] IMO - this should be described in the overlay
>>framework document
>>> to establish the context.
>
>+1
>
>>>
>>> > =A02. BGP-LS needs to be considered
>>> > =A03. Should potentials be included? E.g. I2RS?
>>> > =A04. Virtual links: wouldn't a different definition = of
>>virtual links
>>> > avoid the advertisement of connectivity matrices (this is=
>>out of the
>>> > fwk scope but within the advertisement models one)?
>>> > Take this example:
>>> > PE1-----CE1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CE2-----PE2
>>> > =A0 =A0 =A0 =A0 CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D= =3DCE2
>>> > =A0 =A0 =A0 =A0 CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D= =3DCE2
>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be = available
>>> for
>>> > PE1 and PE2 to set up an adjacency in the customer domain= . CE1
>>> > and/or
>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available= only
>>> > depending on the connectivity matrices of CE1 and CE2. He= nce PEs
>>> > need to be aware of both VL and connectivity matrices. My=
>>point is:
>>> > if CE1 advertises to PE1 only the VL that his connectivit= y matrix
>>> > allows to be connected to PE1 (e.g. VL1 only) and not all=
>of them,
>>> > it should be possible to avoid the connectivity matrices<= br> >>advertisement.
>>> >
>>> >
>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> > DANIELE CECCARELLI
>>> > System & Technology - PDU Optical & Metro
>>> >
>>> > Via E.Melen, 77
>>> > Genova, Italy
>>> > Phone +390106002512
>>> > Mobile +393346725750
>>> > daniele.ceccarelli@ericsson.com
>>> > www= .ericsson.com
>>> >
>>> > This Communication is Confidential. We only send and
>receive email
>>> > on the basis of the term set out at
>>> > www.ericsson.com/email_disclaimer
>>> >
>>> > _______________________________________________
>>> > CCAMP mailing list
>>> > CCAMP= @ietf.org
>>> > https://www.ietf.org/mailman/listinfo/ccamp
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp


--00151758858ca3bfae04d37e845e-- From daniele.ceccarelli@ericsson.com Thu Jan 17 08:32:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D385C21F8783 for ; Thu, 17 Jan 2013 08:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 X5QvobEkp1af for ; Thu, 17 Jan 2013 08:32:28 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A514521F872E for ; Thu, 17 Jan 2013 08:32:27 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-14-50f8279ad6c2 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E0.A6.10459.A9728F05; Thu, 17 Jan 2013 17:32:26 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 17:32:26 +0100 From: Daniele Ceccarelli To: Vishnu Pavan Beeram Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRwFLO6lqWmk6S/LNDTw8InAANE4iAAACVKQAAC1BWgAAXfYXgAAD8bIAAAk2+IA== Date: Thu, 17 Jan 2013 16:32:25 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806CCE8@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4806CCE8ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje4s9R8BBqfmKls8mXODxeJUTzuj xa7+f4wWc9qeMDuweJxd8IfVY+esu+weS5b8ZPK49OIQWwBLFJdNSmpOZllqkb5dAlfGqj/W BTt2MVW0fOxmaWDc18rUxcjJISFgIvHn0QU2CFtM4sK99UA2F4eQwCFGiU/3fjBDOIsZJSbM e8PexcjBwSZgJfHkkA9Ig4iAvsSHz3MYQWxmgQKJ2+2dYIOEgeK/bs9jhqgxkJix5RMbhB0m Mf3fBDCbRUBV4vyEc2A2r4C3xOrpt1kgdm1hlrgyfylYglMgUOJc/wZ2EJtRQFZiwu5FUMvE JW49mQ/1gYDEkj3nmSFsUYmXj/+xgtwpIaAosbxfDqI8X6K15wwjxC5BiZMzn7BMYBSdhWTS LCRls5CUQcT1JG5MncIGYWtLLFv4mhnC1pWY8e8QC7L4Akb2VYzsuYmZOenlhpsYgdF3cMtv 3R2Mp86JHGKU5mBREucNc70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRWWVfxuMzTKUF XHF9Lw7ytU+czT3ZSXn153hZi/p4yYZFb6VNC0o0D9dMWFq/Zo4Kg8qtp9FCj7iP2TOKKywt uuA9wS9H5phpy7r7r3dypLssPnv5w5uz+vturZshIc8WnmQ665zttzez8kterSsztL3LI351 g6iD5bQVkurFV1KvMFxZyvJdiaU4I9FQi7moOBEARMwiz4wCAAA= Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:32:30 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE4806CCE8ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pavan, please see in line BR Daniele ________________________________ From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] Sent: gioved=EC 17 gennaio 2013 17.09 To: Daniele Ceccarelli Cc: Snigdho Bardalai; Igor Bryskin; CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Daniele, Hi! I agree with Snigdho. Why don't we call it provider topology (or whatever) = if it includes both virtual links/nodes and real links/nodes? I don't think= it has anything to deal with naming space. I (personally) don't see any confusion with using the term "Virtual Topolog= y" even if the topology includes VNs that represent fractions of a real nod= e. If there are still some strong reservations, I wouldn't want to use the = term "Provider Topology" as the alternative (look for other terms - "Export= ed Provider Topology" (or) "Summarized Provider Topology" or whatever). [[DC]] It has already caused misunderstanding, i would suggest to change an= d agree with you that "provider topology" is an unlucky term. I'd like to have feedbacks from you and all on Open Issue 4. That's an adve= rtisement models draft issue but it's something that i can't really underst= and yet. I think you have "CEs" and "PEs" mixed up in your example. If the notations= are interchanged, your example topology would look like the following: [[DC]] It's the third time a mix them, i'm starting to think it's dyslexia =3D=3D=3D=3DVL1=3D=3D=3D=3D CE1-----PE1 PE2-----CE2 =3D=3D=3D=3DVL2=3D=3D=3D=3D If you have just one access-link between each CE-PE pair, then it might be = ok for the PE node to advertise only the VL(s) that can be switched onto fr= om the single access-link (and hide all other VLs). But consider the case w= here you have more than one access-link between each CE-PE pair as shown be= low. =3D=3DAL1=3D=3D =3D=3D=3D=3DVL1=3D=3D=3D=3D =3D=3DAL3= =3D=3D CE1 PE1 PE2 CE2 =3D=3DAL2=3D=3D =3D=3D=3D=3DVL2=3D=3D=3D=3D =3D=3DAL4= =3D=3D Say the connectivity constraints only allow the paths {AL1, VL2, AL3} and {= AL2, VL1,AL4} to be provisioned. For this particular exported provider topo= logy, advertising the "connectivity constraints" is a MUST. [[DC]] in this case why don't just advertising VL2 on AL1 and AL3 and VL1 o= n AL2 and AL4? But if the provider topology is exported to the client as shown below, ther= e wouldn't be a need to advertise the "connectivity constraints". Each PE n= ode is broken down into 2 Virtual entities. [[DC]] agree, it works, but still don't see why it's more efficient than my= proposal above. =3D=3DAL1=3D=3DVN1=3D=3D=3D=3DVL2=3D=3D=3D=3DVN3=3D=3DAL3=3D=3D CE1 = CE2 =3D=3DAL2=3D=3DVN2=3D=3D=3D=3DVL1=3D=3D=3D=3DVN4=3D=3DAL4=3D=3D The manner in which the provider topology gets exported (operator choice) t= o the client would determine what TE attributes get/don't get advertised. Hope that helps, -Pavan >-----Original Message----- >From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >Sent: gioved=EC 17 gennaio 2013 5.28 >To: Igor Bryskin; Daniele Ceccarelli; CCAMP >Subject: RE: Overlay model framework v2 > >Hi Igor, > >Not sure if the case you are citing qualifies a real node or >link to be called virtual. The client space name is simply an alias. > >Regards >Snigdho > >> -----Original Message----- >> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >> Sent: Wednesday, January 16, 2013 3:04 PM >> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >> Subject: RE: Overlay model framework v2 >> >> Snigdho, >> >> > 3. Virtual Topology: Virtual topology is a collection of one or >> > more virtual or real provider network domain nodes that exist in >> > the customer layer network and are interconnected via 0 or more >> > virtual links. >> >> [SCB] Since the topology advertised by the provider network can >> contain real or virtual elements, why do we call it "virtual >> topology"? Should it simply be called "provider topology"? And then >> specify that it may contain both virtual or real elements. >> >> Virtual topology includes only virtual nodes. Even when we are >> considering real PEs terminating VLs, we must treat the PEs in the >> context of Virtual Topology as VNs since they must be named from the >> client naming space. >> >> Igor >> >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccam= p-bounces@ietf.org] >On Behalf >> Of Snigdho Bardalai >> Sent: Wednesday, January 16, 2013 5:48 PM >> To: Daniele Ceccarelli; CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Hi Daniele, >> >> A few comments. Please see in-line. >> >> Thanks >> Snigdho >> >> > -----Original Message----- >> > From: ccamp-bounces@ietf.org [mailto:cc= amp-bounces@ietf.org] On >> Behalf >> > Of Daniele Ceccarelli >> > Sent: Wednesday, January 16, 2013 7:33 AM >> > To: CCAMP >> > Subject: [CCAMP] Overlay model framework v2 >> > >> > Dear overlayers, >> > >> > Please find below a new version (v2) of the framework summary >> > reflecting the latest discussions. Again i hope i've captured all >> > the comments around, sorry if anything is missing, in case >just let >> > me know what i missed. >> > >> > BR >> > Daniele >> > >> > >> > + Disclaimer: >> > 1. Packet opto integration is often considered but the >work can be >> > extented to any type of SC. Eg. TDM over LSC. >> > >> > + Terminology: >> > 1. Virtual Link: A virtual link is a potential path between two >> > virtual or real network elements in a provider layer network that >> is >> > maintained/controlled in and by the provider domain control plane >> > (and as such cannot transport any traffic/data and protected from >> > being >> > de-provisioned) and which can be instantiated in the data plane >> > (and then can carry/transport/forward traffic/data) preserving >> > previously advertised attributes such as fate sharing information. >> > 2. Virtual Node: Virtual node is a collection of zero or more >> > provider network domain nodes that are collectively >represented to >> > the clients as a single node that exists in the customer layer >> > network and is capable of terminating of access, inter-domain and >> virtual links. >> >> [SCB] Agree with Igor's comment - a virtual node can be a >combination >> of multiple nodes or a part of the single node, but to the customer >> node this is transparent. Yes, agree. >> >> > 3. Virtual Topology: Virtual topology is a collection of one or >> > more virtual or real provider network domain nodes that exist in >> > the customer layer network and are interconnected via 0 or more >> > virtual links. >> >> [SCB] Since the topology advertised by the provider network can >> contain real or virtual elements, why do we call it "virtual >> topology"? Should it simply be called "provider topology"? And then >> specify that it may contain both virtual or real elements. See above >> >> > 4. Overlay topology: is a superset of virtual topologies provided >> by >> > each of provider network domains, access and inter-domain links. >> >> [SCB] A more concise definition for the overlay topology is >- CE nodes >> + Access-links + provider topology as advertised by the provider >> network. We wanted to include also the possiblity of having multiple provider domain= s. >> >> > 5. Access Link: Link between OC and OE. GMPLS runs on >that link. It >> > can support any of the SCs supported by the GMPLS. >> > 6. CE (customer Edge): Something like the CN in RFC4208 >teminology >> > but (i) receiving virtual topology from the provider network and >> > requesting the set up of one of them or >> > (ii) requesting the computation and establishment of a path >> > accordingly to given constraints in the provider network and >> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >> > 7. PE (provider Edge): Something like the EN in RFC4208 >but able to >> > deal with (i) and (ii) above. >> > 8. PE-CE interface (former ONI) : Interface allowing for >signaling >> > and routing messages exchange between customer overlay >and provider >> > network. Routing information consists on virtual topology >> > advertisement. When there is no routing adjacency across the >> interface >> > it is equivalent to the GMPLS UNI defined in 4208. Signaling >> > messages are compliant with RFC4208. Information related to path >> > carachteristics, e.g. TE-metrics, collected SRLG, path delay etc, >> > either passed from CE to PE via signaling after the LSP >> > establishment in the core network or from CE to PE to be used as >> > path computation constraints, fall under the definition of >> > signaling info and not routing info). >> > 9. CE-CE (former O-NNI): Interface on the links between different >> > provider networks in the overlay model environment. Same features >> > of the CE-PE apply to this interface. >> >> [SCB] Is this "PE-PE" instead of "CE-CE"? Oooops! Definitely. >> >> > >> > + Statements >> > 1. In the context of overlay model we are aiming to build an >> > overlay topology for the customer network domains 2. The overlay >> > topology >> is >> > comprised of: >> > a) access links (links connecting client NEs to the provider >> > network domains). >> > They can be PSC or LSC. >> > b) inter-domain links (links interconnecting server network >> > domains) >> > c) virtual topology provided by the provider network domains. >> > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a >> set >> > of parameters e.g. SRLG, optical impairments, delay etc for each >> > entry) describing connectivity between access links and virtual >> links. >> > 3. In the context of overlay model we manage hierarchy >of overlay >> > topologies with overlay/underlay relationships 4. In the context >> > of overlay model multi-layering and inter-layer relationships are >> > peripheral at best, it is all about horizontal network integration >> 5. >> > The overlay model assumes one CP instance for the customer network >> and >> > a separate instance for the provider network and in the CE-PE >> > interface case the provider network also surreptitiously >> participates >> > in the customer network by injecting virtual topology information >> > into it. >> >> [SCB] Specific implementations may or may not have a single instance >> for the provider and the overlay. Mmm, that's true. It MUST work with two different instances but no one prev= ents it to work with a single one. >> >> > 6. L1VPN (and LxVPN) in general is a type of service >provided over >> > the CE-PE interface (it falls under the UNI case as no routing >> > adjacency is in place between CE and PE). >> >> > >> > >> > + Advertisement models (to be detailed in dedicated >> > + document/documents) >> > The CE-PE interface in the overlay model context foresees >two types >> > of advertisement models.(names still to be agreed) A. >Augmented UNI: >> > The GMPLS UNI is defined in RFC4208 and augmented by a number of >> > actived draft (references to various drafts to be added). >> > The Augmented UNI is a particular type of CE-PE interface where >> > only signaling messages are exchanged between CE and PE. Messages >> > from CE to PE can include a set of parameters to be used >by the PE >> > as path computation constraints when computing a path in the >> > provider domain network, while messages from PE to CE can >include a >> > set of >> parameters >> > qualifying the LSP being established, like for example >SRLG, delay, >> > loss etc. >> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >> > called with the general CE-PE interface term?) allowing the >> > establishment of signaling and routing adjacency between >CE and PE. >> > Routing info passed from PE to CE comprise overlay topology >> > information including (but not limited to) virtual links, >> > connectivity matrices and access links with parameters qualifying >> each >> > of them in terms of e.g. SRLG, loss, delay etc. Signaling >> > information >> and procedures are compliant with RFC4208. >> > >> > + Open issues/questions >> > 1. PCE-PCEP - do we need to include considerations about PCE and >> PCEP >> > into the overlay framework context? >> >> [SCB] IMO - this should be described in the overlay >framework document >> to establish the context. +1 >> >> > 2. BGP-LS needs to be considered >> > 3. Should potentials be included? E.g. I2RS? >> > 4. Virtual links: wouldn't a different definition of >virtual links >> > avoid the advertisement of connectivity matrices (this is >out of the >> > fwk scope but within the advertisement models one)? >> > Take this example: >> > PE1-----CE1 CE2-----PE2 >> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >> > i.e. There are 2 VL connecting CE1 and CE2 that could be available >> for >> > PE1 and PE2 to set up an adjacency in the customer domain. CE1 >> > and/or >> > CE2 can be blocking nodes so VL1 and/or VL2 are available only >> > depending on the connectivity matrices of CE1 and CE2. Hence PEs >> > need to be aware of both VL and connectivity matrices. My >point is: >> > if CE1 advertises to PE1 only the VL that his connectivity matrix >> > allows to be connected to PE1 (e.g. VL1 only) and not all of them, >> > it should be possible to avoid the connectivity matrices >advertisement. >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > DANIELE CECCARELLI >> > System & Technology - PDU Optical & Metro >> > >> > Via E.Melen, 77 >> > Genova, Italy >> > Phone +390106002512 >> > Mobile +393346725750 >> > daniele.ceccarelli@ericsson.com >> > www.ericsson.com >> > >> > This Communication is Confidential. We only send and receive email >> > on the basis of the term set out at >> > www.ericsson.com/email_disclaimer >> > >> > _______________________________________________ >> > CCAMP mailing list >> > CCAMP@ietf.org >> > https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_4A1562797D64E44993C5CBF38CF1BE4806CCE8ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Pavan,
 
please see in line<= /div>
 
BR
Daniele

From: Vishnu Pavan Beeram [mailto:v= ishnupavan@gmail.com]
Sent: gioved=EC 17 gennaio 2013 17.09
To: Daniele Ceccarelli
Cc: Snigdho Bardalai; Igor Bryskin; CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Daniele, Hi!


I agree with Snigdho. Why don't we call it provider topology (or whatever) = if it includes both virtual links/nodes and real links/nodes? I don't think= it has anything to deal with naming space.

I (personally) don't see any confusion with using the term "Virtu= al Topology" even if the topology includes VNs that represent fraction= s of a real node. If there are still some strong reservations, I wouldn't w= ant to use the term "Provider Topology" as the alternative (look for other terms - "Exported Provider Topology&q= uot; (or) "Summarized Provider Topology" or whatever).
[[DC]] It has already caused misunderstanding, i would sugge= st to change and agree with you that "provider topology" is an un= lucky term. 
 

I'd like to have feedbacks from you and all on Open Issue 4. That's an adve= rtisement models draft issue but it's something that i can't really underst= and yet.


I think you have "CEs" and "PEs" mixed up in your = example. If the notations are interchanged, your example topology would loo= k like the following:
[[DC]] It's the third time a mix them, i'm&nbs= p;starting to think it's dyslexia  
                    =   =3D=3D=3D=3DVL1=3D=3D=3D=3D
CE1-----PE1                 &n= bsp;       PE2-----CE2
                    =   =3D=3D=3D=3DVL2=3D=3D=3D=3D

If you have just one access-link between each CE-PE pair, then it migh= t be ok for the PE node to advertise only the VL(s) that can be switched on= to from the single access-link (and hide all other VLs). But consider the c= ase where you have more than one access-link between each CE-PE pair as shown below.  

        =3D=3DAL1=3D=3D        = ; =3D=3D=3D=3DVL1=3D=3D=3D=3D       =3D=3DAL3=3D=3D
CE1                 PE1  =                     &nbs= p;  PE2               CE2
        =3D=3DAL2=3D=3D        = ; =3D=3D=3D=3DVL2=3D=3D=3D=3D       =3D=3DAL4=3D=3D

Say the connectivity constraints only allow the paths {AL1, VL2, AL3} = and {AL2, VL1,AL4} to be provisioned. For this particular exported provider= topology, advertising the "connectivity constraints" is a MUST.<= br>
[[DC]] in this case why don't just advertis= ing VL2 on AL1 and AL3 and VL1 on AL2 and AL4?
But if the provider topology is exported to the client as shown below,= there wouldn't be a need to advertise the "connectivity constraints&q= uot;. Each PE node is broken down into 2 Virtual entities.
[[DC]] agree, it works, but still don't see why it's more ef= ficient than my proposal above.

        =3D=3DAL1=3D=3DVN1=3D=3D=3D=3DVL2=3D=3D=3D= =3DVN3=3D=3DAL3=3D=3D
CE1                   &nb= sp;                     &= nbsp;                    =            CE2
        =3D=3DAL2=3D=3DVN2=3D=3D=3D=3DVL1=3D=3D=3D= =3DVN4=3D=3DAL4=3D=3D

The manner in which the provider topology gets exported (operator choi= ce) to the client would determine what TE attributes get/don't get advertis= ed.

Hope that helps,
-Pavan 

>-----Original Message-----
>From: Snigdho Bardalai [mailto:SBardalai@infinera.com]
>Sent: gioved=EC 17 gennaio 2013 5.28
>To: Igor Bryskin; Daniele Ceccarelli; CCAMP
>Subject: RE: Overlay model framework v2
>
>Hi Igor,
>
>Not sure if the case you are citing qualifies a real node or
>link to be called virtual. The client space name is simply an alias. >
>Regards
>Snigdho
>
>> -----Original Message-----
>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
>> Sent: Wednesday, January 16, 2013 3:04 PM
>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP
>> Subject: RE: Overlay model framework v2
>>
>> Snigdho,
>>
>> >  3. Virtual Topology: Virtual topology is a collection o= f one or
>> > more virtual or real provider  network domain nodes that= exist in
>> > the customer layer network and are interconnected  via 0= or more
>> > virtual links.
>>
>> [SCB] Since the topology advertised by the provider network can >> contain real or virtual elements, why do we call it "virtual<= br> >> topology"? Should it simply be called "provider topology= "? And then
>> specify that it may contain both virtual or real elements.
>>
>> Virtual topology includes only virtual nodes. Even when we are
>> considering real PEs terminating VLs, we must treat the PEs in the=
>> context of Virtual Topology as VNs since they must be named from t= he
>> client naming space.
>>
>> Igor
>>
>>
>> -----Original Message-----
>> From: = ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
>On Behalf
>> Of Snigdho Bardalai
>> Sent: Wednesday, January 16, 2013 5:48 PM
>> To: Daniele Ceccarelli; CCAMP
>> Subject: Re: [CCAMP] Overlay model framework v2
>>
>> Hi Daniele,
>>
>> A few comments. Please see in-line.
>>
>> Thanks
>> Snigdho
>>
>> > -----Original Message-----
>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>> Behalf
>> > Of Daniele Ceccarelli
>> > Sent: Wednesday, January 16, 2013 7:33 AM
>> > To: CCAMP
>> > Subject: [CCAMP] Overlay model framework v2
>> >
>> > Dear overlayers,
>> >
>> > Please find below a new version (v2) of the framework summary=
>> > reflecting the latest discussions. Again i hope i've captured= all
>> > the comments around, sorry if anything is missing, in case >just let
>> > me know what i missed.
>> >
>> > BR
>> > Daniele
>> >
>> >
>> > + Disclaimer:
>> >  1. Packet opto integration is often considered but the<= br> >work can be
>> > extented to any type of SC. Eg. TDM over LSC.
>> >
>> > + Terminology:
>> >  1. Virtual Link: A virtual link is a potential path bet= ween two
>> > virtual or real network  elements in a provider layer ne= twork  that
>> is
>> > maintained/controlled in and by the provider  domain con= trol plane
>> > (and as such cannot transport any traffic/data and protected = from
>> > being
>> >  de-provisioned) and which can be instantiated in the da= ta plane
>> > (and then can  carry/transport/forward traffic/data) pre= serving
>> > previously advertised attributes such as  fate sharing i= nformation.
>> >  2.  Virtual Node: Virtual node is a collection of = zero or more
>> > provider network domain  nodes that are collectively
>represented to
>> > the clients as a single node that  exists in the custome= r layer
>> > network and is capable of terminating of access,  inter-= domain and
>> virtual links.
>>
>> [SCB] Agree with Igor's comment - a virtual node can be a
>combination
>> of multiple nodes or a part of the single node, but to the custome= r
>> node this is transparent.

Yes, agree.

>>
>> >  3. Virtual Topology: Virtual topology is a collection o= f one or
>> > more virtual or real provider  network domain nodes that= exist in
>> > the customer layer network and are interconnected  via 0= or more
>> > virtual links.
>>
>> [SCB] Since the topology advertised by the provider network can >> contain real or virtual elements, why do we call it "virtual<= br> >> topology"? Should it simply be called "provider topology= "? And then
>> specify that it may contain both virtual or real elements.

See above

>>
>> >  4. Overlay topology:  is a superset of virtual top= ologies provided
>> by
>> > each of  provider network domains, access and inter-doma= in links.
>>
>> [SCB] A more concise definition for the overlay topology is
>- CE nodes
>> + Access-links + provider topology as advertised by the pr= ovider
>> network.

We wanted to include also the possiblity of having multiple provider domain= s.

>>
>> >  5. Access Link: Link between OC and OE. GMPLS runs on >that link. It
>> > can support  any of the SCs supported by the GMPLS.
>> >  6. CE (customer Edge): Something like the CN in RFC4208=
>teminology
>> > but (i) receiving  virtual topology from the provider ne= twork and
>> > requesting the set up of one of them or
>> >  (ii) requesting the computation and establishment of a = path
>> > accordingly to given constraints  in the provider networ= k and
>> > receiving the parameters characterizing such path. (ii) =3D= =3D UNI.
>> >  7. PE (provider Edge): Something like the EN in RFC4208=
>but able to
>> > deal with (i) and (ii) above.
>> >  8. PE-CE interface (former ONI) : Interface allowing fo= r
>signaling
>> > and routing messages  exchange between customer overlay<= br> >and provider
>> > network. Routing information consists on  virtual topolo= gy
>> > advertisement. When there is no routing adjacency across the<= br> >> interface
>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling<= br> >> > messages are compliant with  RFC4208. Information relate= d to path
>> > carachteristics, e.g. TE-metrics, collected SRLG,  path = delay etc,
>> > either passed from CE to PE via signaling after the LSP
>> > establishment in the core network or from CE to PE to be used= as
>> > path computation constraints, fall  under the definition= of
>> > signaling info and not routing info).
>> >  9. CE-CE (former O-NNI): Interface on the links between= different
>> > provider networks  in the overlay model environment. Sam= e features
>> > of the CE-PE apply to this interface.
>>
>> [SCB] Is this "PE-PE" instead of "CE-CE"?

Oooops! Definitely.

>>
>> >
>> > + Statements
>> >  1. In the context of overlay model we are aiming to bui= ld an
>> > overlay topology for  the customer network domains  = ;2. The overlay
>> > topology
>> is
>> > comprised of:
>> >     a) access links (links connecting client NEs to= the provider
>> > network domains).
>> >  They can be PSC or LSC.
>> >     b) inter-domain links (links interconnecting se= rver network
>> > domains)
>> >     c) virtual topology provided by the provider ne= twork domains.
>> > Virtual Links  + Virtual Nodes (TBD) + Connectiv= ity Matrix (with a
>> set
>> > of parameters e.g. SRLG,  optical impairments, delay etc= for each
>> > entry) describing connectivity between access links and virtu= al
>> links.
>> >  3. In the context of overlay model we manage  hier= archy
>of overlay
>> > topologies  with overlay/underlay relationships  4.= In the context
>> > of overlay model multi-layering and inter-layer relationships=  are
>> > peripheral at best, it is all about horizontal network integr= ation
>> 5.
>> > The overlay model assumes one CP instance for the customer ne= twork
>> and
>> > a separate  instance for the provider network and in the= CE-PE
>> > interface case the provider  network also surreptitiousl= y
>> participates
>> > in the customer network by injecting  virtual topology i= nformation
>> > into it.
>>
>> [SCB] Specific implementations may or may not have a single instan= ce
>> for the provider and the overlay.

Mmm, that's true. It MUST work with two different instances but no one prev= ents it to work with a single one.

>>
>> >  6. L1VPN (and LxVPN) in general is a type of service >provided over
>> > the CE-PE interface  (it falls under the UNI case as no = routing
>> > adjacency is in place between CE and PE).
>>
>> >
>> >
>> > + Advertisement models (to be detailed in dedicated
>> > + document/documents)
>> >  The CE-PE interface in the overlay model context forese= es
>two types
>> > of advertisement  models.(names still to be agreed) A. >Augmented UNI:
>> > The GMPLS UNI is defined in RFC4208 and augmented by  a = number of
>> > actived draft (references to various drafts to be added).
>> >  The Augmented UNI is a particular type of CE-PE interfa= ce where
>> > only signaling messages  are exchanged between CE and PE= . Messages
>> > from CE to PE can include  a set of parameters to be use= d
>by the PE
>> > as path computation constraints  when computing a path i= n the
>> > provider domain network, while messages from PE  to CE c= an
>include a
>> > set of
>> parameters
>> > qualifying the LSP being established,  like for example<= br> >SRLG, delay,
>> > loss etc.
>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be sim= ply
>> > called with the  general CE-PE interface term?) allowing= the
>> > establishment of signaling and routing adjacency  betwee= n
>CE and PE.
>> > Routing info passed from PE to CE comprise overlay topology >> > information including  (but not limited to) virtual link= s,
>> > connectivity matrices and access links with parameters qualif= ying
>> each
>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling
>> > information
>> and procedures are  compliant with RFC4208.
>> >
>> > + Open issues/questions
>> >  1. PCE-PCEP - do we need to include considerations abou= t PCE and
>> PCEP
>> > into the overlay framework context?
>>
>> [SCB] IMO - this should be described in the overlay
>framework document
>> to establish the context.

+1

>>
>> >  2. BGP-LS needs to be considered
>> >  3. Should potentials be included? E.g. I2RS?
>> >  4. Virtual links: wouldn't a different definition of >virtual links
>> > avoid the advertisement of connectivity matrices (this is
>out of the
>> > fwk scope but within the advertisement models one)?
>> > Take this example:
>> > PE1-----CE1               = CE2-----PE2
>> >         CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D= =3D=3D=3DCE2
>> >         CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D= =3D=3D=3DCE2
>> > i.e. There are 2 VL connecting CE1 and CE2 that could be avai= lable
>> for
>> > PE1 and PE2 to set up an adjacency in the customer domain. CE= 1
>> > and/or
>> > CE2 can be blocking nodes so VL1 and/or VL2 are available onl= y
>> > depending on the connectivity matrices of CE1 and CE2. Hence = PEs
>> > need to be aware of both VL and connectivity matrices. My
>point is:
>> > if CE1 advertises to PE1 only the VL that his connectivity ma= trix
>> > allows to be connected to PE1 (e.g. VL1 only) and not all of = them,
>> > it should be possible to avoid the connectivity matrices
>advertisement.
>> >
>> >
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> > DANIELE CECCARELLI
>> > System & Technology - PDU Optical & Metro
>> >
>> > Via E.Melen, 77
>> > Genova, Italy
>> > Phone +390106002512
>> > Mobile +393346725750
>> > daniele.ceccarelli@ericsson.com
>> > www.eri= csson.com
>> >
>> > This Communication is Confidential. We only send and receive = email
>> > on the basis of the term set out at
>> > www.ericsson.com/email_disclaimer
>> >
>> > _______________________________________________
>> > CCAMP mailing list
>> > CCAMP@iet= f.org
>> > https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org=
>> https://www.ietf.org/mailman/listinfo/ccamp
>
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--_000_4A1562797D64E44993C5CBF38CF1BE4806CCE8ESESSMB301ericsso_-- From vishnupavan@gmail.com Thu Jan 17 08:58:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB86421F8614 for ; Thu, 17 Jan 2013 08:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 hmXRw0sb5Yib for ; Thu, 17 Jan 2013 08:58:17 -0800 (PST) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by ietfa.amsl.com (Postfix) with ESMTP id 05B7921F8833 for ; Thu, 17 Jan 2013 08:58:16 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id ik5so1517943bkc.38 for ; Thu, 17 Jan 2013 08:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3nBgKHAesQSl201Jx+zmrcxUiMgwnSxdzJOWtxJ7dNM=; b=BiUwGUos6Qae+D7+MBc97s1tS+pkWDle3HvQW/AKwThXXLu8vyQ9z6AZ2B+fCpaTEP gHe2FjGs6CIszEdvKC6SgVFttobyCNTpn70hgl/ChWfGOj/Kf243uar9N7tj+qGBpZTI MYqR2pHdqhgIJu7OMOHI0k9FJLfvjwiISnpR6QS21lSaAGyZv6sYvNjnS0vAGQ0GSz9c 82Za+nqV21e8pebYw9X8JnHjhMSWTwS7YoJesayER5HO49cgitrk/O50JbVRHG9A9AkB YJ0a1tMrr1Os+cleT6smQwG7BsFI3ma5t0oLK1BmFY1MRS8ph7nKaew3Vm7CrGg2+0fV 4v4A== MIME-Version: 1.0 X-Received: by 10.204.128.148 with SMTP id k20mr1754735bks.107.1358441895944; Thu, 17 Jan 2013 08:58:15 -0800 (PST) Received: by 10.204.170.139 with HTTP; Thu, 17 Jan 2013 08:58:15 -0800 (PST) In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806CCE8@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CCE8@ESESSMB301.ericsson.se> Date: Thu, 17 Jan 2013 11:58:15 -0500 Message-ID: From: Vishnu Pavan Beeram To: Daniele Ceccarelli Content-Type: multipart/alternative; boundary=0015174c43a6a7e38f04d37ee66d Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:58:19 -0000 --0015174c43a6a7e38f04d37ee66d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Snipped.. > =3D=3DAL1=3D=3D =3D=3D=3D=3DVL1=3D=3D=3D=3D =3D=3D= AL3=3D=3D > CE1 PE1 PE2 CE2 > =3D=3DAL2=3D=3D =3D=3D=3D=3DVL2=3D=3D=3D=3D =3D=3DA= L4=3D=3D > > Say the connectivity constraints only allow the paths {AL1, VL2, AL3} > and {AL2, VL1,AL4} to be provisioned. For this particular exported provid= er > topology, advertising the "connectivity constraints" is a MUST. > [[DC]] in this case why don't just advertising VL2 on AL1 and AL3 and > VL1 on AL2 and AL4? > > Are you proposing the use of a new TE construct under the Link TLV to advertise the constraints specific to a link (instead of using the "Connectivity Matrix" which is a node-scope construct)? Regards, -Pavan > > > >> >-----Original Message----- >> >From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >> >Sent: gioved=EC 17 gennaio 2013 5.28 >> >To: Igor Bryskin; Daniele Ceccarelli; CCAMP >> >Subject: RE: Overlay model framework v2 >> > >> >Hi Igor, >> > >> >Not sure if the case you are citing qualifies a real node or >> >link to be called virtual. The client space name is simply an alias. >> > >> >Regards >> >Snigdho >> > >> >> -----Original Message----- >> >> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >> >> Sent: Wednesday, January 16, 2013 3:04 PM >> >> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >> >> Subject: RE: Overlay model framework v2 >> >> >> >> Snigdho, >> >> >> >> > 3. Virtual Topology: Virtual topology is a collection of one or >> >> > more virtual or real provider network domain nodes that exist in >> >> > the customer layer network and are interconnected via 0 or more >> >> > virtual links. >> >> >> >> [SCB] Since the topology advertised by the provider network can >> >> contain real or virtual elements, why do we call it "virtual >> >> topology"? Should it simply be called "provider topology"? And then >> >> specify that it may contain both virtual or real elements. >> >> >> >> Virtual topology includes only virtual nodes. Even when we are >> >> considering real PEs terminating VLs, we must treat the PEs in the >> >> context of Virtual Topology as VNs since they must be named from the >> >> client naming space. >> >> >> >> Igor >> >> >> >> >> >> -----Original Message----- >> >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >> >On Behalf >> >> Of Snigdho Bardalai >> >> Sent: Wednesday, January 16, 2013 5:48 PM >> >> To: Daniele Ceccarelli; CCAMP >> >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> >> >> Hi Daniele, >> >> >> >> A few comments. Please see in-line. >> >> >> >> Thanks >> >> Snigdho >> >> >> >> > -----Original Message----- >> >> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> >> Behalf >> >> > Of Daniele Ceccarelli >> >> > Sent: Wednesday, January 16, 2013 7:33 AM >> >> > To: CCAMP >> >> > Subject: [CCAMP] Overlay model framework v2 >> >> > >> >> > Dear overlayers, >> >> > >> >> > Please find below a new version (v2) of the framework summary >> >> > reflecting the latest discussions. Again i hope i've captured all >> >> > the comments around, sorry if anything is missing, in case >> >just let >> >> > me know what i missed. >> >> > >> >> > BR >> >> > Daniele >> >> > >> >> > >> >> > + Disclaimer: >> >> > 1. Packet opto integration is often considered but the >> >work can be >> >> > extented to any type of SC. Eg. TDM over LSC. >> >> > >> >> > + Terminology: >> >> > 1. Virtual Link: A virtual link is a potential path between two >> >> > virtual or real network elements in a provider layer network that >> >> is >> >> > maintained/controlled in and by the provider domain control plane >> >> > (and as such cannot transport any traffic/data and protected from >> >> > being >> >> > de-provisioned) and which can be instantiated in the data plane >> >> > (and then can carry/transport/forward traffic/data) preserving >> >> > previously advertised attributes such as fate sharing information. >> >> > 2. Virtual Node: Virtual node is a collection of zero or more >> >> > provider network domain nodes that are collectively >> >represented to >> >> > the clients as a single node that exists in the customer layer >> >> > network and is capable of terminating of access, inter-domain and >> >> virtual links. >> >> >> >> [SCB] Agree with Igor's comment - a virtual node can be a >> >combination >> >> of multiple nodes or a part of the single node, but to the customer >> >> node this is transparent. >> >> Yes, agree. >> >> >> >> >> > 3. Virtual Topology: Virtual topology is a collection of one or >> >> > more virtual or real provider network domain nodes that exist in >> >> > the customer layer network and are interconnected via 0 or more >> >> > virtual links. >> >> >> >> [SCB] Since the topology advertised by the provider network can >> >> contain real or virtual elements, why do we call it "virtual >> >> topology"? Should it simply be called "provider topology"? And then >> >> specify that it may contain both virtual or real elements. >> >> See above >> >> >> >> >> > 4. Overlay topology: is a superset of virtual topologies provided >> >> by >> >> > each of provider network domains, access and inter-domain links. >> >> >> >> [SCB] A more concise definition for the overlay topology is >> >- CE nodes >> >> + Access-links + provider topology as advertised by the provider >> >> network. >> >> We wanted to include also the possiblity of having multiple provider >> domains. >> >> >> >> >> > 5. Access Link: Link between OC and OE. GMPLS runs on >> >that link. It >> >> > can support any of the SCs supported by the GMPLS. >> >> > 6. CE (customer Edge): Something like the CN in RFC4208 >> >teminology >> >> > but (i) receiving virtual topology from the provider network and >> >> > requesting the set up of one of them or >> >> > (ii) requesting the computation and establishment of a path >> >> > accordingly to given constraints in the provider network and >> >> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >> >> > 7. PE (provider Edge): Something like the EN in RFC4208 >> >but able to >> >> > deal with (i) and (ii) above. >> >> > 8. PE-CE interface (former ONI) : Interface allowing for >> >signaling >> >> > and routing messages exchange between customer overlay >> >and provider >> >> > network. Routing information consists on virtual topology >> >> > advertisement. When there is no routing adjacency across the >> >> interface >> >> > it is equivalent to the GMPLS UNI defined in 4208. Signaling >> >> > messages are compliant with RFC4208. Information related to path >> >> > carachteristics, e.g. TE-metrics, collected SRLG, path delay etc, >> >> > either passed from CE to PE via signaling after the LSP >> >> > establishment in the core network or from CE to PE to be used as >> >> > path computation constraints, fall under the definition of >> >> > signaling info and not routing info). >> >> > 9. CE-CE (former O-NNI): Interface on the links between different >> >> > provider networks in the overlay model environment. Same features >> >> > of the CE-PE apply to this interface. >> >> >> >> [SCB] Is this "PE-PE" instead of "CE-CE"? >> >> Oooops! Definitely. >> >> >> >> >> > >> >> > + Statements >> >> > 1. In the context of overlay model we are aiming to build an >> >> > overlay topology for the customer network domains 2. The overlay >> >> > topology >> >> is >> >> > comprised of: >> >> > a) access links (links connecting client NEs to the provider >> >> > network domains). >> >> > They can be PSC or LSC. >> >> > b) inter-domain links (links interconnecting server network >> >> > domains) >> >> > c) virtual topology provided by the provider network domains. >> >> > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a >> >> set >> >> > of parameters e.g. SRLG, optical impairments, delay etc for each >> >> > entry) describing connectivity between access links and virtual >> >> links. >> >> > 3. In the context of overlay model we manage hierarchy >> >of overlay >> >> > topologies with overlay/underlay relationships 4. In the context >> >> > of overlay model multi-layering and inter-layer relationships are >> >> > peripheral at best, it is all about horizontal network integration >> >> 5. >> >> > The overlay model assumes one CP instance for the customer network >> >> and >> >> > a separate instance for the provider network and in the CE-PE >> >> > interface case the provider network also surreptitiously >> >> participates >> >> > in the customer network by injecting virtual topology information >> >> > into it. >> >> >> >> [SCB] Specific implementations may or may not have a single instance >> >> for the provider and the overlay. >> >> Mmm, that's true. It MUST work with two different instances but no one >> prevents it to work with a single one. >> >> >> >> >> > 6. L1VPN (and LxVPN) in general is a type of service >> >provided over >> >> > the CE-PE interface (it falls under the UNI case as no routing >> >> > adjacency is in place between CE and PE). >> >> >> >> > >> >> > >> >> > + Advertisement models (to be detailed in dedicated >> >> > + document/documents) >> >> > The CE-PE interface in the overlay model context foresees >> >two types >> >> > of advertisement models.(names still to be agreed) A. >> >Augmented UNI: >> >> > The GMPLS UNI is defined in RFC4208 and augmented by a number of >> >> > actived draft (references to various drafts to be added). >> >> > The Augmented UNI is a particular type of CE-PE interface where >> >> > only signaling messages are exchanged between CE and PE. Messages >> >> > from CE to PE can include a set of parameters to be used >> >by the PE >> >> > as path computation constraints when computing a path in the >> >> > provider domain network, while messages from PE to CE can >> >include a >> >> > set of >> >> parameters >> >> > qualifying the LSP being established, like for example >> >SRLG, delay, >> >> > loss etc. >> >> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >> >> > called with the general CE-PE interface term?) allowing the >> >> > establishment of signaling and routing adjacency between >> >CE and PE. >> >> > Routing info passed from PE to CE comprise overlay topology >> >> > information including (but not limited to) virtual links, >> >> > connectivity matrices and access links with parameters qualifying >> >> each >> >> > of them in terms of e.g. SRLG, loss, delay etc. Signaling >> >> > information >> >> and procedures are compliant with RFC4208. >> >> > >> >> > + Open issues/questions >> >> > 1. PCE-PCEP - do we need to include considerations about PCE and >> >> PCEP >> >> > into the overlay framework context? >> >> >> >> [SCB] IMO - this should be described in the overlay >> >framework document >> >> to establish the context. >> >> +1 >> >> >> >> >> > 2. BGP-LS needs to be considered >> >> > 3. Should potentials be included? E.g. I2RS? >> >> > 4. Virtual links: wouldn't a different definition of >> >virtual links >> >> > avoid the advertisement of connectivity matrices (this is >> >out of the >> >> > fwk scope but within the advertisement models one)? >> >> > Take this example: >> >> > PE1-----CE1 CE2-----PE2 >> >> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >> >> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >> >> > i.e. There are 2 VL connecting CE1 and CE2 that could be available >> >> for >> >> > PE1 and PE2 to set up an adjacency in the customer domain. CE1 >> >> > and/or >> >> > CE2 can be blocking nodes so VL1 and/or VL2 are available only >> >> > depending on the connectivity matrices of CE1 and CE2. Hence PEs >> >> > need to be aware of both VL and connectivity matrices. My >> >point is: >> >> > if CE1 advertises to PE1 only the VL that his connectivity matrix >> >> > allows to be connected to PE1 (e.g. VL1 only) and not all of them, >> >> > it should be possible to avoid the connectivity matrices >> >advertisement. >> >> > >> >> > >> >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> > DANIELE CECCARELLI >> >> > System & Technology - PDU Optical & Metro >> >> > >> >> > Via E.Melen, 77 >> >> > Genova, Italy >> >> > Phone +390106002512 >> >> > Mobile +393346725750 >> >> > daniele.ceccarelli@ericsson.com >> >> > www.ericsson.com >> >> > >> >> > This Communication is Confidential. We only send and receive email >> >> > on the basis of the term set out at >> >> > www.ericsson.com/email_disclaimer >> >> > >> >> > _______________________________________________ >> >> > CCAMP mailing list >> >> > CCAMP@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/ccamp >> >> _______________________________________________ >> >> CCAMP mailing list >> >> CCAMP@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ccamp >> > >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > > --0015174c43a6a7e38f04d37ee66d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Snipped..=A0
=A0 =A0 =A0 =A0 =3D=3DAL1=3D=3D =A0 =A0 =A0 =A0 =3D=3D=3D=3DVL1=3D=3D= =3D=3D =A0 =A0 =A0 =3D=3DAL3=3D=3D
CE1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PE1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0PE2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CE2
=A0 =A0 =A0 =A0 =3D=3DAL2=3D=3D =A0 =A0 =A0 =A0 =3D=3D=3D=3DVL2=3D=3D= =3D=3D =A0 =A0 =A0 =3D=3DAL4=3D=3D

Say the connectivity constraints only allow the paths {AL1, VL2, AL3} = and {AL2, VL1,AL4} to be provisioned. For this particular exported provider= topology, advertising the "connectivity constraints" is a MUST.<= br>
[[DC]]=A0in t= his case why don't just advertising VL2 on AL1 and=A0AL3 and VL1 on=A0A= L2 and AL4?
Are you proposing the use of a new TE construct und= er the Link TLV=A0to advertise the constraints spec= ific to a link (instead of using the "Connectivity Matrix" which = is a node-scope construct)?=A0

Regards,
-Pavan=



>-----Original Message-----
>From: Snigdho Bardalai [mailto:SBardalai@infinera.com]
>Sent: gioved=EC 17 gennaio 2013 5.28
>To: Igor Bryskin; Daniele Ceccarelli; CCAMP
>Subject: RE: Overlay model framework v2
>
>Hi Igor,
>
>Not sure if the case you are citing qualifies a real node or
>link to be called virtual. The client space name is simply an alias. >
>Regards
>Snigdho
>
>> -----Original Message-----
>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
>> Sent: Wednesday, January 16, 2013 3:04 PM
>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP
>> Subject: RE: Overlay model framework v2
>>
>> Snigdho,
>>
>> > =A03. Virtual Topology: Virtual topology is a collection of o= ne or
>> > more virtual or real provider =A0network domain nodes that ex= ist in
>> > the customer layer network and are interconnected =A0via 0 or= more
>> > virtual links.
>>
>> [SCB] Since the topology advertised by the provider network can >> contain real or virtual elements, why do we call it "virtual<= br> >> topology"? Should it simply be called "provider topology= "? And then
>> specify that it may contain both virtual or real elements.
>>
>> Virtual topology includes only virtual nodes. Even when we are
>> considering real PEs terminating VLs, we must treat the PEs in the=
>> context of Virtual Topology as VNs since they must be named from t= he
>> client naming space.
>>
>> Igor
>>
>>
>> -----Original Message-----
>> From: = ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
>On Behalf
>> Of Snigdho Bardalai
>> Sent: Wednesday, January 16, 2013 5:48 PM
>> To: Daniele Ceccarelli; CCAMP
>> Subject: Re: [CCAMP] Overlay model framework v2
>>
>> Hi Daniele,
>>
>> A few comments. Please see in-line.
>>
>> Thanks
>> Snigdho
>>
>> > -----Original Message-----
>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>> Behalf
>> > Of Daniele Ceccarelli
>> > Sent: Wednesday, January 16, 2013 7:33 AM
>> > To: CCAMP
>> > Subject: [CCAMP] Overlay model framework v2
>> >
>> > Dear overlayers,
>> >
>> > Please find below a new version (v2) of the framework summary=
>> > reflecting the latest discussions. Again i hope i've capt= ured all
>> > the comments around, sorry if anything is missing, in case >just let
>> > me know what i missed.
>> >
>> > BR
>> > Daniele
>> >
>> >
>> > + Disclaimer:
>> > =A01. Packet opto integration is often considered but the
>work can be
>> > extented to any type of SC. Eg. TDM over LSC.
>> >
>> > + Terminology:
>> > =A01. Virtual Link: A virtual link is a potential path betwee= n two
>> > virtual or real network =A0elements in a provider layer netwo= rk =A0that
>> is
>> > maintained/controlled in and by the provider =A0domain contro= l plane
>> > (and as such cannot transport any traffic/data and protected = from
>> > being
>> > =A0de-provisioned) and which can be instantiated in the data = plane
>> > (and then can =A0carry/transport/forward traffic/data) preser= ving
>> > previously advertised attributes such as =A0fate sharing info= rmation.
>> > =A02. =A0Virtual Node: Virtual node is a collection of zero o= r more
>> > provider network domain =A0nodes that are collectively
>represented to
>> > the clients as a single node that =A0exists in the customer l= ayer
>> > network and is capable of terminating of access, =A0inter-dom= ain and
>> virtual links.
>>
>> [SCB] Agree with Igor's comment - a virtual node can be a
>combination
>> of multiple nodes or a part of the single node, but to the custome= r
>> node this is transparent.

Yes, agree.

>>
>> > =A03. Virtual Topology: Virtual topology is a collection of o= ne or
>> > more virtual or real provider =A0network domain nodes that ex= ist in
>> > the customer layer network and are interconnected =A0via 0 or= more
>> > virtual links.
>>
>> [SCB] Since the topology advertised by the provider network can >> contain real or virtual elements, why do we call it "virtual<= br> >> topology"? Should it simply be called "provider topology= "? And then
>> specify that it may contain both virtual or real elements.

See above

>>
>> > =A04. Overlay topology: =A0is a superset of virtual topologie= s provided
>> by
>> > each of =A0provider network domains, access and inter-domain = links.
>>
>> [SCB] A more concise definition for the overlay topology is
>- CE nodes
>> + Access-links + provider topology as advertised by the provider >> network.

We wanted to include also the possiblity of having multiple provider domain= s.

>>
>> > =A05. Access Link: Link between OC and OE. GMPLS runs on
>that link. It
>> > can support =A0any of the SCs supported by the GMPLS.
>> > =A06. CE (customer Edge): Something like the CN in RFC4208 >teminology
>> > but (i) receiving =A0virtual topology from the provider netwo= rk and
>> > requesting the set up of one of them or
>> > =A0(ii) requesting the computation and establishment of a pat= h
>> > accordingly to given constraints =A0in the provider network a= nd
>> > receiving the parameters characterizing such path. (ii) =3D= =3D UNI.
>> > =A07. PE (provider Edge): Something like the EN in RFC4208 >but able to
>> > deal with (i) and (ii) above.
>> > =A08. PE-CE interface (former ONI) : Interface allowing for >signaling
>> > and routing messages =A0exchange between customer overlay
>and provider
>> > network. Routing information consists on =A0virtual topology<= br> >> > advertisement. When there is no routing adjacency across the<= br> >> interface
>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling<= br> >> > messages are compliant with =A0RFC4208. Information related t= o path
>> > carachteristics, e.g. TE-metrics, collected SRLG, =A0path del= ay etc,
>> > either passed from CE to PE via signaling after the LSP
>> > establishment in the core network or from CE to PE to be used= as
>> > path computation constraints, fall =A0under the definition of=
>> > signaling info and not routing info).
>> > =A09. CE-CE (former O-NNI): Interface on the links between di= fferent
>> > provider networks =A0in the overlay model environment. Same f= eatures
>> > of the CE-PE apply to this interface.
>>
>> [SCB] Is this "PE-PE" instead of "CE-CE"?

Oooops! Definitely.

>>
>> >
>> > + Statements
>> > =A01. In the context of overlay model we are aiming to build = an
>> > overlay topology for =A0the customer network domains =A02. Th= e overlay
>> > topology
>> is
>> > comprised of:
>> > =A0 =A0 a) access links (links connecting client NEs to the p= rovider
>> > network domains).
>> > =A0They can be PSC or LSC.
>> > =A0 =A0 b) inter-domain links (links interconnecting server n= etwork
>> > domains)
>> > =A0 =A0 c) virtual topology provided by the provider network = domains.
>> > Virtual Links =A0+ Virtual Nodes (TBD) + Connectivity Matrix = (with a
>> set
>> > of parameters e.g. SRLG, =A0optical impairments, delay etc fo= r each
>> > entry) describing connectivity between access links and virtu= al
>> links.
>> > =A03. In the context of overlay model we manage =A0hierarchy<= br> >of overlay
>> > topologies =A0with overlay/underlay relationships =A04. In th= e context
>> > of overlay model multi-layering and inter-layer relationships= =A0are
>> > peripheral at best, it is all about horizontal network integr= ation
>> 5.
>> > The overlay model assumes one CP instance for the customer ne= twork
>> and
>> > a separate =A0instance for the provider network and in the CE= -PE
>> > interface case the provider =A0network also surreptitiously >> participates
>> > in the customer network by injecting =A0virtual topology info= rmation
>> > into it.
>>
>> [SCB] Specific implementations may or may not have a single instan= ce
>> for the provider and the overlay.

Mmm, that's true. It MUST work with two different instances but no one = prevents it to work with a single one.

>>
>> > =A06. L1VPN (and LxVPN) in general is a type of service
>provided over
>> > the CE-PE interface =A0(it falls under the UNI case as no rou= ting
>> > adjacency is in place between CE and PE).
>>
>> >
>> >
>> > + Advertisement models (to be detailed in dedicated
>> > + document/documents)
>> > =A0The CE-PE interface in the overlay model context foresees<= br> >two types
>> > of advertisement =A0models.(names still to be agreed) A.
>Augmented UNI:
>> > The GMPLS UNI is defined in RFC4208 and augmented by =A0a num= ber of
>> > actived draft (references to various drafts to be added).
>> > =A0The Augmented UNI is a particular type of CE-PE interface = where
>> > only signaling messages =A0are exchanged between CE and PE. M= essages
>> > from CE to PE can include =A0a set of parameters to be used >by the PE
>> > as path computation constraints =A0when computing a path in t= he
>> > provider domain network, while messages from PE =A0to CE can<= br> >include a
>> > set of
>> parameters
>> > qualifying the LSP being established, =A0like for example
>SRLG, delay,
>> > loss etc.
>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be sim= ply
>> > called with the =A0general CE-PE interface term?) allowing th= e
>> > establishment of signaling and routing adjacency =A0between >CE and PE.
>> > Routing info passed from PE to CE comprise overlay topology >> > information including =A0(but not limited to) virtual links,<= br> >> > connectivity matrices and access links with parameters qualif= ying
>> each
>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling
>> > information
>> and procedures are =A0compliant with RFC4208.
>> >
>> > + Open issues/questions
>> > =A01. PCE-PCEP - do we need to include considerations about P= CE and
>> PCEP
>> > into the overlay framework context?
>>
>> [SCB] IMO - this should be described in the overlay
>framework document
>> to establish the context.

+1

>>
>> > =A02. BGP-LS needs to be considered
>> > =A03. Should potentials be included? E.g. I2RS?
>> > =A04. Virtual links: wouldn't a different definition of >virtual links
>> > avoid the advertisement of connectivity matrices (this is
>out of the
>> > fwk scope but within the advertisement models one)?
>> > Take this example:
>> > PE1-----CE1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CE2-----PE2
>> > =A0 =A0 =A0 =A0 CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2=
>> > =A0 =A0 =A0 =A0 CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2=
>> > i.e. There are 2 VL connecting CE1 and CE2 that could be avai= lable
>> for
>> > PE1 and PE2 to set up an adjacency in the customer domain. CE= 1
>> > and/or
>> > CE2 can be blocking nodes so VL1 and/or VL2 are available onl= y
>> > depending on the connectivity matrices of CE1 and CE2. Hence = PEs
>> > need to be aware of both VL and connectivity matrices. My
>point is:
>> > if CE1 advertises to PE1 only the VL that his connectivity ma= trix
>> > allows to be connected to PE1 (e.g. VL1 only) and not all of = them,
>> > it should be possible to avoid the connectivity matrices
>advertisement.
>> >
>> >
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> > DANIELE CECCARELLI
>> > System & Technology - PDU Optical & Metro
>> >
>> > Via E.Melen, 77
>> > Genova, Italy
>> > Phone +390106002512
>> > Mobile +393346725750
>> > daniele.ceccarelli@ericsson.com
>> > www.eri= csson.com
>> >
>> > This Communication is Confidential. We only send and receive = email
>> > on the basis of the term set out at
>> > www.ericsson.com/email_disclaimer
>> >
>> > _______________________________________________
>> > CCAMP mailing list
>> > CCAMP@iet= f.org
>> > https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org=
>> https://www.ietf.org/mailman/listinfo/ccamp
>
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp


--0015174c43a6a7e38f04d37ee66d-- From daniele.ceccarelli@ericsson.com Thu Jan 17 09:04:17 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA6821F87E1 for ; Thu, 17 Jan 2013 09:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.388 X-Spam-Level: X-Spam-Status: No, score=-5.388 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, 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 1j+ewy9MXPtc for ; Thu, 17 Jan 2013 09:04:15 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9202D21F87BA for ; Thu, 17 Jan 2013 09:04:14 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-8b-50f82f0c6604 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0B.1B.10459.C0F28F05; Thu, 17 Jan 2013 18:04:12 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 18:04:12 +0100 From: Daniele Ceccarelli To: Igor Bryskin , Snigdho Bardalai , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRwFLO6lqWmk6S/LNDTw8InAANE4iAAACVKQAAC1BWgAAXfYXg///8zoD//+ZBsIAAKMgA///mkzA= Date: Thu, 17 Jan 2013 17:04:11 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806CDD9@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjS6P/o8Ag+cnrSyezLnBYnGqp53R Ylf/P0YHZo+zC/6weixZ8pPJ49KLQ2wBzFFcNimpOZllqUX6dglcGS+2P2IveNrCWDGhtZGl gfF2dhcjJ4eEgInEzSPbmSFsMYkL99azdTFycQgJHGKUWH7rIDuEs5hRYum9FpYuRg4ONgEr iSeHfEAaRAQKJOYe2MEIEhYWUJd4cF0dIqwhcftwPzuEnSTx+vVjMJtFQFXiT8s7sF28At4S HYvaWSHGn2eRuLLkLiNIglMgSmLphMOsIDajgKzEhN2LwOLMAuISt57MZ4I4VEBiyZ7zUEeL Srx8/I8V5AYJAUWJ5f1yEOV6EjemTmGDsLUlli18DbVXUOLkzCcsExhFZyGZOgtJyywkLbOQ tCxgZFnFyJ6bmJmTXm64iREYHwe3/NbdwXjqnMghRmkOFiVx3jDXCwFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGHV2RrYvFyjf/mrnpcvbPTzKb3bIybyZ9Xz6qYOlf44XB3ScXHHH6IDp hqCmTV8tHBWcTh3+GGCT6/1L5tHHhUFbjectDmfZp+O469d2i06dJNPbCt/df2185ytfHi1u fcvml3j9qehDjhrTH8zN06uuPRmRuPTsupYsFtkfJyocXvh4f5wplKbEUpyRaKjFXFScCAB4 oz9EXQIAAA== Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:04:17 -0000 Does this mean: the topology passed from the PE to the CE? (hope this time = i correctly used the acronims!!!)=20 The new definition looks good to me if you're referring to the virtual link= s/nodes only, but doesn't consider real links/nodes any longer. I prefer the old definition and call it as Pavan suggested: Exported Provid= er Topology" or "Summarized Provider Topology" BR Daniele >-----Original Message----- >From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 >Sent: gioved=EC 17 gennaio 2013 17.23 >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >Daniele, > >What I was saying is that the definition: >> 3. Virtual Topology: Virtual topology is a collection of=20 >one or more=20 >> virtual or real provider network domain nodes that exist in the=20 >> customer layer network and are interconnected via 0 or more virtual=20 >> links. >Is not correct. It should say IMO: >3. Virtual Topology: Virtual topology is a collection of one=20 >or more virtual nodes, supported by one or more provider=20 >network domains, which exist in the customer layer network=20 >and are interconnected via 0 or more virtual links, supported=20 >by one or more provider network domains > >-----Original Message----- >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >Sent: Thursday, January 17, 2013 11:10 AM >To: Igor Bryskin; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >What you say is more than true but orthogonal to my point :-) > >It's only a matter of terminology. We defined: > >> 3. Virtual Topology: Virtual topology is a collection of=20 >one or more=20 >> virtual or real provider network domain nodes that exist in the=20 >> customer layer network and are interconnected via 0 or more virtual=20 >> links. > >If we call it "Virtual Topology", the first thing that comes=20 >to the minds is: its only a collection of virtual links and=20 >virtual nodes. >Snigdho's proposal was to call it differently so to better=20 >identify the fact that it includes both virtual and real=20 >links/nodes, that's it. >The name he proposed, however, is again misleading, because=20 >calling it "provider topology" makes me (and you) thinking of=20 >just real links/nodes, doesn't it? > >I would suggest not to use either of the terms as both are=20 >misleading. Maybe something like "exported topology", "CE-PE=20 >tology" or whatever. > >Daniele=20 > >>-----Original Message----- >>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>Sent: gioved=EC 17 gennaio 2013 16.29 >>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Daniele, >> >>We want to separate a Virtual Topology advertised to the=20 >clients (which=20 >>is, generally speaking, different for different sets of clients) from=20 >>provider real topology, which must be concealed from the clients. >>I disagree with Snigdho, when he is saying that a PE just has=20 >multiple=20 >>aliases (one from each client name space). There is much more to this. >>The way I see it a PE contributes differently to different Virtual=20 >>Topologies (each time with a different ID, sometimes as a whole,=20 >>sometimes as split into several VNs, sometimes as a part of a=20 >large VN,=20 >>possibly with a separate connectivity matrix. it also, depending on=20 >>Virtual Topology, presents itself as switch of a different layer=20 >>network, and so forth). Therefore, PE in the context of Virtual=20 >>Topology is always a Virtual Node, even when it is mapped 1:1=20 >onto real=20 >>provider switch. In general, only VN can terminate a VL. >> >>Igor >> >>-----Original Message----- >>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>Sent: Thursday, January 17, 2013 9:53 AM >>To: Snigdho Bardalai; Igor Bryskin; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Igor, Snigdho, >> >>I agree with Snigdho. Why don't we call it provider topology (or=20 >>whatever) if it includes both virtual links/nodes and real=20 >links/nodes?=20 >>I don't think it has anything to deal with naming space. >> >>Further replies in line >> >>I'd like to have feedbacks from you and all on Open Issue 4.=20 >>That's an advertisement models draft issue but it's something that i=20 >>can't really understand yet. >> >>BR >>Daniele >> >>>-----Original Message----- >>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >>>Sent: gioved=EC 17 gennaio 2013 5.28 >>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Hi Igor, >>> >>>Not sure if the case you are citing qualifies a real node or >>link to be >>>called virtual. The client space name is simply an alias. >>> >>>Regards >>>Snigdho >>> >>>> -----Original Message----- >>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>> Sent: Wednesday, January 16, 2013 3:04 PM >>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >>>> Subject: RE: Overlay model framework v2 >>>>=20 >>>> Snigdho, >>>>=20 >>>> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >>>> > more virtual or real provider network domain nodes that=20 >exist in=20 >>>> > the customer layer network and are interconnected via 0 or more=20 >>>> > virtual links. >>>>=20 >>>> [SCB] Since the topology advertised by the provider network can=20 >>>> contain real or virtual elements, why do we call it "virtual=20 >>>> topology"? Should it simply be called "provider topology"?=20 >And then=20 >>>> specify that it may contain both virtual or real elements. >>>>=20 >>>> Virtual topology includes only virtual nodes. Even when we are=20 >>>> considering real PEs terminating VLs, we must treat the PEs in the=20 >>>> context of Virtual Topology as VNs since they must be named >>from the >>>> client naming space. >>>>=20 >>>> Igor >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>On Behalf >>>> Of Snigdho Bardalai >>>> Sent: Wednesday, January 16, 2013 5:48 PM >>>> To: Daniele Ceccarelli; CCAMP >>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>>=20 >>>> Hi Daniele, >>>>=20 >>>> A few comments. Please see in-line. >>>>=20 >>>> Thanks >>>> Snigdho >>>>=20 >>>> > -----Original Message----- >>>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf >>>> > Of Daniele Ceccarelli >>>> > Sent: Wednesday, January 16, 2013 7:33 AM >>>> > To: CCAMP >>>> > Subject: [CCAMP] Overlay model framework v2 >>>> > >>>> > Dear overlayers, >>>> > >>>> > Please find below a new version (v2) of the framework summary=20 >>>> > reflecting the latest discussions. Again i hope i've=20 >captured all=20 >>>> > the comments around, sorry if anything is missing, in case >>>just let >>>> > me know what i missed. >>>> > >>>> > BR >>>> > Daniele >>>> > >>>> > >>>> > + Disclaimer: >>>> > 1. Packet opto integration is often considered but the >>>work can be >>>> > extented to any type of SC. Eg. TDM over LSC. >>>> > >>>> > + Terminology: >>>> > 1. Virtual Link: A virtual link is a potential path between two=20 >>>> > virtual or real network elements in a provider layer >>network that >>>> is >>>> > maintained/controlled in and by the provider domain >>control plane >>>> > (and as such cannot transport any traffic/data and=20 >protected from=20 >>>> > being >>>> > de-provisioned) and which can be instantiated in the data plane=20 >>>> > (and then can carry/transport/forward traffic/data) preserving=20 >>>> > previously advertised attributes such as fate sharing >>information. >>>> > 2. Virtual Node: Virtual node is a collection of zero or more=20 >>>> > provider network domain nodes that are collectively >>>represented to >>>> > the clients as a single node that exists in the customer layer=20 >>>> > network and is capable of terminating of access, =20 >inter-domain and >>>> virtual links. >>>>=20 >>>> [SCB] Agree with Igor's comment - a virtual node can be a >>>combination >>>> of multiple nodes or a part of the single node, but to the=20 >customer=20 >>>> node this is transparent. >> >>Yes, agree. >> >>>>=20 >>>> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >>>> > more virtual or real provider network domain nodes that=20 >exist in=20 >>>> > the customer layer network and are interconnected via 0 or more=20 >>>> > virtual links. >>>>=20 >>>> [SCB] Since the topology advertised by the provider network can=20 >>>> contain real or virtual elements, why do we call it "virtual=20 >>>> topology"? Should it simply be called "provider topology"?=20 >And then=20 >>>> specify that it may contain both virtual or real elements. >> >>See above >> >>>>=20 >>>> > 4. Overlay topology: is a superset of virtual >>topologies provided >>>> by >>>> > each of provider network domains, access and inter-domain links. >>>>=20 >>>> [SCB] A more concise definition for the overlay topology is >>>- CE nodes >>>> + Access-links + provider topology as advertised by the provider >>>> network. >> >>We wanted to include also the possiblity of having multiple provider=20 >>domains. >> >>>>=20 >>>> > 5. Access Link: Link between OC and OE. GMPLS runs on >>>that link. It >>>> > can support any of the SCs supported by the GMPLS. >>>> > 6. CE (customer Edge): Something like the CN in RFC4208 >>>teminology >>>> > but (i) receiving virtual topology from the provider=20 >network and=20 >>>> > requesting the set up of one of them or >>>> > (ii) requesting the computation and establishment of a path=20 >>>> > accordingly to given constraints in the provider network and=20 >>>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >>>> > 7. PE (provider Edge): Something like the EN in RFC4208 >>>but able to >>>> > deal with (i) and (ii) above. >>>> > 8. PE-CE interface (former ONI) : Interface allowing for >>>signaling >>>> > and routing messages exchange between customer overlay >>>and provider >>>> > network. Routing information consists on virtual topology=20 >>>> > advertisement. When there is no routing adjacency across the >>>> interface >>>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling=20 >>>> > messages are compliant with RFC4208. Information=20 >related to path=20 >>>> > carachteristics, e.g. TE-metrics, collected SRLG, path >>delay etc, >>>> > either passed from CE to PE via signaling after the LSP=20 >>>> > establishment in the core network or from CE to PE to be used as=20 >>>> > path computation constraints, fall under the definition of=20 >>>> > signaling info and not routing info). >>>> > 9. CE-CE (former O-NNI): Interface on the links between >>different >>>> > provider networks in the overlay model environment. Same >>features >>>> > of the CE-PE apply to this interface. >>>>=20 >>>> [SCB] Is this "PE-PE" instead of "CE-CE"? >> >>Oooops! Definitely. >> >>>>=20 >>>> > >>>> > + Statements >>>> > 1. In the context of overlay model we are aiming to build an=20 >>>> > overlay topology for the customer network domains 2. >>The overlay >>>> > topology >>>> is >>>> > comprised of: >>>> > a) access links (links connecting client NEs to the provider=20 >>>> > network domains). >>>> > They can be PSC or LSC. >>>> > b) inter-domain links (links interconnecting server network >>>> > domains) >>>> > c) virtual topology provided by the provider network domains. >>>> > Virtual Links + Virtual Nodes (TBD) + Connectivity=20 >Matrix (with a >>>> set >>>> > of parameters e.g. SRLG, optical impairments, delay etc for each >>>> > entry) describing connectivity between access links and virtual >>>> links. >>>> > 3. In the context of overlay model we manage hierarchy >>>of overlay >>>> > topologies with overlay/underlay relationships 4. In >>the context >>>> > of overlay model multi-layering and inter-layer >>relationships are >>>> > peripheral at best, it is all about horizontal network=20 >integration >>>> 5. >>>> > The overlay model assumes one CP instance for the=20 >customer network >>>> and >>>> > a separate instance for the provider network and in the CE-PE=20 >>>> > interface case the provider network also surreptitiously >>>> participates >>>> > in the customer network by injecting virtual topology >>information >>>> > into it. >>>>=20 >>>> [SCB] Specific implementations may or may not have a single >>instance >>>> for the provider and the overlay. >> >>Mmm, that's true. It MUST work with two different instances=20 >but no one=20 >>prevents it to work with a single one. >> >>>>=20 >>>> > 6. L1VPN (and LxVPN) in general is a type of service >>>provided over >>>> > the CE-PE interface (it falls under the UNI case as no routing=20 >>>> > adjacency is in place between CE and PE). >>>>=20 >>>> > >>>> > >>>> > + Advertisement models (to be detailed in dedicated >>>> > + document/documents) >>>> > The CE-PE interface in the overlay model context foresees >>>two types >>>> > of advertisement models.(names still to be agreed) A.=20 >>>Augmented UNI: >>>> > The GMPLS UNI is defined in RFC4208 and augmented by a=20 >number of=20 >>>> > actived draft (references to various drafts to be added). >>>> > The Augmented UNI is a particular type of CE-PE interface where=20 >>>> > only signaling messages are exchanged between CE and PE. >>Messages >>>> > from CE to PE can include a set of parameters to be used >>>by the PE >>>> > as path computation constraints when computing a path in the=20 >>>> > provider domain network, while messages from PE to CE can >>>include a >>>> > set of >>>> parameters >>>> > qualifying the LSP being established, like for example >>>SRLG, delay, >>>> > loss etc. >>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >>>> > called with the general CE-PE interface term?) allowing the=20 >>>> > establishment of signaling and routing adjacency between >>>CE and PE. >>>> > Routing info passed from PE to CE comprise overlay topology=20 >>>> > information including (but not limited to) virtual links,=20 >>>> > connectivity matrices and access links with parameters qualifying >>>> each >>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=20 >>>> > information >>>> and procedures are compliant with RFC4208. >>>> > >>>> > + Open issues/questions >>>> > 1. PCE-PCEP - do we need to include considerations about PCE and >>>> PCEP >>>> > into the overlay framework context? >>>>=20 >>>> [SCB] IMO - this should be described in the overlay >>>framework document >>>> to establish the context. >> >>+1 >> >>>>=20 >>>> > 2. BGP-LS needs to be considered >>>> > 3. Should potentials be included? E.g. I2RS? >>>> > 4. Virtual links: wouldn't a different definition of >>>virtual links >>>> > avoid the advertisement of connectivity matrices (this is >>>out of the >>>> > fwk scope but within the advertisement models one)? >>>> > Take this example: >>>> > PE1-----CE1 CE2-----PE2 >>>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be=20 >available >>>> for >>>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1=20 >>>> > and/or >>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>>> > depending on the connectivity matrices of CE1 and CE2. Hence PEs=20 >>>> > need to be aware of both VL and connectivity matrices. My >>>point is:=20 >>>> > if CE1 advertises to PE1 only the VL that his=20 >connectivity matrix=20 >>>> > allows to be connected to PE1 (e.g. VL1 only) and not all >>of them, >>>> > it should be possible to avoid the connectivity matrices >>>advertisement. >>>> > >>>> > >>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> > DANIELE CECCARELLI >>>> > System & Technology - PDU Optical & Metro >>>> > >>>> > Via E.Melen, 77 >>>> > Genova, Italy >>>> > Phone +390106002512 >>>> > Mobile +393346725750 >>>> > daniele.ceccarelli@ericsson.com >>>> > www.ericsson.com >>>> > >>>> > This Communication is Confidential. We only send and >>receive email >>>> > on the basis of the term set out at=20 >>>> > www.ericsson.com/email_disclaimer >>>> > >>>> > _______________________________________________ >>>> > CCAMP mailing list >>>> > CCAMP@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/ccamp >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> >= From daniele.ceccarelli@ericsson.com Thu Jan 17 09:07:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2A921F85D2 for ; Thu, 17 Jan 2013 09:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.41 X-Spam-Level: X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, 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 w6XDRpG5swAu for ; Thu, 17 Jan 2013 09:07:50 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B912321F8476 for ; Thu, 17 Jan 2013 09:07:49 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-c0-50f82fe44a5f Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E1.DF.32353.4EF28F05; Thu, 17 Jan 2013 18:07:48 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 18:07:47 +0100 From: Daniele Ceccarelli To: Vishnu Pavan Beeram Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRwFLO6lqWmk6S/LNDTw8InAANE4iAAACVKQAAC1BWgAAXfYXgAAD8bIAAAk2+IP//+1GA///tc8A= Date: Thu, 17 Jan 2013 17:07:46 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806CDEB@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CCE8@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje4T/R8BBs9+6Fo8mXODxeJUTzuj xa7+f4wWc9qeMDuweJxd8IfVY+esu+weS5b8ZPK49OIQWwBLFJdNSmpOZllqkb5dAldG/4G3 LAVHiir2TVnD1MB4IqiLkZNDQsBE4varE+wQtpjEhXvr2boYuTiEBA4xSszb28UM4SxmlJh7 vhcow8HBJmAl8eSQD0iDiIC+xIfPcxhBbGaBAonb7Z1sILYwUPzX7XnMEDUGEjO2fGKDsJMk tq47BraMRUBV4vbb72BxXgFviasTJrNA7NrLInFj5hSwoZwCgRJHH31hAbEZBWQlJuxeBLVM XOLWk/lMEFcLSCzZc54ZwhaVePn4HyvInRICihLL++UgyvUkbkydwgZha0ssW/iaGWKvoMTJ mU9YJjCKzUIydRaSlllIWmYhaVnAyLKKkT03MTMnvdx8EyMwlg5u+W2wg3HTfbFDjNIcLEri vOGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MIbdTki6/7zp2Ed13diD7i+OO6XxP6y9 fWXihqzyGcy/J8/dMd19c/SplNZr/2c+jl82vZj7kqDL62ctCfIvsnQm6erN33wknMXt7iq2 +hWuFha8UxbX/hPe1fFPIj5iiU9Z+mn55pR1x3n8bYo+m8V5RbxiybbtSuGd4paedu+1cBz7 lLBVk5RYijMSDbWYi4oTAamsws9zAgAA Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:07:51 -0000 >Are you proposing the use of a new TE construct under the Link TLV to adve= rtise > the constraints specific to a link (instead of using the "Connectivity Ma= trix" > which is a node-scope construct)? =20 Yes, or better, put it as an option on the table and see if it performs bet= ter than the existing one.=20 If it does we can consider adding it, if it doesn't we've dropped it with a= valid reason. BR Daniele ________________________________ From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]=20 Sent: gioved=EC 17 gennaio 2013 17.58 To: Daniele Ceccarelli Cc: Snigdho Bardalai; Igor Bryskin; CCAMP Subject: Re: [CCAMP] Overlay model framework v2 =09 =09 Snipped..=20 =3D=3DAL1=3D=3D =3D=3D=3D=3DVL1=3D=3D=3D=3D =3D=3D= AL3=3D=3D CE1 PE1 PE2 CE2 =3D=3DAL2=3D=3D =3D=3D=3D=3DVL2=3D=3D=3D=3D =3D=3D= AL4=3D=3D =09 =09 Say the connectivity constraints only allow the paths {AL1, VL2, AL3} an= d {AL2, VL1,AL4} to be provisioned. For this particular exported provider t= opology, advertising the "connectivity constraints" is a MUST. =09 [[DC]] in this case why don't just advertising VL2 on AL1 and AL3 and= VL1 on AL2 and AL4? Are you proposing the use of a new TE construct under the Link TLV to adve= rtise the constraints specific to a link (instead of using the "Connectivit= y Matrix" which is a node-scope construct)?=20 =09 =09 Regards, =09 -Pavan >-----Original Message----- >From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >Sent: gioved=EC 17 gennaio 2013 5.28 >To: Igor Bryskin; Daniele Ceccarelli; CCAMP >Subject: RE: Overlay model framework v2 > >Hi Igor, > >Not sure if the case you are citing qualifies a real node or >link to be called virtual. The client space name is simply an alias. > >Regards >Snigdho > >> -----Original Message----- >> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >> Sent: Wednesday, January 16, 2013 3:04 PM >> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >> Subject: RE: Overlay model framework v2 >> >> Snigdho, >> >> > 3. Virtual Topology: Virtual topology is a collection of one or >> > more virtual or real provider network domain nodes that exist in >> > the customer layer network and are interconnected via 0 or more >> > virtual links. >> >> [SCB] Since the topology advertised by the provider network can >> contain real or virtual elements, why do we call it "virtual >> topology"? Should it simply be called "provider topology"? And then >> specify that it may contain both virtual or real elements. >> >> Virtual topology includes only virtual nodes. Even when we are >> considering real PEs terminating VLs, we must treat the PEs in the >> context of Virtual Topology as VNs since they must be named from the >> client naming space. >> >> Igor >> >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >On Behalf >> Of Snigdho Bardalai >> Sent: Wednesday, January 16, 2013 5:48 PM >> To: Daniele Ceccarelli; CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Hi Daniele, >> >> A few comments. Please see in-line. >> >> Thanks >> Snigdho >> >> > -----Original Message----- >> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> Behalf >> > Of Daniele Ceccarelli >> > Sent: Wednesday, January 16, 2013 7:33 AM >> > To: CCAMP >> > Subject: [CCAMP] Overlay model framework v2 >> > >> > Dear overlayers, >> > >> > Please find below a new version (v2) of the framework summary >> > reflecting the latest discussions. Again i hope i've captured all >> > the comments around, sorry if anything is missing, in case >just let >> > me know what i missed. >> > >> > BR >> > Daniele >> > >> > >> > + Disclaimer: >> > 1. Packet opto integration is often considered but the >work can be >> > extented to any type of SC. Eg. TDM over LSC. >> > >> > + Terminology: >> > 1. Virtual Link: A virtual link is a potential path between two >> > virtual or real network elements in a provider layer network tha= t >> is >> > maintained/controlled in and by the provider domain control plane >> > (and as such cannot transport any traffic/data and protected from >> > being >> > de-provisioned) and which can be instantiated in the data plane >> > (and then can carry/transport/forward traffic/data) preserving >> > previously advertised attributes such as fate sharing information= . >> > 2. Virtual Node: Virtual node is a collection of zero or more >> > provider network domain nodes that are collectively >represented to >> > the clients as a single node that exists in the customer layer >> > network and is capable of terminating of access, inter-domain and >> virtual links. >> >> [SCB] Agree with Igor's comment - a virtual node can be a >combination >> of multiple nodes or a part of the single node, but to the customer >> node this is transparent. =09 =09 Yes, agree. =09 >> >> > 3. Virtual Topology: Virtual topology is a collection of one or >> > more virtual or real provider network domain nodes that exist in >> > the customer layer network and are interconnected via 0 or more >> > virtual links. >> >> [SCB] Since the topology advertised by the provider network can >> contain real or virtual elements, why do we call it "virtual >> topology"? Should it simply be called "provider topology"? And then >> specify that it may contain both virtual or real elements. =09 =09 See above =09 >> >> > 4. Overlay topology: is a superset of virtual topologies provide= d >> by >> > each of provider network domains, access and inter-domain links. >> >> [SCB] A more concise definition for the overlay topology is >- CE nodes >> + Access-links + provider topology as advertised by the provider >> network. =09 =09 We wanted to include also the possiblity of having multiple provider do= mains. =09 >> >> > 5. Access Link: Link between OC and OE. GMPLS runs on >that link. It >> > can support any of the SCs supported by the GMPLS. >> > 6. CE (customer Edge): Something like the CN in RFC4208 >teminology >> > but (i) receiving virtual topology from the provider network and >> > requesting the set up of one of them or >> > (ii) requesting the computation and establishment of a path >> > accordingly to given constraints in the provider network and >> > receiving the parameters characterizing such path. (ii) =3D=3D UNI= . >> > 7. PE (provider Edge): Something like the EN in RFC4208 >but able to >> > deal with (i) and (ii) above. >> > 8. PE-CE interface (former ONI) : Interface allowing for >signaling >> > and routing messages exchange between customer overlay >and provider >> > network. Routing information consists on virtual topology >> > advertisement. When there is no routing adjacency across the >> interface >> > it is equivalent to the GMPLS UNI defined in 4208. Signaling >> > messages are compliant with RFC4208. Information related to path >> > carachteristics, e.g. TE-metrics, collected SRLG, path delay etc, >> > either passed from CE to PE via signaling after the LSP >> > establishment in the core network or from CE to PE to be used as >> > path computation constraints, fall under the definition of >> > signaling info and not routing info). >> > 9. CE-CE (former O-NNI): Interface on the links between different >> > provider networks in the overlay model environment. Same features >> > of the CE-PE apply to this interface. >> >> [SCB] Is this "PE-PE" instead of "CE-CE"? =09 =09 Oooops! Definitely. =09 >> >> > >> > + Statements >> > 1. In the context of overlay model we are aiming to build an >> > overlay topology for the customer network domains 2. The overlay >> > topology >> is >> > comprised of: >> > a) access links (links connecting client NEs to the provider >> > network domains). >> > They can be PSC or LSC. >> > b) inter-domain links (links interconnecting server network >> > domains) >> > c) virtual topology provided by the provider network domains. >> > Virtual Links + Virtual Nodes (TBD) + Connectivity Matrix (with a >> set >> > of parameters e.g. SRLG, optical impairments, delay etc for each >> > entry) describing connectivity between access links and virtual >> links. >> > 3. In the context of overlay model we manage hierarchy >of overlay >> > topologies with overlay/underlay relationships 4. In the context >> > of overlay model multi-layering and inter-layer relationships are >> > peripheral at best, it is all about horizontal network integration >> 5. >> > The overlay model assumes one CP instance for the customer network >> and >> > a separate instance for the provider network and in the CE-PE >> > interface case the provider network also surreptitiously >> participates >> > in the customer network by injecting virtual topology information >> > into it. >> >> [SCB] Specific implementations may or may not have a single instance >> for the provider and the overlay. =09 =09 Mmm, that's true. It MUST work with two different instances but no one = prevents it to work with a single one. =09 >> >> > 6. L1VPN (and LxVPN) in general is a type of service >provided over >> > the CE-PE interface (it falls under the UNI case as no routing >> > adjacency is in place between CE and PE). >> >> > >> > >> > + Advertisement models (to be detailed in dedicated >> > + document/documents) >> > The CE-PE interface in the overlay model context foresees >two types >> > of advertisement models.(names still to be agreed) A. >Augmented UNI: >> > The GMPLS UNI is defined in RFC4208 and augmented by a number of >> > actived draft (references to various drafts to be added). >> > The Augmented UNI is a particular type of CE-PE interface where >> > only signaling messages are exchanged between CE and PE. Messages >> > from CE to PE can include a set of parameters to be used >by the PE >> > as path computation constraints when computing a path in the >> > provider domain network, while messages from PE to CE can >include a >> > set of >> parameters >> > qualifying the LSP being established, like for example >SRLG, delay, >> > loss etc. >> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >> > called with the general CE-PE interface term?) allowing the >> > establishment of signaling and routing adjacency between >CE and PE. >> > Routing info passed from PE to CE comprise overlay topology >> > information including (but not limited to) virtual links, >> > connectivity matrices and access links with parameters qualifying >> each >> > of them in terms of e.g. SRLG, loss, delay etc. Signaling >> > information >> and procedures are compliant with RFC4208. >> > >> > + Open issues/questions >> > 1. PCE-PCEP - do we need to include considerations about PCE and >> PCEP >> > into the overlay framework context? >> >> [SCB] IMO - this should be described in the overlay >framework document >> to establish the context. =09 =09 +1 =09 >> >> > 2. BGP-LS needs to be considered >> > 3. Should potentials be included? E.g. I2RS? >> > 4. Virtual links: wouldn't a different definition of >virtual links >> > avoid the advertisement of connectivity matrices (this is >out of the >> > fwk scope but within the advertisement models one)? >> > Take this example: >> > PE1-----CE1 CE2-----PE2 >> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >> > i.e. There are 2 VL connecting CE1 and CE2 that could be available >> for >> > PE1 and PE2 to set up an adjacency in the customer domain. CE1 >> > and/or >> > CE2 can be blocking nodes so VL1 and/or VL2 are available only >> > depending on the connectivity matrices of CE1 and CE2. Hence PEs >> > need to be aware of both VL and connectivity matrices. My >point is: >> > if CE1 advertises to PE1 only the VL that his connectivity matrix >> > allows to be connected to PE1 (e.g. VL1 only) and not all of them, >> > it should be possible to avoid the connectivity matrices >advertisement. >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > DANIELE CECCARELLI >> > System & Technology - PDU Optical & Metro >> > >> > Via E.Melen, 77 >> > Genova, Italy >> > Phone +390106002512 =20 >> > Mobile +393346725750 =20 >> > daniele.ceccarelli@ericsson.com >> > www.ericsson.com >> > >> > This Communication is Confidential. We only send and receive email >> > on the basis of the term set out at >> > www.ericsson.com/email_disclaimer >> > >> > _______________________________________________ >> > CCAMP mailing list >> > CCAMP@ietf.org >> > https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =09 From IBryskin@advaoptical.com Thu Jan 17 09:11:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13BC21F879D for ; Thu, 17 Jan 2013 09:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 WqhkU46tsKod for ; Thu, 17 Jan 2013 09:11:26 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id CD64921F8792 for ; Thu, 17 Jan 2013 09:11:25 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0HHBLEk001778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 18:11:21 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 17 Jan 2013 18:11:21 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Thu, 17 Jan 2013 12:11:19 -0500 From: Igor Bryskin To: Daniele Ceccarelli , Snigdho Bardalai , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAOJ5ugAAF4jxAAC1ZqcAAgY/iAAAnZVHD//8bogIAAUn/A//+8joCAAFMukA== Date: Thu, 17 Jan 2013 17:11:19 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CDD9@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806CDD9@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-17_06:2013-01-17, 2013-01-17, 1970-01-01 signatures=0 Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:11:27 -0000 The reason I like term "Virtual Topology" is simply because it is entirely = made up of virtual elements: nodes and links. If you agree with me that pro= vider does not disclose any of its real network topology information, I don= 't see why the terms "Exported Provider Topology" or "Summarized Provider T= opology" are better/less confusing. -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]=20 Sent: Thursday, January 17, 2013 12:04 PM To: Igor Bryskin; Snigdho Bardalai; CCAMP Subject: RE: Overlay model framework v2 Does this mean: the topology passed from the PE to the CE? (hope this time = i correctly used the acronims!!!)=20 The new definition looks good to me if you're referring to the virtual link= s/nodes only, but doesn't consider real links/nodes any longer. I prefer the old definition and call it as Pavan suggested: Exported Provid= er Topology" or "Summarized Provider Topology" BR Daniele >-----Original Message----- >From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >Sent: gioved=EC 17 gennaio 2013 17.23 >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >Daniele, > >What I was saying is that the definition: >> 3. Virtual Topology: Virtual topology is a collection of >one or more >> virtual or real provider network domain nodes that exist in the=20 >> customer layer network and are interconnected via 0 or more virtual=20 >> links. >Is not correct. It should say IMO: >3. Virtual Topology: Virtual topology is a collection of one or more=20 >virtual nodes, supported by one or more provider network domains, which=20 >exist in the customer layer network and are interconnected via 0 or=20 >more virtual links, supported by one or more provider network domains > >-----Original Message----- >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >Sent: Thursday, January 17, 2013 11:10 AM >To: Igor Bryskin; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >What you say is more than true but orthogonal to my point :-) > >It's only a matter of terminology. We defined: > >> 3. Virtual Topology: Virtual topology is a collection of >one or more >> virtual or real provider network domain nodes that exist in the=20 >> customer layer network and are interconnected via 0 or more virtual=20 >> links. > >If we call it "Virtual Topology", the first thing that comes to the=20 >minds is: its only a collection of virtual links and virtual nodes. >Snigdho's proposal was to call it differently so to better identify the=20 >fact that it includes both virtual and real links/nodes, that's it. >The name he proposed, however, is again misleading, because calling it=20 >"provider topology" makes me (and you) thinking of just real=20 >links/nodes, doesn't it? > >I would suggest not to use either of the terms as both are misleading.=20 >Maybe something like "exported topology", "CE-PE tology" or whatever. > >Daniele > >>-----Original Message----- >>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>Sent: gioved=EC 17 gennaio 2013 16.29 >>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Daniele, >> >>We want to separate a Virtual Topology advertised to the >clients (which >>is, generally speaking, different for different sets of clients) from=20 >>provider real topology, which must be concealed from the clients. >>I disagree with Snigdho, when he is saying that a PE just has >multiple >>aliases (one from each client name space). There is much more to this. >>The way I see it a PE contributes differently to different Virtual=20 >>Topologies (each time with a different ID, sometimes as a whole,=20 >>sometimes as split into several VNs, sometimes as a part of a >large VN, >>possibly with a separate connectivity matrix. it also, depending on=20 >>Virtual Topology, presents itself as switch of a different layer=20 >>network, and so forth). Therefore, PE in the context of Virtual=20 >>Topology is always a Virtual Node, even when it is mapped 1:1 >onto real >>provider switch. In general, only VN can terminate a VL. >> >>Igor >> >>-----Original Message----- >>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>Sent: Thursday, January 17, 2013 9:53 AM >>To: Snigdho Bardalai; Igor Bryskin; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Igor, Snigdho, >> >>I agree with Snigdho. Why don't we call it provider topology (or >>whatever) if it includes both virtual links/nodes and real >links/nodes?=20 >>I don't think it has anything to deal with naming space. >> >>Further replies in line >> >>I'd like to have feedbacks from you and all on Open Issue 4.=20 >>That's an advertisement models draft issue but it's something that i=20 >>can't really understand yet. >> >>BR >>Daniele >> >>>-----Original Message----- >>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >>>Sent: gioved=EC 17 gennaio 2013 5.28 >>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Hi Igor, >>> >>>Not sure if the case you are citing qualifies a real node or >>link to be >>>called virtual. The client space name is simply an alias. >>> >>>Regards >>>Snigdho >>> >>>> -----Original Message----- >>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>> Sent: Wednesday, January 16, 2013 3:04 PM >>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >>>> Subject: RE: Overlay model framework v2 >>>>=20 >>>> Snigdho, >>>>=20 >>>> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >>>> > more virtual or real provider network domain nodes that >exist in >>>> > the customer layer network and are interconnected via 0 or more=20 >>>> > virtual links. >>>>=20 >>>> [SCB] Since the topology advertised by the provider network can=20 >>>> contain real or virtual elements, why do we call it "virtual=20 >>>> topology"? Should it simply be called "provider topology"? >And then >>>> specify that it may contain both virtual or real elements. >>>>=20 >>>> Virtual topology includes only virtual nodes. Even when we are=20 >>>> considering real PEs terminating VLs, we must treat the PEs in the=20 >>>> context of Virtual Topology as VNs since they must be named >>from the >>>> client naming space. >>>>=20 >>>> Igor >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>On Behalf >>>> Of Snigdho Bardalai >>>> Sent: Wednesday, January 16, 2013 5:48 PM >>>> To: Daniele Ceccarelli; CCAMP >>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>>=20 >>>> Hi Daniele, >>>>=20 >>>> A few comments. Please see in-line. >>>>=20 >>>> Thanks >>>> Snigdho >>>>=20 >>>> > -----Original Message----- >>>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf >>>> > Of Daniele Ceccarelli >>>> > Sent: Wednesday, January 16, 2013 7:33 AM >>>> > To: CCAMP >>>> > Subject: [CCAMP] Overlay model framework v2 >>>> > >>>> > Dear overlayers, >>>> > >>>> > Please find below a new version (v2) of the framework summary=20 >>>> > reflecting the latest discussions. Again i hope i've >captured all >>>> > the comments around, sorry if anything is missing, in case >>>just let >>>> > me know what i missed. >>>> > >>>> > BR >>>> > Daniele >>>> > >>>> > >>>> > + Disclaimer: >>>> > 1. Packet opto integration is often considered but the >>>work can be >>>> > extented to any type of SC. Eg. TDM over LSC. >>>> > >>>> > + Terminology: >>>> > 1. Virtual Link: A virtual link is a potential path between two=20 >>>> > virtual or real network elements in a provider layer >>network that >>>> is >>>> > maintained/controlled in and by the provider domain >>control plane >>>> > (and as such cannot transport any traffic/data and >protected from >>>> > being >>>> > de-provisioned) and which can be instantiated in the data plane=20 >>>> > (and then can carry/transport/forward traffic/data) preserving=20 >>>> > previously advertised attributes such as fate sharing >>information. >>>> > 2. Virtual Node: Virtual node is a collection of zero or more=20 >>>> > provider network domain nodes that are collectively >>>represented to >>>> > the clients as a single node that exists in the customer layer=20 >>>> > network and is capable of terminating of access, >inter-domain and >>>> virtual links. >>>>=20 >>>> [SCB] Agree with Igor's comment - a virtual node can be a >>>combination >>>> of multiple nodes or a part of the single node, but to the >customer >>>> node this is transparent. >> >>Yes, agree. >> >>>>=20 >>>> > 3. Virtual Topology: Virtual topology is a collection of one or=20 >>>> > more virtual or real provider network domain nodes that >exist in >>>> > the customer layer network and are interconnected via 0 or more=20 >>>> > virtual links. >>>>=20 >>>> [SCB] Since the topology advertised by the provider network can=20 >>>> contain real or virtual elements, why do we call it "virtual=20 >>>> topology"? Should it simply be called "provider topology"? >And then >>>> specify that it may contain both virtual or real elements. >> >>See above >> >>>>=20 >>>> > 4. Overlay topology: is a superset of virtual >>topologies provided >>>> by >>>> > each of provider network domains, access and inter-domain links. >>>>=20 >>>> [SCB] A more concise definition for the overlay topology is >>>- CE nodes >>>> + Access-links + provider topology as advertised by the provider >>>> network. >> >>We wanted to include also the possiblity of having multiple provider=20 >>domains. >> >>>>=20 >>>> > 5. Access Link: Link between OC and OE. GMPLS runs on >>>that link. It >>>> > can support any of the SCs supported by the GMPLS. >>>> > 6. CE (customer Edge): Something like the CN in RFC4208 >>>teminology >>>> > but (i) receiving virtual topology from the provider >network and >>>> > requesting the set up of one of them or >>>> > (ii) requesting the computation and establishment of a path=20 >>>> > accordingly to given constraints in the provider network and=20 >>>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >>>> > 7. PE (provider Edge): Something like the EN in RFC4208 >>>but able to >>>> > deal with (i) and (ii) above. >>>> > 8. PE-CE interface (former ONI) : Interface allowing for >>>signaling >>>> > and routing messages exchange between customer overlay >>>and provider >>>> > network. Routing information consists on virtual topology=20 >>>> > advertisement. When there is no routing adjacency across the >>>> interface >>>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling=20 >>>> > messages are compliant with RFC4208. Information >related to path >>>> > carachteristics, e.g. TE-metrics, collected SRLG, path >>delay etc, >>>> > either passed from CE to PE via signaling after the LSP=20 >>>> > establishment in the core network or from CE to PE to be used as=20 >>>> > path computation constraints, fall under the definition of=20 >>>> > signaling info and not routing info). >>>> > 9. CE-CE (former O-NNI): Interface on the links between >>different >>>> > provider networks in the overlay model environment. Same >>features >>>> > of the CE-PE apply to this interface. >>>>=20 >>>> [SCB] Is this "PE-PE" instead of "CE-CE"? >> >>Oooops! Definitely. >> >>>>=20 >>>> > >>>> > + Statements >>>> > 1. In the context of overlay model we are aiming to build an=20 >>>> > overlay topology for the customer network domains 2. >>The overlay >>>> > topology >>>> is >>>> > comprised of: >>>> > a) access links (links connecting client NEs to the provider=20 >>>> > network domains). >>>> > They can be PSC or LSC. >>>> > b) inter-domain links (links interconnecting server network >>>> > domains) >>>> > c) virtual topology provided by the provider network domains. >>>> > Virtual Links + Virtual Nodes (TBD) + Connectivity >Matrix (with a >>>> set >>>> > of parameters e.g. SRLG, optical impairments, delay etc for each >>>> > entry) describing connectivity between access links and virtual >>>> links. >>>> > 3. In the context of overlay model we manage hierarchy >>>of overlay >>>> > topologies with overlay/underlay relationships 4. In >>the context >>>> > of overlay model multi-layering and inter-layer >>relationships are >>>> > peripheral at best, it is all about horizontal network >integration >>>> 5. >>>> > The overlay model assumes one CP instance for the >customer network >>>> and >>>> > a separate instance for the provider network and in the CE-PE=20 >>>> > interface case the provider network also surreptitiously >>>> participates >>>> > in the customer network by injecting virtual topology >>information >>>> > into it. >>>>=20 >>>> [SCB] Specific implementations may or may not have a single >>instance >>>> for the provider and the overlay. >> >>Mmm, that's true. It MUST work with two different instances >but no one >>prevents it to work with a single one. >> >>>>=20 >>>> > 6. L1VPN (and LxVPN) in general is a type of service >>>provided over >>>> > the CE-PE interface (it falls under the UNI case as no routing=20 >>>> > adjacency is in place between CE and PE). >>>>=20 >>>> > >>>> > >>>> > + Advertisement models (to be detailed in dedicated >>>> > + document/documents) >>>> > The CE-PE interface in the overlay model context foresees >>>two types >>>> > of advertisement models.(names still to be agreed) A.=20 >>>Augmented UNI: >>>> > The GMPLS UNI is defined in RFC4208 and augmented by a >number of >>>> > actived draft (references to various drafts to be added). >>>> > The Augmented UNI is a particular type of CE-PE interface where=20 >>>> > only signaling messages are exchanged between CE and PE. >>Messages >>>> > from CE to PE can include a set of parameters to be used >>>by the PE >>>> > as path computation constraints when computing a path in the=20 >>>> > provider domain network, while messages from PE to CE can >>>include a >>>> > set of >>>> parameters >>>> > qualifying the LSP being established, like for example >>>SRLG, delay, >>>> > loss etc. >>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >>>> > called with the general CE-PE interface term?) allowing the=20 >>>> > establishment of signaling and routing adjacency between >>>CE and PE. >>>> > Routing info passed from PE to CE comprise overlay topology=20 >>>> > information including (but not limited to) virtual links,=20 >>>> > connectivity matrices and access links with parameters qualifying >>>> each >>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=20 >>>> > information >>>> and procedures are compliant with RFC4208. >>>> > >>>> > + Open issues/questions >>>> > 1. PCE-PCEP - do we need to include considerations about PCE and >>>> PCEP >>>> > into the overlay framework context? >>>>=20 >>>> [SCB] IMO - this should be described in the overlay >>>framework document >>>> to establish the context. >> >>+1 >> >>>>=20 >>>> > 2. BGP-LS needs to be considered 3. Should potentials be=20 >>>> > included? E.g. I2RS? >>>> > 4. Virtual links: wouldn't a different definition of >>>virtual links >>>> > avoid the advertisement of connectivity matrices (this is >>>out of the >>>> > fwk scope but within the advertisement models one)? >>>> > Take this example: >>>> > PE1-----CE1 CE2-----PE2 >>>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be >available >>>> for >>>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1=20 >>>> > and/or >>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>>> > depending on the connectivity matrices of CE1 and CE2. Hence PEs=20 >>>> > need to be aware of both VL and connectivity matrices. My >>>point is:=20 >>>> > if CE1 advertises to PE1 only the VL that his >connectivity matrix >>>> > allows to be connected to PE1 (e.g. VL1 only) and not all >>of them, >>>> > it should be possible to avoid the connectivity matrices >>>advertisement. >>>> > >>>> > >>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> > DANIELE CECCARELLI >>>> > System & Technology - PDU Optical & Metro >>>> > >>>> > Via E.Melen, 77 >>>> > Genova, Italy >>>> > Phone +390106002512 >>>> > Mobile +393346725750 >>>> > daniele.ceccarelli@ericsson.com >>>> > www.ericsson.com >>>> > >>>> > This Communication is Confidential. We only send and >>receive email >>>> > on the basis of the term set out at=20 >>>> > www.ericsson.com/email_disclaimer >>>> > >>>> > _______________________________________________ >>>> > CCAMP mailing list >>>> > CCAMP@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/ccamp >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> > From daniele.ceccarelli@ericsson.com Thu Jan 17 09:19:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C2921F87C3 for ; Thu, 17 Jan 2013 09:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, 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 vwbjFGgL0Lze for ; Thu, 17 Jan 2013 09:19:43 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EBF5121F8795 for ; Thu, 17 Jan 2013 09:19:41 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-9b-50f832ace517 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E5.41.32353.CA238F05; Thu, 17 Jan 2013 18:19:40 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 18:19:40 +0100 From: Daniele Ceccarelli To: Igor Bryskin , Snigdho Bardalai , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRwFLO6lqWmk6S/LNDTw8InAANE4iAAACVKQAAC1BWgAAXfYXg///8zoD//+ZBsIAAKMgA///mkzCAACbfgP//7YLQ Date: Thu, 17 Jan 2013 17:19:39 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806CE44@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CDD9@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje4aox8BBs0dVhZP5txgsTjV085o sav/H6MDs8fZBX9YPZYs+cnkcenFIbYA5igum5TUnMyy1CJ9uwSujOXfjrMUHJjIWDHz8xzG BsZzZV2MnBwSAiYSHx49ZoKwxSQu3FvP1sXIxSEkcIhRYveE+2AJIYHFQM4f/i5GDg42ASuJ J4d8QMIiAgUScw/sYAQJCwuoSzy4rg4R1pC4fbifHcLOk9jz9wgLiM0ioCqxvecuI4jNK+At sWnmG6hVD1klps9vZQVJcApESWzdtBlsLaOArMSE3YvAGpgFxCVuPZkPdaeAxJI955khbFGJ l4//sYLcICGgKLG8Xw6iXE/ixtQpbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRTZyFpmYWkZRaS lgWMLKsY2XMTM3PSy803MQKj4+CW3wY7GDfdFzvEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QDo1lAxettG4ukv2zc83+SY1pOwMR7HJdid4rPn1b35x7bC3vOpiUfPX9F e6/dL7yV62Z3c+20N1s6JHL/HIwP6l++2O3u6xMrvH60yWz0KjmntShWqWgP1zxOgTm3rtTb vjtvJdr+esuHegVeHReteEtvHqv3hZcNfBZ0X7VareR3RpWVnUvslxJLcUaioRZzUXEiAF0n m7FcAgAA Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:19:44 -0000 I think a virtual link COULD be a real link and a virtual node COULD be a r= eal node. Agree that no provider wants to export the full topology, but there might b= e cases in which it could be useful to summarise a domain in E.G. X virtual= nodes plus Y real nodes (where Y could be very small by !=3D0). I just wan= ted to include this case also. Daniele=20 >-----Original Message----- >From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 >Sent: gioved=EC 17 gennaio 2013 18.11 >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >The reason I like term "Virtual Topology" is simply because it=20 >is entirely made up of virtual elements: nodes and links. If=20 >you agree with me that provider does not disclose any of its=20 >real network topology information, I don't see why the terms=20 >"Exported Provider Topology" or "Summarized Provider Topology"=20 >are better/less confusing. > >-----Original Message----- >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >Sent: Thursday, January 17, 2013 12:04 PM >To: Igor Bryskin; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >Does this mean: the topology passed from the PE to the CE?=20 >(hope this time i correctly used the acronims!!!)=20 > >The new definition looks good to me if you're referring to the=20 >virtual links/nodes only, but doesn't consider real=20 >links/nodes any longer. > >I prefer the old definition and call it as Pavan suggested:=20 >Exported Provider Topology" or "Summarized Provider Topology" > >BR >Daniele > >>-----Original Message----- >>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>Sent: gioved=EC 17 gennaio 2013 17.23 >>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Daniele, >> >>What I was saying is that the definition: >>> 3. Virtual Topology: Virtual topology is a collection of >>one or more >>> virtual or real provider network domain nodes that exist in the=20 >>> customer layer network and are interconnected via 0 or=20 >more virtual=20 >>> links. >>Is not correct. It should say IMO: >>3. Virtual Topology: Virtual topology is a collection of one or more=20 >>virtual nodes, supported by one or more provider network=20 >domains, which=20 >>exist in the customer layer network and are interconnected via 0 or=20 >>more virtual links, supported by one or more provider network domains >> >>-----Original Message----- >>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>Sent: Thursday, January 17, 2013 11:10 AM >>To: Igor Bryskin; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>What you say is more than true but orthogonal to my point :-) >> >>It's only a matter of terminology. We defined: >> >>> 3. Virtual Topology: Virtual topology is a collection of >>one or more >>> virtual or real provider network domain nodes that exist in the=20 >>> customer layer network and are interconnected via 0 or=20 >more virtual=20 >>> links. >> >>If we call it "Virtual Topology", the first thing that comes to the=20 >>minds is: its only a collection of virtual links and virtual nodes. >>Snigdho's proposal was to call it differently so to better=20 >identify the=20 >>fact that it includes both virtual and real links/nodes, that's it. >>The name he proposed, however, is again misleading, because=20 >calling it=20 >>"provider topology" makes me (and you) thinking of just real=20 >>links/nodes, doesn't it? >> >>I would suggest not to use either of the terms as both are=20 >misleading.=20 >>Maybe something like "exported topology", "CE-PE tology" or whatever. >> >>Daniele >> >>>-----Original Message----- >>>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>Sent: gioved=EC 17 gennaio 2013 16.29 >>>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Daniele, >>> >>>We want to separate a Virtual Topology advertised to the >>clients (which >>>is, generally speaking, different for different sets of=20 >clients) from=20 >>>provider real topology, which must be concealed from the clients. >>>I disagree with Snigdho, when he is saying that a PE just has >>multiple >>>aliases (one from each client name space). There is much=20 >more to this. >>>The way I see it a PE contributes differently to different Virtual=20 >>>Topologies (each time with a different ID, sometimes as a whole,=20 >>>sometimes as split into several VNs, sometimes as a part of a >>large VN, >>>possibly with a separate connectivity matrix. it also, depending on=20 >>>Virtual Topology, presents itself as switch of a different layer=20 >>>network, and so forth). Therefore, PE in the context of Virtual=20 >>>Topology is always a Virtual Node, even when it is mapped 1:1 >>onto real >>>provider switch. In general, only VN can terminate a VL. >>> >>>Igor >>> >>>-----Original Message----- >>>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>>Sent: Thursday, January 17, 2013 9:53 AM >>>To: Snigdho Bardalai; Igor Bryskin; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Igor, Snigdho, >>> >>>I agree with Snigdho. Why don't we call it provider topology (or >>>whatever) if it includes both virtual links/nodes and real >>links/nodes?=20 >>>I don't think it has anything to deal with naming space. >>> >>>Further replies in line >>> >>>I'd like to have feedbacks from you and all on Open Issue 4.=20 >>>That's an advertisement models draft issue but it's something that i=20 >>>can't really understand yet. >>> >>>BR >>>Daniele >>> >>>>-----Original Message----- >>>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >>>>Sent: gioved=EC 17 gennaio 2013 5.28 >>>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP >>>>Subject: RE: Overlay model framework v2 >>>> >>>>Hi Igor, >>>> >>>>Not sure if the case you are citing qualifies a real node or >>>link to be >>>>called virtual. The client space name is simply an alias. >>>> >>>>Regards >>>>Snigdho >>>> >>>>> -----Original Message----- >>>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>>> Sent: Wednesday, January 16, 2013 3:04 PM >>>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >>>>> Subject: RE: Overlay model framework v2 >>>>>=20 >>>>> Snigdho, >>>>>=20 >>>>> > 3. Virtual Topology: Virtual topology is a collection=20 >of one or=20 >>>>> > more virtual or real provider network domain nodes that >>exist in >>>>> > the customer layer network and are interconnected via=20 >0 or more=20 >>>>> > virtual links. >>>>>=20 >>>>> [SCB] Since the topology advertised by the provider network can=20 >>>>> contain real or virtual elements, why do we call it "virtual=20 >>>>> topology"? Should it simply be called "provider topology"? >>And then >>>>> specify that it may contain both virtual or real elements. >>>>>=20 >>>>> Virtual topology includes only virtual nodes. Even when we are=20 >>>>> considering real PEs terminating VLs, we must treat the=20 >PEs in the=20 >>>>> context of Virtual Topology as VNs since they must be named >>>from the >>>>> client naming space. >>>>>=20 >>>>> Igor >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>>On Behalf >>>>> Of Snigdho Bardalai >>>>> Sent: Wednesday, January 16, 2013 5:48 PM >>>>> To: Daniele Ceccarelli; CCAMP >>>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>>>=20 >>>>> Hi Daniele, >>>>>=20 >>>>> A few comments. Please see in-line. >>>>>=20 >>>>> Thanks >>>>> Snigdho >>>>>=20 >>>>> > -----Original Message----- >>>>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf >>>>> > Of Daniele Ceccarelli >>>>> > Sent: Wednesday, January 16, 2013 7:33 AM >>>>> > To: CCAMP >>>>> > Subject: [CCAMP] Overlay model framework v2 >>>>> > >>>>> > Dear overlayers, >>>>> > >>>>> > Please find below a new version (v2) of the framework summary=20 >>>>> > reflecting the latest discussions. Again i hope i've >>captured all >>>>> > the comments around, sorry if anything is missing, in case >>>>just let >>>>> > me know what i missed. >>>>> > >>>>> > BR >>>>> > Daniele >>>>> > >>>>> > >>>>> > + Disclaimer: >>>>> > 1. Packet opto integration is often considered but the >>>>work can be >>>>> > extented to any type of SC. Eg. TDM over LSC. >>>>> > >>>>> > + Terminology: >>>>> > 1. Virtual Link: A virtual link is a potential path=20 >between two=20 >>>>> > virtual or real network elements in a provider layer >>>network that >>>>> is >>>>> > maintained/controlled in and by the provider domain >>>control plane >>>>> > (and as such cannot transport any traffic/data and >>protected from >>>>> > being >>>>> > de-provisioned) and which can be instantiated in the=20 >data plane=20 >>>>> > (and then can carry/transport/forward traffic/data) preserving=20 >>>>> > previously advertised attributes such as fate sharing >>>information. >>>>> > 2. Virtual Node: Virtual node is a collection of zero or more=20 >>>>> > provider network domain nodes that are collectively >>>>represented to >>>>> > the clients as a single node that exists in the customer layer=20 >>>>> > network and is capable of terminating of access, >>inter-domain and >>>>> virtual links. >>>>>=20 >>>>> [SCB] Agree with Igor's comment - a virtual node can be a >>>>combination >>>>> of multiple nodes or a part of the single node, but to the >>customer >>>>> node this is transparent. >>> >>>Yes, agree. >>> >>>>>=20 >>>>> > 3. Virtual Topology: Virtual topology is a collection=20 >of one or=20 >>>>> > more virtual or real provider network domain nodes that >>exist in >>>>> > the customer layer network and are interconnected via=20 >0 or more=20 >>>>> > virtual links. >>>>>=20 >>>>> [SCB] Since the topology advertised by the provider network can=20 >>>>> contain real or virtual elements, why do we call it "virtual=20 >>>>> topology"? Should it simply be called "provider topology"? >>And then >>>>> specify that it may contain both virtual or real elements. >>> >>>See above >>> >>>>>=20 >>>>> > 4. Overlay topology: is a superset of virtual >>>topologies provided >>>>> by >>>>> > each of provider network domains, access and=20 >inter-domain links. >>>>>=20 >>>>> [SCB] A more concise definition for the overlay topology is >>>>- CE nodes >>>>> + Access-links + provider topology as advertised by the provider >>>>> network. >>> >>>We wanted to include also the possiblity of having multiple provider=20 >>>domains. >>> >>>>>=20 >>>>> > 5. Access Link: Link between OC and OE. GMPLS runs on >>>>that link. It >>>>> > can support any of the SCs supported by the GMPLS. >>>>> > 6. CE (customer Edge): Something like the CN in RFC4208 >>>>teminology >>>>> > but (i) receiving virtual topology from the provider >>network and >>>>> > requesting the set up of one of them or >>>>> > (ii) requesting the computation and establishment of a path=20 >>>>> > accordingly to given constraints in the provider network and=20 >>>>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >>>>> > 7. PE (provider Edge): Something like the EN in RFC4208 >>>>but able to >>>>> > deal with (i) and (ii) above. >>>>> > 8. PE-CE interface (former ONI) : Interface allowing for >>>>signaling >>>>> > and routing messages exchange between customer overlay >>>>and provider >>>>> > network. Routing information consists on virtual topology=20 >>>>> > advertisement. When there is no routing adjacency across the >>>>> interface >>>>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling=20 >>>>> > messages are compliant with RFC4208. Information >>related to path >>>>> > carachteristics, e.g. TE-metrics, collected SRLG, path >>>delay etc, >>>>> > either passed from CE to PE via signaling after the LSP=20 >>>>> > establishment in the core network or from CE to PE to=20 >be used as=20 >>>>> > path computation constraints, fall under the definition of=20 >>>>> > signaling info and not routing info). >>>>> > 9. CE-CE (former O-NNI): Interface on the links between >>>different >>>>> > provider networks in the overlay model environment. Same >>>features >>>>> > of the CE-PE apply to this interface. >>>>>=20 >>>>> [SCB] Is this "PE-PE" instead of "CE-CE"? >>> >>>Oooops! Definitely. >>> >>>>>=20 >>>>> > >>>>> > + Statements >>>>> > 1. In the context of overlay model we are aiming to build an=20 >>>>> > overlay topology for the customer network domains 2. >>>The overlay >>>>> > topology >>>>> is >>>>> > comprised of: >>>>> > a) access links (links connecting client NEs to the=20 >provider=20 >>>>> > network domains). >>>>> > They can be PSC or LSC. >>>>> > b) inter-domain links (links interconnecting server network >>>>> > domains) >>>>> > c) virtual topology provided by the provider=20 >network domains. >>>>> > Virtual Links + Virtual Nodes (TBD) + Connectivity >>Matrix (with a >>>>> set >>>>> > of parameters e.g. SRLG, optical impairments, delay=20 >etc for each >>>>> > entry) describing connectivity between access links and virtual >>>>> links. >>>>> > 3. In the context of overlay model we manage hierarchy >>>>of overlay >>>>> > topologies with overlay/underlay relationships 4. In >>>the context >>>>> > of overlay model multi-layering and inter-layer >>>relationships are >>>>> > peripheral at best, it is all about horizontal network >>integration >>>>> 5. >>>>> > The overlay model assumes one CP instance for the >>customer network >>>>> and >>>>> > a separate instance for the provider network and in the CE-PE=20 >>>>> > interface case the provider network also surreptitiously >>>>> participates >>>>> > in the customer network by injecting virtual topology >>>information >>>>> > into it. >>>>>=20 >>>>> [SCB] Specific implementations may or may not have a single >>>instance >>>>> for the provider and the overlay. >>> >>>Mmm, that's true. It MUST work with two different instances >>but no one >>>prevents it to work with a single one. >>> >>>>>=20 >>>>> > 6. L1VPN (and LxVPN) in general is a type of service >>>>provided over >>>>> > the CE-PE interface (it falls under the UNI case as no routing=20 >>>>> > adjacency is in place between CE and PE). >>>>>=20 >>>>> > >>>>> > >>>>> > + Advertisement models (to be detailed in dedicated >>>>> > + document/documents) >>>>> > The CE-PE interface in the overlay model context foresees >>>>two types >>>>> > of advertisement models.(names still to be agreed) A.=20 >>>>Augmented UNI: >>>>> > The GMPLS UNI is defined in RFC4208 and augmented by a >>number of >>>>> > actived draft (references to various drafts to be added). >>>>> > The Augmented UNI is a particular type of CE-PE=20 >interface where=20 >>>>> > only signaling messages are exchanged between CE and PE. >>>Messages >>>>> > from CE to PE can include a set of parameters to be used >>>>by the PE >>>>> > as path computation constraints when computing a path in the=20 >>>>> > provider domain network, while messages from PE to CE can >>>>include a >>>>> > set of >>>>> parameters >>>>> > qualifying the LSP being established, like for example >>>>SRLG, delay, >>>>> > loss etc. >>>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could=20 >be simply=20 >>>>> > called with the general CE-PE interface term?) allowing the=20 >>>>> > establishment of signaling and routing adjacency between >>>>CE and PE. >>>>> > Routing info passed from PE to CE comprise overlay topology=20 >>>>> > information including (but not limited to) virtual links,=20 >>>>> > connectivity matrices and access links with parameters=20 >qualifying >>>>> each >>>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=20 >>>>> > information >>>>> and procedures are compliant with RFC4208. >>>>> > >>>>> > + Open issues/questions >>>>> > 1. PCE-PCEP - do we need to include considerations=20 >about PCE and >>>>> PCEP >>>>> > into the overlay framework context? >>>>>=20 >>>>> [SCB] IMO - this should be described in the overlay >>>>framework document >>>>> to establish the context. >>> >>>+1 >>> >>>>>=20 >>>>> > 2. BGP-LS needs to be considered 3. Should potentials be=20 >>>>> > included? E.g. I2RS? >>>>> > 4. Virtual links: wouldn't a different definition of >>>>virtual links >>>>> > avoid the advertisement of connectivity matrices (this is >>>>out of the >>>>> > fwk scope but within the advertisement models one)? >>>>> > Take this example: >>>>> > PE1-----CE1 CE2-----PE2 >>>>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>>>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be >>available >>>>> for >>>>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1=20 >>>>> > and/or >>>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>>>> > depending on the connectivity matrices of CE1 and CE2.=20 >Hence PEs=20 >>>>> > need to be aware of both VL and connectivity matrices. My >>>>point is:=20 >>>>> > if CE1 advertises to PE1 only the VL that his >>connectivity matrix >>>>> > allows to be connected to PE1 (e.g. VL1 only) and not all >>>of them, >>>>> > it should be possible to avoid the connectivity matrices >>>>advertisement. >>>>> > >>>>> > >>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> > DANIELE CECCARELLI >>>>> > System & Technology - PDU Optical & Metro >>>>> > >>>>> > Via E.Melen, 77 >>>>> > Genova, Italy >>>>> > Phone +390106002512 >>>>> > Mobile +393346725750 >>>>> > daniele.ceccarelli@ericsson.com >>>>> > www.ericsson.com >>>>> > >>>>> > This Communication is Confidential. We only send and >>>receive email >>>>> > on the basis of the term set out at=20 >>>>> > www.ericsson.com/email_disclaimer >>>>> > >>>>> > _______________________________________________ >>>>> > CCAMP mailing list >>>>> > CCAMP@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/ccamp >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> >> >= From SBardalai@infinera.com Thu Jan 17 09:25:00 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEF421F87C4 for ; Thu, 17 Jan 2013 09:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 3StXnMGmL6sP for ; Thu, 17 Jan 2013 09:24:57 -0800 (PST) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 74B0021F8795 for ; Thu, 17 Jan 2013 09:24:57 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 09:24:56 -0800 From: Snigdho Bardalai To: Daniele Ceccarelli , Igor Bryskin , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQANE4iAAACVKQAAC1BWgAAXfYXg///8zoD//+ZBsIAAKMgA///mkzCAAL2+gIAAAlSAgACF4NA= Date: Thu, 17 Jan 2013 17:24:55 +0000 Message-ID: <6386D6323049044BA592CB99AB04BACB3F947FD1@SV-EXDB-PROD1.infinera.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CDD9@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CE44@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806CE44@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:25:00 -0000 Agree with Daniele, there is no need to restrict the scope of the topology = being exported or advertised by the provider.=20 Regards Snigdho > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Thursday, January 17, 2013 9:20 AM > To: Igor Bryskin; Snigdho Bardalai; CCAMP > Subject: RE: Overlay model framework v2 >=20 > I think a virtual link COULD be a real link and a virtual node COULD be > a real node. >=20 > Agree that no provider wants to export the full topology, but there > might be cases in which it could be useful to summarise a domain in > E.G. X virtual nodes plus Y real nodes (where Y could be very small by > !=3D0). I just wanted to include this case also. >=20 > Daniele >=20 > >-----Original Message----- > >From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >Sent: gioved=EC 17 gennaio 2013 18.11 > >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP > >Subject: RE: Overlay model framework v2 > > > >The reason I like term "Virtual Topology" is simply because it is > >entirely made up of virtual elements: nodes and links. If you agree > >with me that provider does not disclose any of its real network > >topology information, I don't see why the terms "Exported Provider > >Topology" or "Summarized Provider Topology" > >are better/less confusing. > > > >-----Original Message----- > >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > >Sent: Thursday, January 17, 2013 12:04 PM > >To: Igor Bryskin; Snigdho Bardalai; CCAMP > >Subject: RE: Overlay model framework v2 > > > >Does this mean: the topology passed from the PE to the CE? > >(hope this time i correctly used the acronims!!!) > > > >The new definition looks good to me if you're referring to the virtual > >links/nodes only, but doesn't consider real links/nodes any longer. > > > >I prefer the old definition and call it as Pavan suggested: > >Exported Provider Topology" or "Summarized Provider Topology" > > > >BR > >Daniele > > > >>-----Original Message----- > >>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >>Sent: gioved=EC 17 gennaio 2013 17.23 > >>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP > >>Subject: RE: Overlay model framework v2 > >> > >>Daniele, > >> > >>What I was saying is that the definition: > >>> 3. Virtual Topology: Virtual topology is a collection of > >>one or more > >>> virtual or real provider network domain nodes that exist in the > >>> customer layer network and are interconnected via 0 or > >more virtual > >>> links. > >>Is not correct. It should say IMO: > >>3. Virtual Topology: Virtual topology is a collection of one or more > >>virtual nodes, supported by one or more provider network > >domains, which > >>exist in the customer layer network and are interconnected via 0 or > >>more virtual links, supported by one or more provider network domains > >> > >>-----Original Message----- > >>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > >>Sent: Thursday, January 17, 2013 11:10 AM > >>To: Igor Bryskin; Snigdho Bardalai; CCAMP > >>Subject: RE: Overlay model framework v2 > >> > >>What you say is more than true but orthogonal to my point :-) > >> > >>It's only a matter of terminology. We defined: > >> > >>> 3. Virtual Topology: Virtual topology is a collection of > >>one or more > >>> virtual or real provider network domain nodes that exist in the > >>> customer layer network and are interconnected via 0 or > >more virtual > >>> links. > >> > >>If we call it "Virtual Topology", the first thing that comes to the > >>minds is: its only a collection of virtual links and virtual nodes. > >>Snigdho's proposal was to call it differently so to better > >identify the > >>fact that it includes both virtual and real links/nodes, that's it. > >>The name he proposed, however, is again misleading, because > >calling it > >>"provider topology" makes me (and you) thinking of just real > >>links/nodes, doesn't it? > >> > >>I would suggest not to use either of the terms as both are > >misleading. > >>Maybe something like "exported topology", "CE-PE tology" or whatever. > >> > >>Daniele > >> > >>>-----Original Message----- > >>>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >>>Sent: gioved=EC 17 gennaio 2013 16.29 > >>>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP > >>>Subject: RE: Overlay model framework v2 > >>> > >>>Daniele, > >>> > >>>We want to separate a Virtual Topology advertised to the > >>clients (which > >>>is, generally speaking, different for different sets of > >clients) from > >>>provider real topology, which must be concealed from the clients. > >>>I disagree with Snigdho, when he is saying that a PE just has > >>multiple > >>>aliases (one from each client name space). There is much > >more to this. > >>>The way I see it a PE contributes differently to different Virtual > >>>Topologies (each time with a different ID, sometimes as a whole, > >>>sometimes as split into several VNs, sometimes as a part of a > >>large VN, > >>>possibly with a separate connectivity matrix. it also, depending on > >>>Virtual Topology, presents itself as switch of a different layer > >>>network, and so forth). Therefore, PE in the context of Virtual > >>>Topology is always a Virtual Node, even when it is mapped 1:1 > >>onto real > >>>provider switch. In general, only VN can terminate a VL. > >>> > >>>Igor > >>> > >>>-----Original Message----- > >>>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > >>>Sent: Thursday, January 17, 2013 9:53 AM > >>>To: Snigdho Bardalai; Igor Bryskin; CCAMP > >>>Subject: RE: Overlay model framework v2 > >>> > >>>Igor, Snigdho, > >>> > >>>I agree with Snigdho. Why don't we call it provider topology (or > >>>whatever) if it includes both virtual links/nodes and real > >>links/nodes? > >>>I don't think it has anything to deal with naming space. > >>> > >>>Further replies in line > >>> > >>>I'd like to have feedbacks from you and all on Open Issue 4. > >>>That's an advertisement models draft issue but it's something that i > >>>can't really understand yet. > >>> > >>>BR > >>>Daniele > >>> > >>>>-----Original Message----- > >>>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > >>>>Sent: gioved=EC 17 gennaio 2013 5.28 > >>>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP > >>>>Subject: RE: Overlay model framework v2 > >>>> > >>>>Hi Igor, > >>>> > >>>>Not sure if the case you are citing qualifies a real node or > >>>link to be > >>>>called virtual. The client space name is simply an alias. > >>>> > >>>>Regards > >>>>Snigdho > >>>> > >>>>> -----Original Message----- > >>>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >>>>> Sent: Wednesday, January 16, 2013 3:04 PM > >>>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP > >>>>> Subject: RE: Overlay model framework v2 > >>>>> > >>>>> Snigdho, > >>>>> > >>>>> > 3. Virtual Topology: Virtual topology is a collection > >of one or > >>>>> > more virtual or real provider network domain nodes that > >>exist in > >>>>> > the customer layer network and are interconnected via > >0 or more > >>>>> > virtual links. > >>>>> > >>>>> [SCB] Since the topology advertised by the provider network can > >>>>> contain real or virtual elements, why do we call it "virtual > >>>>> topology"? Should it simply be called "provider topology"? > >>And then > >>>>> specify that it may contain both virtual or real elements. > >>>>> > >>>>> Virtual topology includes only virtual nodes. Even when we are > >>>>> considering real PEs terminating VLs, we must treat the > >PEs in the > >>>>> context of Virtual Topology as VNs since they must be named > >>>from the > >>>>> client naming space. > >>>>> > >>>>> Igor > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > >>>>On Behalf > >>>>> Of Snigdho Bardalai > >>>>> Sent: Wednesday, January 16, 2013 5:48 PM > >>>>> To: Daniele Ceccarelli; CCAMP > >>>>> Subject: Re: [CCAMP] Overlay model framework v2 > >>>>> > >>>>> Hi Daniele, > >>>>> > >>>>> A few comments. Please see in-line. > >>>>> > >>>>> Thanks > >>>>> Snigdho > >>>>> > >>>>> > -----Original Message----- > >>>>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >>>>> Behalf > >>>>> > Of Daniele Ceccarelli > >>>>> > Sent: Wednesday, January 16, 2013 7:33 AM > >>>>> > To: CCAMP > >>>>> > Subject: [CCAMP] Overlay model framework v2 > >>>>> > > >>>>> > Dear overlayers, > >>>>> > > >>>>> > Please find below a new version (v2) of the framework summary > >>>>> > reflecting the latest discussions. Again i hope i've > >>captured all > >>>>> > the comments around, sorry if anything is missing, in case > >>>>just let > >>>>> > me know what i missed. > >>>>> > > >>>>> > BR > >>>>> > Daniele > >>>>> > > >>>>> > > >>>>> > + Disclaimer: > >>>>> > 1. Packet opto integration is often considered but the > >>>>work can be > >>>>> > extented to any type of SC. Eg. TDM over LSC. > >>>>> > > >>>>> > + Terminology: > >>>>> > 1. Virtual Link: A virtual link is a potential path > >between two > >>>>> > virtual or real network elements in a provider layer > >>>network that > >>>>> is > >>>>> > maintained/controlled in and by the provider domain > >>>control plane > >>>>> > (and as such cannot transport any traffic/data and > >>protected from > >>>>> > being > >>>>> > de-provisioned) and which can be instantiated in the > >data plane > >>>>> > (and then can carry/transport/forward traffic/data) preserving > >>>>> > previously advertised attributes such as fate sharing > >>>information. > >>>>> > 2. Virtual Node: Virtual node is a collection of zero or more > >>>>> > provider network domain nodes that are collectively > >>>>represented to > >>>>> > the clients as a single node that exists in the customer layer > >>>>> > network and is capable of terminating of access, > >>inter-domain and > >>>>> virtual links. > >>>>> > >>>>> [SCB] Agree with Igor's comment - a virtual node can be a > >>>>combination > >>>>> of multiple nodes or a part of the single node, but to the > >>customer > >>>>> node this is transparent. > >>> > >>>Yes, agree. > >>> > >>>>> > >>>>> > 3. Virtual Topology: Virtual topology is a collection > >of one or > >>>>> > more virtual or real provider network domain nodes that > >>exist in > >>>>> > the customer layer network and are interconnected via > >0 or more > >>>>> > virtual links. > >>>>> > >>>>> [SCB] Since the topology advertised by the provider network can > >>>>> contain real or virtual elements, why do we call it "virtual > >>>>> topology"? Should it simply be called "provider topology"? > >>And then > >>>>> specify that it may contain both virtual or real elements. > >>> > >>>See above > >>> > >>>>> > >>>>> > 4. Overlay topology: is a superset of virtual > >>>topologies provided > >>>>> by > >>>>> > each of provider network domains, access and > >inter-domain links. > >>>>> > >>>>> [SCB] A more concise definition for the overlay topology is > >>>>- CE nodes > >>>>> + Access-links + provider topology as advertised by the provider > >>>>> network. > >>> > >>>We wanted to include also the possiblity of having multiple provider > >>>domains. > >>> > >>>>> > >>>>> > 5. Access Link: Link between OC and OE. GMPLS runs on > >>>>that link. It > >>>>> > can support any of the SCs supported by the GMPLS. > >>>>> > 6. CE (customer Edge): Something like the CN in RFC4208 > >>>>teminology > >>>>> > but (i) receiving virtual topology from the provider > >>network and > >>>>> > requesting the set up of one of them or > >>>>> > (ii) requesting the computation and establishment of a path > >>>>> > accordingly to given constraints in the provider network and > >>>>> > receiving the parameters characterizing such path. (ii) =3D=3D UN= I. > >>>>> > 7. PE (provider Edge): Something like the EN in RFC4208 > >>>>but able to > >>>>> > deal with (i) and (ii) above. > >>>>> > 8. PE-CE interface (former ONI) : Interface allowing for > >>>>signaling > >>>>> > and routing messages exchange between customer overlay > >>>>and provider > >>>>> > network. Routing information consists on virtual topology > >>>>> > advertisement. When there is no routing adjacency across the > >>>>> interface > >>>>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling > >>>>> > messages are compliant with RFC4208. Information > >>related to path > >>>>> > carachteristics, e.g. TE-metrics, collected SRLG, path > >>>delay etc, > >>>>> > either passed from CE to PE via signaling after the LSP > >>>>> > establishment in the core network or from CE to PE to > >be used as > >>>>> > path computation constraints, fall under the definition of > >>>>> > signaling info and not routing info). > >>>>> > 9. CE-CE (former O-NNI): Interface on the links between > >>>different > >>>>> > provider networks in the overlay model environment. Same > >>>features > >>>>> > of the CE-PE apply to this interface. > >>>>> > >>>>> [SCB] Is this "PE-PE" instead of "CE-CE"? > >>> > >>>Oooops! Definitely. > >>> > >>>>> > >>>>> > > >>>>> > + Statements > >>>>> > 1. In the context of overlay model we are aiming to build an > >>>>> > overlay topology for the customer network domains 2. > >>>The overlay > >>>>> > topology > >>>>> is > >>>>> > comprised of: > >>>>> > a) access links (links connecting client NEs to the > >provider > >>>>> > network domains). > >>>>> > They can be PSC or LSC. > >>>>> > b) inter-domain links (links interconnecting server network > >>>>> > domains) > >>>>> > c) virtual topology provided by the provider > >network domains. > >>>>> > Virtual Links + Virtual Nodes (TBD) + Connectivity > >>Matrix (with a > >>>>> set > >>>>> > of parameters e.g. SRLG, optical impairments, delay > >etc for each > >>>>> > entry) describing connectivity between access links and virtual > >>>>> links. > >>>>> > 3. In the context of overlay model we manage hierarchy > >>>>of overlay > >>>>> > topologies with overlay/underlay relationships 4. In > >>>the context > >>>>> > of overlay model multi-layering and inter-layer > >>>relationships are > >>>>> > peripheral at best, it is all about horizontal network > >>integration > >>>>> 5. > >>>>> > The overlay model assumes one CP instance for the > >>customer network > >>>>> and > >>>>> > a separate instance for the provider network and in the CE-PE > >>>>> > interface case the provider network also surreptitiously > >>>>> participates > >>>>> > in the customer network by injecting virtual topology > >>>information > >>>>> > into it. > >>>>> > >>>>> [SCB] Specific implementations may or may not have a single > >>>instance > >>>>> for the provider and the overlay. > >>> > >>>Mmm, that's true. It MUST work with two different instances > >>but no one > >>>prevents it to work with a single one. > >>> > >>>>> > >>>>> > 6. L1VPN (and LxVPN) in general is a type of service > >>>>provided over > >>>>> > the CE-PE interface (it falls under the UNI case as no routing > >>>>> > adjacency is in place between CE and PE). > >>>>> > >>>>> > > >>>>> > > >>>>> > + Advertisement models (to be detailed in dedicated > >>>>> > + document/documents) > >>>>> > The CE-PE interface in the overlay model context foresees > >>>>two types > >>>>> > of advertisement models.(names still to be agreed) A. > >>>>Augmented UNI: > >>>>> > The GMPLS UNI is defined in RFC4208 and augmented by a > >>number of > >>>>> > actived draft (references to various drafts to be added). > >>>>> > The Augmented UNI is a particular type of CE-PE > >interface where > >>>>> > only signaling messages are exchanged between CE and PE. > >>>Messages > >>>>> > from CE to PE can include a set of parameters to be used > >>>>by the PE > >>>>> > as path computation constraints when computing a path in the > >>>>> > provider domain network, while messages from PE to CE can > >>>>include a > >>>>> > set of > >>>>> parameters > >>>>> > qualifying the LSP being established, like for example > >>>>SRLG, delay, > >>>>> > loss etc. > >>>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could > >be simply > >>>>> > called with the general CE-PE interface term?) allowing the > >>>>> > establishment of signaling and routing adjacency between > >>>>CE and PE. > >>>>> > Routing info passed from PE to CE comprise overlay topology > >>>>> > information including (but not limited to) virtual links, > >>>>> > connectivity matrices and access links with parameters > >qualifying > >>>>> each > >>>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling > >>>>> > information > >>>>> and procedures are compliant with RFC4208. > >>>>> > > >>>>> > + Open issues/questions > >>>>> > 1. PCE-PCEP - do we need to include considerations > >about PCE and > >>>>> PCEP > >>>>> > into the overlay framework context? > >>>>> > >>>>> [SCB] IMO - this should be described in the overlay > >>>>framework document > >>>>> to establish the context. > >>> > >>>+1 > >>> > >>>>> > >>>>> > 2. BGP-LS needs to be considered 3. Should potentials be > >>>>> > included? E.g. I2RS? > >>>>> > 4. Virtual links: wouldn't a different definition of > >>>>virtual links > >>>>> > avoid the advertisement of connectivity matrices (this is > >>>>out of the > >>>>> > fwk scope but within the advertisement models one)? > >>>>> > Take this example: > >>>>> > PE1-----CE1 CE2-----PE2 > >>>>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 > >>>>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 > >>>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be > >>available > >>>>> for > >>>>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1 > >>>>> > and/or > >>>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only > >>>>> > depending on the connectivity matrices of CE1 and CE2. > >Hence PEs > >>>>> > need to be aware of both VL and connectivity matrices. My > >>>>point is: > >>>>> > if CE1 advertises to PE1 only the VL that his > >>connectivity matrix > >>>>> > allows to be connected to PE1 (e.g. VL1 only) and not all > >>>of them, > >>>>> > it should be possible to avoid the connectivity matrices > >>>>advertisement. > >>>>> > > >>>>> > > >>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> > DANIELE CECCARELLI > >>>>> > System & Technology - PDU Optical & Metro > >>>>> > > >>>>> > Via E.Melen, 77 > >>>>> > Genova, Italy > >>>>> > Phone +390106002512 > >>>>> > Mobile +393346725750 > >>>>> > daniele.ceccarelli@ericsson.com > >>>>> > www.ericsson.com > >>>>> > > >>>>> > This Communication is Confidential. We only send and > >>>receive email > >>>>> > on the basis of the term set out at > >>>>> > www.ericsson.com/email_disclaimer > >>>>> > > >>>>> > _______________________________________________ > >>>>> > CCAMP mailing list > >>>>> > CCAMP@ietf.org > >>>>> > https://www.ietf.org/mailman/listinfo/ccamp > >>>>> _______________________________________________ > >>>>> CCAMP mailing list > >>>>> CCAMP@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>> > >>> > >> > > From ggrammel@juniper.net Thu Jan 17 09:40:02 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7D521F86D4 for ; Thu, 17 Jan 2013 09:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 6+h5iOZISNGV for ; Thu, 17 Jan 2013 09:39:58 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0DF21F866D for ; Thu, 17 Jan 2013 09:39:58 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUPg3bSMAckda1LIFlrCNUOh7t6NQ8Q0B@postini.com; Thu, 17 Jan 2013 09:39:58 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Jan 2013 09:38:14 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 17 Jan 2013 09:38:13 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.181) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 17 Jan 2013 09:39:58 -0800 Received: from mail237-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 17 Jan 2013 17:38:11 +0000 Received: from mail237-ch1 (localhost [127.0.0.1]) by mail237-ch1-R.bigfish.com (Postfix) with ESMTP id E9B7A11400F1 for ; Thu, 17 Jan 2013 17:38:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -27 X-BigFish: PS-27(zz9371Ic89bh1431J168aJ542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL18602eh8275bh8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail237-ch1 (localhost.localdomain [127.0.0.1]) by mail237-ch1 (MessageSwitch) id 1358444289449536_21206; Thu, 17 Jan 2013 17:38:09 +0000 (UTC) Received: from CH1EHSMHS043.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail237-ch1.bigfish.com (Postfix) with ESMTP id 6B7BBD60053; Thu, 17 Jan 2013 17:38:09 +0000 (UTC) Received: from CH1PRD0511HT005.namprd05.prod.outlook.com (157.56.245.197) by CH1EHSMHS043.bigfish.com (10.43.69.252) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 17 Jan 2013 17:38:05 +0000 Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.8.63]) by CH1PRD0511HT005.namprd05.prod.outlook.com ([10.255.159.40]) with mapi id 14.16.0257.004; Thu, 17 Jan 2013 17:38:04 +0000 From: Gert Grammel To: Daniele Ceccarelli , Igor Bryskin , Snigdho Bardalai , CCAMP Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: AQHN9NlmPm1AK+xmrkiikEOUdXTm0A== Date: Thu, 17 Jan 2013 17:38:03 +0000 Message-ID: <305443B66F0CD946A3107753337A031113F8869E@CH1PRD0511MB431.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:40:02 -0000 Daniele,Igor, The discussion shows that the term 'provider' is confusing. Daniele seems to associate the 'provider' term to a service provider that d= oesn't want to export topology. However this is a policy decision and is no= t defining the overlay model. The term 'provider' in the overlay model refers to a control plane entity t= hat provides topology information to a 'client'. Note that I dislike terms (Client, provider) that are associated to an orga= nizational relationship rather than a technical boundary. So what about naming it 'exported virtual topology'? The term 'virtual' shall indicate that a virtual entity MAY not have a phys= ical correspondence. So if any, I propose to skip the term provider and use= 'server' instead. Gert ________________________________________ From: ccamp-bounces@ietf.org on behalf of Daniele Ceccarelli Sent: Thursday, January 17, 2013 6:19:39 PM To: Igor Bryskin; Snigdho Bardalai; CCAMP Subject: Re: [CCAMP] Overlay model framework v2 I think a virtual link COULD be a real link and a virtual node COULD be a r= eal node. Agree that no provider wants to export the full topology, but there might b= e cases in which it could be useful to summarise a domain in E.G. X virtual= nodes plus Y real nodes (where Y could be very small by !=3D0). I just wan= ted to include this case also. Daniele >-----Original Message----- >From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >Sent: gioved=EC 17 gennaio 2013 18.11 >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >The reason I like term "Virtual Topology" is simply because it >is entirely made up of virtual elements: nodes and links. If >you agree with me that provider does not disclose any of its >real network topology information, I don't see why the terms >"Exported Provider Topology" or "Summarized Provider Topology" >are better/less confusing. > >-----Original Message----- >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >Sent: Thursday, January 17, 2013 12:04 PM >To: Igor Bryskin; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >Does this mean: the topology passed from the PE to the CE? >(hope this time i correctly used the acronims!!!) > >The new definition looks good to me if you're referring to the >virtual links/nodes only, but doesn't consider real >links/nodes any longer. > >I prefer the old definition and call it as Pavan suggested: >Exported Provider Topology" or "Summarized Provider Topology" > >BR >Daniele > >>-----Original Message----- >>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>Sent: gioved=EC 17 gennaio 2013 17.23 >>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Daniele, >> >>What I was saying is that the definition: >>> 3. Virtual Topology: Virtual topology is a collection of >>one or more >>> virtual or real provider network domain nodes that exist in the >>> customer layer network and are interconnected via 0 or >more virtual >>> links. >>Is not correct. It should say IMO: >>3. Virtual Topology: Virtual topology is a collection of one or more >>virtual nodes, supported by one or more provider network >domains, which >>exist in the customer layer network and are interconnected via 0 or >>more virtual links, supported by one or more provider network domains >> >>-----Original Message----- >>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>Sent: Thursday, January 17, 2013 11:10 AM >>To: Igor Bryskin; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>What you say is more than true but orthogonal to my point :-) >> >>It's only a matter of terminology. We defined: >> >>> 3. Virtual Topology: Virtual topology is a collection of >>one or more >>> virtual or real provider network domain nodes that exist in the >>> customer layer network and are interconnected via 0 or >more virtual >>> links. >> >>If we call it "Virtual Topology", the first thing that comes to the >>minds is: its only a collection of virtual links and virtual nodes. >>Snigdho's proposal was to call it differently so to better >identify the >>fact that it includes both virtual and real links/nodes, that's it. >>The name he proposed, however, is again misleading, because >calling it >>"provider topology" makes me (and you) thinking of just real >>links/nodes, doesn't it? >> >>I would suggest not to use either of the terms as both are >misleading. >>Maybe something like "exported topology", "CE-PE tology" or whatever. >> >>Daniele >> >>>-----Original Message----- >>>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>Sent: gioved=EC 17 gennaio 2013 16.29 >>>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Daniele, >>> >>>We want to separate a Virtual Topology advertised to the >>clients (which >>>is, generally speaking, different for different sets of >clients) from >>>provider real topology, which must be concealed from the clients. >>>I disagree with Snigdho, when he is saying that a PE just has >>multiple >>>aliases (one from each client name space). There is much >more to this. >>>The way I see it a PE contributes differently to different Virtual >>>Topologies (each time with a different ID, sometimes as a whole, >>>sometimes as split into several VNs, sometimes as a part of a >>large VN, >>>possibly with a separate connectivity matrix. it also, depending on >>>Virtual Topology, presents itself as switch of a different layer >>>network, and so forth). Therefore, PE in the context of Virtual >>>Topology is always a Virtual Node, even when it is mapped 1:1 >>onto real >>>provider switch. In general, only VN can terminate a VL. >>> >>>Igor >>> >>>-----Original Message----- >>>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>>Sent: Thursday, January 17, 2013 9:53 AM >>>To: Snigdho Bardalai; Igor Bryskin; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Igor, Snigdho, >>> >>>I agree with Snigdho. Why don't we call it provider topology (or >>>whatever) if it includes both virtual links/nodes and real >>links/nodes? >>>I don't think it has anything to deal with naming space. >>> >>>Further replies in line >>> >>>I'd like to have feedbacks from you and all on Open Issue 4. >>>That's an advertisement models draft issue but it's something that i >>>can't really understand yet. >>> >>>BR >>>Daniele >>> >>>>-----Original Message----- >>>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >>>>Sent: gioved=EC 17 gennaio 2013 5.28 >>>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP >>>>Subject: RE: Overlay model framework v2 >>>> >>>>Hi Igor, >>>> >>>>Not sure if the case you are citing qualifies a real node or >>>link to be >>>>called virtual. The client space name is simply an alias. >>>> >>>>Regards >>>>Snigdho >>>> >>>>> -----Original Message----- >>>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>>> Sent: Wednesday, January 16, 2013 3:04 PM >>>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >>>>> Subject: RE: Overlay model framework v2 >>>>> >>>>> Snigdho, >>>>> >>>>> > 3. Virtual Topology: Virtual topology is a collection >of one or >>>>> > more virtual or real provider network domain nodes that >>exist in >>>>> > the customer layer network and are interconnected via >0 or more >>>>> > virtual links. >>>>> >>>>> [SCB] Since the topology advertised by the provider network can >>>>> contain real or virtual elements, why do we call it "virtual >>>>> topology"? Should it simply be called "provider topology"? >>And then >>>>> specify that it may contain both virtual or real elements. >>>>> >>>>> Virtual topology includes only virtual nodes. Even when we are >>>>> considering real PEs terminating VLs, we must treat the >PEs in the >>>>> context of Virtual Topology as VNs since they must be named >>>from the >>>>> client naming space. >>>>> >>>>> Igor >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>>On Behalf >>>>> Of Snigdho Bardalai >>>>> Sent: Wednesday, January 16, 2013 5:48 PM >>>>> To: Daniele Ceccarelli; CCAMP >>>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>>> >>>>> Hi Daniele, >>>>> >>>>> A few comments. Please see in-line. >>>>> >>>>> Thanks >>>>> Snigdho >>>>> >>>>> > -----Original Message----- >>>>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf >>>>> > Of Daniele Ceccarelli >>>>> > Sent: Wednesday, January 16, 2013 7:33 AM >>>>> > To: CCAMP >>>>> > Subject: [CCAMP] Overlay model framework v2 >>>>> > >>>>> > Dear overlayers, >>>>> > >>>>> > Please find below a new version (v2) of the framework summary >>>>> > reflecting the latest discussions. Again i hope i've >>captured all >>>>> > the comments around, sorry if anything is missing, in case >>>>just let >>>>> > me know what i missed. >>>>> > >>>>> > BR >>>>> > Daniele >>>>> > >>>>> > >>>>> > + Disclaimer: >>>>> > 1. Packet opto integration is often considered but the >>>>work can be >>>>> > extented to any type of SC. Eg. TDM over LSC. >>>>> > >>>>> > + Terminology: >>>>> > 1. Virtual Link: A virtual link is a potential path >between two >>>>> > virtual or real network elements in a provider layer >>>network that >>>>> is >>>>> > maintained/controlled in and by the provider domain >>>control plane >>>>> > (and as such cannot transport any traffic/data and >>protected from >>>>> > being >>>>> > de-provisioned) and which can be instantiated in the >data plane >>>>> > (and then can carry/transport/forward traffic/data) preserving >>>>> > previously advertised attributes such as fate sharing >>>information. >>>>> > 2. Virtual Node: Virtual node is a collection of zero or more >>>>> > provider network domain nodes that are collectively >>>>represented to >>>>> > the clients as a single node that exists in the customer layer >>>>> > network and is capable of terminating of access, >>inter-domain and >>>>> virtual links. >>>>> >>>>> [SCB] Agree with Igor's comment - a virtual node can be a >>>>combination >>>>> of multiple nodes or a part of the single node, but to the >>customer >>>>> node this is transparent. >>> >>>Yes, agree. >>> >>>>> >>>>> > 3. Virtual Topology: Virtual topology is a collection >of one or >>>>> > more virtual or real provider network domain nodes that >>exist in >>>>> > the customer layer network and are interconnected via >0 or more >>>>> > virtual links. >>>>> >>>>> [SCB] Since the topology advertised by the provider network can >>>>> contain real or virtual elements, why do we call it "virtual >>>>> topology"? Should it simply be called "provider topology"? >>And then >>>>> specify that it may contain both virtual or real elements. >>> >>>See above >>> >>>>> >>>>> > 4. Overlay topology: is a superset of virtual >>>topologies provided >>>>> by >>>>> > each of provider network domains, access and >inter-domain links. >>>>> >>>>> [SCB] A more concise definition for the overlay topology is >>>>- CE nodes >>>>> + Access-links + provider topology as advertised by the provider >>>>> network. >>> >>>We wanted to include also the possiblity of having multiple provider >>>domains. >>> >>>>> >>>>> > 5. Access Link: Link between OC and OE. GMPLS runs on >>>>that link. It >>>>> > can support any of the SCs supported by the GMPLS. >>>>> > 6. CE (customer Edge): Something like the CN in RFC4208 >>>>teminology >>>>> > but (i) receiving virtual topology from the provider >>network and >>>>> > requesting the set up of one of them or >>>>> > (ii) requesting the computation and establishment of a path >>>>> > accordingly to given constraints in the provider network and >>>>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >>>>> > 7. PE (provider Edge): Something like the EN in RFC4208 >>>>but able to >>>>> > deal with (i) and (ii) above. >>>>> > 8. PE-CE interface (former ONI) : Interface allowing for >>>>signaling >>>>> > and routing messages exchange between customer overlay >>>>and provider >>>>> > network. Routing information consists on virtual topology >>>>> > advertisement. When there is no routing adjacency across the >>>>> interface >>>>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling >>>>> > messages are compliant with RFC4208. Information >>related to path >>>>> > carachteristics, e.g. TE-metrics, collected SRLG, path >>>delay etc, >>>>> > either passed from CE to PE via signaling after the LSP >>>>> > establishment in the core network or from CE to PE to >be used as >>>>> > path computation constraints, fall under the definition of >>>>> > signaling info and not routing info). >>>>> > 9. CE-CE (former O-NNI): Interface on the links between >>>different >>>>> > provider networks in the overlay model environment. Same >>>features >>>>> > of the CE-PE apply to this interface. >>>>> >>>>> [SCB] Is this "PE-PE" instead of "CE-CE"? >>> >>>Oooops! Definitely. >>> >>>>> >>>>> > >>>>> > + Statements >>>>> > 1. In the context of overlay model we are aiming to build an >>>>> > overlay topology for the customer network domains 2. >>>The overlay >>>>> > topology >>>>> is >>>>> > comprised of: >>>>> > a) access links (links connecting client NEs to the >provider >>>>> > network domains). >>>>> > They can be PSC or LSC. >>>>> > b) inter-domain links (links interconnecting server network >>>>> > domains) >>>>> > c) virtual topology provided by the provider >network domains. >>>>> > Virtual Links + Virtual Nodes (TBD) + Connectivity >>Matrix (with a >>>>> set >>>>> > of parameters e.g. SRLG, optical impairments, delay >etc for each >>>>> > entry) describing connectivity between access links and virtual >>>>> links. >>>>> > 3. In the context of overlay model we manage hierarchy >>>>of overlay >>>>> > topologies with overlay/underlay relationships 4. In >>>the context >>>>> > of overlay model multi-layering and inter-layer >>>relationships are >>>>> > peripheral at best, it is all about horizontal network >>integration >>>>> 5. >>>>> > The overlay model assumes one CP instance for the >>customer network >>>>> and >>>>> > a separate instance for the provider network and in the CE-PE >>>>> > interface case the provider network also surreptitiously >>>>> participates >>>>> > in the customer network by injecting virtual topology >>>information >>>>> > into it. >>>>> >>>>> [SCB] Specific implementations may or may not have a single >>>instance >>>>> for the provider and the overlay. >>> >>>Mmm, that's true. It MUST work with two different instances >>but no one >>>prevents it to work with a single one. >>> >>>>> >>>>> > 6. L1VPN (and LxVPN) in general is a type of service >>>>provided over >>>>> > the CE-PE interface (it falls under the UNI case as no routing >>>>> > adjacency is in place between CE and PE). >>>>> >>>>> > >>>>> > >>>>> > + Advertisement models (to be detailed in dedicated >>>>> > + document/documents) >>>>> > The CE-PE interface in the overlay model context foresees >>>>two types >>>>> > of advertisement models.(names still to be agreed) A. >>>>Augmented UNI: >>>>> > The GMPLS UNI is defined in RFC4208 and augmented by a >>number of >>>>> > actived draft (references to various drafts to be added). >>>>> > The Augmented UNI is a particular type of CE-PE >interface where >>>>> > only signaling messages are exchanged between CE and PE. >>>Messages >>>>> > from CE to PE can include a set of parameters to be used >>>>by the PE >>>>> > as path computation constraints when computing a path in the >>>>> > provider domain network, while messages from PE to CE can >>>>include a >>>>> > set of >>>>> parameters >>>>> > qualifying the LSP being established, like for example >>>>SRLG, delay, >>>>> > loss etc. >>>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could >be simply >>>>> > called with the general CE-PE interface term?) allowing the >>>>> > establishment of signaling and routing adjacency between >>>>CE and PE. >>>>> > Routing info passed from PE to CE comprise overlay topology >>>>> > information including (but not limited to) virtual links, >>>>> > connectivity matrices and access links with parameters >qualifying >>>>> each >>>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling >>>>> > information >>>>> and procedures are compliant with RFC4208. >>>>> > >>>>> > + Open issues/questions >>>>> > 1. PCE-PCEP - do we need to include considerations >about PCE and >>>>> PCEP >>>>> > into the overlay framework context? >>>>> >>>>> [SCB] IMO - this should be described in the overlay >>>>framework document >>>>> to establish the context. >>> >>>+1 >>> >>>>> >>>>> > 2. BGP-LS needs to be considered 3. Should potentials be >>>>> > included? E.g. I2RS? >>>>> > 4. Virtual links: wouldn't a different definition of >>>>virtual links >>>>> > avoid the advertisement of connectivity matrices (this is >>>>out of the >>>>> > fwk scope but within the advertisement models one)? >>>>> > Take this example: >>>>> > PE1-----CE1 CE2-----PE2 >>>>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>>>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be >>available >>>>> for >>>>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1 >>>>> > and/or >>>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only >>>>> > depending on the connectivity matrices of CE1 and CE2. >Hence PEs >>>>> > need to be aware of both VL and connectivity matrices. My >>>>point is: >>>>> > if CE1 advertises to PE1 only the VL that his >>connectivity matrix >>>>> > allows to be connected to PE1 (e.g. VL1 only) and not all >>>of them, >>>>> > it should be possible to avoid the connectivity matrices >>>>advertisement. >>>>> > >>>>> > >>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> > DANIELE CECCARELLI >>>>> > System & Technology - PDU Optical & Metro >>>>> > >>>>> > Via E.Melen, 77 >>>>> > Genova, Italy >>>>> > Phone +390106002512 >>>>> > Mobile +393346725750 >>>>> > daniele.ceccarelli@ericsson.com >>>>> > www.ericsson.com >>>>> > >>>>> > This Communication is Confidential. We only send and >>>receive email >>>>> > on the basis of the term set out at >>>>> > www.ericsson.com/email_disclaimer >>>>> > >>>>> > _______________________________________________ >>>>> > CCAMP mailing list >>>>> > CCAMP@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/ccamp >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> >> > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Jan 17 10:33:46 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC3321F87EE for ; Thu, 17 Jan 2013 10:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 jUrikP8Favbb for ; Thu, 17 Jan 2013 10:33:42 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id BC9BD21F8833 for ; Thu, 17 Jan 2013 10:33:39 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0HIXYYK021991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 19:33:34 +0100 Received: from MUC-SRV-MBX1.advaoptical.com (172.20.1.95) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 17 Jan 2013 19:33:34 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 17 Jan 2013 19:33:33 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Thu, 17 Jan 2013 13:33:31 -0500 From: Igor Bryskin To: Daniele Ceccarelli , Snigdho Bardalai , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAOJ5ugAAF4jxAAC1ZqcAAgY/iAAAnZVHD//8bogIAAUn/A//+8joCAAFMukP//sSSAgABE4WA= Date: Thu, 17 Jan 2013 18:33:31 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CDD9@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CE44@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806CE44@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-17_06:2013-01-17, 2013-01-17, 1970-01-01 signatures=0 Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:33:46 -0000 Daniele, You say a real link/node COULD be a part of a Virtual Topology. (=3D=3D> Ho= w a real WDM link or ROADM could be a part of ODUk Virtual Topology?) I say a real link/node MAY be represented in it's entirety in a Virtual To= pology by a virtual link/node which has 1:1 cardinality with the said real = link/node. In other words the representation you are talking about according to my def= inition is just one of a variety of ways real links/nodes could be presente= d in a Virtual Topology. I think you are unnecessarily overcomplicating the= model by distinguishing this private case. Igor -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]=20 Sent: Thursday, January 17, 2013 12:20 PM To: Igor Bryskin; Snigdho Bardalai; CCAMP Subject: RE: Overlay model framework v2 I think a virtual link COULD be a real link and a virtual node COULD be a r= eal node. Agree that no provider wants to export the full topology, but there might b= e cases in which it could be useful to summarise a domain in E.G. X virtual= nodes plus Y real nodes (where Y could be very small by !=3D0). I just wan= ted to include this case also. Daniele=20 >-----Original Message----- >From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 >Sent: gioved=EC 17 gennaio 2013 18.11 >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >The reason I like term "Virtual Topology" is simply because it=20 >is entirely made up of virtual elements: nodes and links. If=20 >you agree with me that provider does not disclose any of its=20 >real network topology information, I don't see why the terms=20 >"Exported Provider Topology" or "Summarized Provider Topology"=20 >are better/less confusing. > >-----Original Message----- >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >Sent: Thursday, January 17, 2013 12:04 PM >To: Igor Bryskin; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >Does this mean: the topology passed from the PE to the CE?=20 >(hope this time i correctly used the acronims!!!)=20 > >The new definition looks good to me if you're referring to the=20 >virtual links/nodes only, but doesn't consider real=20 >links/nodes any longer. > >I prefer the old definition and call it as Pavan suggested:=20 >Exported Provider Topology" or "Summarized Provider Topology" > >BR >Daniele > >>-----Original Message----- >>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>Sent: gioved=EC 17 gennaio 2013 17.23 >>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Daniele, >> >>What I was saying is that the definition: >>> 3. Virtual Topology: Virtual topology is a collection of >>one or more >>> virtual or real provider network domain nodes that exist in the=20 >>> customer layer network and are interconnected via 0 or=20 >more virtual=20 >>> links. >>Is not correct. It should say IMO: >>3. Virtual Topology: Virtual topology is a collection of one or more=20 >>virtual nodes, supported by one or more provider network=20 >domains, which=20 >>exist in the customer layer network and are interconnected via 0 or=20 >>more virtual links, supported by one or more provider network domains >> >>-----Original Message----- >>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>Sent: Thursday, January 17, 2013 11:10 AM >>To: Igor Bryskin; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>What you say is more than true but orthogonal to my point :-) >> >>It's only a matter of terminology. We defined: >> >>> 3. Virtual Topology: Virtual topology is a collection of >>one or more >>> virtual or real provider network domain nodes that exist in the=20 >>> customer layer network and are interconnected via 0 or=20 >more virtual=20 >>> links. >> >>If we call it "Virtual Topology", the first thing that comes to the=20 >>minds is: its only a collection of virtual links and virtual nodes. >>Snigdho's proposal was to call it differently so to better=20 >identify the=20 >>fact that it includes both virtual and real links/nodes, that's it. >>The name he proposed, however, is again misleading, because=20 >calling it=20 >>"provider topology" makes me (and you) thinking of just real=20 >>links/nodes, doesn't it? >> >>I would suggest not to use either of the terms as both are=20 >misleading.=20 >>Maybe something like "exported topology", "CE-PE tology" or whatever. >> >>Daniele >> >>>-----Original Message----- >>>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>Sent: gioved=EC 17 gennaio 2013 16.29 >>>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Daniele, >>> >>>We want to separate a Virtual Topology advertised to the >>clients (which >>>is, generally speaking, different for different sets of=20 >clients) from=20 >>>provider real topology, which must be concealed from the clients. >>>I disagree with Snigdho, when he is saying that a PE just has >>multiple >>>aliases (one from each client name space). There is much=20 >more to this. >>>The way I see it a PE contributes differently to different Virtual=20 >>>Topologies (each time with a different ID, sometimes as a whole,=20 >>>sometimes as split into several VNs, sometimes as a part of a >>large VN, >>>possibly with a separate connectivity matrix. it also, depending on=20 >>>Virtual Topology, presents itself as switch of a different layer=20 >>>network, and so forth). Therefore, PE in the context of Virtual=20 >>>Topology is always a Virtual Node, even when it is mapped 1:1 >>onto real >>>provider switch. In general, only VN can terminate a VL. >>> >>>Igor >>> >>>-----Original Message----- >>>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>>Sent: Thursday, January 17, 2013 9:53 AM >>>To: Snigdho Bardalai; Igor Bryskin; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Igor, Snigdho, >>> >>>I agree with Snigdho. Why don't we call it provider topology (or >>>whatever) if it includes both virtual links/nodes and real >>links/nodes?=20 >>>I don't think it has anything to deal with naming space. >>> >>>Further replies in line >>> >>>I'd like to have feedbacks from you and all on Open Issue 4.=20 >>>That's an advertisement models draft issue but it's something that i=20 >>>can't really understand yet. >>> >>>BR >>>Daniele >>> >>>>-----Original Message----- >>>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >>>>Sent: gioved=EC 17 gennaio 2013 5.28 >>>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP >>>>Subject: RE: Overlay model framework v2 >>>> >>>>Hi Igor, >>>> >>>>Not sure if the case you are citing qualifies a real node or >>>link to be >>>>called virtual. The client space name is simply an alias. >>>> >>>>Regards >>>>Snigdho >>>> >>>>> -----Original Message----- >>>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>>> Sent: Wednesday, January 16, 2013 3:04 PM >>>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >>>>> Subject: RE: Overlay model framework v2 >>>>>=20 >>>>> Snigdho, >>>>>=20 >>>>> > 3. Virtual Topology: Virtual topology is a collection=20 >of one or=20 >>>>> > more virtual or real provider network domain nodes that >>exist in >>>>> > the customer layer network and are interconnected via=20 >0 or more=20 >>>>> > virtual links. >>>>>=20 >>>>> [SCB] Since the topology advertised by the provider network can=20 >>>>> contain real or virtual elements, why do we call it "virtual=20 >>>>> topology"? Should it simply be called "provider topology"? >>And then >>>>> specify that it may contain both virtual or real elements. >>>>>=20 >>>>> Virtual topology includes only virtual nodes. Even when we are=20 >>>>> considering real PEs terminating VLs, we must treat the=20 >PEs in the=20 >>>>> context of Virtual Topology as VNs since they must be named >>>from the >>>>> client naming space. >>>>>=20 >>>>> Igor >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>>On Behalf >>>>> Of Snigdho Bardalai >>>>> Sent: Wednesday, January 16, 2013 5:48 PM >>>>> To: Daniele Ceccarelli; CCAMP >>>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>>>=20 >>>>> Hi Daniele, >>>>>=20 >>>>> A few comments. Please see in-line. >>>>>=20 >>>>> Thanks >>>>> Snigdho >>>>>=20 >>>>> > -----Original Message----- >>>>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf >>>>> > Of Daniele Ceccarelli >>>>> > Sent: Wednesday, January 16, 2013 7:33 AM >>>>> > To: CCAMP >>>>> > Subject: [CCAMP] Overlay model framework v2 >>>>> > >>>>> > Dear overlayers, >>>>> > >>>>> > Please find below a new version (v2) of the framework summary=20 >>>>> > reflecting the latest discussions. Again i hope i've >>captured all >>>>> > the comments around, sorry if anything is missing, in case >>>>just let >>>>> > me know what i missed. >>>>> > >>>>> > BR >>>>> > Daniele >>>>> > >>>>> > >>>>> > + Disclaimer: >>>>> > 1. Packet opto integration is often considered but the >>>>work can be >>>>> > extented to any type of SC. Eg. TDM over LSC. >>>>> > >>>>> > + Terminology: >>>>> > 1. Virtual Link: A virtual link is a potential path=20 >between two=20 >>>>> > virtual or real network elements in a provider layer >>>network that >>>>> is >>>>> > maintained/controlled in and by the provider domain >>>control plane >>>>> > (and as such cannot transport any traffic/data and >>protected from >>>>> > being >>>>> > de-provisioned) and which can be instantiated in the=20 >data plane=20 >>>>> > (and then can carry/transport/forward traffic/data) preserving=20 >>>>> > previously advertised attributes such as fate sharing >>>information. >>>>> > 2. Virtual Node: Virtual node is a collection of zero or more=20 >>>>> > provider network domain nodes that are collectively >>>>represented to >>>>> > the clients as a single node that exists in the customer layer=20 >>>>> > network and is capable of terminating of access, >>inter-domain and >>>>> virtual links. >>>>>=20 >>>>> [SCB] Agree with Igor's comment - a virtual node can be a >>>>combination >>>>> of multiple nodes or a part of the single node, but to the >>customer >>>>> node this is transparent. >>> >>>Yes, agree. >>> >>>>>=20 >>>>> > 3. Virtual Topology: Virtual topology is a collection=20 >of one or=20 >>>>> > more virtual or real provider network domain nodes that >>exist in >>>>> > the customer layer network and are interconnected via=20 >0 or more=20 >>>>> > virtual links. >>>>>=20 >>>>> [SCB] Since the topology advertised by the provider network can=20 >>>>> contain real or virtual elements, why do we call it "virtual=20 >>>>> topology"? Should it simply be called "provider topology"? >>And then >>>>> specify that it may contain both virtual or real elements. >>> >>>See above >>> >>>>>=20 >>>>> > 4. Overlay topology: is a superset of virtual >>>topologies provided >>>>> by >>>>> > each of provider network domains, access and=20 >inter-domain links. >>>>>=20 >>>>> [SCB] A more concise definition for the overlay topology is >>>>- CE nodes >>>>> + Access-links + provider topology as advertised by the provider >>>>> network. >>> >>>We wanted to include also the possiblity of having multiple provider=20 >>>domains. >>> >>>>>=20 >>>>> > 5. Access Link: Link between OC and OE. GMPLS runs on >>>>that link. It >>>>> > can support any of the SCs supported by the GMPLS. >>>>> > 6. CE (customer Edge): Something like the CN in RFC4208 >>>>teminology >>>>> > but (i) receiving virtual topology from the provider >>network and >>>>> > requesting the set up of one of them or >>>>> > (ii) requesting the computation and establishment of a path=20 >>>>> > accordingly to given constraints in the provider network and=20 >>>>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. >>>>> > 7. PE (provider Edge): Something like the EN in RFC4208 >>>>but able to >>>>> > deal with (i) and (ii) above. >>>>> > 8. PE-CE interface (former ONI) : Interface allowing for >>>>signaling >>>>> > and routing messages exchange between customer overlay >>>>and provider >>>>> > network. Routing information consists on virtual topology=20 >>>>> > advertisement. When there is no routing adjacency across the >>>>> interface >>>>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling=20 >>>>> > messages are compliant with RFC4208. Information >>related to path >>>>> > carachteristics, e.g. TE-metrics, collected SRLG, path >>>delay etc, >>>>> > either passed from CE to PE via signaling after the LSP=20 >>>>> > establishment in the core network or from CE to PE to=20 >be used as=20 >>>>> > path computation constraints, fall under the definition of=20 >>>>> > signaling info and not routing info). >>>>> > 9. CE-CE (former O-NNI): Interface on the links between >>>different >>>>> > provider networks in the overlay model environment. Same >>>features >>>>> > of the CE-PE apply to this interface. >>>>>=20 >>>>> [SCB] Is this "PE-PE" instead of "CE-CE"? >>> >>>Oooops! Definitely. >>> >>>>>=20 >>>>> > >>>>> > + Statements >>>>> > 1. In the context of overlay model we are aiming to build an=20 >>>>> > overlay topology for the customer network domains 2. >>>The overlay >>>>> > topology >>>>> is >>>>> > comprised of: >>>>> > a) access links (links connecting client NEs to the=20 >provider=20 >>>>> > network domains). >>>>> > They can be PSC or LSC. >>>>> > b) inter-domain links (links interconnecting server network >>>>> > domains) >>>>> > c) virtual topology provided by the provider=20 >network domains. >>>>> > Virtual Links + Virtual Nodes (TBD) + Connectivity >>Matrix (with a >>>>> set >>>>> > of parameters e.g. SRLG, optical impairments, delay=20 >etc for each >>>>> > entry) describing connectivity between access links and virtual >>>>> links. >>>>> > 3. In the context of overlay model we manage hierarchy >>>>of overlay >>>>> > topologies with overlay/underlay relationships 4. In >>>the context >>>>> > of overlay model multi-layering and inter-layer >>>relationships are >>>>> > peripheral at best, it is all about horizontal network >>integration >>>>> 5. >>>>> > The overlay model assumes one CP instance for the >>customer network >>>>> and >>>>> > a separate instance for the provider network and in the CE-PE=20 >>>>> > interface case the provider network also surreptitiously >>>>> participates >>>>> > in the customer network by injecting virtual topology >>>information >>>>> > into it. >>>>>=20 >>>>> [SCB] Specific implementations may or may not have a single >>>instance >>>>> for the provider and the overlay. >>> >>>Mmm, that's true. It MUST work with two different instances >>but no one >>>prevents it to work with a single one. >>> >>>>>=20 >>>>> > 6. L1VPN (and LxVPN) in general is a type of service >>>>provided over >>>>> > the CE-PE interface (it falls under the UNI case as no routing=20 >>>>> > adjacency is in place between CE and PE). >>>>>=20 >>>>> > >>>>> > >>>>> > + Advertisement models (to be detailed in dedicated >>>>> > + document/documents) >>>>> > The CE-PE interface in the overlay model context foresees >>>>two types >>>>> > of advertisement models.(names still to be agreed) A.=20 >>>>Augmented UNI: >>>>> > The GMPLS UNI is defined in RFC4208 and augmented by a >>number of >>>>> > actived draft (references to various drafts to be added). >>>>> > The Augmented UNI is a particular type of CE-PE=20 >interface where=20 >>>>> > only signaling messages are exchanged between CE and PE. >>>Messages >>>>> > from CE to PE can include a set of parameters to be used >>>>by the PE >>>>> > as path computation constraints when computing a path in the=20 >>>>> > provider domain network, while messages from PE to CE can >>>>include a >>>>> > set of >>>>> parameters >>>>> > qualifying the LSP being established, like for example >>>>SRLG, delay, >>>>> > loss etc. >>>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could=20 >be simply=20 >>>>> > called with the general CE-PE interface term?) allowing the=20 >>>>> > establishment of signaling and routing adjacency between >>>>CE and PE. >>>>> > Routing info passed from PE to CE comprise overlay topology=20 >>>>> > information including (but not limited to) virtual links,=20 >>>>> > connectivity matrices and access links with parameters=20 >qualifying >>>>> each >>>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=20 >>>>> > information >>>>> and procedures are compliant with RFC4208. >>>>> > >>>>> > + Open issues/questions >>>>> > 1. PCE-PCEP - do we need to include considerations=20 >about PCE and >>>>> PCEP >>>>> > into the overlay framework context? >>>>>=20 >>>>> [SCB] IMO - this should be described in the overlay >>>>framework document >>>>> to establish the context. >>> >>>+1 >>> >>>>>=20 >>>>> > 2. BGP-LS needs to be considered 3. Should potentials be=20 >>>>> > included? E.g. I2RS? >>>>> > 4. Virtual links: wouldn't a different definition of >>>>virtual links >>>>> > avoid the advertisement of connectivity matrices (this is >>>>out of the >>>>> > fwk scope but within the advertisement models one)? >>>>> > Take this example: >>>>> > PE1-----CE1 CE2-----PE2 >>>>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>>>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be >>available >>>>> for >>>>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1=20 >>>>> > and/or >>>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>>>> > depending on the connectivity matrices of CE1 and CE2.=20 >Hence PEs=20 >>>>> > need to be aware of both VL and connectivity matrices. My >>>>point is:=20 >>>>> > if CE1 advertises to PE1 only the VL that his >>connectivity matrix >>>>> > allows to be connected to PE1 (e.g. VL1 only) and not all >>>of them, >>>>> > it should be possible to avoid the connectivity matrices >>>>advertisement. >>>>> > >>>>> > >>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> > DANIELE CECCARELLI >>>>> > System & Technology - PDU Optical & Metro >>>>> > >>>>> > Via E.Melen, 77 >>>>> > Genova, Italy >>>>> > Phone +390106002512 >>>>> > Mobile +393346725750 >>>>> > daniele.ceccarelli@ericsson.com >>>>> > www.ericsson.com >>>>> > >>>>> > This Communication is Confidential. We only send and >>>receive email >>>>> > on the basis of the term set out at=20 >>>>> > www.ericsson.com/email_disclaimer >>>>> > >>>>> > _______________________________________________ >>>>> > CCAMP mailing list >>>>> > CCAMP@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/ccamp >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> >> > From db3546@att.com Thu Jan 17 11:53:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A7521F8877 for ; Thu, 17 Jan 2013 11:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 z9LLgBkw5w0K for ; Thu, 17 Jan 2013 11:53:53 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAA921F883A for ; Thu, 17 Jan 2013 11:53:53 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 0d658f05.0.1607689.00-499.4459386.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 17 Jan 2013 19:53:53 +0000 (UTC) X-MXL-Hash: 50f856d131e82fc7-99067ccce31889433792573ff26aa355a13aa57e Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0HJrpJB004212 for ; Thu, 17 Jan 2013 11:53:52 -0800 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0HJrlBK004020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jan 2013 11:53:49 -0800 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint04.pst.cso.att.com (RSA Interceptor) for ; Thu, 17 Jan 2013 11:53:25 -0800 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0318.001; Thu, 17 Jan 2013 14:53:24 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 Thread-Index: Ac307E6zS7sVh+DcTsq3U9yZnttyUg== Date: Thu, 17 Jan 2013 19:53:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=fI+OK+me c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=dBC_91PBIbYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=S15YX7xd_bwA:10 a=AUd_NHdVAAAA:8 a=YLzyaleMsNuqIN] X-AnalysisOut: [HW8_IA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:10] Subject: [CCAMP] FW: FW: Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:53:54 -0000 Forwarding for Clarence- -----Original Message----- From: Clarence Filsfils [mailto:cfilsfil@cisco.com]=20 Sent: Thursday, January 17, 2013 2:01 PM To: BRUNGARD, DEBORAH A; Zafar Ali (zali) Subject: Fwd: Attn Clarence: FW: [CCAMP] FW: Regarding IPR on draft-ali-cca= mp-xro-lsp-subobject-02 Hello Deborah, I am not aware of any IPR other than one already noted by Zafar. Cheers, clarence From lberger@labn.net Fri Jan 18 04:53:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0726021F88A8 for ; Fri, 18 Jan 2013 04:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 XjfJVql9ywJX for ; Fri, 18 Jan 2013 04:53:19 -0800 (PST) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 6E22121F85B2 for ; Fri, 18 Jan 2013 04:53:18 -0800 (PST) Received: (qmail 30978 invoked by uid 0); 17 Jan 2013 17:42:36 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 17 Jan 2013 17:42:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=B30N5TgfkFhQLq9DqXRLaLL3BwPFWxnMz2iMnXktPJo=; b=gOVoa3+XObMgneRGXVDaUiVAUdNBMyt/lM+nVbeHyvBSU3++xZZLboqLLZWC/gVZ3I0mXxztMsSiNX98kf7iYBbcKJtLSZCNnCO00bYhD54Y347MLuEVpnJQ794SIGzz; Received: from box313.bluehost.com ([69.89.31.113]:56537 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TvtU4-0001w5-1n; Thu, 17 Jan 2013 10:42:36 -0700 Message-ID: <50F837FB.2010806@labn.net> Date: Thu, 17 Jan 2013 12:42:19 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fatai Zhang References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> <50F58A35.7040806@labn.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 12:53:20 -0000 On 1/15/2013 10:16 PM, Fatai Zhang wrote: > Hi Lou, > > To avoid misunderstanding, I would like to clarify more on the > following point. > > >>>>> It is better to have consistent format and the same meaning of one field for both ODUflex(CBR) and GFP. This is why we have section 5.1 &5.2 to describe the complex stuff. >>>> I actually wasn't suggesting that N be carried in the bit rate field. >>>> The bit rate field can either be set as described or to zero (i.e., >>>> ignored). At the time, I was thinking about carrying N in the reserved >>>> field. But perhaps the right place is MT, if my understanding is right >>>> (would always be 1 otherwise). I'm open to either... >>>> >>> [Fatai] Why not just use 揵it rate攆ield to carry 揘攂ecause 揘 >>> implies bit rate? I am OK if you like to use a new filed (like 揟S >>> Number) to occupy the reserved field even though that I prefer the >>> original approach (ie., use 揵it rate攆ield to carry 揘). >> >> Are you proposing dropping carrying bit rates represented as an IEEE >> floating point and just carrying N for ODUflex? This seems workable to >> me, but we should ensure that there are no significant objections. > > [Fatai] There are two usages for " Bit_Rate " field as described in the > lines 287-310. > > (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal bit > rate of ODUflex(CBR) expressed in bytes per second, encoded as a 32-bit > IEEE single precision floating-point number. For this case, we MUST use > 32-bit IEEE floating point instead of 揘(Please see more in section 5.1). I guess you really still need (to be based on) the client signal rate at the edges. > > (2) For ODUflex(GFP), we can change the text (the lines from 305 to > 310) based on your suggestion, ie., the Bit_Rate field is used to carry > 揘攖o indicate the nominal bit rate of the > ODUflex(GFP). but you're says encoded as (N*Nominal Rate) right? Wat's the value of this vs just carrying N? > > Therefore, I am proposing using one single filed ("Bit_Rate ") for these > two cases, in this way, we can leave the "Reserved" bits for future. bits in the control plane are generally cheap, IMO it's better to have simpler encoding than to optimize every bit (or 8 in this case). Lou > > Hope we are now at the same page. > > > Best Regards > > Fatai From daniele.ceccarelli@ericsson.com Fri Jan 18 06:37:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EA321F88B0 for ; Fri, 18 Jan 2013 06:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.444 X-Spam-Level: X-Spam-Status: No, score=-5.444 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, 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 d1-mEIUXnIcP for ; Fri, 18 Jan 2013 06:37:15 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2560B21F888A for ; Fri, 18 Jan 2013 06:37:08 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-78-50f95e13ad05 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C6.80.32353.31E59F05; Fri, 18 Jan 2013 15:37:08 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.004; Fri, 18 Jan 2013 15:37:07 +0100 From: Daniele Ceccarelli To: Igor Bryskin , Snigdho Bardalai , CCAMP Thread-Topic: Overlay model framework v2 Thread-Index: Ac3z/soRwFLO6lqWmk6S/LNDTw8InAANE4iAAACVKQAAC1BWgAAXfYXg///8zoD//+ZBsIAAKMgA///mkzCAACbfgP//7YLQAAUuroD//p8fwA== Date: Fri, 18 Jan 2013 14:37:07 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806D5D6@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CDD9@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CE44@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja5I3M8Ag31/+SyezLnBYnGqp53R Ylf/P0YHZo+zC/6weixZ8pPJ49KLQ2wBzFFcNimpOZllqUX6dglcGXN+9jIV/JjLWLH0ylWW BsYNjYxdjJwcEgImEl9mv2eFsMUkLtxbz9bFyMUhJHCIUeLa5R3MEM5iRonts56wdzFycLAJ WEk8OeQD0iAiUCAx98AORpCwsIC6xIPr6hBhDYnbh/vZIew6iemLzzGB2CwCqhKf9p0H28sr 4C1x8tFuJojxn9kknm65yAwyh1MgSmL3nWCQGkYBWYkJuxeB1TMLiEvcejKfCeJOAYkle84z Q9iiEi8f/4O6X1Fi59l2Zoh6PYkbU6ewQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKW WUhaFjCyrGJkz03MzEkvN9/ECIyQg1t+G+xg3HRf7BCjNAeLkjhvuOuFACGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2MZcn7xVU7wreuyeU9Lfzq0mQTxZ6Dm55dPWEq0/fS8PfS19nvV+4T sDz9RG0e8/F0zzfyPrm+N+35lRpeHbz7rXR5oedNt7Z1Fc+/RwhctrigdLVl5dr6w8Ip9ksz nSQVbqavrtjQ5VskujuZTdV2Fl+dZt9JyfRlagqLPkw8LNHh0vE4nkdEiaU4I9FQi7moOBEA KbCuL14CAAA= Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 14:37:22 -0000 I like the "MAY" part. I'd add it to the definition. Daniele=20 >-----Original Message----- >From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 >Sent: gioved=EC 17 gennaio 2013 19.34 >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >Daniele, > >You say a real link/node COULD be a part of a Virtual=20 >Topology. (=3D=3D> How a real WDM link or ROADM could be a part of=20 >ODUk Virtual Topology?) I say a real link/node MAY be=20 >represented in it's entirety in a Virtual Topology by a=20 >virtual link/node which has 1:1 cardinality with the said real=20 >link/node. >In other words the representation you are talking about=20 >according to my definition is just one of a variety of ways=20 >real links/nodes could be presented in a Virtual Topology. I=20 >think you are unnecessarily overcomplicating the model by=20 >distinguishing this private case. > >Igor > >-----Original Message----- >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >Sent: Thursday, January 17, 2013 12:20 PM >To: Igor Bryskin; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >I think a virtual link COULD be a real link and a virtual node=20 >COULD be a real node. > >Agree that no provider wants to export the full topology, but=20 >there might be cases in which it could be useful to summarise=20 >a domain in E.G. X virtual nodes plus Y real nodes (where Y=20 >could be very small by !=3D0). I just wanted to include this case also. > >Daniele=20 > >>-----Original Message----- >>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>Sent: gioved=EC 17 gennaio 2013 18.11 >>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>The reason I like term "Virtual Topology" is simply because it is=20 >>entirely made up of virtual elements: nodes and links. If you agree=20 >>with me that provider does not disclose any of its real network=20 >>topology information, I don't see why the terms "Exported Provider=20 >>Topology" or "Summarized Provider Topology" >>are better/less confusing. >> >>-----Original Message----- >>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>Sent: Thursday, January 17, 2013 12:04 PM >>To: Igor Bryskin; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Does this mean: the topology passed from the PE to the CE?=20 >>(hope this time i correctly used the acronims!!!) >> >>The new definition looks good to me if you're referring to=20 >the virtual=20 >>links/nodes only, but doesn't consider real links/nodes any longer. >> >>I prefer the old definition and call it as Pavan suggested:=20 >>Exported Provider Topology" or "Summarized Provider Topology" >> >>BR >>Daniele >> >>>-----Original Message----- >>>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>Sent: gioved=EC 17 gennaio 2013 17.23 >>>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Daniele, >>> >>>What I was saying is that the definition: >>>> 3. Virtual Topology: Virtual topology is a collection of >>>one or more >>>> virtual or real provider network domain nodes that exist in the=20 >>>> customer layer network and are interconnected via 0 or >>more virtual >>>> links. >>>Is not correct. It should say IMO: >>>3. Virtual Topology: Virtual topology is a collection of one or more=20 >>>virtual nodes, supported by one or more provider network >>domains, which >>>exist in the customer layer network and are interconnected =20 >via 0 or=20 >>>more virtual links, supported by one or more provider network domains >>> >>>-----Original Message----- >>>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>>Sent: Thursday, January 17, 2013 11:10 AM >>>To: Igor Bryskin; Snigdho Bardalai; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>What you say is more than true but orthogonal to my point :-) >>> >>>It's only a matter of terminology. We defined: >>> >>>> 3. Virtual Topology: Virtual topology is a collection of >>>one or more >>>> virtual or real provider network domain nodes that exist in the=20 >>>> customer layer network and are interconnected via 0 or >>more virtual >>>> links. >>> >>>If we call it "Virtual Topology", the first thing that comes to the=20 >>>minds is: its only a collection of virtual links and virtual nodes. >>>Snigdho's proposal was to call it differently so to better >>identify the >>>fact that it includes both virtual and real links/nodes, that's it. >>>The name he proposed, however, is again misleading, because >>calling it >>>"provider topology" makes me (and you) thinking of just real=20 >>>links/nodes, doesn't it? >>> >>>I would suggest not to use either of the terms as both are >>misleading.=20 >>>Maybe something like "exported topology", "CE-PE tology" or whatever. >>> >>>Daniele >>> >>>>-----Original Message----- >>>>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>>Sent: gioved=EC 17 gennaio 2013 16.29 >>>>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>>>Subject: RE: Overlay model framework v2 >>>> >>>>Daniele, >>>> >>>>We want to separate a Virtual Topology advertised to the >>>clients (which >>>>is, generally speaking, different for different sets of >>clients) from >>>>provider real topology, which must be concealed from the clients. >>>>I disagree with Snigdho, when he is saying that a PE just has >>>multiple >>>>aliases (one from each client name space). There is much >>more to this. >>>>The way I see it a PE contributes differently to different Virtual=20 >>>>Topologies (each time with a different ID, sometimes as a whole,=20 >>>>sometimes as split into several VNs, sometimes as a part of a >>>large VN, >>>>possibly with a separate connectivity matrix. it also, depending on=20 >>>>Virtual Topology, presents itself as switch of a different layer=20 >>>>network, and so forth). Therefore, PE in the context of Virtual=20 >>>>Topology is always a Virtual Node, even when it is mapped 1:1 >>>onto real >>>>provider switch. In general, only VN can terminate a VL. >>>> >>>>Igor >>>> >>>>-----Original Message----- >>>>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>>>Sent: Thursday, January 17, 2013 9:53 AM >>>>To: Snigdho Bardalai; Igor Bryskin; CCAMP >>>>Subject: RE: Overlay model framework v2 >>>> >>>>Igor, Snigdho, >>>> >>>>I agree with Snigdho. Why don't we call it provider topology (or >>>>whatever) if it includes both virtual links/nodes and real >>>links/nodes?=20 >>>>I don't think it has anything to deal with naming space. >>>> >>>>Further replies in line >>>> >>>>I'd like to have feedbacks from you and all on Open Issue 4.=20 >>>>That's an advertisement models draft issue but it's=20 >something that i=20 >>>>can't really understand yet. >>>> >>>>BR >>>>Daniele >>>> >>>>>-----Original Message----- >>>>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >>>>>Sent: gioved=EC 17 gennaio 2013 5.28 >>>>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP >>>>>Subject: RE: Overlay model framework v2 >>>>> >>>>>Hi Igor, >>>>> >>>>>Not sure if the case you are citing qualifies a real node or >>>>link to be >>>>>called virtual. The client space name is simply an alias. >>>>> >>>>>Regards >>>>>Snigdho >>>>> >>>>>> -----Original Message----- >>>>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>>>> Sent: Wednesday, January 16, 2013 3:04 PM >>>>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >>>>>> Subject: RE: Overlay model framework v2 >>>>>>=20 >>>>>> Snigdho, >>>>>>=20 >>>>>> > 3. Virtual Topology: Virtual topology is a collection >>of one or >>>>>> > more virtual or real provider network domain nodes that >>>exist in >>>>>> > the customer layer network and are interconnected via >>0 or more >>>>>> > virtual links. >>>>>>=20 >>>>>> [SCB] Since the topology advertised by the provider network can=20 >>>>>> contain real or virtual elements, why do we call it "virtual=20 >>>>>> topology"? Should it simply be called "provider topology"? >>>And then >>>>>> specify that it may contain both virtual or real elements. >>>>>>=20 >>>>>> Virtual topology includes only virtual nodes. Even when we are=20 >>>>>> considering real PEs terminating VLs, we must treat the >>PEs in the >>>>>> context of Virtual Topology as VNs since they must be named >>>>from the >>>>>> client naming space. >>>>>>=20 >>>>>> Igor >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>>>On Behalf >>>>>> Of Snigdho Bardalai >>>>>> Sent: Wednesday, January 16, 2013 5:48 PM >>>>>> To: Daniele Ceccarelli; CCAMP >>>>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>>>>=20 >>>>>> Hi Daniele, >>>>>>=20 >>>>>> A few comments. Please see in-line. >>>>>>=20 >>>>>> Thanks >>>>>> Snigdho >>>>>>=20 >>>>>> > -----Original Message----- >>>>>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>> Behalf >>>>>> > Of Daniele Ceccarelli >>>>>> > Sent: Wednesday, January 16, 2013 7:33 AM >>>>>> > To: CCAMP >>>>>> > Subject: [CCAMP] Overlay model framework v2 >>>>>> > >>>>>> > Dear overlayers, >>>>>> > >>>>>> > Please find below a new version (v2) of the framework summary=20 >>>>>> > reflecting the latest discussions. Again i hope i've >>>captured all >>>>>> > the comments around, sorry if anything is missing, in case >>>>>just let >>>>>> > me know what i missed. >>>>>> > >>>>>> > BR >>>>>> > Daniele >>>>>> > >>>>>> > >>>>>> > + Disclaimer: >>>>>> > 1. Packet opto integration is often considered but the >>>>>work can be >>>>>> > extented to any type of SC. Eg. TDM over LSC. >>>>>> > >>>>>> > + Terminology: >>>>>> > 1. Virtual Link: A virtual link is a potential path >>between two >>>>>> > virtual or real network elements in a provider layer >>>>network that >>>>>> is >>>>>> > maintained/controlled in and by the provider domain >>>>control plane >>>>>> > (and as such cannot transport any traffic/data and >>>protected from >>>>>> > being >>>>>> > de-provisioned) and which can be instantiated in the >>data plane >>>>>> > (and then can carry/transport/forward traffic/data)=20 >preserving=20 >>>>>> > previously advertised attributes such as fate sharing >>>>information. >>>>>> > 2. Virtual Node: Virtual node is a collection of=20 >zero or more=20 >>>>>> > provider network domain nodes that are collectively >>>>>represented to >>>>>> > the clients as a single node that exists in the=20 >customer layer=20 >>>>>> > network and is capable of terminating of access, >>>inter-domain and >>>>>> virtual links. >>>>>>=20 >>>>>> [SCB] Agree with Igor's comment - a virtual node can be a >>>>>combination >>>>>> of multiple nodes or a part of the single node, but to the >>>customer >>>>>> node this is transparent. >>>> >>>>Yes, agree. >>>> >>>>>>=20 >>>>>> > 3. Virtual Topology: Virtual topology is a collection >>of one or >>>>>> > more virtual or real provider network domain nodes that >>>exist in >>>>>> > the customer layer network and are interconnected via >>0 or more >>>>>> > virtual links. >>>>>>=20 >>>>>> [SCB] Since the topology advertised by the provider network can=20 >>>>>> contain real or virtual elements, why do we call it "virtual=20 >>>>>> topology"? Should it simply be called "provider topology"? >>>And then >>>>>> specify that it may contain both virtual or real elements. >>>> >>>>See above >>>> >>>>>>=20 >>>>>> > 4. Overlay topology: is a superset of virtual >>>>topologies provided >>>>>> by >>>>>> > each of provider network domains, access and >>inter-domain links. >>>>>>=20 >>>>>> [SCB] A more concise definition for the overlay topology is >>>>>- CE nodes >>>>>> + Access-links + provider topology as advertised by the provider >>>>>> network. >>>> >>>>We wanted to include also the possiblity of having multiple=20 >provider=20 >>>>domains. >>>> >>>>>>=20 >>>>>> > 5. Access Link: Link between OC and OE. GMPLS runs on >>>>>that link. It >>>>>> > can support any of the SCs supported by the GMPLS. >>>>>> > 6. CE (customer Edge): Something like the CN in RFC4208 >>>>>teminology >>>>>> > but (i) receiving virtual topology from the provider >>>network and >>>>>> > requesting the set up of one of them or >>>>>> > (ii) requesting the computation and establishment of a path=20 >>>>>> > accordingly to given constraints in the provider network and=20 >>>>>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI= . >>>>>> > 7. PE (provider Edge): Something like the EN in RFC4208 >>>>>but able to >>>>>> > deal with (i) and (ii) above. >>>>>> > 8. PE-CE interface (former ONI) : Interface allowing for >>>>>signaling >>>>>> > and routing messages exchange between customer overlay >>>>>and provider >>>>>> > network. Routing information consists on virtual topology=20 >>>>>> > advertisement. When there is no routing adjacency across the >>>>>> interface >>>>>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling=20 >>>>>> > messages are compliant with RFC4208. Information >>>related to path >>>>>> > carachteristics, e.g. TE-metrics, collected SRLG, path >>>>delay etc, >>>>>> > either passed from CE to PE via signaling after the LSP=20 >>>>>> > establishment in the core network or from CE to PE to >>be used as >>>>>> > path computation constraints, fall under the definition of=20 >>>>>> > signaling info and not routing info). >>>>>> > 9. CE-CE (former O-NNI): Interface on the links between >>>>different >>>>>> > provider networks in the overlay model environment. Same >>>>features >>>>>> > of the CE-PE apply to this interface. >>>>>>=20 >>>>>> [SCB] Is this "PE-PE" instead of "CE-CE"? >>>> >>>>Oooops! Definitely. >>>> >>>>>>=20 >>>>>> > >>>>>> > + Statements >>>>>> > 1. In the context of overlay model we are aiming to build an=20 >>>>>> > overlay topology for the customer network domains 2. >>>>The overlay >>>>>> > topology >>>>>> is >>>>>> > comprised of: >>>>>> > a) access links (links connecting client NEs to the >>provider >>>>>> > network domains). >>>>>> > They can be PSC or LSC. >>>>>> > b) inter-domain links (links interconnecting server network >>>>>> > domains) >>>>>> > c) virtual topology provided by the provider >>network domains. >>>>>> > Virtual Links + Virtual Nodes (TBD) + Connectivity >>>Matrix (with a >>>>>> set >>>>>> > of parameters e.g. SRLG, optical impairments, delay >>etc for each >>>>>> > entry) describing connectivity between access links and virtual >>>>>> links. >>>>>> > 3. In the context of overlay model we manage hierarchy >>>>>of overlay >>>>>> > topologies with overlay/underlay relationships 4. In >>>>the context >>>>>> > of overlay model multi-layering and inter-layer >>>>relationships are >>>>>> > peripheral at best, it is all about horizontal network >>>integration >>>>>> 5. >>>>>> > The overlay model assumes one CP instance for the >>>customer network >>>>>> and >>>>>> > a separate instance for the provider network and in the CE-PE=20 >>>>>> > interface case the provider network also surreptitiously >>>>>> participates >>>>>> > in the customer network by injecting virtual topology >>>>information >>>>>> > into it. >>>>>>=20 >>>>>> [SCB] Specific implementations may or may not have a single >>>>instance >>>>>> for the provider and the overlay. >>>> >>>>Mmm, that's true. It MUST work with two different instances >>>but no one >>>>prevents it to work with a single one. >>>> >>>>>>=20 >>>>>> > 6. L1VPN (and LxVPN) in general is a type of service >>>>>provided over >>>>>> > the CE-PE interface (it falls under the UNI case as=20 >no routing=20 >>>>>> > adjacency is in place between CE and PE). >>>>>>=20 >>>>>> > >>>>>> > >>>>>> > + Advertisement models (to be detailed in dedicated >>>>>> > + document/documents) >>>>>> > The CE-PE interface in the overlay model context foresees >>>>>two types >>>>>> > of advertisement models.(names still to be agreed) A.=20 >>>>>Augmented UNI: >>>>>> > The GMPLS UNI is defined in RFC4208 and augmented by a >>>number of >>>>>> > actived draft (references to various drafts to be added). >>>>>> > The Augmented UNI is a particular type of CE-PE >>interface where >>>>>> > only signaling messages are exchanged between CE and PE. >>>>Messages >>>>>> > from CE to PE can include a set of parameters to be used >>>>>by the PE >>>>>> > as path computation constraints when computing a path in the=20 >>>>>> > provider domain network, while messages from PE to CE can >>>>>include a >>>>>> > set of >>>>>> parameters >>>>>> > qualifying the LSP being established, like for example >>>>>SRLG, delay, >>>>>> > loss etc. >>>>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could >>be simply >>>>>> > called with the general CE-PE interface term?) allowing the=20 >>>>>> > establishment of signaling and routing adjacency between >>>>>CE and PE. >>>>>> > Routing info passed from PE to CE comprise overlay topology=20 >>>>>> > information including (but not limited to) virtual links,=20 >>>>>> > connectivity matrices and access links with parameters >>qualifying >>>>>> each >>>>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=20 >>>>>> > information >>>>>> and procedures are compliant with RFC4208. >>>>>> > >>>>>> > + Open issues/questions >>>>>> > 1. PCE-PCEP - do we need to include considerations >>about PCE and >>>>>> PCEP >>>>>> > into the overlay framework context? >>>>>>=20 >>>>>> [SCB] IMO - this should be described in the overlay >>>>>framework document >>>>>> to establish the context. >>>> >>>>+1 >>>> >>>>>>=20 >>>>>> > 2. BGP-LS needs to be considered 3. Should potentials be=20 >>>>>> > included? E.g. I2RS? >>>>>> > 4. Virtual links: wouldn't a different definition of >>>>>virtual links >>>>>> > avoid the advertisement of connectivity matrices (this is >>>>>out of the >>>>>> > fwk scope but within the advertisement models one)? >>>>>> > Take this example: >>>>>> > PE1-----CE1 CE2-----PE2 >>>>>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>>>>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>>>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be >>>available >>>>>> for >>>>>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1=20 >>>>>> > and/or >>>>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>>>>> > depending on the connectivity matrices of CE1 and CE2. >>Hence PEs >>>>>> > need to be aware of both VL and connectivity matrices. My >>>>>point is:=20 >>>>>> > if CE1 advertises to PE1 only the VL that his >>>connectivity matrix >>>>>> > allows to be connected to PE1 (e.g. VL1 only) and not all >>>>of them, >>>>>> > it should be possible to avoid the connectivity matrices >>>>>advertisement. >>>>>> > >>>>>> > >>>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> > DANIELE CECCARELLI >>>>>> > System & Technology - PDU Optical & Metro >>>>>> > >>>>>> > Via E.Melen, 77 >>>>>> > Genova, Italy >>>>>> > Phone +390106002512 >>>>>> > Mobile +393346725750 >>>>>> > daniele.ceccarelli@ericsson.com >>>>>> > www.ericsson.com >>>>>> > >>>>>> > This Communication is Confidential. We only send and >>>>receive email >>>>>> > on the basis of the term set out at=20 >>>>>> > www.ericsson.com/email_disclaimer >>>>>> > >>>>>> > _______________________________________________ >>>>>> > CCAMP mailing list >>>>>> > CCAMP@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/ccamp >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>> >>> >> >= From daniele.ceccarelli@ericsson.com Fri Jan 18 07:54:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAC021F8824 for ; Fri, 18 Jan 2013 07:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.157 X-Spam-Level: X-Spam-Status: No, score=-5.157 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_37=0.6, J_CHICKENPOX_51=0.6, 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 R50mwX+6PqTV for ; Fri, 18 Jan 2013 07:54:32 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7A70B21F881A for ; Fri, 18 Jan 2013 07:54:31 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-1b-50f97036172a Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D5.02.10459.63079F05; Fri, 18 Jan 2013 16:54:30 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.004; Fri, 18 Jan 2013 16:54:29 +0100 From: Daniele Ceccarelli To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt Thread-Index: AQHN0q1CtM7xyI06Pk6wLux+sh8SWpggyrwAgACr+ICAAObagIAA/nUQgABAtwCAHDAwkIABqhyAgALpGHCAAF5NAIAKwThQ Date: Fri, 18 Jan 2013 15:54:28 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806DAE9@ESESSMB301.ericsson.se> References: <20121128073754.7548.6383.idtracker@ietfa.amsl.com> <50BE6C54.7060606@labn.net> <50D24D68.5040005@labn.net> <4A1562797D64E44993C5CBF38CF1BE4804556A@ESESSMB301.ericsson.se> <50D39F51.8010802@labn.net> <4A1562797D64E44993C5CBF38CF1BE48046263@ESESSMB301.ericsson.se> <50D4AB0E.6070207@labn.net> <4A1562797D64E44993C5CBF38CF1BE4805D2BB@ESESSMB301.ericsson.se> <50EDB5E1.5040200@labn.net> <4A1562797D64E44993C5CBF38CF1BE4805E624@ESESSMB301.ericsson.se> <50F07604.5080705@labn.net> In-Reply-To: <50F07604.5080705@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja5Zwc8AgyVrZS2ezLnBYvG34TWL RUfzWxYHZo8lS34yeXzY1Mzm8eXyZ7YA5igum5TUnMyy1CJ9uwSujI77p5kLJl5lqjh+cyNL A+OiPqYuRk4OCQETiSsL1rBD2GISF+6tZwOxhQQOMUq86hGGsBczStw/5tPFyMHBJmAl8eSQ D0hYREBR4uvHRUBjuDiYBVoZJVadewE2U1jAS2LqrqtMIPUiAt4Sd25kQ9TnSbw485YZxGYR UJVY/ecaI4jNC1Sy5/EGsDlCAj+ZJQ6dncgO0sspoCHx5WEySA2jgKzEhN2LwOqZBcQlbj2Z D3W+gMSSPeeZIWxRiZeP/7FC2IoSO8+2M0PU60ncmDqFDcLWlli28DUzxF5BiZMzn7BMYBSb hWTsLCQts5C0zELSsoCRZRUje25iZk56ueEmRmDcHNzyW3cH46lzIocYpTlYlMR5w1wvBAgJ pCeWpGanphakFsUXleakFh9iZOLglGpgZLSfwcfB5a9udsPs7+P1Hskq763lLA23Surad7Bz 8Dp4d+oyBCQ/mz7hwi821Q192k9/hehpPF/jcM3IJXqGQH9plkS52MmaKbMmXlHc+cZRLXJi V/t9vpb5X98Kym9dOKOoIrxf3D1t6VMu323LrkzburhTxGOH8imOolhZ1+T88543kw8osRRn JBpqMRcVJwIAc549XmkCAAA= Cc: CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:54:35 -0000 Ok for the all except the reference:=20 >How about replace line with with: >"as, per [G.709], this type also implies support for type 22=20 >adaptation." I would just remove the reference and keep the rest. By the way it should b= e G.7044. BR Daniele >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net]=20 >Sent: venerd=EC 11 gennaio 2013 21.29 >To: Daniele Ceccarelli >Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >Subject: Re: [CCAMP] I-D Action:=20 >draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt > >Daniele, > I think the following is the sole open point! > >Some minor changes: > >> How about: >> >> NEW >> With respect to ODUflex, three different signal types are allowed: 20 >> - ODUflex Constant Bit Rate (CBR), 21 - ODUflex Generig Framing >s/Generig/Generic >> Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex=20 >(GFP-F) non=20 >> resizable. They MUST always be advertised in separate Type 2 TLVs as >s/They/Each >> they use different adaptation functions [G.805]. In case both GFP-F >s/they/each >s/In case/In the case that >> resizable and non resizable (i.e. 21 and 22) are supported, only=20 >> Signal Type 21 MUST be advertised >s/MUST/SHALL >>as resizable ODUflex implies non resizable one. >How about replace line with with: >"as, per [G.709], this type also implies support for type 22=20 >adaptation." > >(please confirm the reference). > >>Signal Type 22 MUST be used when only non resizable ODUflex is=20 >>supported. >>=20 > >Much thanks, > >Lou > >On 1/11/2013 9:18 AM, Daniele Ceccarelli wrote: >> Hi Lou, >>=20 >> Please see below. >>=20 >> BR >> Daniele & Sergio >>=20 >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: mercoled=EC 9 gennaio 2013 19.25 >>> To: Daniele Ceccarelli >>> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>> Subject: Re: [CCAMP] I-D Action:=20 >>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>> >>> Daniele, >>> >>> see below. >>> >>> >>> On 1/8/2013 12:39 PM, Daniele Ceccarelli wrote: >>>> Hi Lou, >>>> >>>> Please find further comments in line. >>>> >>>> Since the changes from v04 start to be quite a lot we >>> published v05. Please provide further comments (if any)=20 >with respect=20 >>> to that version. >>>> >>> >>> Okay. Note that you have a nit to clean up the next time=20 >you update: >>> http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft >> -ietf-ccamp-gmpls-ospf-g709v3-05.txt >>> >>=20 >> fixed >>=20 >>> >>>> BR >>>> Daniele & Sergio >>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: venerd=EC 21 dicembre 2012 19.32 >>>>> To: Daniele Ceccarelli >>>>> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>>> Subject: Re: [CCAMP] I-D Action:=20 >>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>> >>>>> Daniele, >>>>> Much thanks -- I do expect that the thread might extend >>> beyond the >>>>> end of year holiday, and that many/most are off next week... >>>>> >>>>> See below for responses. >>>>> >>>>> On 12/21/2012 10:49 AM, Daniele Ceccarelli wrote: >>>>>> Hi Lou, >>>>>> >>>>>> Please see in line. >>>>>> >>>>>> We'll upload -05 when all the issues will be solved. >>>>>> >>>>>> BR >>>>>> Daniele & Sergio >>>>>> >>>>>> PS. The info model after christmas holidays >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>> Sent: venerd=EC 21 dicembre 2012 0.29 >>>>>>> To: Daniele Ceccarelli >>>>>>> Cc: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>>>>> Subject: Re: [CCAMP] I-D Action:=20 >>>>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>>> >>>>>>> Daniele / Authors, >>>>>>> Thank you for the response. Please see below=20 >for my responses. >>>>>>> >>>>>>> >>>>>>> On 12/20/2012 3:57 AM, Daniele Ceccarelli wrote: >>>>>>>> Hi Lou, >>>>>>>> >>>>>>>> Below you can find the last call comments pasted with >>>>>>> replies in line. >>>>>>>> >>>>>>>> All nits, typos and suggested text changes without any >>>>>>> comment in line >>>>>>>> have been accepted/modified accordingly. >>>>>>>> >>>>>>> >>>>>>>> BR >>>>>>>> Daniele & Sergio >>>>>>>> >>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>>>>>>> On Behalf >>>>>>>>> Of Lou Berger >>>>>>>>>> Sent: mercoled=EC 26 ottobre 2011 0.37 >>>>>>>>>> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org >>>>>>>>>> Cc: CCAMP >>>>>>>>>> Subject: [CCAMP] some comments on gmpls-ospf-g709v3-00 >>>>>>>>> ... >>>>>>>>>> 2) SCSI TLV formatting >>>>>>>>>> >>>>>>>>>> The field descriptions are missing format related conformance >>>>>>>>>> (RFC2119) language. >>>>>>>>>> >>>>>>>> >>>>>>>> Done >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Some points: >>>>>>> (Using line numbers from >>>>>>> http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft >>>>>> -ietf-ccamp-gmpls-ospf-g709v3-04.txt) >>>>>>> >>>>>>> I like your solution for the general TLV format definition. >>>>>>> >>>>>>> Lines 303/304: "Different sub-TLV MAY be presented in >>>>> ascending Type >>>>>>> order." >>>>>>> >>>>>>> I suspect you mean s/Different sub-TLV/Multiple sub-TLVs >>>>>>> >>>>>> >>>>>> See below >>>>>> >>>>>>> By "ascending Type order", are you refering to the TLV type?=20 >>>>>>> Are multiple TLVs of the same type allowed? If not, how >>> are errors >>>>>>> handled? >>>>>> >>>>>> Yes and yes. Multiple TLVs of the same type are often >>>>> present as each of them represents a branch of the muxing tree. >>>>>> What about changing into: >>>>>> >>>>>> Sub-TLV SHOULD be presented >>>>>> in ascending Type order (i.e. type 1 before and type 2 after). >>>>> >>>>> Is there any technical reason for such ordering? It=20 >doesn't seem to=20 >>>>> add any value to me. >>>> >>>> Ok. It was meant to be just a guideline but indeed doesn't add any=20 >>>> value. Sentence removed. >>>> >>>>> >>>>> I actually was expecting you to say something referring back to=20 >>>>> signal type or number of stages represented in the TLV... >>>> >>>> WRT signal type each TLV is self-consistent, in the sense >>> that there is no need to have them in a given order. In all the=20 >>> example we have ordered them form the root to the leaves of=20 >the tree=20 >>> so to make it more "human-readable". We could suggest to=20 >follow that=20 >>> orded but like in the case of type 1 and type2 is does not add any=20 >>> value (except being more easily read). >>>> >>>> WRT to number of stage the order is important. Actually the >>> text says that they MUST be put is ascending order and an example >>> (ODU1->ODU2->ODU3) is provided: >>>> >>>> OLD >>>> - Stage#1 ... Stage#N : These fields are 8 bits long.=20 >>> Their number is variable and a field is present for >>>> each of the indicated number of stages. The last one >>> MUST always indicate the server ODU container (ODUk/OTUk) >>>> and they MUST be listed in ascending order from the >>> smallest to the biggest one. >>>> The values of the Stage fields MUST be the same ones >>> defined for the Signal Type field. If >>>> the number of stages is 0, then the Stage and Padding >>> fields MUST be omitted. >>>> =20 >>>> Example: in case the ODU1->ODU2->OD3 hierarchy, the >>> Signal Type field is set to ODU1 and >>>> two Stage fields are present, the first indicating >>> ODU2 and the second ODU3 (server layer).=20 >>>> =20 >>>> We added: "from the smallest to the biggest one." at the end >>> of the first sentence: >>>> >>>> NEW: =20 >>>> [CUT] =20 >>>> The last one MUST always indicate the server ODU >>> container (ODUk/OTUk) >>>> and they MUST be listed in ascending order from the >>> smallest to the biggest one. >>>> [CUT] >>>> >>>>> >>>>>> >>>>>>> >>>>>>> Lines 306-322: >>>>>>> >>>>>>> Given that Figures 4 and 5 completely repeat the information in=20 >>>>>>> Figure 4, I propose that you drop Figure 4. (and align the >>>>> preceding >>>>>>> paragraph to match.) >>>>>> >>>>>> Figure 4 and 5 represent TLV type1 and TLV type2 >>>>> respectively, which are quite different from each other.=20 >>> The first 3 >>>>> rows are identical but the rest of the TLV is pretty=20 >different. We=20 >>>>> would prefer to keep both of them. >>>>>> >>>>> >>>>> Ahh. Sorry, let me try again: >>>>> >>>>> Given that Figures 4 and 5 completely repeat the information in=20 >>>>> Figure *4*, I propose that you drop Figure *3*. (and align the=20 >>>>> preceding paragraph to match.) >>>> >>>> Done >>>> >>>> OLD >>>> The format of the SCSI MUST be as depicted in the >>> following figure, where >>>> one Type 1 sub-TLV MUST be used for any fixed container >>> and one Type 2 sub-TLV >>>> MUST be used for any variable container.=20 >>>> NEW >>>> The SCSI MUST include one Type 1 sub-TLV for any fixed >>> container and one Type 2 sub-TLV >>>> for any variable container.=20 >>>> >>> >>> I think this new/revised text is ambiguous: >>> >>> You say "one ... for any" (twice). Is this one for each, or one for=20 >>> all (containers)? >>=20 >> Yes...One for each...corrected. >>=20 >>> >>> The flow into the next paragraph is a bit hard to follow. >>> >> How about: >>=20 >> NEW >> With respect to ODUflex, three different signal types are allowed: >> 20 - ODUflex Constant Bit Rate (CBR), 21 - ODUflex=20 >Generig Framing=20 >> Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) >> non resizable. They MUST always be >> advertised in separate Type 2 TLVs as they use different=20 >adaptation >> functions [G.805]. In case both GFP-F resizable and non >> resizable (i.e. 21 and 22) are supported, only Signal=20 >Type 21 MUST be >> advertised as resizable ODUflex implies non resizable one. >> Signal Type 22 MUST be used when only non resizable ODUflex >> is supported. >>=20 >>=20 >>>>> >>>>> Also, just realized that figures 4 and 5 really should >>> indicate that >>>>> priorities are not always included. And that a second >>> padding field >>>>> may be needed too! How about: >>>>> >>>>> >>>>> 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 >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Type =3D 1 (Unres-fix) | Length =20 > | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Signal Type | Num of Stages |T|S| TSG | Res | =20 >Priority | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Stage#1 | ... | Stage#N | =20 >Padding | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Unreserved ODUj at Prio 0 | ..... =20 > | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Unreserved ODUj at Prio 7 | Unreserved=20 >Padding | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> Figure 4: Bandwidth TLV - Type 1 - >>>> >>>> OK. Wrote padding instead of unreserved Padding >>>> >>>>> >>>>> >>>>> 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 >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Type =3D 2 (Unres/MAX-var) | Length =20 > | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Signal Type | Num of Stages |T|S| TSG | Res | =20 >Priority | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Stage#1 | ... | Stage#N | =20 >Padding | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Unreserved Bandwidth at priority 0 =20 > | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | ... =20 > | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Unreserved Bandwidth at priority 7 =20 > | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Maximum LSP Bandwidth at priority 0 =20 > | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | ... =20 > | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Maximum LSP Bandwidth at priority 7 =20 > | >>>>> =20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> Figure 5: Bandwidth TLV - Type 2 - >>>>> >>>>> (Note some field names have been expanded to match descriptions) >>>> >>>> OK >>>> >>>>> >>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> 3) SCSI TLV procedures >>>>>>>>>> >>>>>>>>>> You have defined the formats of the TLVs in Section >>> 4.1, but not >>>>>>>>>> explicitly how they are to be used. Some RFC2119 language >>>>>>> really is >>>>>>>>>> needed to cover how the SCSI is to be encoded and=20 >parsed. At a=20 >>>>>>>>>> minimum, any TLV inclusion, ordering requirements, and >>> exception >>>>>>>>>> handling should be covered. (For example, your examples >>>>>>>>> always show a >>>>>>>>>> particular ordering relative to Stage#, is this required, >>>>>>>>> recommended, >>>>>>>>>> or just a possibility. You have some informative language, >>>>>>> which is >>>>>>>>>> great, but you also need some RFC2119 language.) >>>>>>>> >>>>>>>> Done >>>>>>> >>>>>>> The length of each TLV type and each field should be defined.=20 >>>>>>> (You have it for some fields, but not others). >>>>>> >>>>>> Now all of them should have been filled. >>>>>> >>>>> >>>>> great. >>>>> >>>>>>> >>>>>>> 414 With respect to ODUflex, ODUflex Constant Bit Rate=20 >(CBR) and >>>>>>> 415 ODUflex Generig Framing Procedure-Frame mapped (GFP-F) MUST >>>>>>> 416 always be advertised separately as they use different >>>>>>> 417 adaptation functions. In the case both GFP-F=20 >resizable and=20 >>>>>>> non >>>>>>> 418 resizable (i.e. 21 and 22) are supported, Signal Type 21 >>>>>>> 419 implicitely supports also signal Signal Type 22, so >>>>> only Signal >>>>>>> 420 Type 21 MUST be advertised. Signal Type 22 MUST be used=20 >>>>>>> only >>>>>>> 421 for non resizable resources. >>>>>>> >>>>>>> Shouldn't this text be moved to after line 304? >>>>>> >>>>>> Agree. Done. >>>>> >>>>> great. >>>>> >>>>>> >>>>>>> >>>>>>> Line 416: By separately do you mean "in separate TLVs"? >>>>>> >>>>>> Yes.changed >>>>> >>>>> great. >>>>> >>>>>>> >>>>>>> Lines 416/7: Your reference to "different adaptation >>>>> functions" lacks >>>>>>> context as it is the sole reference in the document to >>> "adaptation >>>>>>> functions". I think you need to either define this >>>>> terminology (via >>>>>>> reference is fine) or replace it some other terminology. >>>>>>> >>>>>> >>>>>> Reference to [G.805] added >>>>> >>>>> okay. Given the signal type definitions are in [OTN-SIG], what=20 >>>>> additional information is added by this paragraph? What am >>> I missing? >>>> >>>> Things are quite different between signaling and routing >>> when it comes to "implication". In the case of signaling you either=20 >>> signal type 21 o 22, while in the case of routing if both=20 >of them are=20 >>> supported there is no need to advertise both of them and=20 >just signal=20 >>> type 21 is enough because it implies also signal type 22 support. >>>> >>>>> >>>>>> >>>>>>> Line 419/whole document: Please double check the document for=20 >>>>>>> spelling errors (there's one in the above paragraph.) >>> >>> you still have some errors... >>=20 >> No more errors seems to be there according to the spell=20 >check, if there are any left please indicate them explicitely. >>=20 >>> >>>>>>> >>>>>>> Line 423: >>>>>>> >>>>>>> By "number of multiplexing stages level below the >>> indicated signal >>>>>>> type", do you mean "number of multiplexing stages=20 >represented as=20 >>>>>>> transporting the indicated signal type"? >>>>>>> >>>>>>> Lines 424-426. It's best not to define semantics through >>> example. =20 >>>>>>> How about replacing 423-426 with: >>>>>>> >>>>>>> - Number of stages (8 bits): This field indicates the number of=20 >>>>>>> multiplexing stages used to transport the indicated >>> signal type. It >>>>>>> MUST be set to the number of stages represented in the TLV. >>>>>>> >>>>>> OK >>>>>> >>>>>>> >>>>>>> Line 428: s/Flags:/Flags (8 bits) >>>>>> >>>>>> ok >>>>>>> >>>>>>> Lines 455-462: should be revised to use 2119=20 >conformance language=20 >>>>>>> (and to clarify the malformed text.) >>>>>> >>>>>> OK >>> >>> OLD >>> >>> 409 Value 1 MUST be used on those interfaces where the fallback 410=20 >>> procedure is enabled and the default value of >>> 1.25 Gbps can be >>> 411 falled back to 2.5 if needed. Value 2 MUST be used on [RFC4328] >>> 412 interfaces while value 3 MUST be used on [G.709-2012] interfaces >>> 413 where the fallback procedure is unsupported/disabled. Value 0 >>> 414 MUST be used for non multiplexed signal (i.e. non OTN client). >>> >>> How about: >>> A value of 1 MUST be used on interfaces which are configured to=20 >>> support the fall back procedures defined in [G.798-a2]. A=20 >value of 2=20 >>> MUST be used on interfaces that only support 2.5 Gbps time slots,=20 >>> such as [RFC4328] interfaces. A value of 3 MUST be used on=20 >interfaces=20 >>> that are configured to only support >>> 1.25 Gbps time slots. A value or 3 MUST be used for non multiplexed=20 >>> signal types (i.e. a non OTN client). >>> >>=20 >> OK but in the last sentence it's value 0, not 3. >>=20 >>>>>> >>>>>>> >>>>>>> The "RES" field isn't defined. >>>>>> >>>>>> - Res (3 bits): reserved bits. MUST be set to 0. >>>>> >>>>> "and ignored on receipt." >>>> >>>> Ok >>>> >>>>> >>>>>> >>>>>>> >>>>>>> 464-479: I know what you mean, but I think the text=20 >really isn't=20 >>>>>>> clear and should be revised. Suggest you just rewrite >>> rather then >>>>>>> tweak (as we tried in this rev.) I'm happy to discuss on >>>>> list if that >>>>>>> will help. >>>>>>> >>>>>> >>>>>> OLD >>>>>> 464 - Priority (8 bits): field with 1 flag for each=20 >>>>> priority. Each >>>>>> 465 bit MUST be set when the related priority is=20 >>>>> supported and MUST be >>>>>> 466 cleared when the related priority is not=20 >>>>> supported. The priority >>>>>> 467 0 is related to the most significant bit. When=20 >>>>> no priority is >>>>>> 468 supported, priority 0 MUST be advertised. >>>>>> >>>>>> 470 - Stage#1 ... Stage#N : These fields are 8 bits=20 >>>>> long. Their >>>>>> 471 number is variable and a field is present=20 >>> for each of the >>>>>> 472 indicated number of stages. The last one MUST=20 >>>>> always indicate the >>>>>> 473 server ODU container (ODUk/OTUk) and they MUST be=20 >>>>> listed in >>>>>> 474 ascending order. The values of the Stage fields=20 >>>>> MUST be the same >>>>>> 475 ones defined for the Signal Type field. If the=20 >>>>> number of stages >>>>>> 476 is 0, then the Stage and Padding fields=20 >>> MUST be omitted. >>>>>> >>>>>> 478 - Padding: Given that the number of Stages is=20 >>>>> variable, padding to >>>>>> 479 32 bits field MUST be used when needed. >>>>>> >>>>>> NEW >>>>>> >>>>>> - Priority (8 bits): bitmap used to state which priorities >>> are being >>>>> s/state/indicate >>>>>> advertised. The left most bit represent priority 0 >>> (highest) and the >>>>>> right most priority 7 (lowest) And are presented in >>> ascending orded. >>>>> s/) A/), a >>>>> s/orded/ordered >>>>> >>>>>> Each bit MUST be set when the related priority is >>> supported and MUST >>>>> "A bit MUST be set (1) for each corresponding priority >>> represented in >>>>> the TLV and MUST" >>>>> >>>>>> be cleared when the related priority is not supported.=20 >>>>> s/be cleared/NOT be set (0) >>>>> s/supported/represented. >>>>> >>>>>> When the >>>>>> interface does not support priorities, the advertisement MUST be=20 >>>>>> compliant with the advertisement of priority 0. >>>>>> >>>>> Replace with >>>>> "At least one priority level MUST be advertised. A value >>> of zero (0) >>>>> MUST be used when not overridden by local policy." >>>> >>>> NEW >>>> - Priority (8 bits): field with 1 flag for each >>> priority. A bit MUST be set (1) for each corresponding priority >>>> represented in the TLV and MUST NOT be set (0) when >>> the related priority is not represented.=20 >>>> At least one priority level MUST be advertised. A >>> value of zero (0) MUST be used when not >>>> overridden by local policy. >>> >>> How about: >>> - Priority (8 bits): a bitmap used to indicate which priorities are=20 >>> being advertised. The bitmap is in ascending order, with=20 >the leftmost=20 >>> bit representing priority level 0 (i.e., the highest) and the=20 >>> rightmost bit representing priority level 7 (i.e., the lowest). A=20 >>> bit MUST be set (1) corresponding to each priority=20 >represented in the=20 >>> TLV, and MUST NOT be set (0) when the corresponding priority is not=20 >>> represented. At least one priority level MUST be advertised that,=20 >>> unless overridden by local policy, SHALL be at priority level 0. >>> >>=20 >> OK >>=20 >>>>> >>>>>> - Stage#1 ... Stage#N : Each field is 8 bits long. One >>>>> field MUST be >>>>>> used in ascending order (from the lowest order ODU to=20 >the highest=20 >>>>>> order ODU) for each stage of the muxing branch being >>> advertised. The >>>>>> last one MUST always indicate the server ODU container=20 >(ODUk/OTUk). >>>>>> The values of the Stage fields MUST be the same ones >>> defined for the >>>>>> Signal Type field. If the number of stages is 0, the Stage >>>>> field MUST >>>>>> NOT be included. >>>>>> >>>>> How about: >>>>> Stage (8 bits): Each Stage field indicates the signal=20 >type used in=20 >>>>> the to transport the signal indicated in the Signal Type=20 >field. The=20 >>>>> number of Stage fields included in a TLV MUST equal the >>> value of the >>>>> Number of Stages field. The Stage fields MUST be ordered=20 >to match=20 >>>>> the data plane in ascending order (from the lowest order=20 >ODU to the=20 >>>>> highest order ODU). >>>> >>>> Saying that each stage field indicates the signal type used to=20 >>>> transport the signal indicated in the signal type field is >>> not correct >>>> because e.g. In the case of ODU1->ODU2->ODU3 it is not >>> correct to say >>>> that ODU2 and ODU3 are used to transport the ODU1 because the ODU2=20 >>>> tranports the ODU1 and the ODU3 tranports the ODU3. >>>> How about: >>>> >>>> - Stage (8 bits): Each Stage field indicates the signal type=20 >>>> beloning to the muxing branch used to transport the signal=20 >indicated=20 >>>> in the Signal Type field. The number of Stage fields >>> included in a TLV >>>> MUST equal the value of the Number of Stages field. The >>> Stage fields >>>> MUST be ordered to match the data plane in ascending order=20 >(from the=20 >>>> lowest order ODU to the highest order ODU). The values of=20 >the Stage=20 >>>> fields MUST be the same ones defined for the Signal Type >>> field. If the >>>> number of stages is 0, then the Stage and Padding fields MUST be=20 >>>> omitted. >>>> >>> >>> How about: >>> Stage (8 bits): Each Stage field indicates a signal type in the=20 >>> multiplexing hierarchy used to transport the signal=20 >indicated in the=20 >>> Signal Type field. The number of Stage fields included in a=20 >TLV MUST=20 >>> equal the value of the Number of Stages field. The Stage=20 >fields MUST=20 >>> be ordered to match the data plane in ascending order (from the=20 >>> lowest order ODU to the highest order ODU). The values of the Stage=20 >>> field are the same as those defined for the Signal Type field. When=20 >>> the Number of stage field carries a 0, then the Stage and Padding=20 >>> fields MUST be omitted. >>> >>=20 >> OK >>=20 >>>>> >>>>> >>>>>> - Padding: Padding bytes MUST be inserted so that the >>>>>> subsequent field starts at a 4-byte aligned >>> boundary. It is >>>>>> important to note that the Length field includes >>> the padding >>>>>> bytes. Padding SHOULD be using zeros. >>>>>> >>>>> How about: >>>>> Padding (variable): The Padding field is used to ensure=20 >the 32 bit=20 >>>>> alignment of stage fields. The length of the Padding field >>> is always >>>>> a multiple of 8 bits (1 byte). Its length can be calculated, in=20 >>>>> bytes, as: >>>>> % 4 When present, >>> the Padding >>>>> field MUST be set to a zero (0) value on transmission and MUST be=20 >>>>> ignored on receipt. >>>>> >>>> >>>> In case of number of stages =3D=3D 3, ">> Stages field> % 4" is 3, correct? While the padding bytes is 1. >>>> Wouldn't "4-" be more correct? >>> >>> Woops. 4-( % 4), right? >>=20 >> OK >>=20 >>=20 >>> >>> >>>> >>>> How about: >>>> - Padding (variable): The Padding field is used to >>> ensure the 32 bit alignment of stage fields. >>>> The length of the Padding field is always a multiple >>> of 8 bits (1 byte). Its length can be >>>> calculated, in bytes, as: 4- "value of Number of >>> Stages field".=20 >>> see above. >>>> The Padding field MUST >>>> be set to a zero (0) value on transmission and MUST >>> be ignored on >>>> receipt. >>> >>> s/The/When present, the >>=20 >> OK >>=20 >>> >>> >>>> >>>>>> >>>>>>> 481-493: I still find this text is really confusing. I=20 >think it=20 >>>>>>> would cleaner to separate out the fixed container and variable=20 >>>>>>> container field definitions (3 definitions: Unres ODUj=20 >at Prio N,=20 >>>>>>> Unreserved Bandwidth at priority N, and MAX LSP Bandwidth >>>>> at priority >>>>>>> N). Again happy to discuss further on list. >>>>>>> >>>>>> >>>>>> OLD >>>>>> 481 - Unreserved Bandwidth/Max LSP BW : In case of=20 >>>>> fixed containers >>>>>> 482 (Type=3D1) the Unreserved Bandwidth field MUST be=20 >>>>> 16 bits long and >>>>>> 483 indicates the Unreserved Bandwidth in=20 >>> number of available >>>>>> 484 containers. Unreserved/MAX LSP BW fields for=20 >>>>> each identified >>>>>> 485 priority MUST be included, in order of increasing=20 >>>>> prioritiy (0 to >>>>>> 486 7) and Unreserved/MAX LSP BW fields for other=20 >>>>> priority values MUST >>>>>> 487 be omitted. In case the number of supported=20 >>>>> priorities is odd, a >>>>>> 488 16 bits all zeros padding field MUST be added. =20 >>>>> On the other hand, >>>>>> 489 in case of variable containers (Type 2) the=20 >>>>> Unreserved/MAX LSP >>>>>> 490 Bandwidth fields MUST be 32 bits long and=20 >>>>> expressed in IEEE >>>>>> 491 floating point format. The advertisement of the=20 >>>>> MAX LSP bandwidth >>>>>> 492 MUST take into account HO OPUk bit rate=20 >>> tolerance and be >>>>>> 493 calculated according to the following formula: >>>>>> >>>>>> NEW >>>>>> - Unreserved ODUj at Prio N (16 bits): This field is used >>>>> only in case >>>>>> of fixed containers (Type=3D1). It MUST be 16 bits long and >>> indicates >>>>>> the Unreserved Bandwidth in number of available containers. >>>>>> A different field for each supported priority MUST be >>> used. In case >>>>>> the number of supported priorities is odd, a 16 bits all >>>>> zeros padding >>>>>> field MUST be added. >>>>>> >>>>> How about: >>>>> - Unreserved ODUj (16 bits): This field indicates the Unreserved=20 >>>>> Bandwidth at a particular priority level. This field MUST >>> be set to >>>>> the number of ODUs at the indicated the Signal Type for a >>> particular >>>>> priority level. One field MUST be present for each bit=20 >set in the=20 >>>>> Priority field, and is ordered to match the Priority=20 >field. Fields=20 >>>>> MUST not be >>> >>> s/MUST not/MUST NOT >>> >>>>> present for priority levels that are not indicated in the=20 >Priority=20 >>>>> field. >>> >>>>> This field is REQUIRED for Type 1 (fixed >>>>> container) TLVs, and MUST NOT be used for Type 2 TLVs. >>>>> >>> >>> Actually, these lines are redundant with the format definition and=20 >>> can be dropped. >>> >>=20 >> OK >>=20 >>>>> Also: >>>>> Unreserved Padding (variable): The Padding field is used to >>> ensure the >>>>> 32 bit alignment of Unreserved ODUj fields. The length of the=20 >>>>> Unreserved Padding field is always a multiple of 16 bits=20 >(2 byte). =20 >>>>> Its length can be calculated, in bytes, as: >>>>> =20 >% 2 When=20 >>>>> present, the Unreserved Padding field MUST be set to a zero (0)=20 >>>>> value on transmission and MUST be ignored on receipt. >>>>> >>>> >>>> Ok, but shouldn't it be:=20 >>>> "Its length can be calculated, in multiple of 2 bytes, >>>> as: "number of priorities indicated in Priorities field" % 2." ? >>>> >>>> When the number of priorities is odd, the unreserved padding >>> field is 2 byte, when the number of priorities is even, the padding=20 >>> field is not there. >>>> >>> How about: >>> >>> - Unreserved Padding (variable): The Padding field is used=20 >to ensure=20 >>> the 32 bit alignment of Unreserved ODUj fields. When present the=20 >>> Unreserved Padding field is 16 bits (2 byte) long. When the number=20 >>> of priorities is odd, the unreserved Unreserved Padding=20 >field MUST be=20 >>> included. When the number of priorities is even, the Unreserved=20 >>> Padding MUST be omitted. >>> >>=20 >> OK, but it's not variable. When present it's always 16 bits. >>=20 >>>> >>>>>> - Unreserved Bandwidth at priority N (32 bits): This=20 >field is used=20 >>>>>> only in case of variable containers (Type=3D2). It MUST be 32 >>>>> bits long >>>>>> and indicates the Unreserved Bandwidth in bits/s in IEEE=20 >floating=20 >>>>>> point format. A different field for each supported >>> priority MUST be >>>>>> used. >>>>>> >>>>> How about: >>>>> Unreserved Bandwidth (32 bits): This field indicates the=20 >Unreserved=20 >>>>> Bandwidth at a particular priority level. This field MUST be set=20 >>>>> to the bandwidth, in bits/s in IEEE floating point format,=20 >>>>> available at the indicated the Signal Type for a particular=20 >>>>> priority level. One field MUST be present for each bit=20 >set in the=20 >>>>> Priority field, and is ordered to match the Priority=20 >field. Fields=20 >>>>> MUST not be present for priority levels that are not indicated in=20 >>>>> the Priority field.This field is REQUIRED for Type 2 (variable=20 >>>>> container) TLVs, and MUST NOT be used for Type 1 TLVs. >>>>> >>> >>> The Unreserved Bandwidth field remains undefined in the=20 >current text. >>=20 >> Lost it. Now is there.=20 >>=20 >>> >>>>>> - MAX LSP Bandwidth at priority N (32 bit): This field is >>>>> used only in >>>>>> case of variable containers (Type=3D2). It MUST be 32 bits=20 >long and=20 >>>>>> expressed in bits/s in IEEE floating point format. The >>> advertisement >>>>>> of the MAX LSP bandwidth MUST take into account HO OPUk bit rate=20 >>>>>> tolerance and be calculated according to the following formula: >>>>>> >>>>> How about: >>>>> Maximum LSP Bandwidth (32 bit): This field indicates the maximum=20 >>>>> bandwidth that can be allocated for a single LSP at a particular=20 >>>>> priority level. This field MUST be set to the maximum bandwidth, =20 >>>>> in bits/s in IEEE floating point format, available to a=20 >single LSP=20 >>>>> at the indicated the Signal Type for a particular=20 >priority level. =20 >>>>> One field MUST be present for each bit set in the Priority field,=20 >>>>> and is ordered to match the Priority field. Fields MUST not be=20 >>>>> present for priority levels that are not indicated in the=20 >Priority=20 >>>>> field. >>> >>>>> This field >>>>> is REQUIRED for Type 2 (variable container) TLVs, and MUST NOT be=20 >>>>> used for Type 1 TLVs. >>>>> >>> >>> Actually, these lines are redundant with the format definition and=20 >>> can be dropped. >>=20 >> Yes >>=20 >>> >>>> >>>> OK >>>> >>>>> >>>>>>>> >>>>>>>>> ... >>>>>>>>>> 6) Finally, some nits: >>>>>>>>>> s/[OTN-INFO], the OSPF-TE/[OTN-INFO], OSPF-TE s/list >>> of them/list >>>>>>>>> s/Priority :8 bits/Priority (8 bits): >>>>>>>>>> s/infer/imply >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> - You have some very nice examples, but are inconsistent >>>>> in filling >>>>>>>>> in field values. I think all values that can possibly be >>>>> filled in >>>>>>>>> in the examples should be. >>>>>>>>> >>>>>>>> >>>>>>>> All the relevant ones have been introduces. Some non >>>>> relevant fields >>>>>>>> have been left with just the field name in. E.g. In an >>>>>>> example showing >>>>>>>> priorities management the T, S and TSG fields have not >>> been filled >>>>>>>> with 1 or 0 but just T,S and TSG have been left to make >>>>> the reading >>>>>>>> easier. >>>>>>>> >>>>>>> >>>>>>> I think this will confuse some readers. I think it would >>>>> be better >>>>>>> to fill in as much as possible, and if not, indicate that >>>>> the fields >>>>>>> are not important to the case (or can carry a specific set of=20 >>>>>>> values). For example why not show that reserved&padding >>> fields are >>>>>>> 0, that the SWCaps=3DOTN-TDM, etc. >>>>>> >>>>>> Done (only T, S ans TSG left indicated as T, S and TSG when non=20 >>>>>> relevant for the example) >>>>>> >>>>> >>>>> Will you add text to that effect to each of those examples? >>>> >>>> OK >>>> >>>>> >>>>>>> >>>>>>>>> Detailed editorial and technical comments: >>>>>>>>> >>>>>>> Thank you! >>>>>>> [...] >>>>>>> >>>>>>> >>>>>>>>> - Section 7 -- update to reference 4203 and 5920. Discuss=20 >>>>>>>>> implications / added risk of additional information >>>>>>> provided in this >>>>>>>>> document. >>>>>>>> Reference to 4203 added and this piece of text added=20 >at the end: >>>>>>>> >>>>>>>> For security threats, defensive techniques, >>>>> monitoring/detection/ >>>>>>>> reporting of security attacks and requirements=20 >please refer to >>>>>>>> [RFC5920] . >>>>>>>> >>>>>>>>> >>>>>>>>> Section 8. This section needs some work. (I'm assuming your=20 >>>>>>>>> familiar with rfc5226). >>>>>>>> >>>>>>> >>>>>>> Hereto, we'll see what the reviewers say... >>>>>>> >>>>>>>> What about: >>>>>>>> >>>>>>>> 8. IANA Considerations >>>>>>>> >>>>>>>> Upon approval of this document, IANA will make the >>>>> assignment of a >>>>>>>> new registry, the "OTN-TDM Container Registry" under >>> a new GMPLS >>>>>>>> Routing Parameters" with two new types (1 and 2) >>>>>>>> >>>>>>>> >>>>>>>> Switching Type Description =20 >Reference >>>>>>>> ---------------------- -------------------------- =20 >---------- >>>>>>>> 110 (suggested) OTN-TDM capable (OTN-TDM) =20 >[This.I-D] >>>>>>>> >>>>>>>> This document defines the following sub-TLVs of the=20 >ISCD TLV: >>>>>>>> >>>>>>>> Value Sub-TLV >>>>>>>> ----- ------------------------------------------------- >>>>>>>> 1 Unreserved Bandwidth for fixed containers >>>>>>>> 2 Unreserved/MAX LSP bandwidth for flexible=20 >containers >>>>>>>> >>>>>>>>> >>>>>>>>> - Switching types are assigned in >>>>>>>>>=20 >http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig- >>>>>>>>> parameters.xml#gmpls-sig-parameters-3 >>>>>>>>> (Again I suggest 110, not 101, but this isn't a big deal) >>>>>>>>> >>>>>>>>> - I think you are actually asking for IANA to establish a >>>>>>> new registry. >>>>>>>>> Perhaps something like "OTN-TDM Container Registry"=20 >under a new=20 >>>>>>>>> "GMPLS Routing Parameters" with two new types. >>>>>>> >>>>>>> Sorry, I wasn't clear in my prior mail. I didn't mean >>> for the text >>>>>>> to end up in the draft unmodified. Take a look at >>>>>>> >>>>> >>>=20 >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-dcsc-channel-ext-04 >>>>>>> for an example of how to ask for a new Switching Type, and >>>>>>>=20 >http://tools.ietf.org/html/draft-ietf-ccamp-rfc4420bis-03 for an=20 >>>>>>> example of how to ask for a new TLV registry. >>>>>> >>>>>> >>>>>> Upon approval of this document, IANA will make the >>>>> assignment in the >>>>>> "Switching Types" section of the "GMPLS Signaling Parameters" >>>>>> registry located at >>>>> http://www.iana.org/assignments/gmpls-sig-parameters:=20 >>>>>> Value Type Reference >>>>>> --------- -------------------------- ---------- >>>>>> 110 (*) OTN-TDM capable (OTN-TDM) [This.I-D] >>>>>> >>>>>> (*) Suggested value >>>>>> This document defines a new sub-TLV for the ISCD sub-TLV. >>>>> How about >>>>> This document defines 2 new TLVs that are carried in Interface=20 >>>>> Switching Capability Descriptors [RFC4203] with Signal=20 >Type OTN-TDM. >>>>> >>>>>> Each >>>>>> TLV includes a 16-bit type identifier (the T-field). Two >>>>> s/Two/The same >>>>>> T-field values are applicable to the new sub-TLV. >>>> ok >>>> >>>>>> >>>>>> IANA >>>>>> The IANA has created a new registry and will manage TLV type >>>>>> identifiers as follows: >>>>> How about: >>>>> Upon approval of this document, IANA will create and=20 >maintain a new=20 >>>>> registry, the "sub-TLVs of the OTN-TDM Interface Switching=20 >>>>> Capability Descriptor TLV" registry under the "Open Shortest Path=20 >>>>> First >>>>> (OSPF) Traffic Engineering TLVs" registry, see=20 >>>>> http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traf >>>> fic-eng-tlvs.xml, >>>>> with the TLV types as follows: >>>>> >>>>>> >>>>>> - TLV Type =3D 1 >>>>>> - TLV Name =3D Unreserved Bandwidth for fixed containers >>>>>> =20 >>>>>> - TLV Type =3D 2 >>>>>> - TLV Name =3D Unreserved Bandwidth for fixed containers >>>>> >>>>> The request Registration Procedures are Standards Action. >>>>> >>> >>> What case does "Whether allowed on ISCD sub-TLV" cover? The=20 >scope of=20 >>> the registry is the OTN-TDM Interface Switching Capability=20 >Descriptor=20 >>> TLV. >>=20 >> Removed, it didn't make much sense. >>=20 >>> >>> Thanks, >>> Lou >>> >>> >>>>> Lou >>>>> >>>>>> >>>>>>> >>>>>>> Lou >>>>>>> >>>>>>>>> >>>>>>>>> That's it on this document. >>>>>>>>> >>>>>>>>> Lou >>>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ccamp-bounces@ietf.org=20 >[mailto:ccamp-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Lou Berger >>>>>>>>> Sent: gioved=EC 20 dicembre 2012 0.28 >>>>>>>>> To: draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; CCAMP >>>>>>>>> Subject: Re: [CCAMP] I-D Action:=20 >>>>>>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>>>>> >>>>>>>>> Authors? >>>>>>>>> >>>>>>>>> On 12/4/2012 4:34 PM, Lou Berger wrote: >>>>>>>>>> Authors, >>>>>>>>>> Please review any changes and how LC comments >>> are addressed. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>>> On 11/28/2012 2:37 AM, internet-drafts@ietf.org wrote: >>>>>>>>>>> >>>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>> Internet-Drafts directories. >>>>>>>>>>> This draft is a work item of the Common Control and >>>>>>>>> Measurement Plane Working Group of the IETF. >>>>>>>>>>> >>>>>>>>>>> Title : Traffic Engineering Extensions to=20 >>>>>>>>> OSPF for Generalized MPLS (GMPLS) Control of Evolving=20 >G.709 OTN=20 >>>>>>>>> Networks >>>>>>>>>>> Author(s) : Daniele Ceccarelli >>>>>>>>>>> Diego Caviglia >>>>>>>>>>> Fatai Zhang >>>>>>>>>>> Dan Li >>>>>>>>>>> Sergio Belotti >>>>>>>>>>> Pietro Vittorio Grandi >>>>>>>>>>> Rajan Rao >>>>>>>>>>> Khuzema Pithewan >>>>>>>>>>> John E Drake >>>>>>>>>>> Filename :=20 >>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt >>>>>>>>>>> Pages : 33 >>>>>>>>>>> Date : 2012-11-27 >>>>>>>>>>> >>>>>>>>>>> Abstract: >>>>>>>>>>> ITU-T Recommendation G.709 [G.709-2012] has introduced >>>>>>>>> new fixed and >>>>>>>>>>> flexible Optical Data Unit (ODU) containers, >>>>> enabling optimized >>>>>>>>>>> support for an increasingly abundant service mix. >>>>>>>>>>> >>>>>>>>>>> This document describes Open Shortest Path First=20 >- Traffic >>>>>>>>>>> Engineering (OSPF-TE) routing protocol extensions >>> to support >>>>>>>>>>> Generalized MPLS (GMPLS) control of all currently >>> defined ODU >>>>>>>>>>> containers, in support of both sub-lambda and lambda >>>>>>>>> level routing >>>>>>>>>>> granularity. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>> >>>>>>> >>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 >>>>>>>>>>> >>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-04 >>>>>>>>>>> >>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>=20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-0 >>>>>>>>>>> 4 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> CCAMP mailing list >>>>>>>>>>> CCAMP@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> CCAMP mailing list >>>>>>>>>> CCAMP@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> CCAMP mailing list >>>>>>>>> CCAMP@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>=20 >>=20 >>=20 >= From julien.meuric@orange.com Fri Jan 18 09:00:31 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D425121F886C; Fri, 18 Jan 2013 09:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id she4GI-90vr8; Fri, 18 Jan 2013 09:00:31 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id F325021F8863; Fri, 18 Jan 2013 09:00:30 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 990741074002; Fri, 18 Jan 2013 18:05:15 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 90CDC1074001; Fri, 18 Jan 2013 18:05:15 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Jan 2013 18:00:30 +0100 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Jan 2013 18:00:29 +0100 Message-ID: <50F97FAC.3010903@orange.com> Date: Fri, 18 Jan 2013 18:00:28 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2013 17:00:29.0878 (UTC) FILETIME=[520BAD60:01CDF59D] Cc: draft-ietf-ccamp-lmp-behavior-negotiation.all@tools.ietf.org, "rtg-dir@ietf.org" , "ccamp@ietf.org" Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-lmp-behavior-negotiation-09 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:00:31 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ccamp-lmp-behavior-negotiation-09 Reviewer: Julien Meuric Review Date: 18 January 2013 IETF LC End Date: 21 January 2013 Intended Status: Standards Track *Summary:* This document is basically ready for publication, but has nits that should be considered prior to it. *Comments:* This document is clearly written and easy to understand. The defined mechanism is simple and well specified. *Nits:* Abstract -Instead of "GMPLS networks", "GMPLS-controlled networks" reads more accurate to me. It would also align on the phrase used in the introduction. The resulting "Generalized Multiprotocol Label Switching (GMPLS)-controlled networks" may be checked with the RFC Editor. Introduction - s/LMP node/LMP-capable node/ - s/functions defined in that document/functions specified in that very document/ [repetition of "defined"] - s/the message types from/the types from/ [repetition of "message"] Section 2.2 - s/MAY include, HelloConfig/MAY include HelloConfig/ Section 3.1 - s/number of MBZ bits field/number of bits in MBZ field/ Section 4 - s/[RFC4202] defined/[RFC4202]-defined/ Section 9.2 - I tend to think that [LMP TEST] should now reference draft-cecczhang-ccamp-gmpls-g709v3-lmp Enjoy the week-end, Julien From lberger@labn.net Fri Jan 18 09:27:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF0321F870A for ; Fri, 18 Jan 2013 09:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.272 X-Spam-Level: X-Spam-Status: No, score=-101.272 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_62=0.6, 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 rEG14xIhmNnn for ; Fri, 18 Jan 2013 09:27:26 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id F076A21F8702 for ; Fri, 18 Jan 2013 09:27:25 -0800 (PST) Received: (qmail 15874 invoked by uid 0); 18 Jan 2013 17:27:01 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 18 Jan 2013 17:27:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=KaZvp84chBy/tdtmBeQtqGCp7BpfCjyxZNPxX1tjmJQ=; b=lw/V7VRMs4weumfM++1jmFP0g4GJ/DvLAgg2BZTn9x+iUyfdbqBDyWIPFTEZHZogXixAIBhPb3bAnUMYiOE/2ZThiSEnVrjBeNTwCYP2LtpIls3Jk6oyUEbNnngi/oq1; Received: from box313.bluehost.com ([69.89.31.113]:49291 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TwFiX-0002Ci-9d; Fri, 18 Jan 2013 10:27:01 -0700 Message-ID: <50F985EC.1050704@labn.net> Date: Fri, 18 Jan 2013 12:27:08 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Daniele Ceccarelli References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:27:27 -0000 Daniele, Very nice summary. Just catching up, so sorry for the (2 day) late response. I really like how the terminology has evolved and appreciate the summary! I have a few detail comments, but before I go there I'd like to cover one more open issue that I think will have some (minor) ripple effects on the details. I think there's still the general issue of terminology to use when referring to the entity that "uses an overlay" and the entity that "instantiates the overlay". In your mail and in discussion we have: - client (service)/OC/CN/customer and - server(or service)/OE/EN/provider I think we had discussed, and possibly agreed on, using VPN terminology which would have us use the latter options, i.e., (overlay) customer/provider (edge). This would mean eliminating any references to client/server in the *generic overlay* definitions. Of course these terms may reemerge in other contexts as they have before, e.g., rfc6215. I like this approach as it is aligned with the much of IETF work on overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). Importantly, RFC 4847 even has quite a few concepts that can be directly leveraged in this discussion. I'd even go further and say that we should base the definitions and resulting framework on RFC 4847. For example, the definitions below could start with something along the lines: The overlay service model, at a high level, follows Section 7. of RFC 4847 as represented by: +--------------------+ : | | : : | | : +----+ : +----+ +----+ : +----+ | CE |---:---| PE | | PE |---:---| CE | +----+ : +----+ +----+ : +----+ : | | : : | | : : +--------------------+ : : | | : : |<-Provider network->| : Customer Customer interface interface Figure 7.2: Overlay Service Model In this model, the overlay is instantiated by an overlay "provider" and its provider edge (PE) nodes , and is used by the overlay "customer" which is connected to the provider via customer interfaces attached to customer edge (CE) nodes. ... The definition below would need to be tweaked slightly, notably to remove any references to client and server. The resulting framework can also refer back to RFC 4847 as needed. See below for some additional comments. On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: > Dear overlayers, > > Please find below a new version (v2) of the framework summary > reflecting the latest discussions. Again i hope i've captured all the > comments around, sorry if anything is missing, in case just let me > know what i missed. > > BR > Daniele > > > + Disclaimer: > 1. Packet opto integration is often considered but the work can be > extented to any type of SC. Eg. TDM over LSC. > > + Terminology: > 1. Virtual Link: A virtual link is a potential path between two > virtual or real network elements in a provider layer network that is > maintained/controlled in and by the provider domain control plane > (and as such cannot transport any traffic/data and protected from > being de-provisioned) and which can be instantiated in the data plane > (and then can carry/transport/forward traffic/data) preserving > previously advertised attributes such as fate sharing information. > You say "potential path". I this this should read "potential or instantiated path". >From my perspective, I think a node in the overlay really shouldn't *directly* distinguish between the two -- now one may have a different metric/SRLG/weight/etc, but these are abstracted representations of the tradeoffs between use of the two, that can be provided by the underlying provider network, rather than a direct indication. > 2. Virtual Node: Virtual node is a collection of zero or more > provider network domain nodes that are collectively represented to > the clients as a single node that exists in the customer layer > network and is capable of terminating of access, inter-domain and > virtual links. > I'm a little uncomfortable with the linkage of real nodes to virtual nodes. I think VN is a purely abstract concept that may be instantiated using parts/whole/multiple/logical/real/etc nodes. How about something like: Virtual Node: A virtual node is a representation of a collection of provider resources that are interconnected via virtual (and customer) links. A virtual node may be collection of zero or more, including portions of, provider nodes that are collectively represented to the customer as a single node which is available in an overlay network. > 3. Virtual Topology: Virtual topology is a collection of one or more > virtual or real provider network domain nodes that exist in the > customer layer network and are interconnected via 0 or more virtual > links. How about: Virtual Topology: A virtual topology is the collection of virtual links and nodes advertised by a provider to a customer. The virtual topology includes resources that are advertised as reachable within an overlay network. Do you mean to imply/allow for a VN which has no links? > 4. Overlay topology: is a superset of virtual topologies provided by > each of provider network domains, access and inter-domain links. > Doesn't it also include any topology information advertised by the customer/CE as well? > 5. Access Link: Link between OC and OE. GMPLS runs on that link. It > can support any of the SCs supported by the GMPLS. > If we adopt RFC 4847 terminology it should be "customer interface". Also, I suspect you mean PE and CE. > 6. CE (customer Edge): Something like the CN in RFC4208 teminology > but (i) receiving virtual topology from the provider network and > requesting the set up of one of them or (ii) requesting the > computation and establishment of a path accordingly to given > constraints in the provider network and receiving the parameters > characterizing such path. (ii) == UNI. > humm, I'm inclined to stay away from UNI for the moment. I also suggest that we look to 4874 and even 4364 rather than 4208... > 7. PE (provider Edge): Something like the EN in RFC4208 but able to > deal with (i) and (ii) above. > same comment WRT RFCs. > 8. PE-CE interface (former ONI) : Interface allowing for signaling > and routing messages exchange between customer overlay and provider > network. Routing information consists on virtual topology > advertisement. When there is no routing adjacency across the > interface it is equivalent to the GMPLS UNI defined in 4208. > Signaling messages are compliant with RFC4208. Information related to > path carachteristics, e.g. TE-metrics, collected SRLG, path delay > etc, either passed from CE to PE via signaling after the LSP > establishment in the core network or from CE to PE to be used as path > computation constraints, fall under the definition of signaling info > and not routing info). > > 9. CE-CE (former O-NNI): Interface on the links between different > provider networks in the overlay model environment. Same features of > the CE-PE apply to this interface. > you mean, PE-PE, right? > + Statements 1. In the context of overlay model we are aiming to > build an overlay topology for the customer network domains > > 2. The overlay topology is comprised of: > a) access links (links connecting client NEs to the provider network domains). > They can be PSC or LSC. > b) inter-domain links (links interconnecting server network domains) > c) virtual topology provided by the provider network domains. Virtual Links > + Virtual Nodes (TBD) + Connectivity Matrix (with a set of parameters > e.g. SRLG, optical impairments, delay etc for each entry) describing > connectivity between access links and virtual links. > > 3. In the context of overlay model we manage hierarchy of overlay > topologies with overlay/underlay relationships > > 4. In the context of overlay model multi-layering and inter-layer > relationships are peripheral at best, it is all about horizontal > network integration > > 5. The overlay model assumes one CP instance for the customer network > and a separate instance for the provider network and in the CE-PE > interface case the provider network also surreptitiously participates > in the customer network by injecting virtual topology information > into it. > We should ensure we're allowing for some of the existing/augmented models that permit the transport of overlay information within the provider's CP, e.g., rfc4364, 5195 and 5252. > 6. L1VPN (and LxVPN) in general is a type of service provided over > the CE-PE interface (it falls under the UNI case as no routing > adjacency is in place between CE and PE). > > > + Advertisement models (to be detailed in dedicated document/documents) > The CE-PE interface in the overlay model context foresees two types > of advertisement models.(names still to be agreed) > > A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and augmented > by a number of actived draft (references to various drafts to be > added). The Augmented UNI is a particular type of CE-PE interface > where only signaling messages are exchanged between CE and PE. > Messages from CE to PE can include a set of parameters to be used by > the PE as path computation constraints when computing a path in the > provider domain network, while messages from PE to CE can include a > set of parameters qualifying the LSP being established, like for > example SRLG, delay, loss etc. > again, we can leverage 4874 terminology if we so choose, i.e., "basic mode" and "enhanced mode" UNI|NNI > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply > called with the general CE-PE interface term?) allowing the > establishment of signaling and routing adjacency between CE and PE. > Routing info passed from PE to CE comprise overlay topology > information including (but not limited to) virtual links, > connectivity matrices and access links with parameters qualifying > each of them in terms of e.g. SRLG, loss, delay etc. Signaling > information and procedures are compliant with RFC4208. > so this is just and 4874 "enhanced mode" interface, right. > + Open issues/questions > 1. PCE-PCEP - do we need to include considerations about PCE and PCEP > into the overlay framework context? > > 2. BGP-LS needs to be considered > 3. Should potentials be included? E.g. I2RS? > 4. Virtual links: wouldn't a different definition of virtual links > avoid the advertisement of connectivity matrices (this is out of the > fwk scope but within the advertisement models one)? > > Take this example: > PE1-----CE1 CE2-----PE2 > CE1======VL1======CE2 > CE1======VL2======CE2 I think you've reversed CE and PE here... Much thanks! Lou (hatless...) > i.e. There are 2 VL connecting CE1 and CE2 that could be available > for PE1 and PE2 to set up an adjacency in the customer domain. CE1 > and/or CE2 can be blocking nodes so VL1 and/or VL2 are available only > depending on the connectivity matrices of CE1 and CE2. Hence PEs need > to be aware of both VL and connectivity matrices. My point is: if CE1 > advertises to PE1 only the VL that his connectivity matrix allows to > be connected to PE1 (e.g. VL1 only) and not all of them, it should be > possible to avoid the connectivity matrices advertisement. > > > =================================== > DANIELE CECCARELLI > System & Technology - PDU Optical & Metro > > Via E.Melen, 77 > Genova, Italy > Phone +390106002512 > Mobile +393346725750 > daniele.ceccarelli@ericsson.com > www.ericsson.com > From scott.mansfield@ericsson.com Fri Jan 18 11:09:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A5E21F8684; Fri, 18 Jan 2013 11:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 w256OrXNZPrm; Fri, 18 Jan 2013 11:09:12 -0800 (PST) Received: from usevmg20.ericsson.net (unknown [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E939E21F8653; Fri, 18 Jan 2013 11:09:11 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-92-50f99dd599e6 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 87.9D.31450.5DD99F05; Fri, 18 Jan 2013 20:09:11 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Fri, 18 Jan 2013 14:09:05 -0500 From: Scott Mansfield To: "ccamp@ietf.org" , "pwe3@ietf.org" Thread-Topic: LS from ITU-T SG15 to IETF on the closure of the ad-hoc group on MPLS-TP Thread-Index: Ac31A9UuFAQBiZIHS9e4ubOSe/IHoAAl3OZgAATkzWA= Date: Fri, 18 Jan 2013 19:09:03 +0000 Message-ID: References: <9BA9FE6D8B2F5344BF95CDAC35C8320D637E9E84@TUCHM02.TUECSP.UNICC.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/mixed; boundary="_005_EF35EE4B92789843B1DECBC0E24558640FF6C2eusaamb105ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0gUURTGubOzs6NpjOvrpFK2aZQlPpAwE5FAsSKSKLLAUmpQyTbZVfMP E61M28UXprmrlo/FF1bmoxbfjzB8RBaIjzIVp8BEJM1EW7XZuRsI/fc73/3uOd/cM7RIuil2 oGPk8axCHhkro8zJ/IT2C+5jpeuhnp0Nu3y5knHSN3u5mQwkQnS6dSIUXTH3v8HGxiSyCo+A CPPo9g+bVFzWH7ukibRtSSraqrRTITMaGB+Yyn4vxmwHI19fUipkTkuZtwhahvpIXFQjuD84 jYwuir/R0vpEYBsmGAoXOYmRrZlLYKiYobAeBku6apPHDzL+vCGMTDKu8LxILbAlcwZe500K LGVCoa8+U/AjPsXaYL2gixh7mOSeETidDcx+HKIw28L83JYp9QHQcV0k9sfAdlqmGPe3ggEN R+Yia+2OVtodNu0OG9ZvQ00BZ/IchbK2ZQrzEagqXxD94+HuOeJ/3Qt0CzqT3xlyZpqQln87 EVOHoL1oXIwPTkDVvR4J5v3wWD1rYidoKnhkupCO4FtmKqEVXr4NQSc3LMbFK34nL2okuCgh oLqjg8QFh0D9gzOdaBB8MUwJUaTMXRgtaRQiUnzcruIqfgrNb+UglD7YhwfmImj43CN8kjUT DoOFP5FW2NxVyPi1QWL2BtVYt9DHuMUG9RaJn88HMlvXJXjWORjozyKN/S14vXrcxihbMKeh V1shKkP+dYhOULKJt6K8PRsR/wv3A+WuR+3zx3uRI03K7C3PB42ESpmoyHj2JsvGsYprioRY VtmLCNrMIRUl1w8lzusNK/YuEYGubeUZBUlOvzWuCSJrvUfYu9msXG9VSq5V8OElw0ZLxKHE 5jX195NDK3rL3X4uly8WZpjJbCOO1Tpfz299uDZam7d3tT8peYpND//UIT8b4L49F2LDiVxt c4JXi/RPVcWlQdOyUcc9lXK38KqUU5o7w4slEzJSGR3p5SZSKCP/AoRI4UaQAwAA Subject: [CCAMP] FW: LS from ITU-T SG15 to IETF on the closure of the ad-hoc group on MPLS-TP X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 19:09:13 -0000 --_005_EF35EE4B92789843B1DECBC0E24558640FF6C2eusaamb105ericsso_ Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E24558640FF6C2eusaamb105ericsso_" --_000_EF35EE4B92789843B1DECBC0E24558640FF6C2eusaamb105ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCAMP and PWE3 Working Groups, This message was originally sent only to the MPLS working group, but some i= ndividuals in the CCAMP and PWE3 working groups may also be interested in t= his communication from the ITU-T... The pdf document attached is a Liaison from the ITU-T on the closure of the= ad-hoc group on MPLS-TP. I have also attached a follow-up message from Yo= ichi Maeda (the former ITU-T SG15 Study Group Chair). Regards, -scott. Scott Mansfield IETF - ITU-T Liaison manager for MPLS From: Jones, Greg [mailto:greg.jones@itu.int] Sent: Thursday, January 17, 2013 5:45 PM To: statements@ietf.org Cc: Trowbridge, Stephen (Steve.Trowbridge@alcatel-lucent.com); Malcolm.BETT= S@zte.com.cn; Scott Mansfield; Eliot Lear (lear@cisco.com); OTA, Hiroshi; T= SBSG15, ITU Subject: LS from ITU-T SG15 to IETF on the closure of the ad-hoc group on M= PLS-TP On behalf of the Chairman of ITU-T Study Group 15, please find attached a = liaison on the closure of the ad-hoc group on MPLS-TP. Regards, Greg Jones Counsellor, ITU-T Study Group 15 International Telecommunication Union Tel: +41 22 730 5515 Mob: +41 79 249 4832 --_000_EF35EE4B92789843B1DECBC0E24558640FF6C2eusaamb105ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

CCAMP and PWE3 Working= Groups,

 

This message was origi= nally sent only to the MPLS working group, but some individuals in the CCAM= P and PWE3 working groups may also be interested in this communication from= the ITU-T…

 

The pdf document attac= hed is a Liaison from the ITU-T on the closure of the ad-hoc group on MPLS-= TP.  I have also attached a follow-up message from Yoichi Maeda (the f= ormer ITU-T SG15 Study Group Chair).

 

Regards,

-scott.

Scott Mansfield

IETF – ITU-T Lia= ison manager for MPLS

 

From: Jones, G= reg [mailto:greg.jones@itu.int]
Sent: Thursday, January 17, 2013 5:45 PM
To: statements@ietf.org
Cc: Trowbridge, Stephen (Steve.Trowbridge@alcatel-lucent.com); Malco= lm.BETTS@zte.com.cn; Scott Mansfield; Eliot Lear (lear@cisco.com); OTA, Hir= oshi; TSBSG15, ITU
Subject: LS from ITU-T SG15 to IETF on the closure of the ad-hoc gro= up on MPLS-TP

 

On behalf of  the Chairman of ITU-T Study Group= 15, please find attached a liaison on the closure of the ad-hoc group on M= PLS-TP.

 

Regards,

Greg Jones

Counsellor, ITU-T Study Group 15

International Telecommunication Union

Tel: +41 22 730 5515

Mob: +41 79 249 4832

 

 

--_000_EF35EE4B92789843B1DECBC0E24558640FF6C2eusaamb105ericsso_-- --_005_EF35EE4B92789843B1DECBC0E24558640FF6C2eusaamb105ericsso_ Content-Type: application/pdf; name="oLS-002.pdf" Content-Description: oLS-002.pdf Content-Disposition: attachment; filename="oLS-002.pdf"; size=264164; creation-date="Thu, 17 Jan 2013 22:42:34 GMT"; modification-date="Thu, 17 Jan 2013 22:42:35 GMT" Content-ID: Content-Transfer-Encoding: base64 JVBERi0xLjQNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4v T3V0cHV0SW50ZW50c1s8PC9UeXBlL091dHB1dEludGVudC9TL0dUU19QREZBMS9PdXRwdXRDb25k aXRpb25JZGVudGlmaWVyKHNSR0IpIC9SZWdpc3RyeU5hbWUoaHR0cDovL3d3dy5jb2xvci5vcmcp IC9JbmZvKENyZWF0b3I6IEhQICAgICBNYW51ZmFjdHVyZXI6SUVDICAgIE1vZGVsOnNSR0IpIC9E ZXN0T3V0cHV0UHJvZmlsZSAxNTQgMCBSPj5dIC9NZXRhZGF0YSAxNTUgMCBSPj4NCmVuZG9iag0K MiAwIG9iag0KPDwvVHlwZS9QYWdlcy9Db3VudCAxL0tpZHNbIDMgMCBSXSA+Pg0KZW5kb2JqDQoz IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1 IDAgUi9GMiA3IDAgUi9GMyA5IDAgUi9GNCAxNSAwIFIvRjUgMjAgMCBSPj4vWE9iamVjdDw8L0lt YWdlMjIgMjIgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+ L0Fubm90c1sgMTQgMCBSXSAvTWVkaWFCb3hbIDAgMCA1OTUuMzIgODQyLjA0XSAvQ29udGVudHMg NCAwIFIvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCA1MDkzPj4NCnN0cmVhbQ0KeJy9HGtz27jxe2byH/BRamOaAPjM3NycEzse d2LnYWU67aXTkSXZZk8idRQVz/XXd3cBSKBIkLKsazvnSCKwu9gXdhcLnp6VVXY/nlTsp59Oz6pq PHmcTdmvp++KqioW/zod/bGcnX4eP2T5uMqK/Oef2bvz9+z316+C1Et8zoLIi9OUBWnoJfCNewEr Z69f/f0vLH/9Sg/DQYkaInaHvBu9fnX6gbOUje5fv+LMh/9zFgovCFjie37ARovXr3z2gH8uX7/6 dQBEzobhIB+mA6BoeJLQx7fDf7HR316/ugB4X56BWexgTjkMdaFmx0ISeNx3IbkdnsgBrCsaLGCZ s2EAaE+E+qVk+HAMv83n+Gn75H7I9dfqEXmymbcY8oRmVMMTHtDvZTaebwBVlfk0gf8eERaOmeIH BY94rD4OOVdDshWbD5NBNs5WBc7PN8NXFUGdDXm4WQA9reBxYMgBiH8MYzXjzuBU89cIj377z2wy NPOAilANuBohFd/YhBAvceAfR5JLwIUXhw65lNmDYVDlIUmKmnwY2YRvmEi/jc2q8Gf8spqZ4UpM wMenIReDjMQ5p6Va/DjOspQ1RakXNRaV5UgFCTubjJHbs6laG/f1wx3JbwSV4U8kWTX9Bwgom8Kf NX4lHaXlTEHOpKLIg7XSa55YeqGZeZy18iTx0va1HpedYeqJpN1412a1DkUogCNab4Vf0yvNMPhY GF6vGGpYoR8namKJT34AmB3r2rF9IkSrHMhzX0cxAwehxQc/0QTL+2TkMFYMtSPVhr5VA8t3AEYi lqgoEcpyszIi6g2ipXF3alysl6FQbCG0LHfFKhxZV0lCgt/UrEJRFW8FUmXKucaWw9rhiu1ciWdH ci2p70mH0ii+Lo3ZlCTnHbIMS/Bjblzh+OhOIgDraVrOVox3wLp5Zhzd2MHSJ9QJRfHjRuRb8bY4 k7HxDaCUoda27L/kkHCw2edPouNKhafCCx2L3vJe7zjekZAKHnhp7MC6I84v+ilgkoKBbxPM94KE /vi+wnX/l72eJ+oxUho3nodBCIww8yGia4LYY4iighhCVGzYUXsoO9fQPSDRz7tWYfATiTUSNs9l 3zK7xzgsKPKigMnE491iZRfXFEGH0ksgZo6S0PNDFvteIlkSeTy1NIidfsbA/Pr91TnzTz+O8wc2 mOUnl++G20ic4CgwEYHB+BXgJG2qyEXdADjslBHsl+CYBFHdpoKGYi4CL+YsBkFA6C9CWGrMhPCE dJDMHSQTIAVH2HBEq/WQndhEi9gLExYDwzdEX6GzuRnh3wu02a/gUG7ORuhu6NGnmzOKfz9CrkBG PcI/NBR/gg/gst7DpE/wSQyur3HmtxuYq34+I9AaFLMefrppuIWXrU6GsLqwvjq3SGQiUPpaJDyK Qe6dIhEOkRCgDdUWoBaqAVFAIXItdo7AWoBsmBJpsomf1+jjeYi8au5Vz8Eq27DG3Ksj/cn33/Gf X4KndXVx4sVJfXUvW00rloTA17B8vGU+7Jw+ap5QMcCxmRiCPcnk/8DFUAZeEP3ZXAxljHtxDcvF 8bEENKNrLU3PqX298LkH20ok0fbbzVR2ek7t7B1wNkQLl+eUPiRJiubRxceL98OTGAz1+htG9DdX 78/w39GV07Udil4Az8EX2uib4j/OCsEb+cZ73o7Obs7PMIL8en6FS/snxpD0AywS/7lhtxfvR/jp 09cjEyThpyStE7SzaFISW/jBi4Xv3jWjFPajYMOZb+e4Bf6DMpDPyJvN7qn2uvOXCKiFCuEL3Kgs KiC6Ajijya8DgCWPjE2QwtXWfHJsFKEXuBcUHRkbRKdBWF9QR3AgICQF3RMQ3SGl0pMx5DwQHrc7 ndAVG1hwhAPO1gJa3aSkde5JsHGTClEQYETdTnHUTbHhcjugru0e7Bhs1rd2kPwBMlMqDGRYlqHk lhU5JsTwvVmCfCEJhnE2DX1+I/6TuBFIjCcjyP24keGnErnwoNhBBeBUlU7wy1t2kWPKTI+ROzRE sexP4lONOLeCmZwLDA7+SXwvTrsMIulOuRCKICiQa+1pD5QkRlGEvlhR+2WNsTHV+vCIBbn0fbD6 PgR1a55qHI4ZUz1Zx9wRr0CkFsWGTzxKKEhyMyp17VgIJzL0tsNxpaYQxoWKVYnZOOUblr5h3H/T siu9AFOcNjBxAXiCU8hbjogIYksvlXVEHc4Qtko0DCUDAXre7b25q0BgAxIOQA6KjXXtQXGNFK6x Uw0EdDYGhiXSiwQWKNIAdBarjaaeYrZEGkBPdh5HuNvp54kXip3nWiLO+RLmbx4rA6gNMAxyAZA+ uCNpnkNMEUY7A4wPMwCiXQgC3FO4hQC7YX3AroMCB4inq2mE8UuX0F35vHYUCEcoOMmejkIEHBUk wqNdq1j96+ArFu3vsQjrsbdsdM58P2XfB+CnLi+wInID5gJuy+GyDqBERsKTYQsl/Q4eNErs4eC5 K8/SRCOYwzw8aERao1md69IhYalPW9HnO138AahTzDHacPc7esWvgIdYCehimDM30UaoyCZADc73 eHpIUHTFS5N9hSV4Ssu+Od3wIfjCGMsQTXwtqcELsERg4KIFy4jd0vHbejo8gSCJDgEZpl6XJZ59 rJesY9c5gBARgMuMWwjptaIQ0gxAo6xIYIdH6FILV+qglNkCBMqMkNqrLK2W5MfoOm0GqgOx+Wwo neazF8YGqxJgsmhD2WtAGp82oG5euZIWLWMbVLo36caIgHSZ2qS/R27Ni9WaTlFZcc+qR2ygYWM6 qnUo2mFECNDIOG4hwmlZB+KBLCGWLXgeCzQk9K3sQZ3/gjkVObv+rKv/goMjPiotEjbzsI2WI69Z YqEhbeBhJz5ECoLqDaPPR0YpUzyKaC6t33PEsefLfeIXV86qzdiCs3f8ApYgUpiaotuyqP5Ih7ln V7f6FIf+JWdyNhrqyheeVtCHm5HLsxxAkoSgM5AtJO0TSyeaKSqMDgFvSj1Kqd+Ic7WsaYQrDtaP Ay43oxxBaAj7JOT93E/pnw4hutI/zTELjiNVcvj+MEy9tMawD0VJvkt1c2C2LAasKpzbwAGoMd2A IL2Ju2MTgNSKbxgmE+BwI2arHcK5UjUCVIMT7h1uhBj0hZGPU7vd0AuQpLiyJpJ+hwBGGeyjS8J1 ZqwFasF5pi4FPp6tN3VJtWTBtrGAeAL/011GclCxCnuvnMp1AC08EJh+NonpVy6FbQ/lcqWEWu4W nOcqF1Ad7KdcByFRytVA0q9cPPaivZSrO92z4TxTuYS/s0Vq5cIuuVAlzQWmfQtMacb7eK4DaOGh 8lwNYvqVS2HbQ7mc+Z+SuwXnucoFVEeykf5djD6wr1hdKNaq1QyQn5XUWAyMxRj2DSVPavAtdW9c urTyAOpESgdWTep6tTJIY2zp2UMru5MnG84ztdL3vbCmCGfLJbINNbH4MZ67lO8QlDhYtuHsVT6N bQ/lc2ZOJF4bznOVz6f2q9206RH1KysXY9gVckydbi8hrfs+gF+5z/4GyuaTCuZratyE75HJ59s1 8BASJU/wBLlJIp6XttTbXoApiDDkaWLq1/U4waB4D13vjvdtOM/T9UBVKSyiz7FcOZ7SGZQ+ozqR nTW3Q7BznxSoib5f7RW2PdTedQylJW3BeabaBwnHqXts6IchoQ29iaRfnUSK53+KpwGFEg7WdGce BCc2VSAEtH/dKQgp+bVdQpFXkHiEg8qpQAfh4z73ZAu+3qKTZhNu+1ha7+CTdCYcKmfUhFuQnlFz Qsrruk+ZdTVbPqIJ5tpRemxE+87TXUlXRR5mrmrFYdQI8F6hbKGm79hcOttUj8GcIMRub3sPnm96 52fz47KAxwJttYHSWYo6FA3VPpp4PuKp/9qU4CiPqo4sZPDNYdyCulfIzqzoGEKW1GdkkfPt9uzI PI94Oya3lxCpj6eS2ksIsAvsrOjyEq70yIYU25D2ElkqsWepaZcjLEO3xKAvwob9dnHc7wVejids x/NXDA5ZLHyWYqdWkjQPc16GGAK7kB/i5oIjC7RhgxcUKGe6B6iVnNvlON9SFB6JIjxeD3ccH/5e PphPX+kaxqqa/UCl86qyeAJS70rahiC7/GWMuqivQDa98ouoC0IKgHqpa3rpF6INMJrvRTtfT7D/ V3lrb1Is+vQoOpLUQj/Blq9eX/5iPJy3b1c7eLbs2ehTgH2Iuj8IKPB9n2+q5a28iWvF+gA2yjDt KtbrEa5ivX4sIowu688jQRG8c34U4PGzea5aaGojkKe4lbog6MqHISFMiBcd5wUBj/F6ozn08fEK lWOj6W6sI0Dp5ohlBxBKeSdUh3wk2Cd0rtGQ1kUlYjxS7BKVGuEUlX4c0h2HVk67ABhOq+dOTtda xFsDepcBKC5BWh/UN2DrIJg9FnRseom+oMQuBPCP+uQ0UIGdfXBqCwFvUSaRDb/uy+pjQZXD+tjR Z6qFPqHzXTHKFe6LEr4sZlN2B99jXVTB6p4cXAKPWZazDyadvyvX42G8Kb+0I5YxHXfUEDPX2MRv jBW+nzB8FwIwQh0ZFOU0y3HbqGbsyZwhlL9hT7Ac4CG7C7y5KEg9Ywr6lG444595sVyYheWVPq5X 59d88NEpggSUeAemUwQJqFl9qJbAV/w7081JxWJLx9S66Zuv2BPe7RWDRxDCLZYTSSIovXwKLGLL sviRTbE7g1SL3YNmmZvVbFmoWkzF7qkg3sOkmG5PKCotqta5fl1BgybFeNDhq6Gg6rHnQICZhJR1 DI1rmjWTa00TW2gGh+IbiKSkhbpQXjxlMB3pQ9KXyKahfpuHacsAlq3wL6lCuX2Rwvbxb6hlM7qu qIxiP6GBwUzm6ykRQH3Y1Azy6Qz+XveIQKbojNVy9tWQ74NL+O4lHKmt3eqoa2KCjrWGATwpVVSn 7BKmc+kJ6oSmH7F4nSq2FMQhcg+pZsTfURVH1Ft1hv7hBscAPYu7GR3FCGyTQO7fkr52L1o1WyiS FuMcBfaAGBcz0Nxqht8X7JGMcmxMF9wCUFDkyBvgNTivigrIFZsUdBo0VW/RoVk5K4s5uV+tB9l0 x9sZRVZ9OrBM46IfwD3DhCXL8OUQ+AoDNi/yB7XK7mVBJLQx+nIGTvP3dVYiFVO2yhBUPjHN6IS/ ROdP6x6r9z2gAj3BYuTgt66+mpqhxRA5hXXcLt8kYthqeX2sdk4Tc96Ts7stt6nujntFBtwr1hWb ZqV5rQX1CIDlgR/4A298oVJYyk/rn89+kOOquhknsJpurmH8vtbN+nQsla/euNTbD+kGsD3XhYb7 SWMsvTCGkSNdTeBPmd0pUd0pH4CbxZMHel5peY0rVurz69USCMv0q3RSnZOhi+TIDOmjV1bv9NDd YDgJlKG2+YxXyMrlhpcr9jheIfe1iuRsATY27WFdEtB9KFrSPYqqWLAv6SmYIAmjYF+4j98QIh2U 3qNgtq/rULZVl93OVbGaCkUR3Xay0brVzad8wh6Ll7boRHGlOjSFNselenVSMXVtKBIbRsI6sO4N pbUkpWK4YDeGQ8NAbkbSk5s7unHyc52W0w9ho6fRp1cBWBMbStgSMkJIt4Nu8EWClN669FdQNasL y7ZmhuGyPZIs0dLY+YzdYytsuYl7Ov1LIHC/tQE65R1EdLHMGkrtxZ/pYjXVo8pFlhdz8qoPam9x SBub6ELngpvCbq2t9Qg7oP3xEGlbM58jbnsa2ehbpxSFer1BF6IdidtDjyNyG2KfzO2xltDpb1nQ O+WsVwTlztyAh3jK4Fx3U/CtHRM9gpfB5rbwMwVvzXyO4O1pyh87LV0KEnwXoh3B20NbBO9MFSGn qU9WaeF+UYdWEXt6n4rYYy0V0VEyNQFM2YXeJUXzfKOmJxH1kDvZ1NST1i6QHj3BO33JQXpizXyO ntjTvnCxh550IdrRE3vocRyEDbFP+vZYS/o3eIZZQcz7G6Zf1HpE73ZT77eiWIj8BvbXu1QhwfN+ JyeaqtDa59KjCj7eXThIFayZz1EFe9oXuivZpwpdiHZUwR56HFWwIfapgj3WqQrX5BDG6hq0iscx O3TWn3x834iTB00laO2UacbXIELsslAQqWsJGIU5g0pTcsyAKOhv5JQmn6zdPdo3qQtjvMpaQ+7k asSxxFIba2p+mX7XXl5UkFgwfOFnketGv7VK8euRf254/cR0gO6bAN08wSBdNWl1pAn40hsR7bcA zeiYb1+6gFnC9+FQUT7bJPoWoTprnquKIenwfXcBtYZgPkM5kWcBRafVIIrHxXKuLtN389oG5ZYL hbC1sdXyFwp+sxWlPtXKoyy3Wnu6bPd9CEkg6ArlgTpTZFS+NO+QRemBwv1QHQ7OdCkI6IVRNezd BtF6aNAip5BjI6LWM5XdUkMK9u4tqIJARrst55CIzBIWlOTiEpfLIssrkw9P2XXpkfGQ4c8nxXzB 3pn6SKXfivl9QBjoqXc3q6oVcvOX/xITZx7p98Kb5Nui1orhizi5aLzytWVl2G1gnIfNbuqKVU1u 1LG4Aiv+asojsIySwts1Vc6wQmupqeqdVaVSqgkkgxK5FOolkUGttoWg+bhS3AAw5CiibkchY4l+ r0a6SyGxRo9tp/ZY5SjeqPQ7n5oa1KTIcQ/QvZlWlbO2tk5m4h0yg0V1KK3n+kYm1kfQd7Dl3GWy kAakO0BmSrWov3bTCepSfx7gGwxr87u1v7XTre6SBdbZuC+91ID8d/1/Lr7DFhnF9ZmdxIS+dWSn X2uVMDwojOjVg/arOyIf36mMiPBuEr4+Et82yFM2ATynV4vxw0wIdl4wc0j3PwT17VANCmVuZHN0 cmVhbQ0KZW5kb2JqDQo1IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1l L0YxL0Jhc2VGb250L0FCQ0RFRStUaW1lcyMyME5ldyMyMFJvbWFuLEJvbGQvRW5jb2RpbmcvV2lu QW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDYgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAx MjEvV2lkdGhzIDE0MiAwIFI+Pg0KZW5kb2JqDQo2IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlw dG9yL0ZvbnROYW1lL0FCQ0RFRStUaW1lcyMyME5ldyMyMFJvbWFuLEJvbGQvRmxhZ3MgMzIvSXRh bGljQW5nbGUgMC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjc3L0F2Z1dpZHRo IDQyNy9NYXhXaWR0aCAyNTU4L0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgNDIv U3RlbVYgNDIvRm9udEJCb3hbIC01NTggLTIxNiAyMDAwIDY3N10gL0ZvbnRGaWxlMiAxMzggMCBS Pj4NCmVuZG9iag0KNyAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9G Mi9CYXNlRm9udC9BQkNERUUrVGltZXMjMjBOZXcjMjBSb21hbi9FbmNvZGluZy9XaW5BbnNpRW5j b2RpbmcvRm9udERlc2NyaXB0b3IgOCAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9XaWR0 aHMgMTQzIDAgUj4+DQplbmRvYmoNCjggMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9u dE5hbWUvQUJDREVFK1RpbWVzIzIwTmV3IzIwUm9tYW4vRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9B c2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjkzL0F2Z1dpZHRoIDQwMS9NYXhXaWR0 aCAyNjE0L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgNDIvU3RlbVYgNDAvRm9u dEJCb3hbIC01NjggLTIxNiAyMDQ2IDY5M10gL0ZvbnRGaWxlMiAxNDQgMCBSPj4NCmVuZG9iag0K OSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTAvQmFzZUZvbnQvQUJDREVFK1RpbWVz IzIwTmV3IzIwUm9tYW4sQm9sZC9FbmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyAx MCAwIFIvVG9Vbmljb2RlIDEzNyAwIFI+Pg0KZW5kb2JqDQoxMCAwIG9iag0KWyAxMSAwIFJdIA0K ZW5kb2JqDQoxMSAwIG9iag0KPDwvQmFzZUZvbnQvQUJDREVFK1RpbWVzIzIwTmV3IzIwUm9tYW4s Qm9sZC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkv RFcgMTAwMC9DSURTeXN0ZW1JbmZvIDEyIDAgUi9Gb250RGVzY3JpcHRvciAxMyAwIFIvVyAxNDAg MCBSPj4NCmVuZG9iag0KMTIgMCBvYmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnko QWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2JqDQoxMyAwIG9iag0KPDwvVHlwZS9Gb250RGVz Y3JpcHRvci9Gb250TmFtZS9BQkNERUUrVGltZXMjMjBOZXcjMjBSb21hbixCb2xkL0ZsYWdzIDMy L0l0YWxpY0FuZ2xlIDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0IDY3Ny9BdmdX aWR0aCA0MjcvTWF4V2lkdGggMjU1OC9Gb250V2VpZ2h0IDcwMC9YSGVpZ2h0IDI1MC9MZWFkaW5n IDQyL1N0ZW1WIDQyL0ZvbnRCQm94WyAtNTU4IC0yMTYgMjAwMCA2NzddIC9DSURTZXQgMTQxIDAg Ui9Gb250RmlsZTIgMTM4IDAgUj4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsv UmVjdFsgMzI2LjE5IDQ0My4wMSA1MTAuMzMgNDU2LjgxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5 cGUvQWN0aW9uL1MvVVJJL1VSSShtYWlsdG86c3RldmUudHJvd2JyaWRnZUBhbGNhdGVsLWx1Y2Vu dC5jb20pID4+L1N0cnVjdFBhcmVudCAxPj4NCmVuZG9iag0KMTUgMCBvYmoNCjw8L1R5cGUvRm9u dC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FCQ0RFRStTeW1ib2wvRW5jb2RpbmcvSWRlbnRpdHkt SC9EZXNjZW5kYW50Rm9udHMgMTYgMCBSL1RvVW5pY29kZSAxNDYgMCBSPj4NCmVuZG9iag0KMTYg MCBvYmoNClsgMTcgMCBSXSANCmVuZG9iag0KMTcgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStT eW1ib2wvU3VidHlwZS9DSURGb250VHlwZTIvVHlwZS9Gb250L0NJRFRvR0lETWFwL0lkZW50aXR5 L0RXIDEwMDAvQ0lEU3lzdGVtSW5mbyAxOCAwIFIvRm9udERlc2NyaXB0b3IgMTkgMCBSL1cgMTQ5 IDAgUj4+DQplbmRvYmoNCjE4IDAgb2JqDQo8PC9PcmRlcmluZyhJZGVudGl0eSkgL1JlZ2lzdHJ5 KEFkb2JlKSAvU3VwcGxlbWVudCAwPj4NCmVuZG9iag0KMTkgMCBvYmoNCjw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK1N5bWJvbC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0Fz Y2VudCAxMDA1L0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjkzL0F2Z1dpZHRoIDYwMC9NYXhXaWR0 aCAxMTEzL0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDYwL0ZvbnRCQm94WyAwIC0y MTYgMTExMyA2OTNdIC9DSURTZXQgMTUwIDAgUi9Gb250RmlsZTIgMTQ3IDAgUj4+DQplbmRvYmoN CjIwIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0Y1L0Jhc2VGb250 L0FCQ0RFRStBcmlhbC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgMjEg MCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAzMi9XaWR0aHMgMTUxIDAgUj4+DQplbmRvYmoNCjIx IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStBcmlhbC9GbGFn cyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA5MDUvRGVzY2VudCAtMjEwL0NhcEhlaWdodCA3Mjgv QXZnV2lkdGggNDQxL01heFdpZHRoIDI3MTAvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvTGVh ZGluZyAzMy9TdGVtViA0NC9Gb250QkJveFsgLTY2NSAtMjEwIDIwNDYgNzI4XSAvRm9udEZpbGUy IDE1MiAwIFI+Pg0KZW5kb2JqDQoyMiAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1h Z2UvV2lkdGggMTA3L0hlaWdodCAxMjAvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv bmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjgwMj4+ DQpzdHJlYW0NCnic7Z3Nix3XmYfnD8g0WRom6xASmM0sPFkMDsREMBkMk9FgZojBJLHlZGGysWYT pCwigrPw4ATJjsE2Y1kRJhL6sLGD7fa0UVuyLNmSpZFaUvTdre6oZaXT3Y5HKISep+pRvzlTVbfu ube/QcVLUbdu3VPn/M7v/TjvOVV3bq5h+9Pl8Zn3jjd9c3fL2m7fvj3z4n5gXOmKrOFtYuTi5KZn QHKlK7KGNwCc2je00rVYwxsqPHHfo3+emlnpiqzhDRKOrd94V5H73vDFo5//Gg5lpSuyhrfJDVvA 8K5H7nvDBl75q7+7q8gL2bCEYHhXkfve0N+xL37rriIvZLv59E5IWEQ1f5hd6bqsyQ3unblnHRiC 5ErXZa1uWsLCGN7NM/S14Y6xhIuuyLfLbXr21o2pP3wyPTM6fvPqtekQTiJ8y5Wf/e+txbrpSm04 YklIcLiQcsZv3EQOHLn6wu6jP906/P0fvfZvj+9GHnpijwfIP//glfTMfzz5FrJj70l+dfbS5GK1 aJm3ICHSU55BmtHwVwfPbPrFO//48M6v//t/CQsAbtt++OU3jr996Nxb750Cnw/+59Kxc6PsPbN/ 6NSO/ce4RgwBlt9SAuVw8ccjExa+dK1e3A3cBBAkc6IaFBDcaD5w/e0/PccexMDk5JnrkPB3N6dQ 2+nZWYQDhZMKv00PRj+Zuvy7yTOj42ALkgNfeRIkEQhMmdzl0z9+tgwILHCDhNjAOxi2Dk+wYPBN 3P7m3v+kyTScNmLKpmZmA5wQ8By78UnI1clCQCzk4sTk+fHriB/Vblj60+0HoSWc5AwfKXw5Aelj CxI2RjXgA3RQghZ96f5t8IRmwjdpVsetDmMgWcEQAPkID+UtSEI/bgRip65ce/PouTAOnKSQVavX VCxIWORqkqgGoIQOtUL+/l9eQHmBFJn99I8IGLpX4qQCFJITSWEUNASjhz2EctyFPYjBbaDjAvAE YZB8bs8R7SS3pitXEKiWDdAu/PU/hDFEr2kyFQYxcENVsXI0gcZimviot6W9KDKKFhLula/4OdcD ER4EQwfH0HeBBRbgol8oP3pH3w3JERCjEG56/OLY2O8/5ed4JU7ag6vTNhLJhCJjDNc9/muaA1bw BNcJMWgXZ/SYHNBeUAqgaCBSATY8rDEM571Ml82vQCZoCd/QaxALVDm4/zu/osCDZy/z7YcXrsJG fktp9Mtq02hcMPobGO5+7KldB06DAxUGPeoMUFACSImNrXzs0ejbyRZfQTYw4Sd0gXELpWFFEQkG FUEPtquzCEiKEl8Nn74EehyDJAcAeHpsEjD5LWfojlWl0TQ2JSHy8IPPUm1bTTMFSjXUuIWE0fOr 9ILpwi5+ptnkox4B30qxOgiICm/fP3cFGLkLGEJL+gt8RFXiycZXBk+AISylc4156J3VQEXqoAF/ +XPf/Isil5Ehuqzj0Bdgyiqg6ThSST0Iwk/4ITDSfJqMNylHc7MYhyJo2TqscQNJtBvEuJ4DzgAO YAJXEA8zQj2PnB89dnmSPcfEVARXKzsqpCFUHrWieu9844cpCQfvfQSeUH8jlgp6gRjghDQ6Yn5I H+lfOBmxjVE3ao6Oq5gFRbcfxO9oM8ETAMUQQtIFX33oJczj0OlLMBMYMaQquOPr5d/wqtolaoXN oVER0ihAStsdU6ToiVUKXQXGCoDci26CzHKvEhxywEnsHuqsamv6gA7cwAqDiSKDrX3NV46vZS9n OKCEZUYPHUEFIB49G8Mr4uoIaRCOZ17crwUTvZR1GreKNGIoAyGVACKV6Jo9J/k5J4FRWPTg4pl6 f6sNnj/f8yF7sDVCWM5hC+gZcREta8BpBQDCloo3KTB87zhN46uu6HXCEAAdQXO+MtZzJAKArx4c kWPUCpchhljmYkx38gL8hIofXRxHc/kIXPRInOQMl3FyeXT545EJOpEKCJpjK8mATIxcTEMaHQon AaGO3u3aVsEQAUD29JRaqVtRtQEQ9dTXq5gYNDQCM8iVoqSeFrbxcuGCcdkgBtqS8PD5a5hEAOTg 21veWAYeYvdAD0Wg6x2TBoBSgnY5aZIKtpFWi0wLeo0YSkLOOFSZK7M6BjMwzQwM7gBwqAxfURPc BzUxIMeDwF7qDJJGj2AImKAHsEAngOwRdXnp7CElW2Etj0POFEAIqUZXvIl511RPO6HXCUDOYzd0 mjTTcSIRC/eVio5HDAUVRhxcBtk4j4/jeiMZoho0lzO0hY+qMPL68fOIg8qlGPHRBNWBuhn51wFE sE5YEteBVDHc9IzQ1Ucfc/OJ1gBQDAHQkzDHaBPLBqNQBC2k0FkHqyR6XM+xpOWAj1DRoBrciKX5 CAk5lnsB4K4PzhmxL3qMTU2oP7pjJjMFMMIJScgQvu5NIuVV4VuljyoYzpVGwzAPbphUhEsAK9XT HFd0qxhyYKQH5VBwR3ND81QEvTePFlhhMwPAfR/+lv3z757lAu61iOiBm4NQKhzVawTQpDHkKcb+ ydgkhMCmK4CeT6EzA8DGrdVfRzctACJ4ExNBQAeAWD9HIqCHVdTzQksQDgDF0AvwXIuCHg0xU4QV Svu3kwrrJak8jE3DwghsnEPppMIc83OUSOi4qSofwzrOmJPRa1QADBVGUAegphAjFgBU+IhtxAfB CqJBXHAKIFr8mxOjpnQWHthQc4oCCn0Ht24H0DiNxoIkNpPBSN0YnrlnnanXRnVGd6i5eae5Mq0d sySyDni5L7AUbvTQOZ1IJPlTADlpBgzQAkD4ph8BQ1NtXMMZbaAA7jx8gT1DPwzvAgG0AlQVRdAa NwJ46UbRQK2fAiAowr9uem1s/ca6Ikf6OkVvdPymsHBTT4YXDvQc9ZisdlhhSMwFkjAFEDEgpECD wBRAc1+aRHgohimAnARh4t6+0aOeRg6wHcWxSnUA0RRCZYwbmCAcT41OIAzzH37w2fd3DcYEaJ2H Qbwde09yL9CAuhIvAukUwHTGBGxh4J1QeeswteK8GAaAfKRTQAkzGCoMejgOb4dJtCPYc/IOgIdK OXzhe0+9zTCw74wNZXJ3ZxaiSimAYqhnASXsG7BwEOKZuhanPIS3Eg/A5aRBYCWlkALoUC6CQLTD JD8VxrdSGZ0LoFFDwh4IwDEhH/UHMZNjNArEIB6QoiyQjZ9jDAPAl4bPIoX27T3ZB3pXr03TLxRI 4fQgKpACGBiqwoBQH4DkCPDCUpgAOBKvPhau6G8kEyKfwHn6ERiNsc2pvrD7KFYOxQFSGgJoHEAG OgudNa8FesYwHNBMzv/gmXdR5EAPEnKmv+GJkzWoJ63jIBhYIWE4kWIA1aSqOeKKzXTCrp5WTfU3 0EuniXVhoATlDFGkJQK7wDAm3zGJxDPD8yF0iBiyR5EFUIHAlNkH/ehBIwEwTA1Lox+BhLFgpg9x nKLPTaFrtH6VmeLUBWtSOCaOAhPMApA6beeYF0V2KDeUAKgL5sDxDhiiyEBHUM3+iR3v0ws9TaPE SJyaCKATCi0Y4og5ro+Ce8BwwxbzBnX06tavHkKHbbF6umD9iGbQQFov3AigguOAPD97/QSKDIDI L//7zH2P7My3hEAN4PuHTnE7cNOVRH3aSVjJqfYqxDzmvlrQa6FfJYBxBMcxg18TCy0ARhTN/oHS qYGbJES0hJkDZKCG8EaexaB76zAAWp8KhpWsAnswbBwF94DhF79lDraCXgXA+jqZTgDidtFiAMGP CGAFvQAQ9BSd77rHfy2AIPn0m6eKLsgYINPv2F5iSCNPagL/8WuNAKYY2hxjwr69iQKH8enltNEt eqQxjZ+JHgJonKEJWDY+pgCmeZgA0AgQxHAoqDMYbhscAcNvb3kDa9YVQHO/3CJiTphv7rGCYSWe SRW5v5CmUZ0dFfbBvRRA9MigQvfRor8RAYIhtgsMN+/7CBKCJwfg0DXD4OIKqqGtEEOzFlG3Cgnr yZkiqdU0gutHnV/cT48gde7lAAh66hHt0i5VVDjoFwBG9AKGGkMYCICIU8kt6GEk0V+wCmNrAjxG Q10VOTwydszF/ItFxUbu5aCH8BH9xRFH+NdIvxRAfYegMaIPAIGiJUVz4MhVk7TO8pv64Poipjp0 ziCtlFvJ4rRbplgxUxynSftiaMwAecGCQXDUrGeRey7ZapqUvzU/AX1LVw4BwBAPApcqESDoFRH4 7z9FZRS6viJcb0YRVL/60EtEiQ6aGjdCdBCGeJTZ1VrGhoGi66lz/k/63sBK4uUP8F3doSPGnsfw TQDzM37wk2hw4CtPtuRnQA+qU75DP/1vrJCv703ZmSd0QrDrT/rbIw6moFkKoJat008YCAvgcDns BUBYlAKI5qosLeXQHJ8FwCQS2JhzaESP+BkDCAmLdRolA/m5K8o6CQN2AcTICGDXn/QtNCQAxGI4 ceYEeifR4AeAWCfCM9Q5nQQRQIxbSznyBGqhwgjANgKIg6aSlEnhAojj6BXArj9ZIIAYCr2GAMai wUZx8MXFQ2XoAj2gMQCm7kMA28vB/lMOFYB+RIP0WuOQBJzxUxauCnelkzVcHgZScgCIxchnoOst YaBJlZhCchJTANvLkYEQDwCJBiGhZyqbDwpZPv4on4F4YbybALoCaikEktQBzGEgF6cMbAQwh4FO 7AIgltCGVzYuYMjs1IAAZjIQAImvXIdGyVpjp8Nir7SbmoFy7ZlXpr/y2Dr7IEOvDDRuAUDsWDp/ hF/IZyAqzDEqjLjIpLI5WuRGAWA+AwPAuflFzulBHEPy9gK5IK3S7WTVtFsFwEwGmgkUQBto8Lzz UBYDBRDQ4B76C4CVerqZQ9C598RAVyMzUC2e3dh70vWoLqqMSTqjDh/L6gqgc0k+F0YfYZBNcHFS e4vkM9AlbXUAHXcQB2Yy0MyqAxOQqfsR5xMtvCcGAiAMRJznEs90uMexXokIKgdAKF3M/pwbpfxY aW9qNAZrgJzJQAFEAsB05JtvAwFQD0I4jbZWInC62zjTwntlYPH8S/lYgbjFgDRgFMBMBgogIt/g YcA4XA4z+UoAMxloul4AVTEnf2lvvg0UQOgHCSmqkuF3PYAAUjhNyGeg68d8FMhFFCmAiuPHTAYy Ak3nsIiETUu69JRa7TpwOt8GfnRxXACLR29KANO8gSqcz0D8rA+/VB5VNg3INRYugJkMxDqBDHVw xj8kTYz0xMCpfUOA5prSEFfdx9ylrMhhoAAiXPzcniNp3u/5d3tgIBcDIAKANLb+rDeFcI2FQ6p8 BhLbu4zW9Z8YwwqMAWAmAyfue3Ryw5YPLt4IDC0KKEypvXn0Tg0zGahdQvUw8jrfABAm5zMQJ/Kz 10986f5tFFUH0CUiAtgTA8GZCqDFkX8TRsW8nAs2Mhno1N7Y+o3FE+uXJy0hxPK14Zk2EMfhAzjO GS3EBv7k1WP4Ea6vA2iewTnlnhjo/LUPsJiDTcUm65XyGWgqlYO33jvls0VpmdxFAHMY+MrgCbSD voM2MMSnG+CSGRh9QT4DAZBosBHAgTLMTgHMZGCs98Y+Ryq7giT+tFcGRlb//V2DqHO6tgpx5JjD QG4KZ1zi6OIEfTongQIAe2WgANbn2SmfCEfL0BMD9w+dGirXbJvNlocphhz0x0Bl9PNfO/bLPWB4 +Py1CoA5DORXsILx4ANP7DFLjzo75xtDuZ4YSCSD0tUzsT6dSvm9MtCULzYweJhiqPTNwBDcCuWI IffKt4GHzl/HBdPk7z31dpg+Zz1obE8jERnYaSQi34hzuBJM8hnoYNNMr49aYHZiXi8FsD8GprNL mEQAiZw5sHTtX1TAiXJMn7Gfc+VOl/caB5qNaRwLm67hW8oXwEwGxmBThqAsmGsffjERxz6fgTQn Xi3VONGJSQTDnJSvOROuxHHUl7uAHmycK0dhPkDRSbiAWjk1DAMxBY3ZGNeIciMu64mBMdhEwAoM fT6XHo+lFMZFmQw8Mzp+8MfPt6xb4FtGK3Pd0jvAoqnHSmPetw2OCJ3zvKCnHaCeLYXQEJ9kBP9w Io35QHB2pMwFVi+TgTFWCgFDRl7cGiQloUY10wbeUf8fP9+yTslXTmGd2gtEHUwEOb8ZKzqsz9z8 ExwtYiYcQNRfBH1vzEgzmsOkYANp+G9OjOYz0FC/giEIOBWLZ3n14Igal8lAW4qeoq2dMDxzz7o/ XR7vav8HylS2Rqyy+U6bduUdKB+M4mIAET0zWo3PgsFnxshc4ItW8hmIngpgLFN0b+5XkxghWQ6A 9Eg8A9hpjfqVck3mXDmR2l5mwMjdTTD6wJ3vAmoX54/Y1F/2hMpObzVuMAQLCYa4gHwG4uZiiJQi iagvFIudyWdgPACIwEOY3IhhvLNr6WayIhCSfo7jGj2IG9ejcRhYotZ8BgIg3s00TsBY4SR+IZ+B UDrtBX5eGIGm1UpaQpQxh069ipXBeIb7gFoDrSsTXJvKZT15YVQ1AKzDqJwfv57PQHxQCqB9QbG7 H3uqjqEL1Km5kz6LIhhGjRjKG1ksAMTD0lPti6VhHWougF2rJIAoaTEsms8RpUiGWGAmA6F0Cn50 CjDWXbNvZpgrF/lTn64Tf10F2rgIkAIjeAY9BjJ+274sx2gQPzg3H1r7QFmjqMICeGdN3aG/POZT B1Cv16m06Hco3dgLDsQYF9cXzqHL/lcCrcPnOoXa1cOmlKu8o6xYmj44EqELYtd0XeVLvMGVhjGZ GwD6OEAVw3lCshfA/ALjgTUPolPMAMC0I19+sB7Y3Hx6Z/oqSCJbujjeLEqQFoJyPVQOKACNoC7m ZOfKkI+bptCF8uY87EAPukbL9cmUjE8sX/p3K32ckLpRlMeg7fgofTglxZM9jqy+fi8OCGtpha8W xOwAYKUX0oWjYohrrrzqJ1I3uBuXFOZ32VxJORuSQhfouea8xf+mm28n8Ld4ZHQf8PEsjoDc481N OzgqF8AWGOvMTCnKtz6d4ROmFOKygcZy4i67DpzGrXSKtDkPmM4OgCdxRbpsEo0wKcHdqT8treBm 89mDHhXzWZvGAUh9gxIYBFwJJSA4ccB3jOxKV8MhAKQh4KmIZAXMFjwr2NIQLjZv7OT1z/d8qNpG CqVRGnlYF1T+2Z/sjNFE7DsJraaB1EQugQYBXv6qThSE39oFwghinkkBNKchLdthzAQTuLiMplFb aM+eu9AWv5LwFvXcniMAMnjvIznoBSe5HpPYgpvQsX+gXIsFc0TA/FImenOlJQR51CowdFIeoXw+ 8m0KYIqhMAaYJkA68acTyMAFA12MR+XRI27HfYuStx9Gc/tewQ6MkBYjX1dYmwn5nXez7zjpO3ky H1OKDf+l2qYGQTMlmJQPbtwCCRjrYKa07EkAU0JyOx8o/u4XHkMTF/IoWeqy6QVgDOtHc+Cb0MGc aLL06+MlHuZptYSBobZUSQEMGLuC2Q5s5Xzx85JvC3mGsSuM9I6zTvI8ZaPZA77tlX5uwO6jOimG 0m+gTP5rD3U0dakgmSkFhtsPY99QtMXiW1elhtt4fxW2otrFU+dN2bDMjfgTYmtXK7rs893etAXG XpEEQFjR6S0BSyRQkS5LmxnJ50jJ9rf50hgNeD0y93G86LgUyRY8U2Wv7ANtmrNYDzp1pZ8+pcI9 B7/wZOGvq/U1PpXCXaiJgCEeP1XzFMmu5GxBGC+cGeMtBDp6KixeXct6fdK/cYPAjBxTRTa0Rmim UwC65roBqTCzBdjK+fhVy1hjoazbOtw4AAkVo9X9+Y76ZsYSvkVmG9Zxi3DNhtmqc3uYWg+9UtAa hZbWUwd92zp6RNa1BNK0lOa0PBPXx8YwMIxhOPeUZsSfaeieD2MOzuwXQkXwV1u73ssRHC1diOft tPkqSNfIOU50rUjc2hmroOLiwoj0NHZz4CbfMvtUbaL+zuAs+oYxdKXT5vkAqe6dN5ejSHoQKgr1 UlAx00EbmfTUj85lLwV6btOzt77/o9ewflQMJFHbRscBsMb2XJDZ+z3BCEMyHTRo53eNC7AXy3F0 2nwrheiZW2isj3GUWVwM5ub5LMdiCaU9/OCzOVaxyMDUUgd19HzP+fK8GR4e+v8+JlrbK2ZyI3I7 i8JG0LNYyszRaAcaLVlTX6O3nO+En5qZddLT9wm0NxaQNYyG30HR/vTXFXp4fC1wodFbh7v6aL6t q7New3eRLf+/EuhTYkTc3mph9CkVE866mJ5gFC77InKVIcCIYWyHkXgm4ueIJTb94p2V+k8H7rtj 70kfQ84hVSg1Gh3po66BdPpbx+Cd/LtsbPcvxtKby2jBwdpSe4327fb8K7JpWmbc4jVAJxq0graY iIsxXaMdkL1p8NkJ6q5sfPlz38QHLUW03N929tKkr73N9xSh17DXmS9+DpJmgysZHk72NMzxGqOd TpkxqDi56ZnV80fJhTqXL76WivluwmSCSDqm1t24Tgwx0863przSbEMdtEqOgjOYOCKZxpdaX5l/ 19nqgdG3Z6uVm3uJ/Wy1x6izQaaLLgbKdXqcgYeIqFbwDzD9lhIA3OejDekp57tfeGzivkcbCTm2 fiMwrpK/nMYqHjhy1RWMkSrM97YiqYWkI8w6PlBOW8R0jMZQESKpq3iBz9H4Q1/ZdPj8Neo2tW9o csOWOoxQcVVpNEFpvKPYoCXlWCfoDMx0LjGaTjkmweQYAiEpHAFkzwQ/ORY9ujL98ylXnMI34PI9 wxXDWFlgs7KbMPpKWNoS04UpJ+Nj+OV2K9qYpE2NHneRk/g1dKFlfAFQEBL9rYxlAJbzqwrGj0cm 4sFzXW3YMQNsI0NYF5FhV00P3CyEMl2CUjyZvnX46rXpnPAYNv55agasKoR0XQ0wrmyUWNkMGv3T 0vu/8yut00D5LIbWMqaWuk4BqKSGQJRDaeKGF+v7L2mCkP/vacf1Gznp4sPVs30yPXPyzPWX3ziO y8ZGiaRPqYCkjgNGada0dZyBqE4lhJvwpWQv7D7qcrtFqRswIljCyn+GrjY2ut2e/4MbTGX807qv /vavluWq/03jH1gzeOTi8k9t7vxpy1K0S18jkhH8rKpoZw1twBheGyRhZgHjKlPq1b9BPMQwsgga N2wpbONdNva1hbtBwVehi1krG/QTSan4fwSadcMNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMyAwIG9i ag0KPDwvVGl0bGUob0xTOiBDbG9zdXJlIG9mIHRoZSBhZC1ob2MgZ3JvdXAgb24gTVBMUy1UUCkg L0F1dGhvcihTRzE1IENoYWlybWFuKSAvS2V5d29yZHMoMywgOSwgMTAsIDEyLCAxNC8xNSkgL0Ny ZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAFcAbwByAGQAIAAyADAAMQAwKSAvQ3JlYXRp b25EYXRlKEQ6MjAxMzAxMTcyMzQyMzUrMDEnMDAnKSAvTW9kRGF0ZShEOjIwMTMwMTE3MjM0MjM1 KzAxJzAwJykgL1Byb2R1Y2VyKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABXAG8AcgBkACAAMgAw ADEAMCkgPj4NCmVuZG9iag0KMjQgMCBvYmoNCjw8L1R5cGUvU3RydWN0VHJlZVJvb3QvUm9sZU1h cCAyNSAwIFIvUGFyZW50VHJlZSAyNiAwIFIvS1sgMjcgMCBSXSAvUGFyZW50VHJlZU5leHRLZXkg Mj4+DQplbmRvYmoNCjI1IDAgb2JqDQo8PC9Gb290bm90ZS9Ob3RlL0VuZG5vdGUvTm90ZS9UZXh0 Ym94L1NlY3QvSGVhZGVyL1NlY3QvRm9vdGVyL1NlY3QvSW5saW5lU2hhcGUvU2VjdC9Bbm5vdGF0 aW9uL1NlY3QvQXJ0aWZhY3QvU2VjdC9Xb3JrYm9vay9Eb2N1bWVudC9Xb3Jrc2hlZXQvUGFydC9N YWNyb3NoZWV0L1BhcnQvQ2hhcnRzaGVldC9QYXJ0L0RpYWxvZ3NoZWV0L1BhcnQvU2xpZGUvUGFy dC9DaGFydC9TZWN0L0RpYWdyYW0vRmlndXJlPj4NCmVuZG9iag0KMjYgMCBvYmoNCjw8L051bXNb IDAgMzIgMCBSIDEgMTExIDAgUl0gPj4NCmVuZG9iag0KMjcgMCBvYmoNCjw8L1AgMjQgMCBSL1Mv UGFydC9UeXBlL1N0cnVjdEVsZW0vS1sgMjggMCBSIDEyMCAwIFIgMTIxIDAgUiAxMjIgMCBSIDEy MyAwIFIgMTM0IDAgUiAxMzUgMCBSIDEzNiAwIFJdID4+DQplbmRvYmoNCjI4IDAgb2JqDQo8PC9Q IDI3IDAgUi9TL1RhYmxlL1R5cGUvU3RydWN0RWxlbS9LWyAyOSAwIFIgMzcgMCBSIDQ0IDAgUiA1 MCAwIFIgNTggMCBSIDYxIDAgUiA2NiAwIFIgNzEgMCBSIDc1IDAgUiA4MCAwIFIgODUgMCBSIDkw IDAgUiA5NSAwIFIgMTAwIDAgUiAxMTYgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQoyOSAwIG9i ag0KPDwvUCAyOCAwIFIvUy9UUi9UeXBlL1N0cnVjdEVsZW0vS1sgMzAgMCBSIDMzIDAgUiAzNSAw IFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjMwIDAgb2JqDQo8PC9QIDI5IDAgUi9TL1REL1R5cGUv U3RydWN0RWxlbS9LWyAzMSAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjMxIDAgb2JqDQo8PC9Q IDMwIDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDBdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjMy IDAgb2JqDQpbIDMxIDAgUiAzNCAwIFIgMzYgMCBSIDQwIDAgUiA0MSAwIFIgNDMgMCBSIDQ4IDAg UiA0OSAwIFIgNTIgMCBSIDU0IDAgUiA1NiAwIFIgNTcgMCBSIDYwIDAgUiA2MyAwIFIgNjUgMCBS IDY4IDAgUiA3MCAwIFIgNzMgMCBSIDc0IDAgUiA3NyAwIFIgNzkgMCBSIDgyIDAgUiA4NCAwIFIg ODcgMCBSIDg5IDAgUiA5MiAwIFIgOTQgMCBSIDk3IDAgUiA5OSAwIFIgMTAyIDAgUiAxMDQgMCBS IDEwNSAwIFIgMTA2IDAgUiAxMDggMCBSIDExMCAwIFIgMTEzIDAgUiAxMTQgMCBSIDExNSAwIFIg MTE4IDAgUiAxMTkgMCBSIDEyMSAwIFIgMTIyIDAgUiAxMjUgMCBSIDEyNyAwIFIgMTI5IDAgUiAx MzEgMCBSIDEzMyAwIFIgMTM0IDAgUiAxMzUgMCBSIDEzNiAwIFIgMTIwIDAgUl0gDQplbmRvYmoN CjMzIDAgb2JqDQo8PC9QIDI5IDAgUi9TL1REL1R5cGUvU3RydWN0RWxlbS9LWyAzNCAwIFJdIC9Q ZyAzIDAgUj4+DQplbmRvYmoNCjM0IDAgb2JqDQo8PC9QIDMzIDAgUi9TL1AvVHlwZS9TdHJ1Y3RF bGVtL0tbIDFdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjM1IDAgb2JqDQo8PC9QIDI5IDAgUi9TL1RE L1R5cGUvU3RydWN0RWxlbS9LWyAzNiAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjM2IDAgb2Jq DQo8PC9QIDM1IDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDJdIC9QZyAzIDAgUj4+DQplbmRv YmoNCjM3IDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyAzOCAwIFIg MzkgMCBSIDQyIDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMzggMCBvYmoNCjw8L1AgMzcgMCBS L1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQozOSAwIG9iag0K PDwvUCAzNyAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgNDAgMCBSIDQxIDAgUl0gL1BnIDMg MCBSPj4NCmVuZG9iag0KNDAgMCBvYmoNCjw8L1AgMzkgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0v S1sgM10gL1BnIDMgMCBSPj4NCmVuZG9iag0KNDEgMCBvYmoNCjw8L1AgMzkgMCBSL1MvUC9UeXBl L1N0cnVjdEVsZW0vS1sgNF0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNDIgMCBvYmoNCjw8L1AgMzcg MCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQzIDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0K NDMgMCBvYmoNCjw8L1AgNDIgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgNV0gL1BnIDMgMCBS Pj4NCmVuZG9iag0KNDQgMCBvYmoNCjw8L1AgMjggMCBSL1MvVFIvVHlwZS9TdHJ1Y3RFbGVtL0tb IDQ1IDAgUiA0NiAwIFIgNDcgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo0NSAwIG9iag0KPDwv UCA0NCAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1tdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjQ2 IDAgb2JqDQo8PC9QIDQ0IDAgUi9TL1REL1R5cGUvU3RydWN0RWxlbS9LW10gL1BnIDMgMCBSPj4N CmVuZG9iag0KNDcgMCBvYmoNCjw8L1AgNDQgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQ4 IDAgUiA0OSAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjQ4IDAgb2JqDQo8PC9QIDQ3IDAgUi9T L1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDZdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjQ5IDAgb2JqDQo8 PC9QIDQ3IDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDddIC9QZyAzIDAgUj4+DQplbmRvYmoN CjUwIDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA1MSAwIFIgNTMg MCBSIDU1IDAgUiA1NyAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjUxIDAgb2JqDQo8PC9QIDUw IDAgUi9TL1REL1R5cGUvU3RydWN0RWxlbS9LWyA1MiAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoN CjUyIDAgb2JqDQo8PC9QIDUxIDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDhdIC9QZyAzIDAg Uj4+DQplbmRvYmoNCjUzIDAgb2JqDQo8PC9QIDUwIDAgUi9TL1REL1R5cGUvU3RydWN0RWxlbS9L WyA1NCAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjU0IDAgb2JqDQo8PC9QIDUzIDAgUi9TL1Av VHlwZS9TdHJ1Y3RFbGVtL0tbIDldIC9QZyAzIDAgUj4+DQplbmRvYmoNCjU1IDAgb2JqDQo8PC9Q IDUwIDAgUi9TL1REL1R5cGUvU3RydWN0RWxlbS9LWyA1NiAwIFJdIC9QZyAzIDAgUj4+DQplbmRv YmoNCjU2IDAgb2JqDQo8PC9QIDU1IDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDEwXSAvUGcg MyAwIFI+Pg0KZW5kb2JqDQo1NyAwIG9iag0KPDwvUCA1MCAwIFIvUy9TcGFuL1R5cGUvU3RydWN0 RWxlbS9QZyAzIDAgUi9LIDExPj4NCmVuZG9iag0KNTggMCBvYmoNCjw8L1AgMjggMCBSL1MvVFIv VHlwZS9TdHJ1Y3RFbGVtL0tbIDU5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNTkgMCBvYmoN Cjw8L1AgNTggMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDYwIDAgUl0gL1BnIDMgMCBSPj4N CmVuZG9iag0KNjAgMCBvYmoNCjw8L1AgNTkgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMTJd IC9QZyAzIDAgUj4+DQplbmRvYmoNCjYxIDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3Ry dWN0RWxlbS9LWyA2MiAwIFIgNjQgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo2MiAwIG9iag0K PDwvUCA2MSAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgNjMgMCBSXSAvUGcgMyAwIFI+Pg0K ZW5kb2JqDQo2MyAwIG9iag0KPDwvUCA2MiAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAxM10g L1BnIDMgMCBSPj4NCmVuZG9iag0KNjQgMCBvYmoNCjw8L1AgNjEgMCBSL1MvVEQvVHlwZS9TdHJ1 Y3RFbGVtL0tbIDY1IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNjUgMCBvYmoNCjw8L1AgNjQg MCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMTRdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjY2IDAg b2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA2NyAwIFIgNjkgMCBSXSAv UGcgMyAwIFI+Pg0KZW5kb2JqDQo2NyAwIG9iag0KPDwvUCA2NiAwIFIvUy9URC9UeXBlL1N0cnVj dEVsZW0vS1sgNjggMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo2OCAwIG9iag0KPDwvUCA2NyAw IFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAxNV0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNjkgMCBv YmoNCjw8L1AgNjYgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDcwIDAgUl0gL1BnIDMgMCBS Pj4NCmVuZG9iag0KNzAgMCBvYmoNCjw8L1AgNjkgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sg MTZdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjcxIDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUv U3RydWN0RWxlbS9LWyA3MiAwIFIgNzQgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo3MiAwIG9i ag0KPDwvUCA3MSAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgNzMgMCBSXSAvUGcgMyAwIFI+ Pg0KZW5kb2JqDQo3MyAwIG9iag0KPDwvUCA3MiAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAx N10gL1BnIDMgMCBSPj4NCmVuZG9iag0KNzQgMCBvYmoNCjw8L1AgNzEgMCBSL1MvU3Bhbi9UeXBl L1N0cnVjdEVsZW0vUGcgMyAwIFIvSyAxOD4+DQplbmRvYmoNCjc1IDAgb2JqDQo8PC9QIDI4IDAg Ui9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA3NiAwIFIgNzggMCBSXSAvUGcgMyAwIFI+Pg0KZW5k b2JqDQo3NiAwIG9iag0KPDwvUCA3NSAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgNzcgMCBS XSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo3NyAwIG9iag0KPDwvUCA3NiAwIFIvUy9QL1R5cGUvU3Ry dWN0RWxlbS9LWyAxOV0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNzggMCBvYmoNCjw8L1AgNzUgMCBS L1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDc5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KNzkg MCBvYmoNCjw8L1AgNzggMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMjBdIC9QZyAzIDAgUj4+ DQplbmRvYmoNCjgwIDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA4 MSAwIFIgODMgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo4MSAwIG9iag0KPDwvUCA4MCAwIFIv Uy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgODIgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo4MiAw IG9iag0KPDwvUCA4MSAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAyMV0gL1BnIDMgMCBSPj4N CmVuZG9iag0KODMgMCBvYmoNCjw8L1AgODAgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDg0 IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KODQgMCBvYmoNCjw8L1AgODMgMCBSL1MvUC9UeXBl L1N0cnVjdEVsZW0vS1sgMjJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjg1IDAgb2JqDQo8PC9QIDI4 IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA4NiAwIFIgODggMCBSXSAvUGcgMyAwIFI+Pg0K ZW5kb2JqDQo4NiAwIG9iag0KPDwvUCA4NSAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgODcg MCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo4NyAwIG9iag0KPDwvUCA4NiAwIFIvUy9QL1R5cGUv U3RydWN0RWxlbS9LWyAyM10gL1BnIDMgMCBSPj4NCmVuZG9iag0KODggMCBvYmoNCjw8L1AgODUg MCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDg5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0K ODkgMCBvYmoNCjw8L1AgODggMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMjRdIC9QZyAzIDAg Uj4+DQplbmRvYmoNCjkwIDAgb2JqDQo8PC9QIDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9L WyA5MSAwIFIgOTMgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo5MSAwIG9iag0KPDwvUCA5MCAw IFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgOTIgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo5 MiAwIG9iag0KPDwvUCA5MSAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAyNV0gL1BnIDMgMCBS Pj4NCmVuZG9iag0KOTMgMCBvYmoNCjw8L1AgOTAgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tb IDk0IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KOTQgMCBvYmoNCjw8L1AgOTMgMCBSL1MvUC9U eXBlL1N0cnVjdEVsZW0vS1sgMjZdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjk1IDAgb2JqDQo8PC9Q IDI4IDAgUi9TL1RSL1R5cGUvU3RydWN0RWxlbS9LWyA5NiAwIFIgOTggMCBSXSAvUGcgMyAwIFI+ Pg0KZW5kb2JqDQo5NiAwIG9iag0KPDwvUCA5NSAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sg OTcgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQo5NyAwIG9iag0KPDwvUCA5NiAwIFIvUy9QL1R5 cGUvU3RydWN0RWxlbS9LWyAyN10gL1BnIDMgMCBSPj4NCmVuZG9iag0KOTggMCBvYmoNCjw8L1Ag OTUgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDk5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9i ag0KOTkgMCBvYmoNCjw8L1AgOTggMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMjhdIC9QZyAz IDAgUj4+DQplbmRvYmoNCjEwMCAwIG9iag0KPDwvUCAyOCAwIFIvUy9UUi9UeXBlL1N0cnVjdEVs ZW0vS1sgMTAxIDAgUiAxMDMgMCBSIDEwNyAwIFIgMTE1IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9i ag0KMTAxIDAgb2JqDQo8PC9QIDEwMCAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgMTAyIDAg Ul0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTAyIDAgb2JqDQo8PC9QIDEwMSAwIFIvUy9QL1R5cGUv U3RydWN0RWxlbS9LWyAyOV0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTAzIDAgb2JqDQo8PC9QIDEw MCAwIFIvUy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgMTA0IDAgUiAxMDUgMCBSIDEwNiAwIFJdIC9Q ZyAzIDAgUj4+DQplbmRvYmoNCjEwNCAwIG9iag0KPDwvUCAxMDMgMCBSL1MvUC9UeXBlL1N0cnVj dEVsZW0vS1sgMzBdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEwNSAwIG9iag0KPDwvUCAxMDMgMCBS L1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMzFdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEwNiAwIG9i ag0KPDwvUCAxMDMgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sgMzJdIC9QZyAzIDAgUj4+DQpl bmRvYmoNCjEwNyAwIG9iag0KPDwvUCAxMDAgMCBSL1MvVEQvVHlwZS9TdHJ1Y3RFbGVtL0tbIDEw OCAwIFIgMTA5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTA4IDAgb2JqDQo8PC9QIDEwNyAw IFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAzM10gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTA5IDAg b2JqDQo8PC9QIDEwNyAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAxMTAgMCBSIDExMSAwIFIg MTE0IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTEwIDAgb2JqDQo8PC9QIDEwOSAwIFIvUy9T cGFuL1R5cGUvU3RydWN0RWxlbS9QZyAzIDAgUi9LIDM0Pj4NCmVuZG9iag0KMTExIDAgb2JqDQo8 PC9QIDEwOSAwIFIvUy9MaW5rL1R5cGUvU3RydWN0RWxlbS9LWyAxMTIgMCBSIDExMyAwIFJdIC9Q ZyAzIDAgUj4+DQplbmRvYmoNCjExMiAwIG9iag0KPDwvVHlwZS9PQkpSL09iaiAxNCAwIFIvUGcg MyAwIFI+Pg0KZW5kb2JqDQoxMTMgMCBvYmoNCjw8L1AgMTExIDAgUi9TL1NwYW4vVHlwZS9TdHJ1 Y3RFbGVtL1BnIDMgMCBSL0sgMzU+Pg0KZW5kb2JqDQoxMTQgMCBvYmoNCjw8L1AgMTA5IDAgUi9T L1NwYW4vVHlwZS9TdHJ1Y3RFbGVtL1BnIDMgMCBSL0sgMzY+Pg0KZW5kb2JqDQoxMTUgMCBvYmoN Cjw8L1AgMTAwIDAgUi9TL1NwYW4vVHlwZS9TdHJ1Y3RFbGVtL1BnIDMgMCBSL0sgMzc+Pg0KZW5k b2JqDQoxMTYgMCBvYmoNCjw8L1AgMjggMCBSL1MvVFIvVHlwZS9TdHJ1Y3RFbGVtL0tbIDExNyAw IFIgMTE5IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTE3IDAgb2JqDQo8PC9QIDExNiAwIFIv Uy9URC9UeXBlL1N0cnVjdEVsZW0vS1sgMTE4IDAgUl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTE4 IDAgb2JqDQo8PC9QIDExNyAwIFIvUy9QL1R5cGUvU3RydWN0RWxlbS9LWyAzOF0gL1BnIDMgMCBS Pj4NCmVuZG9iag0KMTE5IDAgb2JqDQo8PC9QIDExNiAwIFIvUy9TcGFuL1R5cGUvU3RydWN0RWxl bS9QZyAzIDAgUi9LIDM5Pj4NCmVuZG9iag0KMTIwIDAgb2JqDQo8PC9QIDI3IDAgUi9TL0ZpZ3Vy ZS9BbHQoaXR1LW9sZCkgL1R5cGUvU3RydWN0RWxlbS9LWyA1MF0gL1BnIDMgMCBSPj4NCmVuZG9i ag0KMTIxIDAgb2JqDQo8PC9QIDI3IDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQwXSAvUGcg MyAwIFI+Pg0KZW5kb2JqDQoxMjIgMCBvYmoNCjw8L1AgMjcgMCBSL1MvUC9UeXBlL1N0cnVjdEVs ZW0vS1sgNDFdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEyMyAwIG9iag0KPDwvUCAyNyAwIFIvUy9M L1R5cGUvU3RydWN0RWxlbS9LWyAxMjQgMCBSIDEyNiAwIFIgMTI4IDAgUiAxMzAgMCBSIDEzMiAw IFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEyNCAwIG9iag0KPDwvUCAxMjMgMCBSL1MvTEkvVHlw ZS9TdHJ1Y3RFbGVtL0tbIDEyNSAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEyNSAwIG9iag0K PDwvUCAxMjQgMCBSL1MvTEJvZHkvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQyXSAvUGcgMyAwIFI+Pg0K ZW5kb2JqDQoxMjYgMCBvYmoNCjw8L1AgMTIzIDAgUi9TL0xJL1R5cGUvU3RydWN0RWxlbS9LWyAx MjcgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQoxMjcgMCBvYmoNCjw8L1AgMTI2IDAgUi9TL0xC b2R5L1R5cGUvU3RydWN0RWxlbS9LWyA0M10gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTI4IDAgb2Jq DQo8PC9QIDEyMyAwIFIvUy9MSS9UeXBlL1N0cnVjdEVsZW0vS1sgMTI5IDAgUl0gL1BnIDMgMCBS Pj4NCmVuZG9iag0KMTI5IDAgb2JqDQo8PC9QIDEyOCAwIFIvUy9MQm9keS9UeXBlL1N0cnVjdEVs ZW0vS1sgNDRdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEzMCAwIG9iag0KPDwvUCAxMjMgMCBSL1Mv TEkvVHlwZS9TdHJ1Y3RFbGVtL0tbIDEzMSAwIFJdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEzMSAw IG9iag0KPDwvUCAxMzAgMCBSL1MvTEJvZHkvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQ1XSAvUGcgMyAw IFI+Pg0KZW5kb2JqDQoxMzIgMCBvYmoNCjw8L1AgMTIzIDAgUi9TL0xJL1R5cGUvU3RydWN0RWxl bS9LWyAxMzMgMCBSXSAvUGcgMyAwIFI+Pg0KZW5kb2JqDQoxMzMgMCBvYmoNCjw8L1AgMTMyIDAg Ui9TL0xCb2R5L1R5cGUvU3RydWN0RWxlbS9LWyA0Nl0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTM0 IDAgb2JqDQo8PC9QIDI3IDAgUi9TL1AvVHlwZS9TdHJ1Y3RFbGVtL0tbIDQ3XSAvUGcgMyAwIFI+ Pg0KZW5kb2JqDQoxMzUgMCBvYmoNCjw8L1AgMjcgMCBSL1MvUC9UeXBlL1N0cnVjdEVsZW0vS1sg NDhdIC9QZyAzIDAgUj4+DQplbmRvYmoNCjEzNiAwIG9iag0KPDwvUCAyNyAwIFIvUy9QL1R5cGUv U3RydWN0RWxlbS9LWyA0OV0gL1BnIDMgMCBSPj4NCmVuZG9iag0KMTM3IDAgb2JqDQo8PC9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIyND4+DQpzdHJlYW0NCnicXZDBasMwDIbvfgod20Nx0l1D YGsZ5LBuLNsDOLaSGRbZKM4hbz/ZCx1MYIP8/5/4LX3prh35BPqNg+0xwejJMS5hZYsw4ORJ1RU4 b9PeldvOJiotcL8tCeeOxqCaBvS7iEviDQ6PLgx4VPqVHbKnCQ6fl176fo3xG2ekBJVqW3A4yqAX E29mRtAFO3VOdJ+2kzB/jo8tIpxLX/+GscHhEo1FNjShaiqpFppnqVYhuX/6Tg2j/TKc3U+1uM9V /VDc+3vm8vfuoezKLHnKDkqQHMET3tcUQ8xUPj8JSW8rDQplbmRzdHJlYW0NCmVuZG9iag0KMTM4 IDAgb2JqDQo8PC9NZXRhZGF0YSAxMzkgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzIw MzAvTGVuZ3RoMSAxNTUzNDQ+Pg0Kc3RyZWFtDQp4nOx9CWBURdbuqarbS5ZOOhsJCdCddAghTUjo EAhb0llZQiBAgASBJCwx7GERAR0JqIMEGTPu4AIqKqMz0umgBhCN4riigI4jogMoqKggjCM6suS+ r6rDNuP/Zt485/m/+ftczndO1TlVdWq5des2nYQYEUUDNKorGDN08MuvJh0nXlBOFLtkcEFhkTbM WE3M8RoRPzy4dOSYsrMHf0ksaTPRJwsGjxmbN9+QMZl4QCeiAbHDxpQVzUmZYUT5LNTaZXjZmCH3 VbqLiQbdRBTad+SYNFeHqWMfIWJ/hb2qNH942fXRN51B/Y1I9xlXUFI+5qm54UTDnyMKu3PqnOq6 9INzMogml6L9d6YuXmRf9MkPDxAt201k7lFTd/Wcvg8usRJVJxIZc66uXlhHkRSA+upRn/Xq2Utr nrk3aDvRSrS34GDt9Oppn5Tt3Yb2r5ft1SIjQuvQjPRWpBNr5yxasmtNyBG0hf4PSJk1fcFc7qJE YpFu+PDZ86ZWZy0af5zo9H50r3ZO9ZK6mIGRRbAhTfa51XOmdxl2bAKxqAKikLi6eQsX6Ym0C/FU SXvdgul1vLIqmejqaUQRtSTH3rhn4it2Y0ll6MDT5o5mkvTwkcwiKXc/vSLu7Orzt1rJvAC+Acpf EqQpvq2Qxlvp7OozQVa6aGmnkCkyJzSD6klQD+K4rJRG4zBq96FdDqsQM/lzZCCzYb0BI8y6+qTY SDU8nBk4NwuTwcCFdphS9FZako9qA2TdZSX5dsJ1lhtmtRWxDFM82+Empus6Sj9uGC57SpHGfqyT 9OYX+Anaos0nD/0IwTYa3PHv8okm8H7ENaJh4FVg1wUb9MLLfZHOkW38WP2SDK9iBHxyFDjOMI66 a0eop7EfjZH5ojN1v+g7jpJMa6k7/DrDXirzpEQ6SVtIM2EfBj3979oYR/H/VfuIb6JqZy2NQB0j IUci3jzklyBdhH6mXOx3P3Ian6DhMl/1fSF1ay9bjDhHoZyMIwe2iMvqD/uv2vbTv0Ya6Sf/GT82 rm3VFeUW0gBwn586nsvXyMW8J7C/+MlPfvKTn/zkJz/9BMTu1rf/3DH8s6R99v9PrH7yk5/89HMS I327GWwl/77pJz/5yU9+8pOf/OQnP/nJT37yk5/85Cc/+clPfvKTn/zkJz/5yU9+8pOf/OSn/4nU 9iaR3hnyz5flHf8bn2P/b2O6ksTHlCdqaTik+2LeR5R2uY/8mSmtH13NX9Q/v/xnq1Dm73+2qh+l aB7qZJxKVuMS389SKVs/ClSygEZom6ij2EUhYi2FQB+hfU6RvIyiL9YLm2EpWbXr9FPaNzREnKNI KbXVFCnuQHofddZupHBtEIVfrL8X0l2p8085Nv9d6fKx8tP/HOKbqQu4DlxwWV7O3/gMANvA88GF l+W7/8ZvoJTml2nYvzlsP/1kFJphYozdZVQJoxImk1EqUjdG+ry6UqwxYnQ2ZRFFloVaKCc6pIsy HfDZh1PM8Ji7Og3HJp+5dvjw4ZQZaxw+lmjdvyNk40VN/uzxVVf9mE/XC2Y/+elK+j9YFd3/sYuf /knCLvNzh+AnP/nJT37yk5/89H9F6jwjjzT/6FjDOl1wvFQkjTGHVJkii8+mgaOVy79+UrL8yyV/ CrrUwctGJ/1nDenfRoKEmjyDEIyjtzGG40Gt9FezTmYK0NsogAKBgQqDKAgYTMH6ecyQxBAKAYYq tFKofo7CFIaTFRhBYfpZiqRwYBRFADtQJDBaYQxFATtSDDAWeIbiqCOwE8UCOyvsQp30H8hGnYF2 hfHUBZhANqCD7PpfKZHigV0pAZhEDmA34PeUTInA7pQETKFuQCclA3tQd/07SqUUYE9yAtMUplMP /TT1olSgi3oCMygN2JvS9W8pk3oB+5AL2FdhFmUA+1EmsD/10f9CAxQOpL7AQZQFzFaYQ/31b8hN A4C5CvNoIDCfBul/pgLKBhZSDrCI3MDBlKufoiEKh1I+cBgVAIupEDhcYQkV6SdpBA0GjqSh+tdU CjxJo2gY9NFUDByjsIxKgGNpBHAcjdRP0HiF5VQKrKBRwAk0BngV8DhNpDLgJBoLnKywksbrX1EV lQOrqQI4ReFUmgCcRhP1L2k6TQLWKLyaJgNrqRI4A/gFzaRq4CyaApxNU4FzgMdoLk0DzqMaYB1d rX9O84HHaAHVQl9IM4CLFF5Ds/TPaDHNhn4tzYG+ROFSmgtcRnXA62i+/ildr/AXtAB4Ay0ELqdF wHq6Rj9KK2gxcCVdC7xR4U20BHgzLdOP0C/pOuAqhbfQ9cDV9Av9E2qgG4BraDnwVqoHrqUV+sf0 K4W30UpgI90E/DXdrB+m2xXeQb/UD9GdtAr6XXQL8G5ajZx7qAF4L60BrlO4ntbqB+k++hX0++k2 6A8ofJAagRvo18CNdLv+J3qI7gA+THcCH6G7gJsUPkr36B/RY3Qv8HFaB9ys8De0HvgE3ad/SE/S A8DfKvwdPagfoKdoA3CLQg89pH9ATfQwdC89Ar1Z4VbaBHyaHgM+Q48DnwXupxbaDNxGvwFuV7iD ntTfp+fot8Cd9Dvg8wpfoKeAreQBvkhN+h/pJYW7yAt8mZqBvwe+R6/Q08BX6Rnga/Qs8HWFb1CL /gd6k7YDd9MO4FsK36bn9HdpD+0E7qXngfvoBf0deodaob9LL0L/g8L36CUgWgO+T78H7gfuow/o FeABehX4Ib0G/Ihe1/fSn+gN4EF6E3hI4WHaDfyY3tb30Ce0B3hE4VHaC/yU9gE/o3f0t+lzehd4 jP4A/ILeA34JfIu+oj8Cj9N+4An6APi1wpN0QN9Np+hD4J/pI+A39Cf9TfoLHYT+LR2Cflrhd/Qx 8Hv6BPhXOqK/QT8oPENHgWfpU+A5+gx4nj7XX6c2OgbU6Qugf0/37+n+Pf0/b0+/37+n+/f0//g9 vcd/4J5+0r+n+/d0/zn9v+Ge/v7PuKfLz2R83Kn9Q7lvkZKfQ50hjeTvSXdhj9Wwdydg13Rhx+uP 3WowdqCR2D0m4M6fgXt0Me64jawX/8DotkfYCxKiznL5+8VRMhm7aSb2w1zsa0OxS41SZabifl/w d2XkLyU/8g+uqfqmNnbOc/jBw9cefMzw/L/2dQVmvPQJJOPc9yvPr3DAkGgGpQYFSwwLj4iMIjyd ME7tX25LpKRuyd1T8OSgtPReLuqd2aev/D362OQVFVDR4CFDhxUPJxpZOmr0GBo7bnx5RfvvFf8p SShsupjeAX6h9Udd35PQ/vWT/9jZdeeNLXPnZA8aOKB/v6y+mb0zXL3S03qm9nCmdE/ultQ10ZEQ b7d16dwpLrZjTHSHqMiI8DBraIglOCgwwGwyGjTBGfUodBRV2T1JVR4tyTFkSKpMO6qRUX1ZRpXH jqyiK3089irlZr/S0w3Pmr/xdPs83Rc9mdU+kAam9rAXOuyetwoc9hY2YVQ59LUFjgq754TSS5Te qHQL9Ph4FLAXxtQW2D2syl7oKVpc21BYVYDqmoIC8x350wNTe1BTYBDUIGieaEddE4vOZkrh0YX9 mziZLQjKE+soKPR0dBTICDyia2H1NE/pqPLCgrj4+IrUHh6WP9UxxUOOPE+oU7lQvmrGY8z3mFQz 9hmyN7TG3tSjteHWFitNqXIGT3NMq55Y7hHVFbKNMCfaLfBELzsacymJysPzy1ddbo0TDYUxM+wy 2dCwyu7ZOKr8cmu8xIoK1IGyvGtRVUMRmr4Vg1g8xo7W+M0V5R52M5q0y57IXvn6N91RKHOqZto9 AY48R23DzCpMTWyDh0YvjffGxrq34YkcW2hvKCt3xHty4hwV1QWdmiKpYfTS5o5ue8crLak9mqxh voFtCgltV4ItlyvTL9qUptylVjz64sgyGZFjKBaExz7VjkjKHehTloTpWdQwNQtuoAqGUp5pmJEZ noD8qgZrf5kvy3sMXa0Oe8NpwgpwnDh+ZU51e46xq/U0SVWuk4tLDfYLusfp9KSkyCViysecIsZs lc5M7bG4hW9w1FntEBg+KsXYVlf0T8Pwx8fLCV7T4qYpSHjqR5X70naaEucld5qzwsOrpKX1giVq rLTUX7BcLF7lwErequ75KI856eK/UGuHiMLa/h7W4X9jnu6zF49xFI+aUG4vbKhqH9visitSPnvW RVu75onILxdxvF3jcUJZsSgnXnSWifJgj9YV/4xqUU9rMZmxKlUOsxd5rFVDfFgRGB//TxZq0U/J UkpcKtYepqe/88r0gCvSV4QX3CAQsJbEi8smNDQEXmErwg7U0FDksBc1VDVUt+j1Uxx2q6Nhm+gm ujXUFVZdmNEWffuaOE/RrRXoRC3rj9XKKa/JwW4Z1eRmt4yZUL7Nil3/lrJyL2c8vyqvoikRtvJt dmy6KpfLXJkpE3aZoGKGhe7lZuUft81NVK+smspQ6aktjFSe+UIeo6kt3Jdn9TWUpBpy40k9tUXz WdwXvDXkmX159T7v5HZvMyxWadlO2NRJGX0kd438svLL14O6ySpSKTeYyrQovh5vmzYtClekFoH3 N5sW0WzsbLO3aMHNwSEuKb0R0a4WLag52W4LzbVq4VQP5hQKzAFXgoVCRm4t3Lskw90CscAn5vrE TJ8oy3A/B8dheH1s1cKbo2NcMrs5MNhVL6U5QKbDvBMy3LkBWhhe2aRfGF7mlPSWZihziawlDA9w ldtcUOgrlefLzm537p9hy01E2g52g+vAW8CnwEZEH0Zp4EawDtZUSvotB98G3gg+LH1VbeaM0Nw4 zQqLVfXdipGyoowVfa/S5F/B8SgM1cwYFTONBG/QTKRpgV6abduGSkRzoYpUNDt7KulN7u5SBm9s J9dOPJHX4fXdhgzm7RCnLOTNy2tX+mT5lOaUVNeh3ECN6CSYa6QxHFBUqebknq5TLyDNRBuFMiZz xblmayRaE+ebQyNc7lyr+IFKwZw8oolawZzmidO0HMzhvsWb2ks2JLY0B4a4rPA/SXZwPVjQRiBT aTdY+p9sjuggq//cGxqmyh3ypvf2Kc3WGFdpbqT4CPG8Lt4hB9nEJ5BdIF+FxMITr4jXyKLi3NQc anXVo71H4P6IWIqTmk08KpbhvGYTm8UNFKfcPvCG+Nr5wJuc4soNFI+L65XLQjGfekPOFrO8Lpt9 h9gk16M43hwQJOM77rVGuXaKL8QsioTXUXhF20J3irmUBpY9aWkOsLgac4NFC7rZgmGxIUZGGxS6 xTteVIT2fiPqqQNse8QKioJ8Qqz0Rtlad4jvldt3sha09zBWjBTNlhBXa26AeFiuEPENRvwb1dq3 zUlZLspNErdSOphjUI9AOyL/KJL4GtrXmKavMTVfY2q+RhRfyy83ixOwnIBPmjhIdeJDagRvgK6h yqVejOA2pSQmu7aJX4jrMRLWHRg7htwbmgNCZGTXe8MjlNv18gbP2Snep5FgjuD3yzty3g7xK9WV xuaYOFngD96AYAzddb65QMFlcg52inqxUo3ECjUCnueRxPoXN6rCenNwmGs5Zr8MyXnA28B7wSfB GtzK0IcyqgQLuJc2h4S6QneICarwUG9Ihm2nGIKuD1GjNcQblaBiHtyuaKHeuC6u56VCqdjzXFqI ZvSm2UbtEMVYPyPFCO80G2If5UW9suCI5qz+rvQdYoQaixFem8OX7Y3oqJQib4BvXeU3B4bJSAqU o9NrDlHZzvZbUqQ0R0a7bFin/VVvM9RbVF9MX19MTV/cJxlqMlzN1nCs/mnCpXrkoirwRrAHrGGO XXB3YY5ddFjlhIo+6G4f0sECc9uHToGx1YhelAO+DfwC+DDYoHKrwBz56WihCtgI5qgxDWkr0A2u AteDN4JbwafAJtojUtFOKrzTgfVgD/gQWMNc9UAc8s9zhQs7nTcT2Wg5X+fuz5bTcracLxfLteWG 5dblYWZ3ZtceLvdMCT0lJAP6VgXUBdQHiPQAd0BpgLAG2AN4i97qNfXPgHCHG/tnHCj5suRMiQjv 22hsNPE9ucEsjA6BT4IF7WFWpKxIWd2rxJ7sQ9kns8WekkMlJ0vEnoOHDp48KPakHko9mSrcJXH9 XX0r2Ty2nN3GNBtLYzlsJNMqxTyxXNwmNJtIEzlYC1pVUF1QfZBID3IHlQYJa5A9iDcGbQzyBLUG 7Q0yeIytxr3Gw8ZTRkOpscpYZ6w3Nho3Go02U5opx+Q2aqdy8/mHGNSNQA+YUz2wUWlWZWkF7lXp RpWuAtaptBtYqjQHMF1qYAfqOgC/emAjWPrJtAOYLtNgB3b3D5BXB2wEc/6Bu1NCeqI7kVsT7Ymc EtmpRLY38XAi9yS2JvLW3P58v4pyP6Lcr6Lcj5L7Vdv7US80sAPRvq/83off+8rvffhJ7cfyqoB1 SnMDS5XmAKZLjb/vdfQNzY3m96HGSuAG8CGwoDRgDnieStmkB78P6Obrm7v1wAOfr/cmYY+ESPCJ Lj7RSYnmjrGuytxQHFA2gA+BBcmUDZwjU3orX+ctkL7rvIN8on/Godx+eIrKUNbRFjCnkcANSksD 5ihti/IJvZj2AA8rrQ648WK5SqVJPxv4QnmNr8e1DlooX4bcZe4gTh064MQeHmYOb+HbvTPCbS18 qzfZCtHsE14pciO4wPhb2NcKn1K4QeGdCscrDHUHOSw/OCy/d1ged1hyA/kwSkT2KYVfKJzpDkm0 HEu0vJJoeSTR8nCiZQc7QgkwxLtjEyyfJlj+lGB5NsHyRILljgTLxATLqATL8ARZVTLZycI7S2ST FXZyR9st5+yWj+2WN+2W1+yWh+yWCrulvx3u7Bs8Uy3sfoX3KMx8trfF1tvSubdlO8fYsKu8oRSw g3N2FVlEoDcl29YiApTg8d6SrhCdvCW5EHHektEQsd6SBRAR3pI7bLkBPJQ14cBi4yGsySxlsDdl BcxBPmH2pkyGMHhT+tlaWJs3xQFx1lvTGeKMt6YLxHfemt4Qp6V4jv2FanAEtrE/e2seRPXsS0qW 1bLPKYk/CdniLcmB97O+1tlWymZdkY1XOBkF+603BcGxzd6UZIjHvSmJEI/5xCPeFBvEQ96anhAP emvugHjAW3MUYr03ebasbx0lq3rupSQlF3pL4mCe7y2RNdR5S9Ig5nlLMiFmebPfgpjhzT4qi17N mhhWN6uhFBVptbcmBebK9o5MomRlnkiZqubB3hI5JEWyklwLK2zvSAHLl+c+lseaVC1ub0o63LK9 KUkQg3wjN9Bb44TI8iZjjFlfb/KDGLk+7Q10l/PzHEtEGLIihzflSTjZvDXdIbp4awoh4mRJBBXR 3mo4Zaugwrwp0svqTbHbnmdBVKNqDKQktv4Z23nUeza7hY3z2s64W8zMa/s+GeIZ2/GSKbavSlpw 6rV9idv4yWdsh+B6MBuqO8j2UcpR24c1CbY3UuDhjrO9ntLTtitpqa0leYetuaSLrQmBeWqm2LbU qBqeSkIxr21zcgtnKL2xZrjt3hSn7Z6kFhnD7XBeJdtARTenLLWtTFphuwZLYVHJatvClM62uuTJ tpnJsqFo24yU0bZadORqlJlec7WtOuUOW1Wminhyylu2MZmqD8U1qkdDs5VhSM1oWxEigCFHGhDB AKxLF4r2zNwhxwinlfzmt2xj+z7H8SRm9eAF7p6mnaYbTFNMZaY8PHO6mbqa4k1dTJHmcLPVHGIO NgeazWajWTNzM971eGSLftjtlB/fRhqtUhg1iZrSrVyi/KRXvgkyM8fLlidCFPPiMXmevs7iFpM+ 2pPlLPaYS68qb2LsVxWs2NM6lYqn2D3fjXG0sEC8cRscecwTXkzFZXkxcPbwW/DuWlbewnRZ4uY4 +THWNmKsx81r46QsunltRQV1WJwTkxOeHdavqOBHoKodCwuclyjG6bwi1dlzd/GYcs8TnSs8Lqno nSuKPd3lR13b+Gw+s7BgG58lRUX5NlbLZxeOlvmstqACbgOUG2XzWXCjEingxidStnRD/sTL3FgT sguasrN9TiNZk3TCTTNSOU3wOeVf7iTWsHzllC/WKKcHfQ2mIA406JYCbobZlKIaTDHMVm4x0q0p KQk11SRJlyZXEhyaklzKPOqSOdln/p3P/DtpbmHskj0zyRdtMiWpFpJ4MnycPyNNz/sXCrHmQYvn lsuPKKschdPBVZ41i2tjPPVT7PamuYvbP7tMqpoytVbK6umexY7pBZ65jgJ706DyHzGXS/MgR0ET lReWlTeVu6cXeAe5BxU6qgsqmkesyJp/RVurL7aVteJHKlshK8uSbY2Y/yPm+dI8QrY1X7Y1X7Y1 wj1CtVU8Oo8Vl5Y3mSmvIn+iTzbzoEDcLVVx8RV5Hax12erWGRAfc0Pcdo3YZgpyVniCHXkeC1ia UnNTc6UJt7Q0hciPodtNMTcMiI/bzja3m6zIDnPk0aKYwhkF+LcQtGjRNSCM8cKFvrGO8RkWOQuV HQ6LoC1SBE/okheq3Hb7IrrmEjmdPl9a6MwvbyopKYyZURCHg3yzPHs7KxaS0+lr0OkktIleq8N+ B3XYDzJ2yHiv5NOS0yWiVZ3y94IPq1N+K074e8GHccrvIlqz92YfzhatJXtLDsP34N6Dhw+K1tS9 qYdTRd/2CGRTFQwRXrqucS68RmY7meqt6rcMBEFDkb2+MAwLlWGRGhiQL18VdaIi58XizkvKQp/x GlXEl7vw0hqGQVa/6Brn35MvF5Vj7J1Ow6/IZhiuuJO4k+KI9I/BR8HH2obp5wyzyNE2Uz8sIrBl J/q4nbrSTTjsHaO76QWaRG/i7FjIelI5aSyGOmJz70fFGMJoMuARm4yTYzGVUhT2+0+ZhbZQL/qS FdEKPKBH0v04G47Ay3ou/Zo2ssH6F7SC3mUz6EmU3szc1I2GsyH6IRpFpfqzaINoAN1D61kIHljD WSBz6AdRw0JaRdvpj6TTBLrXsBG1lNJomqs/SxNpH5vArtI70VCaSzfQvfQQ7aSj7BbWqhn0Ksqk KbSAmVgESxYr9c2UZdgf8LT+sr6XrPB/CLUe506tSP+a3HRMY3otlkgEZeCaSw/TM/QRi2GZIp9C cASdiLG4nraIZMQ4hFajb9vZdWyLCNE3oTd9aSotx7Jawlp5vGG/4ZS+jMLRv96ItIE20Yu0i75C bUWsTMxpy9FH4DlpJicVoqWb6Jf0FEbuJVwvs1AWz4ai5hfZQfaxmCs+Q82P0wn6jv7KktkMdgPP 4SsNrvMr9KcpCT10o46hNJ5m029ZEnOzq1D2fn4tvwGvzM+Ij7Rk7aSepe8iI+HVnFbSE+jX2/Qu vY/5KmIl7I/8BtFs+KV+HeJNo1r04iZ6lLbRaWZgASyYRTI7y2B90bPrWCv7mHfmDl4upogthlv1 pfpaisdamUTTUXIm3Ug307Mk/6/+KzrBYlEyDSVzWClbi1fll/keMV5MFHdrbu1u7UntJe2cIczw Utu+tsMYdVlPOpXgmkQ1tAxj3YJrFx1ggsWxLqhpEBuGmipZDbueNbK72CPsMfYMe5XtZV+wk+wH HsNv5XfyHfz3fA/fKzqLFFEgNojdWrx2QDtrqj7fue2FtpN6kO7UM/RG/X79Q/2EmoVOWPE5lI/V NYvq0ftGuosewJhvpbfoPay7Q+o6SqcwB2eZEaupIyJKYA7WjfVA78azcnYta2B3sE3sFfYxO8rO ceLBPAFXCu/Dh/GJfCU/zs+JQOEQuWKJuEe8I85oSw0uXE8anjacMh41dTXvPnff+YNt1Daj7e62 +/RMrEUjVl4E7rnelIc1NwyzPI3m41pAi+lajNEyjPj9WDlbyEs76DXajbHfQx/SRypeeX2BmfiW zlMb45hPAzPj8sWejpnJx2qpYtMxt77rOraSrWb34rqPPcgewvjuY++wd9khdoSdln84nafyXD4Y PSrlV/FJuCr5VL6Cr+Fbcb3N/8g/5J/wM8IqwoRNdBOF4mpxi2gQHrFV/EG8pyVpudoQbZb2qrYP PR9iGGqoNEw1rDE8ZHjE8JLhDcNRg268w/iwscV4zBRo6mMqxdF0tek3ph2mj0y6uRvWUwmiv/xn 4O9gV2lpvJHpvAX9fp4vEm/yO9mTl/+PtaEBEUzDS3WL2MkfuL5RfCJ+y1eq39IjaRB2sd30HO02 vKtFGY7RqzyWvsZ+eKeo5s/jdTuG9REDtJu13dh1liLOR/ghbuJb4CG/h1VJY1lH+kYbRycx/nsM DRjTIn6QPclfwevzJNpPm/gOwss9TWd9Ed00eprO0K/ZNmFnz2DdLae9dJwOX4pWSzufx3OMMXyx sT9maBsbpb/Ku+tf4a7/mN1MH4ozWPvj2AiWRo/REcz6e6w3s2ltWhztw87Xhe7Dqv2cmnEPvqEl 4g46TdtEb5qgHcacp51/va3AsEjcyL7juZjOaLVzj5S7Mfbge7FXyX00hLZgJWAXUXf0V/QWS8Ao vms8QOvpNtouoqireJTXc128ptnpdjoshqPVX2B/6sR6o6Y5NAP9sOuftW1CDTMpi7LYFDaBCmAZ Ql30OYj8MexFbn2ivs5QYXDS22w4i6IXsHvFYBTvNgS0nYDnVtyHH9IQtoaa26ZRK54rMawrc2E1 nTAsNjQanjBsNTxveMvYi5bgrr0Ps/gJfYunhp1NxVh8Sd9jrefh7umB+ycXUQzBM2w2rxA7KZ/F Uh32wGTs23kYgwmYyYWoZSXdivvpUTxD3qZTzIq33udpP+6caNznU9G+GfUU01jM+kJ6DLvjjawZ OdOoC6VgnM6wEJbFF6E9uc/ejX22FTF9RJ9h59BVXD3YALwqj0Nd38t7GS30oVK8E5D+DPXDk7JA 7KZPKRFP1zzco5tQrgprI4Q6Uz/DEcapR9sIPYvPEDtZBzwNQ7CqyvBkH8TmI4pQ9OM8RbGRlNk2 GLU9ib2s1PAonr5OPBmieJQ23jAWcR/Ak+xtWqCXs/WmAvG+OKXV4ZneCTPcySC/7mKivK2c7TKa WoTZHUEGbZegQJO2i1FHs9Gwi4vnWC4FYCLGUYzT+t3A8wNHWL8dWHJ+IOVAt54D9EqPD4sP6wpg nTQ6Zxet59wGOkt2rVV+G2iL/imT5w8rdt4bdnKP/OIpv4O68NubOwcwahEd3bFhQ6ODGrts7MK7 REfHBkcOjSV3R1tveokx9XEudBYcGmuL5bE9QoNtwTy4hUW4A14wMmPHzvv3xDgR06SSE5OOTgrv 50w74bSeGGEtnF7w2STKKTn/WU6vdFZUUFQwtIA5krp1S8rs3SfD1SEq0mQyCimNjgSZx2b3MHXr nTZx2JBKV2anhPzKyvz8ysls24KHD7w8tmRy5dDhew8sattXWaAsVeoDvX1iO3oWjFVX6Y7j5vDI 3twc17k3sUDNEhIdRsxkDOkQwkNa2DJ3x8hIEwtbNS96QzSPjo0LXGXXmNYx9lL4I6zfTSo5j3G1 npgf1q8fCwvv108ywsfh0yEuBX5lYlKv2sjxg4pGxLB61/SYiuzBxbF8H1tR3C97/FWZqZPbVrD6 8vT+5ZN7OWrl+/rothp+O6IOp1J38qqQZ0N5X+1efmfAZv5ogIG9RCL4JUuEJTgYvumRoSb5+bQw tfC73AFuK7OOi5h3t1wIk05Mwmqw4qKcEzkneqXTJDaJRRlNuMKs4dEdoqOSKMxK/PbaXgVJ6eOL e0/6c1sTG2GY1bMgd8LaLW2vtO1va5lelOkaxf6Cu8TN5NO5I2KrULGNdif00VYZbgltCdXu5usC HuO/CdAQXQSiw6q1muztUYWNlFFFEmPBwZb0iNGrEd23KjAV5GXRRWT26YsrzMq7JXXL7CCj61jb K7+bLzg2sq2praZnYe6EWz2sP85eg1VwbZa259pebJPHZpqgf84ex54XRAlbaagxSMhVGGQPSA/g AR2D562WE3kOE0myRXb50qKi6imFhf+Ljy8Bk6I61z7nVFd1dfVS1dVb9d5d1dVbzUwP0z1LM8N0 yWZARgY3hNCyqDACysxEGYEQwAVEnyiugGhEo7heQdkaNIEYNW5JMCaR5DeRJFyTeDNqnowkf2B6 /nOqewy59z7/zNNn6T5dM/Ut7/d+3zndixfDgtFNm7bEqJ+M/Q6V8N1SoE0P4xsoIcqNkPG5TmSl 9oIADfeiBtOr08gtEfMgl+4qdW2hm7T1wuv4b2CQR6XqlI3wGL3in6vpO4m/zRw7TR2k+wgSwJm6 3xJkooxqyfjMUtAT86hSxmJm4RAbrkDuZZFO4W4/Yxd9FYrTVaAnkgWga024ybfhpnNSQcdIsxv/ j4FGkZejmOWQlY577NCuuzwFu7/hy7+SGz+jDWIPnHKl7pP1RKogk4vI5CIyucgqGQ6QrGUeXmgM eoZJcceHczy82EdyPbze6PFbSH8Qv2uRr/6uuhanrNGXwGwsHo0jhncIDsQkFFVBjNXG2Sw21mZi PF63FzF+KSAFJYpBmEyaIMVktYyGmIhTXgKSZtyEXL4lME3jJu4IL4GKLbUESF480iAeGdUD0mTr P5vAAByAbrMDYXVi28EqbW8j3ufz0gKZK7KZwVbv83rzLdjEqINF+Rv3XbHkO5Ma4lp3/sSNq3/c PKX6nolL+js0vxpw8x1NLf4sg/a8u2/lnXOuKU8d2Pnd3xzZ+d3H73jlI3hN510TYpLy0ujn1VNL LmyOddxEbGULBuursVZ94NZXgQP+B2wFLHzqkLzQvMqM4AV24xkzJEf2vfApwMO/4+DQCrwI6Q6e BTRrtuEnozi6VSjsyA5HL7+K38tTAg95v+T4PgKARW8CCfngxwbSnyagVO7qEUbLBOtLYvHL4XPw Sw2WNWx4Tje+17wn3ppvaWtrdRaSRAYpFe3yTu+JjrYl5s4MiBNi+Rki/Bvdd/b59dMaVDU9fSM6 dlUuHkucJnfUgu/oEXxHIfAnPXEHehG9QFEp24MU4qycFQI6KO72HvAibwjh/4mzsqEKXHRIzPn2 YfisQPllKLLEXKz2AluhEgccNLRhhxzRg4AWaER/JH7Ah+CxEAwFIjyExyCE/vBRzN23AWKup8sD GB8GekZGy6dBqTRMigq6i9W99hKr+xy48fO4sRcN+8NCmLKgbq94hWGneJHRBwWjfznkLBlrTzsN 2CbwXXYWxSKeCm9jkZVBOR5vBWJrwZCVYUAEvxkYxzJsz1O9534PVz16y1UPX662fbRt2XOLZl5b fQGqKy/IygkvPAibtl1318P245VFT8+4feuR6kFRm0bkOA37+36c98uwV29yMNDC+bk0SFMmN+cJ ekJUBzODOUxTVhrioBMyhQXchk0wYKKwuBboApDdAMjYtyGQBcO9LQdEnP2bKvDzQ2KMOkYhvFDe D4EpUIEP6xzvirqQ6yObHVXQW/vh+yx4BTE4cQ/DL/WAzvayu1mKDSSE9++RoUwwQvYrNYwYwRhx GgPAsHBaGMFiHy4PYxZBRKu7KR0LkNKxNCkif4powpBndcAQvQmLGq8w1UVuqqvA6PFS0r/sthlv 0eYNl8mb9IhMLiqTi8rkojK5qKzjZbIuWmtrtXl1OAVO0Ue05sMBFwyU4WB5AMapuNlEzrUyJkUe Zw44tmE/b2stJOKyGVPAddeOfpqH847uvLtafXjPvO4LtFTv4kkN0dQl36juro4E2+hZ1eoW+2O3 /nD955u6Gzq0ybGpWcF282X7PiI19BLW32EDr9PguB7kqABOZakdlmcsFctbNtNUlvYpNOuLpuAr 8EGcMrDw4f2pFIhi4NZtPA3svveBX/AjP8Fl0RXIKh9Z34dE7tCfGZd7Ty1+1I1dLOaGhWFsoDUz NYC1JZC0iHHVnnSqwUAoEA5QjJqMOZQlICL4l8CkBY9kW3QJDIi4SXAYKMFXQIkfmzaRGOtr7Ubt TD3sEWGJHjcyQSyscZz0CER6pT1/3BLsntv88I9X/WTV0M+/9ePqcpjhslLOn24JpSZrM1KhUPKB X98d8//2B5s/XndHtfrUL6s3D6M7+i8/9OjcjFfr3FP9r+um1vjlH+E56jUclX2g5QjwY8LoF10F ZgYw22aIVp6aYWk45oEev/QV1RoZHWctGPHPi9Ou82P2FUagXrx4aj12U68trsXuxaOD/4riiHwf LL0P6y+OmXyzfr8sWMXSUmG1MKRsETYrz9kPC+aH7PvtCCYUBGRFiXMOa5jzxaWwz2qBFsSGLV6n J+zFMgWy9xsKL8QUEBfiKK6geKNTcDudgoKUOEo7eLfDwaPVDujg1jph3CnwJq8SdzqwhH0KLyfS xhdfnBZ0gadwMOI4C8t7ofcovAUosElXYpy/Odmf3JjcnTyRPJVkVCEZS+rJXvzMtuS+pPme67GA BoTyiD/QM4q5k1QyiFSpK0CiwGiXs/iVj2CmXS5ucTRpLHYd3EtkUH5dI+BXLEpAGIbC8VpbPn9i Frq6zF1ddb6owTi2CDdhi/FWDIIwD721CQmkhtGkKIq6rBovhpqCy6uTZlw1Df6nC/55eqPcPdof nB3zMii0/J0T8JbbJmvFoMCqqvXqXaaJZ5/5TiZKq6pXiIguy+S/wQ+qjRgr54z9jp6LGVcCho8A 79jG/RauEKrUeqbe23Gvz8MDW8ASbHP1BDZ77wrcE9waYlc4V4hrnGvErc6nmWfsT/l+5Hs3yDFe kJzivSC00Xu7b3PwttBh0ysRLpfsiw4xq+2rg5tdR3lzu8MpJsJgPgrjhAa6MdmbH3/WKTro5WHK sdxjgQtzTugM9CdhUlRvOAJbjBCFuZSF56Ic4nr8/pGeP5eD+2ujYcyiyjhXOG0YMRb3X0awaIdH hgEJNBdduualFhZ7dMIbYuy2pE9lLWYLYoJJu5dTARPCjVVyqMASoFVY8+As8V9YHgAY8wz641RI RGeIckQCdu0e4tQJ1FoQE/kWA//a6bmphi92bPj5hNKC1x/Z+IvVg39/6lfVvYffhfNeu+exBf5Y zkyvqGYrr9+3evuRQ9Vf7OzfetPQihfh9MprcMHx7kQuT7wniL1nAEevIGarVn1BYCMWvEIagTQa aZa5+qRl6sOZSppe5rwOT7Y7d3ifdDFXO8yxMJBlNhZ2yEqoiXcguTUYBKzYGOLD0TAKd7PNZthr hub1DZMO1nx/AOeuhNVg4QogKSRRsge4BXezm3K3YZFiIR9K9jS7oTEbnmdkY6WuYU2rCfYqItiZ iiYERJfThZh0KpPKpijmXzPEeD0+j+Txe0xMQtWEpAqzpFECuEm5QqTR8HOa6pFVoAld55PNGoiS aZ4wq/Y6tVJa41jmGEodyMwoFCZfPoNpOg32GWzsLPEW75RiI1r4twcOvrLgvmN3Trp1vuAK5p++ 8uZLLlj6NVWNea6jvtlXSKmT51QrP73nr48uDNhMY2d/e1mS4wcfxvkX/cjahij2kAwApn9ifUyA F+vDXpPfgmL55nx/flv+Gd+H7g99n/j+7rOs4W70fLNpK3Wfm97K7aB2cPd7nqGe4ZiYe5pHz/fm 11A0R3EcypNQ+4DpEcuTphcte9y0DQLzHJvtXTZsjsXCkixrcyZM+F1DWGPmQPguHWbisXBGViAD bGY78Age5PFqbo+X8pl93v1ikzQhnYFNNpuUQRLLmHnzbDMq4eYe817zT80fmxmesGFzS36vdkxD Oa2kzdYWaqu0Ddo92mMaq90qePu927yUN6DnYR7w9qgd2bvjMX9L3TwM46g7V3mAMLiBwRyOFaVa xBSGh7vqCIi5nUhonoYd7y9AGK1341NKoOsgpw2U8Q/OIJxEoXmn0oSUGnsmU6qGdIaijQiJVU18 D49QU3DTjUIyaetZuthVmDjn+//Zok46u7KxMxFwWGkumJzcaFqVDF+3qONhU3X05BPfGZ144wP5 6i39LbF9B6pzVI9DlpZS31zgUbDRVVfdvzFCzk43Yf3uwfptgHG9x2yycA2UbJ1ppRma4bAzUElT kktak7bZ1HRutnUpt5rbzDnWZrY1HTQd5N40vcl9YvqEO0Of4ThHLOyWlXAs7JHl5JyGhgpK68tT 4STPQpYo2RJmcUJinoPQu0zYHImFE7LCms1JZJttR7Nh8pgK1cC+JtgEoJ13RB3I0R3mQRRjQnck EvY3uj0N6QRKw7TNbk+4HeEieUIFaTWBPGxj06sQ4ZA7CZoxVmpYQ11EP10jWD/FXNewMYGGRoXh MoleXTW94vknwifGorquviz/t574OsHCmsoMnREfPC/laT/fM8fVlU/NH5xtUxTXsytSPuyMo501 VRHHNN2ccXzj+q4nsKI+aNt4/ejcH6yrLibuOK4lMq6u23pbkMc6unTsFJOgV4I8XKl7OYFOUKoj c3P0juhtidvUb2fuyHJKPVbZ/lvsypLYNQUP+sx91iHrUOII9X1ThTmcOJw8nOWmKtMzenZLZnOW 3pncnn2a+a75Gesb6rsZ80yHREhyvwQjb4WlBTJJaHQ3fmaDDzrfCvtkJX9e+JLB/OZntUgUClG7 T5JkulWj7K2yBTgFJ3J2w0iglbzfYhMKrWLaX2h9FV6KdXUDPEV0dfFIz5QrD/GWqAVZCN6+ZDEC mnamq6deriHKEYtFiB9AGI9tJPGsJZ+AAPE0AsQtsSzDW7H41VQCg7BZtSkWFTjiwmQYi/ICk8Uz LmVXAR+zTwZsxoh3GG4JqTGinoG3AwbgEnUryQQOemg85o1rGMc+HAidJAcgqm4VAIHjWgy8XZ1S HXlsxzuXLfjxtycsa/NOm6Cg+y/qFCy3VP+4/QdjP2yfDnHIu3ZOwxtiqNmNA6L8+nvPV3/y+A+r v77T44aB3lxSVelowjWz+snEzuueX3Hn87AF7hHYizJFUMNj9BnZ2QV36o1xvT1U4mJhJMuBWFiU 5WAsDGXFGgs7ZUV0IgTZAB+MBlGw28oRFUjTldIpDjZzOtfPHedMC3GDOH8sTl4MBsOFU3HYHz8e R81xPb4wvjG+D0+YSasxGGLk00i8HNQMUDQKT0ROhDOr/9MLPITbEykRL0GfnW/86A0y5q3YKdR/ M/ja+NxteIzvNImZgB3fqQru0duWwCG4TulPmbYp2xJ7EtS/bnqWXLtdrCkqqCQAUAW1X92o7lZp tQKP6EIsnkZYFpBFrPoz8CisoL26919i8SebU3pqd4qadCW5yzrmj4yMYgzBwX60a6TcRYqvvqJx swZNpf5/t+szoBybgj1/dtZ5d/1Bp3HXkuJfNLBy23U5+FE18b/c/e6+osMy68ndNV2b+7AE2uBs fTBC8ghrBFoi6yKouWNaW2/H0+AtQKuhNjgEhkJD4c1gS2hLeGf4mfCn4X+Gbf0dpzpQVIy6om4h Iag0L/Iu3g0SQLW0MecbTdPEcFKuSzE6MazKSi4WbpUxptyhTwHhUAwCkA4F3aFQELS1AdAYjrjD 4QiAbeEQFYUB0NaKIEqq4ZDoZAFo7wgKARjo5n5q/diKrIEOw/dDkYLxD3UQRLJ4vIWOSDSdayKv OclrTaea0PGmE02oyd/eUYGX7Y9jq6vAhtsJQJQNo8OArQ1qBLKxgvwEsiVsheSHtCQG41DMbmnS aJyC4F4yBuOnvQiGlwcJpQUDGoT/bqDnwzhUoNNN3Jk85207X8vUCdiP0g1dCT9v9U4tNox21caj /5BGv6Dtc8vVZkfjxWkrwi9qKAt/Qn0LazUuXXvulvPAffisZnrv3LRrfC0lVYXRQs76dWr+snxK Jf4dxhnJdqzzOBx4WRSxX/7jZXuRdPqQrSiEQrwQCod5+8Qwa3i7T5bRxLBZVpyxsHdWPU/EMTgu hHyQD4e7AXTjy4aDMnDyDgjDvjiLgy5APi/LWyDJIe1woR3a1/cqUBGc6RAIwt4gBMFV2D3Wy4br CyMD5UGigB4SMQdruz3E/wluirWdCYP8kPxvi2n96wA/KdVyPSL6LULX+te3CK9DogVS5gVj+3TN 1Qp4gW8Hg7H++MbYxvi9YBu/LbYtfgAciNtNMVM8a0pZZVc2wAiVsa+/7GrF3R7dJZKTqIIbCsI2 uDu0T9gXYgGJBBi1yfGngwLrDpYEcljRIkolwDpcJVAZ+6I+490lvjL2x/14De5//bLDV4K1c0Tk nA8kpMuMvdmBPE5iBjXLIBXNFEb6VlhFjyrNA/D4FZ1x+dyKFdNi1Wj/lWFtcjc969xhdOFabSLC Cacye9HZ7abrzj1x0yVYwfNXUt9LtMlIJR+TwNr9AuebdhCBz+v5PqHPtYP7UPzQfzJwMvRh+I+i xSyZIz4k2XwBXyglpFwpdzrARUja4yONpx7Y+fOSU9KzxK2uIZGfrIKkEbfDh9BOZif7kG27fQ/a Y/sR/SPLm+EP4Yd2OzKZWcbCcD7oQz6bz+4NW5b6l4Zupodsq/2rw9v5Q9Kh8IfBL1jrFQ5HK6C8 rWaLaPVHb7jSMAccsHU/CArYRHp0ClKBXKwUQzFejIpIxDGcMKsBEst1/t8WiGRTi7w0PF7BJ6F7 DgndXTAiqOGkO2lR6aQ/IAUQw9tFFcspqEIPi0c+Bo+cNocK7SGEW+jivCoImHCjaV3496vSE05e IfZyUkc8wDJika6MjehWsYgksWjDD1QZ+9PLziImS3/BHU1m9qIFz16yF8H4eap5cHyETQsmMJcx o3gslXQKgJbNRnWfIIbYKmCW7MMZ04Pb36reX73vre/AXbDj6OLZay/fuWzalUuu2UUvtFVvqP6s Wn29eu4fr0M7bIL3z/r+I9WPqk/tubFFh/7f4+esN5Dst7d6N/1XbB9ekIRv69NM1j5/X2iZahKt POeawc9wbbHfxW8Vtop3ubZ4uKlwCtcnL1N32rcL28Wdnj3Sc7Enk+/w77jsXmIBsY3nUcJIvRfq vUQspoQHScNYSAOAxcJxNittYwRO5LwXCDPFzfwdLtuQbUi42Tskr1bv4rZLb8I3Ocscx/c5iB3r pC7xzoI1jRtyIOEvVgpYlaCv1UmZSSVWbSiYK7DtADWBaaUr8FrdaY3+DLDMXNHhT6VXxolB1Rig bgcKqWv1uAPHMck3TvLZxUK6FqgNo9LKZ4hRHT5vzUGyJEjMirw4PI+UQLrOEHpYGjY2TDE0lGtm NouYWZstGcdm5lfVZMyrqDBiC6pAEnCTFPFU9kRVLPyQHXc2a4D3qTDhwg22CswQhbqN1S1sYHwM atVlwS44ix784LGNufAD1OyoTBv7QB5SMEkZm6DxGGnheWZEMnfqg6bX7ks3bh86Wv0/M89UP4A7 4ERYhA9VX6vecGDJJeuu2L7j8nU9i2y3b2YnJQ/tK8C1kIHN8P7qyur71X9U19L0K49Wf1t98pmb vvEUvAhOv498nJCwqF/heKKARnizXro8MBjY4aFYRVIuClwYulBeHLpaNouABoxAC4ypObcsOBQc ku9Q3gu+q5zIsTu9Pw/8X+ms/2yAzrG2CvrFARxtZGgMGFmx44FexCxCweTAAIRGRXYrirxBuQsr E2RD8eBG+bQ8IlOC3CufkKkTMpR92ZCsJNWmYAX+XvcpADCJxiaXS0Sxn8XjsozpNYspKaRxygCy QhZlf+urUEj32hIqDpK1batGm62XxK2mSUeg39ihKneRvM7Y6R0lOR7hqMZs2OBxRh442lXfihkY LBdJ+bJYJkGr7MBMQTJYAjaSWKrBHfCo/mRabXBnczAVwI3mbczBjJTMgUDwqyJNvcpd2wxK4yBt tRU11lYMSS5PN6wFlTJeYZAMHEm+2hxrjdc3e8z1AiekjOSSbAahWHBqeXTmVVOCuEerz5zetnLa N+F0PZhpq15evWhe8a47Z9/7OFpeve2GoqyqSscNVD8ZTT287qEl3dFq6zxvlFLRcrRz9MX87St2 PUB4xfKxU6Y4RpYibNSLUvPczFCcYhzQwps1plnifVojrwkZZ06OaYmGtmybtiyzNbM1+2yhkj1a cBW/yvZm6B4wn2+LtqG2ZydgFjg/Fo7GojBawdY1PTIfBIQACjzryWg8m+StPB+yhnjTan51Zhf/ lPWg9XWe0TK81aTQrRMopdVjmQ3HP0pHw7m1AlwFCrpDDHRi/y908mwUE3f81IHohCb/xAosvlSP QaeHCSScMY551AqfvmJ5wHB6kiaWR4bL9SIoGRvDlxjyuXQ9RlkpHqmZpLbceh2/1rqG35y5XXuQ f8H6ivUd6zu8HTv0PEL1BzDXd9Uqn0ZR2vj1uE3Gti8phyrOvLe294PpQRMy9oPqmSD1mjUT/sNt S4c8YT333GeXXlL9+3v64BXN0cBEUVUbzt7bf3u+77YjT8z97ODk7tyWYCBix9lg13M/vf7CRiXX FL/spr6+zc99GUi40xkETv5h7Zzm+XMu+PrG7yx84rRguyA2iWh1JvZuG/buGHjhCJAx3kqBgkyg s1MQCzFZxy53XDY14wGCvzGbz2EdSrGwIMuWWJjHbP83gcC5SDhqDqRBDAk8C/ohUXJWl9laQt7t FyQYk3qlbRIlxYQozqN7oxui26Km6FGYBRJ6cb+B4cIZUkoV8IMkT/X0cLRrvAo2XgbDJJxk17Be I/mfNRSDlCtO2paIXTw1ufBa35SJjaMTa/nikq3dc31Jelb13g2r4uLZT/9FqU3eiXMegquML/ce O0U/iSXSBCn9cYn3y0jiUnJWWad823G3slf5sTKmWIzPqlACFJBA9WNKv8G7wXfE8Vb6ZPpPaQet eByCHIsnlQnx+bL5tfiXCtrjOORAedZM0ms5apQqs7GmMJATTsLBFclHvicd2ZYnLJhDxzZE4cLo WBRF1zc36829zf3Nu5vpZpYcnkHm7kymNwuz63N1bl3fUze49UCNWw/XgEsbByQ5nrbwXDKpOlSr yuZAKm1XhByU45aULQd4GTdExEaEqoPSwCAOUIMukuYw9SSnDj6pZC1frSU/pIyPua2BSuZm9Koy u9Pf/q1FN+zqSYYbL4G/CBVnOe2lkQ/2Lbp1ZUC/gp6lxifeONp3aPXFV794EmW+fjGOkWpTU+zS 0dHPf/5yTn/rWbTjpqJsfNl6HFtnC9aFG/p0KxTESAlHWankJQbaLEYKmPXQwBqGTiu9l36WeVoY sZgWMauZLfTtzIP0g8zT9LPCIXof86rwitNW912enAVgXYzXYxUsQgESam/FA2saIJjmWAMJiIXh XDCo582s6LK6bDj5twIIkTNUgo2c1c3hqyCrbZUXo6/P2KNexPazG1manQsq6CM94Gb3sZDlgC3t dgOE8IXdC123cn6P9yipXcHCS9fXiIuxbU02BUgoyUGhOlK+mBw1GwBEg1voniac/6wnm8nGIQDh beHtebUqAkmNcB6KDd+o+0Js+g5kVlym35/7A0SHZwy9EE+1n01SkbdvUqevm4PFTM86C3yJHzxR 9dLIbO/ZuAR+G9vxgrG/Ub+lfggmgC60QPcwglA0xYRii941tXBX6/3mXa1UN5H44otaDxXht8x7 Gl/oOtz4ZuPJ+IeNJ1s/abS0mqeZZ7pm+ma0Xulbyj4IdrU+BQ/BQ6wtb4Ybu3eaHm58ZIIJdPd2 X+1d1D3oe8izFz418Rg81c2x3t7uGzupr7HII3pQJ/krHb7i552wJc9aWLPWkNYaVK0h05V/Pv9K njLlJ+V78uvz384/lv+P/PfyP8n/Jj+ct/bnYb4TJzDv6dstFnS5m42z17I3sSbEdrKz2LXsVvYx dg/7Fvsr1mJlg1hPlFtkKcmejGr42pmluc6voZbtoJzLIUnPaAVeikoLpVXSY9Je6Zhk/lj6i3QO o5ekO4SChLALWvmGaEOuodRgapiamcKrURWpn2LyK5E/n7OULBssxyymGO4QsAgYBSvwFV3Quzd2 I717UTfqfsYDPeTzKHq6N10aC8KgBtqFdtTeQuuKWliFUzzUTOt0L72INtH+SR2XSxU44fbafpPW MzwwMqD9oIzBcqRMKhvY+8+QEFYihxXxAmw4I6RePTpyWqgFtUHN2HkYPwQovM0KXY6uLpz3wsGa XxywSWEJgfK82t59x8SQwgmUicdcN65ak8WkI+KMAFvMEoGyMpFqjwAhZI9ATsZNh6kzUt+7r+GH ASGbNsHBgTLADzigAcJ11fpOuNpaO95jxMSv9sdrJyHqSNPuM/b8U06mtirfgmY8f0fv8gps9enp C7KBUHJGZ+nywfduuH2Xz8G57YFgpGXF1N753JrOVNzf2HLn9utmr3j+7quWt2fCouSJaukJ02bl v3br9IHJ2e3VB/W4oEozp1z0ICxeOKetvUkJEry5eOw0tRB7ggL+ql//JQMTFjjPsifyBnpDOQk/ hb9HZo6FDSjrnhtdalkWXW1ZzQ1GtrtecL3grqCj7kORo8obkZ+qTgA9LkA5QuQbCBE4AU9BZIJu zDnjLo/kl75wQud/SUmrOf41k5V3QIdGTqXub/GXjNOpQYuzwEO4G+7D7wjsVT/H1sWHoiEUajHX 15H+UFornDBDc60y7iiY/YmOu2uHM8rkOJyRRJMco+f0oAFqwwNCl7GbXh4oDhj4Vj9GRM6mDKiG xBE5iZYfP7Xw1RGL2v5gG6VHJ7+x6pVTS9edvPf5aR2dPRbG54s2y4XLZrRfNOHKv0rfXAMDbx67 d+9984tTL76m5Pfnex677a+dWhPJTWePnTZNw2gewZnEWl3ZYX/GfsR+2GsSxXYWRIQI8kUbLaz0 RDTyhlKLdBX42QH4BBPFg68fZrXbbDbWSj5crPt9a+JJtxlfCgBWwPwOMwlBQlLWEKADS4iHsyHa h8lIIEcO8lzUSrr9nZMKOWMnAsurN3cih/pzu3MoF03CpC6QFzzkrQJsFnShVzghmAR/U8cm6SvH IzIdxJZ8pjYbrvEUTAwJgAvGebayRjkEUlOEZcOV0nLW7kqoiooYMVnbz3WosiuZAlk7blRnPAVT vJYiDlTbOc9u2oSz2Vy/vd/VL/dn9+WO55h+xwZxtW+D0p9Z17jZd2fjDvt2766GPd7nG442ODby W52IaLE8z8gjcvhO/fGSccdSzOhf9kWNOtU8I5fADNPnoVtroXvc9UjpCkd2V+3wYV3l7dTPGLax o3rThaum7++7rO9g35S+ToutefKWmStUSc0VGn3pKy/GceW9693xmCne88AV3btv+d72z9cWLoCB Fd5wKDu6+W539JHHX3ou6bqzZgVUGfuYB8Rgq34lI17kLrtXufs810pr3GaVexq9id52vo/ep07a T3r+Rv3Dzm3w1I59XUEtpVbJQ9QG+VZqs+NT+588liw75oWsxaIRM4ixFFumY14Ap3srMH0gmHSZ 6QqM7LdZLQZnsGLtenW/XPBeB4gHEWUDUoQ4vt/qKABjg8PZCgI5uSQvlD+XTXIsU0sWW4S65xl9 RKz1yeaCYTU2bE4nMBv0x+seaFQtyeEo4oOaRoxF02pHhEZGCTUbKZ/GoXzAsBAMrGFV8vl9iAmJ 0QgIuL0RGHEGI9DnwU3NLrKkYKARJQ/AeM0baxhJFChi/ZkL487qocqjY5b50xZ3LemQZ1XWnFhx xehzd7//maJ6lEK8E355dOWlU+Z6d23avenYp9Dz5ycevzkq5uftUrAoJgNATcZZXiPU9AV6DjKu aALxDDBHGcFsymqYA2Wcgt1mE4HdoQm8LRE1vyHDRJTBPhuMBktBai8OZy3JWzyw0XFrA16CEZzL kcNyfC6a+zhH5TBhgpJB4fzBghTJyDru5W2Z3K8/boSNvwQgUxd61naCh/wvT2CE/KXdLmZs9SN6 pNdzmZZCzHbChnBQsjXbNtq22XbbmP/H2JcAuE2d6+pIsrzJlmzLuy3Zlixv421sz4xns2YymUy2 mQGSkIVJhiwsITQLUBpy06w0ULgNS6GlXB6Ucrtw6SMkQIa0faSXKZReAnm0pRsNea95FGiH0pZy e1vGueccaSZJoe9ewpwjyZIsnf/8///9y/lNsDw7jjdPsu+xZjYYK5aKZKH4g/gxsB4wKFy4dRgH oaBY7ObPbD2zFWpPvPUm/0Hu/e/mjET/HDZAuhGchpITiVEeKkyUa4R6o0UsjuM5iKXaoRXSS0IL pFapparnhCiSqCjxCNmAfm/FC94QYsumf9aoCbfcAn745I4bF/RUexia5f3RFPlZau70jasDSUpR QLi0iLx17dziHccv68j3t8WtERfntXGl2uM3rkUrLRY3B6lfQE4qET3EIvBD7dIkb+caLckD1lvy d2eeop+xHs48XXhP+dOAzVax1pg60xUbNlkg22asGalDGpJut9ycvd/6tfzX5ti1IaU/7sgEeILq NCtCb8ZRZHurbje5FGO/EJzyvZq73qupqWqvJkqw8QaqpV6APj7iDlR7Jyha8woCYlQh2v4Flo0W SUorlqvUBBXRWDiPy18omueqUW4IM5y7gXrNBp85NgSGhgKdE2dPYgHs6ASdrYFtZhJsk8ygiHQc xWiZln4NXgQbrlHsB1y/1E/2D8V5dJDHB3nA8RI0ySYokyao1RK8FVkFXFWqklUtruZa0PdJ8GiL ls5UWxDU4lo2txxsoUZbTraQLTcuhkAL+YEQWDnTjajOTyGYbbTTY1s/hDNlCh9GOQKInbunczhF YAqBLwNLCZoUr+ZWTOXGdDCkH36G6EUOTTh+SCBHpSoUx8aSjNmlGQjl1/GkgtAph4JM2GGAGR35 EHyV9lZ8wIymFpLd7Xqjp5Ka9XNa8YSjdM1t7KnkA6DrSNkT2PzsAmZbvqe995uvjmy9aumer3/6 5Mq5q/duvO4znzp9aGxB5+hIW/doPnbDFfH6J79y24Nc+Frqnz5RTrd1rb/7ElNXRimQBe3mpbfF y+VLS4X5QW3b3L2l8kNX3/pi7w0T92z+xINH+kp//b1LqlUuWTAn6BKhNCYGCYLuwDkibzxDMGff O2yv48BdcWGtahokyVEUtzObTIyPURmacxAJokVy8Am+hXE/7nzWSYYB4VEk5wT5C82VSClSQk5Y FckhyxFFik+QP9fWyWlFapFlEIaXEtCgNyficafTYbNIVmDNCh4t3tfwaHPnVT1aT82jzYF/9U64 UyrDJpWGTS4Pm4QCGzi7PRrvqr7iAZwHxDyveEjeAzwIxLuPF4BUOFQgi4UtaCB6a+hFjsBb4R7e DffwhriHd8J9SwH3mhMyR4HQwVw2ncKH4IO9lwLF1PHUyRSFDh1p76ziHvIO7uFD4VOt0Xg1FcwP 64AETSw4Q3EwkzdQNxRs0CRA0m32v2491o7TLiFMgQAQH6aQAAO63zGOONjewDF8q8A2nCjLCu95 fA64B0WuE2WvO1FKhxNN3rjQOBfmGEMgchvKTIIz1mWkoaM4Nop8zQQ/E4zZNZOWqR9L1cBzi3fP Xb4zk+5pqq1BtzsXTi9q4TxdTbUr6Er1mhZN/+qiOesPPNS8+5qaWVHM8dAG8OXru+Ltc5v29cGE RVGYmO8a6umNVQuKjWUhyJRNmwg7ESF+ofnE3S5/g3MRbiIiuXg3H2H8iuRGkDLhUCQX2pADihT5 Fi5rxKA4crWt+jgDGI0AbIRxu2xWNAYReFS34jQqw7J6jlc24Nfg7XGefmcNp+3HZH25icePe62Y L1UP+cFBPyD8vJ/079DEUZGUxHHxIfGQSBfFhngQbhwXT4tMdPg4FDyQcB+MGVEBRDZoxRl6qDGF JQke6gsTjC8cZzimat/KVZq2cuVLhTlNc68oFPpNm/ABTVvV7JoOr2unFYVM+NeRCbiZhNyZg+Om QO7kCfiybjRq425wyA04E8EQvGTiGZ5n7FDF47GDut6Exw6qfh5uaD4ZXsmYbMSM0rajkbHrI4O6 I/lq1W6MEOo1GQ7RITs4aAeEnbeT9h2S+yH3ITdVdDfcB93H3afdJjc6v1ytov7pfKHqwgOEJvgF IzSTRKLPwa058JHhOHJuGBb99ZOzL099fy16efj2iwiCuQFq0UFyWJPmkcDtljSb2G7hUFnRQckD GWeQAW3tQUWCRt5PnkzkFSkNNzQh0adI3XKCUySPLGspkFCk1AT506Oy1gXaFakLbmtZuV+RBmXZ nMi3xc2AFrtbr6DFK2w22kwMMt1d6ZTgsQ1pUCdhZbhUTFSJoYeGDg0dH6KHIFBycpzEkVw2FIRi K4hk1IPBZ4OvBCkteDBIBt+OJ7KFPPwojz/KP5t/JU9p+YN5Mv82wbVL7WR7tr8PK/Boojred7qP fKjvUN/xPqoIm5N9VF9w3tAEecmROBIqueFz6TlYCXZPz/Rj3bpTCmk9I2OigTLhkNtKT1/EuVR6 qqkhWzC4VYrlcNTuMDElNaKWTQURMOaoPSQC1lFkWkUQZkUd4s44H5HjgJi/ZLvmlmIWa8wipkyS NZ4iYnGLGWCnJpHDBpIyPnR6iGRYha2y2tBrdtOIacQybB2xHx8ydZAjzAj7F4ZG6GzrNt0sGkIL O6J4oI/w3gYzcfbPR6Cgwz0UfxBVvjfbuxz6cdjjfc6u73PG57xxHezR/hP2c3FfDNeRneXV7ar/ WiAi1Gh4RMwfmcAvLt43vPKm+Ojdo5dfl0/1NqP1sFvIRXPL8y5/XzOSynNCMZyOF2vwMxHLTepr O5bMWbJs5eiKW+9t7tlUhXLSlApfDu7aORBvNJq2DaEk4gK5fDG4a5emeKWFTdu6BoOl6SaSx9JU 19ntkC9yJI109ltP2etWBuSxi25hbTQPTFBfJxnqZ+Rr1I9DlJepQU1OvQbeCJNuzknEiZzk5ON8 7nHuWc4CwhFBkThdf6tQZ8sJG9TnWH/HkP72ylCr52Q5HotxnNMWvMJE0eYwNPWPnEQBhbNPacsC NbAdGsmMDWt0r1dAKl2Ac58TQEx4RSAFpN4FqNoFpNoFrdYGG6iRBcQbAlLyAtLvAtLvAtLvvAAE pNQ5KX8oTxbzWyDbQI2eNzQ67uFN8oZmzxuaPG9o+Lyh4fGYcFCz5yN6umk2lVJnVbsKiupx9aRK qYZqVw3VruoqXamqwZZzKh1rdP48lZ5DXr5zcwuzo7GEDl6wFar07vO8/Rfo9Ziu12Mzep1Dej02 o9c5bJMhvc4hvc79rV6HKHQbsjbHtiHv3cxs/piJ/NE5+9zQ/kWrPiXwcEqman7enQstW5CqNVPG 9Nw+PG/DwvrDzc9vwmo9GVwHHrquO76jab+6w3zBNDRWnx6F89BBxMESLfBCCKRY4L7U4lQdgDD7 VbPVYo9q9Izfh9bUXJWjAR2Sdb8P7ubpXQN3R+o9VdRrSjpXPS6flElC1uRxGW2aNPlBmZT1RBTt pB3YDbsf9/DWqH8amvv2IMpv2/1kqtaxFUlOnXi6h8jAX2hdKl5g242JhMXhAIjzSTIpiTGRZASP 10MyjBqOhCLBCIXyVVLwLaMi8FndIhEwR1MoXyUFRMopAo/NLxIRkz913nrSXBYttIDCsJwGdTAf zOe3s6YtzC52F78luJs5yB7kdwe/Tz4v2XaZtzi2cLsCB827Hbu5gwELCitvXYFSU4xAMnb+uf0o 2iPMLDxtw+Ee0Lzp1Ws33PSTH555+5XKfL/TPlTIiymHoCZD1HOffuuzL3zmYZB+7kWQm7f4Vz+4 ZmzegmCiZw2IP7or6kUUTDUX0PBECOqL4Hot6C5akEOBcCGXAu9iPEUZ4i0FOfne1eyGL8FAaFpY zu/3m11uiMaYpCrZGbOTz4CMFg65yzp9y4Zfr4w9CpALR8sny2SprJVHy1vKdNltwBKHG9qgJVZj R9nj7EnWxAZLw1t1aw8zC6s7zVjDacYaTjPECd16Dj+iKj61rJ9aNk4tn3fqBzjlGCNt1CKGvMAb GFNbAmIwmVOjairZEsikgCrCJhvKp0A6kpz1AmJFCOnapWiNeVUZNbsCu8Rd6q4W+nphV3BL9B/k LalduZuF2+V7hS8E7hPvS9yvfFX4RuJR5Wnh24p7wAuwRxBlECRnsgdmOTTubWs3lovqPqSUb2Z9 FORn8Li/NDj9G4yawC3lyvxlV35j+apvblw8p7V92do2uVpXtQ19a5qPDFUDySQZ949Tv0BYcsdQ rLj3/+3/3G92JEKP3FRf8ts/rOi6C2GshQRBfQLOgAxIQXtftdftAsvrLAUFsh3l04WhOWxgPtjv PizV8G5U1A9zPO61lOCr8jlwr/2OHGkPOlxVLkqIREaK8iKfYYDX5/cTiYclEUNV//NSFENVWZEy aDZFZVsrp4ndUOJF2hvclUjJEBlGjNq4McJ2DKwhaLDm6B3mk+bTqBgAOKbZiQznlyB6z8oJfb4l sDao4ij5kXBMj5YLbl/1eAJsmVny+vPssO5J0LEqnEDvvz82NcWf0dF8N1r/gyaHGU8O7EbKncsH QnNAF7czbngj1dTr1123ekZhVU8pfHHs9r6OOX2F2rDZ5oiGMt4YMLPFjqa5J2exqSXqaz+6c83c xpwFAzTjSzQuv+EnHXU+HKQgKKjfRJpGfZGQKYlXsp0hfwRp1Eo+ql1mL3n5Bs07MgIfzdCM4BOe Tz6v/ox/h/8P3pzhk9kOvi17wH6PfI/yDftX5An7k7LdxJocloyXnWdfyDKaXWNJd6tE3E9KACC9 A5Cf5kGcHTBX8xD3u4vwQLX4x1xACt4flkIhJFjhKXeEQGgCXKOJwft9f3S7TWrO7BZVt93gY83t rYJVKK/19JNWgVmKNjSbVSCX6qmr2M1r56r6XgJZq1onlN+SEzhDXBUUqyPVNdXN1V3Vx6tM1W2J oZugllyqZ4po8GJ9KxHKpGe8xEZCGYqzpIMVJPKRxN+aQ0kksENy4SlLDKpRtIRc88NLLJoQb1i6 vTJsfEm4C9/N0KxIRXywDQUQZi6Nx3SL+7RmhfeIr4bXozc5Am+Be3gX3MMbof7w7L1yK87kcO5Y EGjpABzkiAs2fBg2KDNVc/iMBcxEYwp9kSiKXEOcOPt/j7CC3sMzUI8SWfGJ+LxnCBOEXG54rkmE J5pEeJZJmDkFLaEYy83kxuCF7lxRs7kaRc3KwUZfNb0CnaSfhb45mYePBln95BG9h68KoUcyD0EI 3PuhZoUbyTzEJcmJs78/AsUp7M8cRZI4AmXtOXS9gtiqL6ceQw6y85Jr6FlhBrlFpmbzavT6Cm0z iwzJz3OJnn19mU4hBtSx4c8tm7NFtMd9cT6Rf2Cw1NN91X35/nv+cdG8sMvtC1DfbX73c1e1K+Fg 5oXblg3fO5q1t4LR/fu7sqXBeRs7Ll636fEkx+EfvlfP/pG8l54mgsQXNedB+0GWxI2dJYIT4GlI H1oQKO8+EjAxO6roTdm3WTc47WgpvFOLmuxPs6EwoGmCM0km0pT1+LzbBcGjwdH3oCnFQ/ut6Dnu OemhPMEQki56mAGCxfcxHoQAEBf0gLtEY/rMGMqewZGGboDDfPryI688G1/FggW5q9Ey2YlTpziV 7+sUL3p6xQ6X7aZPP9FPTzcfXTf97EXF6Drf8XU9iXvBf8grJrejd22cPUOXqa8RCXDXM4QCn+6r 0CJQTiqklQ2zWXY+S9fZL0W+EZmI0L8zv2shEygTK44azkR4JBPvod8wg7NmgJwJsqxb0CJy68km xmQLbrDabXYikYADwBBM1tDgIoMAPgMRPwNBPoNAPoPwPYOgPYOgPYOQPoPwPYP9dwzgGBBjXmFI guEZkkFg36Ygu0GBOF8xcL5i4HvFwPeoP5zVP4Z3VgyYj3otCAHGcQVIyiGFLCpbFFIRJC/wZjkk aI7AGzsNlO80UL5TvxmWQx4I9t9zgqLzuPOkk3IG5eHZ0CLWEtiTd7737m98eVCNTM368hCqxJgf JZnhij6YKbbN+kAY3UOs63uD6ngJUqpGvZTuae6b85lLRnZkU71gpycTVqLpDoTNpxXka9s5Ov/y vQ+D6xAIn96zvlP0hEbA+4Zl6IGI/F1I/QjYr4XcJEECN+EGdElc4V8RGBWPsqfF90QzShc+7KiJ 6MXViFRt+EZ8yxjK7LRIZtoP/OGA5NepAkwS4+O9km/i7K3aRo6IxMKRyCDHCxzHA4JYzTnhljPi BATN8DEoIXgkLVGIluTDfi7Mc05gikDFaDYzTISwh/+d317iNG6Uo7gx5zsA1WjAKigGHgIkmkyv AAqMoic70j1SxU8YllNVUXNwVR77506LNC+CQ/A9yCjEEtSR+Hchx+V0aryPMtCmg++PvR/Qy+fg VQy6FwSlC8PNA4UcSgg9YCoE8Ebu49avz3SYeDgFVPOK6GFF9LAkj3KNUAPnzunDQh13XtT9+bCd a8wkEq8wASTiIKTTEyo8Hiz09EVmAPym+b16zJ8Hvy+6Ai1f2lHL10FrS0dH8/sR8sf75JA1mXT5 xOQVzS+D4t42KUUmk0zb/ukE4nJXc5CagnQugnVPYa8ni6T2//R4e1EywwJigWMotCK0Mry8sDG0 MXxV4dbwRPj7YWfakxY6iI7QIDHouJK50nwl+8Xi14mvh34SdMC7OooOtuhkWLPEeIM+ycujqoK0 BJWLRxKy3lRayTmLxcFQUAiFgqzDEYCax7EaLUJxOAkA4sVQ0OlgCbM3VSQUtAlMppDyTu4OkVPe Eb0CVAEmJkTYx8uny++VKWwVOIR0tez3hzhv0Ut6ITk1vymTiaWqqYEUlXoxniNMJ6HMDZbK50g9 jKs6jJ2BohV7vnLbZkm9mEfJFMjvpUdu/HV3/YClkNNJ7jRIThhhnf9P5QIL323pxsuKcsQYJKNB tY8QkTQb3t7ZWiGQkcEfmq8O9BXA78vp1oeu7Sr3gnqhc6D5pw3luVddcuW8amsPABYLFwin21Ty qQeGnBCpJwLqluZdIPyFrmQLpLSp54nphc0Pu5esmdO5SJuj2u3R7L2QRmd/Bx6gedJHUERYc5AN ookqRwXpBXNxoRv+TaKxGJW6iNfiNP/XN+g4eGA7AZoHzn6PfNmEaqBqmvh9ClCQXo/rFago9FOO 1pkKVNP0MbJA4pzr6b+pQnVgJ6pCNYbrUL38Yc9+6jnTVX8ZM30FzccugqAHTdcQncT/1iq2XDqX a6E+m340/e30v6XpjcoPlLcUyqJklE5lvkJDE9MLDUwvjSxLORFSJC+2CUjdj61djLSOALUOFypW H4cm5TtVNQEckYmoGAUEgwxiW75VzQFAZh3QcmTf5iLR7aFOwx8bLkKYGnywG3Tvtte6uh/T/ae5 seH39dVlSCl/gCpc8O9jDwCOJfN6LNll+Et1tzWxdSvYthXEz3eixC8Ilci1SnWmuM9MxoZhqSGj ADxLihmtGWoEueafnb7+pm9uhNuy5fJTd629e86i/kZQTrtCDS2eczmoh6eVNQ1aUcwp32py+/SB VX5oaStUyruO3L7un/7X5uqKXOt8f1yNtjt9drc/VlZvQBZ8Gxz5PjjyKtFOvK1xhJkTebMk0kXL jN1+RSKpSJKMrXdZDiqSKMs8YP3BZKbCBXIVVQCqc4JLp1I8zzGSKJpRVsDVgUAwm9GSIPk2cKLF XCS3jW2fMdiLcNSDD9ZBHQ5xR/1jhnhsZoynZpWinrwPh/mMwX7GSOvGd6nN5asl3WpZrXraRaLV WxSBz9/mqoig5ION7obWjW8jqn8+FVTdBVZBytSoLwI/SMZr58X4MUE4obfpWxBybtoExl64SR3v /CmXaWlGcjkr05wGVNjv9ETrl2VFSpu+9fIQCmSZ097LyRuvfPjQNo7/684lJYlUFDoeFi6CB4+G w/60z+ViPQOl2yEf4DgXlMs8cZ8mvPHfjtNEZIJnzo/ToJ+XIfU4jB6eSejhGbvHVzUCM26cEwVt bsk9fi5CQ7mMcFXugzGsFD8aivloIObwbCAGgoyPiUI9R7eCt03LCTsRe5JBxckmwOHD1iB7DDwC PkfoGfvThuC5oKpOz7JlPfDPtBx38A9JsGMgCe4lUQ3cwHcIinoV3u8a+PfaEyZQ5N/X6+mh+pL3 NhXwOjyX16+h3/yvr6Hf/MuPTC3nrgHE37vmT+e+h2geA4PnrrH8N66xEP9+zHLeNfzfvWZ69hqe +N0xXr+GbP4bcQOoUEsIjggT0W8TFrCO8MGxWfckL7ABmiieeP0EKE6dQpdi959ehg7ZSWY8lV08 UjSgcumSW25Zunz50ltuWXLpLxlXY/nyhosBZx5bv2bN+sceWz8+vv6xA8Wbm99rPn9zAY19lNhP /Bp+r59QD/OEewKsgzY1aSb9gGOdLkAUX/9l6wn+l5Og+PLL0y9VyqV2ozqPS+egVLKCOK9S+XWz Pz7MWj12V6TiBmXZzM4V98ci3n5wZYM1C9L26efmuEWoeX5P7AdO+I0i0X3UT3pEiBo98GuPmknS wZop/wR53VHgYG0LUbYXfO+pl1r5qToonjrRWuSnWouVE7hoFTDrE9aop1bBmRZQxuqu0HbgLDRd j4Q/OVBdWs5q/3rpwOLN7Xu+2OuQvAwJVvzY/Wj8zg3VgYsdPyjWLhnf0XstbU3ZoQ5s/hbSgacG CYm4WAuT/0J9iyIpUYpxJSjuOBQGJsUAVJVQjq47HBAj34J0gpeR1z0teY+7gMsOn3jsxOvTp6Za Ibngw/Ivj7UWx1r5E2Ot+JnNPr/hwEUUNOxcQxp5AN/ffD541+Y7tq7d3egYXVxY0pXJ9Xxm7Q5f +h5q8M463T6456YFfa5Aubei1HNXVVUSbIICpvkWfOoQtRROmRjRd9hk4hAd+bC0wnq1lUxbO6xD VspKYOL6pajVbjcFPSZ9VrnqcETRw1bGxirwsYv6DDPjcpl/M9HkhFfA0yz02L3vHVx4aSQ/7/J6 z+i8LTsvWfHzy3rHvXGarLxx4xUQu3Ro/yC11a/aMad70ei+t7e/5kKBa6L/7FvUl6kpwkvkULUu M4WKmEGNkszrC/8mKNtRV0Jl7T6VmKAFnLQDH23MXS+OYVki0qgMjpxAq296SX/CSXoFkcZDWKDB 1OjuywdyQts1X974iUc21do3Pbgt1ZbgSItLKiYW9FI2t5ijpvKLr9j6qfbxY3euXHnXsTWXP3Pw 0kvarj+627dg6bLBll+/qSxfsaQvZUSbqQj1GuTIzqNBhx5mQPUTfQyUe0wJ/4IXzRBBKWxz2iXH BO2Bxvwk/B8Ux049D8Ho689Dfqm06iFDo3AAWoYhkmgZzKLFlbYQvWiom/xBY2CUDrVVhqdLSqyi xcm1/W2KUpsz/T/iWiWGCvYTGnyWr8KRyxBrNEfaLJsomuZkSSZlVPgtiEAP68+ZzT6UvxDza/5R v8nv97mOUQoh0sLhNE2gsolmqFIaFcjIjemXIdHHKpWiCw8unKUnKpixkkZlml4KjikcaidpTvWa Kq0iiSsQeSlzWw8bG/jw1B3f2VqQakNZX7lS8sasIbV90fq+4e0XZaubH7/p7fZK85vlTx/au641 N1SNWgKFpNvf1dNViGTnX96mbdq6bxlNnD1LFJtbqAeon6JCLmffad5OWJ8gdMrX0KeN5j9SR2kX ZSYiBNH8BmE/DAhO/xh/fiW0bl+FKJYhPFG4f/bXcJJBEEqYCeHsOIHOMOpMkhBh4v2ZeokM+gVy 9A16/T34eQTvG3kpcB9SH85YVCs5CdHUMLGOuFVbsIpftmyEn9OplXgzIBZneZstMMrzsQ0BFzci jZAjWQhfiVgsRsYu7ukZWR0D/L7F8gizem9ucG+tVsqBkN9sk6wBSIbJ5uTkZANSYAraKJOT05OT iBQVSJWXT0xOj02+hHYn4R8/fWLyJXf9FCZQEQs/GU0iHI6mMALVd1pnUhqrvTQimL+XqojUrPpF slJ2Ul5vJR5HtEUshOUn5CJ6ZAcd7qxN/yWVEajmm5QnrTa5YsVP79wpd42uWN0yd7xPZZML59Td lSU98UU9pS5bwM34/FawY3olfKtokOXY1nxHd8REzZ1eHysnXEBRQLDQlyE3T9+Z7WsJQpjkbZlT IDevvWzR1tFK1M4HgtZQlKOBN1mNtfbmZEHhhAAZKfUlX33AZnPHYnzQ67a7/OHyvBaj2h4zAqlx BbGL+Kq27Hpx8+ZdG68Uu8W1FovTx63NioGAKg4Omq7IOi8dHXWK8F9hjypJu8CubLmULmzcuHDh ru0FTtx3xdryLmb73vbL9vb1dbeDdDJgMXkl1exHlEHEuIA4lRnqFKEinKVOvVh0VaCMn35ZZyN+ Gh6uo01+stUgVfLjCPX3qEbOUM3gthlBh/SczouQeKjwDESzBUqn38xx0x8olyo3i8m0h2q+RXsy ajOZzHjo5luQmMkmW6oF6D17+rbdv0Jb3Ze2utpHNs4dunFpya9Wwq5sMkiZWas9mkqahxYrzFO3 PVn78AUSWAOyz8ZyDn9cdlQ6QvRrqlaIQDqS4byWRnRNa/nwx+wLuTklSOclS28Zr3gjotUmRoRw aU4mWoy5rD45bON5t8Pq9njtpNp/WdvtVlcoNxwGQkRkuXDQZ+cElm6Ze2n28yh3FlF9HaT6XGIl cR3xsLbkqnXrrusWV2Kar8Q0X71KNBHZkQWDzgGd6DdAol8HrsNEn7d69aolBZHbt7K8ilmyt+/a ve3tfQMD3X1/n+quj3Ll35Cdn6xUpl+G7QV0h+3fozkm80eI3q4TG9McWiugpqrt5ySv1xv/WEoz /nyqGVQziNKUG1I3mcoJeFtVmq58JcTs2UOSiz51zyJvz/zRFFcZvmZex0L1W83fmVkSODi7EMt4 h4YTpuZ7H0PjlFZANKQD2UYe0bRFy/mhBRAq9mEStzSyAdMsK1+09vaVOZKTEzYx7LHbmxd/x+oV PFG/YHV6WKYwek3P+CxlIyGf9TzKkoQN2qpx6j0C/VbgI9qA1xuORSMojV6COCsskuHVLk5wuTiH B3g8sLdYRJKF5CUHWafAsk4nZ7OxLCfF1Ogd6MfIfE6kHTTW5WFtpDnsk7wWLGhbJ/G/BpKmY5Cm IFisBIqIzAf4HE989wCqHQPgIcTOxTF40LKT/9EB0+Skc/KAcxL2LvQpQnB4tUXlXMFKY6U38gCl KKoC5KLFPFhvfrU+mgTLgmBjYiDbJPorJkvf7TvfBcImQXaoYVlmVlxK+T/89oKGLAt+q8DfB65u voFXNf2Wpql3oR4a1EIZwuOBb9XC2SVo4GlQFzkZNZ7NqnH4lkeR58mp+u0QJbVCUYOmLT8FJ6AB mE7A3RNIVRQoPG1QcjGUJLiUoy5V0MTDdehoOsV2jKzvWHz94tSX7ikvG12ojjy9bf/LBxeMHpy8 Yd74QNEXViwp8ub61SOl/hsfWfvSaSHbyK28aNHQ3qc3b/nXgxd7fJ5QDFE0CCl6GfUT2KeJqhb2 aImEKesguLSUJtNZk6QSUsCWVlnJieHSFPLOoQc+hdkMYrx2HS7BuY6WzRtiMI44Skd58HgwWY1z jkgJvlVix4sHh+ceeH739CvgPrMQD91+f+qinUsrsi1SyZK3ZqpRu9z36WPbNzyxb9Fj8bTP/L1X Vz90Qx9CVE4oWo7BJ20lbtOGOSuwMmssmy0PWiiLhWjJhYOhUC7nqKajCaNSYBZFix9KHErQiTLT p0cpYgyVY3JMK1AdIas15KCEVjUtZeGrPSWoUYgLjTd0+aHMKKJincXi2BjU8FCS8KcMjXKiwiMU PnbiBLLGMZFmi84hpIgPUIbIQAOAqs5BosrgsJwZqEi0qtrHFxUtPlXs6Fl/USOo5D/cU+6SrGy8 M09tkO0ZbVXPXaTEtyzsavauXdb8P4lcwBrpXNXbfEHm4+U4eWeiKDrl5q9Lw+2iMTI74ci0EJu0 djPNKCpaqh9TKUZlVEch4QsLs2OCq0AwjMehAjoJoFFOeVrUhKTAIXjS55G8NgyJZ0bAmJ/o9V/i Tz2vy9Ix/gR/4gR+db1EImW8ufe8dz7vpTMrN1KQ16K1xZWwPd5Tnn4+055wohdxUZtlZ3FwvPcA aVl/ZTPfvjAvNH+VhkhDllmxNUUeTJUjdrn5Tudo2UsY3HYb5LYasVxLVSGrhWIiELNCMGgXhHaD 7VKBsEQEgy5GbanVyi2Q9Z4SXKqUgIxXmWqdZbuXEe7HnIc1wthLkLIX8p9RKwBBLhQBYLwfy4uW ZKC+aK028InhXLZVvqwcnRvtWUA6uzuGT265+6e3D4ze9eJN/eNDVa8/ak2SN/dfszDTuPGxa/f8 c1XO2J1vVDLJZLb0rppbsO/wVVu+d9cSt88dSKAfcoSc+WNI1TpxlVaQ5UrFXC8puWwkVi/VyXqd 7XJbWcEcNrLi2IhKEOak152QZAES82jJylSkVvMsbsUtYllQhNR8fVInJ5KurxvzGheKN8jYNjNz vWgooBo8f+98Wv8ne18CH1V173/uvbMlM3Mn+zrLTWay75kEshECDBEhCRCCIgISSGIi2UhCAKVE ccG4VxZppEJ9leJSnualmFJrbQWrQqhV2xRRW7Wx1SqtlGdpS+a+7zn3JERLC9q+z+v/80/O53fO 75577jnf33LWm5kR+q2uvKTRs9PyAl0FGWJCRr7DJNwc6PCmiO7sAofJpuS4R3+TnhdrEn7m/2mq 1x7odhfME3uTvE6rG96cG+//gxCUlOe0uN1WxZswuj4tLzYAvDM3UciiNo/EMDUNeoglU8qiYm22 cFe4GJ5qlMWx35WwBrHBaUCMpb8ren5Hd5ju6A7nZMd9piueF0GcNvpGcr4i2+LzE0T6PkC2KFNS 3AH2PIxEGXl2k9ttsudljK6nqMdGoINAopDpZdEu7BqM8Z+BI4xBOahEJ4ouQkeT0WMT0LAdgnfo 70CKGBs67jx3a2phnBzsKUgSa/J9ybY0b25F63xvcJLb6vImilsz82ONABebnzG6JltJr2igvztO v9m6AegySV3ZFKtgTCWZUdEZ+tjIICUiO0KMiEjITo9PUGJiywl28JkxkRJR4l1AHB1lUwLTRFcG YUM8plusow6fO0xXUpGFtPfnHuOD3/LjXmSNUq0KF3AGt+CmO52Iz7pQqLRfeDZliiLLrlzP6ImM QsWi8z/o9j9hqKjy754906xMTRe+/4E07A6MyfKMNlFncbvNDm+y+KNzu6Rpo52VZW63r1K8ISFX kd2jA/Qc7A/qb3R1kNaD3lEomyzl9JdPRBk2KCNCDhGCYCWREHuiJ8JW7o6yh0e5Iuy2eCJbrbIc EegxxhsCXEZ+BHA4CItIurwopJ/fpvY6fgx7bibx8uXHli9nJ2nCuLkM2vePne8rSZkS/EfaKceX ZAqNvlkJo2mypzTbv332THdkQpzLJtwp7BK+6vImhLnds+ace1aKHB1w53tCIddl4q74KEeQQaA/ 7k3mqCO6J7DCCiVJZEaZh5TdF7Y37MmwV8J0M+h/4maHiWFhKTYnXW+VLQgUAqMT6Qrqv9yJejM/ fVmuHb8sZwcwE/YkdMTSj61J2fRcKuqeqPzqT2+58Sf3L6jeMXRDx9CDV/tfS5pdW5i9Yl5W9LT6 eaWrfB7hg8Zn7l5U0fv9jrU/uKOy/NYf3tz17Y6CzMbHNi18eEt1aefDQI2xShqCNZwkhczHAFxm gyO4rWkugwY11RpiItYgq2KVrK5Eh8OUkhjsCqWdVm9yGcbnHDY68a6i+dvH5xfnY8cy51cZ7vzx JQaGobiC1NHhpHyXPKNSTKr6avusnMY9reu8S5vCshcUJ+3HgGMBJrMzL1nc4fO6Y6c3zJ3WVJk+ t6kx8/LcWKZ7/y+he/qBlalkZVmm1UrKPFV6YbpeyNQLer3ioT+0LmFhXZgdLoSH2zJd9FNKC2KE mJREF13HBlgCrUHexHA9m2roOR03SG7WciaOl9oliB/ayaLRKbGvnmKzSpK2bbiwmYrb9jYETbl8 aV5KVsaG4kV3dyxxXnVvXf55qyWXryzIXFGRHVNaN3da7ewE4YOlj9yyLCR9br7TUmwLSa1onhGx ZPNDy9c+21s5+9bnbu56fO3U9Gsf3bRwz43zS9r2ajbU9bIelUXWlxV6HIIj3h2/wukIczodbo9T UZzOmDKsseISFINgsHlcHtGTag2FYQVrQqIDA1JWIlYQdPJxKrBrPDUs3ZDlarb1fjx2znZs+WE6 6dLzVroJw/J961cO03cbn7U1623M2AZjKPsaJmpx7QwEFpfjpsLiyXmKlY4gYlLb3qbcdde9P7/K /xX/h6XesivzI1rW5+xP88YGinw8+Vpcut3iTixfPW1pV7x/sEVyC0/M9ZRUJi+vxwiKvictQd/z kfvLrrBHeYKsNpunrIyUtJeISklZyX0le0teKdGXlJDyvByvN6qMKF5B8AZ7segrKywLT8myCbLN SU+e7eEGe4RdtOsLE1NyczNTzOGJelkO1LOzMLYCGVuHaI7Bv5+aLTY/pgsRdrG2ECoa0s7PQ88v OvK1RRf9zyynLpIeGGm9nH/nEXUq2i0Mc73LeipKV5Tnhkbbk5JCSquvLV68OK/muramZHtciD53 1b0rpi/z5YRHO+WEpOAZV3fMumZRzoKGNQ0LcsRnZq5dlBkRE5Ee43+ssGFeesX0tOI0T4o3MSY/ zxs9q7MmOywqTFGEjZd1LEifV5I9IzshObt8Ff2OTIwFA/AjF/rQFMeV9mvt6+3SfLtQahey7II9 nGwVhDJByBEERRCgL/ZlBKk27QvEHSTCSPtS6ECQ1WUbm83fpDPoMfjN2/TbuYeCtISv1T679mTn n+7gOGkgSWfPq8y7zKwUZY6+lFTgDq7Jviw3VpckPSAeSF1YmjialDzVbYNjuOA8b6XMmJ9If7xQ ICEYgTuBPwk7uvjw8KhEV5K+PMiV7SpzSS5XCv3+EjEqNVQODyEJrkS61uq3B6DDD2lLLCHrmDYA jx4LoocMQKnNk9rSMXh8MRmsfXqUu7muMzE/3vbqj6/d21pYukB0z5m27is3Xi+7SzKEtdJAUEJp hr/2pR9nXb11iXBmWr7bXTrbL2+4Yee9wn+kTksKcTPc7+m8wG0n15cVmM3BoaEr9MYwfWi43kg/ ESUYjfqYmPDQ0HKdGKYTQ3U6vd0uitkY2YItxgCRhMe4Ys1UGh0dvg6f34Vj872c777Z1pv+/IqQ y/beGNC2moLYN7nSHCqrwYhFQOKYkFhEh4ZO4f9vofPmLU/zP5Pl3x5ZmiMGFJYZTEOHZGtpsbBU GljVcO5PUlthitsdH22NCPNHCQOKN0iJE5ls7NyB7nB6y2bFxxtS09NX2J1h9nTB7oxz2g2GOYKQ Lpit6Vah3GwNM1tN5jC+44kg9iD6gVC3U7FbI8wBgsFljP/sbodJipmfCYs1DnW0oa3nzxmo9EFv HRuTNFgoZKJq3wen/RuJNOGkMF/i4mubiFApOjggY5qwJHVV4TNWd0nW6HdzpsVZfu+ani38RUkM 1Zus/VKCPSHYHud2SzVX+n/pfyltitOMyUoIis/znBH2Ti3G4GqxmcwxIf5hwvuYH/oIJgvKEkwG o9GM5bGoCwwLFElgQOCKYBIWTIKDA0KDZJuNfjlVMJXYSBIDqMRYkh4T2EaWjjJbtcGXCjmEVU7C 2P5VYMNJaJyw8XfVNy0vMie4zpWKKw707o5UoqTquakVa2b6t0l3r+8WpqqqtkrXPyImWrcAoIG8 8bNKElEWKKCPmMLR3eO/qwvH4iBNSMtHaaf4sHib/iZitE4VFokZyGkXnxKLWE4Bz/Ehp5blFPKc 6Xhqtb4TOSU8pxg5LfotyCnjOS71E3Gr+AqruUbdhJy1QFbMcgp4zmzkrGI5hTynDE/ViT9iNWs5 JchpFX/KakaO9m1upl59BVlEWsuK0tJmZSUnhwvu1KzwmFBrakwWwrzFCxfNm2UrdhWLxaW+ebNn pkWEJrtmhacGuhXBYFxYUZxIf0Fo9PCx6XRpMHZ+iREDHhf05pC2vQ4aPR50DIvQEHZAyXZl/Mwx InzMy8Z+guACH/1lCwk6KEae/82vCd/dZghLmj1zhjujoiQ1MNwUkaSwTwcHBKTFJs/LYB8PLooJ 1puDrSHlVfOiNprNPvYVb7mzg82r7pi2JCKRfnA4udAdZM8qifPt8W+bMj3eovN4TEp0g/CNLoeT f4DYzT5rFHmddDDaFWo1BlgM0l8/bIqOSUpIcCRH1+siiqp30O+Eo39TePgP4j8fhArhwfHwvHBK PCHNlN6nQfeCFvQN+n0Tg2GTYZNxtslqGg34SeDPAn9mnsvCUcsR64B8WD5s+zjok+A3Q+pD08bD 2xND+Orw1REhkeGRv446FGOLnRn7Ng325Y4PXBmKHGdDeMd9k/tPnk8TPqQh8Tf/r4Qk8QIhl4ff Jx+81JASNx7mTIbJMBkmwyWEVf8rYdNkmAz/hmFnypMpL0+GyTAZJsNkmAyTYTJMhskwGSbDZJgM k2EyTIb/q5BqSJ2eeg8LH2ghbdo/GbanvZFezsJiHurTW9K70zezcBsP96TvzFieuSRrNgvHs45n Z2bfnBOUc2vOX3N7tFft3lDvHd5P8xbmDeR78wemXDnl6amhU2+ioSCgoPr/IDT9fxw6Cm4ouIWF u3nYWbCnYH/BUywc4uH5gucL2ybDv38g9P8mCPEjTibPET3JJhLxqPcinqqeJGEkDLyHSCyeqjYi vorFyxCnIH8AcbDqQ+xBThYrmYWSPsTLwOeDH0S8DPFU3D2JOBglpxIHiz0szmX5Pjw1lZSzeA6L K1h+NeMXs5JXMH4JiymGyxEIWcxqXsyQLEYNlJ/D4nnsbjXjr2T8MsRXoeS94GhM/xZJHxL6GS36 dx2LJaYZJ7uS2GcoTUII5yVSTX7FeR30dprzehIl5HLeQNKFuZw3ku7xekzQ8AHOB5DbhG7OW8U+ 4RyzBf3L1+3kvEBsuqOcF4lO7+K8RFL0Bs7rSJjexnk9seizOG8gEfpizhtJ8Xg9JhKl+5jzAWSW fiHnrUKlfjv9ILhOQluyUeC8jmQa3mG8nn7ayZjFeR1JNdoYb0C+wXgV53Uk0VjIeCPVm7GH89CV 8RrGm5BvMX6L8zqSbtzK+ACuf43X9K/xmv41XtO/xmv613hN/xqv6V/jNf1rvKZ/jdf0r/Ga/ikf yGR/jfOQ3fhfjDcjP8QkcF5Hco2aTiwUm8nLeeAxhTJepp/0NNVzXkeyTbMZH8Tq8XIe9fDyoVSH ph2chw5N6xgfRvGYvsd54DE9yPhw+t+ppg84ryN5ppcYH0HLBzg4T8uPMj6alg+Yx3mUD0hjfCy1 aUAP52HTAM1GDmbTHs5Tm2r5Llb+Uc7T8r2M91CbBrzGedg0QNNbKtVPgMp56Cfgl4zPoPUEJnEe 9QQaKW+aoH/TBP2bJshlmiCXZUJ5y4Tylgl2sYzZ5VGikFx4QA5ihdSQRlKPtJK0kVZQF9lI2lnO LFx1gKdxLfKbWIlM+r0EpBlBgQc2kWvxfBfpZFf1SOtRuhtxHUrW4H4Ly1VIFdL1rFQb8mpRk4K7 9E4tqIu1UYcy9F4HWYO8NtLwpfB9vmTRRXHMBN+M1hX0o0qUXY0a21CaIujCqH4Fk6qTt6CQKWil APo7X69W6/k6F5BFJGO83kqU/Fv8NeOcj0mwHrW1Qp8KmY92GxgOejcDtAjP0XqbkbORa6OD6Y/W mo6cK1j5LpavkAqmRarPVuQpwFpIvLD3Vbi/DtcUJa1nHbMY1X8jt0YDq7GL2YVetzPZW3C3C6Ge aWkVe7aLW2Y25pMK+IT2bMeEO+1Mj3VoZTWrsYlpbz1razXiC7erXdOyqyHvOiZFHSvbhriO3W/H HU0CqpU63lYTr2E1r0uTnnqs8jeStzFtbmQ2b4KNFeZ7q8bbuhCu1r+p+9K1dL72unE7dzDf6WLI V4978IWl11r/W1zFE3RAJdFk6WLtjfUNWr8max1y1jPJ21h/u7CkmqZrP6PVembZNh5rUmn8Oly1 s1hhaLvHPVerh5ZsRol/aKNHldzsnFylprFeqWxrbeva2F6vzGrraG/rqO1qamvNVGY0NyvVTdc2 dnUq1fWd9R3d9XWZNU0t9Z1KVf16pbqtpbZVaepUapWujtq6+pbajjVKW8Pfr28ss+jzdcxsa65T kiubVne0dbY1dKVcUd/RiQeUKZkFOawsirKSCxZl0LKVNeP119DI11G7vqn1WmV+Q0PT6nolQ1nU VdvaXL8RMDqaOtta05UrmlZ3tXUoFbUddfWtXUpOoTf3qrZ1SkvtRmVdZ73S1QgxGtpwp7ZTaa/v aGnq6qqvU1ZtxJ16Zfbiihm428Eu2jva6tat7lKaWpX1jU2rGyc8i7SpdXXzujo82tWm1DV1tjej gdrWOjzVhAKrUQrNZyrKWONtrc0bleSmFKW+ZRV96nxdrWOlLwiJFa+jMnfUd3Z1QDroa0LzeHy8 rmKGILkJrXTVt1BrdDSh1bq29a3NbbUTGwXoWg1qfYcCedvQFOJ1Xe3rupS6+m6qXJRprG9u/5xE Fx3uad61rPPRQfVipbvIOsEK7oOLlmxgXfVipcpZu10XKyfdLn1fOiz9APFTlyxR0yVJVIH7jeC7 kUefWHfRJy5jw0gnmyy6WLe+uJQfoNOvIZ+ilQ/w9MXKX8FqvlipOUibUWPDJZVeAJ5qZR0GXm1o vbhuJmryolLqXLpSXbFulm6KrkBXppumm6crvGgLNZfsT/OotEIO+IuXpN7cDn1fFLMQTN6V3Li6 uJe0samqdmxPSNQ48jy58J9E6G7GSgSVrXEJqRTfLxeJ9C1CZur1FbhWtIF2Zp3C/lSVfWOPv6ay amZ2tkRuI3wXbsEWTxbpOncxuLuIIN4tfo1IYp/YB/5BEet+cbe4G/zXxYfA7xH/AP4T8Sz4P0vB RJBCJOyRpFCpHPxlEtb6UoW0GXyP1ENE6UbpDPj/ls6BH9V1Yt3dpesikm6dbiP463XXg79B91Xw 9+u2gd+u2w5+hw57Et1OfToR9Bl67K/0Xr0XfB72lpK+xOAjgmG2AW0ZKgyV4KsMV4JfYlgC/irD 1eCXGbrArzNgP2PoNqwHv8FwKxENtxm2gr/d0Av+DuM3iWB8xPgIkYz7jN8Bf9A0g4immabdRDJ9 3XQKq/7fm86A/+8A1BxwVcB6IgVsMGOXaA40W4lkls3J4FPMWPGb88zfAr/f/CT4p8w/BP8j82Hw R8zYA5uPmYeIaD5u/i34D8wfIf9j82nwfzT/N/hPzZ+C/5P5T+DPmv8M/i9mWNZCLD/CTuJ5ywvg f2z5BPxpyx+JaDljxd7bGmSNIpI12roY/BXW5eBXyCuJINfKtTDqKhkalq+Xv0J08mb5afCD8nPI /6F8hEjyC/JbyHlbfhv8L2258AUd9wiRxDEbadbR7MItAs1UQyc1JmjbtMQEnZiWmlaArzWtRtxg akfcbdqI+HrTJtztMd2EeItpC3JuNt0M/hbTbeC3mnrB32G6E/x90DbV82muVRH6TAOfbsae35xt zmYa+xD878y/Y9o4jPiIBVJYXoBmqB7CEUdYI6CBSGsk+CiqGSZNIHlRPEX0tR21q4iyemNHM6m5 tqN+DWlorF/VQTY013a1klsI9sflM6oVYl9c7aPrOsL6lR49LILzBiLTT9Yw3khsJIrpi17r2OlG EImekCNgnx9MYsZz6Oem0EZFzRyFOGuq5ynYQ2gl6Te5hJJYfiURMwnj36elQ7CQcOIgztXtne3k IIufY/HLLH6dxW+vqe9oJb+lsUBYHMXibBZPYXEJi2eyeA5drAlVLF7C4lUsbmZxB4tvY/FjLH6W xa+2rGlZI7zP4lMs/pTFfhqLBhbLLI5gsZONUvHETTxfgAskCSSRJMECKSSVpEFLGdhPfPF8gZB/ EFPPEPmp2t9yAuxLLUp/vMWEFsywghUWJ7BgCGwVBptEwBeiYPEYWM5OLURcGMLj/s5zl5onwuL6 C6ZB8KaLpdeSV8gvyK/Ih+Q0+YsgCoFCiBAjxAupQq5QJMwU5grVwlJhlXCd0CFcL2wR7hDuF/YK B4RnhJeFV4U3hHeFs6Jd9IjpYp5YIlaIy8RmcZN4F0b/x8RB8QXxdfFN8dfiR+IZ8ZykkyxSmGSX PFK6lCeVSD6M+TXSMqlOapa6pE3SLdJd0nZpt/RN6QlpQHoGC6tj0uvSm9KvpY+kM9I5nU5n0YXp 7DqPLl2XpyvR+XQVuhrdMl2drhljzybdLbq76EkKZo7DrDcJyVX0ioje1/Nk6AQ5eV2EnkUKU+/T 0sIXtRGs6JtaOj+Vp+e0dOFSLa0u0NKV6VpaG8bTs1radAXRiTT9FTHAXYT1zxAD/V7n6z0akhve ZkiETf3a9aa3eXpWS7/SqqU9V7Byuptab9py086bHtOutkRtSd9StqWGX/1oy8+3fLjFr13d/NzN r9/825vPac/f8qyW3vqYlt52Cytl2rpia8fW27c+tHVg68tbf7X1U5Zru73/9hduf+P2U71ib0Rv am9pb3VvQ+/1vff0Ptx7sPdlDfEdHub/wh1ztfTON7X0buqNhOjvf/X+M9sithVsW6pdb2vedt+2 gW2/2HZOu94etD1v+5Ltm7bv5dcD29/YQXYk7qjQrnes2nH7jgM7Xt/xF+16Z9DOKTuX7dyycz+7 1u18duf7D8gPTNGuHljwwIYH9j7wIr96d1fgrtxdWsu6XV27du86vOsjipoIXzPwVOZphKaRrzl5 yjX/YKaW7n5YK/dQBE+d8CWaXqHJ+1AjT7t4uoWn9/H0IZ4+wdODPH2Opy/z9HWevs3TD3l6Vkv3 GHgaxtN4nqbztIinc3jK8e2p42krTzfx9A6e7uLpPp7285Tj23Ocp9y+eziuPWd46tfSvSaehvDU ztNEnmbzlOPc6+NpFU+X8HQVT9t5upmnWE3GW1ivekc4JoqiSewQn8R6cYH0mG6Dvkh/zDDFUGJY xUIzQj+LnzO8YHjdKBpFdvU6jY3pCB0Ig8ZBU6mp3fSw6UXTiywfeabjtJTpOA2G1wOSAzoCdhn6 Aw2BNYFbAo+Z2s0i1hK55jctHZZNln2WZ6xF1hutB6zPmV60fkjrMb0oR8mJ8jL5HoTtCMflc/I9 tlTb3iBDUFewIdgTXBS8nd4N/jBkQch18j0ht4PeDW0PfSOsMTwzvCt8H70b/mT4IcRnIxoiBuV7 IuVIT2R15O2Rj0UORB6P/CgqJKosqipqU1Rf1HNRn0YXRFdF3xh9W/R90QeiX49+N4bEVMfcBXo7 Vol91l5n70fOeBi/ugvhbRpQigWU1EI/DTGYihy5oAWOVhZvcvQ5fuF0OgvolbPAWY5wn/NV5znn Oddtrr2uT5U8pcF5n3yP6zalAbRb+bnz1bgNrr1x++KOUZloSeTujnsDcxR9R0ff0BWCikAl6oDw iXqv8GfQX9V7RQEUoJ4UA9UB0aYOyCtRRmBv82LYOzr6Lq/QfxbPOvCsj73VWwqi79QOqo3Wu0H3 +s9a71Md1vtVn3UA9GvkjYDeB/0GdAr3fg/6A+gT0GmU+SPojOpDe42YR+n7QRtqp+/lPHjienWK 9UHQbtDXQQ+B9oD2gr4DOgh6GnRWnYI5XcPpg4w+4PQxnPSd4kG0cTfoXtB9oPP4fMDnAz4f8PmA zwd8PuDzAZ/vc/h8DN+9XxpfBHuzWQgqApWAlqmDwDUIXIPANQhcg8A1CFyDwDUIXIPANQhcg8A1 CFyDwDUIXIPANQhcg8A1SLzsbaYNGgxi2BrZu1Infe8Kou9K6ZtS+p6UviWl70jpG1L6fpS+HaXv RrklIU+jdZN60noj6HbQHaAdoAeRvxv0ddBDoD2gvaBv4N7joCdA3wYdAP0n6Du4R73iadAgrr8L OgT6Huh50GHQEdALoBOgN0AnQWeBI1uTBr4WhKtgpA4gdFKNg89Vh5k0miQD45IsYbb2Wa+HD25S H4EEj0CCRyDBI5DgEeuDyN8N+jroIdAe0F7QN3DvcdAToG+DDoD+E/Qd3DsIeho0iOvvgg6Bvgd6 HnQYdAT0AugE6A3QSdBZYPRwe/ggwQDzFQf8xknfiaP3+JDOAWl2uBfoTwL9SaAfgP4dQL8P6PdB 5w7o3AGdO6BzB3TugM4dQLwP+nVAvw7o1wF0+4BuH9DtA7p9QLcP6PYB3T6g2wedOlgfHuCIfBwR 1ynIhxJzQJo+HWQR8mqQLmH93AFUPqDxAY0PaHxA4wMaH9D4gMRnpf3radBZlc4yB8la7KA+rwH6 jn0Ok/gk6j6JUvT3sG2Qn75TD/6XjB+SLKsjcjQoVh0Bku/QPCChfj5ARyli/kKyBIoZqlecAqoA LfT3iDWqV3aAEkEloBn+Htmnehn+f358Cf6XjAZx/xa92MI9zgT7moSz5E7hz/7TmGksouA/Lcao h6x/9Z+2+v2nZT0o1H+aWDAXXYcShzAXXYd56CjmoaNWXFv96iFZD5LVo3Io0miksepREoAnqlBy BCVHULIKJatQsgqlqs77gehRf0Mi/tf6VgidFYR0tVfIAG692ot5tFAM9P9FtIEi1B4RIzEwPCmL aq8cALKqayDLXNmm7pYjcR2tpgNpOgm4JKljhUzVJWSBckBe0FnSAu2egu5CoN1TYpDqEkPU/WIo 5vIopDGgWJADuBTcS1Fd0P4paP8UMB2EBU4B10Hg6ZZD1KdhjVPAdVCOUp/GnlliM2jjv0RCM9fV UdTyE9SyFhJPhcRT8eRRPHkUpY+i9FSUnkpCUHI/2lwGiU9A4hOQ+AQkPoGn90PKE2IkKBrkAimg RFAKKE09gRr3o8b9qHE/sVL0n0d+UbSBfL4vhw+XQ8OvQcNZ0PBr0N5r0N5r0Nxr0NZrRBBy1YdI 6oR5uHziPIzWT0KOk5CjHHIsE7KR5oC8oLNkPfy4EHW3wPMLgfKkaAWhDhHtQr+NsOJOWPEkLLiT 6VpBvlvdBp03ignISwalIC9V3QnfaYHvtEC6k/CfFkh4ElY9CR9qgXQnYdWTGHupVBrKcqAsB8py oDwIlPsv6l969SAQHv2Mn0XAMzRfG/jSviYy+8F2JBAYeoGhFxh6gaEXbfUySytIE0EpoDS1l+jH +v9nxn7XPyXLP9tngtHqIbR6CK0egmesQ8uH0MIhtHAEmupFC0cgzSG08hO08hPYtBetHIJkh9DS IUh2iJhRyxHUcgS1HEENR1ADfeo9lDwixoMSQSmgNPUI0YlhuOMGJYNS1feYDvfj+f14fj+epz1m PxC8xnpNFFIF1ynoHRduyaU+f8GWJNkDLWeC8qFpK1ZqI1iljZBH1R7ymDpE+tUh2aU+iFIeOdV/ EiU9KOmRC5BXDLpcrSYWzKIjKPEuZtIRORmUqvah5Lso+S5m1hF5Gmg6xoIZqM1HR3G5FLGMkagP z+5CC7+TPcSJ53fh2f1yJvh8UAHyi0ElyJ+B/uxDejlQm/HUW3hqCE+8hRbfQ8khlBxCybfQ2nuo vxFPjOCJt1DahSsPZqZU/0Y5E2mOer+cj7QA+cWgUowRlyHvcrUAG7eDaoUIpOIctU+8HOk8pBXI qwRVYXxc6H9JvBL5S+GrV6u7xGvANyJdg7QZZVtArWo/MG5Gy33AuBkYK9DqEFrsQ4t9wLkZOCuA bzNaHiLRYhFqK1X7xTLUMpu1fhotn0bLI2h5EC2/I85H/kLUXoNyV6nPiCtwXY/7LajZob7CbfAK WhucoP9X0NIgWnqFxKKVngmt9PPal06oeRtq7mM1t+BeG2gtq32ihY+z2rOZ14xZ+DgsPASd91ML Q5ODWDnb1GiMSdETvQkI4oAAGiZecbb/qFiOFuYwLY+g5QZotUJcBmQrwF+j1omrwNer0WID0mtB jbh/HaRoAb8OaTdoAxBvVBsu6qlG1moltF2F1q4Efw34WuJl/qjH3WhoZeQzfSKC+wJFOAR9vQV9 vQc9fQSkQ7B/H1DuAqoGIKr7Qn4ZDj3cDEuMoM19qJVagNq1f8yuX0rr0eNYK9VhyNmIWqms0cxf r0HttUgbgVvzV2rnIXE9a+3SsRuYBq9mNZ5GbawWpkUju3MNa2OE+dBatLmeRLO7EbB/H+Tu4x7Y J84Dskr1brEK6Xx1JdAOcQ8cEVfiKQ9WS8nqD7RxAXy2+hHkPwREP5BLSSAQ/Q5yP0nc8DYCbyPo wRXECXoM9i3C6qBUTUBrg5p1/UPwuBPQ0RnWcgVrfQiY30LrY77fz/FDL6hjI0YuB5C41J8DTa2c CD5ZfQdoaoGkFnr6OfT0c7kE+dOQ76PvI8blnM0sMYLajzLZaqje0Cr1vDWgZq3/QksjTEtfdCyl cmPPAnpU7UMvO8pb7mHa1XrXCOR7jXkW9dllzGf70bOGxDrmaX3oXXQM+6bYhPzrQGtAdBxrA3Wy ntY3oaf1QxePAmUPkPUAWQ908Ch08CjJwQzSjxmkH+uQfqxD+oEKlkD/Z33fvxHIctCj4PPYOdAR lnrolazvV8Cf+oFuibgctEItBkq3uBKt1uJ6FWg17tch1caDJRgPlgC1G6iXAPUSoHYD8RKxHdQB 6gRtAG1Ui7/QHBDMx8kK6LBBnEP9hFmxDhbsYT4Cncku5p10bH8RetgMPWyWC5BXzPzgRWLhI8cu 9MZ+yLmWydmo/pCOXcDTz2eEfrTfz2YBkdqK9RNRbOE9xob5iLZ565eaKWPZ00VYG5RiTVcGHmMF pDoAzzgwYVRrgH+2QLpYbottX6q1MLRSw3q2NpL2MN1VYe89H1q4CgjGRrZL7dXhwN6PWhtQ61rm 0WPWmI8V8kI+VmKc+EK16sV6EgKvGUHvOwpr7ELvO0DMrC7a81cylEPwsWE+ivXDr/rZSNaF/I2w lZWNfqx1rKXoLNyAMaQRo6HWq+mIeAjrgDMTnhohprE5EU/2sbbq0XoDH202Mh+oxfMYdzDG0jGQ 1kbHh1akbcCD2Rhj7NV8jKVl6ZNrsJ/AHbQzgp3nClytBNG7DZitGoGiRf0Z0JxGqWGUwqoIPfMo xoN3UNcQW8PU8jF7DcP+HkrTUelJOjcQCSVPs7sYo6CpZbi3AnKv5CuQBoypzeOaos8dpSUh0Qmg XcGRajp9h5dkKwugXYo7YyMi5mJ2p3V87THMWsTKVG2A3hpYaT43jNdJcV3Hx9MWhtHLtB00PjZi VMVoNMLmhKV85loB/7wGvXEls8LQuBXWIK+VW0PPPXaIj9EvsXotvI7+CXqjY+YRbvd+uv5D6T5o up/pT6BYYdtmll/HdLITLd+Nuk+i5VPMU9qg7Y3cgndO8ELUz2eKsVLwKSKNS/cY6jbiKh9X+ZB1 CLIO8ZG3n468JIzosXsNBA38a874sXofOzt/nJ7UovTfO5GaePJET5MoFh+w+IDFx8/zuyect3UD SzewdANLN7B0A0v3Bc7buoGlG1i6SdA/e9ZGkvhOv5vt9B8HPQW+H/X/O5y/pfAT9D5+gv4u7Psu eRz8U8jrV/v4SfkwUA4D5TBQDgPl8D84KR8GymGgHAbKYaAcBsrhz52UDwPlMFAOA+UwUA4D5TBQ DgPlMFAOA+UwUA6zk/LQz52S/wIof0G9AygHgFI7Ef97p3UTT+roSdxYbb4L1OZDbb4vdPpr+bz/ j59RWdW1sqxOxd5/82fOq4xj551o02T9q1pq9aulsh4UqpYS4+dO9Z7mp3pP49mnsaueeF5lHDt1 Qk3leC4Lz2XhuSw8k4X5XfO8DfyMiduWeeAGyLnhgmdA/PyHBPOznw387GdMS+UTns7D03naOQdS es4Rwk4h8/gZx1FiQKkbUepGlLgRd26EJI9CkkfZKfyPx09iQj530jSxtXK0RqUrQj1FvLUifqqy n7dYNN5iEDtpCMLIpJ02HIc3j6AWtkck38e+hu5E6OoqVY07v7riO5LLMRcEXtJKma6Q42H7Hti+ B7bvoeshVnecekCOB9EaEpCmgNJA6aAMEK0pC2m2+pSci/R/iPv6uKiuO+9zLzC8zoRaagyhhFhC DKGGEEIJoZZFH8XZgVLWUL0FYy0PDANhGWooNS6xMgzzxjBz5wXWB6ylxFIXcRhG17I8PtRYan2o jyHWRWtYa13rUj8ua1nWNdY833PmzjCQNu0fz8vnfL73/M655/X3ds65cO9kA7TlHMRfAOhYXkGc B9AxFSD+C5wGChFvBLDHUmCPpSgCtn70fYUSOwwZ6zn0bOU/V50in2H7Zj8/6N75Ijh7kXnwv0N6 iS8q9kQh9aMXsY/9Gcb4IvaQ9Dz4YvDJAs4c2EvSs6AKuhWBawzgA06i9melFtIQf/yZhEp6JqFi u1H6XIfuU+9JXPYue66Qi/xXgXzk+58veIl8hUx+Dpm8LZ1afx4il9AT60GiQC0qazoqyp1O1PKi 1kHU+j5q0ZFRTnViD/cEzj4ialId6CXrls58H82CY7NYCT8DfSTkNPmMdGZbgKSvQNJX0MNXIekr 0vnt55D4FQV9tpwBfB5Yj/svIM4CsoGXkc5B/AUgF+28gjgPeBW0/6xHpX4FEr8CiV+h5z5I/Qqk fgVSvwKJX8EuK/R09neI/zs9OTAuHWRzpPPLRfpVuu5LnDgrccKNEmdR4qzEATedOWzyKey3c4FX P+qBZ6PrPtOcj639d9Hjy6HaQ04jjyd19C9phNA3fAlHUgl9e+85+kYveQEhHHvPl0gEeRlBRr5A qC98heRh75qPEMPeuo0lryHEkR1EwN6sAuExspt8A3b9XYRVZIgcgwc/QU5CHmMIj5N3yVmyhkwi JJJzCE+Sf0FI4niOJ5/lwrlwkszJOTl5inuMe4ykcE9wT5CnuSe5J8la7inuKfI57mnuaZLKPc99 njzDvcC9QNZxL3Evkec4N+cm6dyPuB+R57l3uXdJBvdT7qfk89x73HtkPfc+9z55gbvMXSaZ3Afc B+RF7p+4fyJZ3K+4X5GXuF9zvybZ3L9x/0Ze5v6d+w+Sw/0n95/kFe5D7kOSxxOeI6/yEXwE+SIf ycvJBv4x/jHyX/jH+cfJZv5JPols4Z/iU8hWPpVPJX/Jp/FpRMU/xz9Hivnn+QxSwq/nXyCl/It8 Finjs/mXyTb+C9gJlvNVfBX5Dl/NV5MDvBq7uzZewzcSHd/MtxAzr+f1xMobeAPpku+V7yU2+dvy t4ld3i5vJ6LcKDcSh9wsNxOnvFPeSVzyLrmNuOWiXCQ98v8mP0z+Vu6T/z35rvw9+TT5vvyafJa8 I78p/w0ZlN+VL5Ah+X35fTIq/1D+IfHJfy9/RE4oeAVP/l4RroggpxTRimgypohVxJJ/UMgVj5Fx xSrFp8n/UDyueIL8WPGk4klyVpGM0+9PFKmKZ8hPFc8q1pGfKdJxOvyfikzFi+SiIluRTaYVuTgN v6/IUxSQS4qNsI5fKjYrisgHCqVCSa4TLmYqlr01yq0mhYQMHQU8hPMeQnwSGAc9gPgMcE6KLwCX JJriKnAduAXcQXnaxj3gvoRH/vhYuB+WZkLcbj8ofSwGdTxLaYDbt9sfezGGY/HAaiAJWAusQ/44 4vVAtr/esTygANiMexjTMZWULmNjWgk6RjbOE5jTCcxnXxriS4Q7AY6cuMq/MXLAd3DE4Ds8NOyV Mcx5CymOZXmFY7neXcf03laGR95ZiuP1o/uPNwFjo/zxCWAamBnlPfd9mz2PfGVDJSOnh7aNnB0S EO8aOes55CugGKoeOT9UP3LRcwfl7vlUQze96QzVKFeP8sMjtxnmvJkUnk2+eI/St3rIN3KXYR5l KcZGFhgWQQMh46xmWErXM2xAehPSFtAUHm8vw0kJ1zEvilt+DK/1PmRYN8oDUcH0eqTXI70dNMXO 0USGQLoKNEXjaMYnYt9o1vCB0dzh02jvLGBA2or0edAXwUvZqJIhzpt+fNVo6fGS0T0Ma5BORrp6 dC8D5T/Fw9ELFB5+tJQhavQqQ8LoHYaU0fsUQw/BL8BT6kvylPtWeyrabZ7dvrWeAciHQpIf4u0j 4b6dATlAJncRpx9PBdLR/7bRPUNNkFkLZNaKWIe4euQyZHhtyIS0DTI/ivYoPH6MxPg2j8RDNybQ FnCMh9yAoUmkKSRZoq8HDHPeHAaflzDMe/MZplCWoh9lKaZBA8ei0F4Ure+NY5jzFlEcU0L2pZC9 CLlTlCNdgXQPaIolXWliWEq3MOxGWo30IZQ9tKy8jmHc28/g8Q5KGGYY9/oYznjHGDzeCYZz0DeK C95JhkveKYY70D2KexKue29KmJMwL8Gfvo8ywHC4hICOZo8qGJZ0OIFhSYcTGJZ0OIUhkNZAfyma oacUTujmQejmZejmtRDdpEgdLYc+lC/pK+jMkHQO9CUf+rJUvgLldwfThbhfhPsCdJtil4T50TMM i6PnGEL9zSTQAt2nmAJN0QoaeCt7lKeAbegZxkYPMdhQ1w1Ifup4L+h+YBY0hW3UgvsW3B/A/Qak RaRFpI8i7QmWv4myN5fsDTwppfgz0pcoYJsVDCmjjyhgi5kUnjTYJ0WGhBRfOAXu5VN4spAHhPix VgrPHt86z17Y8X7feo8esAABWw7gpIRxCWcknJNwQcIlP0ZW+6pGknyakbWw13W+smMKbyaF5yru AyPrfY0j2b5mxPtYXOazjmz3OUd2Iq7yOUP0TMGw5BvTGJZ83Qb4uk3wU9c9oi/b0+PLO64Dj02j +0esviPHrsJGgOEY6DbgUcNXNcBXSTFsfBVDwEeNedcwLIKmWLGWwYfIGOZBU8x4kxkkGaBsKsOc t4RhFn4FOJYAv0LRAN7vAe8H4AMGlvkB/9o47p1m8HhnGK57FymC/MiD/eRh7TiM+R/B/G8gfRsY QtqL9F3QCwC1t1NIP4CekRB7Sx1Vw3YaQtK7ka44PgieDQMBW5B4eDwHNEX9aA9spwd2cBK2M+5R YF2gSMS6QBE1eoshYfQeQ4ovhiKom7nQPeBYIngAeDYgDRxLQRpYufYMx0NeFKslBOZfgLkVjEaF 8M3EsJS2UQTLb0Z5iiS0ARzbi3L7Ue4oeA8MubHO9GLd6Uc8OHJjJA/6WgB9TYO+AiObkVYhnYE0 AH09gLXNANluo/Bchz5T3PJjRAP9bYQeNyPe53OGjMtNERyXCmOiCKTLQAPHffBBFHOg5+he6ES6 59EJqk/5FEE5Sff9cjmReXzsRA72UIdOEN/mEzJf2Yl8byZDHNKrsF7OQw7AiTVIJyPdjzRAv0HC 3sQk7B3MKPb2ZXREdkQ2UUTkRrxKHmPvSH5aViL7K5IoK5d9laSwtyPXsrcUn2HvGK5nbw5ms7cC 89n7gH+Bdj/F/ys/j3afCltL+LBnwzKJLOylsBwSH/adsAWSELEuIoMYIvJlr5JO2QbZRq5TViGr 4RyyWlkt911ZnayeOyxrkn2T64+Njo3mBmJHYk9x78RxcQ3cMfouIv8kff+Qf429dUXfPsiW3s16 AX1HKJwKFyGKHsXfEl4xrXifhCsuK/6RyBRXFb/0v8lC3wKVamqkmowbYS9jjCTMGGbCqP817B4J jyiK2EqiZFmyl0mMLA/jVWC8XyLxrI9VrI8ERa+ij6zGiH5K1rD+Ell/Say/ZKk/ju8BR4LnhsNN QAvhjlQjbgV0oOsRmwCbFGOffrhXoin6gUFgGPChPG1jDJiQMCnFU37s30CIaacflD48jTotS2mA a0z3x0foGGaAWeAmMAfMI1+HeBF46K/3PR6IAhS4hzF9L0FKJ7IxrQQdIxvnDzGnH2I+f30XcS/h fjgI9IM7G4iKlJNdkMMe0koMRCS95Ajx4Ox9llwgM+QGuUMWwcIYLoFL43K5Qk7FCVwV18C1kLCm 6iahqb5pV1OT1kp47SHtUe2A1gPKqV3QHtTeBTWsXdT6tOC8tkd7X+vR3gN1UHuZlgCl097Umthd vfaCdr/2HKhG7UVts/Y8qCbt2A9mtD5QFdrxH1zQngS1E7W3/4DeLdIOakt+MMnuitpNWguo7Wg3 j41lm7ZVm6ltAVWKdtO0e0GptBptkraK1a3XrtJWg1Jo92qjtHsI33hf29z4SFtGwjHefu0YWndj 9L2Np5AzrN2F3Grk1msn3vCi9GVtcuNF7RpQE9qUxkltIglD76q+e9oybVXjfsL3zfXN9y32PQR1 vfFe352++6AW+q713ei7DWqqcbZvpu/m/0UfEMXe4Cbs3W369vRbJFrWKmsncvYu82fYm8iPs3eN n1CcUvwDSSQct42j70bFkVsEdthXAmwDBGAXAFvpq5di6FRfi0RTQH/7oKt90Mk+6FofdK2vV0K/ FA/68TfQ1Y48PyjdN7xEB9AH/e2DbfXBnvpgV32wp75pYMZftg92Au6RPthJ37xEL0p9rwC1a2oD 9ecRt5CchqKGkoZtDSWN1xqExhsNuxqqG+qBpoYW3GlpaG3QIZgabA3uht6G/oZBhGGkfA1jDRMN k+yurmGqYbpBV5/QMPHmrTfvINyrV/Qm9qb0pvVm9Gb15r7jeefkO+PvnIEcPg353iOEX+D/nfD8 f0DW4UzWMibrSCbrOMj6FSKPeDUo8XhI/CvkcdlfQe5PMrknyQSZQJIh9yHyVOwwpJ8K6T8kz8Y+ gg6kQwe+RjKgA2dJ1v+nXjmynRxi+rOBfpcgxFcxP6WZ9Pup76UAaVI+MLAJQA1NwRsFb2x+Q/VG 2RvbNQf27Dp45ODQQOZADmYTy/+O/x1ms8gvwpvnReQRXlYmKyNhsIUdJFz2NVhEROyx2GNEFvv7 2N+TSHkFLCJK8RNYRAyziNj/Q61wqxY+vR2rVxx3mkCv2mC5bY8I0YUDMYR/C+uZLh5YTchbKkL2 7veDpnVJwFpgHbBeysPKqcuT0gVBcBbIsPaGH281As3I34x431J+KELz3zogxYY/Uv6AP99hXXbf P4481o9/bHQsKpRxElK7b6ksYv+cylg51g+rvx3AGqWrAigfGqV0s0Sjnu4AYACs/jIB3qB9hm/D lnVOls+/ddA/l7f84yW6g0v96w77ywL+vtHG3rQ/CHaftld7g589sGDS228ceGCy2G+3EZNov9sm M/XYF9riTIfsD9pWmXpEgvwB5BPTUVHWtsbkEeNQ/qS4qi0ZOWvaUk3jYnJbuumMmIoy51Am03RB TEfdS6gLes8cyl8VM9tyTNfFnLZ80y0xH3XvoEyhSRQL24pM95rOgb4PuhD5mW0lpkdiUds2c7hY 0iaYY8RtbbvM8aLQVm1eLe4CnQS63rxWrG5rMq8T69tazOvFprZWc7bY0qYz54mtqFUg6pCzGTkm s0o0tdnMZSjTZN6ONt3mnaKtrddcJbrb+s0asbdt0Nwo9tfcMDeLg8jfJw6jzAHR1zZsNohjNZfN VnEC+U6U95kPipNtY+bD9httE+wKvr2Z1TZpPgKOTZiHkDNl9mJ20+ZTYrou0XxDLFl2TTHfDl4T 6ZXNbkaXZr4rCsuuGbjO6rLMC2KLLtf8QLwp0RvYdZOFiE06pUWGdkKvpSHXckucOKyrYFc/vduy SpzTqS1rxPm2GfNpcaotk45W12BJFhfbmmit9mudaY5zbbPms8E5shnp9JZ8R0LbsCXZkajbY0kV H+os5lOOlLabrIyfA356jtHz5iPidNui+bwYJ10fSvRFMU7Hmy+jzdBrlPkaroqQq2gphAT9Osak qeuxFIk5ukOWErFfN2DZZr+tO2oRHGl+vdXttaQ7eF0C6mZivqmiW7ffkumIwnxzHAqdx7LLkaE7 aakW63XjlnpHFtVJRy6VvprooixNjg26M5DFbIC2tIizktaxefklSK3mW4NUPx2bdOcsrbCXaljK riXbcSipljpKMUIdRniGyfECnYXuksVEZ2Sx0RlZ3Euzs/RidlfNQ6JMd51KFj1Cl/w0+EP575fv LUs/ZnfHMij26u4x+j6j/Zx5RDlDrcxRTvXZUdEebhkW89tjLD5xsD2ecbUcOjAMbp8K0O2rLdvE ovYkiyBOtq8Fnd++jtHrLWOO3e3ZlgmHuj3PMuloaC9gfEihfGjfDC4l6tLAJaFdZWmy320vY/R2 y5RjD+hp2OmkZcr+wK/PbXPUq7SXMd32y0JJZdG+E3QiNJbSVaYBx952jWUGMrpqmRVl7Y2Wm2JT e7Nlrj6hfZ9lvj6j/QDVonaDecGxv93KaCel/XrVftD8wKGnnsphaT9sznaIkMKiuKr9iOUhPAO8 1pul1D/smWkf6uTrMyj/m2OodtU8oB4Mtgxf4eihNPwepQ+1exn//Tbll0Uipalnaw6nPsQxEKqZ 7ac6oxxH2093KhweWBD43H6W8blgiYZ8g/yn/tBxknoeR277+c4Ex3j7xc5EsVDS5DvU1tovd6Y4 zhjCOxNcg4YYetcQ35nQdM6wGvSYIQn5w4a1LH+d+ZrL157Utegaa8vszIAvaurMgp9J7nwEutca Lg5THXZNQEvDHaUYydmAbhvWmw65Jv3aC9npILtEyKukbY7KUZIp4zM49gDay/hMfa/zNvX2mAV8 rGsKmnzZftevsXR2rml40X2uGd2tJQ2k3t416/erdMx0pl2LoLPBmUxDHrVf/9iMMvMN90ljHJP1 YchaL3kMJgXGpYAm3+jMdVzQD1tVzsb2250bxPn2u52bHJfaFzqVjqvIKUXOQmc5o+ndB50Vjut6 0rnbcUsv61Q77ujjOhvsC/pVnXv27ELJvazkfnFev6ZT77inT6aS1ad2Whz3dfs7xW9W6dM7exyP 9Jmdh5zh+pzOAXjR1s6jYos+v9PjjNEXdp6sT9CpO8frM/RFnWec8fqSznPihH5b5wXnavR1yZmk FzqvOhQoed25Vr+r85Zznb66845zvb6+854zG3Xvw3fBjznzpDWUrVb6JmuMs0DfYo13bta3diqc Kn2ydTXGprMmOTyUdpbpTda1YrreZl3n3K53W9c7d+p7rdnOqrYSax5WWLaW6futBU6NftC62akx rrLp3ePGNTaL+4wx2Sa6zxlTbT3uC8Z02yH3JWOmbcB91ZhjO+q+bsy3edy3jIW2k+47xiLbuPue scR2xn3fuM12zv3Iv0YbBduF7nDjLtslx3VpF8HWa8n2z1B7N1ZbZrtjjPW2hO74UP2hFuc4SS3O NWVswn7ABi960JXTpqNWbGyxXe1ebWy1Xe9OMupst9xXQ/2J0WS7073WaLPd616nu8c8qpJ6UaOb +q72JKrnof68bZ7qtrGX+ahQfwU9715P9bw7O1TnocPwAPCWS97A75kHqDc29lsGu/OMgyGeWcEs /QzVT2M1oyvoKhzqpY3DtvvdBUaf7VH3Zh1vmXXnGvbB7+mMY/bwbpVxwh7TXWactMc791HZdW+n suveCd9yNuCNl9YdcQbr9eWAvzLcRo/J8DmwJr3PWubg9WPW7c5mXHc6m6l2QbeZveBaRa3GqoE2 Tlgbg/mT1mbnPv2UdZ/zAK4HcJ22GpwG/YzV6rTqZ61O6N5N60HsxJh89XPWw06nft56xHlQv2gd ch5uH7J6ocNquk+jV7T/0HrKGd/BWwqdRzqirKcd+g6F9axzSF+Eazy7ejsSrOedpzoSrRedp9n1 LN3L4cp8sv/akWK97Dzvn1dHmvWa82JHhvWG87I+znrbea0jy3rX2diRa13ANcv6wHlDP9xFnLfZ 9W7Hhi6ZeLNjU1ecc6FD2bXK+QDXNc4H1L6+WdVR2pXsIh3lXakuWUdFV7orrmN3V6ZrVYe6K8e1 Rlpbh7ryxfmOhq5CV3LHnq4iV6re11XiSu/Y27WtPkq3t0sAvb9rlyuTygvaS6/5IXROh76run4D rvW4WrqaME6xq8VV6N9Fd/R0tbqK/HzuONSlc5V0DHSZRF/H0S6baxt6dzsUHZ6uXpfQcbKrH7S+ azDY2njXsGtXx5kun6u641zXmKu+40LXhKup41LXpKul42rXlKu143rXtEvXcatrxmXquNM167J1 3Ou66XJ33O+ac/WyNWKS7nNcNw0FXQ9dc22CjRe30fMC1g7szF3zWC8srkXDZtAPDSpLq5v375cM ZaYed5Rhu3m1awplelyLNN+toHskdwKlHYf8ZVh+IvIPId+/7kCT3Sl+2rATbaYZqmxRYrVBY1PA xjMs1e4M7DewNzCwvQE9m7iz6CkAWjHFbKc5mL+B5rs3UfpNf5me0DULO71ZcY1hny1B1BkOmI66 plGmAGMzoHwi3Se4lRjnOMaJHYLzdvt2WyLmZbWYnLdZfinNd5fTXYS7wl/G4LSliKmGg7Y00WQ4 zOgjlKanpKAOj5mHHCmwSuLeDT6fc6v9+szoBkq7FaH5bfO2DJEYhmxZos1QYMtwzRm8tqxv5RhO MT+TQf0M3Y1g/NiNuPdQ2r2X0fsNp225dGdi24CdIVYQ1zzVcLde12PbJOYYztqU2EuH0LS8a56W d+uxZ7tlf2A4byvFySjEX1HabaG0On1ZPtZ6t0jXencPW/dn2XnKHUobsm3l2KVctFXghIUzIPJx 2nLNSHuYy52J7kOGa6Z77gF6/sKMxmy7HSmGGzZ1fbnhtm039gZ3bQ3uo/BsdM9Qij1DPXbCwR0s PT9CP2FfGA9ot4fSNXeZJigMC7Y94qDhgW2v+xD8dirqslXASGz7nfHdC90Peohpg/2wM96Uaz8o trbftq+GvyqyJzm9esG+1qEwTtnXdVd1POqad/X7r8Zp+/pujXHGnt3deGDBntfdbJy1F3TvM960 b+4+IO3w8+2qboPft/ht3zhnL6svl064/lOG/1QbemL1n1XZKdU4b9++4qzKVnDjon1nt9X40F7l WmPi7RrHPVOUvbHbaVLYm51DpgT7PuzTWDumRPuB7oOmFLvBley3X78l0n67D0unaeg88pkmL/O3 wZF0Hwn1kOykbKNnZNeM5Nmox5jyn6/9fslvy3QF6R6iK0j3kGTpzAZNaeb4bq8pw27tPuXXEFOW 3dl92rTJfqT7rPR0gj0xMClN+u7z/qcTplL7UPcB6VkEO/Wbyu3e7oumCvsph0J65uA/3fufKrB9 pmmv/XL33dATpUSz5xV+CzLttp/uvmxS2892XzM12M933zDtsV/svk21oj+Rfp+OfVGShHxRkmdf lAyPKozaTiLYVyST2Fckn2ZfkUyNao7aR16IejvKTHLYFyI3si9ElsY+F5tJtsX+S+xvSQX7Lubr 7CuY30AfL5FU8kVCyCZSSRLJbvIdkk2MCNuIjdjJa+Qw+R75KjmCsIMMEQ8RyI/IGHmdTJJfkK+T 6+SfiZb8htwh3yKL5CPyNxzPpZMOzsRZiIdzc78go9wH3E3yu3BN+Bvkw/CB8B+Qj8LHw3/MhYVP hb/PRYffDv8t96nwxYgw7jMRqRHPcJ+TmWTj3DOyCdmPue2yd2XvcoLsnOw97muyf4yUcf81Mjry cc4V+dnIZG4g8unIt7kj0W9H6/mIaGO0yMuju6MP8o9H90UP8U9GH48+zz8f/X70VX5L9AfRi/yX oz+MSeBr6d/W+LZYRexjvC52VezjvD52NvY3vCXur+P6eHfcgpzjfyJPlCfy78uT5Gv5S/Ln5M/x v5RnyDP4a48pHlPwHxAO3NGwJ670W2pEiAdWA0nAWpIorBaShLXCOmG9kC3kCQXCZkEllAnbhZ1C laARGoVmUPuEA4JBsApO4aBwWKiiX1FkEiZRG6M2Ej5KGUV/E4Mnq/gMPoMQPpfPJRyfx+cRnv8S /yUSxhfyG0k4X8QXERlfzBeTSP41/jUSxX+VF0g0/zr/OpHzu/lvEAX7n8V4/g3+DfIp/k3+TbT5 LX4v+TT7z8XHwfVUskb2nuw98gTmNENm2czY180qWsnuitYKXYWpwlbhruit6BeiBEXFYMVwha9i rGKiYrJiqmJ6x3zFTMUsUhMVNyvmKuaEhor5isWKh5V8ZVSlojKhMrEypTKtMqMyqzK3ckPlpkpl ZWlleWVF5e5KdWVD5Z7KvZX7K/WoEwyo5w8pUtgUDGopWCpFYH9lD3CocqDyaKWn8iTCeOWZynOV FyovVV5FieuVtyrvVN6jf42MfAfcXL1M2+lX3rNJI3Q3j3wbml/ItP0voeUeUgw9/xEpgZb/gnyZ zCGUMh59JfJzkc+QsshnI58lr0U+H/k8KY/8fOR68tXIzMhMsiMyJzKHCJF5kXnka5H5kfmkInJL ZBGpjPxaZAV5PXJn5E5YDcf+2ke5vJZ+qXKHBzgpYZzF+TuGdnh3nNpxGtezO87vuLjj8o5rO27s uL3j7o6FHQ8EIsiEOGHVDq+wRkgWUoV0IVPIEfKFQqFIKBG2CYKwS6gW6oUmoUVoFXSCSbAJbqFX 6BcGhWGkfMKYMCFMClPCtDAjzAo3hTlhXlgUHtJv/kVpo95k38eMWcatbyNkk/+F8DL5NUIObP+f yRfIbYTcyNLIUvJK5GuRr5G8yKrIKvIq4eLuy+kvq8SRdPpt0GrMrnqccLU0PgOcI1xZFXA37KVq T+2h6pO1AywO0OO1R6vP1HoYztWerL5QO85oeu9S7RlWjqYD5Wj6au25Ze1cr72wrE3aBi1zq/ZS ML5TezWYf6/2OksH6Pu1txgduB+oQ8cTKEfv0fZpTEHvP0L6UUi/oGvCMcZHIeVWgtZbCTqGUAT6 W4nA2EJB5x7gS6CcNC42lgBvAuOn+THSWBEzxNeeXAbUCyA4Rwo6NjpPxDWr0Tf4w9qicwj0EZg7 lRfGx9qgacrLq/46rGyAfwEZhY5RaqcmqfZOkLcoF+iLxdJYatbW3mPxutr7rD3alhQH+360vL/A 2Fm7kC/jwfraRx+rH7Oi32xNeE2eJqamQBO/bL6hc/lDY6WxNJbgmM4spdl4aDrAHzo3KabyCE2z ulQnA+UDtkDvSbZRs1mzmuWfWd5XgO8r5x+ct2f5/IPpgA4FZIu+1D5/3so4WAZ91qg0STWHNY01 RzTNH9OPT4jVY3/e/dByH+P3nxGrJ0LSK/l8Zrm8Pimm4whNs3n/kTjAl5W8Vk/6+fSn4j/Fx8A8 luk+1YkyzdqArdVs16yr2alZz2gpDvpPyZZrqjTZwTIaTR6zsUZNQagfrmnWbK7Zp1ExngX0kfZ9 QFNWY9BsD86Rztmq2Vnj1FTVHNRoWJ7kH5gPGdLsq/FqDjBdDOgk7e+UxlBzWmOtOatxsrkEbOu8 5iCF+mZdq3quTkfLq+frTOrFOpv6YZ2b6mstX9fL9Bb91EbV9dcq6gZrE+qGaf2grv4BGQdtMSS/ NhF9ldQl035qU5b6CN5Pq/PVZtSNLfMfFz5BN+OX2/bHfMNKn7LCLwX9FvSoNqtuIjDu2ty6ydoN dVO1m+qmA7wKjuXkcj8UukbVXNQcpgiuewGfLKVrLmuO1FzTDDHc0HhrbmtOsf7vak4zLGjOsnYe aM4vW5uonyCai2qZ5nLo+qaO01xja24AUnn1Ks0N2o56jea2OllzN6iPK6BO1SxQBMcNHVKnax4w PcisI+qcOhnTIWntVufXxQXaDtiPurBuFWurqG4NlS2Tb2gf2+pSqR6ohbp0Ol86R/Wuusxgm9V1 OaH8UtfX5aub6grVLXVF6ta6ErWubpvaVCeobXW71O66anXv1++q++vq1YN1TYExMH0IyDM0Xil3 zyfHK/UrKPsVa5F6qvaoehpyC9W3wDohrZfL1qIVaxLVV/WMX1//YLnA3oD61pmlvUIgVs9iPwd5 B2K2v6Pxn5jnJ/laJsspvy8JxEH+rdxnrFz/Av4HabbvCYmDe5sVPmlZ/MfkEmKvrK2ArQV0L+B/ Vq6rf8RvrJQnazvQv2TDlN/fufWdOx/b2yKuVdbNqIfrWijYHgYI+vuAb6CgPEH7taV1s0Ebpm2F 2GjA/oJ7YzoeaU9C14na8rqb1N6p3bO+K+rmqP2Ftle7u27+Y3vvkD13rbpucdl+WfJRQX8k+aLg 3pmOuaHuIdMB2HHtnno+cD6o3VsfFeSbNM7a/fWKoLxC9q61Yn3KMp2la1SAR7Sevj6h1lKfSO/T k3xUZ1QXIbEvsl84uRN7h9Bf3Xz2/+2Tlogw8hF7ovI6e6LyddmE7F3OyZ6l9LBnKf3sWco0e5by K/Ys5dfRb8ck8IXsCckMe0JyhT0h+SV7QvIr9oTkt/QJSVgifUISto4+IQl7jj4hCcukT0jCXqRP SMLo/6QNkKNLzxG2uknRVvfW3q39Wwe3Dm/1bR3bOrF1cuvU1umtM1tnt97cOrd1fuvi1odKXhml VCgTlInKFIQ0ZYYyS5mr3KDcpFQqS5XlygrlbqVa2aDco9yr3K/UKy1KUdmjPKQcUB5VepQnlePK M8inYUA5gFYRlAoWkFLup6A0BX0mELWD/n/ailPuXsjlb8jbON8OI7zCTrx55D0yjTPtJYQvcj/j zpMN4RfD3ycF9PkV2cT+B2/n0nw3FpK1WxRbErYkbknZkrYlA3EWqKwtuVs2IHfTFiVC6ZbyLRUM uzfu2qLe0rBlD1LluO7ZshelEraUszHSZ0OPs/d+CUkj9Cvz6xB4nKrTSRjJIPQXGdaTF0gE+63M SJzOc0k0xrSJyMlmBAUpQniMKBHiiQrhU6SEfBkj/QopIwnQvO1kNfvBrETSjPAkaUVIIvsRPkum EJIx9/fJU5yCU5Cn2X+1tobM9UBYluqw6ohqSOVVndoYozqtOqs6X3hBdVF1WXVNdUN1u/C66q5q QfWgmBTLVM3FccWritcUJ2+s2ugtTmU4UpxenLlRVZxTnI9rYXEmShUVl2zcuTG+eFtxZuH1zac3 NhYLGzXo53BxuuoUbbVYhhaCobi6ONUfNqrQRn1xE20lEIozpdBSvAs1W1XNJQraFmhTsa1YKF4D +hTDKdV5KdymoVhGw0aV6jLwAONJxii8G1djBoKqsVinOo3xnC92F/eqhopTKTZ6Vf+bva8Bj6q6 2t37/M1MEmJETJGGJMX8GTFGGhHIADGJKWLmzEwEihQDRqAYUxoBIyJSy+VyuXyQUoqKlMaIFBFS ys0FSjFGwIAUMfIgpohIaeDDlFKkmCIiJt9a7zmTTCaD0N7+3Of5yn7We9asvfbaa++99j77/JBT Tf6s9qwjvdrCWs9Gz+bCbZTXZFthaibvmFrIu9a8YhBb3+7ZQb00iurMBFFtqLHas8ezn+0GaoHF ALEPRJ6DdGwgq0z7qBabPIc9x3IbPQMLD3hOetyeuZ7TVPc5zwXPZdQPH3JTUH9w3USmYjo9UQX1 3FrqUeYCxO2nkqxVWG1WwbduFE5uVnkumNO6+B9EyCOfzTVmtLne3NThYRCFk7PM3Irxygwllpt1 PMoWwQ/uG9t/s1deTF6t2cdMJGRKoX5KKqw1++c10K8B5qC8Seawwnoz3xxZWE6RcQBxmmn6qB9N sj3GHJ8X5xlhlnAfFm4zp5rTuCfNmeZs8xlzAdVKY2guNpf5Fb/TXOGP9vfy9/En+lP8/f0D/IP8 w3x7/PkciYGR5Br8I/0+JnOxf4xnoFWC8/zj/SWInUCPBnpvn6cs0KrguAr0gn+qf5p/pn82R4f/ mbz6vNKCZv8CxOoF/2L0BfVNXk0ejW1ebV6Mz/BF5dX6evp65sUhlfp6UxsW++J9SXlx5jKyuiev MPc4z7e8Ql+6L9M30Of20ez1jaDVoIL6qtlzOS82L5ZyTO82ms2abxRZGeeb6OudF+ebkjvTV0bt qPVN983yzSWa71uUN4kspZPVGN9S33OFLb5VvtUe4Vvn2+jbnFft246cHb49vv2+g77DhdW+Y76T vtO+c7T2cLStpfHaZe41G81DNB+m8Ayk30fM4+Yp8wwdz5sXA/1F49rm1bwRFHFteRF5a9HvmD3e mMAs8sZ647z9vGnUt9N5TAoPeDO8Wd4h3hwzGlTgLfQWeccWHvXkdhDmtrfYO8lb6i33dove3OOe EUw8Nt453nmghd5Kjh3vcu9KxJDNcxR5q71rvTXeWu82b71nu7fBu897gHy/GBhXtuht8h7lWelt 9jZ5etJaydTbijtvi/est9V7yUe2aN6Oy5uUu2v6IF5t/cv8K4iqfBd8l71zKJKrC2v8awqbPMK7 zUMRSVFQm7fWv57qGUFxNJ1X47xS/yb/Vn+dfxeNegTJa/Mm+ff6G/3U3/4jnlX+42Y+zYQ2/ynf RJKc8Z/3X/S3+UYUaUURRTG5bbSOrcpNLIotiivqV7iWzgfVPBa8OhWlFWUgXntjpcdKSWeOVorP UUVZRUNwLpxM572U/w77KGrtVFGOu+f8lUExPEtIol7DMykNpOQe7s7Oyc4ZnktpBCWT0qjho7LH Zo8dPo4SyyYOXzR8yvCl2c3ZzcPLKE2nNIvSXErzh8/Prs3mb+AozgnOifw/yMQ94lvUr/cK/vK4 h3YHhrifei+S+vlBcYOQUWeiLsAjPPUqpBExD9Exh45H1G8WZpmNhUOIsmxiPoeowKZCoiKb57yx tl5BkB7/Lg6xMynEZpGtUxp0LA+SV9i/A/wcmw/kB8oUBukV2faLbCoNqjO4XQUheqFUGoYqQqj4 CmWLw9CkMHUGfCoI6ptg+ZCg4xC7ncFUEETBbayw9QM+Ftq/S0PqKLLHq9i2UWTrBspkBZUJjFFo eT7OC/KzNOQY8GWhfaw0O2MjK6TucPUFfC+3j8vDlA+tdyVRNdHaED+DbYfztTTIl3DH4qBjod22 Kx2LbJ8D+gE/K4L8rglpf2g/hLY/tN2hx+D5VWTXFZCFHrOC6qw1Gz0GUdQVxvfvebxSv1/rMbSf v2q8rnasvYZjSB8H+ulqx6v2Q6j/gXq2BY19PVGDzTcE+REcy/uC8g7Y/dRkdl2HjxI1m51rRmA9 bSE6G1Q357USXaI2CFsWWB+orKcnUW+zcy7aR088URJRetcxpn01iPbjjWaipW+mEPUnGmAiFs1B 1pHrMYcR5RONtNsXiNWvmotBctS32a4nqI5AvukjGhMypl8Vm1eLtdA1Jdy6VG7FkTm+02+zhGgq 0TSz+7ocug4FnS88Ay3qOO8F4sT+7XET5do0gsi06qfrF4vG2XYmBpWzY8EzhajM7HJ+80w3rXNu gGx9zyzbzlyi+UHtDyHPIpsCfnMMLbV9eo5old0/9rnbs7rTdqDdnnW2rY3W2GJ8g+vYbvWVZ4fV Xm6jZ0+Qzf1d+8tzkOgw0TGik0Snic4RXSC6TGOiEDmJokPGpDjM8UrjfqXjta5xOWbnuSPcuedK x3DxGk4v+Lwc7jjWHu/Q49Xad7U1N7CW5Jjd+y/cMdCmqx2D9wfhjtc6PqHrwZXOmdd6TisOqj+w 56P+Lc0wu+9teV2YSdTLIuxhVobUG7wPJPvmbLNzDpebXeZoYP517I1Lzc49CZ0nzGes+c7zHnUv sOZfsD1zcZB/IbbZrrksqF22/eD1KbAWdeyd2ecVVj7PY7PK7NjjmmuC+s3201wfJk54Ha8zu8Zs TlAfcblNRFutfH4LCl/VFv/d7tvLpfwVXxElo0WOEO5SonKiCqI5RPOEuCNXiIzDxC+0qZJoOdFK omr7N9NaohpL313bSf170XGbRcx35JOuu94+NtjyfUQHiJqIjhI1279bbP4sUSvRJYEhgk7Ap3qb qJ6hhmV3aBRRzxDf68PT0N4ixx3n7udOc2e4s9xD3DnuAnchpSL3WHexexKlse5Sklmp3F3hnuOe 515I/Fh3pXt5Rrx7pbvavdZd4651b6NjvbvBvc99wN3kPuquva3F3Xxr2a1l7hayd5ao1N3qbiXp paDUwu9/dn8HGN+T1/Al+RvxxfhYfDH+JnwrPg5fie+Lt38T8fbvbfgy/B34JnwWvgZ/J74GPxDf gR+E78APxhfgh//T65Oyp7TepN0ubhUie5kQ6REWZa8gqiJa0ykLpmB59nr7uCm8/i3rLXn21pBy dZ2/kb/J5ndZNrPXd80Psnlrdp/sxJCUEsT3D+IHXEEeJvFfJsE73sI5yvltIfGOt453vCPwjncP Z4XzSdHbOc85j/p+vnMB9f0i53+IxMj+kbeLfpF/iDwtUqJ2R+0WaT1ie8SKW3r07tFbpP/D7Eqx UWzufBrUf7bwpOUG0oAFnTz9eib4V/hklRjwDOsOWGxR9/yvshekMSVUk+8hKs9RXxhKtfI6Le47 ld0iXnlLOSVuNp4wnhB5vIaK/MhfR+4Q93T8taQM+68l3cHflqeSFAnKWmW70JU6stIH2nG2bSli wdv9kTpIyNQByPsZI1mXYpAYFqQRK3qmZqSWZy5PP5rZkBqX2o9SAaXY1DSSZ6UOQcqBjRX8Vq7y ivIKefAL5Rck+aXyS6EotUqtUJUtyhby7zXySac27RVOtCaC/HtdREa+QV7G0IxbKPfiLl6RuF6I FJplmaVXofIr5smUBcKTsi1lW+ooSvspHaTE/OHUwylFKUXMpzSlNPFv5FFKKadUa6VM+tehV37l lDoudVxKC6XazsRlu9i09YIT+VYeIKrjYOp+qwzrZuZm5qYUZY4g/8rhL1tYm2na/pVTXmbAq84a mKcEf1KPoV2jAl6QFvs1kJI7083tTqmg1GSlQBtSJ6ZOxDj+VPmpEMbjxuNCusa5HhSKa4JrojBc k1yThNM1xfVd4XI94npERLq+7/q+iHJNd80QPVwVrifEddccw1LWyIsY7wravYikdddOGSOJaEXM 2BqGRlqUfISO6+3jSCEzrKMnaU3S+OSc5PrkbRlxSbuS65PG0+/65IakYRlZyTlJVSTLSW5Ibsgo orxlGUOSS5NLSTqbaHzGWCozLGkYaVDiclyajgX2kWRJW4lKSHIoeV9SCZWyKbk+Iy6jlEoMo9pK SbfU1gsm8i1A3X3MyGAfk3YRT/4lbyMp/KMj+UZ5ccE+dfpDEtsfbifbTVpmE/t2KKNfRlpyQUYx WS6htItqLCQqINkkKlWYUcGjpCxRaI1WnleeFy7lBeUFEeF6wPUARUCxq5gi4GHXwxQBpa5pItr1 mOsxcUPkrsgG0Svy08hPxdci/xL5F9E78rPIz/jrJX/FGucjmkI0DavcAPy/k3HCTb+K7JVvAPRo R4CVqyBIbwBKpnfoKbQOoV7UEo9aEvgpg/JTinOF4pojXSDSNUS6gUh3INJdiPQIRHokRXqF6AGL 3AaBNuhoQzLq9omx8Nqq+5vwkd/FGEfk7pApIg2eF3TRY695Xe5lyzo9DOf/39Pvzv6uQd1ZkFm9 LcWOIFmj3d/BetvR21KU27Ir+Rv5/xRJHEO9OYZQRqCMRBkFZVSUcULbxc+OutcGe5GwFP2VYzid WrLQHps7IduOd2lmdpGloTcmdpEtQ28UdsiuzY9/fW+F6wv+evd+7Ar68F/7T5wtyDGQJ6EioSgh LnE6KCYhjo/EtSbOIr6COCt/LqX4hFbi4inNZR1K84GLKMUnljGRdkWoxQ57yGFLwXZIt5Wk0+3a 4qyaqS5esVTXQ66HqM3lLopI1+MunkHXfG4StRhB+xlnfBTIk1CdsDahJqGWcFtCfUIDpX1EB0hW ndCUcJSkTZTbnNCScJaoNeESyasTBSfKY/0a6AanrhYD9prodzUssZ0G4htIspbyWsjWpUSD7BqJ UcCeib15lXCVuGb+rS3smw7yxJfGl/dtjC+nY0Z8BR3LCecglcZn9Z3dtyo+ixLLreO8+IWUU4mU YWvOIZmVSpHK+x5CCctiwF4WbFmWylGmtO96cOVkq5x+LwdZuBAtnOya+lecPxRan2huymH2PBzI 36uQA+QgbrlM7yJNk/3EGpL26iLtKQ1RSb/bgqXislTELPrd0kV6SpwXJfT7YBfpAdFM64AUdUFS XkcG0q+1HbJrWR96KquVl0nj58paOiO8qrxKO+oapYZKblI2UZ9sU7YJB/XJTuFUGqhnXMq7ygFa Pw4q74keyvvK++I65bByWMQoR5Qj4nrluHKcbJ5QTtCasT1yO60Zr9Nu/Ebajb9BMRGIJ97b/xi4 BPgCcBlwOfBZbpHsL/kezSC7RXdBVijpvCGTusg0Gg0pY7rIkmQm/brcRdZPxgX1sCXrJfvQr0PB MrGdRojPTcGyi+I8zk3BspPiNP1a0UU2VzTRr/ldZJvELpzDgmXP0ZWkFOO7yMrFSvo1ootssVgg Ov/2rSXrhbNIYoessw9/jEjmkRZYnSVWZwWrs0qrcxmdzafRGu1gbVdpUL//BJISYHHQSCyxx4Pl j6J2vuJTRD86R1n1DxKBa0Gp1Np6jGXUu7OETm1Mojb9m/55xDO/v5JJ83qAMoD4LOUBigr+Zkv/ 6LjokeI2GpkYGpncf7mn/7+QIjR8vUfIP8vPaI3+XLlORPT4Ivrr4htC0ZxCp0D/V/v4b/o3/Zv+ daQIj7CejZWIqXTdws/DvkE7gl+Km/EdsVSxh/YRaeI4pbtoh9ZMZ8aTlAaLjykNwTfFssUfKbnF BUpDaU/xOV3xfkEpR3xJ6W58cSwXXxzLkwbtQvKlU7rEPTJSRopv4RtkI/ANsnvl9fJ6MVLeIG8Q 98kb5Y2iUH5Nfk148G0yE98m88q+sq/w4QtlfnyhrEjeLG8W98tkmSxGyVSZKkbLW+QtYoxcJBeJ b+NrZWPlCrlCPCBXypVinFwlV4nvyCpZJcbLalktHpSr5WpRLNfINWKCXCvXiolynVwnHpLr5XpR ImtkjXhYbpQbxSS5SW4Sk2WtrBVT5Ga5WXxXbpVbxVR8De0R+Zp8TZTK1+Xr4lH5hnxDlMmdcqf4 Hr6SNk3ulrvF9/GttHL5G/kb8Zh8W74tpst35DtihnxXvitm4htqj+MbahX4htoT8rA8LGbJI/KI eBLfU5uN76k9he+pzcH31J7uUdCjQMztMbvHJfGDjjveve2dzGDetxiF/Dw0+rvR/FchQjXwXm7k S1+hkQ2N1V+h4YbGmq/QGMoa0R+HaPC9mz42Cdwp6e5rV53hYb3tqpMT1t+uOneH9birTm4Yn3mn Gg9Nq115QbmW99118rvqkPfdde4J0VkdRqcgRGdNGJ1vddUh77ldfJ3CO9w4PNkQNPPD9XSo1r2w UHEVrZHQeuIqWvdB68mraPEVoLzuhpAej6XrAks3FlqesH0eqmWG9ERFWC1viNYTYbV8XbXIw3Ba /hBbT+LKNrZDzxqhojDed9e6P4z33bVGhfG+u9boMN531xoTxnuev5LiSyWKR5wJ8e2wUdFdb2zY uOiu90CYMQ+nNy5MBCmk1w/azPWG3nfCjnt3vfFhR7673oNhx767XnHY0e/doSltvQlhR7a73sSw Y9td76FrrLckTDs06AU0rTh4OIx/4fQmhfEvnN7kMP6F05vSzT8pIkjXh7v8+BaN9bt9VdBvXdBV jQhcrXe5V+c6KETEJuFxHXc1uk4RnSGsouN510Xi21xrIjTX+YiIiJiImohYV2NEXEQ/khx3nYlI i8iIyOJEJc5QWkO6aVai/OMhFjvskbUYssCWOuxAr40kWZQ7hHQpReRQio3gM2/gmcW13o1slrFo If+vUOHcQXSY6BjRSZs/TXTOPl6w+csWuRQcPc5GZ53zENERwsV0PO48RfwZ5zLneeIvOtuc512a s84V4YohSaPziCvWFefqx4lKHKG0zLmMZEiU3xhisdPecbbFljrtQO8M2e7nPO5KIw1KrgxKmivt b3xOc61PUqPlKPTedHET9cQiIRzFncS/nau6UkAe00J01qZWokuW7HoK1usNoijSW91Jtk0P/yUt RytRkSPNUUlYQVhKKc2xkKSXnIKOC50GpSjKrXf2dNQ4ah3bkNJszTSSWWmSnYItdthjW2wpyE4a 6ZWSZBvVW+/sTVjhaHA0OOMd9X+/ZyZ/S98bNOuNjUHEvyeGEMvHEW0m2k5E0W7ssYn5/UQ0xw2K eqMsiA4j36O36C3GLMImvcboSXiJ8CylGiOKcuYa840oSosoLdWbjFzjOSPTGGi4Oek1libpZlqJ rYVa7LQHW2Sp0w6VbdHPksxN9eYaq/RLdBxBabWR+8/ue3w97JLofPbBZwRnW3lbVNswUDnRsL/i PivvkyVGk++J7m3H/VLcI6UV+dLELxu7rOVRwnHpsBgQRrownPRi5jVKqVVtH/9DJNSKL57s7sMX fw7n2RcvhZN+XniN0u61k96FaeFKXzgYTvrpyWuUhq3pYnVYP7Ww9cdeo5T67/KyMOMd1v8vBoYd 7xHXKP3HRcG/VsI988dwfXDZG3bEHrpGqdB4/yTaS2nPlKLx34E41Xae3xvW+VndKZ7LclfbIV4x WCL7t5VzLrCVUZwztrEFYxQQfNsw8NOheQj7OcFrPr8p0Y6nXYSTSNKvbQflPofc/kANOIdRccLD zcCVQDwllDeAnwS+Ffxe4CmUyoR8KXA/JGORew6SXZDEgcdeU+ZAkg/+OPhngIuAKcAy4ElgnV1j GmE1I/mcBvvxqDcNnqShRYxroF8N+6OA2xhVPEHjb9YRjydiqvXcbjEj9Yvl53XCftOF+pp19gGn wE4TeAWI52faJiDeb9Ss9yisZ1iz0OeHwR8Fjzc02vD0UE1sP8StY5St4MeCXwPsz6gq4KcjtwpY B4xDbg34Z4DrgMshN4HlwBbgfCDq0mLaEVdGK6MjE/xU7ltL4kyH/CKwDPgMcCyii//ii7B4vRqS 45CYkGyGZA54vDukH0W0H4Z8KjSdkO8FXwd5K2J+FdDAXNiKeK4ElnNbjP4sp92GVFfwtQj1WAPx UbacUDkLfrOD/7bLXgft69V09l8dBkxkn5VFwHXAs4zU22ynHDbngE8Hn2PZt+uK4bhlFJcsOfum HuJZ5kxsWy2ksZRRL2D/tVXcFjWKURukz2ObVht51uv1iJNBnEujxpK9PIu1mfo5stbCOrQXYp1m lstduhX5z2GsGwlPtP+ZcAOiKI55ichUWu1cxsHQWYKIxdyXeyARbeOJx0wknUa0ji2UA0dDcw34 SnteTMPso92GMofvIKkf8fxS9rfNB8/6o9HqGOZ1xLn6hPg54VZrvcJ83MWobkW9gnktEppT+b1n 9SN7TeN3d9qdiTRHDnGEtJ234oTmlmz/s2Zwq43PCD9x3MEtNfiac4PezP1goaMno5HIOpyr/onl ylaWaD+E/AQkQuPR36OVEG9q6Yx6KeQPUakElsjt4KMZlXRLX89hHX0K9zZbE/H6ONbXKba1HRrF rf6wvoj4d5jXNumFhAsZ9edYU3+ZeeV/Mapzddqt6TshGcroiISmF3Kh/YbKPgqbO7W7iP818+pH +n+QJAaa02DzCdZ3NKKUFzUegv371AWEQ9X/TdhPfQxlyU9VV39ImKPfTViqMm5SyWdZpb5MeFFd RpKP1Xria1HLBfU2kvwGmKg+znbUYZDwqvKwShGu/FR9m/TrtI9JslutIdyibqGyK9VNxD+vVhF+ oP6S0K/yOwFCqQLWMsqNZKFE8ozYoKwlne/QXlqqknnlMUhGKHt4ZJmXlZCvUMi+/CHXIpdCpwry d1lOmmRB+ZFq8fUsZ14ZDPkJZSuQJFo8I/Fc9oTkWfYkeCGTWF++yOMu/xP8SeLPKkWEMxSOkAsK n53vUj8n/Iak9VA+Ir9H+E14lQKvRsvfo+zvYfMT8LSKKlnyNL5a+ntuEcvl3YpG8ghofgbsJd9j pPMh+/AeLPwCLTqJUpshr4F8HfFZsHan8iHh+5Lv3tyEfruRY0PbhPVnkj6ccICm8EqFaFmCUZ7F crWGecOBmHweMTkZuc8CX0WpHyAmd3FMUkSxPAmajeBfROxNoXVUarryK+LvUO/niNJ59RjPnqvF uk7YrNLOR31JfZDXB5VHX3Dsabr6Y5JgXuiHEXVvACuVTwnfQ+x9hBhbwnLl1+pLhIsR7TtUWpm1 m9ia/iIjxSHjCeD3IX8WPqxga3In66tJ8HOVyrNjl/o6WeihpvIoMKqD1a8R/yn4bwMvq7yyvay+ Qvgr2HyazktcO6FWr9IMVW5T36BVaxXO+zG84rX3AQ7iHUt7BmNbDSQZQMPez/A9tOv0X+PMSNeI 7ZscD2Kv6Ic+7x+wb2k/Y+/uGKdDgn0Irem8bvugiX1LGz895F0H23dDB1+uVnoCz0I/Hpo1dJ6R shg6ubB8B/jtWNuxn1SxI9JgQcU5gvav2PnwWUPHrkm5E/rY/2joAQM7Se2wtVNiTXVrO4/vANjB +0oq3n1T/wQ72J1qFyCZDX4LLO+09LErwG5NrgSPN610a7f5IvUQ5TIqQ6wzGus4rF3lrTgrbbTK whrez9aabU0q5UiA5LS1L4V+E6Me3zab9F9h1FYxKn8AXsRZ9TVGtRyaw+HPPN4/KCbryP0oZZ2L B7KO1odbqjVYe0uU/RPsH4P+Gt5RqBhT9S/AbCDO+1oy+Ci2o9wImxth4TJqH4c+X8roKOMW6ZMY tcPt+Tgvk6ZSwfa1Qua1XIxIDdDanWahV/dBcyAkh/iNdSUFXm1lVBaBfxw4GzgC8pPgi3h3pHzJ qCHa1WFt2NNC8gb2Myfg/1igE31iUMyyzj5EFJ/Tv4Q17LKUPSxXRiA3H3HSYu2lYfluaNa0YRcN SSzGbhTs70FuA+R9gImQT0CP+awZgV3c+vYLfL0A/4+g3jiUHQa+F/ACavmjrVMO/XKMNffndWjF ZOAU6Feht1cBj6Cu62HzblgYD/yLZQ3j24ien4eRXYC91k3WbEUtdRidFniO6y/9FOvr1ejDZtsf 9kRFqRJIfsh26OqPLR+AnQPoPVyF6ZjpdFbm2tci15qVCvTfQK41649buz5r3iHqPmI0cC1pRLPc +CXsjIH+CPh51BpfyL8Oa3+yrp7g+XrUsgdyD+y3tv1fISMmMO/cZEUyEFeCRqtdO6ETK5WjAj5X WCsMZmUdsIQj32iyV4YXMe7jMaPRwzwKch/G5UvWpDO9FQlsvxK50y3E7jcKfXUJ7UpHjZlKPHqJ W42ZSKsBtzTGygU/CLm4ileWw3INMA494wbuheYm4DKM1xbI54GHXMHqbazByDagFZ/BE6zAtFuu JoyiKwxayRnb+zDS/pnvEwr+ljrxg0h+QUviVZ0ltK+O5PMC764pF0hxwXwMcBPfS2K5vFW2EboY xRbwyUAP0AR+hty9wA8gGQD+OrZGdVk2J8KfFj4rOR5lnx23Eq7mK7X2b+GqU+jHgHfgPIgrQR1X hfrLwBbgbiCuLvXfQnMp8D3gzcAZwO9C5+fgF4P/CPzr3C6Nd5UuRrGF+1AmQ+IBmvp65oGfQWcv 8AOd76UMAC/054Cfweb/AY+eN2KFvIx7Ee24Vup4R8B6njqA+wS5zdgVNNi5BVyKo5Gufy3E/RyO Q8KtuGbhq5gy7OjectB46WMYtROMxmBGtS8kgtGxBPwMRickKiTKeiD0DfD6MeTuAKaj1K3IfRb8 o9B5H5JUSKZB8gdIIsCPBL8QuZaOZf9u1DUTls/CqwXwB14ZqEuvBF+MUu9Akg2+D+RTIbkL/P2Q vwJ8AXINluGhVg9+HfhHgK8Bk+DDU0APJB8CM2HzBtj5AGXvhA6sKe8C4Zt2DpgP/Do0NwC/gKQI uAoYDZvWiFxCex+D/duRex/4V5H7NiSfAxuAN8EmPNFHQ+KCpBf43YyRGF/XKCBG34VIcKIWB3Id b8IC+lZpA/87oNUnKuTwUMuFJ9DXJgChqcJD5RT47ShbB030ufoJNGFZRVS0N3NktjdYdzhRtoTn O8VqKTCGV2na9VDc8t0kfQyjdoLRGMyo9oUE95ocS8DPYHRCokKirAdC3wBPs6AMkV+GuVCG+C9D zLPkGMruAKbD5q0o+yz4R2HhfUhSIZkGyR8giQA/EvxC5Fo6Vu13w5OZsHwWPi+At/DZQF16Jfhi lHoHkmzwfSCfCsld4O+H/BXgC5BrsAwPtXrw68A/AnwNmAQfngJ6IPkQmAmbN8DOByh7J3RgTXkX CN+0c8B84NehuQH4BSRFwFXAaNi0xusS2vsY7N+O3PvAv4rctyH5HNgAvAk24Yk+2hpTjBGQVqQy zP0yrGNlWJ3KsDqVYQVjuQsWesHabsZIjLJrFPMuxJILceWEVw4rll5hnUjwjjdRO8ZFaQP/O6DV nyrkaJ2Wi1ZAX5sAhKaK1imnwG9H2TpoYrzUT6AJyyoiSnqxZ3gL+5wxOHefwH5pMPZOfSHBfTnH EvAzGJ2QqJAo1u4I+gZ4/RhydwDTUepW5D4L/lHovA9JKiTTIPkDJBHgR4JfiFxLx7J/N+qaCctn 4dUC+AOvDNSlV4IvRql3IMkG3wfyqZDcBf5+yF8BvgC5BsvwUKsHvw78I0BcQ2lJ8OEpoAeSD4GZ sHkD7HyAsndCB9aUd4HwTTsHzAd+HZobgF9AUgRcBYyGTWtELqG9j8H+7ci9D/yryH0bks+BN8Ea fNBHQ+KCpBf43YyRGFnXKCDG3YUYcMK+A7mON2EBvaq0gf8d0OoNFfIT1jUafIC+NgEITRW+Kdj/ q9tRtg6a6G31E2jCsop4oF0i7VXaYvlePe0SN2OXuBn7MexesDO8oPXB/rCF9ye2nN/HdFt7SPU8 dol1kC/kexGQRDDSLvE0domnsUs8jV3iaewST2OXeBq7xNPYJZ7GLvE0donMX2ftSO2daiHvpfkJ glLFqMaCPwCsBS5ilAuQOwySI+ArgemQDAGugySKUcuAZA/KtvHTN2Us7eilPA3eyTyVYuwJST5y +wOLGdURlhxoAocAMxnlUkY1C/xxyE/ycxblIrDW8TB2VpnsD6M2Bv6cZDnpPAwd1lzEvFwAXAr9 dJQdBlSAUcht0w8Cn+ZWgG8F3593vLIfsD9d43JbnuZ2sQ7h02gp8yk2Po2z6o18lQTP4yARLFEe 0+m6WCtETyrsj+yv+dmC5SEsVIHfz7xaBP4/4c9S40N4xToH0MYjyO3PT47UWEjykXsWfBz4PdBp goU1kKyz66LduPIpNPfAk+N2rsWTz/pg9lbN4x24hvufykX2Qc1Cv8VC8zRaV2fLuYeLMBY9Dd6l 5MO3OLajDNZfwlhwKY1nkFyAFmncq7I3Yqk3ImQkImcw9wztNEhH2YCyo/Ui9PbTfBVsjR3aVQv9 /cBW9LPluY56fw48gRF5wqCrV+UbWhtLoFOD3Bu076EW5uOg+RprqkOhk8goK8HHGS7irRalQPNN q3VsQbPG/UZYewvyn6HsSONb8J/vdo6GTjpyfw1+NttUpqCH70XvPYXe2AM7AlgIHAwdybzcAlwH PAQcjVjKgs6D0L8Nkp7IjdN3EvZliewNTEGLUnG32SoLufqwVkz8GVjIhzwfrVgJO3Nsf9jCDPZf vgBMAC4EjtZXkM4s2ybrnwD2Q6k96MM9sPkl5LdAswnjYkLnCYyjA/INeC6TyjGg3wW8k1Gt5nhQ pb6D8ALz2k7wTyF3DKMShVrOoLfXc13qbmvucORoGYiiLPAx1nqCeP4ddJ7BWPwOK0kPyJ8Bn4lI +5/g66w1EJIySIbw81m1CHFbwbySAhzLc0E5i7mfiFL9scOphA8/wXyvhA9TMBNNYAnqrbItZ2Id c/L9T9j8BueqijUjYLNVfxErQCa84icvU+GPAmtx8MFprSdoo4b+WYR+LuH+ccIfRxXrGPDEqbCO 8Rpi9ReMzhkscWQzr38MTEN7T8CfRFguQV0m7xudi4wFfH9JT4NNfo7ZB337LCK/DivSLnj1Kvys gIW7EEs/QIR8As3NQAn5YzybVKwV6kicL2KNVKxIs9AzfLfhDFZgoT2A2bESM30o9vz8Ll8K87QC Eyq3A2dBsgfnnd+ilvchKUZMxgE/YmvKNvT2af1HVG8hnqIORqk2ltDq+iPc6+Daf4DaT7Od9u3K EYw1eajNZNTngW8EbodkPfAcWlHHqLYgdy6jowS59cBekBcCVwFjIC8ALob+OvDTkNsMayN4H6I+ pPfi8yDzWhLkiZAfs2oEP5916Iw2C3HI8suQDIfNo9B5DVgE3AE8D6xkVI4A7+VSmoG6MhgNDTqX IRkEvgb8MqMf9wOjXg/8CaMRyehYi1YMZZ7WZ8Yp0HkE+HtIfsbXxeQD4+OMygHtSV5RGbUYyF9h JH8YvwOcgRXmLfiwBBKB530nNL6rOUOjldPxPPohhXdW2mTUdTuuwe+CzxJ8O/ihqGW6cQdJfgvN nyD3Zvh5HaOyHPwY9OoOWH4Zrfsz9E9AvwD8t/k+mPEsdg6P8hquv89+6oOR+yK8Ha3fRDr3QPIB 6+snefUjz9n/76LGX2mNkFAM6zif0nr4JbXrS/SwBp+/yesntZ3mrDEfbdmLupbrvAeIZ2t6s87v rY/Ec88I4F8gn846xkU+b2qX9PtZotG+1/gmo/6i5Q9W5oPqND5XWj3MEkcMlzLisLafYWtKAjT7 MhrX8+5as841aJeajxH5IfQ/sSyrb6LVEST/DbeCeqk39jCF8Hwn3/FGnw/EKJ+CnUR9BEaB+Qe4 lDEVNm8Gv47r1d+y3iXA6GC8tGUYtUHcCnUD2pLPdWn57IM6GZJ41DtDJ4mmQ7MIGAt8A3g/o7Ie EfUINKewBQ33mbUk2Hyaefmpzs9PPczTOvMZX81hHlllMxn132q0Nurz2Sb1PD8ZWcJydQlaN8ji 2aa6CHgn6spX+bz5Aiw/yj4o64EjeDSVSkuivcAtQi33wM6HsDAGPdwXfgpESL5dI42COhM4CJ58 Af0vuS59Mp/ltVWocTRKzUArouFJH/1dLsVljRNo4yUg5qZ+O8buPozvKI1izKjgkdU+h7wBOA09 n4Fn3z74NghzZKa1bmDdO4aYvwUR7uf5or2HFaYEEXIU+i8h90bwMZhBR8BPxjtUt+s8dlWYmxKa /wNz9k3Uchmafqw/e6HzAPgTxk8pdzN2I2/wTNR28yhEbOZSrlGs47yN0YVIc2xBvG1ldL3F6Mxn NH6P3A3wdjrrR2yGzijuAbJA6MCar6frE9An1M9qD8TGIpbQuYNQ3Yg5iLM5XctcwDrGZ1sf76b0 M9xXNB/74JzF82sOo7pFz8dZ5k3sn9nOneh5oVrR4uX7IXwla9yI84WHeQVnW60X89o5SN6FhQ3g sf+UJ7H//D7m0RJtMlkw+ZmFlqZFk+RHLFEmoMZPUONU+IZzdHsz3qq6iHe0qvAcNrb9Y17/IakF LrLl/HbWAuDnkAxD7hHwlcB0lD0LeQn4dZBHQYI3weR/sffdcVYUW7e7uk71Ocx015BFMiMgyQFJ kiSLSFTEEQkjySEPMCAiIklERERERERAREQkJwUREVBRSSoCKiBZREQFxIQ68/Ze3RzBe/V6v+/d +897c361ak91dXX1rtqrq7qre2chvZ2gOgW5MeSeyJMbT8/xjFVVEKRdSGmHcpoiT6vgCTuemtVH znkoYTJKqwVshfxVkb808mzGU+9UpExFyqlgnRj2TQ5zyr41BXVxyIVxLII8EHlq4ol2C+SpivTj KG07jtgmrMlZ1HAAtCQpWXiOthJHPIUyF6D+k1HaVJSzDesHRmLf9UFpyBNB+QUC/SOlQKAllNk4 0APkRcFqOtStHEp2kZIHWAV74Xy1wVFewHGPIeUeyCWAeZCzMNJfA16Po6CVFdb+6TfDvURGzgg0 o/Nh33dQ/sBsnsE5syAPQQm3Yesi4KsoYRi2piNlC/JsQR2gYUdBey8DFwB3I70T8BrslRvpRVC3 oK3RavpqYKCNpsgJHepu2Pd0cO444jvACsA+yBlDrbC2hH5Eek7gIziWCc4FeYainAJAQkpy0N9Q ji8aUHjC65TF1r0oAc/XnCj65C7gUayXqCb59RzUU6H+P0C3myDfh3MJ+jBsSp2GvBBbT6KcnEg5 hK2HcZTZwFGocxbkb4ClgceRvjfIg33bhfl3kzxHFnww6JNhr5OUDyBXAq4E9sURz6Mm+YHlAt7A OoTGwHbYdz3WMFQI1zDAllH+T5B/wtbhYT0DWXBGaDW7UecBqL/Yl4OzdoOzC3gMeWJokQi0PQEy Wi2GPhwF17npkCvJVhe2pmFNvFVSwDxmBOzoLpxL8ZDZzsrsDPsOQTpW1DglUYcZ0EMzYFukX4f0 kaj/t8DVqM8iPN/H+hA1EC3bLMBAD9nzwbozwRhzwaVYH4j6vIaSKwbMGTKA4MuBBQE7APcAP0P+ tahti7AnzAX/CP6IrSNDTha5c+Q4H2VIRGajnYMeiOcLm3Bfd1PwfBZPjbOj+4Slo98IxsYyHgmR W4eWxTpiZbXIJ347Lq1vmgizyappPQnvd55wN0tflRXOKg3rnJtiTXU2ZqPWTJT1z7KemeVpSJeU N2UNqsohMg8WFwIlfZfMZxmTpQ6yko2Kyh1dqiMrEKgMMC+Q5MpIhJwkM2LG5kB8I9M8DhwKxNc1 ZXzFe+0E4jm+GYT6SJ7V7hHGocDV0eIiA1e7xZBeDOl1kV4Xch3IdZAnBXlSIM+GPBvys5Dl7sSV kX2CZrgws9tJZPdDYCCXAHZBnieBraUEw7qlM6Yw5PMoc7+kuO0hfws8hDw7gB+ibl1FjnbBXmlA Hj+omVh7MB04060iMnCmWxCy4MxoTpGBM0UDLBdHnkLIUwjpA5EuOM+kCLoNIR+EfEwwmgtyeciP SWvKCmdu02xO0VideNDdJilReS/9xSiXTDMEVRF3Ou4ezBF0NeNSOVN1yowF7kX668BNSGkKeQ1k XKOjrDFnutz9UBUiwX344M52a+B+oNwpqiB9leVCwGtlL1NVrDLEjwSlH3LO9YJR0VJJM0RqFTkv svs+asijODqJ87oQLYX0eUgX/Z90ZyA9CqyJY42RNgrq5s5FmzZFq3UC+ki/FW36LVJqIc9e1KEx 5MNc24ciB7A1hpShwF+Bw4DIabZDHoPeshY9pBN65in0Ye57apuMb9U2rF3ZZlYxPibHdXKYdSw/ jvs8O3A3KYfsq3aIhtXjuI+9A/i4aQT5Tsj3Q74f8n7I+7FvRZz7QuAE4BbUvxTOdxHwEdSwBLAe tkZlTIg7yfOM9K7WsqKez0jYo6Wsxle5pOerGbLGWM2QmqujZo8g+sBRsUHGnoLyZgrL3HPolCur yr+LDuYUT+YL9J0ra5aSxdZUGvp2sivXrzRZC6Q82cp5erOcEJFzaWLqAqXOQ8VOub+1ZVwolusk R2QlQ7KZJOi2hLwD8t3At5HyOFB62okoIb0R9j0AZKZS2SYP472REyLrFdLDtejwM/0DUk4hRe4k J2Prq3qWpEdeQDpK0F8z7sVe2ZEySH8LclnIXBN1MiK16uJ8KbKcl9NFVkdz+mrIgyG/DJlzqgwT kTaK5IPdCSuewfd1z9CdwvBYp3QU3w8hfKeesEqZeIvkkbaoQANFzn5IZEGW20qZwDOyVZXNzmR8 jqpJ68tXJTlliqRkvwu5O9AFPoByRkJ+CvgCyvwZKG13JqscZLnWnPkNlpKVHynXQHbEWrNKMh7P KoMxzxlBKYHlY8B0YA1gfmytAtkD8jxdPYna3gd8Uo7FGJUU4BSkfyilqQ6QWwHXSN04PZjjyLV7 atYFlCl3Vg9nfYF05oFInWyxynlSK9ZJNYzotgnKGfE8a7Tgb2uAYn2HoYGTv50Q/vlN5p6FJb+a h72Ssj+B3gItSQ0ryNnxyASYXQxbBW/Nkru7OaCN0cj/WdZykrH0R8CdQOHteVITrmExHCUdZabj uDWQUkPuV0gJPLuUs3gkmzWv8mQtwKxBVmCqrAmQxb72Is9e1O0o2nGY5GfkqwzVxZtWpbOFG/sg Z1P5ghGPOUVLTZHeJFtW+q3OuhvnJVe0jCy5A1A7W5j2ZbTaZrT70Gx5F2xoFvOSk4at3yP9THZ1 9BDwVbYHeTeQZbU46znGJb/JuzBfYmS1Olvut5+StzXpXXm/jFtQdFJfMHuOvJ1Ev0R49MIjn7ws PwPruCC2kz0R78odAT8fcJuB62bguKxtelXWwLPlfg/LPQt+MCJHmontmyOiYbk2cd2CmstZ3C/t 4sSCPg9mLp118eueCaqG2UWmS2aXrlS8272ZfWlYj8y7+tD0nnd1zaS1fbsMzqAtlJOcJg3aFKcy t7VpXFx81GRnUw4ynB6j0lSWrqObqIK8E4B0l3IxXk3lqAbJVx6LIT2Botw2CVSGylNVqsnskELF xadpuPVKykMlqCLVonrUGN+XviW+NZEKUl5K5rgS1ebj30DMqNQmvt2hfORJLVu0bVqcKrRt07w4 HznYsxDlp6vIp2upDjWgJvjG0K3Y5lFh+Hi3zFfV6HpqSDdSa9LUNtxahApQKUqiKsw9dakRNWWO i9BtlNqt8qBujgvMCSwILAlM6dal72CnBrAusHG3bv0GOM2AbYFpwJ7ATOAw4FjgpO59e/VwpgPn ABcAlwPXAjcCtwB3Avd2z+jfzzkIPA48BTwD/CG9V0YX51dB7QBj6ZldumkLLABMBlYAVu+V0Wuw rg9sAmzRa1D/vroNsB0wjQ/bRXcHDgAO75txdz89HjgJOBU4Azinb/9uffV84GLgyn53de+l1wI3 AN/ijJl6K/AD4F7gAeDR/lLOSeAZ4E+CEQLGBgjmBOYHFgYmA8tkchUjKcCqwFqD+nUbEKkPbAZs C0wD9hwse2UChwHHACcAp5B8y+gK7iFX/hvSxfW8v6Nma4mxtfyZJPnk3WGHe565LOWfSQ5bWJ5/ Gpdme/w9VpTvn6T+vrXMX2LiH1CzpRTFh9P/rqTI/wdM+ANG2PJyMpPk+QtZUam/xCgw0E/wzSzv H7DsX6DDDJX8N2LFDPNXaP+AmvmsEBX+NySHubHkv4xrUCYNozE0gabQDJpLC2klneDR1E+KVEzl VAVUcVVGVVLNVFuVptJVhhqiRqhxapKapmar+WqpekVtUFvUTrVXHVQn1DfqB5XluI518jtFndJO ilPdqes0cVo5qU6ak+5kkCuvYzoRMLF8qxlxLLi2qBxzSMaJKsd8kiu3SmwR/J+4UpCUt5jTc9AV 3hbvE++07/h5/TJ+XT/V7+kP96f4C/31/gf+CT/L5rQlbS3bxna3Q+0klOXY5VZmyDlI2Z9YTxwn ucH/BQoHceHKfDSOi6cFcYl5wdFLvBv8n+ygpITkSsmNk7cmH79qxFULSmaWnF9qXKm1wTFKZ5Ye hRo6paeUXhDsXXpvcG6lT4Tx6SC+ul0YLw3icuPC+FwQl785iFMqEd5pSake/t8+jIeE8ZQwDstJ 2RrG4fEqOoGOKxYN4+5h+uAwnhzGi8NYxsoSHw/qX4kC7VTCt884nhykX1s4jCuFcccw3hrElVOD /JXHB/tXnhGUX/mV0L5ygx8krQLn1HwFb8nJq9QqcqK1eA4rX2D7L/s5M71ljMINXVU3ibRjO6rF 1/hmPG5oT12pd2gr42kyTac5tICW0yu0gUc7O2kvHaTjdJrO068qorwon2N0cXRJdA3ipdG1iJdF X0W8PLqO4yUsvYZ4SXQ94qXR1xEvi25AvDz6ButiSXQj/7eUc29CvCS6GfHS6JuIl0XfQrw8+jbn Xhrdwv8t49zvIF4SfRfx0uh7iJdFtyJeHt3GuZdFt/N/yzn3DsRLojsRL42+j3hZ9APEy6Mfcu7l f9BITxpAQ2nU39LILpz54uhHoWZ2h5rZE2pmb6iZj/k4i6OfhPr5NNTLvlAv+0O9HAg18lmokYOh Rg6FGjkcauQINHI01MixUCPHQ418HmrkRKiRL6CRk6FGvgw1cirUyFehRk6HGvn6X2hkGs2m+bT0 TzXyTaiRb0ONnAk1cjbUyLlQI99BI+dDjXwf9pgfQs38GGrmp1AzP6PHXAj180uon19DvfwW6iUr 1Eh2oBHmX2gkpgKNxJxAIzEtGolFAo3ETKCRmBtoJBYNNBKLBRqJ5fg3NPIWbafddAC+CM7RBZ6+ JcQSAo3EEgONxLxAIzE/0EjMBhqJJYlGYjkDjcRyBRqJ5Q40EssTaCSWN9BILJ9oJJY/0EjsikAj sQJBj4ldGWgmVjDQTKyQ9JhY4UA/sSKhfoqG+ikW6qWUnGmseKiXEqFekkO9XBXqpWSgl39bI6fj GikdauTqUCNlQo2UDTVSLtRIeWikQqiRa0KNpIQaqRhqpFKokWuhkcqhRqqEGqkaaqRaqJHqoUau g0ZqhBqpGWqkVqiR2mGPqRNq5nr0mLqhZuqFmqkfaqZBoBm5Mki95TqgpjDTe5TBF4IYXxMK85iy EuurMc+72nm7mOkbxW6JTPE+CqUnvN2Q2nDanlB6wtvL0g3I93EoPeF9AknyfRpKT8BvT0meR9bg 9mhBqdSZWX0wjaDx3r74kfbHj3QgfqTP4kc6GD/SofiRDsePdOTikbxTLN0Ya8RpX4XSE95pSDdw 2teh9Fc1Ohqv0bF4jY7Ha/R5vEYn4jX6Il6jk/EafRmv0TfxGn0br9GZeI3OxmvEtq9SVAoPEQs6 sj7tKucqEm9BMVJ+FYzD5O7eKJ6f/EOdeQw5j3vzWtrF/fgn7sGeys8jyHKqqqqrmioZsUQSN5MD rx+RxDfj0lsXJWcHS9Mh7YxL78elD+LSh5BkROY5u0R2jjFOw7aP4rl2x6U9kDSfhaW8zl7sITV5 1JFaPIk8H1+SJ78jdZrmvE2ac05zPomX9Glc2heX9selA3Hps7h0MC4dikuHIRlu/7zc55OpjMPX Z2cWH4uvz85sjt/hHLOcdxlnO0fi+x0NzzvqTHImcxvNceZz/gXOYkpwljpLKclZ7qygnM4qZzXl dl5x1nH5GuP9vGxXCt/NJvGkAR+Zz/GGRc4iLnM159fO687rPHrj1nam4suF4vtQ2p6ZHrPJBJ6f aGeGM4OKODOdmVSUy3iDiuFLhPXwJUIp/xzP8gpzn67PnNeRMpjt5tJivv6dDNpL5+byf/TbkWNq hik3IqU9Uvgs/U4s1Qq33YRtt1+SuxlS7ojn7ojcBr46C/CMsST2OY/jnPV5HGpqY5/vcZxz2KcD 9r5kHzmCc15qxfvcIbmlPs45yen8FBxZjuT8ILWTb3twKalSE+jrrHzzy9Q0tbn3iB9H7T7kjnPk TpPWaACdoGXFl6c9jHblq2RK4d16Dinw6XNKyV3R3ZekaflCvJJ7kxsvSVVqqzw3uGzfpWotp02/ bN8Z/JMnS2MvSY2osfhNkvual5U5nEPqZWW2F6+/qvFlZTbhXyqnVrqszEr4cdurgpeVKU9FnMvK dOHL6MylZXJ/OafkqdSBS8vk/+QnrbXl0jKJ9UZLLy2T56zypHbmZWXO5h/rLe6zLihzPH6sE8q8 rEy5x9/+sjLT4I2w6WVlNuNfOv3u1Sgosyp+MlsrGk9X4ZfXtfOzfMmN296jBHec+xC+ZHv5d+IV vgSv8HVlFX7xXZHcWa4QllcRNaqEr/gXjKdJ3uf/zjHs0KBH6i/dIlr4XbnF3BKyLTKVNqsJPJuf wvP5GTyjn8tz+oXcl1byvH4dz+w389x+K8/ud3Ev3Mcz/KM8xz/Fs/xzPM+/wDN9h+f6CTzbz83z /YI840/mOX85nvVX5nl/LZ75N+S5fzOe/bfh+X97J83p6qQ7vZ0MJ9MZ4gxzRjhjnHHOBGayKcyw M5jn5jrznYXMYyuFuZwNzmZni7PV2enscvY6+5yDzlHnhHPK+cY55/zgXHCytKNdPm+rc+v8uqAu qpN1aV1Op+jKurqupevqhrqJbqZb6TY6VbfXabqrTte9dYbO1EP0MD1Cj9Hj9AQ9SU/R0/QMPVvP 1fP1Qr1Ur9Sv6HV6g96st+iteqfepffqffqgPqpP6FP6G31O/6Av6KyIE3EjCREbyR3JHykYKRpJ jpSOlIukRCpHqkdqRepGGkaaRJpFWkXaRFIj7SNpka6R9EjvyACe1Q6NDI+MioyNjI9MjPAMXJ7L 6eIceEasZcUE9yHx9K551i/fv9JjOcj3h8bLClWsqFBa9pvKga96mmfX+AaWrCeV9SQLZfWhrGEk hS9krST5OprSbBPy5S29mYN8uYmZRO+UVccc9nKQFfgHORzlcCKs12kO33A4w+GcvM3AgetorieF bz014NBIVr9yuJHDTRyac2jNQVY6386hAwdZWdmNQw8Osmq4P4dBHLjfm/s4jOQwmsMDHB7k8BCH hznI98ge5fAYh8dl1TsHvmKbpzjwqME8w2GWrKLmwPYkb6OZlzgs4bCCg3wnbA2HdfLuIuGNGCOr Ud/lsJ3DBxz4/M1uWScsK1w5HJb10iTff1HmtLxxwOE8h584/MoWRLIqnAPzlutxyMkhN4e8HApw kFW5RTlcxaGUvCUrK2o5lOdwDQe2X1kBL6sq3Gryri6H2hzqyRuyHFifst5D1nm4stJzUHAXLHE1 B25Hj63YcznwNcWzHPjYXn4OfFyPj+slc2AO8bitvHIcuL08vv57VTnU4FCHA/O115hDUw4tODCH eW05tOPQkUNnDt059OTAVwKvL3MJt5Hl9rHcNpbbxXK7WG4Ty21iuU0st4fltrDcDvZ5DtwW9kVy 7EuWW8Ryi1huEcstYt/hsI3D+xw+4sCatzyOok06pmVCWkwXk7V9+mpydHldnvnrGn0NRfS1+loy upquRq4erUdTVD+gH6CYflA/SDn0Q/ohStAP64cpUT+qH+XRwmP6MfL1E8x8Vj+pn6Qk/bR+mnLq WXoW5dLP6ecot35Bv0B59Ev6JcqrF+lFlE8v0Usov16ml9EVeoVeQQXwvbkr9av6VSqoX9evUyG9 SW+iwvpt/TYV0e/p96io3qF3UDH9of6Qius9eg+V0J/qTylZf6Y/o6v0EX2Exyaf68+plP5Sf0ml 9Vf6K7paf62/pjL6W/0tldVn9VkqZ8qwjZU3FdjKKpg6pg5dY+qaupRi6pv6VNE0NA2pkmlsGtO1 polpQpVNU9OUqphmphlVNa1MK6pm2pg2VN2kmlS6zrQ37amGSTNpVNN0NV2plkk36VTb9Da9qY7J MBl0vck0mVTXDDFDqJ4ZZoZRfTPCjKAGZpQZRQ3NGDOGGpmxZiw1NuPMOLrBjDfjqYmZYCbQjWai mUhNzSQziW4yk81kamammCnU3Ew1U6mFmWamUUsz3UynVmaGmUGtzUwzk242s81susXMMXOojZln 5tGtZoFZQG3le9x0m1lullOqWW1W0+3mFfMKtTPrzGt0h3nDvEEdzJvmTepo3jHvUCezzWyjNPO+ eZ/uNB+aD6mz+ch8RF3Mx2zLXc1+s5+6mUPmEHU3x8wxust8Yb6gdPOV+Yp6mG/Nt9TTfGe+o17m R/Mj9Ta/mF+oj8k22dTX5YsL9XOjbpQy3EQ3kfq7SW4SDXBzublooJvHzUOZ7hXuFTTIvdK9kga7 RdwidLeb7CbTELekW5LucUu7pWmoW8YtQ/e65dxyNMyVVUT3uSluCg2XL47T/W5ltzKNcKu6VWmk W8OtQaPcWm4tGu3WdevSGLe+W58ecBu6DWms29HtSA+6nd3ONM7t7nanh9xMN5PGJ65IXEEPJ65K XEUTEtckrqFHPJ540UTPeIYe9XJ4OWiS53s+Pebl8nLRZC+fl48e9670rqQpXhGvCD3hlfBK0FSv lFeKnvSu9q6maV5Zryw95ZX3ytN0r6JXkZ72qnhVaIZ3nXcdPePV9mrTTK+eV49meY28RjTbu9G7 kZ71mnvNaY7X2mtNz3m3erfSXO9273Z63uvgdaB53p3enfSC183rRvO9Hl4PetHr5fWiBV4frw+9 ZEfYEbTQjrFjaJEdZ8fRYjvBTqAldqKdSEvtZDuZltkpdgott1PtVFphp9vptNLOtDNplZ1j59Bq O9fOpZftPDuPXrHz7XxaYxfYBbTWLraL6VW73C6ndXa1XU2v2S12C623W+1Wet3utDtpg91ld9Eb dq/dSxvtPruPNvFY1dJYHlGU05V0VX1eT+RRwnQ9U8/R8/QCvVqv1ev1Rv2Wfldv1x/o3foTfUAf 1sf1SX1anzZl9XlT1pTXj5iW5hZzm7nDdDJdzF2ml+lnBpq7zb3mfvO8edEsMsvMKu7nr5ryZoPZ bLaYrWan3s3xXrPPHDRHzQlzynxjzpkfzAWT5Tqu6ya4Vp80Ld38Otkt7PZ1q+sS7p1uN7dH4lov 4sU8z8vp5fUKeIW94l5JL8Wr7FX3anl1vYZeE6+Z18pr46V67b00r6uX7mXY0fZB+7B9zD5ln7HP AhfZZXaVXWPfszvsh3aP/dTyXJbGgJEJjKzAxQ64WIOLI+BcA7Z1wbNR8GwMPJsDPJsAnk0En3rg Ux98asGnSeDTnODTXODT3ODTPODTvODTfODT/ODTK8CnBcCnV4JPC4JPC4FJC4NJi4BJi4JJi4El i4MlS4Alk8GSV4ElS4IlS4ElS4MlrwZLlgFLlgVLlgNLlgdLVgBLXgP+SgF/VQR/VQJ/XQv+qgz+ qgL+qgr+qgb+ug78VQP8VRP8VQv8VRv8VQf8dT34qy74qx74qz74qwH4qyH4qxH4qzH46wbwVxPw 143gr6bgr5vAX83AX83BXy3AXy3BX63AX63BXzfzrKAY3QImagP2uRWM0xaMcxsYJxX8cjv4pR34 5Q7wS3vwSwfwS0fwSyfwSxr45U7wS2ewSRewSVewSTewSXewyV1gk3SwSQ+wSU+wSS+wSW+wSR+w SV+wST+wSQbYpD8YZAAYZCAYJBMMMgjcMRh8cTf4Ygj44h5wxFD7IrPDvWCH+8AOw8EO94MdRoAd RoIdRoEdRoMdxoAdHmB2yE3jdAldVlfUVfR3+hH9uH5KP6Of1c/rF/UqvUa/pt/gHv223qbf1x/p j/V+fUgf019IH2V2+I7ZoRyzQwtzs2lr2pmOprPpbnqavmaAGWyGmuFmrplvFpqlZiX3orWmnHnd bDJvm/fMDv0Rx3vMp+Yzc8R8br40X5uz5nvzs/nNVa5xc7i+/sK0cPMxKxRy+7jVTVuW0tyubro5 kviyp72ol+gleXm8K7xCXjHvKu8a71qvmlfTu95r4N3g3eS19G7xbvPu8Dp5Xby7vH52lB1rx9tJ dpqdYWcDF9qldqV9xb5rt9sP7G77iT3ADPHg/2eI/4cYQkYpt4In2oInbgNPpIInbsfIpB3Y4g6w RXuwRQewRUewRSewRRrY4k6wRWewRRewRVewRTewRXewxV1gi3SwRQ+wRU+wRS+wRW+wRR+wRV+w RT+wRQbYoj/YYgDYYiDYIhNsMQhsMRhscTfYYgjY4h6wxVCwxb1gi2EYUdyHEcVwcMb94IwR4IyR 4IxR4IzR4Iwx4IwHwBljwRkPyjo68qgoDaDNtJ320mE6RecpS8VUblWYEuChWvxTp1BVqkX1qQm1 0N+zDY3RPzKO1T8zjte/ME5yx5NjrneHMtZzhzE2cIczNrJrea71uF3H+MSflPgDSvwJJV5Aib+i xIdR4r0o8T6UeD9KfBUlvoYSFUXcEZIb0si4NCoujY5LY+LSA3FpbFx68KLknYtL30FymB0OyTdA zW8mixzmNIfzG9cll7ktgWLMSenwByb3yGK4M5s7cTszy6Oynz71u4x3MZQWX+ByNzmBSiJ3Ts4R ieeNhDlli9Ujma04PYixvyNlcZyCEgrgecUO3us7PUl/FuxluwS5g1jumfBeS3gvufEboXJUiarD f2ZDojDtYssEd/MqoZ7HgPOAx4ELuXwb3FvWuXVu5sobdXPKYaqaqmRNDVObktwb3OaUx23l3koF 3VT3diru3uF2oOTEBYnLqVTihcRsSvFT/U5U1W6yb1Mde9AepAaoRRS1asjYlFqRrKPuGNYvGtau cNhzglpeizo9CzyIJ0Ea8q/AQzjrU9Dkf67OSZTKtZTVGAM4DGF5OI1haQJNZnlaeB84yFmBKlMN 9Pr61ILlNtSOpc6UznLf8Jwqo+6vAQ/jDKrLfa6L55a4HVu2Ac/Hz1D++xq4Cnj0P3rOeXG2Q2gE jeUwgWV5cjyCZtM8WhhKyzlVvl+6Pjz7vGHbNqObOaSyLFprFpYUSMM5dUyohyr/Sz2MjveB/45O 8nAr9qVMGspnP5T1MgE6mUlzL/lvAW8PnhUEe8Q5kIP0hTTqDn38/t8QWasMfVTFOTwOXB2ezx+1 8egl57wU+Pwltnsi1NV/UgsK33ktSRfXdOYMa18N9/03CiYlhdvkaUVj/CRH9TC1AHNRSvgL0h3S ic8lziVKnCe+c+0X8C976ROF3BR4G4s4X5DjyLox5cwJnxAPhpbk2Ud3qmgL2yK2qC1mi9sSNtle ZUvaUra0vdqWsWVtOVveVrDX2BRb0Vay19rKtoqtaqvZ6vY6W8PWtLVsbVvHXm/r2nq2vm1gG9pG trG9wTaxN9qm9ibbDM/dKjh3EDnjnfHg56ZUwv/NOjbJ5rF5bT6b315hr7QF/F/8X/0sP9uSVVbb iDXWtVEbszlsgk20nvWttTltLpvbFrSF8AS8vLqGT/Ws+pHlnx3xP+moGF/b7/SH+ff5w/37/RH+ SH+UP9of4z/gj/Uf9Mf5D/nj/Yf9Cf4j/kT/UX+S/5g/2X/cn+I/4T/rz/Gf85/3F/rL/FX+VP8p /xl/tr/Uf9L/zp/lz/Nn+i/4c/0X/QX+S/58f7G/xF/kr/BX+sv9af5R/0f/aX+1P91/09/hH/HX +q/6r/hr/PX+6/4mf7P/of+Rv9vf43/s7/cP+Af9Q/5x/4T/lX/a/97/wd/pv+yv81/zN/hv+Bv9 t/wt/tv+O/67/nv+Vn+bv91/3//A3+Xv9T/xP/X3+Z/5h/0v/JP+l/4p/2v/G/+c/5P/s3/BP+N/ 65/1z/vH/BmsnVaUA6uNS8Ljs6xoKQSv4snwKl4SXsXLwKt4WXgVrwGv4jXhVbwWvIrXhlfxOvAq fj28iteFV/F68CreAF7FG8KreCN4FW8Mr+I3wKt4E3gVbwqv4jfBq3gzeBVvDq/iLeBVvCW8ireC V/HW8Cp+M7yK3wKv4m1UCVWCboVX8bbwKn4bvIqnwqv47fAq3g5exe+AV/H28CreAV7FO8KreCcl XsXT4FX8TngV7wyv4l3gVbwrvIp3g1fx7vAqfhe8iqfDq3gPeBXvCa/iveBVvDe8iveBV/G+8Cre D17FM+BVvD+8ig+AV/GB8CqeCa/ig+BVfDC8it8Nr+JD4FX8HngVHwqv4vfCq/gweBW/D17Fh8Or +P3wKj4iyn80Er7FR4UW+7+1yr+y+MBi2zsPscU+7DwMi21GyWydYptihXG7ZXv9Ddbq/MFexVov sdXAvm2CrGdQKaoKl5zTyUOuk88pTwnORGcilWDLTeDx+P/Mcmeypc5i+50dWvBcttYX2FLnw1YX sq0uYmtdxra8gq11JVv3DNi3WPaYP1hvYLuvh9b737fdHayl1qHtNiZ5r7MXjWbbfZh/VWkOyZtz y/l3Hb3Kvxq0h3816Qj/atEx/tWmz/lXh07y73qeu5xiqz3Nv3r0I//q0wX+NaBf+deQsiibbVcr zVZrlGGrjaoo3agSuC2a8oTQY9vl5mXbzalysu3mVrnZdvOqvGy7+VV+tt0CqgDbbkFVkG23MM+P blFFVVG23eKqONtuskpm2y2pSrLtluZ5Vaoqo8qw7ZZT5dh2H1GPsO0+pZ5i231aPc22+4x6hm13 lprFtvusepZt9zn1HNvu8+p5tt0X1Atsuy+qF9l2X1Ivse0uUovYdpeoJWy7y9Qytt0VagXbrqxP 7qleVi+z7a5Ra9h216l1bLvr1Xq23Q1qA9vuRrWRbXez2sy2+5Z6i213i9rCtvuuepdtd6vayra7 XW1n292pdrLtfqA+YNvdpXax7e5Wu9l2P1Yfs+1+qj5l292v9rPtHlQH2XYPq8Nsu0fVURqhjqvj NDIai8ZolD+Yr7ujgyswYQzH12gdXqmTwzHBdVjJ8xr/yN5m5V1jWZ+dJ3xboCAl2Oa2hW1pW9nW 9mZ7i21jb7Vt/5jH7+x38bv63fzu/l1+ut/D7+n3+mMelvNSPp7hBG+xBG8kcB7et9e/Ksfv7Q+K 5+nt9/H7+v38DL+/P8Af6Gfytr97rL9RTlgfWeUh45koj54KUPGLs2VffGLfRC38exC39u9F3NIX T8430RuMLWijWJQv6ytaQus3XTo6suLduznSrws1fJtNtbfbdvYO2952sB1tJ5v2P2mF/yvlWB75 7UlMSmJK/ZP194rZWd7ZS+aZVHW272C13TasDtseXzV3XPxbQ/o8Lp24KLn3SO5/sdqsJCXx2LKn 7WV72z62r+1nM2x/O8AOtJl2kB1s7/6TVS6Kx/5JvPfF+XXDcB7bHnO8YHbg2KG2B7AnsBewN7AP sC+wHzAD2B84ADgQmAkcBBwM/PM65Y+3/3qK6Hn6uKzFCGf3KfE7FvntGxTlWbTWz+pf9SF96vL/ w7mVzLUHYB9ZlViGmlq5C3qYZ2aa5yBab2P5vD7F0td6FctHw+3V/53tfKz49vgscFL8qJWpo91A ef/kqKOl7peUH+T8Z8f/GznDmozG+f9jnarGNbuR8ujVvCXYV+71LNXPs6ZPXPLf+XBPmcPlxZ7G bkxKSsqZlCspdzg/ghXYIfYee29Snj+d+fxriwvfX8JbsR7e1yEyzhldKNIj0jPSK8yhglxEBbti ho6/gu0rjSmY6ub4P9WdeTjU6/vHZ7WMJYwlsoxsWYbPDKKyi7GOZWQp0WAwytIYawoT0iJ7hDRj CWUrnJTWo06IaHeUJZSKZCshfD+jUznn2/d7zveP8zvX75rLNe77fj7P55nned+vz/08rmuoJFkk zfJBOWFMhgQBdJnCoFAcD8DNgVTlh8MkkBCAzIFS5QDLYYYODIpgkgAHQG2VR7JIOk4STAL2yw4s ykMhwWAKUCB08MeA/QJkV3WGEKYMXTunIgvbK/qgOllReLG89FWuGJMhoggwECcBBjyeCQfLbxga rKggp6RTlKobp7tXvksFcgrg+zZaKBIcV9TKMOHbEBxo2DYSDg0Isg0uNMqFHOpPDfKjBwfhBAB+ tpMTzelI8QkMDvLBSQOSbA8KLWJL9aYFhwb70jGmwbSQYBqZTgWvkANk2XE4WmJ13IeCIVH9gsBe MfamxoC0GB8OD2wCtPA4LfB9O2hqAprfTCD+4N8yNj6Ahx3nQSNs7ewdvzaH/4fmAAO6fvWcgdUQ nAFuW0A/CsaAQiGXSyz3CCysL6AUieZuuUv2mqcrV6VwiD/Y6yp+xMOFj+oVtJFJXFwfNSB1R4J8 fP5zsaCCaMsNVzXckeRqvHTys1gDustsYslGUpvxe2ojtTDQeTRo+IKibeh9n731Mk/ICckQ2ff+ rgd3WKbW9z/UfnL3V+A06XP07rwE1YuyfvRHHyN/Ih/KzYpR6fR7I37t18ve7/SIBvtho9OxNZ1r LsYfmFl4PZtu0ZSqf6yFM1Ny+mrY8GdvjPLpTdPGTrrSTj5G9QlndaqnIccG+eZZF9asbyirqH4i dgmYgMlhBOZ3u60ZqDpduCs+E27Dl+8lXtd04kr69jORSeH5ezpsxoQadAkwOJgZxQwoHzgj3AAa nEspBQQvgOLgAtWNRHLC4YAU28mPEEUI9zk8XzclbYU0FJK8eaW5jqKWjswFZNhhOcRaQDRO+K7g 67YH9aKu0FYddU1R0Us2eSgZwJndQAZhB9gC1kxLJiHJzJ9OD9msoeFN26Me+HXV1L2DAzVCdlPZ Xo0QWrBPmDc9VANcVFB4oOxAxXkCulhNHBYP4AB1sBGw/esYoVAEEbABrL7aACzJ4LdbRERE/OgW FNp/7Zv+hzSDs5WiUjI7fqNZMfqgl0RkwY7bi2Mit8oi0ffFSBt4eCEmhrprDj/3EU/QjrW41Dka fZjVYVcx0PSOILAk1nPosMB9GxHmhOByz4lOn874Rc2y5sjM4ZjHgYf2PpEkD7YTfS6GGs7tU9L6 6GhIML3BHx9CunkCWmTddF0FHrEvaKHL/IjYBlwpckj0SOOkFVVkp+Zcf2yWHsFMqrrt6J3ZZOm3 S+m8p+04ud8pZgTVZYlDP3nGj1T3HE6N3e6R4NlwLcb8JaFmyVU1PfbQc3MZh+z2Zi9Wwx3P0Vaq +970ihRnjNpmYuZiPkdq1ZFP/ge2XI4yydxk+aHLYywkxSTsNmNb2rqGbWQQTpdBOBV9gROKDDtu sgJRmT8yKeJvyXvZFaGBib72e9yJGkjBkujkwJBVRMIBm/B4vLa27hciaX0zgfi6/wsiKQEKX0zp IFNqiD+FhtlKMsOYkYibzbXxoMp0dHSwusY6G3EKgNyXTyT5w09EotDCqd6UPyXYibHjBFunn92z 454SefSv55g2Ww/t8hPUgNrydt831xAw6uMpsXcUSuYxjcYajlsE+d5JfwVvCxqLqgiQy+/wKuwI KDEcKTZd9iKw6i9vne83upnodOA1s0zNVC7fUQavPbOU53w6xTtiH1CI0kykrWuzamlX6Hi2U1D9 Tu2xyVRTCwKyIRrD83L6/c3LM3XdHbqpC7Jn9VGBiWJdbSNJ8BuaBxsUbrVvL7jV3OOlYEtSECan LqwbGJsl/BJn9kqbJLcxoq22N1d1040w7TW98Tay+uHA7Qu1lFBlC6Xunx/UJhCaIi8/psP7nlqL z5L6InuSZsnJipr1hF+YTskiqmphXwnGDc4IchWsNF6bt/g/DLK7gOnqO0ycJIxb3Jz6HazktD79 6mgegnpntBC+UKda26xdtwZw+gIrEFUAiCqmWZLp/wSrL2H2Kq4sIqjKFVS5rkIVCCrAYhWq9P4a qn7YM/1HxOb6Eb1Cl/ern+pISVaN2T/kIbL3jb/XBNdPps633K2w/t1zFoLp04IFiWNCj5yYYRW6 LLfYsPFfPmh1O5UMdrXH5JzLDANyOKUQJLWNsbGTRtK8+XGDQijMZtwNzjC/gXmtgrHkBRfJl65e mDQzjZ1mFS3H62JogQJKt627g4vKheoCteX85tWeKWAv7TwvjRwx3WBQgAyPmFToQxLEA/ssE1k9 VtZc5rLa5WEbbS7WcZ3tv6j66zWVgMV+bbF2Q947vRydxCx5bwyPuny1p+lWoWj3Xp1nJWZ16ZuF XPYPEX7xfdhZYO48Y8N5foD37OOPj/WKBhoefZI8gNgmsHvtTHqHQ1k2mEbIKyC9Sr7SS1NRYoVe uD/Sy3MFCyjuDMXDmVNqPlBxUTi4FjhxQOx3Tu5vS4XDAqpf8lj+ex47BgeDkADXjupL9SbTKRjj MLp/MI1Kj1qhFADoauLweNwmTTxIKfxvJp5t/pMl3Z+h5gLNzV0c8LkulbcLgzE5GU7aY7DuSXD7 3cm3u5dyRAUG+jfTD0pc1GDix5b7fjYhyj2mQZ5pu6AOt1VjLGcm/CttrVNKr0ZZ780ncPYsKvSf CkvuPBu6NfZp/LPpq1MbS1rdzZ7XVOkPbPDPkSgrpYU6T4plDS9qZ9GYT8I9pSPMDibqinaF7kBe 9nNMKb1A1egR51nKoCsPhms49QoDbp8epHgt3m31NMfZX1JCDxsBnTRlgQ3r7+gQ9Zl4/bQOli5H ojvRmbFBBYm/aP3UznvkAdZr0kx/pJIL8tGcVXh/xzFF0uvos1ZT5p06erqF9RHupWKFKXcFU531 blZye8IffkWNBzgj24E17NRDs7/iBwnAwbdV7PlhHcR+SkitQSBABSYBQhzcv20fRNj/SpndMfg4 +OaDsXtZvI8jPlQ8kv0id9eWclzwGb0r3VhA/FsjYRiCVxoFIUHCwC2HKcT4d3Djr2TsMnJWynmp gP6s8gJFynYbLgHsv8DNEiAAZkxTpnGS4V+H27cwDZQ2m0orYHNaBTYLwBzYugpsuv8L2NgJY/ql 13+vvmBQiNsmg1hF85rRYKPz+IaAUX6NoHLL2VHPsHc2W7BPTat4lu6+weKK5dpj7HPjZHdW6mvY XC4qdy4YCmlqrP8U1WBJmzV4axzb9oJXjHq3tACDneexv+XcgR2yenAlZKScrwhe6jzQeMTaZSrb pGBy+v34UJKMll6jc94ESS5RpYQhmTmYxSk1NUj8dIzV9hpdmk5sWfcglZatsjcwX+KT5ATpiV/7 +mV3qY6iY1eVLkR5O28tcuiYe1Ps6tybDzPbquE501P9iIEP+lySjR4epY5UFKlda1EV4KccP/ns Q9G8kCI3RTdrMlrGqun+C+fXXZEn1rq3aot69mZKWR7HXqvS2io5LiAiAdnZq71D9l7uHe7xRP5j doH8aKJ+jLJFAe3+9J62m2MhxS4ZLvuzUpjrLODbZzuL/VD00o3vsBpiLa9oOkIzwef1/BhzjhdS NEUp0vxHegX6fGaC75k/eij2JuoWov7hglq/zJHCStQCWsmoanjuRUWseRPnLgJllxGx1mSM+K4u PKobpcUdKBmHkxnkd+p9yVp4SRCo8sldthdVj7mOlI0ezDZWojZnpma3pnTny1bzuRdMFFUn+R/k DcA2he+GSJ2omhLd91H0oPyl5M6AcgJOI+/50F79p5ADXoT795JbG9fO89NSbhbr18CMApap+ScG BcoF6nXsuZ406wMMDk6Q3++/8lvUX2uF35L/BL8BHbCsBImtrbmy78XjVkz27hfc9/5j5e+f0fs0 a8/5/mcWGSoxu9XFX1wdHLp90kHOvupe71qi/Jrx+2X3baroAEZwlPOxU7aIZdY6k4zqXHdAsQey +/W+q2OHOdfM8iNyJw63y9zVlD90amrGT1Lt876RZKm3I8Ri1k05UlvKvFknd5dHTVetCaJo7sye TL+nG56bk2qTul5uMFdXqkyy2+bIOwxXWwhISwOCDk27AafmDzzJqXstm3Pg0wP0NNdFUqBjvVna aQuIFcFXUEnZtzxn+CFHvFXRXEKZIEGYm3E64d22yCVonpQ9VyJEADB/d7FPzrzpFtbpdI10pDEu oj2/f8vBTBYZ1iDFd/7zbP4F6L311k7Lc8jmnzE8X+l9DpyRsv9G7x8Whr+jt8BqeoMeCBCf+wW+ 8WlAfMqP8cvyLiH/7fJkCERVibKsmKVVNqGuM5xodcr/G+r/pVIWnGuBnCPN7vCtG3vf1FdFPLsX 5WALPa9O37sjkBd97t61famN6o+Eio4FejW6wO4SMWj7k73RRoMuTTWueZIvpKBJlU2RU0e7xrZA xwevpaKQLSkWgxMkkV67cxnDIykBj+Nuvsqa4tBIhL9JV5FfH7Lw8fNw5El1vlnOwZAra4mnju9G 0bIbWZsK/LC3HfjferkbiuYexRgOckrg59pxVuE4fVUaT8vbEP3lRBS6/2cU+fjE00axUeLR2Nva qh7F10ev7Ocx2feIRJMdB9qaIinuO6BiKGH+Bz3CuR/0Lvm61mE1RuYSk9odnF+fCsnaU7nJ5tHH qOtn10Z7Kb8vylfW4oiQ8GrVlw6UYUzw3FFr6jStezk3tr9hqKScrt1IvL1XTkgxnEfP8dje7eam wlfq6mpt/VpOmyzHRcnGFYoAvq9NhDwkWgrXy3aZvlF90zRj0a72qBsfZ6OoYiHvuf2t8/szfSdP tW0OvhqvROcQHA+XvZ7PuKnk9NP5AP3DrHByfRALfeb6WcKEUPDiEfyeC0v9Di3H5Fp9r56SOiTk A9PH1rilNg7LvmyobfOuj3RCPjJWt6/Mqi2NPFfHPBEm8WvGIXTYeg18OVcQc8cxhevM9wltsk9G pe1a88YtB2ahlODDPPtbqC2vgt6W5dzDKS/z397h3m27jtU9r1FoqL5NdHcrungRx0AUAQxEIQwK BcB0++fq5R+f0H4/6GXG32KXa7/plxuO4119igwO4LvFg+MHVkdF2MXg1wsROBBK+bKek4OPUDu5 X6puGioiSPevV1IDfFZdwotzBpyYKnEbILYQKsQbQoMErxxE+0LoEAzECRIFCQEtP9BPBn/zh0Sx FOPk/2Oy0qNCgv1o5BD/KMwfHioIBhRy8VLHMX8haU/hJbswjXczs9Bs9IGUoW456T0R7ymz4j6G fTmild6HqL9Gbm2r7bdIE+k/VJ4xFKm4nyjkzffkhidcb/cHwzObXPTyLvUor+3b/eJaZeV8qOlr CHfpON8rfjhy9JpGrhHav3LZii/mxk8DE2lXvUg7+8aOmphiCNtIlEyvMpd+SMJ5vrH9iTMKt3ZM Bdm79bvOyMWe9WAdcrO+VqOIU3FERSvJivZf3heS8MkKP+XjQSP+pNV5RFR9uBdvsNNk8oW6nq66 xqgD6kBN2bnAl8rJHjMJMMtHsV64xpijhpJW2g6PE0I+mkfm2L4wHZi23AeZ9vAVzuspxaqnsFgM mAzAgK37vkYcOAaMF3Rxragy8R+rAn53MLdKijuBtauVyPP9jx5Q8J7fIkjcGvYhGg4H6ILb0404 ne3/JsSl8pBk3aW0qbCxlEPA24mwjom5G3/ANFsiqfH811vT+D9QjI0Jlp0FivtPRl1/yuI9bp4Y oPrAoEKoz4p/wlA1QG3q2T3xtySB7oyBtUHb6k8mh72fuv4eln4/dh2WcjbQRHODq8PHWznn1fRq PBMUPIvll846CCInt0xcqMjwuFKT4e1mhLE2N+OXG9KmF91wl+A1xMKFrEebFbWarYR7ySN2d7e5 5YYRqM8JU8q56eGRiFOelWMzxTzRcT0tzhUK0w5ZpTUHycjtaSSjOd5JeTJ1zZOP8pDiD2FvxcM2 ceIMruodnOCT+rC4FTsrq7TvfHrkGS2Fa49doWYjRQae5JpFZEDFvIpv5bz4OiuodNBT/i7K5pSQ 6LwBHQjkX2RCmPkNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMzkgMCBvYmoNCjw8L1R5cGUvTWV0YWRh dGEvU3VidHlwZS9YTUwvTGVuZ3RoIDE0NjM+Pg0Kc3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7 vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRv YmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03MDEiPgo8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6 Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgo8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0iIiAgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4K PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiICB4bWxuczp4 bXBSaWdodHM9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9yaWdodHMvIj4KPHhtcFJpZ2h0 czpNYXJrZWQ+VHJ1ZTwveG1wUmlnaHRzOk1hcmtlZD48L3JkZjpEZXNjcmlwdGlvbj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8L3JkZjpSREY+PC94OnhtcG1ldGE+ PD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDQplbmRvYmoNCjE0MCAwIG9iag0KWyAwWyA3 NzhdICAzWyAyNTBdICAxMVsgMzMzIDMzM10gIDE3WyAyNTAgMjc4IDUwMCA1MDAgNTAwXSAgMjRb IDUwMF0gIDI4WyA1MDAgMzMzXSAgMzZbIDcyMl0gIDM4WyA3MjIgNzIyIDY2NyA2MTEgNzc4XSAg NDRbIDM4OV0gIDQ3WyA2NjcgOTQ0IDcyMiA3NzhdICA1MlsgNzc4IDcyMiA1NTYgNjY3IDcyMl0g IDYxWyA2NjddICA2OFsgNTAwXSAgNzBbIDQ0NCA1NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OF0gIDc5 WyAyNzggODMzIDU1NiA1MDAgNTU2XSAgODVbIDQ0NCAzODkgMzMzIDU1NiA1MDBdICA5MlsgNTAw XSAgMTc3WyA1MDBdIF0gDQplbmRvYmoNCjE0MSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAyNj4+DQpzdHJlYW0NCnicE5Co6eF++b6F++f3Ewxw4ABnAQCh5gabDQplbmRzdHJl YW0NCmVuZG9iag0KMTQyIDAgb2JqDQpbIDI1MCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDAg MCAyNTAgMjc4IDUwMCA1MDAgNTAwIDAgMCA1MDAgMCAwIDAgNTAwIDMzMyAwIDAgMCAwIDAgMCA3 MjIgMCA3MjIgNzIyIDY2NyA2MTEgNzc4IDAgMzg5IDAgMCA2NjcgOTQ0IDcyMiA3NzggMCA3Nzgg NzIyIDU1NiA2NjcgNzIyIDAgMCAwIDAgNjY3IDAgMCAwIDAgMCAwIDUwMCAwIDQ0NCA1NTYgNDQ0 IDMzMyA1MDAgNTU2IDI3OCAwIDAgMjc4IDgzMyA1NTYgNTAwIDU1NiAwIDQ0NCAzODkgMzMzIDU1 NiA1MDAgMCAwIDUwMF0gDQplbmRvYmoNCjE0MyAwIG9iag0KWyAyNTAgMCAwIDAgMCAwIDAgMCAz MzMgMzMzIDAgNTY0IDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgMjc4IDAgMCAwIDAgMCA5MjEgNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIy IDAgMzMzIDM4OSAwIDYxMSA4ODkgNzIyIDcyMiA1NTYgNzIyIDY2NyA1NTYgNjExIDcyMiAwIDk0 NCAwIDcyMiAwIDAgMCAwIDAgNTAwIDAgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAy NzggMjc4IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcy MiAwIDUwMCA0NDRdIA0KZW5kb2JqDQoxNDQgMCBvYmoNCjw8L01ldGFkYXRhIDE0NSAwIFIvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4NTc1Ny9MZW5ndGgxIDE3NDE4OD4+DQpzdHJlYW0NCnic 7H0JfFRFtv6pqttLlk46IXuA7k6nyU5C2EMknZUlAQIJkCCQhBAIKBAM4IYSFxSDCCqD6DiAC4ui 0ukIBnAkOm6ACggCLgNBgojKiIqoA+S+71YCyjze/83Mmxl/858+N+er5ZyqOlW37nfvbeiEGBGF AhSqySkaMijo5O69xJe0EkUsGpSTm6cM1VcQu2EREW8ZVDiiaOHpZw4Tm1tN1LJmUNHorF5vnLmW +BgjUd9tQ4uK82bET9Oj/evotWtBcdHgEXduKiO65m4i/74jipJTO40tupWI/Qh7eWF2QXHp/juO o/9ClPuMyRlWMtxefSdRwctEAcsrZ1TU9N87MJZoIuz8ocp5c6zcdrIv0bwmIkPLlJqpM2qHro9E V4hXP31qRW0NhZEX+nOiP/PU62+eUpc7L5Po9pVEb2+rrqqY/OnjW80Yf742XjUqOg0LuQXlF1GO rp4x56YJLZFnMFYJ0YD466pumHl++0U9sSrEw5XrZ1VWzHnhmYvEBhVjetUzKm6qCT5ono32h9He OrNiRtWSXm+lEpvaTOQ9oWZW7Rw1miYjHqtmr7mhqiZyc8YPRFMxH/9q0tZev2d8bvNvvirzT//e GI5lhDx5vMtrWvrO5jtCz8+5eL95onEkil7SXxOkBltbLo010/k5P71vnnjZ0iF+k7Qa/560mAQV QDmZKZnGYLheGJfDKkRvtox0ZNQ9puuJLh3tqVhDU3gg03GuFzpFx4XSQvFqM92ULSOAFA/LtpKT rOe57v62PNbTYGPbncRUVUXr5boCbaYUpO/POmve/JI+S60ihxbSVQS2Ymh3La/cRQ74z0S5COmD vD8JhWgo9Aw0EVoEtUInQUugBdD50JHwdV2tf8NEqtC9RWbdGIqCDkXerhyneKWWbMgP7oihp+hC 8TKG4xRn6ALft9QTmh1+UVqKtnbk62AfiLKP7HsJRWopyp2uNrZC6tdaKpbQEOTPI81DrDlICzDm COSvgZoQezrvr1YiH4D8Nfr+FIC8LzQX7X7S2sDfhBgnwx6kaBsSvhjX1D4O+aLPuKvF4JF/rrAx bRt/WcYeCYeG/qPH0fbIf6t7lk79o8fxiEc84hGPeMQj/5nCNqjbfu0Y/lrRRf77xOoRj3jEI7+m MFK3GaFm8vCmRzziEY94xCMe8YhHPOIRj3jEIx7xiEc84hGPeMQjHvGIR/75ov0/2F87Bo94xCMe 8YhHPOKRfzcRxyiLf0wzxWuUJe6gVPE+RYt66qV9Z0qcpGxxiKZr35lS+tNU/ioVat+tEk00XPtu FdrK71ahHPWL71alKx9QnP4t6AaKU6aQXb8OaRR5i10UogyiIcrTFCGWU29RhnKjLIfxYIrhS6mz ModixD6K0UWgz6epk1JHQ8QG8lauoRilK4XwszQMMSUrd5NR8SNvfRFFaPNQAqVP3195Of8loq3V rx2DR/71wsdQKPRmaCC0L9QXOgBqg9o76mx/rZ/Wp9FAA3/teXnkrxX/ngbG2NRqWdDryRg6wXhN 18sySNb3zB3s5wybNIiqqqgqzOksdSb0H+WkA+SUZiOlTswYnN86uXiAe9Kg74onTpyYHNWzuGI8 vVX1Tw1e++5x1VWHGKDBP3dwj/x7CvvfXf4OV4/8LwKW+bVD8IhHPOIRj3jkfxTPXcoj/1Bh0Xj0 YV1ZO8qj64Bwh2JRLKgJYnGsB0sKlXY7Y1Y8Jv0fnpR6/AMD/9uFXUX+f72gBAk5P50QjGOaYbqv fJrpR6OK12Gj2kZe5A30luhDPupF8iVfoEmiH5mA/sALZCZ/YIDEQDIDOwHPUxAFAIMpEBhCQcBQ 4J8pjIKB4RQKjJAYSWHqT9SZIoBdJHalSKCFOgOtwB/JRl2AUWQB2skKjAb+QA6yAbtRFDBGYixF q+cojhzAeOoGTKAYYCLFqt9TEsUBu1M8MFliCiWoZ7HzEoGplATsKbEXJavfUW9KAfaR2Jd6APtR qvot9aeewDTqDRwgMZ36AK8BfkMDqS8wg/oBnZQGzASeoSwaAMymdGAOXQPMBX5NeZQBHERO4GCJ QyhT/RMNpSxgPmUDCygHOIxy1dM0nPKAI2gQsFDiSBqsfkWjaCiwSGIx5QNHU4H6JY2hYcCxEkto BLCUCoHjaKT6BV0rcTyNAk6gIuBEKlZPURmNBpbTGGAFjQVOAn5OlVQCnEzjgFV0LXAK8CRNpfHA apoAnCZxOpWpn9F1VA68niqAMyTOpEnqCZpFlcAamgycTVXAG2iK2kq1NBU4R+JcqgbOo2nAG+k6 9TjdJPFmuh54C80A3koz1U9pvsTbqAZ4O80GLgAeozq6AXgH1QLvpDnAu2iu2kJ30zzgQroReA/d BLwXeJQW0c3A++hWYL3ExTRfPUL3023AJXQ78AGJS6lO/SMtozuAD9KdwIckPkx3AZfT3eon9Bta CFxB9wAfoXvRaiUtgvVRiY/RfcDf0mLg43Q/fH4ncRUtAa6mB4BrgB/TE7QM+CQ9CHyKHgI+DfyI 1tLDwHW0HLieVgA3AD+kZ+gR4LO0EriRHkX9cxKfp9+i5gV6HLhJoot+B2ygVephctNqYCOtAb5I TwA305PqIdpCTwFfkthETwO30jr1IG2TuJ3WA1+mDcDf0zPqB/SKxB20EdhMzwFfpefVA/SaxD/Q C8DXyQV8A7if3qQG4FvUCHybXgTulLiLNqvv027aAnyHXgK+S03A92iruo/20DbgXon7aDvwfXpZ 3Uv76RXgAYmIAniQmtU9dIheBR6W+CH9AfgRva6+Rx9L/ITeAP6R3gQeobfUd+kovQ1soZ3AY7QL +CntVt+h4xJb6R3gCXoP+JnEk7RH3U2f017gKdoH/ELil7Rf3UVf0QHgafoA+CeJX9NB4Bk6BPyG DgO/pQ+B39FH6k46Sx8Dv5d4jj4B/kBH1LfpRzoK/Enin6kFeJ6OqW/RBYkX6TiwjVqBKp1Q3/Rw +n84p38pOf1LyelfSE7/QnL6F5LTv5Ccfkpy+inJ6ackp5+SnH5KcvopyemnJKefkpz+ueT0zyWn fy45/XPJ6Sclp5+UnH5ScvpJyemfSU7/THL6Z5LTP5Oc/pnk9BOS009ITj8hOf2E5PRWyemtktNb Jae3Sk4/Ljn9uOT045LTj0tO/1Ry+qeS0z+VnP6p5PRjktOPSU4/Jjn9mOT0FsnpLZLTWySnt0hO Pyo5/ajk9KOS049KTj8qOf2I5PQjktOP/IqcvrKD0z/8uzj9sOT0w5LTD0tOPyw5/bDk9MOS0w9L Tj8kOf2Q5PRDktMPSU4/JDn9oOT0g5LTD0pOPyg5/QPJ6Qckpx+QnH5AcvoByen7Jafvl5y+X3L6 fsnp70tOf19y+vuS09+XnL5Pcvo+yen7JKe/Lzl9n+T0fZLT90lO3yc5fa/k9L2S0/dKTt8rOX2P 5PQ9ktP3SE7fIzn9Pcnp70lOf09y+nuS09+TnP6u5PR3Jae/Kzn9HcnpuyWn75acvlty+m7J6bsl p++WnL5bcvo7ktN3S07fLTl9t+T03ZLTd0lO3yU5fZfk9F2S03dKTt8pOX2n5PSdktPf/g/i9AQP p3s4/T+G0x/9P3H6oX8Sp2/ycPq/gNO1z2TatXPHh04HUEKOfUQKziaBJa3IeYNd48Bog8A6o8EV pbj+b8QVtoaeZz14X/6h3mnNiQo+z7XfK44WseBVJ3iqoMO3AtfkX/pqv4T8+FWPShxPGw+3sQuu lhuPrNO98rd9IMb0P38kzThv/5XmVzhgyopOZn18yc/fHBDYKSg4JDQsPCKycxdZb492dIuJjYun xCRKTumR2rNX7z59+2EF2n+ncxbl5OYNGjxkaH7BsOEjCkeOKioePWZsSek4Gj/h7/po7H8W8Rfl 7dAdzVd1/UCDj9rz/7Znz5k1utiZMfCa9AFp/fv17dO7V8/UHinJ3ZMSE+LjYmO6OaLtUTarpWuX zpER4WGhIUGdAgPM/n4mXx9vL6NBr1MEZ5SYa88rt7q6lbuUbvbBg5O0sr0CFRW/qCh3WVGVd6WP y1ou3axXejrhOeUvPJ3tns7LnsxsTaf0pERrrt3qejfHbm1i40aWIL8kx15qdZ2W+WEyv0zmTcjb bGhgzQ2rzrG6WLk115U3r7o+tzwH3TX4eGfbs6u8kxKpwdsHWR/kXKH2mgYWOpDJDA/NTWvgZDQh KFeEPSfXFW7P0SJwCUduxWRX4ciS3JxIm600KdHFsivtk1xkz3L5J0gXypbDuPTZLoMcxjpNmw0t tjYkNtff32SmSeUJvpPtkyvGl7hERak2RkACxs1xhd7SGvZzEZ0HZpfc+0trpKjPDZtm1Yr19fda XWtGlvzSatOwtBR9uLgjr7w+DwPfjyXML7JiLL6wtMTFFmJAqzYPbU7ts6uy52o15dOtLi97lr26 fno5TkxEvYtG3WxzR0Q4t+LOG5FrrS8usdtcGZH20oqczg1BVD/q5sZwpzX8SktSYoM5oH1ZG/z8 OzK+pl9mqi7bZE66a7n8UZfXlWkR2YdgO7islVZEUmLHnPppUNWP6iv7wQ1SytDKNRnnY5rLK7u8 3pyGerPW3qVzmO3W+u8J599++qsrayo6avQO8/ekZbVdcnmjwX4p70pIcMXHaxvEkI0zihgHynLv pMR5TdxlrzFbkWD5qBBrW1GalozFt9m007u4yUmTUHDVjSxpL1tpUqSbnMkJpS5erlmaL1mCR2uW ukuWy83L7djHL8orPdhl7Hb5x98c0im3Os3FQv4f5qp2e36RPX/kuBJrbn15x9rmF19Rarf3u2zr yLF2AxbcpTiwUkPs2HqjxpVoFfjROfLsudPKB+NSQ4yuTtklIpKXtud4pJBdYf+Ov9yzVijx1fpS HHq5/yc3GYzYwLKGWfNc5vLB7VjqbbP9lY2a1DNaK5n83KxjTq60hCvLA64oXxGeb71AwEo3nl88 rr7e+wpbHsiqvj7Pbs2rL6+vaFLrJtmtZnv9VlEiSuprcssvnf4mddviSFfe/aWYRDVLw9bmlNVg Z4tGNjjZoqJxJdrfXbEuKi5xc8azy7NKG6JhK9lqBT/LWq7VapVawaoVKJ/hqnBzo/SP3OokqpNW RVbIcmUTI1lnvFTHqLKJt9eZ2wfqJgdy4qZd2aS0W5yXvBXUGdvr6tq9Yzu8jbCYNcs2Av+TNLaL RjHZxSW/3DzyiixNIsr0pmLxNX8eb5YW8SdxGnd3izjt1nexNImvGkW8JSMzWLRSuThFq8UJOgpV yIwaM3IZ0BrkVahObRbHGnNzU51NSBO6y9QdG5e6VTO4Izqn/l4c48/hLdSCiqPukEhpOeLOyurI 9OnXnmmMT0o9muktjtDXUC6OiKO4H8tWjbHdU89kmlDBxO3kzxhegteIP5ILyskpPmqM7pa6eod4 B/ZdYidewrRmO92mgFR0+JZ4Ca/gFrFFbO6wbG70C0ilzFqxBKehGbgX2gI9A1VollhPC6BLoZug CvkDLdBk6AitRmwUGxHnWrT3ByZDZ0GXQhWs7LOov05DsUFM197Pxf1iOd76LWKxeFimTyONQPok 6rsifQJlLV3dUf4tUs3+WEf9oyiHIF3ZkT6C+kikK1DW0t90lOeJubLdnI50jah1d7WYM7vCboWm QAVyy5FbjqVbrj1mAZm4S1wvR2pAmop0RnuK5brNbbPLc3RbY2h46hos6W1Y+tuwcrdh5W4jBab5 l3zmt/skifnwmQ+f+fCZj1VJEbUYr1Z7JgWaoVaowLrXYt21ehewGbpX1t8NXAZdo5XEjVjHOER1 n5jujrVgk01t7O9MzdgupmCpnWJKY3iX1KU/l7y8tY2I1K8j9dd8q6S1qtHLV6utaozo0p7C67pM P1FJt0I5BQGjob2gOVBFVLqjky3bxHCaYSSnn2UBXyAWKAt0SkoOC9whUqnQSNiSgSKJ0uEQZylL Z33LvWq86ryE2cvqleLl9Cr00s0SC8RSISwiWWSIEaJM6JrUZrchrScS5yB9Ws9lPmt8XD7NPnt9 dC59s36vvkV/Rq+z6lP0Tn2hvlxfo6/TL9Ov0Xst0y8z8HKfGp86H2H2sfqk+Dh9Cn10FgNbk7lQ yL+qBDRDa6DLoArWuAz1VjERWoazUYalmKj9QR4goWSG7kW+BakOJX/4+cPPH7X+qPVHLQE1SyG0 HFrTYdVftlxqo/mf0SzQGFj9UOuHtW0BntFy0KEomVAyoWSC115+ARGagVZoIVTIuhao9jJz4bIt pcNeDtVL+xnpc8nm1NryC86KmOY45opja+LYsjjmTM/ITHVGAQIDA8vsZY6y2LK1yiz7LMes2Flr lRH2EY4RsSPWKhn2DEdGbMZaJdme7EiOTV6rWOwWhyXWslZZWrCpYEfBngKlrGBWwYIC0RenrtGd kJIq0yiHlm52h0ek9vXPHMA3YTplwNXQo1BBFmAyNAM6C6rwTUALiDgZmgEdAS2D6tDieY1egJYO m1a/Wtq0nGbnV9gFJv6cO63niMxhoNwy6GqoQN/Pwf6c9G7PbZL1LmCLrB/R4b9G1luAl9oI2Uaj uXEdaIFmQMugNVAd7RFjcYsYq/UPtEBroJugihiHY6wYy5/H8Rx/TiQ6TT2CLRQSgieiwACjOdPM fbETTGyDxJUS75OYITHa6TfUdG6o6ZWhpnuGmmKQ4bGUCcNyiTanT6bpxUzTiExTXKYJvYWSjUw8 WKJeQ/alxOESE51BNtNPNtN3NtM3NtPvbKbZNtM1Nq1dZ1zBJh4k0UdDtkLiUIndnD4W05sW01iL qa/FlGliqxhGpyyJXSVGasi+fdE/x5+8trNvKQc9MXd6nAU3epkw1Z2eiaTNnT4IyUV3+iokf3an P2x5mf3E5I2NnXNHt1oyg9lZNkTRyt91pN+wIbQR6RmkU5Guo3TmQPq0O/0Ozf8ptH8M5Scpyqj5 P0GFst1qNkTW/66j3ePuxEkY9bfuxJsx6mOUKEd9xJ3YitqH3Yn3IXnInXg9kqVuhxbgdHd6vCUz gE2laK75VpKDa5EUdIw4GD1fj3RQe+Ncd6LWKkcboIllu+09kMRoUb7M7FQoh7O47XKSXcguu+hM dhl0JDlk6sf8ZfAmipKp0W2/A73oX3S0Wn5I365NnL5n/u5VluMvY35jUPyUDXFvtOzbqi2X27In sYk5tljes2+3vBHdxMa4Lc2JTUYYdiQ2cbbZ0oBFdsGXsy2WTYlTLc/bpXWtHVac6tXpSZbf2sdZ HnWg7LbckfiyFgbNwIzHwFyaONBSkL7RkudoYjA70zGY09uSZr/B0h/V/ZrYkMaNlh7RTVooKehj 4xZLPEbsZpehjO67jfcmA5vrTDTMMUwyjDGMNAww9DQkGayGLobOhiBjoNFs9DP6Gr2NRqPeqBi5 kYxBTWqLM0H7ECdIb9YSvaKhIvNmrqH2eY/2EMiMHNeOq5PI5/lFWcwVmE/5xVmuvgn5TQZ1lKtf Qr7LWHhtSQNjD5Si5OKL8HxaXIINqlUtjNTearcSY8kLl0Rq6fyFS0pLWb6ruZLyJ1ld54owD288 nevsWWEUMi8jLCNwYED/vJyrQHkHJvwsYQm/lLAurhX5RSWuZ7uUulK1jNqlNN81SHsf3spn81m5 OVt5jZaUlmxlt/DZuaO0enZLTullN4riNXCjdC3R3BopSnOjKNYo3QqkG7ZpVG5OQ1RUu9NrbIjm hO3zmnSa2t5XNIZAX4VaAjfelaJlX9G8q+aG/dDemf8vO/Ml5i878/cl2VlnzanB4YBLokNzaejr gEODo680b/zZbHe0h1NKDjmOg5XKcRj72Se23Qe7oMOHG+GT8I+Uqqy/wZk1VnwyuVL7VKLcnlsF LXctnlcd5qqbZLU2TP6k4+OKbuWTKqu1tKLK9Ym9Ksc12Z5jbaiovIq5UjNX2HMaqDK3uKSh0lmV 465wVuTaK3JKG9ctyM6/Yqz7Lo+VveAqnS3QOsvWxlqXfxVzvmZep42Vr42Vr421zrlOjpU/Kovl F5Y0GCmrFK+1Mm3kPt64HsojbaVZIeaagfLiGGALuz1ym0K4bfkklLp87VkuE1QzJWUmZWomXJ2a yU/73KnDFHb7AFvkNrahw2RGdYA9ixIoLHdazuWf2traObUazJ2bAJwzN0xWzsFVayvKd+Vpr8np rvRcl7M8p5Rp52Nuh2SXOM070vek81npC9KXpq9O35Sumzu3FNWBO6L2RPGyqFlRC6KWRq2O2hSl 1wzjS7Y401dHfR0l5mI7sTmQ3Bw55lyk+NGKc+Zq0dQSBqiFtg+XMDchuyQziirx0Kv9mc4k6gS1 Q3tCi6A6+gNwP/Q49DuoQncBH4Y+BW3UakSSSMoNm5ajjViaoLFOmEhtTOmd2q8JacWU9rRoXHua O7w9Tc9MDUPqzujpnemP529G24C7oB9Bv4D+GaoTqSJVdj63fduW1lJtAkP4hMIcDWoT5rAEZJi2 3HNqExJIU22H4xTANYFdufGJ1c4lLAVOCBI4ydpardlcLb0kMGi9JOgeINIVkAXaWb6pkXoM2gr9 vG2oekF3HdnbpqstQvurnM93KJGDVtBqiqYzrAe9Rs3g8nV42Cmk5TSI9tAm8qOb2W4spx3PGBvA GBYwfx6FMh09Sh/SeLqBTlAL3p7z6QgLRD+5VIO3xv7qKWA+LVK3wsubsukF2sauZ0WUjPxgnoil cNBStZlCKVZ9Vz2M0u/oBItWG2gwcp9RAJ7SF9CDeJ2eTrvUC4g0mibRejafncLTVTktVnop9ep1 NIA20wcsH7lhdLPusNdmPB88SE+xUNasHlVP0iu4m1ahpztpESJ2UzPvLrJ1a8hK3egaGk4VsN5K H7JOrIdwqjFqlvooatfTtzyBvykMiCOBhlAZLaEnsBoHqRUPAz6sN55xNuLYx/6k0/7SbT7NpVuo DpGvQ9vnaCvrwXrwUDwhcswwjkbDtpTWYvxG2svyWSlrZq+KtbqUtgw1SA1WT6oqxVMJIlxNr2KM sywFPhhBRIk5Sldlji714h2Y4WR6nPbSPsRxBOv+Pf3I4nEc47fzBepYdYN6grSvvVqoH42kcTSL 5tGN9CTO6mv0On3DznMveO5R3tDdojujPoS17UZZiH0EvIvQ92KcJTc14TiIWQYwK2bRjw1no9hU tpStYE3sQ/Yh13MbbpZfCJfYLT5R+uh0ahp6CtHe6LFLxlI1zsDtWO2HMN8N9AbtZMGsG0vCjA6i /Tk+gOfgeIrv4UfEQrFUuaC7p62l7cu282o9GbDLBmEd5tKzWIWvWQhiiGPTWS07jsiX8ReFnzAL u+gtMkWxKBWLxHLxtnhPuUHZqHykG6Kr0G00VLTNbNun5qt3yycUPeKKoUTqRX2xf6ZgN12H+Gpw 3EDz6Q6qpwewXx6iNXjibaIdtJM+oD/SVzgDxGyIeRpGn4Fdt5A9gONR9hx7lb3BdrJj7Jx28Cgc sbwPz+DZPI9P5QtxLOd7+UH+uegsKvEeXodjldgiPgRPK4qqS8UxWLdYt16/2xBrGGyYZHznwumL 8RdLLx5po7aItmvbVrS92nZSHaPejPgdlETdEem9iPJR7MG1OJ7FTtxCb9I7dEjG+i3jTIcdH8bs 2A2JOGsZbBAeNoawYWwkjtE4xrJxOCrYJFaNYwGrY3eyu9jdbAn7jTxWYm5r2TNsC46X2DYcH7Cj 7DP2BfuWYxNzgd3s4DE8mffHTLP5ID6Cj8Ixlc/CUcNv4PNwhtbzRr6VHxSdhAN0WyFmi0fFC+I1 cUD8pHAlUUlW0pUxylTlLmWPsk85rJzXWXS5umrdKt1r+kh9L/1o/XT9Sv0m/ef6Cwa9oRAPrPMN Bwyq0QG2egvz3nzFP2Ml6/ewWl2QchM/iusiTNTo7mWjsWJ6XiyuFw+I93VT2BlhZR+xejFNXKc+ JfL4j2IWG8N3sChh0aWJKXQ/qWwjP8bP8pNKMCvmp1is8iB7ic8S2Xing+j2K8HKXbrP8ax7iNL4 bayZvyHuEnepv6c03Sp2VLeK7yOr0sI70VFc1ffyR9DoPT6NL6YSpZfuPE3Duj+juwnrPZAvYvHi gLKKTgg7/w7vVyvAGu+yoUo0n8j7s41g3IusK51ms6mG/YacbDv7I2vCU/EGsZ4VcF+cLRc3sb54 8H5X2NgB4U2lWoysGw9mhfwMHy1e1u8VvfHis5fep1uYYCk0//J6tdFMXAHLeQw4LRdssp+lUhg9 Ar4/2/ayxti6w7rF2GdPiEQaRSk0ge+mNFwbJ3CU0D2UStu0/zdBKXwlzVfr2GTw/jDwJye8uVEy 8wFban85fQHuFyE8ClxYhlF/BP/vAuvnsz/RjcyKK6uZYhXNcr+SC2YqB/8uxjGZJqD0OD2k36zb TyNYKJFibVuFXf4JTcQ95zjGj6B0xDeOnlASEbUVzDwbLR5vG0xOHPfQbsbpNsQ8ENd5oTIYzLtC nY4ZTsM9qgD3xJ00TX2EsnHuRql3qYupTH1CHY931SJ1A/h3nuqmPnSvrpSP0SUovcCxO9nruB99 zBaDtwfTR+AjBwujL3C8gPgH6rZTvXII3Jmh3q9+QMFYjyis0CTcRVtpBv0J6zZYNFPPtuG8Qc0T NbhDHaWR6nrVwrypWr0ezPsyrTXowD111FW3Fnt3sTKFpyDeOAphyagdr1stDolvlBq8anXGbuys fTQGnhzWwNl2/gr4zcB3uEmnNPFXXhTkbdAymxmFG/W6HbBzEiyOvNh1bCKFJZjPpV9MH24+mz7s YjplIG++AOiRYguwBTgArLNCF6yi+YJTR+exq5vRvlVtZW/i6cEXe6V6O3+WwslLbXZ69enXi5zO zF5G7TPFoK62Xt4RP/pN7UPO+N691tNLiLdJDHnJZBAmZycf5Hs7TUTeitkZ0svbqfwYbj53+uzp gMD+yacp43SG+bMeKWy2fPBJYHk5zC669e7Vp2dqSHCQQWiot0dpNay6W4k+Ozk5U5nZPTOzO5RN FfG9IzIKCvLDEi6kZCZp1UmZ2v9IWIir7GVEbsK+efylpvC3w3/wFb5N6o+NdkcvmSal9GJN6ueN CJma1LedXZAJDwNE9AP84MsMvqG+3LvzQkzMhF1e3GgQEX5I3UGCMKUXTSZvxU+bW0hERGiA9wzl D6EzKIAFLIzsvNw2/Ra8f56bcPFc+zQ75noxPUNb8gQ2e0LHK84NTMT8Yra2X06dO/uE8H7dE/p3 6t82qW9I76TEtIg+ws6ibw4Pz0hL6zG6su1jFntLojNtQI+YB9o+1O55xW1D+Xw8D3aiNKd9RcD6 AH6P730B3HulVwCtxJMOToPXBr+oQj3T1wUVT9S2xYTTF9PTzenamTjdA1c+m8CCu8V0473N1DdY r+fBQaFdOZ//SNWyx1nquVtXDbdFDL2tbZajYMqDrP4A68PUmfE5X7WteOPgpvr1jyGG7ohhjIyh vzM6Tok3DtYJDB6AIDqB0Ly8EUD7x81CXxdc8vR/D4JN6NQ7JDQkMNhMht59+gT27hXTnXdfWbX0 8bY9P9y6epgtPH++bnJ8/pSH2m78oG1XG5vpyP2SXffGB676dY/JO+cS5VrlD+RDq50RyTxZWI1W LyWZrDqrPtlnFs3y0ZdjBfBUP5IMIoa8kfrg9SIGN7uR2nMUcl5i5BYfHyrXMd3vUal9hA0UMS+x ciMzbtf7NIkYZ4SuHMNtt/IU7sSdcC/XWTnj431L2ld29tkJuMZaJ1Dy6VZz6wRzuvnsaflzsXVC +1I7Amy9bQE9A2zBtgAe2ubHvi1kZ9t8l7DvRrFv2vxHtZm0szqzbSNbSW/jebLIGVPKS0NfDxFe oeXhe8OFFyODovgbA2lLoNPXR0nzD7YE1wWL4CYW7/Sx+Jf5c//wsMexyLj2Jwy7OEG75FoD+7OA wND+2kqz2Z2wxFjhbvYoQ8eVJjegfubU2V4Gg48jMKhHWn6frKlL2zYmRi0t7GTyCvJK69kjr7Zs aoMWXRGr4yV43hWU4bRyXV2Xyf/FxpcARlFla997q7q7eq/eq3qv7q7uTjrp7qSTQEIklbBIWEyU Hc0QUAEBJYlhVYbAqAHUgXHGBXEgjuKI4i8QlgCO26/OoM6TefpUdOaZ8QGCmhnfDK6Q5j+3OizO /NG+9/bthfT5zvnOd07dTtUaDcbqtRYGER4341a8GffgY1gLQrJiP+pip8yiBhpsoZhnBmCkv0rK AWaYTDSD54jnYfrOvwD+WQKZwYhSih8pWiOj6JWaSr1SVzlbj7frn9cT/d0mGmv8N+0dqRT9bGVZ +UrOQBlFpYpX1TGdUej7MhdOkJHgoQy6TtEjzVsh4C6MKaBmwjgJgV8bOMwIUR9SnGEmy7QybUwP 089omSP4OfIW24eX7PmE/qsDZ6lBa+tquzXp1Gr+NRrcIMXIyLyrGX+h+fkP0zTPUD4af+E0c1Cz APFQyxzeO4cL92HtXo3GRSez2duHrYpd70VxJU6UeGu8J94fZ+M2um2ZDWJ+DZQQPVDrivJh+r1N NITmwDV8S/s3kwaGwmbUSmUijkVjkRgodRAARKuT/b6AL+hjtI64VTbGBdEjEq3E2uaikNY7Fzst sHKbYBXD4bnYx8Fg511zkWiAQWUoOhSrt+LitY4K+zDwDo/b5iRg4UR8GO9x58qrhlXZwIEKLkTG 39c5q/WxO7euf3fuq2tvfW1MdXtVZzCdjVUX1YyuHFdBtp3GTdfVb389//yX+QMPnnzl2/zpPQ/O 6diFq09vvT0rXTU5/xhg9BUEnBYs5kYPK05FaBV6hH6BRYIikGWQ7oml3gEKvR7yWw9kXkZdc7CO AsDfISu+BbIopAL8D8WCrVYof7BGz5kIA8Xot/D0RsVusVgVW2XWusa62dpjZa2i5zCJ4RNDxk3V TuIhamtVdG00YKrR1wPn8deplBq67S0OOWdzut0el1Q5klRSA9DP/xUeLzlqb8iT1uFug072yg3s 7x8/190xPEhkmQTKVpE//6o4HAxRPyyBz/gsfMYgXqCs0wnGao/gv6pCUGAQ6WANut1Fulpdo26n TquEr2dncdd7ZgmLuE5bp/0x468tW2y7jLssRzVHPX8QjnuOC/3h79nvPS4XDrCixucS3aInIOj0 HqNgDFSIV4sbPJvCOkEkxOMVTaLWzIhEoxU8NN04WHMf/Bp6veI01XXpsb6PySkmXuPdJOLt4vMi EQ8zOTDc/b2YmIJ9+H7I6dpPmxyzHUscaxysow/rFAc9ceBFYSXcFWZawz1hEhaP4O8hzsxYUZyz oVxYQzaRl6AA/IT8nXBEDB2G0uqSP5+oLXh0yyQIK54G1sBgSzskzfY9WnrK4OAmPX5J/46eoJb2 makTlMJUZOzV1YQvPGXfavF+ER6faant5jWrX7O8RsVFRwsgVhAYjFSJUGUFQKXVRauGcq1WR3RS eVXVMObZ2ef7oVYKb7vtpu1xWXxn646/ZMc/9f1IPHfx9LFerMmfk3EDfmTn2qeWth96473N8+f/ Zn/+q+F8GW1QTYYonwZ4luOJh5DhQv9eU7WeSqRaU3W9foxhrHFChH1Hj4uKhhcpFa0V71T0V3xr 0KEKXK9fE12VfiZ2KHY4fTT9SfQT+eP055EzsqmRK+rD9/UmkzzqIyd6j2Vxto+p2M9oeDd29+Ht +wNKKlMR6MOjenlzUfIIXoCcSE/+RzE2AwZks4oBINm724RNfXgz7Jd2lZLNpT2lpBT298/WrYHP 3kdOKgalAvdUvFxBQA/hkQcVx0sO4hBzlHBOXwJIRWeAJjYYToCaBOpJDXTUDbQMUImjclBVOhOM G6ysNiJFpZgkS6xWI1vicQOQS4YtnYuDVlhJxsRcbNCntdm5OGQOULbha4c6YcVr4UeNsQ4EwtBR pXIO4ORWwZKGkpQHgo+yT6XKPfFolMYhRVa3oGbPXU9Mbzi8uqvtgfwXG27MSKLXtsIjF897OOoN pR66Jty0fdza1q0L2PEbHlzYNOtX28oO3LF77dOjE4ESTlOnNW5b3DRheCBZHzT85K6m+Wueohwe hmg9BOgaQFV+oCTdZmxFY8yKlVGsuNiEXTogXMzoNVrMmoxmxJrMrNZkhqjyK3Yd59TpOI5hdVoT h0JmbD6CHwMFb8TbFbMGa/WcVstpWJOJPYIbIV44PE8x6vVWBm9nnmcI04e/VQRcp4aXFbcCX/Vb GatW0WGdaLkihtprVYRqIYBgeYqnWr+uOgPKo5Yf4Ac7am3VNjVgutMpFvIVXVqtVmC0DlAj7R3Y FbVFQZPgHEyYOXRgx+CrZOltO/IxfPbn+UfxvC5m3fn7yOODsyl/zQV/X6mZiCQcVEY9yWL7zOAt wTWaNdo1gfvY+wO6SlIpTWWmhqdLi/zLNCv93WSjd6P/CeZpfU+0P2pFUaweDna5PZwTMi9DTWUL S5By2bDk9fkZncBqYHd7bzgsOQ4DkwiMQwGb4k8R+VSSQJUdxiORD1+9v0vXQ/0Yfw1+HMVKtDVK ohAg3x/gSY+EJfomij6s8D084cXIYfwgPqNa7EQL0DzfQq2juvYJIB1YQz5VHRpYn7JMN5dOacBc iN4pEI1i7sAdpCO8Dq8j68JaYBxKNMAzo26YoRgXsUvsNwXbNG0BTctMEFk6ScdSD9Zqr9BYQ84L vpvAzMpr8gtmYv3Wu6ffde3tK1ctSUe9icyESUv3bLv31hcwq5n4zIHEtvV9iw50JYZNLveneKli z5o7/qumVEes1DtnABZ7wDsFqETPK8VL9csMyy3r9MflM7JWy+DVzCp2lftuD1vLJbUaJiomRS0T ng1SFrjjQDiO43EriLP7ewWkoeKk12rGYFyFYqTYjV5UrBQTpbi1uKe4v5gtFgt2h4eQg3eEHVmH 4tjs6HHoHGLRZYlyHgTniSGNolIFEDpYtWWgA8yIL9tyn1Hr0xLVhMAfJX5Zbw/4g36itcnmuKyP AkPwvrlIssAqZojPxX57eC6KmGBAFzUKJQ2VMrDLwugu8jrVKLYKe6wqh7Uu5yWLA/kzD9312ycW xTb/4t6359/59r1zXnwAW79bNPi2/eqxucbpG9avjk/XLJDNTb/5/YYb+3c/c98zN/TiwAE8Lj9j cHT35Na/NmSefOTZH8IQBRMvnGB2QBQY0SuHEHuhv9fhG6lRL6PCQuSwhinWNyDF3GruMb+Jj5IP 8Yek3wwmxUaMzIqZIRoWFOUvFS9DnAxDWMasUa6u1HyKtTBpP8X0tDnecqDHiI2iSXOYnEYM+Uwx IZZnFbaZ7WE17AvkFDIN2Z1WUydUuj5LM2iKH0gV9Gm3ZfVrQ86r79R0au/S3KVlhxwXMmQH2BEU OMhXCWScLvEf5IN8bRt+MH9ve3ZKLqCZGP/hRfZ1X7rVSPsQd4K/bQR/E1Ec5fAq5fBMKO1yoVxx YkluVaTL2GXq8nb51sld8Y25ncIO72/lXtM+78H4kcTrhteNH5jdOmTAWjPx6hNus8crm2XLBHwf /pn5bstOZBmBavAENAE3Jmfj6xM35BaihfgWMj++MLEgdwe+M7Gs5M7cJnaTpkvXxa2zrbNvcm5y P8I+xP3K9pB9q/up+HOJ53J97AHujPFz0xnLmcSZ8iKdWZ+oQdV4eLlmNIdM3gSrDrxH1eJaTSmd HOZAvR54XQ+eT29ZWPPAxTyqVCqJUtla2VPZX8lWRl+ABxiIgWKIAUPWo3g2exiPWHEY/22IWKg8 P6uSysCJswWFTh0e06oLnLw8lQlGbG6Wc8mSJgpyXBeYi0ucxXNR2g4ZMcJCigxSOZ5yl85FGVtp wdWHfJ3mR0o27RS1+OWSTef2FGoftakgVw35OvV8h5ZOQ9kSb3i85e2dT/5h8bO7qyd+tOeVxdNW 4rIVyrJ587oqy6omN99/6+J18avJs3f1TLvrpb0dE7ctWn/NvPZNb62cc/usPe8vXt10y/JlTRUL MvnPxu5oXbt11fRx1QuBg66FSHgafMKDEtik5O5IHNd8EDmeYBewKzWruVX65aYV5pWO5eF7uZ85 DHpuUxEZwWkSgpQQNExQZpFOcxjfiASs7Es0Q2YDZlL0GXmJDMoZBSk8Fg1w1H37PB5kFigDebH1 ILLz9rCdsffhm4GNipSiriJGKWot6inqL2KLMOUwCZ6mGF4yEIOY/JGeGSgImsEC69cNkROvNqds BY6qLuBV7ItxNlOcl/3xaDxkluaigJWWTRyswsYg1E42GCJ6+UpKokCpOcFDuxjDCsw/bEjMEGAn TAEqIKRS0+J1/X8q+vWaTW/Pu+ON3y5/4L/fePxFkrM3rJw0856Z9bPTP/XLZCmOPX/zXw7uvXfn xmfPfZpfuXYhObTumjl/XdGz7d3l00po1Q1V82ZmN/CRBzXsYUR6bCRgnl+1WeyB4k9BOhMQulVx QTFdsdnV4yKuF7AMeeM/MSqwx1lVew91YlL4inLacWVpLQ114Uoy9Q10ZnYXaux0/aCjobBqoJlp Tn6srgSq7QY0Bf9FWfgUeqr+y3oGiMPPiy5/szjVv8ytwzxKnkaf1/dP+2YMO6P5KddT7mPT2HBz +NrwdbMFVkJhDEq2iV2AbibzA92IXYk2onP1zB6uvqEh14CaritrqCeINbLe4qb6HGFH+VAf06Do +ZF45AI0Co+CewcbrGPjqEHnP8I0wL/vY67eP3FtVXCsp4+5VqnSjU1XVBmum88OLyubOs04trjO +1zYl/UpPsbnnVY93NrY1Ugan3bUhCPZiBJpjrARceq0Pny8V3rsJ0IfHnZ3KnUNdarBFihjvlHj nzb+Bk+iurODYNTBU/zJuroB/uuWwZaTqnsVvAyexB/t5i21qqeNGD1h2FWa7NXjxo4bM47Rjqip rSHakrhedsXDsk2OxZOQFEdf1diJJgxrDCBthg0grtTYid0hKMKW9iIh4IX5IPb7RC8v0z0lgCwJ eMa4mlGdePzwiQGkyeoCyJDSdSKn5FFfJfoLsz1qhXk/NhVZOzG6dBaDqnPQ5z/6KS4u0BD9GT4c ajLMXCQZe2UFiUUjLHE57WwujBw5gqRIjFTydpQrZ+0utX9Ao0FbmNW+gtszTEdTz9CbVNHvJ8U1 XUvr/alw4x8f2JF/98Bn+c7P3sJt72Ed3tlZMysfz//pb/kFn36HXzr3Dp70f544v2HiJPuv9o6+ +rbfPXb79aNm8tKrEya1N4+4uqSm677w8EbmxXx7/4pYuOQBPG7vsziy9et8xXen8utfwcAl+b/l d/0V//o7zOGjGD+bP3joYH7Lk+Pqh1/fu3DNwl/gBe2Tx4y5zdHU+frmGXVNMw7esP2mhmvAw3mE NLs1i5AfhYiwh6gZ1o5DQRIMINAxKBDCoGacLzKfIg/cdHAzMJ8qHo74g4yV87sDKNSGu+hfbeKs hEOZOkpEfzz2x0yG+gc/MPC3L3Gm8MOv7n7tNR5uZdQzOYvVauYNQX2oWdK6rA7ea/P6fH4hoJXo sV+5kk692RkV6pxKq/PeosJ2OF7Y9gYL2x51e69LnZSHeUeF2WqEN6+2jreO5RuDTdJM63R+qnNG cKF1Pr8guIzvYrstG63dfLd9Q3B9aKt1K7/FtjV4yHqI/533UPAt65v8HwJvBj+2fsh/YT3Nnw5+ b/2O/z7wfbBEb53gIyHQK2AkFAgG/XqLwad3+z0+N0d0Ps5lc/pcK4JWPswH/f6IjXfa2myYfhXN 0keOKjYSdBISDAV2IFQwXB/er5g43sq43G6O03P+PvyDorfCa8gOi2LrI9nepiAO9pEvFUtYsTRb vrIwlt+GF21UGU/0QswKXloE0K4DdXUYz0JZMFjbbSlo/+4WS1pIdWtWv5YSED+A+Zf/fezmV79W q6uF/9Vi4PJRpg6oAiTVr2m7CBx7GM7hQu9Ibb4aCbNz8J83REbMzU+dKuZG4r9E8YfVLZMHz1xb nbzt1Jf4jfebEqGMTpatQvaX7A3nHll/rUaW2bRUMhubSWzwz1STRRBiT4ESDaIUGk5WK9lZaFZw A1of3JDb4v11Ypd3V+KM9/PEZxnTcLQqsTL3aPmW3I7YM7kPvR8mPkwa2Jo+8lmvdX5VDfUKf6SC zsr/uDwVOUUqgUEMVpQr0SQMvkDF6NhoeYP3OH4/9lHupKxjY1g2l/OMS+vzOoPumDvpyqbLx8TG V0zHM8RZiYeIjUd8zVQ8K9Za01bTVdNTw3mz3vJmxPA6byyYFDOsljBBT7Aptz72aOx4TheuUWqa a24kNzKtmlZtq641u0x7u/d2X1uwM3Z7YlXyLu09vnuCm3JdNW9mPsp8EfshJs7krCGfXorwIZ9b iuZiiGFLUGUqFGMiRcNLckw6kqys1LuLkh6Pm6ST1FM2Q+1D3b6mUp0a6NTVW1dfQe/2jhqrzooT 9ifO9mNDMOsn/qlsKjS8pIw+wI+ptCugwSH39LD9LMPSTYPZVoFYHGYxCPs/KXKJ1uEgU0tMVisd zWYYI+DLVp5MtYbpXeu26poX8J+QhOZgAbIwJJJUqnbSAPjOYEt7qqWdHloqY0rP+NRpYCbQcS31 0I4B1cE6CgIGbuqlJjWpeAqlvqeadiwhsdRnKqJJIYh1Xp/oI1ptPAbCKhdPCvEczujKcjgajOeY ClyWYxK+ohzOatI5JAciORQsZypzUFtAAqi9QtwU+jQYeL+jowN1tF8SqIi22wpSVBuVKnPlQOS0 PxqNVkq0awP7sltl+EK7xjZUlqlNOWbv/WPndH1ycrArN1X2BBKTcmT8kzc+tO3OwTvk2dUP/PKa Vw/f1NzZvv/Faa9uGjnDR/YFG264++ZDU+WqaAez+KdSiSzEDi6f97hVp6tbN2n50+5zS3xPrGh6 YAr9TjJG4y/8VWMFro5hojTogxlMrw9lQg9ZtwSfsD5hP2A9aDdyQfjtoWS+w7XCfT+z0f1r5iHv LuYIozcxFpYExjEzGU2G420x0BhYs5/4MD4MamPCgfCjmqSfwX3kk/221G4e831M/f5N5u1mYu5j MkrGqafH3DEu53c9b8MhW52N2LwKOKC+NixgqxASiKC6h9Ao33SjKlJTLR1qn/+bjnYQFO30KmL7 2Zazp+oGvjwLlENrjKMqvGGXT2vSyd64Me6WtT59KTK5YOBETSk2eMylVJfiK1VpB9TKjqhqdJqm 1T6+R8tGw7R4sMeoSqXIDWP/FAqNPPV490erlw08ctebK0Pz8l8dyT9/aOMBXPe7X24qtvucXqNm UT73zoEN+fc+6cv/Y3P70879T/9w+PxbeMqRcW6HL0t1YBSyJO0WuUGPM8pMo88YuId/kP8vXrOM X+bs5h9xbHEd9R0NvMdzgs3uDAQZnQt3e9cHSZLThnygH3Qhn1mKeiQxlLRYzERMut2I89c22XGh CMjaFbvG3nfhvw9QG9obozQWR9ZVKlEcjuK2KO06MVHJo0ajR41Gj2puD6gOEw/RqFU3tV66qd0W mTOEAY3FQXWEeqEj9Y0KyuWQq74YYn5v0OriZWc8aPVPw14XDAFbaBr2OcRpF81P2xQQMS3tuR8H RhhUEa/TSgmwOgKuhLiI5qbF3H4aAUmcxVe9suuV/NKP10w7jcvz//HVrNvlYdLtzOI14RJ5Y/7F d/MnX3xvrh+PxR4s4tEB6uvFkA/2gcVzuEqpUyrn+5f7t2Z3CruyR7L9ldw0sU3bplvDrdF3abt0 m7hNen0s5AtIETnkS0lRTqEG4SSLJaT3cTpqSonu6CRCQlqfzs/7CI6C/gjk0I5UGpXytKVM3oVU UZICh9oR8J32+wOcfhfHaXfV0T4z0vG6Jh0D73VKaVbfa1l6V0kqVJqBly727gqDovkE1Pbk5so2 KLSZSsSrUPEqKrwKFR+RYypUMXUzpkIV21bRfwh3q+ULhUnFCmKmZeBsy4lBgKtloFa9nsB/CRkd prya2oEqawdraZHHD3yJ+K9TeGgeusbTgm0SjYCcLao2mCV6vSenXu8almMKxHYZQBpLsMK7cHFn okIryxaL/bqp+ff55PBTty/IjqxPLj33RTabCnu8sSlZ1mVNuHLlyZs1ZPB0NN2ZT97ojybz9bMS nnBm5Or8LtnDKzcy7WuDSTn/waJml5UiKgGi9JxnKS7ek8z04aAyTL6pSs/qDbszzCOpw6k3UseZ d1Nn2DOGc+w5g75N06ZdAxh3abq0mwBjTmfQFxOdZDL14bhi5ny6QMjnkSJaAJXuFGl8WouaO4Mh X1yKpkqSBs7EaghADeb3lKJoHCX5JElSpOVEIk7cHi6RSu5CRRgVZaH8boOqe7NWG9LhJh1+SS3j 9ytpZFGRtKigWVQkLZFgQEUyoG4GVCQD29L/FnRnIeZq6eV0tU4H9P7Wcgk8tVBX6/TUEHqDF2eA sJ02tVPYRiEDENMkGrVBpQ3ElnNdkZcu4geP4ye+ndpklmWcGDP6W7MhXJItGzycnRIXzIYQOAXz v+aod8zNCwG0LyYsyVc2jZfz0+ZLol2Q5bLwKmZxYZ1/f/bMJMVrHGSbZyDbVOAWZYqBHZsmYsKb JLzAiyRcpVS1Vq3g2oQ2cUXxZmGzuFvYLRpLM8uM3UZGqEp7m6vaqu5jn2P7q1gTc4/x5SpmHAe4 CP+M2Clq0Qo1//Sq+Qf3ggKcoIwqe7TEIwgRbbKEsSQjepwKBU3U8kHVyEEtNXIwYrM12zfbidXe ZCeUO9fYL9hZO0vRsAOBntinEmgf+U4xGmqb49gaD8UJCKGvFJ6+TZynj8cbK2/aOIQVECLEWSal QqWidkJtIVCU+IuZaoglK8IpHc/JyURRojjBaE0gRKySbQQOh3ibLmUoReYoDHzYMgLpE9pSbJQt pehHRWhxIYWl1Bil0oMmMkAxTCV2IZPZqJyolFz0krTLBjpETWsQuJc678PYMwD7lJUv5ge72x/6 Z9eE++pD9dcRs3hNwHl7/4b88re3TJu398G3xq9cMtzh8DGQ4qb0XLv0j8/9/dX8yw/GZbx+Xp0U j1fIt+bnjKw5/7tve5/8v7dMF4pc0Rwgn4OUt4KeykavKEsklUslhVpNUpKVojTHdlMVF/IRKSKE fHYpIoZ8WIrqQz6bFLXbINw4QSQUN5GjBhdZ+lIxom/jurh+jrnA4SzXzLVyzGzuZe4Yx3AsfRqn xhDXd+G7ffS1sMgrAZXG54TbpC6pX2KyUrPUKjEvS8ckMufPgB4gpgYbQAfYFSJODbOUSoN0lP89 WIbsWggmsmLwyFCMlGSzZEzZ5LgIsZPKyj+KCro+/yt1rWanC39lbGChKDqjjBhjx7Mds53kJk+b 527Ts9aXZY1dwFlZkYmXKxgqoJrILfh5t0gwyToVJ2l2YmcfY9gvJs36gL/vwg/q54bF2X3UHnSh SNQm/ohen+UUbhO3nXue07zEfcJdAKuRITN9rjhVM7lV+3nlT0C79cfkPlLWK/X/hurxEy1qamlp Bw0wZKOBgZb2utrC9bSLCoD3+gwmr8k/AhsNPqM4AgEb1areSq9BtzsuW057uR04dF1iyLpvqwYU Rj3Z+ZPFolQSziU8MV9GtacmoRpx8JYtL97fUlsmhoqvr2qYwmy7ZNMiyA8HwaZhtFvxQb2FwyiM lch0Mp8sJxvDW8I7w4fCJhzpwz9XcpabqqaSG4IEvI6RIu5hPttVEUPIx0vRcCiMskiBkvIzv40n /ihhOLQLLyZ95DUl4/7/CSi93qCSuUHdNaiOaNgmzWm5TOYFu509q17YBxo/0ULNBnbDHSmIYw/z L6WCK64tuJiac6vYh6TOc6dy02SXKonmLZ4e5k3lP7vxsZ8uwMt1+c3y8HAns4jKIRkXKyvP75oc cjnTS8EqUBdr/wFWyeKjymmrgC2I81hEc9JaZC1mszr7VfiqzExhCV4g3JpZKTyMH828JXwknMZf CGazAOJZmx2bZaqEquzVAuPOJoR4ltEKmqzHw6RQEdwbgWo81UKlWJmtK28qX4BWoWXCSrEzuxFt EO7ObkEPZ3eip7I95bvL3/YcFV4u/7PnuHCsfMDzufC52F/+DfrB821WHocbPWMzs/BMz7TMQs8K 8Q3h9ez7wvvZk8LJrKVQ1YZDPq8USYd8SSlCQj5OihbqXCnkS4AuBtpH2IkEEWFREGifZGQ248wK nmxGgDoHfnePVxQ9RM9xCGWziSSXvR5YSsykI+Gw1CPtligr9EtaaZtSjssxoW9h5q1hq41WqGUq XQCW9AjpJKqu6AL8P5MHQNWmido2gf9o5/zSRVOYBXUx9JU82lUGrmlvh/RML5b6MrzTVIcLA18t CLZqgbdXI06o9vRdOLbfU+3JOqsLxzfU20wMoSRh6hk/zuOU8DG+gpuueBgzYwfP+uTmbD6ZBVXt tEyYjLvwl/gE7spMB5UtN2cGX85Oj7oHv2aXnl+2OlQsyxXhDmbZrGQgIZ/7mFXvnt946YGN5+6F iLtw8sLnkOEnogR+RZmw0Y7tmzBUlk2Vmwi2BwhOkFLHcMcKxyPkE3KB6ByRiB0wM0gRwMwnRRiK a9RJcY3a7TZMSMQecdrtEYjQ3yjWxC5s0Osx8Xk5u55R8TDZJ9tsYT7LKzzD913o32cDcPiLhEcX avHDbytSuxNQ/BThMP1yen8RKXI46Vu4JCkbwS9HcESN2Iia0iM0uRvoSyNics5vLkZtge8u1T2w AetT6rGCAtYDA91D18ZBhlWrEOvocT7U0jFqhpLU20V7Ea5D1fYmNN4+G82yL0EL7avsW/FOfATv t7+Ff8D2vxNMM/lMBFqtfRT9fiS58HRv0F5HaAvGba4DSXL6ADiV4q+my71Dk0+dDojVkC3p8kPF aq+2u+3VhHfBTax2wN5eYzW8zbHC9N1+ZzVRbNUXG9sXWxnUq1ALA05V8aP8Fv1XL1Mlvg+3MVdR j8EfUl+KnV/nizeBY1FHGnHViMAIzcTzOsZy0VXObWBHn//dJcd5fkyJQw/1MNWGK9TT1T60Ryl7 2P60bqdhJ88uxyt13Xi9jh3FmZOIcSW1eqGW/j0HghieoccRFUbDNAYovt66ynBACZCArZb+DQhi 1Yf0RN/oH2oe0DJ1Et+e+qZQr148JViOffQ0oDfuiFtMtlLkw0Ipdupg5dbAijeYS7FIYLBzrlLk YV2l6EpjpdZCAENmgSJVouOwKlo/29SjgHYbDzXBAObwz/Kr8l/kT+d/9ueXvj1w24af39r70vcb bgMRtST/Xv6t/AL8c1yLR729p7H76fwL+X2963Exrsc3PLue9gpoJzOlqqcSvOIQSsNH/WVNZSa9 VOj0dfrvTLalH/TrVgoHY4eTH/s+9n8U04oJPp2MV8vViRHJbHpW4pZEW7orbXwDYa+/yD/B/4H4 sU/zdBK/GTvu+Sh2PPFh8ouY1q9EA0nOQqk0gkM+nRQFonVJURQIlxQHknXRpiiUDDpXcdLtdhFO x9mRl/dmvYq3zavxNqaH+gsojZX07jTZnn45fSzNpEuwmiCxmgqxmiBxxGpRo22oAlLzo2VbaboP L++VaMmjtvz+pc/QMon2/eKFvl+c9v0KBZDa5aNHrqrthQxKew+xIo9fkJPxIk88h2N+GBJicQ7L PtCjl3sPjVNApASBfqIj2EgwPAIgDCGs6mqUKlxU7gBJ3UKv/P07w6odPPfQRcCE+3LfToef9Mcn VQwegfzs9EF+xv974D83f/yHso76yusCCx4ed9eUXDO5I7+0KwT5eXiok1lMVxP2rnrqmOVqg+Hx rhkPT3DQqMgv0ayEqHChOBpUisbgGboHMaO14OmwmoeX4XvwZvQQ93vrSaRnrQpqwMw0jnmY7SPH lAznTvIMCu7iOKpf2lAXYtF1HGdmUpHakCPjIJdPq2gcjcmLEZRUoKD11v4/vr4Evo3q3HfOjDSL ZiSNVo/WGVkaSfZYWyzZluNEk8RZcBJiiJM4CSYuS6AFGsdAHktpDCSkAW7jQtnSlqRlS4H3EkIW h9JiaIAuuE17e3m071JCXx5dwG16m/JrL9h55zsjJ8DvvqdEc84czYx0Zr7v+3/rsezUnLTbqTpp 5wWZ/4qDToFvdQDzUVcN8rjJbTeFtKZH06LkkGhW0VNJPUmzaqAxh2JCGDOPG2/SHryb8MdzeFYR CTcCH3IFcyjpxRuS9zaT+tYMubb10L4d4gPpVCpTz8YHXvNT6ByrWUm3aeaujZMP3T392vTvN472 3bID3Y2wyoK2Y9675cime7/6xcMvXr+jp/p994EnJc1+5fNXds77HIq8jIrovunrpif+Of0V25/u eGz6wPTRgzt3fgd1/e3JkZtnvHVXYw7MUmWaNg+mFCBbnRDvjkbk3Z5+Nflqjrkg9VSOVtSG/MYU IyBBT+uLqX60id6UuhXdSl+vXq9tabxJvxvt0B7OPYOe0Y+mX8ydTQVYbRu6N7Utszv1BHqcfjK1 P/dS7q3iX3Jnc04vFURh2pvFXFbqzHcWN6Y+X3A083Q0igJqxJ1opPRshMIWgQvbAmokmkiadIue SjXSyI/NptSztEZzzU1PEIdVA/xcTuZ6uUGOGSUpYlTk2Wh5DH3NdM/KxmJR2u1yIUTxXhL66rdC XwtXVKjE/gS9AitFdOKw3IZMbImfaGPayjzhbJ7cB55wNt8YDBDODpDBAOHswKOVzx1DIeozngx5 YPjMwGaDlCAXLK4u1Lm6rjxNTsqYrQeGC8YUHgiF5ckdEHaCVD1vNYylBIkzGSS3tVRUgO9zpXhS 1XPJQisqxfEm39jSSiVTRW1WK6JmKAtbIMOWz5fgq06SUxHG/IP+KuaDk0f8BDBx9/RhuVqU3Rgi kYWMWN0yjEQCEZb//4kEDiJaaNa5HCvOfvX0g9OVVs0Zl6PpZRUiHIjyjv781sSux55ByuDdmz6e 44sKr7y6587Oy+lbaISmt3xaRNS+e+NtY+npW+/ql+ivo313bN3jA0tn5Oy7NjuWEx30GjPkfaAF uZGbFhnKbctSTXZjBVpBC57OMbTIPNHW0RZmIrYNyobQhvCGCGt32l1U83in7QbxBucNri3uofiQ OlQYKu7k7xJ3OHe4trl3GPts+1plr7PVWXZWYq2xcqwCoYKcTYtralNTrnUumkvXbMVQMV5Ui4k5 5TmVJc4lzX3iaucaeXXTaiOmIpWOtKqVSFuf0hfqC6+ddUnrJeVLKpe0rWt3MaLY5BMjTUlR65zd VOwc9g77dqYe5h4uPFLcVxjPvtz8mjHeebrTfyHfEaE20ZH96OeIRltRPdJgOiu7S9FIbJMaicdf iMFIObTbj4VHl+TyS5LLkJpdtrRAGjaJprAFlC0xySxEIJAZbywjpELgCyVNueB5yUO/40GaZ7/n HQ/jGaN3HFWfjRsyZIHjA9Q9efRS/i/5sxjazMUVM/9zvMNQeS1fxIBny7+IFlFVtIgErkBkDhib sbAcPgPJ28NTw9WCYekeBLfqiX8QVXWBTUCd8w6R3gCSN0/WRWtbqsj5smmxRWilmtwAaj684Yp4 15GTWilRajEyMoY4t6upWfdimOMLLNC85SYim5l8KWwyDA9ghVS4XNzovEq+3LANrB3ARrlBbbZS NiVRcVdtRXe1tegm6uFaRByGVm5OQ5yu51VZieOe1jg9k7yZSs+kI4NTiXlG9w48e8nVXzHm/vEH 9yz9y4uzy+oPw6EYp+vh/sPX3va19s7M9OP3Lzv536+9uaMhnHBgjcjYsffSrRfNbV1628brvn7R 7ncEey1eQL+472uD29bN2tgS/+EN9/bd96+VkFoAyp+LdaMDRDf6q9m5Dq2j18XWxa9B19DXxK6J 84VELbEi8bD9ocg++5MRjkaxeBBs+kYBpGeSU5KUSstuPjFGj5s+ARmU2eCqed34cr3Ufkg1pLNm mBeInBOISBOInBMaG4KqEQf56IIzqLgc3xDfG7fFX6CzVPDsB6YIUjBI5F8QX/157YoByyF/ZgAE XhwLWLECFzgousv4Bhun5K66gxeeDGWKFfye+eg9oupMdYFf98cQ4wKrz/LzpS037ifkEGjr+LH4 bN92p0WfelXfS1gjL0y9DOr5Yxuy5R4uLduXTb/Sl+ps/+jMjCpuk1y+ay9Bc+GuimdP2p/DdzWP 7jxGFbHZ0VwoF0mWRIq0Zl8wWs6ynewy9ma3TU/qmVnJWZmFyYWZJzJcU6aaoXuLN4i3undnXsr8 I812uSynlapGQonGZuK68qkRJZHEpjnGKVrPOoVmbKP99RDcNdx5jxhwpAN3sAksNVkQeFOq8iZW UvgiT/Pgz/L4/YA9BIdY4rUCo89y/5Ff2l2ryEU0VNxbPFA8WbQVVY08TI08TI08TK3R693qQ5t8 yEewy+eCz3xx+MwXKpw5b/8NzPhtII+XWIDGwHlnDsnpnckMKhWXXnTzc+08Zt10IuvwQP4/zbr1 jJ5yaTlK9qSlphwSHQlZz1FZUQerAlnKD4klowHMi9RmYFn0GT9ZJo2x5lOOR8J/dQRifoFOtvYa gYsm3/jte0VtIYSMy32pUGzZrqu3/3I5RhxwnC1QN0/95o13v737jrV/p723XajrldTw1HMr3hju ueHwW7S+VWvBdBA5+y53G6aDKhO3MnmOCKijKe33jDG/A/OSztBRoRixiV5a5KlCoYaFWa0mT53A r3FUgKyckMA6OYl3CJzDUWSrnNel+KoSfkeAnnihHIEMA9xGcWv+AXfahEqhR1hr6xeeEtg0a/At YlbK+rLhpkhzNlNqY6vhcnEx280tFZdE+th+rp9f6+iX+sP9xb7S59kruGvFq8NXR65p3WLbwm7h tjhuEm+Vbg3fFLktepN2Y2G77V7+7uhXCl8p7izdxz0i3u+7X3kk/HDk69kHCl8v7uOfFp4Wnw7v i3w3+nTsqcLz3PP8UcdY+FDx9eI/+X+KH8f+qfVcXbiyeHVpp2DriFwb36R+MWe7kruSv1pglgrL 1CXZpQXb2siawkVFppfr5deJjI2jHBjkosFCc7RJLXFVUainHsco7+zOSFGI2kSPdWcjXp4TkchX M14aPEk1CM69Cq9zOZgRs0WIRnlBcEQx6sXjPMWiCOUL+yO+bKEpkvVK+CqZeDqSqZY6ItWxs0PP R0SHNnZ2k+kv8pwmiWJjBB8dCUejccHhIG6QSBQPRAsxnm8EP1mxUGI5Dj6JFkt4t+TzZrJZbGJR tOhw8DwnzH6UfaKEn9lBs1KyUkZICkg6VywXSyOl0RKzorShNFgaIjsnS6dLfOkP/O+Fi8XI4bD4 Aq1RYfSfpmhKvdIJiZGe6pw9Rn/h+QQkIRmQtB2STyny1BmiIhpT753TCuu+tZkcbtwqn+jw9Q7A qfH/zk365JaTXV08/sfJXWuJO856Ye4DQxEzICCiP5sNOmtx2GhFvFEVr1izLEmsEq5FAQyEWOdL QsFjOjMTbQG4RL4MGC3Em31+EFlwmaxwt1Xmx/3G9F3Z6Z9OT6Smr8tJ/oWz0YdKpaMFie9mNaxD +0IhXxMtpzrKOWRDdEssmJ5jX6any8ltH32Pufzjb9k2frkhret6sTH55SmO3jG8flba5/TyLB5q at06pdLvf6nYgI17HaQ7Vhnt3yXS/d8O2SnkJXJyX61iFi9VLg31Fm0tDbc23Jy+OXNPw84MG7KH WJoqBrhAViv2Fu12O55pNkCTNNQUl82ksnq+WFyEzOJF2CpdF+/P9havZ6/nrs9e3zxUHEEj7DZu W3akeaS4p/kx9Bi9t3g89m+xk0VtO7uD25FlEEdHkAXLalqLqFQ2H6EsgI4rsUg8lVYaGrCy4cf3 keN5oMnGTBbvZZV0QyHLFfksl0krdlVGFKWqcQD0huBM+CM44w2EjukmeNxo8gJNwByPHSV4/qyW gbvgdVa0TDFjZnozQ5mRzGiGy4zRDz9fAKoMQSFkGEv6rrByPjAEtHiOM+G9w2Ypc7i1yBDbKnU6 ND5BdVa/XvLRme7MWCUfxBsMahgaRgaxTuxnT5ouTHEoCxQHGwXcfVKVsxr8u//wnFSdSbSGAhtC ZZgaP+v1Tf8XNIgB4wT6dTh8xcVd08ei6YtbpsZBT5i+d36hx5+mu+OFFXNQBDm6Ym1tmObyqz83 NTX97IzSgObRHVfMSjp0vaUlden0UvSdS/PRlhD4gv8yvcjmnd4Na98eo2goJ6bcDNVmp9FVtsVL sC709y6rZA5POlFJ2LwfvW1LTi/qA3v7grOTzE5mPzWLmsNcUM8h1WokYlgz4akGIlxe50URrHAY 1SmpFXy2otdLr2oNwiF4/7dEnWiFBx+Ax91Kjm2tcqTlcsRlpQn4lHwrFbc1tRTLkingi0pmLAZb D/5IGjv7KzMOB0mSbauCFDKqkCMUWY9zXS02qoA1eixvBrxYv8evicIUkMKvjAlUwDtE7R4ff9sw jsu/moAwYsTcJEbvbqW9K9uQV1OrI7V9whEH4zW8t1G3td5F3SPeU2Fj3mCnXBup2YToMvsydqG2 sHFZp1nbGeMdLk6jGi9ASx0XiBdUlrYv6LxgzhrxKnG7sM2xTXT3Be8M0mptQ40e5Fupcle+KVf+ HoYI+NNJ40eEqpQVqxLx93RWZCx/aRDCgxKjkWaLZJO6FHAgN4nVFcoGZZPCFJStCq18GbMYzLjY ZXbReNpDUD6Zq+D7NsYsMj02MT+eQ7lBnWp1SlK5jG/8x/gJsKtavwcrWWI7G3+jq0rpqj6ij+o2 Uz+t0yM60mU4SP8evYDiqACGErUaGENXmfFIoVriTFdV43q5EY6ROXSaQ1AMsWDugi9a5tXm4WED cssNrIKBlxDr0HWAkD8c6IJc81MD8uTm2uQwpA56qnCMYRQsvjvISAhznVXgUK9tWFyZHU3afe0d bR00K/AOnmYTjVojzVbEqkZ5Yr4o5fW5VWcUNSZn26tRqoMva6hSFr1ROYpcjXjTyXZFKeLhAJOr rtM1WwniwwhzNza1sJ3Vf7DmBegYMKhhzOmHSnimmCJPHpRJc8RVbdfw3C0u16CGShSriiZWG/A7 CtQeFqsO/Cjbs9A6cOvArYBb4ZxPf+a1Fs9Tn6m3a29ra7ecEmygwX+uBg/C1wGS1QN5PgHLxYHP sTLQ6cX/kmqbs+HWeNNPP1izsqan6UJaLxzYc8uFs6NeR4NblgJdQxtLneihlhXdqzuWbbvOE7rj CwtK3TetTu3c2NjY0pmfVc6tHm1S5xvbp39852w/5+zqeLD7fjTQFWoZrC7ZgDn/7EdnTzHH7F+l glQK/dLi/OfiduBgGXjZ7pcohQRmFAmMA2B0CcgMhkgH+FyC451wvCQpDZSNFnygsHr8poAP8weo iC6IibU0Ryzx2tuGZYoTPn3bGJdfw0yLdde6jobhh2LwJfB5cA6cG7fb0zoF2YnsKoUG6oWf849D sI87fz4KQ5KU1j1EIGDGH4feRP37Jqz1JiLmzXIaPc4eYQ9zf1Jt9vQC50Cblr6R2WK7i9lhe5J5 hucWc6iT92ec83xxf7fSIFG2SJCSE+jcLymp9lE7PWgfse+3M/b3pSBFKSlJkp29ziHnqNM2gjcH nAzlBIduEXfHnSecnBNz/9GuinNQf2VpPbMS8h1k8LPJUwPDlo9iuOZpqJI6f8Ia2ZDGiFxaY+Ia CjuUKBVSRCnK4z3VltBQSIxEqRgb0epFP3VL6PbbMcGT7JThtWvR+VpETFuWszyjt3o8wfOOMhbN 3r77X375nXue6X1itVtTos0u5Mu1Xldd/61vXVGpZOkPj/31F2ceGOnsZA5/c0lYTg5NZaf+fVbr j1468P2IH+s3izAN9WD0SKC/H+RtaAY/6PCn0hoJBrBB3S1wg4mhBA3OzsNAT4kYlviHfNiuxJ2f HAFEiZUYLOKx+DYGascnCaFMQM3Bc16SVXl9c65MJeHpNTjX2Omor8+20r6S7eP6I/1R7ir7FvsI NZI4FHlVO6GdpP6PXWhHi9FqZVV0Q3JQGYxuUYajd3u/6hv1jCpPosfp/cnn0cvode710B/5U9E/ aWeQwtI93jXee9R7tJHk6STn0dCLZ09SGn6rWGBQMQoEcBHTxWBiJEFTCTmhkdSWocToJ2LZpxPO xMbYO27kfj2oC1wMAoL+KjRmh7eKJykm3lAltELaJdFSQSZZD4PUEDVKHaDGqZOUAAM09fT14TvD dG8Y7Qmj8BiSTO9pFlGszFoL2djZBY0LjtFfsxxgkKk7MLx5avPAqc2ErAyjNjm5mYjuU946izlW xi6PXR9j7o8hWM0A80ZHRwfqIOVikNJEdPBDlKyA1Xj6iK9ql2Vw2I5jWYkl4/hzcrUelMMkthmB lUxXylTrrJkCwPpyHESQYdnG9Ohv3fnNPyB0aMf/KLXMjnvEZHLuFXMu+vbOyy5sL6NLDv8Qse+8 hVy7lqcL6cAWNd5z2bcf/2hB/mY8++6zp2x2LKFUKkcvrdNWukBymppYhRAVbxEYITZKiwWJwAqK GnFYAD1pxGGhkaPx6D9MyxuhwBla9AXmd1QMgBrSAVUviC7ZZwouepXPT+n4wbW0METjAMlVwG9U 1zDexvrFOCFOrGPMiK+LvfgsShMZBk6NDsWQGRuM0TFVxJcRg0SGBW0gsPAv9EOr2dxuvKXhE00r 5JvIMWRy7CqWLeSJVJswLOFmjE8YBoiLtwcGJmqQbY8FHOaNY1QBG/iLF5cLwCLzjXx5sPAl25fs d9tGCvsL4wXOLIwUaKoQbA4Yq+yr+D7jQY5bwiGt0O5Y7FjteNj2VPPeAjdeOG3QmkZpiRcwtYsY BRd2aSu0S7WNjmu1W7Q91B7tae4Y91qzmOZ9GWmeN+7rDsQywXnReKxbxaeJtpYAuWtqC2ppURlR pcSEpIGC4Q0MBkeC+4OMGhwN0sH3m3pZcEpk82Vojy6usAvyC7bWvT/LJ6eGYQUjeEHOzjCeMhaP MpGPlHxeTIbTho3P6Gm+SaMMG95kOV1DzfYWbSbrHLKeO4DCIbQFoQiMzxid68VfGIgr5yWjBccN 9mTFAw7YOg3Try8Y6Xnw5D9+ePMKLCHDhhN5cu5EMJITp0/n2a7LC/0L1x+4dv1Vi+Z89OqraPHy 736LCMqP3v724qgnufnH6K3uoeqKq3/0k/+JKRpqtlcyByg/FWNuq1N0lg9ivJOgKINykaaepxoo mhSCgCJNUTIseXd2nMhK6JgeyL+gKDGiezjIb6Yh8HQIzuaIdMXHcbaxs2+SM3DnJ0eBG2wlUSSC ATRokiUJrrYBQtYYjgsT4+fBOBYYofZiccTM5GSRH2F9o5WXnQISljmNO8AxFDfIwWIINu4+23ds B20MfBWHpwacmAZy9vvVOJ4ndPFsMdnDbHGDLS485HKp8U9DuDFxAlB84PjAgDHLqpHFZE8cXd4N ykBokBr0v8nYQ1oUq2nRatCMVlVSBLOgp8yrABEqIbFsmQyvbM6XI2xI6PddGtzQsE5ZH+YQI7Cc wEv2wAXsTvpedod0t7w99hj9jHLY9yv61+7fyGfovzE+7yA3yA/h2e0UXuZ+5D7NYaTjnNtoRgA+ YTGf9LQJi+jFwgq1j+4TLqOH6Z2+naFHfI8LjzvG+MPCAcfr9O/pk9IZh58/wSGKO8HRm6GFewfh wQMcy91m81PFYAB+qs9b9W4IbA3sCbwTsAUCkX+Fep6zJzCA2EBF9UHzlrnEW4V7fEkEwRPh3uCD 2UjVHUSbgluDu4JM8IzfPwLpmqM8XeR38e/wjMybPJ4Jf4A/ybP8066AjdoJdMW0mN6iC6rTGMol uzQXc9qFXPBLBHwvXQviC+qaCzYBlk9tBrVlM6zzMYn1fFKyOwwkZQx78CPCuvamANa1DVjq7ww2 sYfJcl9URwdkRS/oP8TCX+/bvJYYByTQN0xsbw5/m5isSmau6sRvWOLvYBYMb2hARhyMWHsR67P6 nsPac1h7AtkzXUI1IIeqIc1TdWok6QYZn9LS165d62Mb6pUnFoJ5AcH0RNqKtPwGXXHFjnXbc2rg Jw8/8f5fj+x+bWoH2meXQ5e3rbyTnv3GDTdcfpN/57sI/fp9xP306c7+VId5O9aHVlAUc4v9Xsqg +Tp36zmCVzkTYCdH7OqIgWQXi3hXE+JJjobXBZmgXmBQl5ewvpWswQI8CRiTHHxKjzdQlLvJPYYi B70s1GpOjsvjtYlJedICpXFQp4/Lr8G/4yR/ts7Ixyg3OYfCp5qxJjaFr8Q3IcKIiAUORESvJj/j LVMk3EjG8f5viH7tcuVaZiDobdjgr5+YsPJ6Iubce7RHAo+kmW6mW1oS2s5sl+y7baiQ25qAP+Wy h98jPCo/6jmQE2QWy6kNzRsMOsq7DsX5+xrRoTg3xvCmmozvib8Up+OelN6AjF5s/Babm7welucc MibwMXTx87uwwTtGf3gQNRtjSDad2SbkdXvk+9xulAJifX5wsEzazk6rrdWsNlUirRmMJsqjLgQk vsE15Bp3nXCxrlDLCwzLcPUQokWUyyfBXwJKdRdu3hs4NUz8T11dU8NdtSls2RbquS9ePeMPpvVA Wg9mo1TGn4qiz0S9sZL0CdcQBA6SlVZsAtaL8QGHiMKELb9AawA9GdXnrpx6uyk7P3TwYP/hzZ/v 7yzHG1p7VDWdN6MfMMumnhxpbEmlst2X0euWdO38wY3duY54JXGdz1e66s35S6Aac870IuZ/YZ18 NnUBtZZ5yLzDG+x9KP1IG0Pl5PX0luYtK2mqmc2zF9+j2WrtK9Zvar8xPbQeVrW4s2Gbsqty99w7 F+5aeteKBxoeUB5ZMWY7Zj/UcEj5cfnHS8fXn1h/cv3p9ZGwFmiVK/42db39Kb6nrRahgkxboidC hRac/7uNgs/nF/gRHXl18A95MQ7p8Dj8Ug1aU/SKtT36fv0lndHH0KOH+40RbGzhQ00nHOvdk9if eCnBJOrnkBafksDHmspoD+qBFcN6TDzU0wKs00OSshFv+jbxaCuPOx4IWFXYR0gVfsmUQj2OQgj1 hkZCdOj79C8pFjPXcqoLf+RgudBF6KKWFvfyHzBFjHdxvK1Sy5miqcpFtKm4q7inyBQVwNeiBCxR rFTzzEgf6oO5OTG34s5PDsl+0vkt8cX0WamNmJH6dDWLSNpPsCFc3pVFK7JD2fHsiawt64IjszOe U9z5s+kFgZG9UVtfXG+u34vvuX09nBoVpfJ6164HF6FFxIuzqKQFkTs4FPw5FvZjZ//D9JA4qASK QZD8xuAY/X3T90gN1UpFppehexkEqXw0A7cyFCuTFl+Vga8HNRk6R2GOzOfXrX8B3YTtOsdzOyFK YCXqD08OT5HOpDF8SjY2W5nphlUMulk+RQoyJuXJOihMvQcQUZNhaQuohRqW4Xh8MEaJQz9PvJOg MU4Mn5mEgmUY0d/R8cjwjJ+37uYl7t4Zn9EtS9d0LkxVorEGBdnT+qxSa6lcYth56RXpvN6cXq33 RVF0djxKLa0s16j5qKZRc+y1KNWbWx6lLjb6NNStLIqiVZk1UbR6Tawzgg+PzKaWlXo0tLSn0mbS C2Btnbm2rii6sHBRlFrZdJFGLWxYELXWQZmJ79c3n15Cv5kskALMD3lUaDOBNtORlzGNVmQv+JpO P+etR/lnovckDR/sdDaZrNtQrLVmEPw7t5qQVUPSTs5C5xbuIIuqsJ/cw/uVvnUTe+8cfMVwMayd cRv/reP4E92LW9REMTr0szkDm77wzY9e3r5U9FS4DWWjigI9V3SXe5ddtrB1+h+FYucV3z/0TGt5 97vowqb7137luGlnhYaww84uGRo54k9X/R6NszF2wTl08ebL71szq01R9PnC5WpJTV5K79hyy6Nr 5g/fsmfd/I9vb+3Xi6m5W5eUg0EbBn3KiYXT37A110bvqmNjrMMExpUdHgcBQoeSgn2FhPIV8PIA TyjgjyMWnuICIlXSgJYqDKQT5UomhxI2SaJXJcg1EjkFrpGDoASM4s6HxGWVm+Ex3PnAdBNQJtfL IWyFzXNgqPXit47fWfzOUGUIvFaIH6vSRmU8sRYbeLEKBbAFMep+8AEmyro9SJRW+fhrs+TjhjUy gQ3E45+wDfvLXmDJCtnib8yU8UXhkp6Mg8Cvg0Cug8Cyo+7pIkN135fS0Y4SZDhBhhNkOIFnc5pI G9z5j0PwAe58fBQ+y+U62uuoTUC73p8ApQvPwvKOAV8h8JIXOszmiqNjEOvNbt2dHukY7bAd6Bjv ONHBGCzq7RjsGIIhswNpvNIU94wxbtPTmGuKZ3oaHU1xuSeZaIqnxxiXmU9WMvl55XilG2mZNorM EqtVHo/sCCkpYdSBDjiQ2zHk2OP4ucPmACGl56hEKq/menODuaGcbSQ3mqMP5BAUd47nTuRsucH2 J7eSJRPAeTZFNFBoZ0KVk1APU62vk1kHZ384audZPZKO2kNRxPFhLgbwXPeUEccwVOmBH8PTZlXD 1Ks+LKwmeWZW3g0xDfFove6ybjGi5ZvumHfhUMTnchTN6bkBc5aDUbuLpS/0BKqLpjvnJP2KWw0H Ci7ktX916rJbFq6+xHx6+sU1mhKF7Er5QtT94KWF8orp6KV5NZXyOTpWM3Ms6xEiM114w2F+EalG uh6ZOUalMBDESJGck5C7M0E8GQmSJpnwKYyAEYTIcgGS9EnADazAegjuZ0fgaMGpzEh83PndoTq7 nZxhtzcPE27TwB3SsCKxKbEVw3DjJszDsHwx0WSJ1Q4XYBtZH9YG38RCfWJAfnug7iGxIjETmCWw zDRgMcxznODUCA8kyBauc2jp0npn3jyrY4ba29lVJri69rI0fClFaYlGzgfT+9CMwpmCkEo6CT84 aSB7J+EHmJnFDwowPuEfPHLUYqFU8hM8YNmY+Le/PVGbsIIVdVYIjabQYGooNZramzqdsmup3hRt wiYFgDlrVpm0HZ1WmytabVInrZkPhcuYQXw9jc6muBezRSY0T4snuqWQ5BvFU6lSVKPE+byOUQEJ VcDggwsq0JjuWoW5RpKcIWdKMY2qQuJGbZ3lUQX1KmhQGVJGlb3KacWuHEwefMxa6hmWHwYewNA7 aampGHmhsvjcorEWRGFSt9zCn1xW6Rxdt7WdW0gW03VT8+zZzc1ds78cKs2bXrAgHxG4eDiadSG/ /avwQVdz8+zpxJS2uooJOdy1Cn3ugRYt5E4NUfTZy6cXoV32XZhqm9DxupwXsz5iBPlUeH5nDoGA Jp06eZ6cIc+3TJ9FnxZtO2DYia33aXIK7nxATsGdfyenqHCKAKeoFNuUAXqVsiY487JNwcjPZKow OQFeO/nNiTpZGsYMYRqvYdvlyDfDiA0hA+50rb3iNA5i8Wcavcaosc+1L7bXYDW8M2IwMh45YTBh PpvR5mXi2e4QTIld5QsLzaGI1iRxwTHkMp0yRUkc/mb3Hh/ygeOrq9l6zObiCpM3GhrC+PlaVEtc fzBTvE2p6qiG3BqC1WtPa4ymEe/g2Nm/Y4sRfIMHm41fJOCZk3T9egTBSo9aeGX3e8vP4Kcvkxzx Ws3iswPsROQQobfJ4bWwYEB9BU6vUV9Q2KobjMZd7pgedatRFHdFQMtBM/YLhglswHyGYD4Rwgq2 foZuskZXl4HJY+RHe9f3lxLhiOdzCSUfPE89u8jHzUbXtPbxxvdPzU8mZzm5Nfqar9H3PmQkCAUh ykNRNgnLvXbmpTr9GGEC/yGytRLJPFZ1g5VUJjmBAoKwxbrBHwiNQMc0LCWhLZNXUV09IPWqCZYo DHmC//kgEFd+Rk/Iz+gJeZCkcIE8lLOSYqW8jDyqLe1oCOtZ8kWgsn8PawtpqoJpz9tGtIW2diod kiQrTsb87oggOQl5M797zsGShWuNuhIxZYyPj58PiNVx+jUsNSGlplS0nBZEJh1zV9Uq7WVlhP/f LzzgGBVHpW+4d3u+4d2t7qk+73BUQ9XwBnmDZ4N6rbzJs0n9Bi28H59U6RHhdtdrzGvuP9J/dE96 /uLla56aUlM7tFp1kXvYcaObL9DNsqZr6UK1A3XIXEBehS6W+zRbUl6D1rjfk/8u2y/wLFFfEV5x /G+HvUEIympMVRfS892s6HH7nGEp5o67VHYls8q20r5W7vP0+diQOxaLqytpW13sF9oUQtNIZhyZ Cr5HX5KQdCvmDQcbykgS/uq6dkOcgok8xBxhH5RmIsdx5z+JHM/nqx3n9Rqi1oA+M4EB6FzAD8ON uUp2I9rj9fnkkBqOh/JYVck0Omgh7gBNJZNsyxTmVeJt3VSBErHcSWmqX0O0pmLdsIhoP0I0lLGq PmTL0G6HLCuOdopqGEMfmMsU6Q1RdLCY8kMhxSEWpRGJPi2hE9JJiR6SxiGm09CwR0FKWK2iKlZt qFShQP1fxr4Evo3q3HfOzEgzGi0z2mdG28jSSBpJlmQtVpSEaJzNWezELElswNiBUMJS4oQ1QIhv byGkpcSX8gqUPpz2vbZweW0WQmJCKW7rUvpaQ94tpaW/S7nv/lIKBQPtL+W2JZbfOWckx+G299XJ zDkazYyORt/51v/3nZyQO4xTdUx9OTCaG8uRueFFtQlw+9PRb9yIp/bOXQj3CLXLDcIulOeIPGiD O5cuwOmjmSyhr4yMIkg4wtKlGKnvaGU8Oox6sTWxKQEWQGD2ofemGAaBX3bt2olCPruaICxiJ2Fk wAlw2nigvRJJQcsLbiEdEl6KR0lsk0etNStqnDXeaCxGgwAOR5y1Jm6/GR1C8XZn1aillqxEvWYz w7ixTVNqVZ8CrTrmxeo5bQsxko3vrLOx0QR44KJPd7377pVthbi0rLEiEUg1fivlehu51TGvlXco sjftBILpgbM7X13pstk8IVJRyNyS1xu/uDOad3DxOPC6/SVwTePUwCIRxONOqz96IbV8vDvgjCFO cwHUsHjIabzgn1r6lR+qF1i/8tjMgGn65zDPAJhnABtSs5ux8N9hC8PWUqFsSNHCofCJuV8/g6Pj puchc2BR7TXCDRmE1T0fF2eQ4pEpzrvvDJ1kCnnwFlgNSTfWkjw4WITC4gTBND13hs8OCxE0KEPp sRnMC3cMpcdm8/vOU/zrOGaEeMqJMf+k/0M/5cfOstVl1OqLa0vKwH/Uvq2zzw90f59/2D/iH/Mf hCcyNi3MrGsDWticjLUC5XBIjJkjQNxua97GgLtUlpTHbKDPBoZtI7Yx20HbhzaT7ahvgdpiqO/1 pecUFWgyY/8Z1lPO101alHGnVO5u1Os52RER5ZQTOE0PfNy1eVEI6yGU/li3oT1jKWIuUIeILdTP mlLEP4CtzQHsg/U78U/r3NRTaPH7AvpB0c9XwPA19BsXMvisTEd1deus1a2zVuMcf3TW6q7uLnxe FyaULkwoXT0e9Gk9ret6WvKlp3UD2PmLLqFzezh0m54MvjyDL89UMcYKHajiohdVhI3CSPdqEN24 io1gdGqVxO/jkgJVJ76HE9/DiQAtxj2UQjP++X3jHkoax0Yn5n6lW9GpCtl8/yykURQv9Un54qo1 SKFSui/ZpKNz8pvAxk07Nu3dRG3abO7uENWslVmaNRnIjjySaIODULGanUR/LYE2r3Gd122SOvKn TAkZ3L6IrYR5p7W+FN4e3t3KmJhLNm1mxI5uJ6Z4p4IDqEoGG8EZfCxT7cKvuvCrrh74PX53wgip 9leRGwEdrhr+BNz5A363Wu3vQTIeHexpzSDY+RN+t6dnoL85cZzzewGOHG/wKxD4O0/X64gpQ+o9 bF9/Sf8LxOq5t4lVcMvDrTD39jOyKInQeDf+BgJ6sMycGvjAR41CEh9A1nbGDsYGoFGtaGFxgjx7 rK2qhTtgR7e29Wjh7nVtTi3sh3b1sVhGCxcmKPuxWJcWXg07+rLYpmRv1yXhTStZrdqr17QUSzBq 9+Yt6IdRszbOyphpE9O9uqMg+rkBqH0Kzni0oIAR5TAq0A8qOl/Vcpn4okIVjFQPV8kqOubr3dIV 7+mJ9Pb1kqO9Y70k0Sv0kr1wXh/3+Mq9w/0DE+SlUGbtFSfANlx99Bym5Qyyy08bzdINSDdF0Gr4 V8f/e7EAa6E4iXmLvWWzt8VtvF2NJeK2aBA4+DaHutBmhyY7WsQIgVuqhsn+Vwz3pizBXnWG8Z/j I/OHmQUW/XkabAn0bXO1by9tvst7zQPr1+6M+uxc5wWNpe4lUT9HB5KbK9f3kKR38epGR0/Naopm N3ZWLm6XOtY3ltSLMtZzkzzwZMj3tvGJ9Lah29ev37T4rsatmxUfNPD9QszZBz43ktMra6yZxnps 9UOpdBE81qGHstWG99LOQDweWLIJXPFwtqUP2wiC+g/IyUrkPCerYE5WwPpwh5Hey/K+GGIJOfQq FoprLGZJzfosmB+wPuxea2bK2D4J2TUgnD7kgU6g031ECF8cwjcK4VuENOxd07DirLUUZM1Q0XDn o2YWCeRtHLpCI4JkvIAYiaUDW2YdRTsqSCrArc3wt+mWOB8vMnLWQInl89i5JmCsWO181XgB/xAQ AxEMJ9s5tnFF3oe989j/3YH7eAAdxv35OIulJ4s5BYu5BuvD8AsfPuRj0SGfr1ImQvjMED4Qwm+G 8BfFCI0Wu9AQM0FnaFql/Pc626BuuriipytsBc3/QqWvMlwZqYxVTO000HF/FL46XDEfrpyqkIcr YBgemKxQIdanhXnD8aZp4fi6NlYLO9bFQlo4ZjjeOpLprkK4Y2WQiBVL+BvHYzGed3B+X5wZY8Fh FvDsCDvOvsLSLHK8BbRSKJ6OaH3aMKqgNaqNaYc1itAEjcSFHCxwwmvDZcP5lvn7nW8uUaLMtCpR /iAwmUWT3JrGRuHGQQy7xr63v+l5QwUaFxw8pwSUwPqvPrj+BsXnsHYsbyxx6yWO7uq97VarA01E z+oOPtKahzPfX7956V2N3VsiEva58RvBbXt2fqYRGvSF4Ezr3gYu+foaGXsuINM+TT0L5xlPhEhb c6YFoRpogBuxOmfYdAICQ9tkGs0d9Cbq6G50kMan0X6VtQoqYUhGA8JmeB3OgSss6H10nowuDiCa kmkPpjiPTcAanIDVNxrrAahL02GbzQBJYFGEiAvKIqIVhl3lGvWCb/qO+34IfmyZCr1uMbt+y4E1 llW+Ld57wP2W/fzrASaiFys0BkeMR8CL3h/LpB4Ba9nWaFy4jGgG6v8bISnS4BTa99HD9Ag9Rh+m zfR7qIh3XbeNQxNnHheAcMHIMZtZfzh18frDfRdeesQWXnskQq+96NL+5xESmqDhFpmbRCJwRf93 CJkqEjThoYrvCO8EFryE0mHgXL2IThByqY4EqQYTnGpOOHmPQoSArACfBfZEBvbcdkEBAQruvFa/ QkgmuGvazK0/jASGtAapDqzo1523kLeY7+DucNzhut13i3hLkB0caC6fYQkKzloAbl4UqLEagRrk MmuWFDXK23f6UbTW42oGXEji1N3X3/rK3lfuuGbPTy+uXL98/DNb7762mzr0+L5Dd54d/frnv3X3 n2/rqj9+10uNXx/8wZn7hxH29s+NddRJSGtJoka2NWlNW4Lx9kUujRoUDkAREbdEKJTmxjzYrWC4 vYJiGy19DfNdZR6Fq1CpjIt2mOWTRtFn3QrVj5zq6BwwM9g/ZiEwFyYApE7IYaHmNoMZ7nmw3Enh RchY8+eh254linNnn0GEWOQQTWKIGsctWQxHh+nWjXmkWzFkAPZeva8HsLKmwLNSZkeSAJIDDsaK RoMGgDG6gsEZwTz651QT/pNBVH03twRRa01YK1wm7HfS92bBkmx9yfrsZdnrnNdlb2J3O3dnP8t+ nXmH/bPFXljSXxoo31Cm9SUgz1IpzeWGapV0b5sbKlfJGJGMbkyGiZWkK5Oi6JzQCdBISAaNSRId xY4IN8aRw9wod4ijuHcVErvwAorSh2Cro1GA4J4GxNMUHV6MAL3YmEFFHZtYXsQOkQfWP++BpRyo Zq5RZF3JVxg7q5YTtkRBrTBFBeTtcFeydCqgw5pTPlEsFccRIQlSask7vxgRpsNkS4Ep+RbEJEwG w0QpKE1FhwRyovvAxs9dvvO+kX9e15kq+mvrG4pUTbq9QiwsqqBscXz64m3LLrxc7y/k41Rt12u7 t97w2VdnHtvr5dsb71xRCqsq8Fk7tlFXDhREx97GP++ILe7f8Kln/2XnBtGF4hQrG+toAtJyiMiA V5u0LCcwq0x4cWEzLzSlw01b2oFsEozMbNYiwXqIAzmBsR6DauVg8IvppGE66wITMvNhV0wVzdqA y8o4DLqBJFNfaDxPYoo1iGYykEYsNJBGdBhIIxqUeTm8WaBAO1a5FTHZ107q7aPt/zN1sJ0uyIVo Pb0os1HQZT26Mb0m08/3yQPhvuil6aHMDuFK+crojvRdwk55b3hndG/mHvkLma/wX5K/Ev5S9JH0 45knfN+Qnwp+K/Os77twBL/KvJf5OJNW2m9Sb0odcD/sftgz2c5c7AZtrANa0MmmBR0Q+XCEiska QF8rpoZEhjE7AgEiEnEgsssTETAGyGEwCg4BCrDY3n830SF4+7zkC95XvB94KS9GAnhXZFvYSZQB P5sZ3GWUqMxjA3umPovo0dWqFSfGU25/3J9QiJQb7lRfTAFJD4JQtny/CAu8c9eiDIIDZ86Z4s26 o030JIH17yrlbC0lgfzB1PViaV2j6F4U8oiX3bf2nv8DPD+oDScWV/4xua0+cvB/3LTkcurQx5/q LwZVVbDWoOp7w8Y//OQdoCpKMD6bB9+G8vq733t2skQYEWPyBKSsFHimhZVMYx5pjvidSaycJsUI aJryCy3fSEuvjbQ00gjiRhghEcGGeQSrsBFs8eITgUCJPgk5c0UiAcnOsTG5I7k3SSVTjGijILOa RhbuDLRv/5NWiqJcwvnh3hi6XQJeu8Oy10Ja4A1EMxwpZpRObMGiMf4FM8oI8gggekUdjLeKRNLa Ag+nMIXxVoPzOmRA3wHNN75IFnmd1PnP0IyeBkNpEEFcDtuL98aSSaUrEU6uJDhr2ulRBECLaHm9 mmADtgGKIhhoEQ6ZgW4G5lwkDdKEMx6JRBQwqowpJKEI0EKcVE4pJmVY+8Z8BpBh4+06vXNXsyDQ rplBZzMjj1gQctoF9TsoOL2dLVx4y+ryzwdSz3P49dy0u7qmHI9t8bq87QW3ffmyRmZ1m8SZ7DE5 kuSAlzr08ssrssnOVR7tisbaniRU3uI+bE9ddfCCIFLgIL1smztN/hzSSwddbtJLsoTppaQj7YwE OFYKcKwU8AGZTdrQ8WSUb7EfHgnSInqf72DYJB+lXRkT2G0CN5iASc0DANKMdFsYXBUGYVWRwbA8 IpOyy0rUpwYHoQ6Uhy1sBhE0G5EI1PumX50WXjUk6Tx1FKN8kqXTvrArZyLTHYxxG8m13gSuN91p Ik1qmlkZBtvCN4fJsOqyAjTCP+gyohaeLxVl1oGtmKQLNclkqdiUmFNGO4Vws4NoE6amBuvCFM66 ambCaJaslCVdrpxurWVT1proGbBdmnhMeChu4hguxWnDpZHSaMnMlyaAou+D7PIn9p84puJT6i9i r8Vfz75FvxV7K/5O1uqqZwezN7bvyR4AB8gD1KgXrbw0GtzffiBnR1VROMpiMwe57EttP46xQcrn cQV9IUkLZB+1PMo9pnwx9sW41ZWxp7LrshtLQ6Xbtduz9zqeiB0qvU29FbRpbEeYeJ4MgwjI44UW MkeJ53MTQNadaTEsPR8IyxEZCLICnxx6U3reh95sc7niMbuV5pO4MYXBj4hcPt1BEOihyndLkogS ODy+PHqw5E9dALgQFOkDhDSjPLp1BK1zN8KP8RQ/ATp1KSlLuQgL2Ox4EgzjVFUK5a2SyZNAIYpA ObK+NTlQ7RFsHM0iFOxcFAwO1PJQrzw6B2AXL4B7Bi/3g8ym0wuKkkCtlIN2Wtxu9djt1laJkgGj RsngrvOqlMBuM5M1p1jsZSJjLF4WTGkRRXCamYgzGgRmjQ0SaAkLgkmZgqDF2JHthSpefMx8JHzk /DhFDw6AXbgQSb8ujYNxcpwat37ZPuYdk8cCY8FH2x6OjbfboHqcQVgmhNHSrflYPv757GPxx7Km wQGkNDtTilSzpKQa0LkaCbeAAciVcRyfq+XgoSzeLDWbEHbVHQraoRJAgRpupFrcgDXHjMaGiuu5 a9lm5YKjLuNevAt+hAt+hKuWVVzomg91noen8TVKsMPPsaMbfKi77PBz7PAcuIlOvH0yRe/8P2Dk 7KHCK/OLIvnnF7RC9dCdpVbSVDy5sOgKORZN3Hb56s1KZOjBnzx/yyU3RL1+ezQafPzKVVu2Nn7d 3v7YnZ29JafgslGHGi998bp17YtSWq77qq/teTTMyaD7/gcurK26YmxxbcvOR/y8Q4Q8zDP3e3Ip /T0iAGZbCOKQ7oI8LIRD6FYbdsDYvG5gcuOuGwsydwst5W7F1d3oWRhFNqxslvd5aAQdJoAZSrLZ U9P5mammDHujlYV3jj9JfgM/iPfeBf0AinpidarVkZA+h8MTI1Zg5QPAe60HrPUA/HE6JEX42dYA MGHjwISdKSYsBU1uw31kxiPF8s/divC53aHgAmcKzgOoz54aHJwUpoWpwRamAf6sgWcJOxxAl602 BIZIsh561Pmo9IL3Bd+E9LbEjIfAfhlstG20D9mG7H8UTWbRKyZFyucVJZkCaOcJHASUt9AcLVUg SWC2VdCgfa9438Q61tWewE8JK4r7ZRUoPHP50OEQGSIAoGlT3NPnBqNugAq8HXZPuk+5/81tdg8H n9rfMg1mjRTZQby0LFrbhajPnjYiefCt0wCKTwJrZ0bdcLwiHsYklbwxJ9apqiWscSUQdrgTr+Gy 7rXXSqnoMmcyNroy15/+p+pN7X6N/l7jZ6tnvz2wTEtdeVVp6Cpye9R37ZrE1UgyknOnqVnqIUIl C02q8iWxD5FtquVWJdWMCDT1ISXctDBPG5gMRcYnyi4cfXC1yM3VskVh5wyGDbniLdPTIapmq+IQ zaGsw8ogZP4zyPRkOSL/Rgahxw0V/r0WNAM3KLNqgR61hTFSFiiWsypW0RFX/fCuxi2tTZ2YM2Jg OCqmyDgiJmMVS+awX8XFsgkFU55iNqICCReK4qFTXC2UEOpg2nO5komFfn+4E7C/Ee0mMcACEiFW xKA+iPNRKiCJrAolieTD4SRdtlYji5U1kTWKSWbdG5HlGd0YVpMxNgm6mDC7UrGqIXYCrNLdHKGq UCSh7+PgrJzVGsXpUg7iMAA8GAHj4BVAAwyRc0ly3OXqc4+5yVG4O+ymjKqCBtlBokt8f+/5ehpa xLi5vr2xZAQunIpGPq+pIQhIIMg7g7wcJARnQAgFW6WjcS3GViDOyItq0SHU25hKtEmdThTfpa7i o75I0tF4v/3Wu1b17swGq2tA10A98+n1tUuph2Z/Po6zob4/unzg/lHwaFcxANTZx0b7OntIZkOV VFHEDtLoDKRRhfxeqwKOhZBdZrx+lRNuCtxI6t+PEAhEMfPee/U8lAj5cz61DpGzBFiLpS0Kr7N6 sPPX4zY7sf3ndJlJfATObwV3FHSf6cy5/wbUOP/GtICz6nSL62KuX7xMoiRczrXShqTQVm/FI3nk mKWNizoVV1xUJEVebKlxi12oFPNieR271rKSWyWuktbK17JfYR+1/Hf5y4HxtieJJ9ivW74mfU1+ IvBd9hnLce64eEI6KT8XmGz7ufgR95H4sdw+bgFtGGM2XMZtpsNow5rRdncbbTJptLGY0TqduNV1 KVjm2+4i0BqxI6a7lH8w3eM80GZZzJa5slgLvGiejP5SZu7j9ov7JKrqWiOSbtETdhMBJUy4OGcY zoJ79axFlhRRkgoWzmOxcAFZjltY2GMZs4mmWaiSuV1QbSLMsmQVJwAUT0McELg4N84d517lTNwe SwARsaCb8wfZZ9mX4ezdY5FukVFhBIWwwPHyrrKlCULHGIJiBTUnbBXCMgnNpQnwwnGhDYy2GU8D noXa47y7HEWMVRIy0NA9g9e5kmfFt1C5EPGMPIPaXeLMfLEQYQZx133NIiHztWr+SqkaoxjNzpZG gEk/AxB8+xlO8dnrkHm9fQK2lrgVwfL+DWopHIIlc+4aq0A1BW5N9AMwsotalT/cbuyKwbVAmmVr UMJH0gkOBZOa9+ev+VlrWxlkyp5YsPGc1njWl4o4i9RDakKJFRpm0r4o5LDwVlWlneHVZ9+nTJ15 wcIi23jutOkYnC1Zaro5WxLRsNNBZpGTz0FYEiJLp9SImTcjMq/X83l/bWG1qJZTLwGl50qMjgxi kwLvRexWYI29mLDQRArffHcWZIlbVKBab0mBlNW4ezbbHo3m2pt+afRZ9cE6goLiDzPgOPipBo64 cBmQYL3iS0ID06kmldxQ7lrLSO4d9Z3Un9Q/pWzohKPuCj7vpUCkHM3ltG2dIUmKBGJCjuYSoUQ2 UUts8n/T/03xmwnWqlbj1eRGogf0MmvZ7vjqZG+qV7uPGRVGnV9Q70vdp43mviw8hE5WnxOeVZ9N vZB7SX0p9br6eupULkKYaMbspf0WlUlaUmat4l8hrHD2mS5iNosXafutB4T7xP3S/th96n2J0Zx/ n+Ve/74EZbcMgNuE25w0nBPw11RVDjBwVgh+Z1hQYtGwQmjZMMFzjjAfkcJhaNbf+zQCDk7M7dF1 UY0rLMNamLiW8mhaClKDmiywFg/LWqB2InnjnOrhODUWjxdEySOKkpaISdBYh/OPg7/Dc+A9OInC 4L2nI4B3olcC4YC6CZSCggANeIUg0UFAZOEpcJKKz4HrCJVgwTd0PqXDwcbjKatylr+agzbVkWOT xNVaDGXNePVAvk8CByXwvPSK9Cbkeg/G83B6B04ovAoE+KM3s0XU54BAJAgvnOE2ncsPJYCeGEWr dID3jln2JPPsSTjNWahOcQqRAqOpD9GqLVD2w0tTBxnsUO3TwChat0XQFE3XDmuT2imN0Ybb57Wm GRRRluSZ2dPQ6NnZnNvwkAwPwLfF0zJUpdDWWjZPNpBRSMVqFSUx+jOGnYVqWGEugLBSbIsdsAuP /N01rFAFK6N8EC4NiHxkkF0gXpFAxeSRYYISltyIT4RQLfn5xoOaD4/6aypqvPjVEW9tPlhhcA6z wThwISuDbbQYSfM1iFEGH7GDUSiGp35YFpO+peDYmrCHPfU9T7IGolu0xsvabxp/VBu/Ci1aCvkJ HQ5GsrO/B9/at9TvoFSV8gsxj3f2D+DjTsUdJlXVfu3Zd8m1sycocm3JjnRGW2M1dQZymOJ8hALK gEyaIm5PgmQIymXsTfEghKMTd1GpuuMk7pKoW8Td4kRLZGdmMu/Bf/X89CAONpyT3GFLhgh5nOQd RVAkXJCnxO5An8F7PCWCKJfmWcsbg1NQ+0KcZdJwhB0W1l/S/zwRmPsTIc19SMjwcXJCE2jxlAXl 3Tgy/00j3eWcb1vnP5ruMZMWi8nFSqxsyXjkhCXuisuJzCLQ6aoEul3bLdu5a6VPyVcFtmdvZ3dz u6Xb5JsDt2f3c/ulR4hHLA/LX8o8R5wq/8YcgzM/k8mm0xzA8lBCQjRbbArRBKtIslxIcx54QjaT weIzk4aXpGULzbFZ2EpwPrOxpiDFBbEccLTJfKwW4st+vyyhORk4wIE3uQ9RSGKE+4CjuD11y0bL kIWy7GER3DiUeY1HsOFxhVQODGVBPlvPklmpVH4SgTPwsrC7ek8P7jw9e2YQ5eLONgEZvbOnM8a8 ma+Lyi6YH6iSlnO+lNZ/NQXATiQrM39L4GGJZ14AGUb6YhUYNdps4Clve3v0zWknw7ZlQFpNiRap 8fnOQxcu6akWorUUF+6OdzVO8FFJ8JcgCSdDyVWNIviLlnJZrHYoEsWoo372xnvuW5lNl3z8soFx 8ulILmYTbMaKJNQNkHq94Ek972JpkR6nx+3jjifpCZoZ9wO7/xZ7R2cf0c/3eakA7Xe4+Svoi/g3 6VM806TKFKD8PoonHSbbehO40wT6TMMm0lSwmVfy4GYeDPE7eJIvkBy06HYNDuLduXWhalCBJD4S hC5vGBmPcb1oMh3jwlbawfNxivZQFE1ZSZoHNoffjj6F7jMBU8FuMwtDPOALgOT458hlhIOgyWV6 lgK5cfi1cn12ULDr9hE7ZZfz/rp/o5/y23LWCkECUvL5vxqd3m8gSXvPnEbL90ECODN4WoD/IKdE +ato1xpjM8MOakj79kyJzVXImg0GiUJTFKpCGBjqmDulW8KuOlWAOxwmtsMOr6NXcR9ChP7rcV+N TnlQ95fHPTV6xIW6Y8ddNVr0ou7bx72wy+PuEb52Xu4cXl+DilZAFJf3i1WjXhDFK55Rl1vP/pIc bry6dak7QKfMFDH7ZbDh2vV+wQqkxm/jVFqKFdc11LOvxrLKNZBzNZ6a+9/kU6btBEUshUYo1U9t J28nn6D+RJqpCfKKp0lgpb5DJQmC/ABVSzsK3qJPkotJB1rG7cyMsUwMJm7IZMmnzg4MUN80bf/L labHEVeUCIK+wPQAoYND8yoUCBzVzD7kQbAT5iXldoJTuAjv51HiAlKhsFcZ26e8CeeumNBKdHHs C8HFD0ym5V2EH5/hx5gUP3aX+DXVgLObUebs/8V2Kuy8i2MEqrq867yc7HOIE+yNzy9dkKK9aSQ/ UibX5fXOz+U/1/lk/snOg8uf6Xyx83Qnt706vHxk+e86f1f9c+fHVaZvOYC2shbmkm3qsbByb5tJ C1uSMf+xcOTemKZ2LvJTHXznoiUby6A8Qa3U7UvUdsLbB9l1IUXRyLXantJShFmJcBauI28S+Dg9 bjoE5408svyV5eRy3R9P7FAPqKT6YFLqWj4BLns6+pSR2AApFYHGWku8YJLFqDGUjY1od2Zmp9OI FCPCrc2jTXxL6+nssvoFddKcSSzN6gpRTy9RMJY0jeNZKBwByamKinw0AcdN2Nf5C7MZ+dk4PXt+ tQEjPxsKYbAD7B2JZiuDjUVXBj0c237HmzZLMKukG7b46mVHjlz94p7N969oj7QValE1mC5d7Zap h8yzi3fUyXg8E74G/GbQzTtn/9cNiugMxuO9nyUvWX9i+tbaQLItF7sw7+Uvqqw5hiKqfkhjdUhj CaIMvjABivcYlPaMPy2KhAO58ZxmgMjNUTa3p72EwipMgkwmWvSWmKe3hBxseuv+YNCbjOlNliGT JvEZJE6eIjG9kU67kWJj3gQ7v8D0Zm/Rm90OH85fobcmBH8BwdWdLhxoKFvzfZ3kwU4w0gnaWPux MHtvW0ILK8k28liYuTcma+FIMua0ZzN+ihTlRCrtb09PgKRean9Z9BJEH2KD5aRTgMQEdd9UIi6N y4dkUpbhDTtLZNyxw37ATtof5KVK539BRy0qMtjfzIyrlQnjX0hDYq7o8nQUC8V8kTK7EzlPKUgU Xe3BeSqCeiekIeQNqS6glWUklGuYrlpLLMPjzvmIl9nrpSyNq8OruhuWVG31kSPMJccu/dSVX0h5 aysateUxj6iouZsXt/lVwUatmT10w4oEJBb9frK/58cv7Fq37uPVl1bDIB4Hbq7zcnISSsknPeFF 6clLES/CGYLUIcIHlJYLxIPx4l6893m8PsbEsiIbgmYcI/qbmHFygb9sIXL8o08ix0X/eelyRL6U cZbqb0wLBn786TER4Bw1qVgsj4iHxA9FShH7RFKHu2FxTKTFZp6c2MyTE5t5cvgqVZLL5xDl62Le pL3LE/autDM+gsGYcjuIYzC5hHLgMJh8zPahjUSIctJ21N/EkiPg0Yzh5KovddXOz3tDaW8ITw7+ RqrbnfInU9yoQ38tsQ0+7XfoIfADU42wEu06vxceoD5tkWz2/4j+5g2D6maI/OC53KtnCTO1YQZJ 0QUJVGBzu663t+t1Uw01aCPA3EmggifAz6C8Ep+HEukEASi0quLEERPIIybYrNsJnmi4wPtA/TZh XGMK/P+vMQX+Mm7aeu4aQPyta35z7nOIxkmw+tw17N9xDUv8x0l2wTXC33GNQHxwUmhdg/IG74a0 HCE26PZgWA+tDDOEFYQoK8rxi3DOstVJ86EkEfd6o5AfAJ4FG9khdgc7x9JsHhIBXoEaKrdvTGWI oSsGxXrvH2X4Sep8An2z7uK5FSQMMOHdG674zgXFlYU2MeRt71Au8FgtthImhYz3R7sPeAOVtpLd omUvzI6hNLXFBlpw+dxpapz6gHATSeJmfUN/ArykgpeioF8BW4LXBMkfBcCP/GCL7xofud8F7nCB +2xgtw3sY8GtLNhHgltIYNoaA4WYHuuLUbGYJhnqZJizeogJ6n2iPl2fBvnBaVz3aLqjMPiJP1BE awM4yFhbjqyUl5H+Ngd8jcqTL4OvcyT4/dbHdy5bdMPB7VeO71q2dvdjW1bt6NUi3Ts29OxYE8v2 Xkt90Pf5567b9p0HB/o+/8KOPZOfWfHp6rWPbF3z4C1rl+98ZMtlX9xeg0R+I+Qx11GvEQGi4xmZ 99iAeQKshaa9p+AhPTIIBCaomWM2PmBHWvAU/A/HPPvrF4Vfvwh/ZC8aE66ZjmYeHJcTDixWIa/T utrFQH5ZrMGm6u2iP1tPUa/F7Ynu2ux3a/WgKR5nlQs6ya0di8OWOJp7yyH53ASfdpYY1qMi5MhM wkTRdOLfbUzBCZxOOccwkiIXkHCQfCepEhGl3tctFEELNEln4AMtHUUspT49W/zpYLE++3IRPdtS Hi9o5KrNFPPTyMwchPSCTBQmWllGVZdR6EEi4Z9cZio1nzfjJS/vHs21XTabzt9449Vqtha1RZf0 5S+5NRNh/InO9VvrfSPd0drtJ//hQGeFPNumbb3y8nhmnV6VsxuWxLasszoXLauXlM5LtuWW7/7s V66m5+aIYmMHVYHfjyF8c2829kH6ijeGqMfgEY6wE4tO2CwMx9AoCr72mJ2xAg5SyFG7BcDv9bSJ ZuAXm4LfbAq5sPM/nJ2ectWE6SL8AXAQKeaEajUDouQ7R49+dfZfyZF1jXXgOPXB2Uf2NYbAV7dS D7w1ezcBR1Fu3Eytp34JRyHO/Uvjfnikf+5t6ohpO2lGei/8HVY0rqeOQ2qwEcv1YDe5j3yYPEHS 5CP0E/AxAwr+c9g4q5Wjn6PQYqQ26v0jFAnlRr2En/h0CSoK+Tx8ztMoiOcFSajuw0ea/H/sfXmU G8d5Z1c3zsbZuIFGN47uxg00gMaNwTEzmPvkcDjDY4akeIuWREqiDuqwROugZFqmHGVlWY5t2ckq cizLlkzdayey5jneLEmtIz1zY8vaZO0Xe21TWWfj3bcRAW5VYy6Kdp7zx771vp353hTQXd3oru/7 fVdVdZeVeKkTuxZ8vlMPD9Ykq/9W4vuGf/6ST/EsBEnQDCro7g7De7kdRvUqjH4fbW/qPEI8o6Dg 3XoxrPNluOcgPOId+Qgrg46Yhtg9ALfVmO3ybgztSUAcfUVuj13enoRnbJLPcHyAtv2w/lW53inX 74H1aO1wFeaSt6/gB9wOQitwp1zv+T7avgvWf1yup+X6TbD+GXnbK28vP9MPt8cxFOnBLFW5T3kK m8T2Y59qVvbGTs2AmYV9o8dG8dHRGMdlYgGP6x7TaWgYlLSLX4zFKgcz8QW+kuupVSp0LF1zLagy fCCHen0twSw5OjUntFrY3qkp0iLASzTaZ7OiREkijHoaS+2lpaXGEvoA4tKPvmNuL51FCgB3vIse 3v+O3NEiIYVYRCHcehMje0yozXZ5WHKdRgeu2ELRc10h64q9TiiDKUX3rAAyUUWVSnFnckszbLC7 9Xa/lzZ5Sky64FE++6wzNZxttxO1ENXZb+KqiU4gXgtZ7rtPHyjN3zmT3TEYtZbHdnZedIeCAT7h zdd9WvBZXGPQm/zKU654jbcwdp3exTmFYGJ4MfPMSPszQxO8ShB04bFe/GD7Mz2jUZMg6CNjDfzg iHj9dfvGU45w0a9gahnfL5zBcNCZmjpUfmhHIBcP27WgKxvV3cpHoGTuwJ5utm4b/OS14Nq9ewcb jcnBaFSs5Wn+2OBpPdArleEAL06JIC2CQXFQnLtrcuhmfm5667a5ucF8epufPqaanuiJhhqylCYj NfJ6YedO7La9Bw5oulK6eA5KSRZTVzyynKQPCwqqzuKiuX1WEqG0ltC+srgssnPrBKaS5ZUiEOfR K4XtAXkZaigm56oZXk59oOS6ic9vkSSOJOksFNYJMlcoGnHFGwOHBrmkz+L2Cj4TEwi7PfkkTxoN 4J7yEBXX+SrpTjFeDhgCtsH6f9b6GwWyo+d4yWe6UrzRxcevl+b7E+rSa50zV8iW9mjsDuUj4XLD zSUVDjFhZ+2kI5SmuY/uKCiIdrXS4g1AELT8YA38+JhJo24/2z+ThDI2p2Z68dkPSXzn109usobr sZ1bL64Je+ujZQ30ETBOQbI+CfXQgkWwm7CnmpnJyQXrrDsana3XW+MDFp6fzeV5SY210i0w25pt 7Tu288C+hS0cf3Dfzh1j9eokEq1voTZOMsINN6SiVocDKFL5vKQXUti+2YH0QQuvwrrCbVyUJBHa 56tEDpAmnu3qIZK1eemsdDG7KmkoZZS6iMiud1cn6coYphhoc01CUNPqhCy5NbFDX9YV8BUbv0Fv lYMav8fNG2wM43Nki7TyiF6wuKIcJ8TprmhIk9VLT85t4VTRfNn5SZYK9cQ7gUhP2No5pOf7Ch19 rk8wXCloE1+dv20CiZp4DIQ1FqfNn6B15V13D0yDgF6zJpPS1oFCWWwl7ISRoUc+mKuPhJGYARka 7cWvbX+6MRrWoW19fGboKikXj123aygK5Yx8FdcZJJ6F+rsdO9jMPDgFDk7dNoXfawd2HXN6GAz3 9gKeYXILcW6WzyULxRyXSxexWdW40OrBYknUgR0nnefNKhOMGi6i2AaWSCWvMJ0ocFg0v4vcGQzJ qHXxmMx/h7Qa9QQ+pG1r+rWisV0Lq5YVFoqQeDa/6/7pVCvpMDpYMzSZQU8m4Aw69Rpaind+rvFk YvFlpTp5suemLx1oHhoOQ5VkWN7D1CVPLsWTHlBzlSt5O/HcpQO3fPXmsoXhLBa/04Dr3a44Vb52 G/7s1v1ZQ/vZ2Hg5uKI6I/f/+V1Vvtjr5ZJad0qIRZDatV4pwDhDhexiZ1D5S8jXW7CPY19oTmuw cZ46eTyVorRa1/3UvYfAoZ1HT9dArVCY5Y+mjwLqKHU08AmX5T4+QHN8IEBh6c3j/P2qw+f3bjOd TN16azlztxCN9gsZjCbVLsj4FzxaFNF0lmRdES+aZeuI+L+0JP0Gm2helQKa6SgrioSqkaL8ziZO +m22E4pC+pcECz5kG4nnfid7d/dvs6B1V6lSsMfzux6Awk+sCV8MOrll4UtXm0pi9He0f7/FokLZ /osQAXNX200cRqeYwkX8ChOg3TzbPGY2u8Ietyti1OzU3KAhOhrwCw2Y0ICYpqLBaQ3QasBfacAr GuDSkBo+4rJFIi6jkSQjghCivUyE4dU5Na6GX9JKtU2pVAOQVjaVOK8ESmUkFBY8EZrWuCjSqAQM zwpmUq2RcyXoLTvZJZkgAMpIS92i5ILuUhJPmlHvNrjRfNK4pITggbshQlb3d9eEvvHGm7rVFKrP pCUU/wMJsMQKWnKhcDggv6EfIYgKEKQtFEnQYNgMrrOFwlFn5yDpZx0mY7HzVF6rsbOsFmQ/xwN1 cLBJMJdeSElumNcQpN1Cxdh77nEGzDbapObBdeA65IEcsPgEcQFGqL3YDLb7xYcmgGfG/jqRxYpY kMg2+dEiJNVs7wyvgkkY7UmmhZmpqXrfgADYBNlbF/SsEeZiaGpMFv1DPkDngWaqv7cElaGrKvJw KAwUFqV16Vggyyq6mQ2rlD+NBEegOT91Bcx/FPILsByOlbwSbTrKTZ9KG6gXwOd2fXx3NaDLtgat 5kyxlPD6YzGSLg3v6rvJVGHU4XQu4aXjhXzK6ArbnGORymzRQ5U/so3OmHi32BfDw5lWwsYxYk9P 0VodTzkVCsLoCuWHUuJQhlGarHolboUZhs4V701nhkSvSUEQl76oUgmVYc4+PlbEcWTrRy7/RIFD HDawo01uqwiK1iErflAE9UYD8/n9IIBlIF9XXmHca34FctQ+lQAJvw9AcuqETKMxVwblDITTN5xC GL0luSFB9CB+QcZREpAXvkW5uCQH1OfQWtNoQWIuRaw4YhurQCNcEDpOo3LNXjicEEayHSF+zatN Dp+d7h0a5cfu3p7lyqPTU8HKXRUX53UaOY1X7F+8Y2Lfq49smTn1+rUT+4Mu1kIqFRRlUnD449ZY IuGg46y5cesz1+56ZH9fyBSR7OFIwm0zVwYGK/zoA68dufHN0zMBE6lX4wqT34u01AO1dAfEFoPl sD1N+lQSVJKgnHg4gVfC4EEdGNKAQQIM4ECJ+OIzx/yxR2NPxRSxmKPAUDnewXICxZrInCh4WWw9 yIB48b2l7qLAaz0UK2kDwtH6tB/IXFB0QQSrcevj7z46aI4NFWq3H7+z0dmZKPn0Zq4QAhWSj4tO 7+zizjGx/5andpoiEYEkLkzd95XF0J5D+2NQtRW80S+F8OPJkl/HXbqBUCsJU6ix+4Gth54+VgcE ASAq8lCnDsJ257DrmoWQwJtMFori0fuH/Tzg+WRBiiS1Lj7JW3iLixVCJmACGlJwuTQRNkRqBGm1 sfLrp7tIWAYEENtL5uW2QzBkESKyYjfrdkJIwOgaiTwsUd0N2Q/JGFCv5wmRJXllun8i+L1vV5qM AkU2mkBf+WXCnozOZGeHejx8ta1Nw/aqPVKcuPCz1khQ1bmDTpSYzuN8OerovMzGab0hPt26zPvE sgffjPZysPXIovTD1iex7c2w0UiZzUnMD+CfIMb9Aqtx8oIRM2JqreA0O82sWoizSdSZw/hZttuZ c7Hb1LUGn11p8bms3FzY1rWmFtc39Yr+ngDRH1bYYoOFzuci5bBdwfO4MdQqPqLy1gqdQKnhV6vY ZoXw4xfTA0l7514NW8t3/iDeI5g7l2Be6OF5R7IfuuVIf9rDLWv7k+u0vSKCUgqUY2DQCA4RSOkB hjE8TzddwOXq1SFUW5C20yyLeb0WFdJ2WdVfdFoEHik7NJUNqavt4nm5E0tW9vNysiUr+zK2ufWq DhtNdSdlGAm7XQ7Cr1J5hYez1+ePje5/bGdSaMxs2xHh67mYGWYtX6NFzrr1zZsevPD4pvFPfe+B whHJ6jLrNBaHQYUL+Ffye8dTsw/+6ezMfftHRIeesmqAYqCGQ+7pAz2Z/5Uubj51Zs/+Nz69YLNr dSrcZHdpkS10QW1HnqSKHWtWVQ4Hz2htJh5jmEQtG07k+SrLJzDBxPpYkZ1iT7NfYFWN5S9vsUqW FfJZrYpV5yAWXuadtjDrEFA01u07QDEZYsyNFxEe3ltRgaX28idERL4r86v7/gL2q5Fh7+Yv/Sq2 VgB/m6/7SX2wlu346XyC7jBqf6PccRcbPrWabZTATwtNvxa3vx/uS3k4zhoflNo/zA9EKZ5Xeat5 4GtH+0QIFo/YF8UFBCWOc6QGUj9DXAnD4iLkCo1FmnraZOfV0AKZDehx+otnaJzF1vovkb98F7Yk cPWdyu0BFzsVscRoFXQ5D76TL9MKLVMSeXusHsH7/T0iwyF/5m9/M1KP2dG1vZd/gu+G1xaxWFNv 94UxFZ8MY0lWhNd+0eMJnjcjd5MV5aufb583v4fe0NO9nk2lQnb0ithzXfCZD+C7c2WPQqHTWct9 I5yznOV0NsZKuSwmDUVr7S4S1wYaefA2cYbN9PGdpwJ9vTU6PZR26T1x1gSdDmnxmDijV6wHcQFy S7YdkFuKO+Adt2AuPNRqYRWg1YKKVq1Nlyq2klZXqlRgbKY2qYFaR1FurU7L024b7dbSJpNOFx0U +Wg2UKL5KF3i1aBfzLKZFmxsk3RbdKYAz1LBZUjBgK0Lqqz8UN06SEFlxN44qZRjtCwK2RahiaWk kxoYtinuXsKQn0GRGupkVqjV0LnIvRsFBL8w+A1GqCtAsNypm1f4Xal8fdOB3jtAf2P/ZMXR8YRY pd5m7Lyu9PXXO0EkWFnE78XrUSugdH7GbvN4lMQFDjeypbn6sc6ftCbCOoLnGaPGaHZQYEfnP3I9 CRfPe8WqD+9ne9Isx+kCNanzDwAj/ZxgMlq0BLeMR+LrkMNBLN+krJTF4uH9dk9QyXv8GBuAvHrJ ohPsrBXy6WL7rIyM9or5PSetwmPVqxBXtBXX1lp+FQ5T6L92NYbHBX7+0vnV9vwX4ow93hLbjzkD Nq06MjfZeZ9nxSqD9wdqIi3fXRDK/5/h3WWxP2se2k6DBwG4DXoOD01wKQqYKB+FUy6TQsu7cZcr nsuE4gEOZtxmDue8f4KBm7CPYfheDLSwWQzN7VZBZ4RjTBqLm+N4PGQxcSzlATRPkYzXm3G53YoM i3d9LQQF9KWIGkvvZJfMl+R+kcV2tmt/s+cXF1cAIkGjYz67iB5AhDWZtBb/DUaHA5CuRgPYDoN7 AQwXehi10lsrdXoyebdC0Xkh0HlBYQ43052TxSqtJDw9ZeJCO4G/w3mzA5H2j8P9WS/PB4ojUXz+ 0uuEt/2VXJPTQwSkijRO9mwte7nldR8Vj0D+hbE/al6jNaU/jYE7sVMYvg0DEQpglIXiAWYDmPpR AHoBMAM/SAMCAEs0TAfSZjdwmyxAY3HRrJt6oMt7s5sk1aw2cNhyhwXfYQHDFlC2AEuIxbQy4965 KLMoC2P9xjvwKwr6gbhz8exi+7zcVQErz59cTnkWF11tlB6DK3SDu1JtoKfLAw5/0hBsZMARfyFk 59pFXbA333mo3ONVBNLRqAcypwwudm2thimmLn2fULe/h/pvoPvNDCXwg1zMoea6Kw3+RFGEXtsO Y/EjTbGYGkrhwxFQjoCSf9iPF+khGt9qPWTFt1sOW/A5wwG0cOB+Nb6dOEzgJPLhFMabeb/8Wtav 8yqelxxw78sYI5h0cUEpJ4LyCzcufiggXVy0rna1yHm8oth138v5jVExMvrAKzccfe2B0bEHXrk+ e9PRg1PimwQltA5PTBweEChCaYu0Dgz3XTOQcGtB+9BLD01OfeJbR6/75qlpe2bTbV/aYdty7ZEd 1eqOI4dmbcHdB/dPZ2PDiwev7WbIxM0QCTzM48ZexdSwGZxZ9Iu4KDJlu0ngGc7FCDHBpNfn7C7W QRZzArcuyG4vdRO55TTu7EqwDZaTNnl1Lyi1ov3qUHs1XwOvOmf3HNicq+28Kd/Yk9ZyAz3tdrAu 0mSwVQFzGl8obouPSEy4NhoUhmzEBcLENfYMDR/sZU26zgdCT9QOww4l06jgo6neqJXrxBWkRhWo zmQaW7J2tRrJN9y5pPBD+QawGvbz5vhQBQznwUgCHI7fEcf3h28J44NhkA+DAR8o+sA8C4YYUHDM OfCCBcxRB6hbKSJPgbJhm+Faw3GDoqIH21TgIRyGcjYk/GL6hBfc7AV7vGDaC3q9IO0FKq/DG/IS pwkY9t1O4F7CSwS/mH4+jZvT/vSjaSKdbgTRubZvkeBrJPg8CY6Q95CnSYIsCtDxv/9yVPASugCL oTWeJBk7CC3dPG+5v335D/UxXT0IiyLCEB9OKfNrfXnQXauhMwIfgpjC/1zntUcW7plNOZTjD75y /Y2v3T8yP+wR01m2sHv7XOLSXy0D7iMy4OzhgRXAdS7hd95t37T/yJ5x6ug3H5rY9InXD9/+nQEX R9u1vdMpuwJ/67fjD2YBCla25APYp5q2hyvg4TKIQxPFJ+O2ZDIOJB5xSKxlMsmPJcGtSbA7CXqT IJmt1WxZg1ribbTJJuWFSBzEVQAYBvoED+uVnXkywxr0JhYzdJ25+ZdyTkgh07y4hlhRflklYhWF AmxLudvxIs+gDgCVahnAH/LW3UAHIlzRde3A4SgU1o3IEt7OvzFaKauejWesnajUCOjIQCMHnvVP bJoRInk6USiIRgCcsXiaafdZYuk8w8a9RqYwIXoLZvBdlAl1fl2uM0qetyVaaTwsDiTsnMLko5mF amowx7uMis6b3jhrU/HgA5gcG42muFR0J8aLPrXc6zAB47p3IOLHsW+/TOkdYxCqDvQMsalszvlz eC5Xn4wI4bAe7ZutfxX7JoZ/FPskhu/CjmB4CgMmzIe6Iyj1/RSYofZQN1FEjmpB1yr2n4iA6QgI RAAWMUfwSKQsniqDxTKolsfKeJlWC/3j48P9CMKiQIdCfhrlMIi9K1nMojwXVcYvZVm/tQjtI0xo zsnb8sD3OXm+FuBCoZVBPjRMwBIrQ39ysg5zPFa5YlPCKWIF8PLzifineDIU4xZiwWyQ4noXyuL2 gRg3futMqLck2ixuSqfgOFO2UpUEJT+Q8/vKM7nsNZNpbuBgK1JPhyinSxfCn4vvkOJRO5dyh5uV SoBuTu2qJvZsLpotZp2JUoPx/sWegJGwhqrRYE+14mPqY4u17OJQzEgZXXYoDxHa2qch1n3YrmbV x36eAfcwpxm8zkwyuI8RGZxxYOBTODiK34vjGbwXx824H8dxk4Y3O4yoh4MBTo3QNb7tpXe76cDZ 9tn3EN/OZc3Ln2sp/hWRhsymIvGEkVOxqWrwD3X+ithJSlVW8wdSb4QieANx4efFPl7fLgmNpJvn 3cmGgH/XEW9Efw7vXgP9413w7svYNc388QTYmjiUwE9R4GEzeEAP7iNBqeTJYqp0bxaYs/5sOktk s5aqx8+7LLQLlNiyB973NyLQGSI3KAfVKJtY9v3dz9U0djlQ6uYWoQ/nON3UFo0SdUPluypNn8ri DCzs2xv567dIlE/8tNDwa3CTv7qjPzg+1LBbHDpoSStpGB3Tmf5I547q8Wh5KGJ89WXw5W54YE8M ZDrzhmLfQFkw0Ak/XSgWGfC0vxB2yDETCduvkCPi+5uDRRqoaAcdogmnpqiBSqLSaHiasdEakmYC AYahPRSlIV0ejYdMuzw2F/xHBe3RMQGXTQVIirUuR5QrPcMNyA/Ucwftj5xaoGnucmewvBPmFfIe OamQWRSSl+GwWpHRCS1zBz3AJcdFn02ljLrOfyCNGkU8BMxBMcTZO38ndJ60CzwKizhg9djCzvZL OOWN+Fw6t4vj2OqWQttGDEolWoGyLM/ln6hgeInVsbea991uALGY32pleT1FYfpEIpv2P118qYiP F0G5CKqFsQKuKYAHSXAzCVQkIAtFovR07qUc/ukcuCMHRnKglAPXSselhyWiKoFbfcAn5fI6pf8h P0Dv88D1fr2/1MQwLV+q10ukL69T2HIFXS0Zo6CzimOWLrtWx5/lhzSQNcmKK4PPFjnUlv/WfV0+ Qj6yC7IuvmTuob7RZWQhs9JlJzQhcqfJ8jLuMke/QDEOg17/938e8cQE3gbu0dEus8ZgVL337wkY +lK03wiy0Jwn3J23Q50POv8odP7CFRLCbshsQu+w2Di2/S3wxp7moF/JcTjpsOt8waCx/d9BW+0N BI0OhtLiHKekYhPNS238+vZjRKzaH1AjSaBxDI3sJU80e61WPYaRGlKvWfaR2WwcOsQ4qfd4Sa8+ 7fHCNNBrt3s4Ly/E416rEGR56Aw9Dg3QW1nbh2GHQriyrIrnsleAz2U+vyjv0SxDUWbeOt4VCus6 U9TE+v6TfJdpL5PBoNtu+u7zjNfkDlhAzRWJpf2/VDC9tY4rU+f0nf/m9PkjPgRIrc3ijDg7fwkc yTzML0gCheyVTOfJv+d6syzPW2ID0l+Cz3MpWod4UpTfO3kB5jLzzdT9WqBVazSYRwe0OjAHgA5g gCd1NpLUQWbZUQZLaoBAkjBtXTagMGs9iwAkz6xaG26BYYAL7kMTgEBgOXftTgPirMT32jvAx7fs r9D6UOjSAfzPOq9Nbpdcet5LXLi0L1CZTHXeJz5rETfVgR7Np5F7dZQP4iHDxzCUZv7gxQnM1tQC TPBp7E0Ag79/wKCxiufRrGr8S3hN+TjmhPmH1HRF7CBsumDCw1BoJ0IhyXUC+g35pf1bX4grlVjj 3KXFc91coptKLOcQKOpWILe4LodALlLhLG3eFaLr9XLCw6QqPUVbdO+W8iNAY/aJwUCSMauB1ptP snEGcl4R2P/JbVFKqM7eMDh282w5aAxtf+w6S3N8shmJ9U6NVAy52/b3+wsDI8NQEsfx58Db8p3D UNbhdJImDYafMDmtDqAmMQ3QwHt+HsBbvrT4oyU0sQCI7exZ8/msiDoKpCujK3kyexgMCwZ3yNN5 wRd1aTVOaCxtysfbJ5mAifD5lJTfA86kcjqtF17dgj+Hj8Krx7EdTYtaqVJxJ4xGdzKm1cLE3Q35 1TrDxlRoeblW03JYC8raEe02LaGDiMHUQI3ujZXvDeWn0EJkkZlAc8FEaWUEHd3mSt/4SoiH8NCd xSAHgXZwOpLymkmxr0N+9DOzdCBbcoYKIYdKVDnz24d7F6telSs1fXwLQSoNDvMf0tecvmFLKFLi zG4ubHAO9acj1ZbXliy25q8fUCB/U4R4cMJ21bDtzYi35jmhDJwo1ZSlkrJGmBvxuMlcq4GaFzOb MEhkSsJCIPQa2IqRoPW8HbboIgTIueXRIUo6BwMrCU0odMIdqwNt1nXNCa80R70WW8mzUtcmbXKv ofDIyadcgZTPro1omNx0jzBU4g4WKrQyPHFsMtMXNvM2VyKW8NBp3hFvbYkpRKVTKIa8cdpooX1G ylKSBHukIkxO2qrVtCa9fTCmt7l0TgdlpexCxpvpi1BQH/RQruOw/SRmxIaaZgOGVJxUEOCEUa9W qJE4TUatDhNBA+DoKTU09XPr8xhq+aI8a7I7GwKW55Yks/wuBHnCoR0arDxQc1Ctf3TkyD2d58Dd cUUH4MrHO5GFM2cWwH96ovMXSAJVKAFR+TAmYL1NNwyeNScYJowLgtlM8DxB4FYXZgAGxHIcshxb Y7kIFTMLkQT5LgMI4UfNrbI1dCVXFWErLkr/lOm/dVuusvN4o3eTQLkiobCDraYYpSMxdfvcU8qH F3bq0iO7KuW9I/FY0O6gbJQr1sOrQ9miGMCBPI4WgPebhxxjMQkrN50YZjiRSOR9yuAJpy+jhNYx jFmABRkQjF02ICgZOoeGybLZLtbhnUK3tzLdYHVWgUICy0PLa2k7zvVdv7XfxQxIiU01ITK4q1jd Nxz1luduOj3XOU0oTcFy1BbnnHpfMS6UlbfgibFDdaPbW5jO53cOxcTNR5rZw/u39Yc6J80xDzc/ kadC9aR7tJWm5fkxsDVFyH0dtIZGQMD24ZhBpyVJLQFl/w0M5kdr8panb0or0zeRpAFn7aK6iBc7 /7jzf/xM7+Mjjui08uG2Gz9FWISg/lmMkLWMgTwLYyVsDNvUFEwgmRyM2PJQ4GXl4CA3kQdKZR1w ZYzNkrYI2Y+xgEUXJmWjgRTMjAo5bbm4vPIBGpJCU6eggq2lIvKY43rV6sawXWYihwqD3S6Lu53E Fzy5BB3o2SxJs/UgJ5UcaHwp1DefyW3vC5n4+mO+qENLh2OmwkApbdOxXqs5mA/lhzV0PqngqJBY 4YONDONNVVh/IRHUM1KhEowNSV422wdj+3R+lz3Mc1Qk5VKVk0Kf/7jGE85x7kLCW5MMvnA2sB5T XuiVak0P4zyh9Pul2AkDRBcjIlAJFgzzAi9iiaXLEvMqrLoJtShdlGRTU1w/BLWML7AcRKxODy9I fddvg7AavAJWzXvfOAFuhKDiSutAhb+Jx9dAtWsoloagGvvC/bPguCnuCW4dz5shpDwjEFLQGzsv /xqv4f+VUBvHMKy9GdN+A2BWmI3k88hXH4eIeluuHZdr1S9gGhJWojoLBvBRuW7iqroi/FWnXDe5 UhfSLdfp4Xnjct3U6hXRNO/uFavwTBF/F9ZOr5xpWDkzAOvy8pmbVs+0rN4rB2uL8pkzK2fiunX3 w8hnbpbrdGdwgLHyqR/65dnVX/Z2fxmtLIhh6n9W3o3NY7c0ezZtMszn87WpgG+In2fnszG+Ng/J to2hvTaDKmiybcpnTfpJNmeYJof6EwFBTdtVHOv3szjM90XUvSIPXa7NIDyPRgnkiAuNVbfPU5K5 nV2dKQr1FmGBW7cmKXoYAj2qpILhV6AoUYXi2huZu7Nf5GRw7amZ7mv8nOve46d4zlndN3mBFqbF 9hvpOd7xx4ux3Kg6ZFYUvpQ60tvbXSRNafLG/J263R/3mpWE2dRKpwuFEZJkvEOdSj1o1+kVDWkw bvvgn+72xQQh57tZoTdaP7II6pn2zcc5bsti4yudfzcX0FuNap4nrYwVraD2RDKd8nimOt7ddqfZ xPNWHe2dw9BfdZmeALZ1NAc+DekyPonfif8p/rfEceIXireV31aNqSn1ec2IdjPpIHeuke4tg9X4 b017zDSloN61/I3lb6yHbejvC/Zzjp87b3fd4i57HvaqvM8zLzIv+p7yPeV/ex39yv+r4Pu8WWiE nok8Ef1BIpT8luhOV7JHpMX8t4u3lp6tWKqNnvn6q42f9Bb6zrU6rc7g4tCO/4fp4S4Nvz7y1u9K ow+u0jc2aIM2aIN+Bzr3f4R+ukEb9PtHY2CMHstv0AZt0AZt0AZt0AZt0AZt0AZt0L+aHtmgDdqg Dfp9pXEw3ho/M/7N8f85gU1oJgYnJifmJ3ZNHJo4OnH7xL0TD008OvHExFMTz0x8ffKjU8emd24i Z8wzL26e3fzj2V2z720Z2/KDuf1zfzx3af6r85e2/tG20LYvbnds/7sdpxfmF15aLCx+becxSJ1d 0/8X6MD/x/Tmbnz3Dbvfv0a85uQ17+8J7Hl+r3NvaG9ub9/e6b279l6/9669H9/75N4v7/3yvsUN +v0n+a1omPw0wGZwL6bCbsIIjL98Gs18ufxDWFbksufyGcyG2WDJYwSs5WEtA8vK5QVY9lxuwXLb 5UOw3C5/X4BlFDPB2ihGySUPa0V47hlYFmGtCM9Fe3ouS7BcgL8pybUSPIuBJSWXPDwyD49/AJYV eEweHo/KhcvPYUV4/A9haYK/U8TM8MgiPAt9Zy4/CUseXreIZeVjWpdvhOWgXA7L5fjlV2A5I3/f In+fk79vlb9vl78vwLIiX6UCr9KCpRlevfK/mfsWuKiua+91zjwYmJkDoiIgwkiIUUOIAlpFmhpD iCGjsYQYY7lGFEZQGGaG8UVUvL6KRKM1ashICFHDtQjMMCXE5nqNVWNSI9xU/azVxOYhNm39jLHW ksfl3P/e5wyOxtvW3ny/fp7ff6+199lnrbXXXvtxzs4QaGH8EFibAS1DkGZBVwYks9QK2zIgmfFP cn4GT/PRikzexkwK7+1BGoFnM6kf54dAZiaXlglpaUgn89QKjZmQxvgneJ08XmcGT59G+aP0KCx8 Eha2Io2Qf420H556knJQ/jTKn0XaD+lMzs/kfD7n8zlPlCEeIPZXPNi/+TzV8MiI5zkN/1tvkhCp 8hqaQR+pvDaojo6ihXEqr6dEYZrKh9CivjoGGkWtKh9K6wSXyptFj9DDYpH/G6PdovIChWvfUXmR QnSDVV5DyTpR5bVBdXRk0qWovJ766TJUPoQm9NUxULT29yofSg/pHlN5szBF9zwkC1r2X5OZ9Oc4 rwMfof8j5/W8/GvOh7DykBDOGzg/iPOhqg8VXvGhwis+VHjFhwqvDaqj+FDhFR8qvOJDhVd8qPCK DxVe8SHjw4LsN3Lb7uG8KahcYnzI9zjP/qyIFPII5/uDjwx5kvMDguoP5H5Q+Kig8hj+7DzOD+a6 FJlDguokBPFJvP5Czo/k/GrO38f5nzDeEGS/IUiXKajcFGjLT8lCqfDIaKQWyqNiKgKdQuVkB9y0 lBy85CHkXOBZWoDyEl4jBXcepFJcFspF2Tw876YKnisCLULtRUgLUTMP98t4qYX/xcPFvFY5ygog yYK77E4B4OY6ClGH3XPRApSVk+0fsu/Wmhl/0w5m+TxaiDYx3RYaDhklNBd8OZ5hdrgxI0/nbatQ 9VhoLHSNgxdvSFdk35A8jZ6ApLzb2J7Xx2Vx6xdDhh02WOhxaLNx7ezufcATeI5JK0XJUtUTLu47 JjUZJdN5fTcvt5CVt4L50o4yCywcj5UhFXNaOdpo4bYxOQt5bzHfF6s9YeMS3bxPWN7BW1yGu25c rE8tNIc/61Z75WHMmlbEg/KsK+iOg3uvEFrmcokl3GeLua65SG+vV8mzunPR3oW8FYW8bjnSQn7f wftpKbfSzu86uD8UCXNVWUrrWbRavtXycu7NpbynS9CzFh53c/p03c4u+7dk//1euiG9sK+fXTxi 3NzyuX3Re/vWK9q/bdeEIB+wlihtcXN9gXHB5CttLUTJYt7ycj7Wbt9SxdMFN3m1iPdsuZoqrVL4 hcg5eGrh1i7qi1xFDqtZihp/tY9+akkdNTrVkldcZJlSbi93L3UUWR4qdznKXQXuknJ7iuXB0lJL bsm8YneFJbeoosi1qKgwJa+krKjCMrVosSW3vKzAbimpsBRY3K6CwqKyAtcCS7ntf5YXKMy4VUZu 0byFpQUuy/ApJXNd5RXlNveI6UWuCjxjGZsybjSvjtq88rQnpuT1Sc9jSZarYHGJfZ7lcZutZG6R 5T7LE+4Ce2nRUhjhKqkotydbppfMdZe7LNYCV2GR3W0ZPT4t9enyhZaygqWWhRVFFncxGmErx52C CoujyFVW4nYXFVrmLMWdIsvDT1ofxF0Xzzhc5YUL57otJXbL4uKSucVBz4KW2OeWLizEo+5yS2FJ haMUCgrshXiqBBXmohbUp1gsAeXl9tKlluElIyxFZXPYUzdk2QO1b2sSr17I2uwqqnC70Dq4Kkg9 Hu+TNYFbMLwEWtxFZawvXCXQWli+2F5aXhCsFEYXKKYWuSxobzlUIV3odix0WwqLFjHnok5xUanj lhZhAi7nQ7EAQWdH0JezgSiYEWjzkf89n4QD9wPTaqEyXWo8mjbNf2jeAn6ueVPTHCSL1S7py3/M ZRfdpKvoJmlcnjZeO1r7mPYR7feRjkftAgwONuyUhaBY8AmvYh/HJoMHUd+FQWTnMvr2lSQPRfXb /9MQ20H1I0GW2dpONEW8mCqSZivRJJ3OirxFCe7APxn/6Adyb96UqbmjRhGtU/aKRCZsEyWR7Rme BLeBBHGj+BJpRI/oAb9D3AG+TqwD/7JYD/4V8Qr4L0Tsm8QvNbBAE6nBHk3TX5MN/hHNY+CtmhXg qzRVJGpWaq6B/7PmG/D/pa3AvsWtdZNGu1C7FHylthL8s9qfgN+ifQH8Vu1W8Nu028Bv1yWToLtP l0oaXZouDXy6bgL4TH0WCfqH9dClt+qngJ+qfwr8DP0M8E/rfwQ+X+8Gv1CPfZN+kX4x+CX6tSTq 1+l/DL5avx58TchuEkJeC3mNNCGNIa+D7zA8SKJhkqGONIaXDZexm/rccA38n0MhOfTp0MWkCV1i xC7VGGY0k8YoGYeDH2HEu5gx3fhv4PcYfeDbjL8Af8h4BPzbxvfAHzd2kmjsMn4G/vfGSyj/v8ar 4P9k/DP468br4P9i/Av4HuOX4L8yomdNZDqEndth01Hw75i+AH/V9CcSTdfM4SSYI8zRpDHHmJ8E P938L+BnSbNJkAqkAnTqHAkeliql5aSVVkhvgN8nHUT5L6S3SSMdlT5EyXnpPPjfhqciFrRqRIg0 lPeR0jtKv6g9As/kwid5BnjbMMMAnxhmGmaBLzDMRWozOJAuMixFWmlYhrtVhn9FusqwCiWrDavB rzGsA/9jw3rwNYbnwG+Gt5mfr6peFeHPe8EnG/H+axxlHMU99gfwfzT+kXvjCNK3TWiF6Sg8w/ww EGmUOQoeGGQeBD6aeYa3JozeFS+TrsBVMIcsc5e6SilvnqtoAdmKi+a4aElpgdtOa9ifCcx+MNdC cU/mZrG1lPi40pGZ/T0FzutJUv9GuAbvFuEUzf3F8lr+hhRBMUElAt4z+lFsX4lAkUyHNW+yheLz ch+zsL9MzmuyvxjSX/3r4VrINtIA9W+Ha3GZaCANofi5jgoHdfD0IE+P8fQUT88vKHLZ6TOWCsTT aJ6O4ulYnmbydBJPJ7MFUpjK0xk8ncPTUp66eLqOp008PcDTE2ULyhYIF3l6mafXedrLUlHPU4mn UTyN57NUIt1FSXfAhdHdNIzuQQ+MoJF0L7x0H/Zwd14eeBe+fcoiQ1TfzL/NCehf1qN6UAM0GNEL ZvQ4+2OSkeirAeiTKMRCNHo8Fj0Xx3qIErCvGfo/PPf3lonocd1taQSi6W/RefQ+ncE78h/oKn0l iEKYECnEConCSCFVyBAmCTlCrjBTmCPMF1xCpbBKqBG2CA1Cq7BfOCacEM4Knwg9YpyYJCaL6WKm aBXzxVJxmbgBs3+TuE88Kp4SPxAviJfEa+I3Gq3GpBmgidMkaZI16ZpMTRbm/DxNvqZQU6pxa5Zp 1mg2aLZq6jS7Nc2ads1+zRHNcc0pzQeaC5pLmmuab7RarUk7QBunTdIma9O1mdosrVWbp83XFmpL Mfcs067RbkCrDFg5jvDRJIzIZjkS04+P0cMnKBlTCg+CjqtWaMZBZQabUKfQaYkqvabQ3FyFPjFK oQVJCp1jUukVhc6fSlr2fW/+GdIjXIQl7aRHWAjPximWLDvNLRGWNyn55adVekWhK2wKXTmV19Ou sq2qXPX8qp1KbnXE6qTV41Zb1dybq7tWf7L6upJbs2/N8TUfrbmmPL+2Q6Hrdir0x8t4LUP19Or5 1Surt1c3Vx+qPlN9mZeGr29af2D9ifUX139VI9Uk1oytyamZVeOqWVfjqWmtOaRY/Fwcj3/huUkK 3XBKoRt7cJ9I98KxFy5tlbaO2pqr5LcWbq3e2rz1/a3XlPw2w7bkbdO2ubfVqvnmbSe29WyP356l 5LfP3L5ye+P249uvKvkXDS+mvJj3YuWLDTyvfbHjxfO1+toUJVc7udZRW1t7UM2dfUl8aeRLimbt S6UvbX1p/0sXmNUkvNSrUI9epZLiEU+USlXP1w1T6Msepd4rkkrZ7obRqUp7X5mt0lKVVqq0WqXb Vbpbpa0q3afSQyo9rtLTKv1EpVdU2qvQBpNKY1WapNJUlU5UqWpfQ75KbSp1q3SVSjertF6lTSpV 7Ws4qlK1fxtUuxouqfS6Ql8llYapdIBK41U6XKWqna9mqjRbpdNUOlOlxSpdpNI1JNyljMLzwlHh G1HEjNKoMWiyNQ1au/aULkO3W9eqO8KvLl2XfgBPE/XD9Rn6Yn0xz2XwdAuuM/ozIfG4doecCOnh ZcijZgarpVyG+JAThmLDRUNPaHaoI7Qj5ETolbCosLiwQ8Z8o8242dhoGm5KMblNO03vmq6a48yp Zod5J6495j1SilRo3iltCdeGLwr/LGJVREPEgX4WdrdfZb/PIkXzzsg4YFV/bX97/28GHBoYPTCH 3R2YP3A+0mtRrYMizDsHLRq0YVDHoGvRUdGW6Ozowuia6P3RR6N7YmJjJsYsimmP6YqlWH1sRGxK 7LTYWbHLYrsGGwbPHLx18Om4ZXHHhkSjpO8K5FDDgBrsOq1ccceUa0g0u1DTNqQW6BhyiqefxFN8 dvyG+EaWi2+Mb8fVm2BK8CdcSLhgqbEcHBo/NH/o8wmmoQfjey01Q58HTiTGJfgTXZaDiXsSzw49 OPQgqzv0BMqvYHViJxzsfGM8+7YPZMrtwhfyJuFL4Gt5kygAofI5MUxuF8Pldmk26gj8/COWn3+w 04/xvT38/IOdfrCzD3bywc49OuQh5o3Apt4e82Z5pHmLnGVuBy6grBu4CPwOuIx7nwNXgC+Aq6jz J+CanAV9Q7A/Y+cn7PQkSS42VwI7gDrgZaAeeAVoAF4HOoA3gB5YEs1PGdgpy3h2UoESdsrCzlg6 IH8jsAnYjNpb5DTYlgbbsmBbFmzLgm1ZsK0YthXDtmLYVgzb0mBbGmxLg21ZWN2ZBnZSw85pkvBE JbADqANeBuqBV4AG4HWAaX4D6MHTUfxEZzw7IWGnG0C+3Aq71sKufNi1CXZtgl2bYNda2LUWdq2F XWth1ybYtQl2bYJdm2DXJti1CXZtgl1r+RnSOX4ixM6D2GkQOwuKZydW0MbOgthJEDsHYqdA7AyI nQCx8x92+sPOftjJT77sRHvyzcvkc+aVQDVQA2wDdqC8DngZqAdeARqAV3FvL9AMtACtgBd4Hfc6 gDeAfcj/HHgT+HfgMHAEeBs4CvwGOAucA3pgb4zSGsQZbw3oELQonp2zgc+C5ycDVrQ7F/knQWcA +YitSsTeDqAOeBmoB14BGoDXgQ7gDaAHz6laoIGdbrGzLXayFc/O+iCdnWyxcy12qsXOtNiJFjvP ykdvVELTDqAOeBmoB14BGoDXATYS3gB6ICdWiRjeliFqW7KgJUvVksbPu9hpFzvrYidd7JyLnXI9 jbi7E00iPw/rICf2VexMjJ2IsfOwHF5qxX128sXOvfp9J+NUI0nyGSkGGCyfwSyB0cjefJBOh9an mFbwxjtqQ5h4n5wmjgWswA97q8Q8jLwhwDAAo1l6sLdKYl7r952M537fyegb+v/FqDGif8PQv2FC D1mFL3sPY0aXRKH3sBgr7zN/3XvY3Nt7WNIB/XsPUyjm/HrU6MScX4/53oP53mP+Wq4398r1kg7o L9crtXDXhru2W+/29X0kWxuEZLlZuE9uFnVAqJwghvX+UgwHouQKEWNXTJIrJFFulkIBs5yA6NFJ 4eAHATHgB8s6SoCUHEgZJKTIacL98nRhtDxYSAP/Za8P1hLa44OGHNEMRCBGIrFi9QeigVhgsDxL HAJYcO8e5Eegt/Ec7CZoz4HtBAtyoHmQFAnaH/lBoNFyDt4X4Ieboro/X/U65ITvpHVhTBoknIOE CuiaBK9OwlPn8NQ51DyHmpNQcxL1g74K6KuAH9rhh3b4oR1+aMfTFXi6EW1vFwcBMUACMAy4Fyu2 KHshzQtpXqykGvk9ZvmtVv9NS0MRSwmIpQT0fzb8PhtRkg0/zoYfZ8OHs+E37L4FtrKMCFp7stW1 pw4zXB00n0MbzqENFWhDhTAKGA2kATxG5XzIzoPsu7hXzEAE2tcPiEJERqNNiF30Zzt8vA99WgE/ 7xPvRn44MAL5kXI77MqDXXnckzpQ5s1IoD945tVo2DdMnYe/gpWsZSKszIaV2f9wxEXJo7+TqBPR dwfQdwcoDDYshw3LYcNy2LAc+pajh89B7nLUWg65y1FzOekCI/amaLWwNqrtyfmnjCABffwhojdF 7oDuDujuQIzMh/4O6OqALh/81gFdPrSrA/p+DH1vo3c7oI9FcQf0daCNHWSElMuQchJSTkLCZUi4 jFg/iZonxURgGPIjQO+VL1MoZF8WB8BX0aCx8u8g9zLk/ka8C2XDgZGIgrBvjafAOGJjiFmQyOOq ndc8GaT9JGoGaz6paj5JOilJ7pZSgNEUI40BfQR7i3DEWjfW+276qVxFTXIn+eVOKQGzRJJslUb2 fo4nrNJo+T/xhFUah/IJwCPIPyqnkwlrXjdqerDudUvDgZHgU4AxQCby3wd+IL8nPQipWXI3CdID SIdirvLgWZs0VG6VEoEkuU66G3QYykaAjpT3SPeCJgP3ASm4fz/oKLlKSgVNB8agbCzo94DxQAaQ iecngj4oV0uTQB8CslD2MGg2MBl4VH5BysHOwwwL3kJbvdD6FqxvQzs70UYv2uiFpLdgfRvsbYS0 bkh5C+3uJCOeyIO9MfDOUtgVg6eegy0xeDIPT+bhiWLUfA56YigOLbWKaL04GSPhMcCK/BRgqlyF ncMvxadwb6bcLf5IrhWfAV8MugC0FHXLALvsh51WaGVetsJOq2qnB9qYl62w0wr7rNy+ODED0h6Q /eJESHmYa74KzVehuRua90Hzx+LjKP8hpOeh3tPyfnEW8kW4XwbJQ6AxQb6KNvqh0Q+N+9BOP9ro h9ar0HoVWv3Qug9a/VxjVZBGv6ppZpCWF6DFw7WU4V454OSaWPSsVqOnAb1eBU2r0cvd0LZajaAG RFAn+sDPIghe9WCWDIdv+wFBUQsrhsIKeJvSYIVNzIaWySh/DPRp5GeCz4d1s8A/IxeKc8AXgbeB zgOK8ex8tKQM/ELQRcASWL0U8fP3jogQrn0KxYhPgT4DWkBpaFsX2tHF78bAtu7bjsVoNU6YxZ3w 4Yfw4afw3SVu+Y9gyTOIDRYfZYj8fyR2o+Cf1eilbtjQCOmsd1j/+wP9/w/3yOA+u6fIv0aENUJy N3wQw2P7GWgoAC1GG5TY9qMNNnEx13jn7dBDAxsxTPJVSO3kcctmFuXOM1wXL0Wc+fmdGMSHB+33 qFGK0YiyKfJGcSro49g7/BDlT8tl8EW3lIB+YfPacKxZgTltFHSweW0c7k0Avo97D1AYfHEJ1n0M P/wEa1u4TIhMIrz5UTzQhDjI6P0Kmm3QvE+NAJs4GZRZYOVWdMLuD2FFOSyoggX+vjYsxvNL+Yjs gkU2WNQJa2xq5Njgqy74isVXJ4+i2L52Psx7oxtS3+Nty2M+gzYWlQuAUmW8w0Pd0BJzx3P5XWgr +y9B0zAKPRiF76maq7h3ldHXjXad5BGmjD4Pj4U54At5xHkw+ticZxNLUD4fWMBjw4M5wiNW8JHo CRqJzA+LYSWLyipYVoX2L0b7F9NorGR+rGR+7Jj82DH5YRW8j/mBzw29S2HZaIwwFvsxfDaeiv3w U3xuiEEsVcG6GPFfMAfM6v0YVoaJs8EXAHOAuahfCFqEOjbQeUAx+BI+Z1hhdRgsThMd4F1ABbAE WIp14U7Wi4HqXGrtixEr78VC9GAVLGUWsJWzU43QavRWJ3rrE0iuhtTqvujMRPn3UZ6F8WJSZ5Za jFA/2m3l7S7mcx1bWfzqqPPDHj8fYVred8U8EpS5SyOWQWogl4h1jdmz9p++iqdwSzLkPfDafIyw KrTVD++1IgJbg2ZTG8ZBGbw4WO3zF/7plkfD4jw+GylzQhXv76kUBktrYeFP+mblf3Q2YnOeX515 nHxUBiLqcTmbz/1Mw2yU/W+06MQiisRI6MaM8h4iqhYzSitawWSzWWw2b0Unxs0lvraWA5iVRTfK liLWwtX9T7f6xDU88TbfjdgwJxZjhl+AslI+n7+J/VB30NPdZAjsBfC0h+srggU2dfZk8kWswTFs HsX7Imv/TGJ1u3npAsyubA60g1d3JVilf6SuIawGk7IA+3Lcgc5u7OBnITcbYHdtWKGLYV2Z/H9g 2VXU+jVqfUgmzD7voV0fQ1Yn39cp619gb8dm3k/xBJt9fWwdhJUz8TzmYYzWWWg/m6Vnq7syG94P mKXKc8yD7Ln3WG208Ddk6GuPUvtjtSZvj9Jy3urA7F/AW90d1Opfc81m+NIGX9r6fDSb147h/YfZ QJyvrh1lfM1I4z0Q3rcOYAXBzNvN17wbfVqlRgHrmca+nrGrvaNXo1xZre3wpVP+JZdrUmX4g/zH 1oe31Vjws70xanvgcT/3ocBshSdLeXkhenKWvB2a2yH/HDRf5vLL4XEeObhbGxSd3dxrgRqIMdL0 tawJckOQG4PcGLSzE+3sVFcYP1thaADp2JdBoB24+ZQh/698vcw3fw5cAb4Agr5eBp0w7MWdOzlh YLZkwZYs2JL1XZwqcFuU04S97Pv1HZwmRPxvv13yX6oEnxh0wfddsKOY2lDm56cb//zvmv1vOQlQ rQTfZ+UdfPXvf8sX/zOQdgZtzoK0TZC26Y6+V/e/5ct+sG1DIG3IHUkzIboSEF0JiK4E9tVREuV6 KRQw401Ikiep3+nYl9dUabCcykcO/+aLFoSZv5aTzb1ysqQD+svJFHLTF1sJq43y1daDZz2kgfTX IP01SHyNS+Jf/CAp4Vtf+vrd8n0v4DUWKdloZ/bf9Q2OSRGDvr8FpIiQkgApTG8qpKRCigdSUiHF AynM7lRI8UCKh/S3+Q5diRZV8hMJT1/7Im987QO90Tdf/VVt4fKz39KowerN3k4/x4r9ORs1vd2Q 23nT15294NuU92X6D5Qd4F97OrEP6sY+iO3/V2Af1I09ENv/D8UeqBt7oG7sgdj76grsgdg760Ds gbqxB2LvhCuwB+rGHqgb+8dO7IO6sQ/qxj6yE/ugbuyBurEH6pbYO282f88diD0Qe2e0YQ/U3fcF 6fgtbx3HIfn4bd86RiD6qhB9VYi+Krb34/s4pQ2BvVzX39jLdfXt5UZD+o39XFfffk5pi7KnY225 sa+bctt93SOQo+zt3uj7tnSJWzUMdLj8KX9fY1IVaZfQrk+D3msv8Xe3QfwdRumzW99jLqHv/EF9 Z0XfXeJfhZLkuXi32It2zeXtGQMa+DqkvFt083eLcHjOCs9Z4Tkr+y51R9+VTEHfhS4EfRe6AH0X bvtdKNC3F9S+9fLayo7ygtq33pu+Imil4fDSaEqTvg/6CPYtkUHvOh71XWejujPdpb4De25559mI HWoMYmYLe/dhfuW71IE33szhy3gAuxSMaqID0DcEtRQtNmkYf8+55S07oIHvgRGJ3D5lx3TTOzAk pqF3POid9+At5Y068BY9jo8MJeoDrfKprSpELR9q+W5pTSF/g9NBVq3aP7WQUav0Cd+R8Hj51q7k fVgy5pZ4eZ9EsmFXw/67wwHE/vubJGK/9xrBTkfoflxa+CSNdDQGl56+hyuExlMGdtmZuMLYrxnJ SE/iMtHTNBPtz2e/VaQ5NJci6BVckdRMLVhxXqcO+PxNXIPoMB2haDqKK5bexTWYfo8rThAFzK+C VtBSvGAWzJQghAvhZBFihBgaKgwWBlMi+/9n013CUGEoJQn3CvfR3cJ2YTsNF34u/JxGCIeFwzRS eEd4h+4VfiX8ipKFk8JJuk84LZymFOFD4UO6X/it8FsaJXwsfEyjhU+FTylV+EL4gtKEPwt/oXTh S+FL+p7wtfA1jRNJFGi8qBN1NEEMEc2UKYaL4fSQGCUOoixxsBhH2WKCmECTxSQxiR4Vk8VkyhFT xPvpMXG0mEpTxHRxDD0ufg/70B+KhWIhLRNtoo2Wi8ViMa0Q54sOqhIXiUtonYiL1ovVYjXVmCvN lfScucpcRRvMa81raaN5vXk9PW9+zvwcbTJvNG+kzeZN5s30E/MW8xZ6wbzD3EBbze3mN8hj/pX5 BNWbPzCfpwbzBfPvaJf5svka/ZsZ+whqNX9t/pq85v8y95JPEiWR/JJW0tHPpFAplF6XjJKROiSz FE5vSJFSf3pTGiTF0H5psBRHb0nxiNBfSEnS3XRYugcj821pJMbDO1K6lE7/KY1DnL4vZUgT6VfS QxgPZ6RsaTKdlXKkHPqQhLDjRhZZJiGKJhE1NQN+Erw9oPuAA+B7QY8Ax1TK8H4Qfxr4APgE+IwE nxb0MnBNxVcK3Usq9ETrjilg/F4TngkLyutJWDZHob4I0EiitRdBo4F4ohVvojwKfBIwUn2G0VEc gi9OvTeKt4XZdCuYjdxOP9r2M9BlFtAwEn4WAUSJZa0ftL3f+knb6aaV3pkcPu9mjh5ve1Ovt33v cO9xDo9vGEPzCd+h5jO+Qy3jfFkcOQpaHW3VrYvanm9K9kY3pXrjm8aBPuCNb41qW8XQlOVNasrx jmwtRL35qNfkXcKRhXo5qL/SO4nD513B0LK/zdpyqC23aZ13MkcH6jJsAM+wHzzDDTvfZAjKH+TQ gmdIAc9g9f6BI1fFMrSLYZUKv+8Bjn2+LCCnL38A+QPIfwae4bIvnyOQvwYeaCaf/a9C73M3m3yV zZN8Wc2TgUjko5GfCj4PWOLbwLHCu6R5jW9Lc7uvg6MG+c3IH/ftZ2hJhd8ZitvCOOy+LRwr26I4 NrQN56htS2doOgRfAS3vts1o6WrLbTnVNqvlbFthaxz6h0HtP9CtoJ5AP6BPJoMuad4O1EH/m76O pmnos+nos3zQOaBZ3lHow7GBvmxNhDyG4SqWQfYq9PkWyGJ4F7Yw1IJn6ALPsNI7lcPnXcOxzpvH 0eGt4QjUP4W6p4KeD+RXemdz+LzbGfaGod8Z0tHvDBHgGTLAAzdiZY+WISh2jnJEgY+6XX3vCY4Z 3iscVu91Fd9wzPCJHLMQXwxWn4GjEDzDfJ/E4fAN4KhG3DE8r2KZL1lFqopxKpT8VtRhaFARiNEj vmkcN2J4Okcgfww8w40YnsMRyH+FGP4qKIbjEZtJiM2ZiMvZQbHJsN1Xi3io7cvvBL8zKL8H8bIH 8XKjfj3q7+7Lt+J+K+4fRGwzHFXQku/r5ZjTpmXom2/UeG8+j/gHWh5AHmi+gDzQkoU8gLHxLgPq fsTQfB3Pf4Pn1XmqRQRvAKaBB3C/C/e7cO8i4EP+FPKnwF9qyXk2sUVC3QG+Q02oy9A33twYawyB fCX4ytvmIzjsvnqO2rYMBozFFQwt9RifDLtV1LZNZMC9GoaWJpQBQfPYcYaWS23zW65iHPe0OVp6 2xytWiAwlgNIUZGuIkPFRBXZKqwq2BxQ3dbQ+jzoVozXs7ARaM3FPQZPWyPmhmZQP6fNbUda/W3H WveBHmg7FhRn0zhuzI3FDM0jfe69Wj7XrcRctw7zVFxrWNui1oi2Zc1/QD9d8R1q/aztg72LMEYY 1PHQ8hHmqotthQGKMW7j8HnrODZg3WDYD3v38zkrsJbt5FgHnqEDPEO9t5TjEJ5lWOl1cfi8ezh2 Y05hOIs5BdgbB78zTMQ8MPGmeUBZG2f4YjmsPgtHYE254Y8sIKd5FMbTWLTfhrgrBTJvGV+B8ea6 Zbxt9zVh7PiC8ruRr2+JRWxagMBYUH3YMh15AGPnLMbOWYyDq0BPyzqsCwxbsC4wrGxL5NjQlsJR 25bNEPBLiw+xBzR9BD8ALR3IA00XkQduXXv2NqLNjerctDWo/e+j/e/7coL8doYhKH+eI1D/NOoz NEMGQyLqMGTD/0BTMdYZuzezyQ1a6c1EPFa3NiBeL6HvAZ5vRP4q8ld5fh/i9QD6tpWhdQZimWGW iiOI32OI4/dBT7cdC7LrAkfArg9gE0Mg/wl4oGUY5p9k3/5nJ/qyGFod/sjWRf5o6KphCPRT4H7z CX988xl/Uss4/0jsoT7yj2qr9o9te96f6V3BMQn5ybC/A/YD/qnI5yGvxjf7uxf8F6jEf3tq4L86 DdWl69JJ0o3TTaBw/tvQ/vqp+icoVj9d/xRZ+K9CE/mvM+/mv61M4b+YTOe/hszkv4N8kP2iVvxc vAK5CZpEEjX3aEaRXpOmGUsRmn/VXKMBuuG6ZKrWZeon0Eb9A/qHhI36fP084QV9ib5EeEW/QF8q NOhd+gphpzHUGCrsNrYZ9wmvmQSTXWhhv8EUB7PfXYr8b4Ww/wcSpau/SbsfunXSVmkbkVQrvUSi dEI6ibfv09KvSS+dlc4pv+Bhv35Vn5yvPjmKeUMzBjaSZr2mBlZ/rrlKWt1k3aNk0Kfqx1CYPgP2 SrD3BxTBdURyHQOkOullioJF71A01xfL9cVxffGqPkGshUf63hvq3UAlCbsOgq4E1oE/CroB2KJS htogvh7YDTQBPtQ/DtoB7FdxSKXvqugiqtyigPH1p/DMiaB8FwmOkQrddQb0LNHSVtCPALw/uFah /Dz4S8BV9RlGeziEXRfUez28LcymW8Fs5HY2om2NoOV4n2g8QULjGeA8vPMAWWk6zUY/uGkFVdMW qqNG8uHt+gh10Rn6hC7RdbgwTBggDBPGCZMEqzBTKBTswhLSuKJdJle8K9KV5FxGorPSuc650rkB nMO5z7nI6Qdnc7qca5xLwOU7d6NGPbhc5yznfGcDuMnOzc7ZzjpwDzhznNOdteDSncucVucicCOd Y1+TnGvAWZzFr2mdc8BFOROdKa8ROJMzz5m0+xtww5ySM9Y5AFycc6IzwpkBLtrxlVPvZPUGOJMd 3ziHgYtwXHRcdVziz0Y7PnNGkug46hzmOF92Adx+53DHKWciaWFznrPUORPWzXZOdTSiZLYzEqXR KI13usoaUft5h8fR6EAbHGscxx11jqOkcYY5eusinVpnlMOO8lLHkrowB0a5Y46jqY4cu8HNcBTu uO6YD26qY/uOS47N/w/nAAP/5Trx36yzX40/S6H6Ffq1ZOa/4R7If4E9iP/GOkbaJ/07xZIg5AnH MF5MdJEwDndMA6YD+QDeb3cUA3aVMriDeMTfDoyjHesAjJUdiPEdtSrqVbpbBcbPYrsCxu/wBfEB YFwtqgHFeNqBcVU+CxRjakeXep/RUyreVel0Vfct2LUT2ENUinf/Xa001j7JPhmYunCOPW9hsX2m fbbdZi+1TwVcwBL7Clxr7DW4Ntu32+vsO+17UNpqb0fJHn6XXTX2N0tj7TULdy9sWuhb2FE6zJPh meHJ9Vg92Z6Ju1J2pe/K2DUR/dAf/YtRK14T/0yi+Bf0tZb3tZ73dQjvaxP6ejyZdRP6ejwCPf5D GqR/Av0+mPd7nH6mfibFo9+bKcHYit5PQu9/Q/cYexEDIxEDP6JkxMARSv0naRVoBtXz+HmA/T2G esRNPeKmHvFRj/6df7Rv3lXm3GIFr6Ls1UoylQ0vS5k/EWl6Wfr8andS7dHa46+2vtqO1hjFP4l/ Qmuui9cxm2foMML1uf/N3rcAxXVcifa9QsMMAxhjjFkyHhGMEMYyIQSPCasoLChoMiBCWLh3ZsBj mBmwrCUYa2WiUBizMAzzZ34QohAVT48lWhVRKJ6WIoQosoL1FJVKS2RFT0+rqFiiVVhZRekprKIl ivJO9713uDMCS8nmJa9qU12n+9zT3adPnz59+sNwr6QKbYK5oENRklqYEZvl35F/B0nkv5H/BkXH 1cGMkMZ/ADMihswI+R+IC5W48owWVq9Y6iRqRqgHbK8HbPFAEgH6nVJ4BlvsAV/eA368B/x4D/jo HhiLAzA3emCm9zwEvIsDSxRPh3KWmBBQzmpEv7nIwTvlAFVAT4BUu0bfCN4xAJifoBz4oXdaAdrI M5ELgyWZlw3LokD0395D6M2OsLpcuXQox0B9Lg9Zsn53gDUO8w6BwNeSg2h/AcDOUJ+xXkPtW2DH ceAAAfJ8YO+GQPKhHUjp6902+1Gvv9tjP+4d6g7aT3gPdx+yz3hHu0fsp7zHusfsZ7wTQD8P9KD9 onfqjSX7Fe9s97j9uvd096T9hvds97T9lvdC90n7He+l7jn7Pe9VKDkD5cfsD0jdGe9Ct8dBQ8lz Dqn3JuDx0Na8IwnKXHakem93X3Okee92Bx2Z3imIkyBedGz33u9ecuR5H3YvOwp8UXtjHTt9Md0r jl2+hO5Vh8aX3IOg3dkeiaPSp+iJdTC+9J5ER50vqyfFYfTl9Cgde335PCUDHNftnmzHAaBIII6B uB1qSRxdEOc6rL7CHpXD5Svq2eHw+0qBfxfwlziGgGex47D3ao/aMeor76lwHPNV9VQ7JnzaHr1j yuvnYqy3zvieeqyxnibHLJRvdpz2Hu7Z7zgL8VHHQ+/DsPi4MyoUH8Ux6Z2554QzBtoVxzMkPuVM gF6cciaTOMG3r+cMoZx3KqBHFyGOCYuvONNJnAXxCWcO4bYWz5D4ujPf19pz0HHBZwCdY2lvOAt9 bT0SzKFX68r1S3o6HZegjxbSU65HD5xVvu6eDKfWZ+u55SwCbTRDH6egJC5T77gKGuBwh2MBcI7i ddyEkeLiQR6/DfGw4y7wFMdHHPfDYwvtNPiyOBvjRtMidZq9Ny3xzn2+IkuSs9U78cZlZ5tPy9kt 369hqDvVc4dIeM9Z+tZ9oJf7Oiypzg6fB/TQ7VNY0pw2sGSwSV8Qj37HdM+w0wMtZmJLs2wneJ4z 6IvirM5SgPtl2YlHEM+adx9g+3x32LILJB/tXnEeAssMzR3fIWyleyWcBiwaPI6WStwLC+McwT1y juEeOcfXeuechN6lYvux1OGRtRgJvpeM8jDRPxlfS4tz2nvWstN50ldoOUDwdoJ3Ec1YsWbwLPON EHseAy3NeYcsLuc5X6nFT7Q6RGzgCLFPYhWWw6DJ+5ZMrEnLKNaq5RjBJ5zzvnHLlPOyb9Iy67zm m7acJno4i/VguYC1BPoPglSXiMauEnyBjP5x5yK0Uk/wo8SSHWSOHCfa2O7sIK3DWPQ0E3wG49jb dMZbbjqXgD7sXPZOWW47V3zprcvO1bduWu46y1sVvBUl4llguU9wbkZwdpWIZwr2VJ13ic2ctDx0 Ie/p3iiXxJeDvZZvDvuHzsreGFdsqwLr33eOK4k9mG8e+4rOSs6bEb9xuTfBcdp3rTeZzC8yFr0K jGPPBtywD1nsTcf6783C+u/NcSX6lnrzXSm+ZTJHDnPzrrdQhBet6R/7w8544nlWektdSu/d3nJX BrS+ZsmrvVWubD/q24lz+3bh3D4NwSsJzhC8TlzLc9JX1R10qaAViWsHSDvvugded9X1AFoEGw6c xTYcuMDPdOKdOOvtMzo0gUt9ex1XA1d5X8TN6BkypkTPfS2Cnt+9jrUXWOg7YJ8J3MQ+NnCbn9HE YnHvAje53kFb90O9Bm8fuMv7VZHMvFfhPAyRzaIhntO7Nu628jX+tirM06bFPFsXXcX+WGusO89/ oue6S+1r7TW4KvyJveavjPlTeve5qoFidun9KXxuq6ve19bb5mryK3s7XM3+jNZl137vaG+366A/ G0p2kloWKGlzOfy5rUtkZD0ur1/Vc8816N/RG3QN+4t7D7mO+NW9I66j/oqeRNdxX1bvmOuEvxrk mXnrZu+461SronfSdcav7512nffX9550XfQ3QVtH/M29c64rvg5O8t5zruv+/b3zrhv+g72XXbf8 nVD3jq8D+zG/xWZwSINL3GrVe81N+x29i26p39u75ErxD4JsnSDbsjvet4xx/3DvihvW2dZFdypw XnWn+Y9YkTvTf5RbYbm1zCpxb/cf5+Leff31vlZrRX+T/wSWKrhsM/c3B1ds+/r3B1dtrf0HB5Ct rb9zQGLr6LcMxNq6+x0DiTZbv3cgxeYButIW7B8cyODWaNuh/uGBbNtI/xFfG7eL4NZr25izYyAX xgvP/XrPovesbdyz5MvHuwWwB2I/MFNOA37FqQjctk06tgfoNy47JgIa2zSexbaT/UcHVLa5/uMg 1bn+EwM7ME9iD8DTNu9I8yfaLvfPDBSDDYc8Krc22a4RW+LWKW5FJj7KtojtHMovhGxe5E/ENm9b WvMAYs9sW8be2LZCvDHx0rZVjPOe9ijxtEbRrBd5aTvqPzWgtkv6zwxUiP2ePbb//EC1PbH/4oC+ d7z/iq8Vj91APR67gSbYgeDZcdXxcKAZz9xgEb/uNJPZMQNSJYtnkzXRXeA/YU1x7/TPQLzLP0Os q5Wnk7jnulvj67Aq3ZVAJ/PImuFm/CprtrvOf4qPc91G/xmryr3Xf966w93i30HKK7jxtRa7D/gv WtXudv8Va4W7C2wpxm31dfSO430aiTus1W6XX2/Vu/3eWWu9ewjmxaT7cFg8aG1yj/qvW5vdx/w3 SHwL7+UgJj6Zi6373RP+O71z7imQ9qB71n/P2uk+7X9gtbjPBmirw90SkFq97gsQO9yXAvHWQffV QFIoXgikWofdNwNp1iPu24FMiO8GMvH8Cmy3HnXfD+Tx8XH3w0ABj5/wRPn13Kj1xnhioF21JyGw 0zrjSQ7ssp7yKFoV1jOe9LduWs97sgC/6MmB3WM1tl4SV4pwjfWKJ781CuJCEhfhUfCUBhhuF229 7ikP1PF6vuGpChjfzvZoA3uttzyGQAtotR00ecdjDsChybMPcIEPju95WgPt1geetkAX4B0Bax/t 6Q64+qQeW8DfF+/xBIb6kjzBwOG+VM+hwGhfmmckcKwv0zMWmOjb7hkPTOE1wjdJ1oj7fe0e2EXA ulngS+jrsh8PkJ154BI+OwSjMB6M6bPivVCfi+zSJ+0znZf6/I5dQbIvCibjfVRQ0TcEeDrZU13u Owx4FtTdFcwh1pvfN+rQBAvFlmwZ9ZzzTvQd88x7Z3sLPZfBqq/wewaYI30TeI7gswn4CjgFBEt5 +pTnGkeHnTmml2M8WEVOCgrx3qBvFvufvtPE/8DeAGQ+C2eHFYIvYDyoxTuEoIFf4y54loOGvkue lcACoZsxPbiP4K0Eb+u76ln1Xupb6Efe2303CX4b4/iUFOzou+toCXb33ScnBbKHxzuNTiu256AN 40EPwRUED3J2bknql3gnei72x8LedZTgVzDe1479TN9D7GfwbqTzEt6NBA8RfIHgI7ao/kS8M+lP gZ0h7HiDY9jCg+O2mH6l96YtoT8D9tJdBE/GOC4fHMPlg+N97fi8ZlP0Z8PJCPxVcBJbfqeL4FEY D06L/RhZ6+9ya/3armavBOPBKowHT9rS+3PhRHalXwVjBGfAziR82gqW2rLW9jD4VBicw+cv0Exz /w7vlC2nvxjmEYfn96uD58Cz4T3DLbxnsBWu7WCxhwzO4/kVvEzwaxh/Y5FYwqKtqL/CV9pX2V8N +r9I9hhkFbCV9uv9aDBpMG0w1V5vLR64gWM4S17vvw6+a7L/hn+wd67/lq/DntJ/Z2B/X55nMjDb V+CZDpy2K/vvDRy0Z/Q/GOjstnnpAYs92ysdcLwx740P3ObPyB5v0oAXa35gkHjvYXuuN3XgCHfC 5U4Z/Kk2/MTaLpxS7SpvWvhZlVvBuf2DfYc3c+Covdi73Z9rV3vzBo5zftVCewtg/SJ8rGrvzsBO e4V318AJMmdzuJmI2x2Y4U/T+Ox8mbNkLMnAKd7fhiQZOCP2kOSkrMBn5IHznE/DHmPgIne+5vwS nsvBk3jtGLjCxRyFa8Ve7dgZYOx6r2bgOmcheNUASpO3cuAWfztBbgzszfajA3e42wn7fi8DNkbu IrhTv/2gt27gnr3Ta4QWyZ0DpzfuVoHbZ9qHvV2DUvGJkh8d7r4Cag08sFu8e98dtju8Le9m2L3e A4E6+6C3fZDG9tAxht/LR96kiURv0qTJmzSjpMVSLdpM3p6pIG/P/CR5e2aGtE3agT4lfU/qRCry ZswS8mbMSvmL8lxULf83+UeojrwP9HXy9k8TtPEZlIE+hxDahV5DqciI/g7lIzuEauRFPlSDRtB/ Qywag6BD42gC6dH30Ax6HZ1BP0UNaAH9K3ob/QLdRl9F99Bv0bsUTWWjPspBudAENUj9FP0P6mfU DfTLqH1RX0G/jhqN+jb6bdRs1PvUpqjzUR9SsqilqI+op6Pubd5EPbs5Y/NW6gWJQzJLbZWckrxP aSU/kvyI0kvOSn5C1Ur+V7SEaoyWRT9HDUQ/H62kRqM/Gf0eNSZ7T2alN8vsMj8dJ/u67BD9nOxb snH6E7Lvys7RL8k+lF2ld8t+JrtHf0n265gk+k38tzW6Rx4vf4q2yBPlz9FW+XX5L2hX7Fux36IH Y1fiKPqDuNS4VPrDOEVcOn0p7sW4F+l/jtset52+9lT8U/H0zxAF2tlHblyV+P1kry3xsAywglJf W3pt+bWV11YNyCAxxBoSDSkGpSHDkG3INagMOwzFBrWhwlBt0BvqDU2GZsN+KKPCb48kI4ykJdIS REs1Ug3C30VIJL9KRHQBXYAoupAuRDT9efrzaBNdTJfg/+uj1UhC76H3oGi6hq5BUpql9UhGv06/ juJoI21C8eTXign0V+ivoKfpd+h3gOdX6Xb0DPnN4nOg9QyUIvmJ5CfoL6BPV9B10jP8V0Kkq0BG XafOonPovLpB3bDuiO6o7rjuhG5Gd0p3RnceqBd1V3TXdTd0t3R3dPd0D/S0XqqP11Xok/Sp+jRd tT5Tv12fp9PrC/Q79bv0Gn2lrl7P6Ov0Rv1efYuuSX9A367v0jXrrboKUajmg54P9aHQxAW9S7df 79cd1A8BzOoP60f1x/QT+in9af1Z/QX9Xf0l/VVoaQFK3tTjN9dR0X8P2kwOs3b8RvF81Aq2W4i+ BpZfTKy9DKx8Au0BO/8eqgAr/yn6EroFoZLo6MvRL0RvRVXR26K3oZrol6JfQkz0y9E5iI3Ojc5F umhVtArpowujC1Ft9I7oHaguene0Gr0WXRtdh16PNkQbYNZQ5K99WMvp+A2djB9giIfDAKNoBxNk DjEjzBgzzkwy08xJZo45x8wzl5lrzCLQl5hlZoVZZcZZxErYWGaMTQQ8hVWyGWw2m8uq2B1sMatm K9hqVs/Ws01sM7ufPch2shbWwXrZQXaYPcIeZY+z59kzQDsONU+wM+wp/K5D6dvSd8h7QWPCtPU1 CPnonyC8gn4OQQVz/1/Rq2gJQkF0ZXQl+mx0TXQNKow2R5vRXyIq9n4c+eoFysbvRK0HT1YPfsxU CWkXgBVRVecA5jZ9pr7FVFB/wLSTAMbbTbvqu0wagmOwmirrXSYmlOc31YXyhHK4LsZxvpA3ZDKG cEw/bNpbP2pqCUsxb4xjOGY6QEDAJ0ztoTwBBFmEchgwfwHHPKfgeYqXCbcrPGPA+U8KgjxiuZ4U BB1hGQSaWA4hX5Af02Z5WXGK4TT0VQzi+mLAsuF+4vQsjAHWzyyvb6GNKT7FYyR+xvrs4utgWXGd C3wqyCbwEXR7ydQVNqazolSQ5arJStIFkyvUVmSK28HtC6kgu9AXzO+myf9IvdmIdm+bhurvmg7X 3zeNhuS8ENGX9WQV+iPmLdbXQ9Ezlg/LJKSnI54FmxTbotAPntYQZTrWEGOaCBt3nB7YoP/rySR+ FuaXQIc6xmqOFpmK6zYkmKYaDOaoBrM5JmxcH5Ma9U+WH1YuUt9PkJL6wnOkniN18XHpw/Bn3O8N 05a1VMzHWM/p6XHpx8ol7sd69sbPtYZk02yDwnSa4Hwa8sv8HGxIN50NlckyXcC20pBjuiT21w35 pqsNhaYForOWNdtoKDLdbCg13RbbX0O56W5Dlel+g9b0MOQfeH/QsM+cQOav2L/g9lrNyaRum1kR snOQr6HDnI6B6O2gebWh25xF8M5GZLQ0SrC9Gh2NsUZvY6JxsDHFONyoxM/Ez0N9YzP4RGENWm8s I8fmCLTF+2nj0bU2QvnHGzOMJxqzHxmLjWzzdMTcfpy/iszndWScacw1nmpUCXJj3RrPNO4Q6yok Q/sGfgjr02bOwRBa1wSfLOR7zPkNQXMhgUPmooYRc6l4PW0YM5eHrbeidbZh3FwVub41TJq1ZCwE EPhMmw0kPWk2N8yZ9zWcM7eSdjaAhnlzGwbiywTaZXNHaA7za2nDNXN3w6LZJvZpDUtmD+nbsjm4 4bqMbW/FfAj3F/exYdU8IvA0IvOYWF9GiXncGGueNCaap40p5pNGpXnOmGE+Z8w2zxtzzZeNKvM1 4w7zorHYvBS2dghzT5wKa0mkH94ojbSv9ohUoGO/f3ode9poLYpck6CusYm31/XKidZTUk40l4m9 4nkH4y2kZG+C08f182N8LUnP8nsNIRXmzYGIeRS5/gn7EXg27g9PQ3ubY4/2I3K9fWJ5+fzQWhm5 rm60/4gcT35uhdrD9gf67pJ0xT6yt8XtnW8sNqrNy8YK84rxYqPaeKWxImzPiPliwH3GvK43Vofm MNaXeH8szD9hH8LLY7zRqMfrhPFWY31o3mP6ncYmPP/E9Y33GptD8kXyBr7GB4378bOJXptfYv8k +KLQ3hlSk7TxoJBvim/sFPy7KanREtIbL7MptdERth/i9Wja3jgcNsbYPoQ1EddLa/SaMhsHMY5P 8lK3tB8h+afJl11uy28j/CXDbX/cm5bNm9BvyY3K6+RGpUFySvIjKkjuUobIXcoRcpdykdyl/Au5 S/m57L2YJLqY3JBcITck/5vckPwzuSH5F3JD8hG+IdmUim9INmXhG5JNL+Ibkk25+IZk06fxDckm /Ju0UXRs7R5BM4XUmguaS5qrmgXNTc1tzd0v1mvuax6WRZXFlCWUJWumyhQA6WVZZTma02X5ZYVf rP9ifVlRWWlZeVlVmbbMUGYu21fWWtZW1lHWXWYr85QFNbNlh8pGysbKxssmNWfLpstOls2VndPs 1MyScBbCFAmnScBPswQwDoDvBKQ6/Pu0iFNuO4zLu+g9ON8eh/BZcuItRD9BF+FMewnC56gfU+fQ zqj5qA9REb6/gpr4N3iGtf6WFKN0oafQzwVIFwCD/mIK6TP0ukwBPVZwvcZ9hv4qoMdFZUVQ5y6U UxAZzSDjc+Q/exHKhEChLAg0nKqz8Xc5IUShHPQptJl8kzEaTucFSAYy7UJxqBRCPFJDeAppICSg cghPowr0JZD0y6gKJYHlaVEy+fpcKmqD8AnUCUGBuiA8j85DUELfP0RbqHgqHn2S/Kq1U9RX86a8 msWapZrlmpWa1WIrgxhJ8ULxAhPLJDIpNYuMEmgZTHaJh8lllIyK2QG0YkbNVDDVjL7EU2IrGWPq a5Y0SqapZolpZvbXLJWMMweZTsbCOBgvoyopYgZLSplh5gi0s8gcrVnFXCFUrIXiTOBDgkapUZZ0 MycwFyFAq0I4DvVmSsbZXYSXkklhzgPnYnhaJbCKZSfyK9cCyJZY0g09cIDcR2pWmFPQg2Ho1xno bT2UvchcqVlm9BhKPMC3grnO3KhZAXyFucXcqVktsYE2mplEzEmjJPoCYJQgWzb0E4Bwv8c8AC15 iZ4wQGsYSsqZepbGfIVWMEcBsAwYWCmkEuAKULygUYJczThl49kkwJuYWDaVTSsJFsN4sZkszW4n 7RMZ2DzSfm7xhVDbAGwBu5PZwQyS3nYRTACgcLUZFXC7SWR7BNajszfZ2+xdsfxiwHlE5vvsQ22U NiYkoQjWo2OaNkGbLJZeAEzXJuBR5gDLgXUjyM9qdNVMdc0qW8lUE2DYOtDwCmtk9zIVbAt7gG1n uxjEWlkX68eWje2UHWIPA6dORsmOssc0TcxBdgLrEPhMsbNYk+xp9ix7gdVAqzCG7CX2Kr6hZBf0 s/wt5SX9Vf0Cvp/U39Xf1z+sjRJGErfAFtTGYKhNqE1mmrgaOK9WUZvO2Q+vUV5z3IiDfYXGlLOr kCbAtmqzanOwddTm1xYyp0pKa4swB/a2tpXUwPrJrVnV6ZlqctPaXOLR7Wf0uoO6TnwLzO7SOfBN MNuiq9YN1izphqHFCWixWaNcuxkG+indmZJx3Xn+bpi/HWYswv0wu4vdpY/XJ2ly9amMSp/G3RHr tzMO/pZ4l+6eHsZEd4VR6iuF22LdoL6luh3ncHfGeqveVVKu9+uH9IdL8sH3YGtbYqq1CvauNl2b pc0pzsQzUJuvLdQWaUu15dpC9pK2StCXVqs1aM3afbj3xVbwQUiYPdo2YRZpO7TdWpvWQ/SKRz1W G9Qe0o5ox7TjBCa109qTbB54kf0CcGMD1jinPaed116OtFTwGgcxcOPDPsSgvaZdxLajXdIu41TA sS/QrmhXdUgn0cXqErH8uhSdEqehcQX/qMvQZeNZqcvVRtUslpRiIKMJdqdT6XboinVq7Qj4lUGg VegqWrXY29aW1pbXVtVq8d15raHWDJIv79KDn8qt3VfbWtvGVIN3HqvtgH4fBFk5b3wELLC71lbr AQ5e5mBtUJ9We6h2pBZ8OMTjtZO100A9WTtXe652vvYy2HdB7bXaxdql2uXalRJb7WodqpPUxRan 1SVi/4d9LrZdpqkupU5JdAJy1+Vy3hL0lA2+1FuXUZdN1sJGWPcy/yvso6C3e1EruT3H3x9CJQhR AEnFD4oflNAQ8J+J4iEkQUiFkAYhE8J2CHkQCiDsLDlQsguCBkIlBAZCHQQjhL0QWkpaoB1a+rq0 Hv8HGfoC2g16/SIqg33FHtgdSNBfg/bkoOfX0DOIir0de49IRP7qVQq7E7UL0nRI/Zs+U5qstpYq eMB4OkAWj2PIAcgX5RWK8oRyCh5PF+UViXBMLwUoj0hzeBxDFQ8CrhXlCSDIUiWiJYvwUlGbigh5 kvn8J4WqCIiU5eNA0JEiQk4BhHwxPV2UpvN9FUPyBlDFl6/ixyBfpG9xG+V8vvg5R1RHwdcRUqFc aURqiBhTcSrIYubTfevIIKQKvn0hFcsu8Gldp15ku20AHQDdIjkj+7KerOvpZ6M0h5dpo1SwSbEt pkfQbACej9FDZP8fJ5N4fglzRqBFpuK6QYBFgKUNxvcPmW6k9ydNI/X8pOO1Xhp8wlRcT9DT49KP a1fcj43yMX4IYITHhVTwy4JOx0R547yeJtXh/noa4KR6zWcItjEHcC6i7XmAywDX1Gv+QbDDZTU3 f8X+BacrfN1Vddh83I04wLTdVwAkPH4d4Iaa2OLuWwB3AO4BPOCeiZ/H/StUr61BTzCmpK1STi5x G0K+mgaQrqPrjWzzcbYW6a/W80tQTx0PkCSig27VqeG6ekSGSF5Yn7EchNY1wU6E/ESAFB6UABnq sPV0d7aornhtwvrKVT+yvu1W8WMhgMBnB58WA6gBKtSPrk0i2F3NAbEhgaYX6ZVfS3fXAzRFjGkz 37f9oj5HApTdfZDrL+7j7k4RT0u4vnY7ALwAgwDDAEcAjgIcBzgBMANwCuCMaEyENXu9dL2x2ih9 Uh+XtYE9PS59Ut8onrvrpYX8eEem/xlfK/gScRo5fzZa/x+XPq4/v6+8H7dmPsm4lke0z/umvRXq R/e22D+lgd2dB7gIeCbAdr6uQtROOt9n4KXOU6/N4Rx1+P5YmH/CPoSXR12gJuuEeqd6bd5j+i5u /onrqzUi+SJ5A191pYgmzC+RfxJ8UWjvjGVm1vLVdeqQf1cbRXrjZVbvjbATwY+7IsY4S702F3G9 FoADHI5/BUW+Jo7+q93bU1789WIUS8WjIoRU4wCTCL0Sz4FqGtIkSE8CzAGcA5gHuAxwDfJSIV3k YYmn43LLa7A9iStHyq7wZXHeKkKvIo7+qgQgFiDx94AUjo8AIX5KTv5XM3jeGLLDy0bUK1LlqPJV haoiVamqXFWl0qoMEMz5d+B5n2ofpK1AayOhQ9Wtsqk8qqCqDeiHVCOqMdX4Kw9fefjyCo5xymGq SRJPq06+tP+l/ao5lRm4mFXnVPOq+RzQmCjM4d9/PvobYGmxtApFSbVSLXpW2i7tQMnS96R/h/5C 2iPtQQppn9SOnie//k0jv/59Wf6i/CX0aXmuPBflyz+Sf4Reif1R7BxSxZ6JPYMK4hLinkWfJV++ //wfvT2KSqS4X9LOoJdA5y0IZcdw8ApI8Uo7QNcabSN4xQrgeoJyfoAhgMPcc74yIn/08Tx4eCn/ wSt0RJC+tEaLF9NfSRLwlx6tFRbwm0nIb7yRtFrKIor8xnsz+Y13DPmNd5y0Tfo1lCLtlnaD7i1S K+jeIXWiNPl2+adQuvzf5LdQZuwHsR+grLjkuGT0YlxKXArK/n/Gl0LH0Ym1vwblRqE9eZqsYi7k 7QWoDD0xeXU8RkpwOXlGIV+oAXFLXkuIosEhPF/gJ/DCnAQ+PAfMu1OoJ7SM7xDpQdCFhB6hfwDO /X36A6Sk/yd9E70g+arkq6gE+1C0S/49+Sn0hdDbknL4tyV9GmpGQU2wEnqMnkGb6VngkkpKK3je FEomOK+PbQWI2pZH8r6FY+BOoQK0U1QiGSVmJW5r26bY1pbbDXE6hFIIyduytuVsy99WSEIR4TGE f5VLf5v+NkjwHfo7QPku/V1E05P0JNpE/yP9jyDf90GmzdCns0hKehMD8v0AyeU/BCkTYMbZqLPk Fq8KPY1QJsyG3EKAoo+B0g3zqEwX2rOtnguZVZlVAr7t/Lbz5Ll6W3Vma2YrfuZzcnGcK8mVZE5n TufG5sbicvg5VFccoD7h3ZbZtu1MZlAccN3I8ricOETm56bkpohlzFXmKgWcl47IlzmN+5ObAVJV f5w8on5x7WO5EnMTMz2Znm1noIQHl+NCZjfQZrbNQNpNxvGb9DcRkrwjeQdRMr3sNUTLXpfVI4nM LDMjqaxJ9gaSyd6UvYnksrdkb6FY2X7Z36I4WZvsq+ipJ7Zhihqn7pPxboPdC8o4+uSQA141B7xq zs51wMrB1glIu/jUiqicYwhVWdGejNGt5Thk7MyJ2jrJ4TlZOVkv38+J2VqU0ZVRB5RpCAooM7RV kTGUMfTy3Zfv4noZGigVlROFnzkePK+9fDoKHCZwmmHcOgm8RteAtJAPbeVjvjhw5cJhaznmTNqC /JxCXsYiLOPWaSxjSL6RNflweZArAeoWCTKtJw/mQehDQj7IZnz5YUZ7RntODpRox+UgJAPektG+ 1bB1DNLTeJRoNw0+mv46/XUko79BfwPFyHQyHViAQWYACzDJTGAB+2QtKF72tuxt9Iz8tHwOJcl/ Kf8lek7+7/J/RynyX8l/hb+a8jv4uEqAJoAW4uXyyP+d6NEOeKriPV8eKQc7AuK5SkXl8kjN7FA5 GvwQaZe0oiStbMF/ZaC/CXZOg11jS0fE0qOIpUuIpUcTS5cRS48hli4HS29DcYQj7gMifdhM+rCV tF2JtERqru3PEBnxbzH0ADtCNBplEclLw8phqbFfTuJpaxKuJ/8fUu41fY+TtvMJjdM2hU6JaBd4 fYvLzRBtU6iVp20kr/w/ZUnYhlKwDZE6iNShSB2a1NlE6khJaRn+29GjrRF+csIp/mPHcD/0xMaP zSuENkN+S3MgjJZFtFEfRvMTbZSHaE8mx59eW+vpgkJT6DzZFaTi9/mnGREIRmDPFsUWbZo+DWHY kgAxxlFavfJumn6LAmhcflNa05aVtHqgrUDaRMqgtGYS70/bj6kkKEgI58jz43OAk5gPUOoBENca lOZaBk64L7IGWQP0uVUGFil7R4Zn0BOvTWiSjCD/N05lLIE9W2xbPFuCWw5BPLJlbMs4hEmAaaDZ tpzcMgfUk5B7bsv8lssA17YsAt22ZYmEEVI+SMqKQzhHgd9JeLYBPk/4jBN8BEpNw/MS8F0GyjL0 FMeradjOaJlRduD37eHz2QT2KAuVhc9PKYsgLVWWQ1ykrALQEorheeb5LqUBQhEEITVDzj4SSskz hC0ZSjMGzA2CVsRxjZ+B8OI4CXzalFHKji3ZwKsQnlsJ4BgC6WGjbO/vsH7Q4J9gblI7+Xmowl+k oPKoAtxzKjuMmkWlo1GgJoVREykJ8sDzQzEVPaBodBCel8KoN9FdZITni2HUebQIfoBCsyIq9iMq eBoL0Z7EPyTSR+j/DiX+nh6DFeEf6H+AHfU4PQ41J+gJ0Mk0PY2iQSfvIyk9B5qR0f9Ez4P/uEh/ iOLon9I/RU/RV+grKIG+Sl9FT9ML9ALw/Dn9c/AZM/IZ8Bk/gN34s7Ab/yHYhGBPeG/vI7GbxN8g sZ/EQRIP4B5R2yl8R1PA9+hVQiunYN2gMsJoUTAaFJUQRsugcuHpQRgtnVKINMzRkqhUeLokpqEZ GCG8Nolp92Ek8Nokpt1At+BpKIzWiS7DkyWMNoFOkzVMTBuEkySF6sJoregQPKnDaC4E+8zQu285 WhJZRdJCtDUd+ogl45FGxDtTxDvTxDtvAu/cDKt5C/joaFxatk+k9wChGElsEI2Emx8PTP8b0jo+ 8dEoHdYorv0CJJwFKTiXceVw3AzaPYg2Qx8zoE9/hj8e4Jm/nc6FeZ1H5wGeT+vAKvDXWrbHK+I1 6GUYmQQYmeI/uaT/vwCNosj3eRD1f6hfgY/+D/opFBP36/hPoE8iOkqKNoOh/6ll/DP8Gf4Mfzqg 0R7E/W3MiPbCuQX/PeyTsCP4LnqBfClsGzoD+4gstADhVdihLcLKeAPCZ9EvIBSSr4b9JfoIwg50 D8LnYE/xH3Di/TWEIvQbCH9FvilWTL4pVkJJYBeyi5JSMvQFSk7J0W7ylTE1+crYF6mnqaeRhnqG egaVUc9Sz6Jy6jnqObSHfH2sgnx97EvU89TzqJJ8g+zL5BtkVdQL1Avor6mt1FZUTW2jtqEa6kXq RcRQDsqBWPJtMi01RA0hHXWIOoT01DA1jGqpw9RhVEeNUCPoNeoIdQQZqFFqFL1OjVFjqJ46Sh1F DdQx6hgyUuPUODJRx6njyExNUBOokZqkJlETdYI6gd6gpqgptJd8++xN6vvU99E+6gfUD9DfUD+k foiaqfep99FXyDfRWqgPqA/QW+TLaK3Uj6kfo7ep/8vc2cDpVOb//zrnOufc90wzQ5LQ5GHY8jB5 6mGRSoUkVMLOFvIcGsUoJLXlZyVk/WOtrKxky6JhJau2LU0aepLVhCR5WjQ0i1SS7vv3/b7PafJw /9r29///f/+/+3V/ztfn+l7f63t9r4dzneucOfc7zjumwHnPec+McN533jf38otp9/GLaSP5xbRR zhZnixntbHW2mvv59bQx/HraA/x62lh+Pe3BzHaZ7cxDmWMyj5tfle94V41WMi103RJ01PuhWXdm 6VshTtdoqRpnPf0jGlegMf9HNFqhseBHNK5Ujax9p2no3k316GvYKTnT11N1rk7p7ak6rVP6e6rO NSk9PlXn2hQ+60q1Bpphva47KTX0/kydNqfqiPdn6rQ9TWd+Cp12p+ksSKFz/ak64r3WS69TdIWb zZ0NIyM/VaRP17oBCyP/hVYHtEb9C60b0br/X2jpFaBT4ZzTIl5FrgtC3SpodUoZ89O1Op8WiZEp tW46TWtUSq2bT9O6P6XWLadqST30yrZKuV7YQl1SeH+m1q0pvD9Tq2sK78/U6pbC+zO1uqfwXsev I/3LyrcG/cyYX6TsFWfq5aXsF2fq/TJlzzhT77aUfaOqXLU57N1VJY8xt6ds9zP1eqRs+TP1eqZs +zP1eqVs/arlmk6kd0fKlj1Tr3fKtj1Tr0/K1j1Tr28K/zz0vtcM+0G/FP6l0uufwr9UegNS+JdK b+AZ/jkmXXT7//BbNOH/k3NO+r9vqgl+f7V+yl5d2hZj0ieYTml75XMQnJW2LK1EPnNFXpR2RCTl jqUlRE6ke3JMCJNIT08rSa+oH0nVfEfSjqRH//j/6Ra/t7dXbJVEliQVbbWwKN0Ta+npVbBQkp4t Uk46u0fRPYufuhu5y6lCDfWvQk1cahjfLt898i2N5EPy/So6ngjlNDf6xjl2ipfIZys4IT43XiSf KSLPiu8QSbm98YMiH4wfke9BYQ7Gj0lKgs8E8u2Qz7Hoo/8vSasiln6wOCXSKsFWaCm0U4KFWcIk 4sfSPCwUpaWneWkV07z/5n2an3onNcvpSvQKpNeYeL4xsV4/fPX/8Vanfr/nKy456bs8+q6S76vy XSPft0Wv4IdvxaPk7RQbIp9hsTzBDbH+csyL9Yo1kk89uE2xsbGR8mkUmxjbFhsn312x/WjpJzvS rBebGn2GRJ9hYDYWv7c3RGwNERsT5aupU7EwBNt58r/ZsTK42fI5Gpv9f+6eyX8n9sFDxlSo+8M3 2Cjf0ad+4a+V75zoO1++C6OvyoXyXRHKFRqc9H0IvpNfJp+j/ja/LOjq75fjNn+Xv1w+S+BuC4x/ XD7Lg4ygdxDId2CQj5Z+5kWaS4JK4QdrocWycou7RFatMrG1TWxkBEFsihwrYaFMbQtfKagRFCgn xxrB6KDG/3Ts+fWw4+aHex96RognhiUyElfx5fNv7LPqOtmhNXVPdF2S/VL2SGVGPt77u62nzOUZ JnZ8i+mfgp2Yij1W/BNZqVXi8/8rjNTi2xFn+vDtgVSeffv7VOw3H/1E9szSRe+ru1Pl/tpLxR4d 8xPZlCUdm5HSzwap2K/m/URW4ndiQor2fjll/G7+/7QX/L9lNDLvpYrBibb/W/3NeLJ+cor8yqC+ 42Ovjl+nKFEi2MvfpnOFP1rkXF1pObmJYfpUMXgULPIeEuygsjkUrFKbgc7tJnEVcgHrOaNzvj4p keRul2B/ZRKrJXUmqeHK7xByV3AamAu/ApwNcq/QOQe5P/JR5HXgXph3wdbgDjAHXAUuUHTzwDj4 MJgPtokstMJmPXyoh2818Koe86fyYymxFbn2KNoM5AuRuc/lhXf3pihKbVUejTwMnYGgS4kTwE1g AXbmkloLOzwXYd8GucPnEA13OTa5V+V4yPPAbcR5Gdg7tJMsUT8VnaPIecgLwFxF6yIXkDoXfAVm FantYR4GF4Iz4DuDw8D94HiQsryKIM+EuFuj2Ooq/ngwCJwG6h3EdYHemTseexhsAl+IrNePB4IO 9KgFijDGnwdzFHkK8iDk28D+4Db6+RZSPVDvYO7VHi69fQ59dZj6H+QqE7yrMn4WkboXflwsW3kt 19ZS32wDRfeVWBvBYkWnV3IXeVtpr0ucUAYsCvnELHTmaK9QOV4rMV+u+acp+u2SgfBzNNVmhDrq v1tGBPbqOPVfDXuUpkr8lVmnY000D4m1/aoTTPNVZ5fyMqIZ4+5c8BlFZxPyBm1HZ7fgYvdZwQ2y ZpBykYeDLcBXlHd3q+wMAne4L+oItYqjlLFT0dzt/llzKS/W3lHLyC20dFvFXam9S/PaEzI+HPeY M1NHk1NLZOO8IHKx8w/kb1V2r6dEnYuOuvfo6PMa6Ch2Fum4du5Txor/Tra7VmxmO5vJG2JoZy64 WzWVd6Zq3R3POQi/Rce+W0lr7RSqrL/a6Oa5NbWOKoum5urm7hd+ks5XUq+PyfsnsVnNLdb+LKPc sZfKGJVRY2U2s2NUtgPtLB2t9jHB+appl8DU9GVd5I3nafzp/tXSgjd5YtDr5HcUrAZuhm+qslsZ nOnLXOqH8nl+M2nlN1T2e/ntRL+Wd7/I9bxOIrfwtJSn/c4iz0Jnssr+WF/8jHX2Rccf6kts/dl+ d9EZozr2d+5fBM+xtwre7j8oONb3BdfY3oJX2p5Su2esjDs7xP5e5Dv9X4mF4bYdjOJEaj3Eakx+ b38u+KjV+J9vpwr/otW++if7tJZlnxK8xc6Q0vdrLr8f0bvTLhW+rpXxa3vavwkutBeJha/BMkVb Fz/PtufpiLPSi2xjRWekfQ4P1ebTGmevgp0sOhXsa6LTw+q5qbKOJm+X9xbtJf3HH+EPFvk+Wq2m ry0y0JPe4q32Jwnu9VYSnyGC9fzbaZeetMjtWju/h1jwNNW9UBlpkSG0SF+x9ppfUfBbcBnWVpI6 W1s/dgt9YBZ599kJRFj7SY4dLthRz8LWt48IDvWvoRUeV96KHWe83SM4w+6Af1Xr7v9VLI+0I9AZ QSvo7HR71BbjaAsZj06et4+2eE09sctoi+WCH9mXdPwm1+uYTR7WGYC5erfKTjfkxaS2gOnF3FiM pkn00DGIjkHHKG8OojMV/TuRC5Fbcm66mdHUmVxjdTfY3q9zptsUm+/qfGifRr9pUlYX9lnkZxT9 5xXtc+Bl+rcK9tmE9G1nXOgPZT2j5xc7EZvp+tSRV1HRnhvaVz6x318nZ8bD3jLODoHWOvha8MNY U617oLtIw/1dKocYqwSv89WHmmofhF+gjJcNv1gZp9jLA6UnuHV11nLr0tbG6wNKqruM2ewvMN8p OpvDXH5r1fH1edJkIH3efKlnHPeV8HzE2byurj1kBSV1TFZUObEyYhSrsz6ZIusgPfe9xPnuIpCd v+AbxaT0WDkz1WPdpRZ4PijB0z+J8PmcRZS1Jlq5qbwFXA/Svom3o1yhBS2Xp3JlVlULNcDKkc46 1qDK+FgIn+M6G2TX2bkAfjH6+31p2UQLRWmjQJHVqfHqwui9gQoRKrNef59XUhvpeiyUZZWkEVik 3qoFSV2GPnKo43KnwasOXxG5N/iyxieWrz7EZLZJPK1y8vrYA9hcAc4gnt2QnwTHgx+Dm0m9FrkU +QOwDjiYNUwaqbNgWL34JchYCEbD8HS29lXBQ+BuUqchv4pcxTgnWOUm9xHPamCFaK9czhfJr0g9 TJ/5KuIrwwh/Yq+OOFkFtQdXgiGja7zOnvbzvt4TMvrWxmRW97srervBEYruIkV7gWIsxMdhQM+g 00IxAP1cUlvDr0a+C34x+sjehzBPkfolzBVYqIw8C/nXpL4J48LUx2YMfifMRPwZiDVk/xL4y8gV 1mUh/BH4q2FuxkJv5MakejA9YFYgTwbnUeJF8H+AOY5+OtgGfij8PvBBmP7IReBh8GuQCHvtkYfh D9EI0Aw+IDWsdSH2m8J3gn8UHAPSCvYj5CT4OcwUxXTaK62rYpzWiWWjUwCzB+ZJmAfAR8hLbL0S 6vsY5YalN4JvCz8TpjZMR7CYvAPA8SD6/nvgXBh0POTkLu1vyTXa3wy+2W5Y7qtXmm6eXEkoykh3 W+qI9tfqFYHfXdHbDY5QdBcp2gsUYyE+DgN6XEe4LRQDUPp2Pr06n/6cT9/Op7cr5pK3NblWI99F rsVYQ/Y+DC2j/xQ6X8JcQSmVkWch/5rUN2FcmPpYjsHvhJmIzwMpBdm/BP4ycoX1XQh/BP5qmJux 0Bu5MakeTA+YFciTwXmUeBH8H2COo58OtoEfCr8PfBCmP3IReBj8GqQVvPbIw/CHmARoBh+QGta6 EPtN4TvBPwqOAWkp+xFyEvw8bDuNqgVl5OYzn+Qz2+Qz8yhOUc102i6tq8pxWjmWjZ0CmD1hlFQn nR4SexLmAfARSqctvBLi8xh+ht42gm8LPxOmNkxHsJi8A5C/SNusvR2GXP574FwYNL1Q7qbo3KTz sL9WV1N+d0VvNzhC0V2kaC9QjIX4OAzosQZzWygGoJ9Lamv41ch3wS9GH9n7EOYpUr+EuQILlZFn If+a1DdhXJj62IzB74SZiD8DsYbsXwJ/GbnCuiyEPwJ/NczNWOiN3JhUD6YHzArkyeA8SrwI/g8w x9FPB9vAD4XfBz4I0x+5CDwMfg0SYa898jD8IRoBmsEHpIa1LsR+U/hO8I+CY0BawX6EnAQ/h5mi mE57pXVVjNM6sWx0CmD2wDwJ8wD4CHmJrVdCfR+j3LD0RvBt4WfC1IbpCBaTdwA4HkTffw+cC4OO F8rdkHexI8Tfg9ntrKWnIvM8uVdRGY+1n8fKwdP1ghOwF2fnoz8+Kasv7wXWe8XwrOJ81h6WvxPw 6iPzbLe7EJwR7pKFu4XsHw4i1zhWgE11BWK7sJ6/HH2uF5xSrAXIj2gut4zU71QOwl2+X6LDTpcb 7v7lqh3vE5i+lLVK0duVGKNegScU3bngBq5lhhMf/kZYroGb6f6Ypjq90N+O/2EcuD5yia1zOTtI 89Gpgn4HrmLmU3oY7WuI22ZiWwfmf4V7Yvj2MczFeB6npd7G23+EV1uksj73H6Mt7qR274IvJNtI KmPf2aTles2xsJUS78fP3XhIn3Qp147Rv/zzrsWHJppLajqfms4nPvN17YfcAHyb66ljyF1YGS4E y7CcAb+SK6/B8B8qyhl6JteJw9AfhoeqPzXxNnkV4zAr2SVbSblbweGktlG0XPv47Je6f1XL1sXb Asq9i/3qQZT7CtbWIO9EE/tuNvFMyPpX20tTZ2DhI8oqRl4VyWptOToP43MvbJ7AkyrgrWjmE+3q YHg9ezb+xMjbAzsd4PlLCPcYOBJ8jh67hRZ5BGYw+BvwHfB1PJ9Oe9VEcyfMhiiGgj772H4e470y dVxPKiV6/N2d1w9rzDPOm1gbQL0uj84vKh+AvwXNx0I/sdOMHsh86/4Jhr13dxT67Jb7TSnlJVJb RGURc+T7wdvBP5NrfHhdic5qLLAz77/AiG6Czmvo51DHZlgmbvZTyqpBfdfh1Y1ozotG/W9l7mU3 Pr6MkXIInIz9D7FDT4ixJx/QG73jeHIrDPv5stZUm8sZ0WmkXq5jLbgjmqmkFHcyfeZTWr83cxe7 7m4mft5F6uP0h1HIXXWvw+NuhZzp2msr4w+9y70eD7kb4mbz+3BPUXdiZWNguFO9Gv0LabW16IRj 8EWYeaQ+GrWvlt6W1CVo3k59t4APgdeiWYjOpcjF4Cj06yFzxyFgRSG9S3vRbvy5Am9fi67Zx3HN Pk+vK+0RrtPncOU+k2vqijDNudZuzjU7V+iqKdfsocz1r67w5dp2pl65k1oBNG4c+QQ6HXU06d6+ OxIsA18BJ4F9FZ1S5GJwuaIdCLowlZCrgBlgCfxc8m7i3lapf1z3hMGjXIOMVNmthFwJviqYCx9X tBmkxrFQCI4N75Tp3TTrIifQaYm8A/lYLK7+xy7TORC5TNFWAafi2zFSiyPNuM5OygiG+pehr8wm 3f0QvEM9Rz6KXNVfCvbH2zuoxSJQZRPUFVwc+gbTktQWurtltxOZql5bYSylTCa1L+U2CD3RuzkS MeU3wHyMXIxciPwb5LV49XfkqtxJibP/6cKUojmS+raE6Rr6ifwn8nYIsjTaMEd1P8SdSxz6Epkd 6r83Ec8vDX4m2Ed3X91jwd90tqd2r2N/A/pFMJM01a0U1KYsvVth/I+0dHKVUlYubWHY39sDnyC2 CTxsgs5Y5OH+73SP1M/Q1sHyHmL1HOWWUYsies679Jx09hU7ggZczH7jJfqefre2J7G1v2GncRet 4JA6SlPtldS0srag0y20EORo6TCHtEa2TchrXvsC+5xrsPMkfFcsVwtz+b8gbw5+quUe6AzUe21u Q3pCsdcOVAvnqexyJ8514AuVd/4Ivgl2Y+ezDP0LkYvBbCLsoZOtjDX+VJ2rSf2OOH/qyXrMnU/e NtQo3EddFtaXvNXAL+CfpBb1o7p0ENxJXoOfuyNv9zAS8QTN3ZSVq3F2mmufcVYp473ly3nfDxRt fe87PS/rLp+d78ckdbC/UeSGpOYoullE8iAR+xXlvkjMx4Tjl35eQk9wIzmOrL2olNG3MBwX9LQ9 4VxH314YznX02N8y89Bz3K3wn9Eua8OZSvcS3Z5gJfALSr9Me7WMF821nN5bVXcU7XT8aY8/A/En A7mKWpNRGWf8MmPgSX447vS+vzMW7MDV8afknYV+Qu8oSVkPMjYZO8EEPccxsr6jxBheWcZLnvof H6JMbLky/ieKQYlGMshiFLdTjK2C2a2yn6no3cr4Wqwe2vOxGaeUNpSbpfWNT9RnEsRyZcl1UFFG nMbtSh0LzmzG4yo82YqFPPL2gy+Ab43mjHDUMIKGBLoqaKPjxXIusOcR/zLde3dztJ84TzLP3+j9 iZGrPapDoBaaRaNA9fvQA3Ppw7/D/uu05lH/fpHfpyyDnU3KyNnkfnqs5r2JXIvUWnKN7nLb6Xqu 8TqCX4HrwTlgd0W/BjhTUc6YoxnpyjRDp7pikIBZxJlrP3xF5BLkXaROAccpxjoj303qmtCm7rHb GNG+SmUvwEIt+P1ge02Vc5DqX0jqeNpoNKldwPHgfEX3FXCDoszzldVblf3j6JyglObIS5Dv1TOF vwi8CjyhGKzAz/oqe/vgMzinXKcoZwplqoGb4VvorqN4oniXorvQ+52OMkX7FPyfwb+Cnyt6zGZ+ dzz5D5gR3GE03jHxYQcRW0uNKlnpP15NyjqfHc4KyF8jD8bPSyj3y+A8Ya4h9TFsrqd/9kRnNzFs TTzzqOPtaMbQ3EXtvmB8cd/Ka+xv1X0hIjYNnRu9byV1J7mmozlWz2W2F3mH6z6txxnQb6S828J7 nf20LFpB6z5Ae77U/S72adWrK2ijsX4tXa9q3f23fAcd3U/opDHxz9LUYISe0bxFfib6+tcRLdHc rWWJvnoyxvbXvSnuqI5QJuipuYJKKvvb1b7zip5Z3EUwY31izigrU97e6H2pOz+hTb0HHWxQHf9K WmE/98df9OSaMXgH/5+mBXtS3/v0/qx7QuvoH8F+U80bTELeoedBry6tcK0dAIq3do/9FtT4vKi9 wuNukVcHnbPR+QBsregukisex3ZT38RDlR9X9G5UlFpcJ7hNvXVbKCPrtOt0r0z9DGDscfBFtean 232S+g1xy9H4SGQ0PneQdxF2vgQXcUd+jr1BcF+Yqn66c6h1C28wNtWTpdgfpbnsEK2d31RR6mWF ORz6zL3sa0PUeEotVH+s2vcu17Ot1z6qke5mDIPnnldwF3UpAq8k/r+mlxYSt71eQ+Fdtek9SuoY cBA9qi5PQXTQsvzmtGlz+nbHsDXB6vTYqfTzN+nnDyK/r7K3jN7+CnNFAs3RWLgk1KGfl6CzAb4m +7rnwzTE2hFKGcD4fYlcJ9C8nlF8M2e3tti5Xp+Akl6ha61rdGSlM1+lddXU2OOKccMcm82ILlCM 72GWbgFuxMOzVDOdGVvyVievxuQBRsojjL769IH9MI/pHWopdwqjQ1dTaxXtk5xTinXt6j/BbPwb Ij/df4Nx+ga5GnEWUHkpa79FzGMzPa3Lm9qm/vhwbldrnkOf6U+vKKBH7aanPe5J//dv1REk/eo4 a78B9Ac9mxfjf5zSWUMmv+KvgIzuOLnH2OMaCZYl92l7IU8C+0Y8Ty+A08K9O3A5u2QDQTfUTMj1 pttS7dgM+BL4PPJuUt4pBROUFUc+ilyJ6/pKaFblWYjRMHHkA1Hpqt8hsqCWW7LnWRTuxKKTCK/f w6casLwY5C6t3R75ptgAvjNX/ZPYlRqJtQ5olpA6Fx/2hl6hyTW+u5yrfhc5js4e1TcHYIajnx3W Dsst8SoL/hL0d+NDOn52RL6EEmsj/wbNXWg62OmGV6NIvRK5cshHZSkeIg5t0BmF/AIW1oBPUlYL fYbB7Yp++ARINqnDsdkDnYEweaQW49V5lFUI/hF8Ewz7zIXkDSNMrS02ne+w9ik688E28N3I25X7 5ofA4/izAPwibGs0K4JLw1LItRMsgv9W6+IUI4e7yrlo1qXPbIVfxb7xWzwDE7Dr+5bmsvXRn47P +OYNRm6I/zmkhu11EPlXxORF8Hl2pWaDpbTvwqiHqLwHPoFcFmlqroVRHyshlyJP7LivsOcZB/HZ /QzPS5EnIa+N5GGMlPngMOy3p4+V0CeVn4HlqhHTHlnrNZAdrSroxJHdaDdYdbJ4buEAuVri87TI 2/mMiBJKYVzAHA3HNXIRmnnkrQTm0Ubs+8WHqGaMucL/RDG4S1P9N6jRQcVYa2WC52idv4O30nvP Vz4+kby0gjOOXK3xeUbYq8EhtPtw/Al3pIvwIRwLVcHz0DyWfJY5bQ7z3rPUtAe10B1R2t25kT7T gTo2w04v6p5BXz1A6QlwE1gIbgFzsfA78r4Ovk+59FL3JqwtUl68rCdMb2+PIj1wpNdZ8HXucr7O nuHr3N9vyHMpx2OSapbG1Yd18S5gD1CfeloXK+bp3NXgpdqv/Ho8hVukz0TxpHqWrkvNcT3XyDVd ZeW9g4Jv8JTvIZgvwY08+7RRdybNTr0uMzX0nGJasQ9ZD6wMmggH8ERNLjuQN8J8Cx6EqYwsZ2ez IvhI53ZwRUw9HA2uCJDBFbGr4a9GboXcCp3H0HkMeTKyPq9YnfVAdf9a8EvFYB7owbQDm2ou/+9a U28j8nrsPELdpyJvA8eCreGH4kOeysEz5MIrXY85c72nwd8q+r8EVypqXsEcmHnIr+r8plc6zgL/ t6BqLkBzAdeqCyh9s19DMbhJ2y7WE1k92ax7AmaZPmVtXld0bvK/kXo10Cev3AbYLFMLIk8GpyoG PtgJ1Gg0iLmsMa7nevkpRfYZcrW9RJ4CrlMMOsN/CB4g13+IPMgbAr6k6N+MppZe3TtONC5SOehJ 3fX9UNvxvFRLF7422I3UWzQ1KMX+X2gXRhC5DoXIc+mHyJvrvwh/CyUO0jnZ60DqWfA8sUz/ORRk wDwK1gTfoE3fpc+s0tnVH6Xo/QpZW7OQNVgm1wVjPX2yepWimxncY3SvtY3y/h+VB8fqClnkjsgj kEcgP4j8IPJ05OnYkXLdGyg91/8UfAZvXwP/Sb0m0d/Ow9t/6vrE20wPOUfPg+qbaOq7tw7FeoAa 55t4TvUcT58tn+21UPR/LviZPg/pfEZbf6ZPyglqf/sslovck548S3BfoO9lLtUnKs0+X9sox++t 855XR+WA3WntV6aUkbIv6C5MOuW284pBHemjdWRJa1bVudH7DP89UJ+q7ewPAC8CH1cM6pN6AKa5 nkGCMDXkh4L3UCPdUZzicT7V52+dKXYo8ibkCcgw3h9hPoEpQ34PfF9rrWtmt4/7KJHRZ0372Bzk K5CrIV+JfL7IgzUCZoV9gX5ylcbc1AHv0JlT79Imd/FmBsMbwA3MYfMGOk9oNMxwlZOe2gEPJasi V0VHUp0GSZ1J5pvLkOeonFyH/Bjogx3AieAfsfMNSA/XOV/kKci1wXPBr8FbSb0YWf/6uTRRiTN1 G/AbzuDDwJ7gufABchVwv5Q7GQ97gZO1LMH6yoBrWSf0J/U+cLZ6JbyeB2ck67E+eQ3Ua+fshJ71 WiYXag9XH5wFhnsKic9B3XVvn3xE8buF4Heis4Nab/9O/yKjVFHsfK55yRXDTm4UGfUqV2vkDAox WZFUxYKEjq9M6p6P/s6EznWtk2vALeCbWK6NhxWRuT+LtQWKXiPNK9cUWu7SpFxbOT8nhjY5RjEx CfkqHRHobMKrzxJHpcRHNMLmkURSsK3aF5+3S+odaF6o71CRaGu5s5PpypDaLvmJ9p/E/dSrFnE+ gOXGgusSz+lIVH25htKxuQnmUJIzmjIi10JeAo4XnecT2gOf/05mJGcn640VSb2GLU3KbC+riyZG r7/qEj3B5DyeGf7W07HjcX4/zoj4vfZ/sd8Yy/r3BQXEc4GirDxrM5bbMh4PMzPfxJjdzui2pD6L LHNLcgpn3p16jjDbgnC2n419OeObl/RZGvE13WnubzR+n4I+fU2tfvcX5JsxdxYMuMvMGjSgb4FZ ld/n3rtNsUTRbXdNl1qmXrcubWrp73okkybN+MLHzYWmvvm5ucHk6tPX8IE5W/Ai08A0N/pmvJrw 6SZmKgnWMw3NpaaFjPtGppb+DmSUWs2cY2qbxqaludq04Z28t5SnniWtWdnkyLGJuULKb2vkrGy6 lKe75lyToV527Nq+lsnt2uXGWlJymPN8U0VmnUzT1LQy15h2vJflVtIyTDa/i51lmsnYudJca643 NxlrukapF5iq5memgrnEXG6uMteZ9uZmKbGb6d6v2Yh+bgBWBKuDdcFG/frk3+s2B68C2/TrN3SY 2wHsCvYCB4EF4BhwPDi1f/7gO91Z4DxwIbgMXAWuBovB9eCm/nffM9TdDu4BS8FD4FcDB9/dxz2h aF0wPrCgTz+bBVYFc8Bc8PLBdw++17YG24EdB4+4J992AfPAXlJsH9sfHAaOzb/7vqF2IjgVnAHO Bufl39Mv3z4LLgGXDx3Qf7BdBb4KrhHFAvs2uAHcBG4Dd92jdvaDh8Bjip4B48MUK4JVwGwwB6xX IC56jcBLwZYjhvYb5rUGO4BdwV7goHs1VwE4BhwHTgKfMPr+l/Okh1T7N6Tv35P0A1oZLXEZLf+V pHr6Jyau9Dz/FCaV5MoIOyflsY6pe9LRkfFyJvtDar0fxbNOQysjpQYvm/6pkmMyz8D009CTkVdR ZpJzfkR2ZJb5MeQJlig+4XuGMs7Amj+CrsxQOT/h6Mg88WOYdRpamc/ON9n/huTK3Hjhvzxebu42 I81DZoKZKueSueZZU2h2mYPmqDnheE6GU9nJduo6uU4752bnNqevM8QpcMY445xJzhPObGe+s8hZ 7rzsFDlvOxudrc4up9Q54hx3XTfdreRWd3PcBm4zt6V7rdvB7eLeZgL9407nKLOw444Pj7FDnFec tGlG12tO2kyj52nnrFbh/8/S3RL5ZMwRPs2cl7EyY13GtowjmV5m1cxGme0y8zLzM8dlzs5ckrk6 c1NmWZbJqpzVIOvarK5Zg7Iewpab9WyWXAlIbierLDqeCI/nxsNjNf2FYTle0CE81oi8qbEi+n8Z ltJrZtdsUnNlzQ21htSaUbtX7SdyCnIWhGXU6VUnHw/dOg/VmRHmrlMU1q3Oxui4JTzWbRMdZ4fH iwqi4/bwWK9VeGyYbXiitGFO9P920bFvdHwoOs4OY9lwZXQsDvncjOhYLzpG5eb2jo5y9a1tkjsr 9Dd3RRiNiyvpX+DLsU3IX7whOu4Jj40qRseHwmPj9FC/caswf+POof3GQ6KxVIm5QDn9XSArZ+tO Qr/gvGDcWMtYS95Q9T/8O1D+EF2PODnupbadlydjpqWczzvIGuE209cMMQVmjBlnJpppZpaZZxaa ZWaleVVWNuvNJrPd7PlhjMRWGhtbEns+9heOhbFVHJfGXuK4LPayHJ8X6a8cn4+9wrEw9jeOS2Ov clwWe01i8XxstfyvULRf5/h8rIhjYewNjktjazgui70p2oWxYvnfUtFey/H52DqOhbG3OC6Nvc1x Wewd0V4ae1f+t0y03+P4fGw9x8LY+xyXxjZwXBb7u2gvOy0i+tvgo83DPykiG6n5ktgHUWRKosh8 GEVmUxSZzVLOktiWKD4fRXHZGsXl4ygu26KIfBJFZHsUkU+jiOyIIrKTiOyKIrI7isieKCL/iCKy N4rIPiKyP4rIZ1FESqOIHIgicjCKyOf/IiLfz53/VUTKooj8M4rIoSgih6OIHIki8gURORpF5Muo x3wVRebrKDLHosh8Q485HsXn2yg+J6K4fBfFJRFFJBlGJG7CiMSdMCJxN4xI3GpE4l4YkbgfRiQe hBGJx8KIxONhROJp/0ZE1ph3TYnZxrvaj5jjjuukx9PDiMTPCiMSzwgjEs8MIxLPCiMSr6ARiVcM IxI/O4xIvFIYkfg5YUTilcOIxM/ViMSrhBGJnxdGJF417DHxamFk4tXDyMTP1x4Tzw7jE78gik+N KD41o7j8TGsarxXFpXYUl5woLnWiuNQN4/JvR+RgeUQujCJyURSRelFE6kcRaRBFpCERyY0icnEU kUZRRBpHEWkSRaQpEWkWReSSKCKXRhG5LIrI5VFEfk5EmkcRaRFFpGUUkSuiHtMqisyV9Jiroshc HUWmdRSZa8LI6JlB/dbzgPOEzPQZ5m45EcTlnJAtK5AmEq82co2Vl7FRZvrr4rd4T2R8EEnTM0qQ ugj3YSRNz9gkUlv0NkfS9IwtSKr3USRN53dN6so1Y3Npj46mu+kts/q9staZmLG1vKSPy0vaVl7S J+UlbS8v6dPyknaUl7Tz+5IySkW6Pn6dcAciaXrGQaS2wn0eST/m0a5yj3aXe7Sn3KN/lHu0t9yj feUe7S/36LNyj8rKPfpnuUeHyj06XO6RjH2nkdNIloPVXb0fXsetY/TXVGRVlHkJ6657pdUelmuR M3w2s80C6c2rzEbpx8ekB2c4VZxaTgPnUucqp70zUvJ6ZxUZl19F8M56o1xa873kvifSLKT15dL7 5dKGcunvSK6shTLcjSq7uwVnkvZBuVZJufQhkpVaZJnK7iZyqCePu+rFb9HZfJJOFVd9mum+aaxo znS3lFv6qFzaWi59XC5tK5c+KZe2l0uflks7kHxp/8rS53NMPVfOz+5TUpacn925clwrGk+56wTn ujvL8+2K6h1zp7rTpI3muc+K/kJ3iUl3C91CU8Fd5v7ZVHRfcFeYSu5K92Wxb1nbV5Zx5fBeYWMa mvA3BJ+WhMXuYrG5QvSt+zf3b0bfX+i6M3izm/42nLa9zPRcOabL1Z11Z7uzzQXuHHeOqSE2XjM1 eVPb1bypTe0fkSu6bOnTrWXO6yFXE6PNfLNEzn/7w/ayspJ0v87MM67fImKuh7kNRmqZ2VOkllHa DaT94iTtDjC/LNfugbbPbxlWlavDuuQ5SjmHM7tL6hXk+ZJyjpDndnKflEdLcI+qV5Lnl6qt/rhH VNM9FpasJblfqXfuF1jprp4Qr8P6NzJ+C/8K6T36O3c2eDSY4OqukrU0gE236bpPaTNY7er7nRyH tz7JN5ffPCl11gtXchJn9Q3azsvCrj6JdXjPy6JT8hY6el9j1il5Z8tH/0pz/Ems54znM1X4u0+x qev+7qfYvE1/FdVpc4rNdvLRew9NTrHZhI/e26h+is1G8nVPsRnwWy+HTrYp/eWIo9dc2062Kf/T j7ZW8ck2jcRN5piTbJrl/CrXnFNszpWPxK38N71CmxP5SExMwSk29W+2bzvFZi85Q//wmy+hzQ7y yTc//OpLaPNSPhKT6M0RyjvRm6mt+42+JUvaPsOkBxOCR3nT56nv0S6/ns0ahbwAOXzn9YXyzY2s XoxfTXjXefVyTnM881NKyhod9kv7WXCB1VneCWoGtXVmcCaZIltqa9l6Ntc2ss3s5XacHW8n2Il2 kp1qp9kZdqadbefa+fZZu8gusYV2mV1uV9qX7au2yBbbt+16u9FuslvtdrvL7hVbB22ZPWSP+PX8 XP9K/2r/Gv86v61/vX+Df6N/k3+r/wv/dv8Ov59/p3+Xf48/wh/lP/Cf7J0HVBTJwu+rp6gmTFeB oAgICKhIpgdQMGAABVTEAGJCkAxKFhEUBUZFRTEHFAMgKAYUBSPGdXXNOa1ZxEXFLLuY/WoKZFmv e/fe952997zzHn2mprq7uqa6uv6/qapp+o/SUAaaiqajGWgWmo2y0Ty0AC1CS9AytBzlolVoDcpH RWgDKkHb0A60C+1F+9Ah9CM6jk6j8+giuoyuoVvoHqpCj9BT9BLVorfoIw94JV6FF3gNXpNvzuvw erwh34Zvx7fnzXlL3pq35WW8Pd+B78R34bvzPXlXfhQfyIfy46TbpeXSnYJE4AU1gQiagragJxgK JoKpYCZYCFaCKDgITkJXoYfQS/AQPIWBgo8wTPATRgshQoQwRogiaWQqmUFmk2yygCwiS8hysork k7WkiKwnG0gJ2UZ2kJ/IKXKOXCLXCP0OAYehClR0xlvD1pQV7WF7IIGW0JJeNWtoDZSgDMoAgh1g B8DDDJgBlOFUOBWowOlwOlCFM+AMoAZnwVlACrNhNiXlPDgPYLiIXm8Cl8AlQB0uh8uBBlwFV4Fm MB/mA01YBIuAFtwAN4DmcBPcBFrAElgCtOFWuBW0hNvgNqADd8AdQBfugXuAHtwP94NW8DA8DPTh UXgUGMAT8AQwhGfgGdAaXoAXgBG8Aq8AY/gz/BmYwNvwNmgD78P7lMsP4UPQDj6Gj4EprIE1oD18 Bp8BM/gCvgDm8BV8BSxomzEDlrTdWAEr1BV1BdaoG+oGbFAP1APYIhfkAkTUC/UCMuSG3IAd8kAe wB71RX2BA/JCXqADGowGg47IF/kCRzQCjQBOyB/5g04oCAWBzigMhYEuaAwd63dFMSgGOKMElAC6 oSSUBLqjiWgi6IGmoCmgJ0pH6cAFyZEcuKJpaBrohTJRJuiNZqKZwA1loSzgjuagOcADzUVzQR80 H80HfdFCtBD0Q4vRYuCJlqKloD/KQTnAC61AK8AAtBKtBAPRarQaDEJ5KA8MRoWoEHijYlQMfBTP agVDUCkqBb6oHJWDoWgn2gmG0bZeAYajg+ggGImOoCPAD/2EfgKj0Cl0Cvijc+gcCEAX0AUwGl1C l0AgVcI1EIRuopsgGN1Fd0EIeoAegFBUjapBGKpBNSAcvUAvQAR6g96ASFSH6sAY9AF9AGPRF/QF RPGQhyCaV+aVQQwv5aUgllfn1UEc34xvBuJ5LV4LJPAt+ZZgHK/L64JE3oA3AON5E94EJPFt+bZg Am/KmyruJ+HNQApvwVuAibwVbwUm8Ta8DUjlRV4Ek3k73g5M4R14B5DGO/FOIJ3vzHcGGXw3vhuQ 8z34HmAq78K7gGm8H+8HpvOj+dEgkw/hQ8AMPoFPADOl26TbwCxpmbQMZEl3SXeB2QLtdII5AhIQ yBZUBVUwV8ACBvOEZkIzMF9oIbQACwRdQRcsFAwEA7BIMBaMwWKhndAOLBHaC+3BUsFcMAfLBEvB EuQItoItWC7YC/ZgheAoOIJcoYvQBawUugvdwSrBVXAFqwV3wR2sEfoJ/UCeMEAYAPIFb8EbFAhD haFgrTBSGAkKhQAhABQJwUIwWCeEC+FgvRApRIJiYawwFmwgU8gUsJHIiRxsIpkkE2wmWSQLlJA5 ZA7YQuaT+WArWUgWglKymCwG20gOyQHbyUqyEpSRPJIHykkBKQA7SCEpBDvJOrIO7CLFpBjsJpvJ ZrCHlJJSsJeUk3JQQY6RY2AfOUlOgv3kLDkLDpCL5CI4SK6Sq+AQuUFugMP0O4GAadAEWkAROsBa OAcuhDlwJcyDhbAYlsPdcB88BH+Ex+FpeB5ehtfhLXgPVsFHlPxPkTmsRebIEs5G/dEgNAQNR6NQ IApFkSgaxaPxKAVNRmvRerQJbUVltJ3vQZboAPoBHUMn0Vl4mb5fRTfQHVSJfkFP0HP0Gv2G3qPP vITneTWewEeoP68NTXh9PorvCI35AD6YD5fuFpQEFUEQNITmgo6gLxgJbQUbwU7oKHQWugkugpvQ V/ASBgu+wgjBXwgSwoQYkkGmk1lkHllGcskaFm4iW0kZ2UVOkDPkArlCfia0Hw/kjMiAEZljLJYw FkPGYiXGXMRoyzPOKjPOqjDOqjLOqjHOShlPBcZTzHhKGE/VGU81GE+bMZ5qMp5qMZ42ZzxtwXiq zXjakvFUh/FUl/FUj/G0FSOpPiOpASOpISNpa0ZJI0ZJY0ZJE0bJNoySbRkl2zFKmjJKtmeUNGOU NGeUtGCUtGSUtGKUtGb8smH8smX8Ehm/ZIxfdoxf9oxfDoxfHRi/HBm/nBi/OjF+dWb86sL41ZXx y5nxqxvjV3fGrx6MXz0Zv1wYv1wZv3oxfvVm/HJj/HJn/PJg/OrD+NWX8asf45cn41d/xi8vxq8B jF8DaV+oNRjESDSY0cebEceHEWcII44v48tQxpdhjC/DGV9GML6MZHzxY3wZxfjiz/gSwPgymtEk kNEkiNEkmNEkhNEklNEkjNEknNEkgtEkktFkDKPJWEaTKEaTaEaTGEaTWEaQOEaQeEaQBEaQcYwd iYwX4xkvkhgvJjBGJNMeSDFIYXSYxOiQyugwmdFhCqNDGqNDOqNDBqODnNFhKqWDJsiExtAc2kJ7 +AbOhgvgMpgL18C1cD0sg7tgBTxIW/RReAqeg5fgNXgT3oUPYLWijVI6vKF0sKB08EQDkQ8ahvzQ aBSCIlAUikOJKBmlogK0Dm1EW9B22op2Iwu0Hx1GR9EJdAZeou9X0M/oNrqPHqLH6Bl6hX5F79An nuMRr8pjWI08+RaUCq34sXxH5ENj/nwQH4buS3fQwZeyIBXUBS2hpdBKaC20EawFmdBB6CQ4Cz2F 3kIfob8wSBgiDBdGCYFCqBBN0sk0MpPMJUvJCrKahRvJFrKd7CTHyWlynlwm1wkd84Pp/58Q/w8R QtFL8Wac8GGcGMI44cs4MZT1TIYxWgxntBjBaDGS0cKP0WIUo4U/o0UAo8VoRotARosgRotgRosQ RotQRoswRotwRosIRotIRosxjBZjGS2iGC2iGS1iGC1iGS3iGC3iGS0SGC3GMVokMlqMZ7RIYrSY wGiRzGiRwmgxkfUoJrEeRSpjxmTGjCmMGWmMGemMGRmMGXLGjKmMGdMYM6azu6kEOkKOAz+A0+Aq HcU/AbXgM6fCaXL6QI25lyq8S23oWLoz6AHcgCf8lWpIDutoOA2+o+FM+IGGc/mZQIKceTqeRd35 iTTsyafS0JXsBhI60tpLw0V/kuNvLMe3LMf3LMePLMdZLMcUluMkluNkluMelmMFy5EDSvwURWoW S2uMpTfGMhpj8sbY1MbYtMbY9K8x4XVj7A2LSSgd7sJ7AKBP6DOQUKZJaHrE02EsZZsaUKFMCmNe MYqZARU2K6UpPU3Jkq04Dj75Pc4r7krkFM9gBYqZNDXQlqXWoCmUGtMqNaRU7CEwjdKKbq9/Z8dL 6v9nj9ahIgcdNld7hh71Bs6Ft+uPIoH1qevf4RN2VAk9SjHppQQsgAg6smeSuwDQsO3rlamfw7Bh 5XzAQjb3oXhWLA030vxJ/bwa1ISalJXusB9QRQ7IARDkhLoAdb433w9o8V68N9DjffmhwIgfzo8E JtJiaSloJ30v/QJssC8eBRzIYXIUdCV3yB3Qk5VCmZXKhYYewAv4gHrP3/o99aXTb2g59aW0ZWVa w8I7bBYcsvhHFt5lZ/2E1eTfV2Z14EtLqfglOo6+kmg8FchpLAvMp/GlDXNg9SmtgB1wYq2+B/Ck 8cFgGI2NBmE0HtVwTiIrewUL77Ez6Ahf/n5u0tNszykW1jaeoWLtGQvLWFj5t55zc3a2ivtRptFX Fo0rfjWbAlaDQrCxIVZKtyqe/rmv4eybN1zbvmAgffnSuKLW+jbkVB9LpVvlDfUg+1/WQ0ZjG/jP 1IkWvYpRIAEk07NPpvWSxepkJShoslbMvKi3NNSI1u8MpC9FW/AHIaw+fl9LUtyTCRqevAoUT/lS hOUN5/NtbWQ3OectLFzbRLu/NNTV31kLHHsebFvw9d41jYbSs9+oyCFFqK7esM+GvvdiiyKFQ8NW Hcoim4alfrsEQGm+tAAAaaHCV5FUs3nYpvOomqDeiUZJUg0kEsX9u4onONX/OpbIakkx7xsCbIk+ MSCGpDUxIsbEhLQhbUk7YkraEzNiTiyIJbEi1sSG2BKRyIgdsScOpAPpSByJE+lEOpMupCtxJt1I d9KD9CQuxJX0Ir2JG3EnHqQP6ct+c7CSDAeA+Ucr+OwBjPEnIiHqRIs0Jy2INmlJdIkO/oA/4s/4 CwGEI5AoEUR4okxUiCpRI1IiEEwI0SDNiCbRI63Yr3//4LhMe/wq9Ls9AE/Ek3Aqnoyn4DScjjOw HE/F0/B0nIln4Jl4Fs7Cs/EcnI3n4nl4Pl6AF+JFeA3Ow/l4Ld6It+IyvBgvw7l4Nd6Cl+A3eBUu xCtxES7A63Ex3oDX4c24BG/C2/B2XIqX4kpch5fjcpyDj+Az+D7ejffgnXgX3of348P4B3wBX8KX 8RV8Dd/Et/AdfBdX4V9wDX6Kf8W/4bN4B96LK/ABfBAfwj/iY/go/gkfxyfwSXwKn8bn8Hl8EV/F 1/HP+Aa+je/havwIP8ZP8DP8HL/Gb/E7/B6/xC/wK1yLH2CF35QXUGV3VbZlbqCKX/NbMcdZE+Y4 25Y5zpoxx1lz5jjrxBxnOzHH2c7McbYLc5ztyhxnnZnjbDfmONudOc72ZI6zLsxx1pU5zvZijrO9 meOsG3Oc9WCOs32Y42xf5jjbjznOejLH2f7McdaLOc4OYI6zA5nj7CDmODuYM+aMgTdznPVhjrND mOOsL3OcHcocZ4cxx9nhzHF2BHOcHckcZ/2Y4+woTuE4688cZwOY4+xo5jgbyBxng5jjbDBznA1h jrOhzHE2jDnOhjPH2QjmOBvJHGfHMMfZscxxNoo5zkYzx9kY5jgbyxxn45jjbDxznE1gjrPjmONs InOcHc8cZ5OY4+wE5jibzBxnU5jj7ETmODuJOc6mMsfZycxxdooy/QNpzHc2vUGx/1tV/jPF1yt2 hGQGVewsySym2L7AhKpToU2FCht1S/X6ialV8o1eFWptotV6fRPFfXZKnA1nT3PWkGgBXtJCYgnU JHMkcxQu6Zwa7Y//nyl3JVXqKqrf1Q0KLqBqLaJKXce0upFqdRNV61aq5W1UrdupulcwfSuULf9G vfXa3d+g3v+8ds/QWhrQoN1eQPGfV5Egg2p3Fl0cQB7IBx1oP6IUOII9dHECV+jSCdynS2fwgC5d wEO6dAWP6OJMxy5PqGqf0qU7qKNLD/CeLj3BR7q4gM/gC9Uu5CBVLeIQVa0ypwzcOTV6LTzogFCg 2qWXl2pXg9Og2tXkNKl2m3PNqXa1OW2qXR1Oh2pXj9Oj2tWn46NBnCFnSLVrxBlR7ZpwJlS7bbm2 VLumdFzly5lxZlS7FpwF1e5sbjbV7jJuGdXucm451W4ul0u1u4pbRbW7hltDtZvP5VPtruXWUu0W cUVUu+u59VS7G7gNVLubuE1UuyVcCdXuVm4r1e42bhvVruLezAhuB7eDancXt4tqdy+3l2p3H7eP avcAd4Bq9xB3iGr3B+4Hqt0fuR+pdo9xx6h2j3PHqXZPciepdk9zp6l2z3JnqXbPc+epdi9yF6l2 L3OXqXavcdeodn/mfqbavcndpNq9w92h2r3H3aPareQqwRSuiqsCacoqyiogHSfS792M+m9gwPpw 9Dv6q3OzSUOfoAO7i6GCLoAMIf6KPhx9aTXcFa0H1Eg/4kn6Ey8ygAwkg8hg4k18vk2DR+NAHISD cQgOxWE4HEfgyG/T0Hhz0IKOcOrv1q+/85qmocdG/lU+eAwe98c+BlH4pzLXYdouOeZ4rELHJxo0 b6OvI1us8DbtAzzxBPY+AKew9/5Y4cjZBxykoSc4pGj9WPELcH+WW5+GkozBY3EUjsYxOBbH4Xic QEvwr55RfWn/aT5Nz5rWuy8ZSoaR4WQEGUn8yCji/29fBUJ7bFek6uoUhX9yzzBHqar4nyITOgLq SHVZf4fQKXZHy+nGO32qFJ6lLPawMfbL1xg/QZH6L+6QaQvUaZ8wgkSSMWQsiSLRJIbEkjgSTxLI OJJIxv/Jb/Ic7bOr06O/jotdGsafI9jYrL5XLyHJJJyFESyMZOEYFo5lYRQLo1kYw8JYFsaxMJ6F CSwcx8JEFv55mbQbW9w+OrovhFV09P11VG7TONOgTQ4CZTr6hXAN/Ajvwid/XG8YEynGyHHsGMWd VGbAgyhmL+/RERWkYwcIT9F4LXxCY89gGY1XNuzv+O/sp5/VuL9x9Da38VPtgB85AJr/yadmKMre JP/6lN/7/H8hZUNJMtj5/2OZHBpr9hDQguV0T/2xijmaLXAtrelfmqzVNhypGHs1Z0cickhdXV1D vZm6ZsO4hqmAJJEJJIU5SX9/xPLXiqsnI8f+a09g/1MAAJK8hK2UwpUilCIbUnD1qQDQS2Qja/an FyXK9SJ4VYtMj8w6zClL8uR6w+mmIRKOk0lFVR5ZEijRQ0AM5NUsedqNlTtKOKU8b3GQaNVki36B Ybo+FYFiGUA70+NALJVAKEikr26KRTRukplS80hdcOhOXs5FE5cAizqPB6/ju7u458lb2IpypeWi HGbkQdptlmjRnhBYZZjdfsvuN9fZ0xHAKhE3llbxfGwxhRUTDlHitSRDvGVaYjPFioqW2tDAcRGR MeGJsTEyDZEoNiprKQ8ODYmOjQmRGYr6ii1qWi36RwYnxI6LDUs0co1NiItNCEyMpEe0EY0V+6GW XtP9IaFG3pHhMTRXo4GuPUXDllhmJ3YSHexkDvR9BF21F+0bV8WMqX9L2bAoVeyXain1HzBw8Nfk 8E+Si3LOpGmd0V4MlNPhBt2uJpFzHNhb2CdK44PJytAC7ZwupwKD3ieal2Tzuhfjh+lm+Q/FkUEx HfO8Ppmk3DP4SS9w7vuPa5u10z5+aJiVLGvmFjvDmTfTuiUOrZte2NH7ZM8XkbsjV0f71sRUbTft P+5CSHx566uB02YC4xcRw6aO7DOv/O6lDldP/Syu8f44ceyKaZa7jMMTL/+WvDNwRs7iVItz4Y91 D/y8N/hZV69ukyU1b9K2nlPflTGl9sOjugUeFfOc5xxXXqT/Zv/4qo/BRuZrOr3p6eNk6BPSo3za Rsctb8CcSvw+f7u6yY71G7ZcbblHfClpY6Txfuxw9Xsla1aPzlgEPXFukG5ZxdJ9C0asS85Myo06 4/lUc4eTuwRSZayVc5jWiKqoRevSoJ2SIKrxKrR1I6QMoWig2EiUtJWa3xl0q9Vrw76ou6b+4X1H ykKtFqAcsbVidxslHVE7vfmpZo9OXizXHsadcLSx19be47lCrbXoq0jQWmmA2F/sl9cnzz2zd0Ri YlxnW9vghCib6K9XzSY4Nto2bmykYqttXEJsyPjgxHG29KLShkebHW1xAaKTtb3M2k6UiTY0kTji axk5TslL9BT7fl0XJZndGj5iwoQJ3/uI0IR/mnfiNzKDipZiUVj3/NAR04lTg/SSV448+ulpix/X J2tdaOltJhWAS3cn9Vm3QnSndUjz2HOuZuKs/DMDNtyreOau8bnljRmzNC54tsh72ezLjaXnQs5l fLJffyR5UVXqlegZ8Vf1AytPe4XsGtf93aT2Dr8N7u7ueohkxHkfXsoV9Ks4aAEnTIr5cN4tq6WZ rAg90M7a/apvZItR9u/upi3u6t7bYMvJ2T/VzTR88nmBsGaAsuoz04UxZYt1ubcBGdVbbsyalzbC f1rAjgOpbg/dt34eZrkgbcYtt9aDlpw+EpS/46eAmhORfvELNmT7Gll19lr0KZefV5L1NmJKl70p Los69fn1vP/TuGyX8UflQ+a32jEkkMLpCIXTpiZwsuxk53F4+wmPN4ymlt/CacLfAgBj1uKo4nV+ 3+8TGR1q7Z0YGB33LZpkdvYODE10w9dVMaPsP4Gm9mK7+lXDGNfIuIjQBKNe3r2Nent7dXYV3Rys 7UWnjta9ers5ydqJberPSP+7Z+QdmpAUGRz6lyhbt1MkMHTLwBGZY6ev8cg3PHHouX8f5en34pam HtgTEBTAm16a3alCx6TIZmHJ9X4zO+ttzZ265bh/pzk/2E3STn7m6NT5VdCHCLkk4mlNRY+sbZ/z rToGjY7rNDqIfDim4xRbuvBqD5y+DifP7jg2M8u0pc6X0pr+eyvMtX7x85gb59bR9LNDh00O9+tu XPd7snyybFf/1kNrUq8uwWGCIbFr2c3qSnr+2Zq6nAWSW4cDPjmlv+2UNirkpKNfl0EjR00POGuo /8HhQMBDsyFxPit3P00FQ9xGmuWY+Xref7VXVXdphoeFeLzO3iiqOvJI2eUjXudEQ8fLOYMvb2jT e/sWv559BpQHRSz6ijJVWiOoCbWKdOy9uy8Zne+q/WLusa0XLfeuHnb+D9Rq4/D258FucWrPenxI +lBmWXqkQ5m66FNPLcoskTIrr3em679FrfrdiqvILiJtlYxZw5owixJL9GjCrK7/GrO+m3Pi99Ct 8j2MTTldOumh7YFq3x3nxt3cOPiCdqdj5WfeX/tsGLqj2uNNrttMFDbGNNP/84xht44Fz3VKr1Vx S7Uct40c7Lnx1E8bFxc6vgzpdP/olXdnlc9uqmr3MnLLZbfKz2F2Xa8tO2pn/P65Xrs8f8HFqpl9 Z/nUT88Myg6cXVC4oF38nk0Jpau3Vp0DQbPiNuzuO3DOc1uTkKLiX/qPXWKln/J0/VrZjfmj5xfG fF4kwd2t2uJjY0wzBk3tq1ExPrjXxkiVY7Cm8pz0mW/npy8S1qsJteCSye6tJgll1T+ulJrlpZ98 cP9apzCx2q2lTvV7+fvh0on7ivFn/S9wdvD2/pqSNgOsy6ZP61KZ7/7oXAtRjvZRjBXWY0wt0N5U j9FL9i29AhgW1FQXms5a9NoqhNPVhvRayHTFln/YqNp4qWTWomW9jtv+ruPBsbEUEvTaRYZFBgcm hhr1HJ8YEZsQmZjCKCWKTpRMdrJO9naUUnYNq3aK1f9m3+6vULM9Ybifrhhy0GDFaCMjl+VJ3lHd Wl2NPX3q1ZOxn5dpa9y72zlxqt4u2zy7p1/u/ODi1eZKArjZYajarJNbjPrUvozY3L9fdtH+lH7x ue7KNz61u7tq/MxzG8f1SruWcfPN/tcdC0/49b61tcT5nlnEMr31RQnjfF+1XFz1qcPihLyrSQGG E3pPne6kfX7cSLQ3fHB20fZI2xu60s8LE80rk2x9bjcXh7+9mB306dSJADfZwD3ttap6iOcSzDXM TH5y9HLOs3OefybfiZ/u5+UrN7NAdrv6XRsQXH3ROuhVb+fqzSrgN7f81RdGzjH1fjRxY9/Xbucc uzqtLp/gV9RydfapZvN8ux7erBoAL31FjT+tkRGiukJ6Whz3RQmJkL41Yc93O0SKbwkDdSUl2gIz RU1etWEc0YJTQixj+nXQuE2iyOXTBZnXJdOsJfdzRncplsWu67rvurWo25iouURJMFQD3mA8HXu4 gp5/gBvZLB/dw7f9softtD5a3FfzXjK8qlAcWA+3PqK72DvPNa9nZvd/HW6NuxNo01ZQiYHNpwnY PEQ3sVcTsDn9O2BTCMa1Ptd/7IZJODC8U7c0U7etNbE9ttntGFNDbGOK+9TVBIx/5tnF+pprifTz qcfWsrVtTqcOzEk3HrXZ2dZzb0Gx78oHcRW7y9+m7OiTUNftSc+0k/eFlpGnilYaWb+XDvzR94z1 g74X98VVF+MCWOR7b3dWv6Gvl7isfPXmxfMHma0duu72XfHSu810i0K5/qLKxcoGryu93s7JP/lI q2iB1/FWF+clLLGIj87Ve6v/0vtq+GmTL34GZwrm7G+/PSXYt1fBoDPvHq8d5ns7V9K7l21A7Y0t l+V2MR8Ll2hV1URWbyiwOnDcUoOEzl1+89eC95qmqqFOi19NbN234sJ930fnk5fq+J3ooB1we5FB n7nWB0oceuk/12ihB0bd7jDS+GzOT6rPp5M5A6KJlpdzqrnHyoQLb6JOHn4at3bowqGTF2fntfKA I+rOrQ1XSyzq+MzatuXxXxIcNWtjt3UNl78bvD3bXjvUkGTd1rgTUht71u3ypZaPU35UKr/0wepu 66zVm9U+aLXvUVL17v6GNLcK5dHuoaN7eJW6PPV6VpaUcl3NQTVaP13WupL43H6Y/+Ghu0ZJSM6X gdo2qQeR8cTKJT3bRx5ZNG/JiezrucZbsN/KlwVbMiOmCmOsK5LGAoOlJa+1J/2mPbXtnpnnxhS7 y2xX3HoQ73wNTAlyv3B25ondOu9JQvbhtc5bJT3GfInMXVqpUaxR7jhQ5eoRZ1HOK1N+v/jKb+0I B8Zv/f8Gv0VH0UGkxO5gzwbAdjK2qhgG0wHwf637+1f0XpMfte3uTY+FFqljbXTv7698cHT5oDYD S87e1vFqq/78wvoLniWJolGzGuUrPkta9FncymXhlhw/0fQGGPto0v6ns5TV64hSzstZp1ufsm87 Y9Xr2nB9q4+TqmcaPKn2Wpt/uI33yez3vc+pnvffer7URang3bqoReHXzG65eZdmnn9o5mbTfnPm gCGDhSpo9WHM/PlizIw3w8VV76dcXVb2yHjZlLcXtd6o7PKOHlzee/4aD9DXPaxZe/Ow4mVVl/iM vgXvpq1v5t5cVb5m2rMhyZ+5FQYDVaYDDdHt2a47bdwqfrT2WbPVMLmnbMLp3Ltdpi7KD5TsMMDb PtblbufOmvTz+fIOHfnBSPqV3ptojaz/Z/T+bsfwD/TWaEpvugWIGTn18M2YL2Zkfx+/+cGFgX97 85RrpJRo5/fNKyrxHDesVlnLJvT/Gur/S11ZWtcay7KO+MFeHW8/Li+ZcPNsyqD+3DabxPiR0YLW prMHJs3bbXNZs2BOdNDuoZJTXkZaA5ffntijcmjF1mEr9O8bcJmbK5Jfzz7/tAv3vPLAPDV0PNuj 8qV3i9sDNi2sqs4ecyX98C+LX/O20+HjBRZtTeI+/PaxKnm5Da5Trozbp+O1au5YtYQlu/M7rQy3 PjqIPAny666dM9uoe6Wynt2707K+STJnywTp8Sdxzl+mq2nd/UEtcO7La7tb1njNTjvawdJ/7cGa fZOlLpMueycYPxdPViSH+o3kWqo1JxdvNM/5teuesGFl1rbV76Znnh7k+2hV3OKozZ08L/+WcnCj zsQg8xcFueYO/AS9oBPOhtGt5S+lP1lVnHMte/ju6eQdDwqLEzvs9joa30bTNEnadfCc+BFurs33 lZWV9g8/vsblS3qKcfrqFmLYIxdNf73jq02Mz7s+tnxcUetx2urydbt0T1MLj7YBI574vlh3Z/mq k51j92e0T+SbPU8yPpgrP9zeZ+e2Mc6z8pMCy2PytdYd3Oj+UjP2U5Zd1PbPdwcdn9PmRNj+VQYz NEMkztZbh8/bXWX8cEfpyeDyZB90uafNwM2LS4uSN5XlLR2v9/PCGVrjTWztilVi8kbOaXcw78W0 k8ZXawwHnFjxvM+9Oi40dpZ08vHI47/EPFm/7KzM/As5OtLvev9W+dff267ubjNEe+wJrbWfZHIl KmGl9RKOE6nc/nv95e9P1f4+45uX8aOiu9bQflWhTGg6nUwL8PuaVEbEpntbKDqDXw9UklEoba+t KLA0PDX3hwDT35a3fzdqkpFbrhjS5BBB5iv65Fmkm4H+IBIEgwQQy2akw0AiMAI+IAXE0bVwuj2Q xiJASr5pets/FWtiSlxseEJgXESK0TdfKkpyDvhLg8ZHtXuKjlpcy6qJUZ5yz6r22cwPe0JTFtY6 Wj0wR2v3+KSblTqvd3xoe39bzAQ10uWE/b3JKgtuns22mTXAV6y8UnZ9hDw4WTeqS+yQS3M3TW6n dUIjvp91dHHEgJrhR98l3N1jP+x4r+COVstvxA9VKgx1uD/N9uazFxNXDl6hWT2w3TWNuztvPf5i e9MxdXisu/kkh0UWm4qHL7K1BwvCUtepx/Q02Rs6eGZMXVV1XanbpxYvkjIdFh855fqhPO2u594h s6fl5/J9KuM1JtxzdFVd72o9b/aJtFJfXanTIJ2K7qNLQeQNqSwpiy/Y+dgycsWr4mzt+zLzTUmr PuyR3t5gXBuzcly+XGImyiVtf79GvEwuoYNMSTPWKuf+13oB35+ha9ImR4k6TZuk9PefQTj64Y17 kExdMZsmk4lOdJzaUeY44h9a5F2jsGdLdBOmWKnXkrhXU3u32Kk1+RteK9qKq900/47a426dGb// VILyD5mmsZWpbtL5/P8E6AAX/0RUVrjPVxRuF6IYu6UBEQoQvcUO7pBGtViBIzLTea6rMM5kIQsv jsoKfp63VWi8om7TlEUyd60BCf0Ba9pnsmWNUFC7ZeqY6bKp59ihteTNzOIpsOjyYReYkQNF9aAR b7cApyCNZLSMMrxPtrryaEK47Pu8cVFwBAyebWvEb2ImEYFky83hZAfthqinRmiQVcjZ+6w1PEbH zOZ3OQiLL72i5I6QGAr8lYRhjj61mbPbnZfsU4iSEp63ao9DA5W/78h+sHTCGtv3lglcM6PHY7gY ANaYdVmumlbwHfILALY2ZEdBjlFE8UQPAKxMDQplbmRzdHJlYW0NCmVuZG9iag0KMTQ1IDAgb2Jq DQo8PC9UeXBlL01ldGFkYXRhL1N1YnR5cGUvWE1ML0xlbmd0aCAxNDYzPj4NCnN0cmVhbQ0KPD94 cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz48eDp4bXBt ZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSIzLjEtNzAxIj4KPHJkZjpSREYg eG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4K PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wLyI+CjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjph Ym91dD0iIiAgeG1sbnM6eG1wUmlnaHRzPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvcmln aHRzLyI+Cjx4bXBSaWdodHM6TWFya2VkPlRydWU8L3htcFJpZ2h0czpNYXJrZWQ+PC9yZGY6RGVz Y3JpcHRpb24+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPC9yZGY6 UkRGPjwveDp4bXBtZXRhPjw/eHBhY2tldCBlbmQ9InciPz4NCmVuZHN0cmVhbQ0KZW5kb2JqDQox NDYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjI1Pj4NCnN0cmVhbQ0KeJxd kMFqwzAMhu9+Ch27Q3G6S3sIga1jkEO7smwP4NhKZlhkoziHvP1kL3QwgQ3y/3/it/S5fWnJJ9A3 DrbDBIMnxziHhS1Cj6MndajAeZu2rtx2MlFpgbt1Tji1NARV16DfRZwTr7B7cqHHB6Xf2CF7GmH3 ee6k75YYv3FCSlCppgGHgwy6mHg1E4Iu2L51ovu07oX5c3ysEeGx9IffMDY4nKOxyIZGVHUl1UD9 KtUoJPdP36h+sF+Gs/t4yu7q+Vjc23vm8vfuoezCLHnKDkqQHMET3tcUQ8xUPj8UIW9QDQplbmRz dHJlYW0NCmVuZG9iag0KMTQ3IDAgb2JqDQo8PC9NZXRhZGF0YSAxNDggMCBSL0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMTIyMjAvTGVuZ3RoMSAyNDMzMj4+DQpzdHJlYW0NCniczHsJXFRV+/9z 7p2NYRv2TeDCsG8zgAso6iDghqICKqglwzDAKDATM4ComVK54BJvlpYt8qr1prYMLomZW9nmq+35 y6xM5VUrLSuXTOH+n3tmMDAM7NP7+b/ncr/3Oc9ZnuU858w5wx0gAOCOIAIuM2/MqONxcQEAGTsA AgrG5eeNnv4VsxcLLVjr0IQ8VVLhiz/KAMgLmJ8yJXN8QV3x/W0A4hS8L+gqtaa4R+PaAQJXYJ1p uloLF3PoxsMAkTexXFRqKqu8Z/B5FiDoPObXl2nNJvADB5S3CftTlFXUl4LDgccA4jErPlReUjln zOQXngFwDEMly8v12pJPt2iWYd9xWGGgwHBtZodivgTzYeWVljkho5lvARjMMpYKo0579OKRGQBJ h7BOQ6V2jonxlgj6L8UKXJW2Un9KMXE2QP/RAK5pJqPZwocB9pXxkFBuqtabpmx+bjh2jfVZMwi+ EgOszrsyaaZr2hVZIHaFaePo14cIz4OjUsU83zFMdk7miFlHWl9I+JQ5dgxDnNKx9WaC7Nytks40 l3IOQApVXTBAASqYjNQP4vW2PkRHSRNKl4nXiZMxG257ss1Qyrg7sWIxYYhUwoilt/UM+eMzONBc 4i7tEq/oGEmSZY7kjYW3SkVHoYwSv9nyzBZoE+8A7e29/K8maSCE/7f6Zi9D1l9pJyoBw9+ty19N 7Msw6/+3Dj2kA1JC4PG78O70ntnt3XJre++npO8ie0sEWCJmWZx3hE5nX3r9KuNBBjK+A9c1B0Q5 yBEdwRHRCZz4dnAGZ0QXcEF0BVf+Js51BaIbuCG6gzuiB3ggeoInohd48zfAm6IP+CCiHP43XDn9 EP3BHzEAAvjr0A/6IQZCEHKCEK9DMAQjcsAhhkAIYiiEIipByf8KYRCGGA4RiBEUIyGSvwZREIUY DdGIMRCDGAux/FWIgzjEeEhATAAVooqiGtT8FUiERMQkSEJMhmT+MvSH/kgPgIFID4RBiIMopkAK Yiqk8r/AYBiMOASGIKZBGv8zDIVhiMNgOOJw0PA/gQbxZ0iHdMQRMAIxAzKQnwmZiFkwEnEkjOIv wSgYjTia4hgYgzgWxiJmQzbiOBiHOB5y+B8hByYgToCJiBNhEv8DTKKYC7mIeZCHmA/5iJNhCn8R psBUxKlQgFgAhYiFFKfBNP4Chud0xBkwA/EeuBfxXpjJfw8zoQixCLSIWsTvoBiKkdaBDrEESpCj h1LEUihDLINy/lsoBwOiAWYhzkI8D7NhNmIFVCBWQhV/DqrAiLQRTIgmuA8590E1YjVFM5gRLWBB rIFa/izUQh1iHcxBnAP1iPUwF3EuzOP/A/Mozof5iPfDAsQF8ADiA7CQb4OFsAhxETQgNsCD/Bl4 kOJD8BDiw7AYcTEsQVwCSxGXwjL+NCyDRsRGWI64HPEUrIAViCthJeIqeIT/Bh6BJsQm+Ady/gGP Iv0orEZcDY8hPoZ4Eh6HxxHXwFrEtfAE/zU8AU8iPgnrENfBU4hPwdP8V/A04tfwDDyD9LOwHun1 0Ix0M/wT8Z+wAXEDbOS/hI2wCXETPIf4HMXn4V+I/4IXEF+AzYibYQt/ArbAVsSt8CL/BbwILyH9 EuIX8DK8gvgKWBGt0MIfhxbYhrgNtiNuhx2IO2An/znshFcRX4VdiLugFbEVdiPuhtf4/4PXYA/i Hngd8XXYyx+DvbAPcR/sR85+OID0ATiIeBDeQHwD3uQ/gzfhEOIheAvxLXib/xTehncQ34F3kfMu vIf0e3AY8TD8G/HfcATxCBxFPArvI74PH/KfwAcUP4SPED+Cj/mP4WP4BPET+BTxU/iM/wg+g2NI H4PPEf8P8SP4HI4jHocvEL+AE/yHcAK+RPwSvkL8Cr7mP4Cv4RvEk3AK8RvE9+EUnEb6NJxBPANt yGmD/yD+B84inoXz/FE4B98inqf4LXzHH4Hv4HvE7+EC4gW4iHgRfkD8AS4h/gg/8f+GS/Az0j9R /Bl+Qc4vcBnxMlzhD8MVuIr0VfgV6WtwHfFX+A3xOuJ7uO+5gfQNuIl4E9qR0w4d/LvQQQCRJwRR WNtx/+solwqL/h92WHdO8p7Z4m65PvQn7r1KH5OTzQaHvrf437PB2UmGG+S7scGpZ3Z3lWS99yPp u8hekquLA9ogcux7C5ee2d217oNP/j4bFK7yu7TBtWe2w5/kekx9GKo+Jjdqg9i57y3+92zwcHNE GyR3YYNbz2z5n+R6THcxBXtJXp7OwILkDs7tKXn2zHb8k1yPqQ9m9jH5erugDbI7OLen5N0zu/ty 1YdxvYsp2EsK8FWgDQ4efW/h2zO7u9Z9GNe7CN9eUmCAG4jAwavvLQJ6ZndfchW99/P32cAFeqAN cp++twjsma3olutDbN7hc+YvpJAgT7TB8S5sCOqZreiW64MNd7GM9JLCld64TXC8Q4D0lJQ9s927 5e6weHVNd7GM9JJiIvzQBpc7BEhPKaJndnet77B4dU13sYz0khKi++HOxSWk7y2ie2Z319qv9376 MFR9TEnxQWiD4g4B0lOK75ndfcntQ2zexRTsJQ1M4nCz7xbZ9xZJPbO7a32Hid813eFz5i+kwQOU aIP7HQKkpzSgZ3a/brng3vu5i2Wkl5QxNAp3kF6qvrcY2jOb65YL672fPpjZx5SdGY87SN87OLen lNkzu/t/AKJ67ye07yJ7SXnZSbiD9B/S9xbZPbO7R+MdJn7XdIc1+i+kGXmDcAcZmN73Fnk9s7tr ndh7PzF9F9lLKilIw21z8Ki+tyjoma3ulhvYez8JfRfZe2Ls/xn0xE04JuKPtwS6/iMR/vC/QyEv uotvV9Q9s7u7bnLf+7tzmvN3dEKTCDQgnIuEL35El0Ivjb9Ucqn60i6eB7gU8nvO9Yz9Oni7lzSa /OHDhqYNGZyaMmhA/+SkRLUqIT4uNiY6KjIiPEwZGsIFBwX2C/D38/Xx9vL0cHdTuLo4OznKHWRS iVjEMgTispQjizhrRJFVFKEcPTpeyCu1yNB2YRRZOWSN7F7HyhXRalz3mhqsWXpbTY2tpuZWTaLg 0iAtPo7LUnLWo5lKrpVMm1SA9MpMZSFnvUjp8ZQWRdCMM2ZCQrAFl+VbnslZSRGXZR1ZW96YVZSJ /bU4yjOUGXp5fBy0yB2RdETK6qM0tRCfYYQSjE/W4BYGZM6oldVfmZll9VNmCipY2fAsbYl14qSC rMyAkJDC+DgrydApi62gHGF1jaVVIIOKsUoyrFIqhjMI5sByriXuQOOKVgUUF8U6lShLtDMKrKy2 UJDhFotyM60+c9t8f89i5+4ZBUu6lgawjVm+Bk7INjYu4azNkwq6loYIWFiIfWBbJnxkUeNIFL0C vZidx6E05uHCAit5GEVygiWCVTb79MosgVM0i7M6KEcoyxtnFeHY+DdaIbc+ZJu/v2Y3/w34Z3GN +QXKEOvwAGWhNrNfiyc05tZv99Nwft1L4uNaFG42x7a4uNoJJ+euhP5WGaVodYHKzr3lWSJopByD EWHldBxqUqBEm1IE0KdAoy4Fq2EqJNjKWoIjYrA6ZBQ1KgYLfKG9VRyuUHKNVwAjQHnxQneO1s6R hCuugEAKcXIr1rC8k7bGxlpjYoQQkWbgmKKOw2h+QHxcbSuTrjQpOHyg+2Ai+lZbOFiF7g8JEQZ4 easGijFjXTipwJbnoDhgG2hUsYVWpkgoOdBZ4jVZKFnYWXKreZESI3kHncxeVlnErT9XhbdHVvlg K/H+k2K9rTw7T5k9aVoBl9VYZPdtdn63nK085VaZnbJ6ZBSwAYydYgJYWopBOeNWZSFT4GQVheOf hAZ1SatUhlFJOYQbaVUUjbZhoTwkpI+NWvlLQiv6+L2ZXU3r4Nju+SHd8t3Uc2pkUWFRBJOdP62x Ud6tDCf4iBYlWTqpRUOW5k0r2K3AveDS/IJtDGEyikYUtoRhWcFuDpdOymVucYUcJ+Qgm2DAbmNk tChgNy7RC2mpiDJoXtdKgPJknTwCulbGxlNQHqZ4aMl3T/dkIvGKYCLASLyx3kyKEygOp6gSkFFt UwUHtzIJ25qFR9y2wGh8hGkcT/kHJ0a6B6dFCnkfzZCK6OBvtvgFn8J7a2RS8NK0pOAH8VbhXYt5 oV7kluhgY6Sx0rjYuEQ0CLyF06G7m0zTSs68OtnTwdNhUFMr2a9JlTbtlTZtlzaVSZtKpE1TpU0j pU0DpU0J0qZYaVO4tClM6ilzlylkLjInmVwmk0lkIhkjA5lnK/+NJlb4jPaUKISHRCSgiNIKRkDh hR8MYIbIGBgLVg82m8nOG0GyrQd0kF3MWa/mKVuJHEdWrBxBrO7ZkJ0/wteaEpvdKuVzrYNis63S idMLWghZVYhcK7MUPZ5f0Ep4gfVwgLCI7gZC+IdXBtifhYXgXTvcd7j7MLfUkZk9QJEdY39PvrFd U/bE+tchmNTgMSqYWLZLg1dLBW4ecpsot0ngNlGub6B1TXZegXVLYKE1SSD4wEKyPX2nZp6w7hYp s/R4F1mX15b7WhcWc1yLZqd9QY4oKtaVC0+t3rpTqc+0apSZXEv6vB6K5wnF6crMFpiXlV/QMk+j z9yWrknPUmozC3dDDiluiVnVTdyyTnG7IYYU/7HHVlIsdBkjSMxZ1YPEVUJxjiBxlSBxlSAxR5ND JWYZhAGcWNAigxGFONnpczvjKMexKAoIKRzhrTANowMzJMR3QcBrIuGFOkdc+5zwc9QZb6EoPj0+ XSjCgBGKXISPWHuR74IhIQGvkRfsRQpkuylHQGxN7G3JLCTwzTJkCjdqsps/wCzc5h6cFFsYC+J7 IFE8DoLx7sc+JhxO+VP2u62jkL8ong3Kjln8l5HC12k77LctafHMdS+eWcbCG3AJ9pEYmAgH+A9B BwVMHZ4DxsIjsAsOwNd4ZCvBEPcn84Hjn4YVeGx5EJohVeTP74RxcF7mCt546hxMjCABLyiDZ8mX MAYPSfEwBLeky6AacRLyr5EULCF42LoHpT8GT8E+eB9Ogh/2mADHiJRc4/dABh5NdDAPdsPX4hHi 5eAB/4B/wWY4CP8hCWQT+Y79gd/JH+G/x1bReEIZCNOFNzLgUfgn1vsX/JtRsht5f34e/wL/Lp7v M2ErWn0Q3kJZVwlHphAd8zxb3/EbX8VvpTtSL0F7vNLRmhywwHNY8xjcIA54NeA6OZzRdbjxPsJM wbN2LOo3GSphASyFlWjFOlgPr8B5MpyUk6PkB8aZWcjsF0+U5khzHPa3f8aP4q8Kbw1BCGo7FWbj jnqB8IYErMGW/0RZh/C6BO1kIBlChpExJJc8QhaT58ivTCxzgrnBurCubBxbyBax89nT7HWZuH1C x9qOD/mJ/Bz0JS5H6M9w9Fom5MMMMIEZ6mA+LETtVuHVhN7bipcV/bkfrzfhKziD11k4DxcIQ8Ro o5zE4KXGawjRkLFkMplJyoiZrCWvklayj7xFviOXmf7MQCaVmcDkMmWMibEwTYyVaWH2M23ML6jl YDaLNbMPsFvZN9h32Y/ZLzDqx4q0IoOoRvSYyCr6THRJdFnUIQaxEq8EsVbc3L6hI7tjOh/BD+GL +ZV8E17n0cdBwttMEIn2TMRR1Qlv1aBVJrgPr3r03cNo0Rp4Fn0neO9VaIXXMUrfEN6hgA/hC7Tv KzgtvCWAzhHs8yIhJJ4kon+HklF4TcNxqiXzyUKyiqxDP7eQnXgdIF+ilR1o4RSmkLmXqWXmMyuZ tcxTzG7mAHMMR4JnJTgSvuwoNpudyk5n72Ut7Br2CfZJ9ll2PdvKHmDfFjGiwaKJomrRg6Im0QbR K6J3RJ+IvhSrxUPEjXhZxTvFe8VnJe6SAEl/SZ6kVSqR1cvOyTpgO7wDLbDz9iMTWUoUpAVeIudY EbuQOcIUMI7MMdIg+oBE4gikERCvgir4GTUMJB8zg8hUVkemof8aSCmZDs+w/dgN7Fg4Iq4ieexE UgJ5orVwU/wmaMWNzDaWETey7eQ6sxXKYRUzu30zX0hcII9sYp7HiLkf0iBa5A/HmFTRbhLORDP7 pS+TVhgmlbCp7GCZK+Y2sWdQzTyZK/kOtOxpnD+ncG7lMs/jmnCWfCmdgNq1s69gnfthGNnU4Qab xYVMEenHbCLj2h9s/5x9il9P/JjTAO1u7elMBkbcZH4Lsw9+hLUd10XfwD7mBEzGVUNHZ87POPfq cKWZAjcZZ5xPebiOmHBtKsPjZRmen1mMnyGaIIlUh6c9sUjHglwi1rEs4+8gFekI+MmiU3xjcxSX 08a3p+UorqaNV7SnwfC09jThTlQnu4W4hYe4hZSJ4CbHHripEcMN4EQH6OvIfBucxvXUCXxh0C4g zh5SHKFWsmCHd6LC0b+VBGqc5P2dE0X9PWb66Vf4xiqutrW3tcHw9qtpw4mbe2pqotpDyUYM6D8w OQkPqFIPT4ky1J59KKJAMkKlThcz6Qnx6enxCemkjI0d4JUxbtw4v5gbbyakpyckaDS216Lx+Izr vRTn/WbNuBRIYUaLykWtII6Xp8nHyWfIK+Tz5RKQyYnUQS6ROohBxrBOIkc8BIsC5RJPuVxCGJYN lBMkCUgDZQ4OEjE6TN7KWHZoRKzcaT9zH+5mXsLVTowoJ9e3OwqO81NcbvO/eNEXPeZ/cXhaWlqq Ct0mXpIQu+T+Q0sSfIUHcU8VLuFPmpaGf4lquIfcQzySiZIke4hDCHtmc0n73vL2PeVbmefbHyLD 2f1k5W87xOM6zLr2INupX/IhWqiC45r4UaqpqlrVYpXIVRnkEBoarAzyCw2NVwZFhoYyyiBZqFKh DPIKVXLKoIhQZSv/j10+oOJ8E1SqVmLUaHx8PX18fL2xz0gfbyS9vdGBKh+VL+cTzyT4ENbP19uL UUVGOOBOT/UZ5Pkk+vj4cwnxkcHcEVfCCJ3IFa5+6sQjIek7cQeVQ0MHo0aInyx95lmMoLMg+CIt TUCfVGGo3VLdBCe4pXZzTecOLFFN7gkhbp4+3snJXiEDkpMGDRzg1j9CqRwQQkiIlzJUKvG6rZSw Ye2XA8Inqjui1FPCvHOm+eL6dYG0kYWqqWHe/cInqtoPqKcqvduviMw359wfHBMe3p+rZmstueE3 Toho5mbjLfaKG8tsEX2KnYUrSDQMghpN0NwYEh3bDxfNGJTYnw1wTo6PCWCBEatDw5SurSRE4+yd JCPqJKVjKjrJqZVIdyUv5a5E+CWJcXurcYxXRfilpF4JiSmnjhp/8fJFRfvFthzBTTB8/MXhFy8q 0tLcqIt8UmlcRERG2GaA8JUNTgfMRkYoQyVent4+3gIPbFNkoI9E4CUnoWZYg7RGJayesmbj3lkj EsO93fzmhak0hTNnvXouN7fj230vfnvv6588/czTpfOWq0L92ZmRyvvmDcipHR0/LFQtd13s7jM+ Ia6ycllt7YqjHScvWQ3vNUj839y1a/+76/IeVYdRz3SMxJXTijM9Cl7URAVpAr2GySAgMGy6szQw yctR5BLjwy11u+rANhHiFyVqikqTOfhFtxKXllU48TFGLrahqYo2tB9Np7a7CQtARr0mLihS7hkR 7hoeGuEREe4UFQ6OcqULF06CPBEiHcPCSYgCIdg9MBwwWkhsrCKNxs2iRTAmv17j7t0vIMIn3N83 cLWon7ffatSSYA2h7qJBuK4oB9J4GmT3qpS6lfX0tnsvgsbX4eCtXhJ5Q8Pbp2unG1efmjQibmBi Q979L89+foY5KXhQzbWHNVGZZcyiDx56cMOC9dvXvu3rRqYvq8g+tPmB4+WFA161fWf5CXOCfRkc IWQ3sGSHxsVBCv7OEj8n5x9DhPUiNqdNQUceI77LYsecOLb2iWPHnlh7jEm3PY+B8E8m21UL5/4b F3nqbi4m6k+uPX/Ldfp/66Ibjv5M7a1vXWdA5/fUwh5Tb6cZ/Nx52E6zuHLMsNOiLnXE+Bm5wk7j 5xA8YadluJdvttMOuB/ebqflhINP7bQjJJHLdtoJkpkIO+1M1jKFdtoFEthLwrfrIlydwEkURGmx 8IsbUQKlJZQ/jNJSyh9LaRmlp1FaePGpVTTLThNwEve30wy4iC12moVccaidFnWpIwZfcYOdloBC vM5OyyBCvMVOO8AI8Yd2Ws5oJO522hFKZLl22glKZa/aaWemzaGfnXaBGU5AaXkXG4WXxBROMyjt 1IXvItBOFZRWCPo7zae0B9LuTo2U9uxS34v6wUZ7d+H70bZPUzqAyrL1GdilTnAXOozWt9kbT+lW gZZ10VnWpX+nLnwnu/759SZ9qVan5zZz+eV6bryxymhBFpdhrDYZq7UWg7GKM1XoErhMrUX7Z5XS Kyq4XENZucXM5erN+upafUlnvcF59ZXFxgpucK2+2izUTUwYpOaixht01UazsdQSnasvq6nQVk+x Fw9IUKttTcbn35KFihrLqrWm8vquLD2XWa2tM1SVcRNKSw1oRmJqSmp+ucHMlRqrLJwOQWuoMnP5 hkq9mcvR13G5xkptFTeqWq+fzem0JoNFW2HmtFUlXIWxTl+t05r1cVypoaymWm9jF2vNBh1nqqnS WWpsllqMZXpLub6aqzNYyjktCqmo0OtokbGUq9RiGYJBp63gzIayKls3ZfoqfTVyTDXoMrOem2jg dOXaaq3OgkYncNxk5JUaqzmz3mIRzOnWjdCBWWfQV1kMaCRXZ6yeTXlaMxVfaapA89Bci5HDVpyZ +k5wQQ1WMlRxZgvW1laXUKeYE8otFtNglaquri6h0u7LBOxFVW6prFBVWoQf9akqzTNt3SQI3D62 qNNXIFdPm+RMyB8zckxGev6YCTnchJHcuDEZWTl5WVz6qNysrPFZOfnOcmd5nyoVGmvQHfVcDbrI cmto0XaTvrrSYLHocZDqqeFZk8elUy8KGVO1saRGZxHsrys36Mq7tMWnoUpXUVOCTdFnJQazqQIF CC41VRvscYMOxXHpFG6sqqjnogzRnL6yWGj1e19VnbV7VIlWLxFGFAPKUm2gcdJFPDa/1dcQqkGU AaVY9JXCzKo2oNQSY11VhVHbVSgqrbWpimGI9hppPBprLKYaC1eirxVmAtYp11eYbrPoT0dSyKkq sHGV2TaIkANGqIZKPOdV4FmyHnPFUE+c8bNmFua/FX5Dc6s8Dyz4rIISxGooYdexLexedj/eu9nX 2BchH9ubhN/qYLkOnxxsxjsfT78CPR57Enqz2GtxkEH7NlHUIt9Aa3DIqcD2CUhlUr72L/eULvwe CJ+5yCnD1hYw05wen3qsW4tY8of+BqOl9WhzMfKE1oNpvWps09lvImo3CNRIRWFrA2pbjSVmvEux l2gqoQxqsLXgqSm3tR6ArdV4dZUyHq37o102jxqxr2p6Ei/H/J1q6am/hHp1KKkK23AwAfUppfrp qdapkIK34EcD9UQp7cuClM5OaWlbM+3VgNrpKZ2DzzrqOSONBcGKUShLj9ds2lrQzkDbV9AWtjjh MGfEloL9Qh3B63FUroH6p9ref2ftYlpH0FeIghrk6rDPmm5jaqH+0OOznPbLUXuFHEcjRUf9WYFl ui6thJHhqO62dpX2PnVUY45KLbNb3qmNIKWKyrDVMVGNTXSkBX9OxDaCvHI6yloqzzbSQuxyMNle r5TGJUdzFirVNjp31qZTAzNyDFQLobTU7pk62t/sLvW0dr1t1lfSGWQbPdvoCj7j7LKEXn+Pu84o qLH3ZKDeMnef6V0iRbCtnFphwnmhwquOXgnYY/e4TLDroqL1K1GWCtGCdbRUMyFnhpndtEm4Vffv lSFEYIW9rr6LlBycIfkwBkbinYGrhUBPQK4wc0YijqP8LOTkIQrrySicA1l4jafcfHAGOb0LqQ9t Y1qPzxr72Ft6mGu20TLRWKmksWuh65AQ//VdxikLI2gcyvw9gjpLTHS9KUEpOtqjbdTqqCwdnQk9 ybXlDXRWVWDbErtUW3SU0HITXbPqu8SWIMtw2yphiytblN9uuVCjglJR2C4an3o6vp2yetKr6g99 991Lv/decmtm2dYVC9X891WgZ+sN9lXldr2GdPGBYInNFguV1/lJI/Rvs7WErnNVdL3T3tFSm6e1 3bxqW8OMdvx9VRO8aqFrjoX2r8dPoc6V3NZPOY1qUy9j9NdnUmeZiq4mOtqj+bb507k70NI6nflT dDeh77a70HfbP9B1RRQkShRli0aJhiKmYm0t2ih4T9AsXfidLl2XhFas7dDMh9zx5+ksffPJHQjP 09qEXvSMHSC8FGl/STkgTd0QkCJxiFk8evE1ZyJlmhsCopEVzhCS6Kh2kIhjXVjGXwxqrUQeKyEi 0jCIIaLmPPUkdVwXTr8NQQv7CT/HxmsCBqCZLmB66vhhwqUO6dKZyPO9USPiiscNPHaB/+xY/4VX tj0b9e9ZzQ1eJ9UN7CG845tZhjCMYtR+v8dPrswdmXHtROVo58RNaudbqhIxKrVoOVWSnSySeDDT 0hO91B5CRubhNBW3n/rqKi5Da9IneqrdBbbUwzGzprpYW1VrwCNMoiv2hly5hyS/XFtn0ScGqgME hqOHp43BZeir6RGEHoQSg9WBQjHr4W0vpqcsi7bSJOx3M9LVQT7O6uTEJHV/NU3TfJwThWxyUvKA 1AGp09R5XZSdnJfoo/ayyXfBk6AhD89OcdyYKl1CYqw62iYotLOAiuLyOmXl4XkTt61mQWgDCe3q FSIGtoG4AvLlTAMhsPnwtk1HjnKvyO9f9uKSmks7cn46edB1f5l278aSfl/suX44eetD6mUFC1ac mP3VwGdd9390Yc7Pdc8vMKbtX/2K82vllyseO7w3N37r6KFXXv3snpkBzPrfVLODNl3buO55/3eZ Uw+Myz3jUnRB02/Bbuevh7+z4+SSvTPnzkpMYJ9c5PHCKO79RLPz1Pijc/onP+7+pPvur8tVW86e eaNxRcyby0OWlO59sGCqsWZ/2paIJfccVnilrX/ou/yD8qpDHW+N/Wq31G1t6PwTwyI/CppzYX3i ez+dDfU7cWj7qIx1/jObg5ra7r3yw/yf7t9aTB65Mt7x6w9Dp7zw+NGXl9a+/MNrzr+0jT/efKO8 +WXPIduXHNzDsBj4GxedUC/6XN1fIsOIFYulhIii1BHqsM68miz2tR8VjDqzKQFP7gbhMCucFWjs BHoQwotkagk+GALqdIEXLBqsTlEPbO7fnLRYbW+uq67o1lpli5WuoZKRnoC1aKQGhouc1PJOLViZ 2kVgugqyhFcIJagh5t1EGJmb/NQ+nfHNejjl56VjoKXEJ8YPSL5tVrCLFsHY2de/K3gjs1/isvon Y9fsb3iRHOs37qi1saDqpCx6473vHl7tcU6U6/zjqEgVpFjb3luds+7T0GKva8MHhUwwJS78aXnK ku3nz6+Fjg8mr8kJ+3hzZM7cl3dp03+Jef/ce8fv/WpP7MPDdj6z8/ipqfy+HW8tuPKB07OX1nbE fjIkNyAgJfLa8LE4h3l1A3POPo+dv4299Onn0Ut9k8QO966rXXr7PP6vzIw/Tkd1StfpOLWPQlXq eJvQiN6ECmX66l6n5LaJUaO/+qR87kO+maU19yw41LpeF8EPzXh6vluKInyy+XhNpKE9Zzc34xP5 9eaAmIuTp4RoPw860fZ68ux3fvxq4yD9qoDVTq/mBc2YXzpgprgxq6M252Tewg2LuGdeXjpjg+za f9TXfwgdNG6E/P2TbwcfOjb520XDd+ZujNtC5v68YcvKAR3rz94zS7x+6Owz+9cc6DhSdF1zTtqc +f2iSVXPxfz8aqMi6uIjX0qaF09cN2+szFkdeFjx7Oxr3xa8LNqseXJb1PlHvF9MO5NnzP5kwDM7 jSWB29fE7Rl6rv77yrnXvc9GvPTKj0/m7dLEPd5av6Xj09yt0ZYFIy6kBm2Y5X22cE9Y+eewMEOx ZOFs+5Q8rF70zl+ckk63piSDR8dk22SMU8eoo5ojmsMWh95pMlrM5nidlk4/bzr9hC7+ZAZKDvRp Bva/fQYKo7xkjumLnFzCTf+m/r0G9aH23X5r9v4D3tx79Ojbl10+56+PP5BcrHZ764ol4NNHv575 NOfRMj9r38SjD55b6PPgvyJXl3mMvHG49Yl09shTk6aLlz/wgvGXgIkBYQk/G1ZWhF7bc9j78YtO lgPldce/f7J4yUFz06/LLHOVWzc+MW9ty7VHou8bn1ATMDr9i0s7nbn8Y3XNaxt0hnaHDxov1exx eOr4dbfJEeu0SfvmMtZ5i/dteHN5aNycjwbUvv6oecb13WfHecmVR9o+/rR/whiNV5pr0dywt58r /XHNB6bvh5277Lzgy4/mb6y9z3Dw6Qmj1ANCWja84l+cFnt81ZYY6bzPfbfPmHf6meeMHWnLXlI3 iNxxCfjNtgS4wkFYnpa21O2jYVd1F05qunpMhCuAqXNu/7/qzTOsiWyN4wkJHS8QilRJaCqoTCCS 0KVIWaSFqhSBEKQoICLNAglIU0TUUKUEpCNFhKCiFOlNFMErsOBeOiJKXRWBmwACe9VnP+3dZz/l OXMyM+fMec/v/P/vmWHlEtX09ArwpuVW4ftw++FIBQU0fCt5up6EPYTcAwht/JnnjzWb6VkkAhDZ GCa+7Xqsp6cPXP28j4unt6tPAA0PCmgAiQQA9CYeZAGkrBxys/g3tOhPl3K6J7VeY0pzhoL70uL9 7YCpjLxoiZOfVknHMimrKRlw1YsmGckZMfay7i80nAJmCn1bzPrm3t0JE4pJC3Uua3APdBTrFVYe ZAffnIirrz7onJTkIpnYpXigmq3cSrJWe5xFFRN3IG+fQu60XojGcCj746TT5g6FxItk+4N+xyYT HzgpJRkLIZnEudPyxmOl+cZUEnDc9lb0+DRhNDb895wPt+kaBburzY+WRQZXK06b3TYsWskJPONj WMzXHse8DwGyvGHvin6sD2NUtlizXr7rzMKU/ZJgYfmhQsmOl+AH7Vt6WhRMWi3pCOrNEfC2UW6t +siUKQqUMVxpKYP7cV0Z2uRGLkDIAggZtHkJhhKSAEJ8MId1l9cHV+9UMZPL3PcNrq+1kb3//+NH /JMYX6cCaYK1Jno+nu/w+0qw+L/9OOdt7GXTUlnbVOljI2JaFMcQcx8tbx0oT9dpdvzw9XW7ktKJ PHkz11XxM2ot7fmD9Bd/RUarpHF4uT1ehRnxudZ87dIc5jwBN5pyvFCcz98sjZY4+BRPhkVJsOMy fzcT+oxo6eWZxxZ6aMoyrhB3fxo9dXqXydKTWWzTk/F64CscyRwhTNovYNAjTJc1G/wW8sB6ofTX ZssZvF4T1qziAWQfbO1G70emmMuV8Q0F6AMjgSO5fsO+6aAuN7Xal/JRb9VhuYfdBN36D//2Sgg6 knsU2nxCDuNhILTLkcKSca27x0xNu0PIPNurH6YYfut8Ws7LdCoVnlHFQfGmMHBjTTSqAQkXcPbV 05Gd9z76ZhKE/y4kAPJUvYBColEoJIom4KmIl5X/hgRC9h8lAxfAuWE3WCwdzrlQpYAP9T4c60sI 1WwwYvFOZzw9nL61jOVnLftZN2WpN/2um2IAYqMbAjtrnPDr4oOmRozXTQH8e5LsopGEaZ0kz9rh 0VVDa6rGM4F1r8Qllnw7EWsdUhaGrXcoxPuHAw6C6nOZenAtlKylydra3tJrcRmMX9griNikd8TG JxwNuTUz7qHXTQUfG39xAkfW8r4iuoCO+GstwjCGyziTt19UHo6iS4dwjGJKZ4+gdBbci7QX957b I9qmwb/HpAKb1J3ZxdXIr3aW4cwcCaF1UuN9TUuiE7yyFvU1Q2vswn1hmcrswQXyUDKCfdUKqW6O uVxsNT4yfTxAouB3KRlONYy/qkZQjsvIZVGX3WO/3Kz318LqkI1CI28l15y6MMW8HAa5tJR4Vlk6 xzmhfejgf6TpBNhRuvhFZVjxbLiQsCTWs50ae5BMIliK+jwkf6TDIf8MvMAYmDcNOA+VL3QQCAi6 blGF/wXlhXJLfJLWt232Nrs3upQutZt3ufazKQHg3zqFmw7KtocFZAo6T7XrmiB1gHVd+Kz7Dm2A fUtg0QMQ6s+OebmOMdzw23n6ypIpVlbUCyJSNdLxaA9TzmcHfPMhyBeMrvrz8rm9Id3DDRamueX8 ne1js+mfLSp0b+uIj+aJDAS+WuINhPXP3xCcZrItu3Lj4TWrx0LtpG7SbbmF2MG1iGQ7fT1jBUlF uKAZ+uslG55bzwaErn90wCqPMr53/hAwHdNpicOT+PTSA4fwlCHJotVmWEVjRnvjyate8639BUQP xgE8/8PcpbA6Zo2EWclC18DSWumcEmeRrOJwJvd4rsoS+cQ99JlcmMyaQkD1EeI1kN3qCBMqtowe nQ3kfGSnzIaevVV7M8IQeoLepul5b96b3y7F+u9dfuCRFcMgZ1VqJ8XJDhDp5agoE9zAGIuDdmob 7b1rEP67DMU/BRnb7FNAyaHkaW4JTdVG1OJhWhHw+Uv6sVkP+Un9n0qiDkIcpsgmY652aLCrgBTd q5wicvWZbdgh24+l3osFhRFu5X2lohdYm5uz9GPtRLkmPy+KpZQvePgWfZi5q9xUX3PcRq2g7Jyc ZLYjwSGA7LjgEUHq8vi1Ke3lXRNOX4dHXlF4chxvZI4toUvLebTfIvVI69cBX/FDWgBotPfSBRJn j5Vw5oQRa0vEQEavaeLpVlxrolvSTbtjBpwTMt3W1nYnsZnnDmY9Dj266xo/j28bU19SthfPhMG0 64rtffeY9/tN0Jirjdp6PLeNE0oWXO6+HmQ+e8on1e+a8BX3+Knxk0fb346d3fUCB7p1AZlwnfUB 15OyrpnZIcRMnr3DDFpT5dmGJCKCb1KfyPXvvMs2DGbeuOedN+0wmhE05GfYk3mn4PntlZ+QL492 VAxKIAOE1OAfUoTsc/fv4N/3YkF/w/hpARrAkXTVdOUwxR3G78y366w7Py93V9pRmc1t8nMytAlA i39q7MuuG0KjHU5UE1AH1LacKF2Y3M595O+vi/f+/oI+P/KEmDcfSJhkmwRuWzMP1yG65vGy5e46 g3syBUFmu/pkKz65je1aRgj4qWa5BD4gXY6ymdOsD0nGX4owNrlI5F4MOfc646lNK51Xp+Tp3VVY 7qzIGsoIuZ18PiX2rIpgjQXIovxTqGSfndxyr0SgXVJf9vLCnLpAobn2Pd2BWAyXFbPe7DwyXKQK et0ahodMspp0kdmiEp+8qc3tYuKRQJRXWEYKvbAOO5zVupIfPp2HVqNoug/DZ49WXS6anDW/T9at wj81Rb1pmWDAQRn8PYzXdB8nT2meCO+/xxK8eLzhwMhokPUvo7IBM6JXbrIdLDO2bqw7YmVV8LJj WKa2Y/pMGjoASYS2UbHZRAcGA4Tyfwwc/wD47TR2OmEC4N5aUPeBkYwQ+vVkO22Z3Rx6ZgiSbWfm nNr07RIr8l/AzloeQGz7RCiSOm8lB/eYdnyxAl/b/0pXBq2Fa117eAzw3nEKG9IJcEzHBMv/YOcd DtLe2mv5ya47WTJY/Kex7bP1DtL/qkkoEQxq5Zj33l3U9jWgPLFEVF86JaE9IvkeeCHIRSCfXa4c 0eO2N6ZOzTB+rJA3oANVHs1aA1GYI4nPQWSOE0JdbmDDFT1NhhOynz1CWavgGpcPmWL8jygXGX55 y5jf9q62OOP5oo5xagRMOS0eEdqVbDpthTkiDCaJKXFyrU7rpbC9qqqeTGwVDKF0XvU6OXdxyYiF tZr3dD9C1KlHGm2iXTitM3ATU8NRWuDVEZsUSRF5+UsE0FoxX239jpnFSS8ENMMy+kywIVpkJkEt SEm6U9rg3Xnzvk75EWZheJrqnI0tJJKJ/4KXa6uJSh5h8HhNSRR/pZtRM/fK1YQ4ypke+ioUlEyk yiIieHl7xBiQRPA09dAELbxP/SVJzR+kUtkYmDYaQEelTPpxgG9n7LFub+2AqaG3VUOPZKet99QF XlaW9m076gSVvztCDwblMEwUpZQPSkUJ2QMjn1fjen8QAu6mWrpvuw5ptq3Yehj0JL3XqL+jRLGQ 9D9m75Svv/dKufmxHh7N0JQvXuqBOjr1w1e7Gx6tva972bRmCQ7xL53sRwS5oh6py+SoBj44nEJ/ p77SkBsNCp9Uup5/3lka5os1JybINOGY7ldj6waffmQhr9TRzS+I95VqOvQxQDxX9RNSZ0OKq9D3 4ZppFWPD1fXjaKBeb+Xi/jnRc0NA2j2p8Z4wPiQF3hBZZ6ypMoWXU3QzA6nq5EdJJZoKAllTTg6e 2eaUbGkEe6H+4Ou1EIYsEb90gzuLBgLlkN0vPvvtbr7BcUWt9FRnZA4WJ7a6rHAixTYYeG6mMlNC mQ/pH7jxX39/QU8NCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNDggMCBvYmoNCjw8L1R5cGUvTWV0YWRh dGEvU3VidHlwZS9YTUwvTGVuZ3RoIDE0NjM+Pg0Kc3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7 vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRv YmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03MDEiPgo8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6 Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgo8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0iIiAgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4K PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiICB4bWxuczp4 bXBSaWdodHM9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9yaWdodHMvIj4KPHhtcFJpZ2h0 czpNYXJrZWQ+VHJ1ZTwveG1wUmlnaHRzOk1hcmtlZD48L3JkZjpEZXNjcmlwdGlvbj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8L3JkZjpSREY+PC94OnhtcG1ldGE+ PD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDQplbmRvYmoNCjE0OSAwIG9iag0KWyAwWyA2 MDBdICAxMjBbIDQ2MF0gXSANCmVuZG9iag0KMTUwIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDE1Pj4NCnN0cmVhbQ0KeJxjYEABDQxoAAAIoACBDQplbmRzdHJlYW0NCmVuZG9i ag0KMTUxIDAgb2JqDQpbIDI3OF0gDQplbmRvYmoNCjE1MiAwIG9iag0KPDwvTWV0YWRhdGEgMTUz IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDUxMDg5L0xlbmd0aDEgMTI5NDM2Pj4NCnN0 cmVhbQ0KeJzsfQl4VEXW9qm6t/c9ZE8n3Z0mAdKBQBKWQIZ0yAIY2UNMI4EEiCyKLAEFN8IognFB HQdxGREdFXXUziI2AYeojAuCMIrrqCyC4Mwg6Icrkvu/dbvDMuqvzzzz/X5+f5+b89apqlPLPffU qbo3EYkRUTxAptrSCSOH31Iy4FNie2OJklcNLy0rtw9ynCRqe4eIfz187JgJD5alLiZ6ZjfRkQPD J0wctqT+1UPE7m8jGuo/b0Jl+dys2VpiH55Ar2nnV04Y4RvtepGocAORbe2YCTm59n7TXyJiR1Bf O7bk/MpTVw4tQf/3Iz+gqnRU9djb53xBdL6fyHHH9Ll189fPvvZxopo9aPP69MsWuR+7/v1LiRoq ibSTLpo/c+4rW97TEE1F/7rnZtY1zKdEMqC/W9GffeYlSy/KTvloFtHSIPrrOau+bsb+d58vRF+X iPFmoSDmtrhnkf8j8t1nzV20pG6hpgP3OoJocO0l86bXTcquVIiacP+urLl1S+bHbjGPgv7L0Hdf Wje3fvGK1XcSPSYTGefMn9ewSMmiNRh/vqifv7B+/s2eo8VEMzGe6TAJW2t3TS7404rHptoKv9Cn 6EnQAx/1yBLpjqeX07dPnZppn6Ifh6xB1ReEVDe0czSV2FH/zev2KadrImS5V5TY7qD+xNUCTnbK oQAe6xaMK0iSVrFbSUN6zd2aPHSZEk6lv9JFPEav4SatzAXJ+yhL6aAlJeoMQJWjStzkJ7fWr3mj cxzL0w1lLX5iigK7yJmazeJOKVYbmRIvOM1B/jZNof8BpHmJ7vspHe1jtPYH2q3/T4wvN1D5v9OO P0Yr/hPjRylKUYpSlKIUpShFKUr/SmyD0v5Lz+Hnkibl1zPXKEUpSlH6JYmR0q4H2ykaN6MUpShF KUpRilKUohSlKEUpSlGKUpSiFKUoRSlKUYpSlKIUpShFKUpRilKUohSl/x/JcB49/J/sTz78/f/e 6l9J89L3deS//XS7KEUpSv/byHaHjjH2uPYnFc1dwmIBMd+r956T++n+ohSlX4TYT6v8G6pR+glC lPmlpxClKEUpSlGKUpSi9MvSDx2HTpf1EWD7fzaXKP2PI4kkJkgjSYzj7Jyo+aepg77WK6QnvdJJ BjIop8hIRqCJTEAzmYEWsgCtKtrICrSTDegAfof3dgewG8UAY6kbMA54kuIpFphAccBE4LeURAmQ kykJcgolA50qplIKMI2cyjfkUtFNqUAPuYDp5AZ6gV9Td/IAMygdmAn8inqQF9iTugN7USYwS0Uf 9VC+pGzqCeytYh/KAuaQD9iXegP7Ab+gXOoDzKMcYD71VU5QfxUHUD/gQMoDDqJ85b+oQMXB1B84 RMVCGgD8DQ0EDqVBwCIqUD4nPw0GFtMQ4DAqBJYAP6NS+g2wjIYCy6lIOU7DyQ8cQcXAkTQMeJ6K FVQCPJ9KgaOoXDlGo1UcQ8OBY2kEcByNVD6l8SpOoPOAlVShHKWJNApYpeIFNBpYTWOUf1KAxgIn AY/ShTQO8mSaAKyhSuAUFafSROUfVEtVwDq6ADgN+HeaTgHgDJoErKcLgRfRZOUTmqniLKoBzqYp yhGaQ7WQL1bxEqoDzqVpKL+UpgPnqTifZiiHaQHVAxfSTGCDiotolvIxLabZwMtoDvBy4CFaQhcD l9Jc4BV0KfBKFa+iecCraT7wGlqgHKRlKjZSA3A5LQL+lhYrH9G1dBnwOhVX0OXKAbqelgBX0lLg KroCeANdqeynJroKeCNdjZKbgPvpZroGeAstA66m5cBbgfvoNvot8Ha6Fvg7uk7ZS3eo+HtaAVxD K4F30irUrgXupbvoBuDd1KR8SPfQjcB76SbgH1S8j24BrqPVwPvpVuB64Af0AN0GfJBuB/6Rfgd8 iO5Q3qeH6ffK3+gRWgPcQHcCH1XxMVoLfJzuAv6J7gE+oeKTdC/wKfoDMEj3AZuB71ELrQO20v3A NnpAeZeepgeVd2ijis/QH4Ehegi4iR4Gtqu4mTYAt9Cjytv0LD0G/LOKW+lxYAf9CfgcPQF8np4E vkBPKW/RNgoC/0LNypv0ooovUQvwZWpV9tAr1AbcTk8DX6WNwB30DHAnhYCv0SbgLhV3Uzvwr7QF +Do9q7xBbwBfpz30Z+CbtBX4FnUof6W3VXyHnge+Sy8A36NtwL+p+D79BfgBvQj8kF5SdtNeFffR K8ou2k/bgQfoVeBHKh6kHcBDtBP4Mb0GPEy7ldfoiIqf0F+Bf6fXlZ30D3oD+E8Vj9Ie4Kf0lrKD jtHbwOMqfkbvAD+nd4H/Re8BT6j4Bb2vvEpf0gfAr+hD4NfA7fQN7QV+S/uAJ2k/8DsVT9FHyivU SQeBCh0CRmP6f39M/+xXHtP/8bNj+ic/EtM/+V5MP/IjMf3w92L6xz8jph88HdMXnhPTP/qRmP6R GtM/+l5MP6DG9ANnxfQDakw/oMb0A2fF9P3fi+n71Ji+T43p+36FMf3dXyim74nG9GhM/9XF9F/7 Of3XG9N/7JwejenRmP7DMf3l/wUxXXyTCbMz8qFuEXKQ2BUkIxqIv4qwo4QjupYivozHyl5I92v9 4t/0RvT9lzLlo7Ou6d8Ff/i3zUx75qsg45wi/xL5WQqYkqz5yc9JPbqEvgL6f69++Dm5iT/Z379H 0r/X7L/Nuv7y6guqJlYW+4uG/qZwyOCCQQP75+fl9uub06d3ti+rV88emRndveketyst1ZmSnJSY EB8X2y3GYbdZLWaT0aDXaTWyxBlll3nLa93BzNqgnOkdMaK3yHvrUFB3VkFt0I2i8nN1gu5aVc19 rqYfmhf9i6Y/rOk/rcns7kIq7J3tLvO6gztLve4QmzSuGvLNpd6AO3hUlUep8q2qbIHs8aCBuyxx Vqk7yGrdZcHyy2Y1ldWWortmk7HEW1Jv7J1NzUYTRBOkYIJ3fjNLGMpUgSeUDW7mpLdgUsFkb2lZ MMlbKmYQlDLK6mYEx46rLitN8XgCvbODrGS6d1qQvMOCNp+qQiXqMEFtSVCnDuOeLe6GbnQ3Z3c0 3RSy07Ran3mGd0bd5OqgVBcQYzh8GLc0mHDFwcQzWXQeU1K98uzaFKmpLHG2W2Sbmla6g/ePqz67 1iMwEEAfaMszymubyjH0TTBixQQ3RuMrAtVBtgJDusWdiLsK31+9t0yU1M5xBw3eYd5ZTXNq8WiS m4I0fqmnJTnZvwk7UXKZu6my2usJFqV4A3WlzuZYahq/tDXJ7046t6Z3drPdETZss9UWEcyWs4X6 03WqpKoLqWL8acsyMSPvSDhE0D3djZlUe3FPgwTUD6Km6YOgBgowtArOwBOZHTSU1DbZB4ty0T6o ybB73U1fEDzAe/Sf55bURUq0GfYvSIjCT067Guq75KDPF8zKEi6iK8EzxRyHqvn+vbMvC3Gvd77d jQTmo7GwbV1gcA7M7/GIB3xjyE/TkAk2jqsO5900LaWF/Dm+QJDXipqOrpq4iaKmsavmdPNaLzy5 TV3XcUF95ukfmz2+W9mswUEW/3+prg/XV0zwVoybVO0ua6qN2Lai8pxcuH7Q6bqIFOxWUi2l8IjE UyS1Fk45+bSyyFSbg3IGfrSqU88I6fTwSrWEucuD9toRYQwYPZ6f2SikHBet1ORMs8g0g4N95+aH nJM/Z3rmJgkTljN5ReWkpibjOXVwtfCAIyMJPJ4qqz3ukiBNxMrMwE9I6RgkOJAS9MNkJUIB/hcu imTPUUyJyAGQ8M7e2eUIdE1N5V53eVNtU11IaZzmddu9TZv48/z5pvlltV2OE1Lab0wJlt8UgK1m scFYFJyGNXvZqnHNfrZqwqTqTXZsAKsqq1s44yW1wwLN3VFXvcmN+K6WclEqCkXGLTJUwXCTLVyv 6qds8hM1qrWyWqDmp4cYqWX6rjJG00M8XGYPD5SpDuTHpjQ9JIdr/F3aMsr04bLGsHbPiLYeNXZR 007YO0itDJMITiWV1We7nbqWRcUFvmozb6qYgIcmKo2DUoxnVbtFwyDzBqd6l3ia0WewyrvUg0Jv 0I0AB6VmGu4MNDW5cXkx/PSq6jCKKpbtRE+BYOO0Lt0UZ8B7VtaMpuqjaHWKZXd6tCu7RluI0YTQ 1DVccPoPjobZB9mFAtUfdfrNA8gbHh8bW3jQpslNk7wexM1UMXBkHshanQG1B8xkrZgJVnexmSql bHHxdLz1uiSflIV3SJeU1aJNdYWknq2Zia7dW6RetA/MpV4tvlTXJqmHlNoyxOUPSd7WmLhcW3Fv yY0HnKOiGzgP/BR4K1imqVIayu3AZeBG8FPgreDdYJzRgKLWDZ4HXgfeJ2qkVMnZ4nbZi3tISWib BFexSQl0DKyAJcwzAaMm0BjwVPBq8DqwVtUTJfPAy8BbwcfVGr+U0HJ7Huae0HKjmrTOuSRXzdaF s5Nr1GzrBYFwOmpcOC0dGVYbHFbrlx8u7jMsnPbIDqcxGbmNIjVacjuK46V43GQ8Jj4fyPg2sjFG LrpfiqMgmEvaSIlfimntnpm7bqskE5O4xHAccykdEmuxOHKLjVzhx3CIc/FP+dFwDT/aanXkris+ jx+gp8BbwRI/gGs/30/L+D5hc2AReB14K3gX+BhYy/fh2ovrQ/4h2fgHlAMuAk8FrwNvBR8D6/gH QDt/X2wGKgq5CMz5+0A7/xtu629AG38P0nv8PUztjZaBBbmbVMGXExFcGREhISUixMTnhvjrLd/0 gkdl4knDozZL6TSU8qT0lox+cL/ElsLZrhD/qNXtc91f3JfvoSBYHOT3YOQ95AaPBdeC54O1kN6C 9BY1gm8F3w8OguFlQDvYzbeDd4Dfor5gP3gsWM93t2CYEN/VkjnMVRzPX+MvUQIsvpO/rKY7+Itq +ir/i5q+gjQN6Xb+Ykuai4pNqCe0sSO1I81BvYY/19o9xqUUO/hW2M4FzAEXgceAp4JXg7V8K09v meGKQSebabueoNlCn6jpw/SAnvxzXP7MEjigW0Dm4N9AAqxzr8vk/sw1dyErIPOW2yEJyLzuJkgC Mq9YDklA5iWXQRKQOWMOJAGZk6ZCEpA5phISIMTve6Z7D9fAMRczd7GNXw4rXQ4rXQ4rXU4yv1xc 9I0s5nZPS1YWLHa339cry9XYzhq3sMbxrPEB1ljPGq9hjctZYyFrnMIafazRyRrTWKOfNW5mg2CK RuZvOydb4E9kjdtZ4xOssYE1ZrLGDNbYnTW62UB/iHtaRuapSZmatBaLRYf0N0MRfWzcA4t64PMe xIStwF1gRc35oeRODysnpYk0vTWrKJzvMzh3HpbPC2j4Ah7DC7QXLOMBvQA3egGdvIAObMAi8FRw B/gYWAFroZ2Oia9W0QbMAReBp4KXgY+Btep0joE5zYtM8Sl1YmLSOZGJjwHL/AVc6bg83ONPtTvt PvsIabWT2dLYmDQljQ+k+HjxIufQO0LMsvEry9dfWchQbOC38NUidPNbI+nqlm8QutnalszNruI4 dielyfA8VkCZLAPpIGpQ8/3JqRdpPjn540hzW5xVaGZrycx2tTOraLXR9Y3zoOsTZ4hDPOLc7Hrb HZJZi+tNlDy+0bXHeYPrlZyQHiVbMkMMSbtbVd3kHOR6YruquhwVd7e4rhHJRtfVzuGui51qRX24 YkoDcn6ba3zmJNcI9FfqnObyN6DPja4i5xRXYVirv2iz0dUXU/CFxSxMtpdTHdSbpnY4cWCIzfJn 69boqnVjdAN0ubpsnUfn0qXqUnSx+hi9XW/Vm/VGvV6v1ct6rid9bEjZ5/eJrwCxWrtItLJAWZXt XKD4YCACH9NzOo+C3aQKXjFhGKsIdkynimnu4JcTvCFmxPFQ4x3GgjEVVFE5LDjIVxHSKeODA30V Qd3YC6ubGbslgNIgX4VjUWV1iCmiaEWKeBHbRIw5VtycItKeK24OBCgx/rKixKKYoY6C8tIfgNoI +s5Q4jlyanBNxYTq4GOpgWCuEJTUQEXwd+JNbRP7nB0vK93EPhNJoHqTNJR9XjZelEtDSwOBihCr UvXIzT6DHjzmM1VPj81Z6JFbnxbWuzusl4H20OsuEugZDJSh6mUYDKqezIRec0P3stLm7t1VnQQ3 Nag6DQnus3W2Z0AnI0PViW+k7arO9vhGoRMcqqo4nVBJc6oqLJmcqoqTJasqVWdUciIqN5xWuUEd SWJndJxhHcu+Lh3LPuj4fi7VD/P5WOuQwPTJ4i231ltWD64N3njZrERx4nI3Tw9EXn8za6dNnyXS uvpgwFtfGpzuLXU3D5n8A9WTRfUQb2kzTS6rrG6e7K8vbRniH1LmrSsNtA4fmz/wnLFuOD1W/tgf 6Gys6CxfjDV84A9UDxTVw8VYA8VYA8VYw/3D1bFI9fGx1c16GhbAS5WatnKTEf5ai6PmsHj7/KGq 8w7xJF6T0o4TywYy4R3T7B0WtIBFVe/i3sWiCmtKVFnFp4xIVeI1Qzwp7WxDpMqOYod3GPkWLW5Y TIlls0vDPw0gFC1aLAweRl/DjxHqyoL+utKGRUQVwawJFcEiHPSbdTqU1opbCg7uKjOZyvAyFS7s g8LBolCSTiuKskJRZjBEFL///BdH0hKxChr55lbmT2OLqCEgBdMqKjlCQWXknbEd5ymxRTQEcIMN zMcauvqITNvno3CexD138aLFESlii0WRNNwSTRq6THKahLF8py22SO1WNaePNO2UBE7WPEJJciYl EimHwUdE2jlbOSLqRcr/joAXijDRBnqCzaYnaCs9z46j1VO0idpIHIdK6V66iu6gldjiJqHkBhqP S4PyO1iS0kY5tB6b3HraCd0L6Bpqp3iWqHxCy2iF9AZarSALpVMxjaV5dDM7X1lMk2mvfC0NpPPp UprPGpVq5RblduWP9BBtkl5Wf/+XTNNx7VQ+1byjvE+90eL3dBftZbcbniY/RmmE5h9oId0t1chM mal8ixl46HLMQaZRtJN1cB96r6fDLJFdJZWglweVoLINWk6qoVl0N7Wz/mw492gmK6OUnRSPMZag 17uohTbiCtGz9B4za44rf1SOUxJl00jcTxu9xjqkzlPLO4tgMQ2s1IsKUDOP/kwv0W7mZc/xeRqz Jlfj11yh7KFY6kcTMdtH0PJj9hW/Btcy6UW5XBlGVtjlNmFt+gvtZ8ksh41hVbwXn8fvkxbi1Tcb bfvh+D8b9l6L3j+EO23kZr5LelB+XD6pTe3cp1jxRDLpHvoDPccsuFM3a2C/ZW+xj3gJn8rv4Qek O+RH5dd1dbjrKTSXbqbH6SsWwwaxcexCNotdxVay29hdbCfbzY7wYl7JL+bHpFnSAulZeRiuCXKD fK3mes2N2iOd1Z3bOv/a+ZWSq1xP4+APyzH739N9uLNNtIvexbWXDjANMzErLjfzsInsSlzXsJvZ A2wDe5S1YZTd7AD7BFvTF+wkx47LtTwFhyBxFPLyhTht3sHv5btw7eb/5N9ICVI63lL7S4VSQJqH Wa2UbsX1tLRfTpZ3yQrsnKtZo1mn2aB5XPO85rjWrPst9vod3z14KuvUh53UuapzTWdLZ5uyn+Lw DLGL4OWrELOvwzUHz3sNPO4peoOZYbtklsWGsvNhmalsDlvAlsCS17G72UPq3J9kW2Clt9kxzNnC neqc+/D+fBgfg2sKr+cLcCi7nbfxt/i3kk4ySTYpTsqShks1Ur20SFoqrZGC0g7pA+mA9KX0HS5F NsouOV3OlH3ycHmqvFi+Tz4sH9ZM1ryqOaQ1audqr9eGtJ/hdDNUN1Y3TlejW63bqNujr4V3vkBP 0zNnf59n+6TlUpn0NN3C8+QkvM68Bn+eSjOkURyeyjewVfxq1sa7a5Zoh/AhbDQdlzNh6xf5Ov4l HyKNYhVsAs3h/cK9aWPlx5AUyi/QUXkL7u019LxEa2bX8GNaM7Uw9f+xyv4i9ZV90qv0nrSX6eT1 9DfZyBLYUf6INBZe8Kw8VFNNHuleelJawK6mp3kZkfGk/ib48Wj2GOJCJctlX0sK3mRHw4sGSuL3 pBfzd+go1vEqupPNkGfSLZTHrqLD9DBWRS/NpdosbRx7hc+Wm3g31kZcflT8v15ZdyZpYuk6ViPd rT3G36XFtEs20ofSnzD7XfxJaZR8XDOezcIKuJqupwXKclqqqZZfZzNJYlWUIYvfnV4l5coepMsQ VSYjpm3E6m5HHCiWRqEkEZ5zPvxiIiLE3bjWIk7I8KDZWOMXIIq9Rm3aSh6imRorQ9Qhkl/tHE+T lIfpLmUmXarcTr0RD1YqV6HHDXSIVtMGtqLzSpqP18p3sbbP15TzXZpypTdv4u/yCXzNuc8X1s5g ifR3XE8iM1SzmZrkt2kCFSk3KW/Cu3siwt5F03BwPYi7/BQjjJA6KK9zNG9WyqX5uN+9NE55RHEx I81SLqExtIUe0mmoTufDMw6y13G/V1I9H68skuo7Z8MOq2EFP6y1GPHnBnmBfK38DZH6HQ6BTyN+ RaWjYW2cHdTqQvwufzfSyAclMurkg4yS9FrNQS5tgUMZEF76UKLP/mXhqcLR9hOFo04VUhFk+3eA fn09Do8jA4CzOH3nljq+82voJLnlDvEbvCDuezX2Kw0Z6Opmrfjk18JJE+JP+U36Qq3RMFgu1A5m LOfgqYNUdOrjopRmp1qbiVpOWqPpVckwWDNILqRB0JMKOXczxl41Gk3LPevX4iyNGdUUjrIftR9E Fwftn1JR0Sj7qY9xlm7V4KjD7IX2wkCgX99ukiPPIUn98+IOD9yb/+AudolkYGWdm7/7qvOOnTvF XKdIrfxyda4mWrwJm+3XrekZ+ZqQ8rU/PbNXvklrhLnxNqbRaE2fGvR6SeKk0xcabYZGAzfg7OGP s9jyDR8ySS7kzG9x5LMk84JHEsUUfcJq9lO+mkLVeGJSpwoBzBFTUCC4X1/m83UT05PyVLw1d2fv D/rt7Cu1soTjxzs/CaOY5314fpMwTxulst7+GLeLleidqWmccYc9zUb6hGK70in+9ob5qYoSlM/F X+NE5C9RbmF+v6sqIdNtYC6/xcInGtx2O9BoswET1ZKQcsJvNpu1Ew3JrlS71WQKMX9bld1osYQF 1EHwW6vsbqZ+RxQ9UEj5sk10ogqiHwjftpnNqvBVm+iPhDnRDaSatCGThVuFz0OwDLAwkq05Ko5D wsuKVCcrWeofIKXo8DaowfugrE1KTE7kWpPRbLQYJW1cfGx8t3hJmyIleFiMFZCod3pYvNHhwbEK hs0CLWc1eQ5PbkJ8QnxMXCy3cm+GJ3fAwAED+udn9sj0eu5j3zw+6ZrAoobRV9y2c0VnMyu47aF+ ZaPuvGT0E507NO1xqedP69y17ZHOzkfrcp8Y0K/sk4c//ipLfCtdi3hrw/OwSzmt+ixT2EIcwiZh 9GYunH4T6ZUv/SZhCr3V4uATeUj5tE0I8K9P/T2FZI4R1RqbWTIQ43qDyUp6AzeatMK2Jruwpwn2 3Ci0THYY8uO2iNW/7rL6d2Gr58B4O1XAaujosO/e3eGISSjw+VQv81FKeCX6XTq3yaSdqFVRUlFW UaOiPqR87vcKiZtVDa14gtyq+oXqHUYVdWIG4pHqxcN1CSlTw8xuY0y+TQWNWSJmNZFez7hR3Ljo TRXUTjbzKvErb17lt5A6EGm7XEXtlpi4lxM5J1SXKCosDN9MTfhuzjqUp/iXEbfpY3mKXr7MfL35 ZZjSPNI80ib1kjMs2dZq6UL5MssS60qL3sQ1+gLLAOsYXiGV6vz6UZZhVuNafpe0RrdGv0F6RKeN 4Tarta+Gx2o0XG+2WPpq9BD15vG28czPONfrDUaTyWKxWu3iOdXGNMbwmHa+AeurX4vGrQ+xfk+b DQhU4bVjNIaXjKHK6Pabl5mYqR23bWUm6PIQEhujYiMWaNdiJXWxYhE/U0Vu23w7s4d41TNuTa2m USMhRm5odQwJJPqSEP8QARNPicVzNDnJfhS55LOyB2sosaioUI05XVey/ejRlZo+vpVXb1vZJ1Ek /friXcqEd6k0vEs9S2blJDz2LeLKW4MGDQqwiqAZdT3HTQrykqB/7CQ4tEX5utlqFJXqa5VF2bPR U2DN9hRYQhAHFlhzB6ri071R2rsg/JwCCxfU0IIaVhPAC5YP65HFJwwYyDwOrwNnb8daHAQu7Buf 1B9HOM3mzqqnOqs17Sc/v23E2Huk774tl1892V/ed9ItouB6RMEnsOoSKZ2P9XtiTFYWM8A5yXWR fq5LNthVd1RRp2J3xGc1EmFKJ1TB3CWYuoSYkHKgNSY5H+nx1vQe+Q6RT+2Rb4+ktkiK+ndaUzPD 9dC3R1JR7x8JIcN6nvM89wTTZOdc50LDEutS2wrjKtudlkdtIdsR62GbHUvI7bDFOhw2h81siMEJ OjneqI1x2C1mTaLBEJ+QnJSW8Gel46zIjd1FLI2EBPKki1hPiYk2m1Wfdk6wTzsr2Kd1Bfunq9Iy rfdqQ8oRNUxou4KzVnxRSxI3rtUKE2lr3N3nd2/sLnVPT+Sqs7ZVJXaF/kSj2RKO+Ik/GfHDcY60 6lL+ocDvHbIhvCt2hf5R4dhfowb/pIOJkegvXFXE/5gCBADsn4UFOVj5zJFQsNLax6e52g63ZTXn vFaLQFADh/Qb9X5bgc0+2BEzWPgdW6B6qVX50J+cVOBITyqIAVv9zgJ7eizYBY6LOKkvIDaK+Pi4 WK0Ou0VCN6/Uh2OL8DpQrO4XXs963rRtxxXb3xjVc+L5yonnJ156QW9PxX62fsWa0Xc+2NlX0z7m 5aX3vpWa0X304s4FrN91Nw0y6U4tlvIGLh0+63rhv+XKEWkv/NeBXfyQ/yojly0ZlnxLqUXTP7a/ 8wJeaRwfO8E5k8/Q1Bumx9Y6O1x7NG92+yDpULdDsccS/pF0KHWfS3HFu1y+5ML4wuSK5PmuW126 Pry7pU/8YN7fUsHLLOWxI50XGKssMy2HtIfjv2UnrHYWJ1lNdhulOE06BxnjnJIpEWHna/FXuqrb JEJW3QnPPI/R5i6PasMx22GDt51RtSknTnuerUvP373KlmG373Ywu8PvqHU0OmSX32TiE8NnDUeM 8BuHOF84hOM4tFYrUD11OMR+YxJe47Da7VqRD+8Qjq6dwLG5a3YbqxyLYvSR40iMOeKuMWF33VgV 011nj5SJ9S88d0jVVt0u3V6dopNduiLdGJ2kSxPz0iUKb9WliRno1O1HZ1bjRrK6tyWl5Y89y1lr Fvh8o4R7njrL6WoWINYixQGv8KDw3KPYpsAOcbRDZK1hIup5+mu96ZmZ/fNjBuTlxifgOMpi4/Ny VX9K10qD6rcte3PxnD3X1q7JaT3l/tPiyx7acOWS9dffd9PJB9cxqWlcMbd+W85jdmx/7sX3dmwT n7pXwJFelIfChw77h+R0Y3aZeeV8uQSv/RfJi2StwaE36A2Wbg6DhSQ9Mzm1OqYlo6HnrXqmT3d3 Y914uqNrhTu6rOnosqYjg5E41trzBuQfF1/W3ST+tlFWN+auo4ffIR4gyV1LPnIOEc+PxFOOt9lO b+h6dfmPjhm+7cy5TzWpevY7aK85sRBvAUVFRx04FBcUqIdjsr+y0qruTzULxQkuL24AzJegEzbT aeMcKx4YOrvowilDhw0bMiU2Tc5cv2DE4Ed6DC+qXXhqD2yktOO9awN7A287ic8S58dwtPoHzHa8 WcNy7BjtKEKIp7+HbeiMYZ+yjCcjbTQpP91Gk/LtOk3dmTaMfqzNoTPjUGc7Kz/TRv8z2ujpq3b9 WW3sP6ONnY612yNtxL+8p39S8wbl0xx/6Yp+7PJ+rGf2oGw+0cvKvWx4MitPqkriZYlshYFdbmA9 5UEyT8lzU6a7J9lMbgv1SXN6PA5tWrxk5T3NpKeibdvwmPLycvKOspz3j+ba3z9qP5rbr2/NGfI4 8vtwb7qVx2Fzz4vLGyrl5abxhEgqCk/Xy+f5qn57weK1k7wdG/XOwIIVI0bdsDCQqu9Rv/TGUZeG rjuvA/XVi9cGvNJ5/4e9bwGL6jrXXnvtYRiB2VwFVJSBICLeEIy3EKOGGGPQWCUGqTGgoAMiEBhE U5qmqSVqJBo11toRLyH8cpsZOcQnpRxrDJqY32NFor8N1qqxUWzisdZ4jDXs86611wyjYmpO2qf/ 8xxcz7u/b+29Lu/61rcue41uX/t1Ufxzb/528W1Mnv8v4blJA8OfyJ/5eG5yzMRNXzXernFPgFkW e3Md3n3BuDcZPzFyrI+UpJcep5Iuys/X5Et9fUN6DyQGk4EavIYYvHoPIe/JsWz4olXPf4ll5/kv eZsCI0zE349ERIxJiJ9AH2bEH9oi2aRIKaLzYuelzolN13M2zR8Sn/nWwi91L3Ze7rzQ+VnnmYoE 8/bcvC3zBxPtLcFjBJj0JjsnztsSJK0IklKDpKeCpKCAgIE6OUgnB+he8/6FN13mLS32luZ4S09g j2g0DvTQB3nojR5rPKQVHtJY36m+tFj3cx3V+fl66Dzl3gMpDdF7DiS9THgJlYP03mhBo4dOMnix Tmp5LKElnrUlHo35MgGrJ+saP/L+ax5DsHxKz7uioa44Xukf8n8I2zFc2QYtOCRhNPZoCR4jbPrO utc7bTqbpJcCgvoZqPeAEKnPl/Lrt4tl6+1M3YvfBI9aYApfnEjPCNsfRotDMG+kThwWFMzmoCg/ NpH4R5EwvzBTmBwW5hUZahhIvExe1Kt3UFDoEE/PXqYhrBENUi/WBDYZgLl/AlrxTYs/75N4wH8c f2uOwNosP8SZMq/Cit07OESK0GbVCN3hCycGPvrYtJG7mmhY5o6CxPrqHy35Zr70yOr1P1rd6ZDG jH5yiH+nn+5F01Mlqa/uDNaN3CrNmJP5zGx2YDNahLWY8753wBx0V5AXOoPug78fPP50/6Av6Qk9 oSf0hJ7wHcKb/5RQ2xN6wv+H4aD+j/qve0JP6Ak9oSf0hJ7QE3pCT+gJPaEn9ISe0BN6wv/e4Lns AcNv7g6GUa6wqSf0hJ7wvynwf9wwnu4jzo9e5fCrzP8xrhePMZ0ShXxBnF8WSyJHha5zS+NBQqUA oeuJIsUK3ZNkutIYSBxK0vReZI00VuhGukU64Pr21cO6NKFLxEO3TuiUeOp+J3SZROr2C13nlsaD +OjOC12P9FeE7klGutIYSKguQ+i9yBO6r4RulJI9xrMvpenY17t89GVc94Dup9/MdT2/X8V1T36/ gesGrh/gei9hQ03XbKjpmg01XbOhpuvc0mg21HTNhpruSRbojwtds6GmazbUdM2GTPdy4+/NuHmO 4rqP232F6Z5JXPdj3DxTuB4IPcBzAdeD3NL35m3U9GC3+314Xv6FOV0/XpdWZn+3NOFuehRP/yrX Y7m+nuvDuF7BdIMbf4NbXT5u932cbakmJhIPi4zE1URSiJlkQU4n+SQPsJAVpIDfeRyxQujsmoH7 2TzFcDyZRHIRTGQW7i1Gfgsp4rEsyCykXoZrJlJOgp6NvCytCRpLlQFYeImZSLUUspAswb18suh/ xObulOPvqJVxWkyK2Zc1cddEYpA+myyEng82rE4LGUzmcNZFokwTGY1yx8I+XSVNB7N7OaW4tCTO qgSp81CfiTyDkhfxmtjTYZxJPlnAn5vIDP7EjDuMVxEZinszeasK+ZNsbqXZuBYjfaZgZwKjceAV T+YiZzHizHorIIu53ZldzcLKizhXC7c3ixfwMpbiqQWB9Y4JbFaIPCzvE+RZkowWa3kL3Z4UcGtl opaFvEStDSW8LtaK7uvV4iztQrSymLcik6fNxzWTPy/g7V/BWebxpwXcAloJC0VZWfzK/O7udrPn uVyLQa7BkMyjFrhq6o5V3j0lP7iNukrPdPV0Ifd6Z885/bL7tmu138vrETcLsJZobbHw+pwez8rX 2pqJOyW85fl8FHXfUs3OGXfYNIv3a764aq3S9GLECvjVxNkuc/muVg5LmYsU39pD1ab4uJHxphRz lml6fl6+ZUVBlunx/MKC/MIMS3Z+3nDTpNxc06zsxWZLkWlWVlFW4bKszOGTCrMzck3ZRaYMk6Uw IzNraUbhElP+ovuX4rw5Xss5K2txcW5GoSlmevbCwvyi/EWWwXOyCouQ0jR6+NiRPNH0FFdJKeyS VJhRkp232PTMokXZC7NMw0yz8hdk55lmZC805+dmFA01zcywFGYvzM4wzc4ozstEcaaR48bGz80v Ni3NWGEqLsoyWcygvCg/z2LKKDIVZBUuzbZYsjJNC1bgSZbpiWeTJ+FpIY8UFOZnFi+0mFBDiRlV uOWFzM5bmFuciayWfFNmdlFBLirIyMtErmwkWIhUWXmW4SZn3fl5uStMMdmDTVlLF7BMXUXlORN3 y4gnz2SNLswqYo1jtnSrHdldZT3CCcRkoxZL1lJm+MJs1JqZX5KXm5/hXik4Z2hMswpNaG4+qsK1 2FJQbDFlZi1j1kUac1ZuwV0NwhyYz0cbm13z4NdsdlwhGeFLOYh38JnW+Xw2vEsbH2wcZMpb5T3y v8u/BX4tN8l1d8z4/5xVpostqyXbFT/H2Wfd0ZqsO/hyxroBupG6p3VP6h7FdRxSZ2CEMW5a7WbJ Ie3Epo7NKKwthXzeZ2W4PqyqDiKbSfd/ZMJ2U/5EUlXtq7XT6W8j6ThdNCETP/VoQtykDRXnHxV/ yGNq56RZybPi4pBK2zfy/wmYRtPhKG0utLVEouX0l0SmW+lW6L+iv4JupVbo2yj2HXQ7vQr9L/Qm 9K9lMJADZOzF5EB5CvQn5aehJ8svQ/+J/BNC5Vfk69C/km9D/0buhK6yf02tI7oi7GcsOuyJdMW6 FdBf0r0E/Ue6N6Fv0G2Evkm3Cfpburegb/aIJ5JHggf2aB4Pe4yBPtbjEeiJ+iQi6Z/Qo159sn46 9Bn62dBT2L+p08/RPwc9VZ8Kfa7+h9Dn6S3Qi/XF0JfpS6Av1/+cUH2Z/jXoq/Sroa/xrCSS5zue 7xDZs8rzXeh7DZMINUw2lBLZ8GMDWmf4icEKfZsBe2fDfxquQ/+qF2rpNbdXCZF7LffGrtbby9tI ZG/FOwb6YO8E6KO8/w/03d526A7v96Ef8G6BftD7/0I/4v0fhHof9e6Aftn7S9y/4v1X6Ne9b0D/ L+//gn7TG5b3/tr7FvS/ofNkH8nnA+z0Wnw+hP6RzzXof/W5TqjPV0Y/Ihn9jX2IbOxrnAP9OeN8 6C8oqFc5oBwgVPnAN5RIvn18Iwj1jfSNJrLvIN8JuPOY72PQJ/puZJ8fEp5CSQTvL62ntD4SvQPL zIIdUgywtiHVADsY0gyoy5BhWIjrIkMBrssMK3B9CTZk1vsprq8asMM1/MzwM+grDdixGl4zrIa+ xvA69PWwMLPtNWFJChsOgT7UewQsEOcdx630Z+hfeH/BLXAQ10M+h2CHD2EN1vZgXEOMIWh1qBEt NfZh1uCt8SIf0SvEI6MwYwExLVxRmEtSFhdmLSGLzFkLCsny3AxLHllJsOefMmmWiYQ9OyuJrdOE jzcPYiTBQsf7BwkRuifxJaHcXiyu429RfqSP2x0J7yL+pK/rjsS/g0yTU6aayICUWU+bsC/UUlIw DCT9REwm3iSIhImYDqO2N+lPBiwsKCoge/l1P79+zK+f8OuZJVmFeeQSu0qEX0P5NY5fR/NrIr9O 5tepbBmWZvBrKr8u4Ndcfi3k1zJ+reHXffx6fOmSpUukz/n1Cr/e4NdOdqV6flX4NZhfB2jvpeQh EvUdNC8ykESTQeiBwSSWDIGVhvH/Ve+73ne+L3d/lfkHtuT7aBL6l/Uo3phx9UKP+MAP2H/r54de DET/9IZXhMAD2Fc8+qG3+rPP8WGFibhPvge9R9nbe7fSD9709+RicoycImfJZXKN3JKo5CUFSH2l SClWipfGS5OladIsKU1aIOVIhdJL0qvSGmmDtIN/S+Rj6bj0qXReuklDqYnG0Dg6lk6lqdRMl9NV dAutoo30AD1GT9Gz9BK9Sm/KGLaynxwqm+QYOU4eK0+Up8oz5VQ5XTbLBfJyrAar5PXyFnmHvFt2 yO/J++WP5GPyKfmsfEm+Kt+Eaxt0frpQnUkXo4vTjdVN1E3VzdSl6tJ1Zl2BbrnuFd0qtMqAVWQ/ H01S/AIWI/TRyxNiYRPcmbAeFoSctE+Tj9/QZrCk45qcm6rJtFhN/nCVJuct0mROmiaXTNZkbrQm i1YSHfsEm0UheriL9NPLRA+3kFbO0piU+XAmUhn712OeRHrNR7v/WrSQVk2uXsnT6V63vu54veX1 U1ps7ZS1aWvz1r6qxcqTylPLc8tfEbErb9A3gt+I1fK/8YUm153S5PoGnsrw5to3d7y5980jb55/ 8+YGZUMUv2vccHbD9Y2GjWEb4zYmbUzdmLvxlY2bNu7e2LzxmMZ2UyT3fWnTVE2+9akmN3fiOSEe 1mPWa9uCto3elqrFt+Vse2Nbw7aT225p8QqlIr5iTsVLFRUi3lBxqqJze9T2aVp8e/r2su11249v v6nFdyg7Ru1I2/HKjioe1+1o3nFhp8/OUVps54ydy3ZW7DwkYmd3GXbF7dJq1u0q3LV114Fdlxlr Ir2tE9JHyADNGm/3FfK6Jt8xa7KqQku3O0DIvvAjJidr7d2dImS6kHlClgq5RsgtQu4Ssk7IvULu F/JjIU8KeUHIa5qsJkIqQoYKGS3kKCEFv+qZQqYJaRZymZArhdwgZIWQgl91k5AfCSl4VZ8V8rKQ 14Xs1GSNQcgAIcOEFDxr4oQcL2SSkDOEnCdkjpDLiTTkEhtRkg+NpMl0Dp1HD8g+co78nk7vYfa4 pX/F85DnMc8znpeAa57XDKP4dbJhk+Gy4aYXZTGvUGhpXMtECPWqQrjgdcG70yfZ52WfSp+9PpX8 WZXPWWOw4abnNWMwC4abxlzjVuNZhSorla3KJex5cn2rfE/5UT8fv33+85SV/psDwgIWBeQG7Ao4 5VMZSAP9UBpC4ITAqYFlgUcCTwalBB3vrQs80ju+9+3g+cEXQl4O2R3SFBqEZ0dCF4XWhR6AvBp4 pM/8vkl9D/XLDIsNyw2rYE/D3gs7Hnikf8oA/QBL4JEBnw+4GT46fHn4rvC68OPhF0wBpkTTFFOK aZlpi6nG9ElEcMSoiLSI3IiXIlZGVEW0RByN+CIyIDImclpkZeTnDyV6VT30clRcVFnU6YGjcc8V ok4L7fPIzwdaBo7mtkFaLSC9Fk6zEDltYNnA/cCZgbfZNdorOiY6LXpLdINhFI8fM4yKPhY4YdCA QUmDzsSYYmJj4hCOxlwfHD24dPCBwV8MSoqdEDgB8S9irsfOjN066MyQUYOjh+QN2RE7IXYCS427 M4fsBfPuQkx3AWtflLqOjFHbSaLaLv1FXSd9DfxNXUcloJfaTr0AXzynxrfVsYpBZV9sDVLNWHll ntNMxgHj1UaUYCZzkTINmAfsVc1GK1ABbFcbjTshPwD+ClwHvgJuqA7jN3jWCahqo0IASTUrFJBR XgDxVfsTfwA8javV540bVAtjYqyBXgvUAfWADbADLcBB4BBwRrUonurznDV2puDYxdfM+c7Dvb0o uYun+T48zeBpBk8zeJrB03wHz0CU3k58O28SfyAKqVYDG9QqcI0CVzO4msHVDK5mcDWDqxlczeBq BlczuFaBqxlco1Aa65FxwHitZ8CvHfzawa8d/NrBrx382sGvHfzawa0d3NrBrR3c2sGtHdzaFcYq VeMGG/qhx5gt+wMDuE3NJB7PkqBPAaYCybDILMhnIedApkKmId88WKlYPW9cBpSiph+r/Y0/BX6G nmNtfR331gEb1CbjLyB/CbwNvRLyfu134FkT8BugGfh3YB/gbpcPEf8IOAx8DBwH2oBPgBPAGdRx CbIDuIwWazZsUhar5xUzkA3kAEuAXGApkAfkAwXAi0AhUARYALRRQRuVEmA5sAJ4CfgRUArUq/2V X8NLm4DfAM2wTxSsmySsmwTrNsK6jdy6ScBU3E+GlWdBMqsyi8LvYEEzLGh2WXCDegoW2/CA3nJK tHQDGJnvYRQBRuvAqB2M1oFROxi1g1EjGDWCEWPTDjbwDj5ar4BNI9g0gs0VsGkEk6Ng0ggmjWDS CCaNYNIIJo1g0ggmjWDSCBaNYHEULBrB4gpYXAGLK2BxhfzANSr8YBc2MvqDzQD1R262SRIel0Rm I54CmYo0c7m3NcHbWsAsCcyShJdZ4WVWPrJ+AflL4G01B15mNVYB9/c0KzzNCk+zwtOs8DQrPM16 l6dZ4WlWeJoVnmaFp1nhaVZ4mhWeZmUjFJ5mhadZ4WlWYf8cpRf0xfA4M5AN5ABLgFxgKZAH5AMF wItAodoCb2uBt7XA21rgbS3wthZ4Wwu8rQXe1gJva4G3tcCqSdg9PcVmU7xnybxXWY/uJcnsi/iw mD9AXff9vveMKyv91VZlEBCrtpIgWD0H1h4LK+th3RxYNwfWzYF1c2DdHFg3B1bMgRVzYMUcWGks LJMDy+gVL0gjEAREAuPUcry5vYuR+o8uVeaz+xy+6rSTyT2+I3zHgw5T0+loIBn4gdpMU9TmO7yE rXfp8JL0brzk7vUuHV6SDi9J57uBFrSg5Z6yvvva6fu9VrcpPavSfValQMwK4ZgVwqWbpBL7uiTs 65Kwr0uifdXddBBJxUhKwkhKUvwxfwdBhkJGAJHQB5I0JRp6DDCYpBEflNCOEtpRAtsV7sOucB9K OIESTiD3Ccwb+5DzBOaOfZg79pFeyHHQLeVBpDyIlAeR6qArlU6KVz+jYervaZR6mK5VPyNe0nD1 M2kEMBJIwFM/IAQwAZFANDAEKY3o4yrenzWQtUAdUA/YADvQAhwEDvHdVRXrA9L7n7LWefM57QHm MjaPEX9pqHpCGgb7eKgnsM82w05m2MlMg2FdrNWwRjv65QT65IQSBu/pDwyA3aK5hc2wnZkYmHW/ tQ9MqKcc9ZTDplNgzymw5xT4Qw36xozeNKM3zeBQTo1qBQ2AHqg20lDIvpD9IFEv7D4F/rKADlan oDYzajODWzlqNINfOXiVw28qULMZfjMTHMvhNxXwm5mYgbzUVrSs9Y51JZC/PeAN4R9iB4WVxkoS pax2lvJ3cwYg1/uofx3scxE+dxE2uggbXURJ78PvLsLvLtI+QDhgAqKBwcAQ9SJKfx+lv48S37+H g/mBOThH1okHHlleYl91C3uqW+496eod1jORbGeA0VWBUVVBhoq3AD4jYB8Wjn1YOPi2o/XtaH24 FAeMBBL4jNF8l4e0w0PaYZFwivw0SJ2BHpoBT8nhntIfcgDeGE149pA6E722jg7EvUGkmcYg3WDc j1VnuHlPu/CednhOu/AcNuO0w3Pa+YwzyNVKP3UKa6nYPa67j0/fzfhOnw6G3r1fr/gf+bWC2hvg MQ1g0AAGDbBNAzzl9yi1AV7SgFIb4CUNKHkVSl6FUlehpFXYm6Nd//JxGYCaS8C/EbWXwEtqwKAE bShBbe2wVg1qa0d7KlBjO2pko7EGNZagbSWosQRtK4Fn1RCJzd7EeM8I6m70RN45gniuc8h1DrnO IRfzsHNIfQ6pzyF1K7zpd8hxDjnOwYN+h1zn+ApxGLkOI9dh5DqMXIdR12HkPIych5HzMHIcJrJr dWEri/d98znzRGv5UMthQpWJapsyR20jvhg3eowbPalWS0gN0IAnw2FN2Az7zxLlUYClToJ8Even AcippGK35a8MVS8gdRtStykPQx+DNWMc9EeBiWoHcrUhVxtytSlP43kyns9Qf6vMhJytfoGSOsBm OlLOhBaOeTMdZSbwMuNEuaN42QnKWMjxwCNAoqhjAjAJeJwzbFOeAKaIOqcCT7nqTlCegfwBMAtI AZ4FnuMtqVTmwhas9pJ/We0+ylASgpo7lIchx5Bh3H5PAtOAp3EvGfemY6c1G5LZzRupm8GxWfRT s+inZuRqRq5mpG4WfdVG4tG6cjqBJNFJagd9ggyjYEifgv40JNtDT1er6Azso38AHcxoGgmhuZBL kSYPegnqHYr+0azToSSQJFgHfHFvDHYgY6GPBx4BEoFH8XwCJGsH6oSV4A+49wTkFN42ZqUOWKlD WCkd/lEFS3XAUh2wVAcs1QFLdbD2wlodsFQHCaXoB96KqZx9B9hXgn0r2HdQ2BktqGRvA2hFB0UO mgUsRQ1DYWtuYcgxWK/vsDDuJeMes2wEamim6F06kdfUTJ/gtTWjtmbUVoLamrmtnoHNtNrKUVMz nY90i4Bc6Mxu+cCL0FeghqHqW6L2t1B7s1vNb6HmZj4KZqD9M3mPdZDo7sYmmJWAWQlYtYFVOZ2C dk+FBH/OIA36PGA+0rwALICeBSwCFgNm3MuBXApZDLkMWA6sgA896Lj3otPhDzO4pZtoBnzKjPhS +McY7qchaEsb2tFEdJznEu4F2owTLHquTes55JsOX0wBmL+9gNnTzHur4zuPhyDRS06faEMvdXCf wLhjfvCde8D/Di/T2tz0nXl5cA4/5BYKcc113oJZh9ZugNlwiZYKPtOB8daVuh/3eadHsnbCwvC+ StG2NvR3G/fzfN7OP3CGCfDph6FrM3Kl8hh2dtqsXOnW9j+gzZW8zWyUsbliHPYmP8a+5MfYl7Rh X9IG7yt3eR5KcPM+t77ko7BNjMJKziqNj4l09GsV+rWKluDeClh6qHqSM+TzCDxMm0dOolfa7p1H 8HyC8CDXPIJ7XfNIh9s8wlp0Er3Zdp95pM01j5hcNuUzIpg6WwNf4CP8GbRQO1lo4nMJ66l0eOqL 3Mbff+Ub5PoNoFqtgo2rxAhnc08znYjaNGZtYFXJ5xvNppUY4VWwaTlGdxXNBLJwbxG3cTrNhmQj fAkf5eXwiCpaBBQDy4DlwAqM5uHodbZ6aCtHh1g5KsG4krMbCS+4Ci+46vICjWUlWHYIb6gUntDM Z8cZfM7V/PGHAJuHnkcazQNKaDqeZ3DWlXQh9EzILNxfBLkYYHNTNmQOsAR6PmQBUAgUAcsBbZ56 8HXPT/RyM2eZjNqnu0ZNE2pnvniRl/Yw5Bi0nZXISnsacfg08eFtdM7+WhubxCzVxrlM5H2t1c3m OD33orRu5kM996HuZkoT232wGfxftgMZynZfbvNMs/C+JoyLNjHK2dhIEPNOulhfK/9ljPtp4wRr hnMEPwO22mzYjJEawvqXr8cr/gGzYpgYmVViDq50W2vKhU3YbFcpRuP3r1GH0dLh2oO9yPbrGP2t vI4XcCcdyODzPquPr7PMJ2keXwea+c7DApRwC7CxkMZWIoDtU7pKYDukVm4n5tVLXHVqJb2I0i3a Hgbv52JPgpLaBI82UUIbcjMObTwlRZ42toaRXqLGNje+zW47pDbGE239odvaZyHDsEI6873gYtnF kO9Kxe4KNWFPgvGGMobxtTSD9b3bmporymZ8KL/LrCnzGljJeEYMbhy19jgtny+sz1K0iqdNdz/l rdZxrzN3reDcYnyO57Znfsntjj2TZjHRGqT0Q8oEpEwgNcifJvYMXTlCeA6tly5ijtRyMhto/dtB PF0Wc2fv5NbL1ftOe3b1ttOWzOfuegorvSBiS7n1cjHyX8RuVLMXt7az/8UbQ76Lj9OiTubOp6wm 6mqvp2un27XSpGOlSWfrIenFT03/3ompB0lUj5ImoEM9KrUBn0E3kDHqeTxpwZMWPGmRwtXzUgTQ Bv0z3Avm53Ueqpl4AUY1hzRCar/wl3Xze1OZ8TrwFXAD+Lbfm/xcq3ut2t+4Wl1nfFtdZayBrAXq gHrABtiBFuAgcEhdp3gCBnUV6c1/+/EAPy+gkZ8rfv9f9P1cv+bXdt4Er1Lwehm8SsGrFLxKwasU vErBqxS8SsGrFLxKwasUvF52nbh1/e6OFpI90Bv432Uoc/t1wur268Qq8etEGWoqQ01lqKkMNZWh prJv+XWiDAzKwKDsAX6dsN7160SZsKT779i1QBdb9vv0ef572YP9Pn3e+RsXL7Xrt2j0KkptR6nt /OxdK7XpQc7fRamN/BQ/+J7fltFPKDkJJSd9L76+8KUm+FITfKkJvtQEXzoKXzoKP7LAjyzwo6Pw o6Pwo6Pwoxb4jQV+Y4HfWNjfF73TE7WTYdfYEeOm21Nhk3r0jpNhT9d5ba0a7vq1hv1SE4l2en7r GbF8x+m0p/O0GFa6dc8psc9d9dz/jFacz7ITMbdzWZQJy0+B5bs/h3SeQYrzR6K/769BrMVWMLGC iRWpjiIV+22K/SZ11PW3bO45Ef67DAZ0w6IX+qQFfdKCPmlBn7RgJ5KMHUgy9rdHsdNIxr72qDhf 8MMMy2beWmAPdO38713s5VqVeHUD9i4fYj/Xir1cK99vj4d8BEgEHsWzCfwche3pWrGna8We5kPs 6Vqxp2vF3uZd7OlasadrxR7nXex1W7Cna8WerhV7ulbs6Vqxp2sVb2Wt7GwB+7pW4ge+n7q9XX3K 39bHqX+5z9vVp/ztfQZqmI33bu1MEfM+7p4nkjKSbMablgdWLC+gEdDO+ZK72bMyCzXxfeu4++xd H0NND7Z/ZVZuumMPO1vNuWsf28z3sd3112SwmQw2p1DSZJR0ynVC2CZOHkLEyYOoz/U+0XXy0Ju/ wfmxkwy3t7ha6HtwD29x/O1lBCwVjzoT8N6svVGdFG9UJ7t9o/IH23KwLQfbcnaq6DoVZCeCztNA dvo3UZz4dfWUdsLHuHk98GlcEFJWi3c+1kfVSN0Bphd4nzzGPeKm8AiN7dNIk4w07uc5s/n51U1+ fqW75+0rAHXsFHt1VsdOfhIxjr8dO+twep2T4U5+ysD27LNhQeeePfqes5Pazh+j9Mtu5x0fivOO y/c57/iwm/OOD7/lvOPyA513KGLFbnNbsZ3jnZ0EXETNzveSi3ecBPigx0+hx0+hx0+hx0+hPeXi nbn8rnfmcv7O7NHte7HPHTOOyz5uM89QkojxuhYengiPTsQesZj9DRhC2H+mw/5+JmH/Uj4KQSaD EXRkBIIHSUDQk4cRPMkYBAMZR8ZjXCUieJOnEHzIswhGMpekwRLzEPzIArIQ3rwdIZDUkXqU/W8I weRdshc73SaEPqQFoS85hNCPfIQQxv+fgv6kA2EA+TNCuMT+mymTpJN0JEIySkYSKflKvuQhyV/y J1FSH6kPGSj1k/qRaClcCieDpAgpgsRIQ6RhZLA0QhpBhkrxUgIZJm2WNpMR0q+lX5M46QPpAzJS +lD6kMRLrVIrSZDapDYySjopnSQPS3+Q/kBGS3+U/kjGSOekc2Ss9Jn0GRkn/Un6Exkv/UX6C3lE +kr6L5IofS19TR6T/ib9jUyk7D+1nEQ9qAd5nHpSL7yD+FAjmUp9qS+ZRkNoCHma9qF9SDLtR8PI dBpOI8gzNIpGkVk0mkaT2XQwHUxS6BA6lDxLh9MR5Dk6ko4kc+ko+jBJo2Pw3jWPZtJF5DVqxtvA GppDC8jrtIgWkQ10GV1ONtIyWkY201V0FfkFXUvXki3GYuMy8kvjauNq8ivjG8Y3iNW4ybiJbDNu MW4hFcatxq1ku9FqtJIdxgrjdrLTiEDeNr5jfIdUGmuMdvKO8QPjIVJrPGv8jNiNfzZ+Sf7N+Ffj DbLX+I0ikybFU/Ek7yteihc5oPgoRvKB4q/4k4NKoBJEDimhSij5SOmr9CWHlTBlAPlYMSmR5D+U aCWGHFNilRGkTRkJn/y9koBZ41NlnDKR/FF5XHmcYIwoT5JLylPKMwSjDrPuVeVZ5TlyTZmrzCVf KYuVUnKDSF6feA9lX1CQgslkQqpXAmuIZI+CXA9shh4LaQV2CWkV6Zz6bsAGNAJNwH7kiYM8BBwB jgOngDPABeAycBW4AdwmpIYCBuQZDakAQfyZ9HPUW9MX9xMhTUA0MBSIB8biPvjWTACSCFkFHjXT gJm4PxVyDjBP8Nt/Dxg/zrEBdTQwibobEonUMBWYTPNthj2KTdkTVF1nK+M4bTvAUBNlu1YTC6TY /TgO2ecz1Hbab9XpgFR7KUckdIYc6ED9ZseheqvjSHWqLal6vm1adSZkjm1afaJjP0N1gW1m9TLb nPo1SLce6U7aKjkKkG4Z0tfZ8jhO22oY6s471tRdcqyvbrBZOM4jLcN70BkuQQe6+NpucnTFOzni oDOkQWdYbo/keFlgN9rHYBM4Y1/GccFeCrzqil9G/LL91dog+zKOvvZNHM64CTrDUHvVtyLeXlc7 1t5Qm2cvrbUAExBPQvwl6K8AlfYWjhpbZa3D/nHtWfsVjr2INyN+036doW4W7M7whmMqxyb7xxxV jhSOBscijn2OQobqK7AXUHfFsbnuumN93S2HtZ44dtVPRv8wiP6DPA55Cn3g4KiDrU+j7gPAR6j/ c/uV6lL02avos1WQb0AW2OahDxc4+7J+KspjmCGwC2XvRp/vQ1kM18GFoQU6wy3oDHW2lzhO2/Zy NNhe4Thva+YQ6WsI+p105XfF62xrOU7bPmKoGY1+Z0hHvzMkQmdYBJ3B5SsbCHxd5+b7XhyToU/u Lv36DRwr7TEcy+3DBUZxrLSP51gD/1rD/W0ix3roDJvtUzis9mSORvgdQ5PAbnumQI5AgYAW3480 DEcEnD561b6Ko8uH3+Bwxm9AB9x8eCuHMx4N/4128+Fp8M2Z8M0y+OVaN99kOGA/Bn845oofhX7U Lf4J/OUT+EtX+pNIf9oV/xTPP8XzL+DbDNc01L3qSORY5ZjM4Jp3nP7uBd9nmA+dwQ86QyZ0oPam gzDUzXKEcrA5KqZrnqobDn0UUACdIdKhr4sBchwD8PwS4j6I+yAeBcQ601eX2ksZXONtK8YagzO+ A/qObuMzODbZT3LscyxnwFisYahrwfhk+Fhgn+NlBjxrZqg7hntA1zxmD2aoD3Dsrg91rK8f4LDV RwGxgHMsO5EikCaQLrBIIFegUIDNATbHmfpGyCbHkRq9zcFQvxzPGPY7LmBuuAx5lctTe2j9mT2G +guQl/cY3PxsFYPb3LiDY469riaOz3XvYa7bh3kqrT7O0Vg/2tFUFww7h9lv2YL29K3ZhTHCIMZD vR5zlQ/mKiExxjdwnLYd5XgP6wbDJdiUoWtN+4SjATrDeegMH9u2cFyxfcpRZ6vgOG07y3EM8wqA tldyTIXdGXIxB+S6zwPoC4aV9lkcy+2pHM41pcsepcCrtfMwnhag/Rvgp1sA813jyzneKu4abwfs 5zF2LrnFTyN+sm48bDYRcI4FYcO6ZdCB2k5HQJ0OmOWIA0bX1WFdYHgP6wJDlSOdo8GRy7HPsZLB aZe6k/A9oMYHNgDqTiMO1AQgDty99tQcR5uPi7lpv1v7b6P9t7GWdtktjOPu+VSkr6XgDtScQhkM M5CGoRC2B6o3YZ3ZajNX74Csspnhj4fqD8FfQ22fM/D4EcQHID6Ax2/UH3fcRt9+wVD/MnyZYaXA VfjvDfjx7T3URuHHXTx1HE5eBvACXHEFcaBuCuafZIDND6VsL7Rnbb11D/PPZgZXP4nnWr/s2VKX in5JdYzeU+Y4tOcVPt4+Z9jzEuIWrJfnbZ8z7MlD3Iz4JcQB9v0w/vUOwr/bYeBf7OjFv6uh8C9q +PFvaQTxr2j049/PiOBfzniIf7Uimn9zYjj/ksQo/sWIRP6tiEns35rT/6TYucrhciSh8iB5NNHL P5Wvk2CPGI+hZI1Hov4Rsk4/Qf+4tE4/T79Yekufrc+WduqX6HOlXfpCfZFU6d3Lu9d/k/c1QG1l V5pXz1jIgDFNGJp2aMYhxKHdBBNCMGE8booQSY1phzD6QzhuLMTPUo7juN00YRliPQn9IT2EyktL KrfLwzqEchHiZRmKsB4vcRzCulxeQojXyzgehvGwlMN4KYd4vY6H7Hev3pOF2u5OpnZmt2rq1nfv 0X3355xzzzn33Yd4kg0m/ofECdn3krikb8p+kPw3OzK4V+lbKTg9+198+n+opeJ/7O/FrHJ5kfyL hCT/JvkR4ZL/d/ITErfjCzuKiHzHvh0lRLHjT3bsJwn0P33p20LE/q1i/wKqjS1fBKdki2uLG1z/ zy0PSdxW9dY3iUJeiHET5KXgOhlcv0FS2BypbI605H9M3iDp4CuXZLD5drL5Mtl8WeJ8Mu7SFsWz 88MHuBf/oJLIBnCf/0E1oAON+/0PcC/+gUksD4vtJLoFOA6cAjqA0+gDLX9gBzyAHwgA54ALwEXg EjAOXAauAjPog/PEBzeBeXZN1k7nXUA9zhgfLALLwCrwEHhMZP8e544PNgg5F0dIJ/g4lwCkoF6B Mh3IFPk7/SFQ/hiP38Uc36Ul5v7uUyIbxDlmEKdt6KIaJ3n6Jpx2whMP6SfnyUUyRq7gjD5H7pBl skae4EyeLMuQZcvyZAdk1TKjzCw7KeuU2WU+siVUHJoK7Q9Nh8pDNwgXHH/nSvByyAxqIlQfHH3v NKiBdy4Gx0LVoC6EqoIX3zsGSninPzgYUoPyhUqCZ0MVoDre4YP+UC6ozlBO0PkerWt653jQFkoD 1RJKCZ5+D3YSrHnHGGwNZYDSBJ8G68NX31EGdcFVUObgSrDqPax1sP6dwmB58Daow8H5YEnbOijD O1nB/OA11ncqmNO2CKr6nYTgzuAlUFXB4WBKG+QIPMBVeXAa1FrwauBp2wSJCx6hIwcfBGuC60FD cAk1NagxoOYIaszBJ2g9fvJK4GYQ8gcmgvWBa22nyZZgRfBcsDJ4IbgreJGN3B5YD3axkTsC99uO gFoImgP2YCuopeCxQGdb5T9jbIhnbwMi7D1A4TfubGNvu3mZvavmFfY2mk/ueGVHJskkMplGRv97 Pgl2AM8M4dQLbZPQTgAn3RBOuqE8sdwtXpdonH5DJQBOvlhdEsKpFzZAQjjxhmCtIXhZCB4VgkeF 4FEheFQIVhuCN4XgTSF4UwjeFDon1sOjQvCoEDwqBI8KwaNC8KjQDABv+jadEx4VWgDgRaFlkY/K D2NgDJgEcMoemCbFgZLAAaACqAxUB3SBwwFToCVwPHAq0BE4HbAHPAF/IBA4F7jQrkR+MXAJaTxw OXC1PbNd2Z4SmAnM/FuhvRR0buBmYL69JrDAqMXAcmA18BDp8V9sDMQNJAzQN1d+AisL3+bWud8Q jvtfWOU4tspytsrxbJWTsMpfwlr/SWStX8Jaf41kyP8MK57JVvxVuVFuJH+MFR8muxJHsO6fSfxt 4j+Szyb+Dqu/B6t/mORh9T9DCv8fzSojBnKO2c8B+narmOhJ3jkVEz07wjgP+ryHJL3f9P4xS+f7 J99vf7/rfdv77vd97/ef7zpvgzSJ3K+5X0OaR9wjxPfSraWEk9fIa8gWeEEtiZPXwRe2Jn4/8ftE nriRuEHit38dvqDYsRu+kMB8IfH/0iiy1PVPGLCfJcmukGOEnHoArANPCHkXQwvwg3flAOR/NxXI ED9nATnAHvFzgYhisc1+oDwC2btGjFVCuFNnUB5gJXkX8VNAlDw1HIXzqEP8EKrDoHXfqgGtC/dn OCzCJLZvAY4Dp4COSPtnPB0CNIARqGdjUJ5ZH3Fe8m4TcIy144TTYt3JfwLaga4o2AA30wd30ke4 ExciIO/6wnUAebef8cb4Y5/PvhDh6wO05O42D9nWPfOWTn7Es9A8Zl/1LFp4vtyzbHHaH3pWLbz9 Ma4KqHloOYP8sSVk3/BsWM5bhr1xrGbVMuiI8yZYhh0J3hTLGUcK2qC9Nx19H3ozLaOgs+lo3lyL kx9BTSfofLRMR0unI9Nb1DzdPecttUygZRmrUVquOLI9C5ZrjlxvleU6xq+yzPJnkd/CCDXN9xz5 XoPlji3be8Qy6yjymi1LaFNjWbGFvK2WB8hPWNZZzRP7Lm8bTxyl3k5e7ijz1vBJyKswghK9Zh1V Xp5PddR4W1s4h8Hr5DMcR7wC6pVomeUwe8/wOegbAq0EneVo9Z5vfuQ44R3k9zjavEXIO8E/9OYd 5gscvGeVL3Y4PY/5/Q7Bmw76DGS87lhiUjzLlxwrjEbO21gNlW4W9Q8g14dy3u1Y9wq8z/EE8oac xHsLudyz0ZLmTAKf/c5UjPOC3LLuzPDeYTltidxyi+VL6Gvgyx0h76hFcJwHt2edWd4lfgD1K5Zh 1wHBzasdg5DxkGMY+X7HKNqMOPcIhB9zFghyfggtHzQPOIu9me0nHBNoo2EaCPcyOnjvhFhT77ji vcI3Ib/GH3NcQ37Scd17nW9nY0bnXY5ZaK/LcYvllJ6074a9LdnWhSTLA8sdIZWfcu73lvHTznKs yA3MsmK55XggZFB7g91SudaxFne8yjCHFt6ZA6uj9U/4OafamwK9HRKy+CanxrPRPGR/KOQ0P+LP Cnv4206jUNC85qyH9u5Smr9H6eY1tCnmC5xNsE+snZDE33ceE/bza45WoZx/5Bj1LPNP4QsLzHdW rZzzpKDm15ztQrlV4ezyrGLGDKHYmuy0CUnWNKfb22bd6fRBopXmIUo74kA/4adhq13OYs/jljSs e1X7IKWtu5z93irrbudZ+NSScwC8FTiLwZvbOSQc4tWUtuY5iaCB5nnB2LLTOSJkWAvtq0K9tcQ5 JjRZD2AVFkBPCsesFWzMSueU1xCmYRvTsATa96S12nlDyBBpHaWbx5xznmXrYedtod1qct71ZlJ7 EIzWFibRcYywCK76QZ9y3ovQHc77iAzUzg2QCDTfT2nraUpb7Yz2QKIUqx/jdFkDsKLwunRZBOea YLOec06h/gLj9qLzkbfGesm5Bm6XnE9Bj9urvVesl12cZ4M/5lJ4NqyXnYTRyYyGd1iv8tOCGzFh QvBZZ1xpQr/1pmuncNY6j/EHLEvNc8KQdQGRpIZGMKGctRyhswhjvNy1S+hqHkMsykXcMAtd/H5w mA6psRZ8e5h27ca6LPLlwoB12TYsTMILYO0tOx1LwpRlkNqDtcSV5xWsq2E9o32N9aGoc/hgWP/M T2usj+m8zXcdSki94SoU5LY4V4nnsS0BbeZbdrp2C9O8u1sNa9lwn/eW2lLcg94Q6GFGjzI6Um9L cF3CSg2B82mL4KqAZyW5KhENzrgWIVES1tHQLbet+xK6kxy5vpT2E3QX6E51T/jSbdmuBV8mjbG+ bF7jWvCsdme4r2AdGQ3LROztznJf8+V257ive9u699gmfPnQ3qiviEZ+Xyn6lvnK+HbQSvSd9a53 FzjSfTTqtvpqrKuOdG8u6m/BBhadaz5Dd7H7jnfWluDIBA/7US/S4L/VO9t+oqdYMDavOVZ6C7uz evb7cm2zPeWw/PYeNeTqp3HMWtFzCPvLOqWbx1zV8GLMReOnSycU21JgOQ9t6diblvlp12Fvgi3d ZfIs2zJdLd4ayHvcO2HLdZ3yLNryXR3QEu86Lhiht9PelOYbLjuiSidaGuiuIdxoHnJ5WI1fOImW AWHOVuQ6503BmBeE27ZS10XhLotU92xl3f2eDZsSa1Fm9bvG6Q5lPQzOp22lwn1blesyWp7BuhfY ahxFwhpmvAofH3bNeNNtBtdN7HRjrnn4VKdrHFax6FoQHlkm6K6KPcjgPWM7ArrMZrbuhCWXWGaF p7DkFEShO5YzvRylexWY/TS0MeLI7E22tbqWe9P4ftdi705bun21dxfGae3djci52puHiIFICCsF n7bRHk1fF+Qt6rN1T/UY+9zd0z31fb7uGz1Nff3dcz3H+s523+452TfQfdcy3OvpvtfT3jfUfb+n q2+ke63H1jfWfM+dDTt51OPum+x+6szqm4Jfz+EOAfs1ZPH0+EDfov7eXd5zyLNq53r6fVcsgm1J sFH76a3A+p4VbHR9QT/qGeibtqz3DCE+POkZ6bthV/SM9bntyeBqzp4Grm7bd/ZIsb2r+UbPpFBA d4S+u+h7yDsBu8Vui7mmYFfToNdhV6CpXWG/eNQz7Z0I248tgdFsf+zOwm51y3q5p9x7RaId675c 6yq1Pau/5waNBpS2LIE2YJw5b659V8/tvnu8htKWOz23va3W0z13JftE3whtGeyZ7rtvLbHl961Z bmGPG7Lvdtf0Peo2Ou/1PbXn9dyDDdxAhFHbC3Hns2K7Y1sHh1g7P0fXzq+g3hGWorfQlm1f9a1T z2XaC3tHqtdgL+m5781EXFqBZ9U47/YWWmZdq70lthOOot4SSyfuoAy2NljCAcSfVvgL7gZ7K+A7 l6jNux6y/DHa8K6N3kpbG/Jq1r7a5kSu4yfdcb2H0f444mSSO4Hm8L4qm4DxTS3J7hRvPrUlrB2b i+a9LZYVPsvbZjtjG43kIUtn7/FwbnnAT/eesnS604U123l3Zm8Hy0+z3M78ZYjyLwyFLQ0zFmHG QXcuPHHYnU/jM7VM26i7qNdvm7DwyEdtht4An+ou7T3H8lM097barrTsFvphma1UUuddYYrPcpf1 XgAnzt6Ltmvwpku265Y71Kfcyt5x26ztWu9lPgP5uGXWneCtadntroI+oQ1hyuZ012CEHLcBcbgT nj6FXaZImKLrJexhHnfVMotVmKFxuHfGdg1t+q1+trITFkHo5+WY/Wb4rgyjHRH5mbfdcpuhPdyd 9i7Y7jSP9Y7TemHaxrtbexdb0lyXhC7bRPM0RujHLmmwLblP9C7z5e623lXbiruz96Gt1G0W7toe uHlob93t7H2MXOjdsAjuM4gSY+4QdodpRJsM2xPXuC+O7RFHmu9jjzB3l8MC862FuK82dKv5Eewd hxxxvlbsdCO+E/QO3NfWfgK73rzVj5o4ej/v62Q0z2gn309pumP6hJY02NhNWi+oLeugZ2hk853B Oub7zJTGHRSj+Uf0DNKtoXf7fLvrki+Ee/ui3hlrBc4LudZkyg/1Ed952x3wMNhtpPXd9ZH6YVY/ yugJSvfetF61bwiT9LwAS9CgfWZ3E9pcsWWjjYHJUsPoa4xOgcViBMuKfZevqPsY6OvdJ5uHfLOs /jqrv8XoO5TuPdfd7rrsW+ruci95l7rb3SuMfuCl+bpvpdvmfoLcCP/KZfvpOnaZS74HuNPI95Ux +jyjsxm9Tunem7y6h3gzca9YJqxF07YE6NDY7aaWbJ0Hz0+6fe7SPsLoYUbL0V6OfbyfP9uX1DzU I/c5u8+CTqX1fRndA7bSvqQP0VmsfQ5iZpI3n29qXuvbg3iV1FdgCTXf7yuOovczupzSvafA8/E+ NazU3NtCad8EpWlMlui+Q/T+BPeQOlj1buxrl3APMOQu69NYN+hJ0JbSk+oNNc91z/UZ+Zye1L56 3A+k0Pb8GNZoM83uE/gx7yzs5CG95+HH2I72sK+pu5gf6zvG6AJGn2xJs5XirqapJ6OvvXukJ8sb 6h7ryfHOdqf27MHdxWRPgbfVv+Bf9C/bL3kqvG32i54K/wV41jisFBFJmKSnSCGHRmyv0E3gTbZw bj/Qs+ZPtlf0PPKn2Ssdg/6d9uqep/5ddp2H8+8On5Hthx28P4+eNP2F9BTpL7GbPArcFYRPuOxs Gz7VRp9Yw2fV8CnV3uJJ3nxWDZ9G7cc9af4D9lOenf4Ke4dnl7/Sftqz219tt3vy/Dq7x5PnbQ2P Y/d7Cr1V9oCnxH+Yzus3sXnNdF5/i3iapmdnMz07+49TTvynGCfmZ5z4O8JShCMkPSn7T9Mzsv90 WC56csfI7HxN4xLrm+99QncQv53uIH4PrfH7qQ/6O+zn+LP+QHg0dvo22y94DvjP2cc9lb2L4acT 4ScG9su2df9FixP3Oav2q55q/yXxWQQ79dtnPDr/uP2m57D/cviZQ1hv4acK4fO7fdnT4b8pPrVg zwdEOvy8Ar18w/Z5j8mXbV/wtPTJ7ec8x/1X7YueU/6Zc4ety8JT+hcm9v5xEvX+cY69fzxOUa4w kK3sneOZ7J3jn2LvHM9RtCk6yV7FdxQ9pJi9T/zL7H3i1YmvJRYQTeL9xFVymL05/W32nvQGzPEF kkP+lBBSQb5OdhITsZAi4kLSEB/pI1pynvwF0ZNBpFoyTC4RI/khmSRvk2nyC3KULJK/J98i/4Os kvfII/I78ucyTraHOGRumYdckvXLfkH+o+yXsnvk13Gtcd8gv427EPc98ru4y3E/km2JuxH3c9m2 uJW4X8leinu0dYvsj7bmbP2M7NNyt/yy7DPyKfmPZAb5j+U/lhnlM/Kfyerk/y1eLmuM3xb/suzf xb8anyW7EP+p+O/IBrd9Z5ud27rNtc3Pbd/2/rYQ9/K2D7YNc5/c9oNt17nXt/182wKn2vbLbY+4 r277bUIa92/o39w4a2Jy4g7Olpia+DJnT/ybxBXOk3Qi6RzXn/Sb7Rz3k+2f3P5J7ufbX93+aW5+ +57te7i/3v657Z/j7uz45o5vcr8kMminlT1xzaJvdtUMASPAGDBJdmpGNGOaSc2UZlpzQzMH6rbm ruae5r5mTfNI81TLada0Cm2yNk27U7tLu1ubpy3UltB3brMVJoovK75MOEWlopLQX5xK5fK4PEK4 Eq6EyLhSrpRw3BvcG2QLV859mcRxak5N5Nxb3FskntNyWqLg9JyRbOPe5t4m2zkT10CS2fcbU7hv cN8gL3Hvcu9izPe4DvIJ9v3Gl6H1HJIh/5n8Z+QVyHSb3GWSsfffatqISdOm6dTwGqdG0JzRhDTn NYOaYc2oZkJzRXNNc10zq7mluaNZ0qxoHmjWNU80K1qilWuTtKnaDG2WNke7R1ugLdbu15Zr1dpD Wo3WiLocbb22SXtMe1Lbru3S2rRurU/bjz7PUk446TidgibpM2qSw0l7VjugHdKlaUeAVO2YdhJX p0BNa29o57RPtbe1d/Hpnva+dk37iP59Mv670Gb6Jmunv/FSRE7AdkvJt2H55czaD8LKL5G3YOc/ JIdg5b8gXyX3kaqZjr4W/+n4z5Ca+M/Gf5Zo41+Pf53o4j8Xn0/08QXxBaQ2vji+mBjjS+NLSV38 /vj95HC8Kl5Nvh5fF3+YvB1/JP4Iob8ydhb+RLWcTd9rDpshmilgGrgBzJH9moeax5oNbZw2QZui TUeeqc3W5mrztUWoK9WWaZXaKm2N1qA9gtwMtGpPaNu0nVoeyakVtGe0Ie157SDyYe2odgJ1V1B3 TXtdK2hWNYvaWc0i0gLoZeSLmquaGc1NzTx9S7TiW4p32dvUEzZp69tIReS/In2R/B1SMXz/78k+ soJUEl8dX02+FK+N15LSeHO8mfwJkSU93s5+T4zsoW+SP5oEwKoa1lFmAFmgnxCZmWz5wlF5wwpD UsMDBkqnNqwfzWh4wj5nmcnRHLOc1e8xJx0tMKeyenqd1kntpH4SXWzOiIxN62lfCjqWRNOxJXq/ OYuBXqclnUe6JqHcnMOuS/0oTeejpQQ15lOL8tC5D6HUgEdaxo73PJ6ieYvGi/rGgspqNO9hemky F0Rkl/iivNDrVD+SXtXPQT3mjAbtJ4HKIkHijeqM9qNjHsOckm6kuaPXkI4hyXjSXLxJj4fEkl6X 2kslvdZu3h/RrTQ2LbtEHihtM5ez0m1WR/QuldLc9DNdT6mUeKT6onxRGXzmQx/qL8kmlf1mzdGz ZuPRAXP9Jj6jZYnlVR2jB6nMiOKNyiPpL9YW6qPoaJuVizJI+qN10hhD5qZNc0hl0gvkl+RNipFf +kzth9JSP8zVkBCuiy0jbUbMx46OmU8efWoeM3HmyRfq5Xll1+95/ePa/SHz1Iv6lfScEbNeH1V2 PfvckBKW+0VlRC8xum5ID+vp48rIuqufU0bLEW37tJw0t0fixpS56+i02cZoqZRisuSfN8zuyLU5 s4/NS+1eite3zf1H75rPRnQmf2YbrLxnHojISNvfNw8dXUObR+aRiJ+LfUwK85Qp2TzNxpFsEqUp zXyDjmHaaZ6L2KtUirHOlGe+Z9plvs10mN94uaGo8WpDaeNMQ1njTRrXG5SN86yuqnGhoaZxkbUz ICbSeBm7xtBhQybGj62H/5suNOqY3R95Nkdkzc2Ny1SGiK4/zvbqY3w71qZi41VsXBJ1RHlqaG1c lWJIw4nGhw1tjY8bOhs3IrqS5oyNx5LdPG9/iqk37TbfZXqmKDTfN5WY16L3KdMB8yNThfmpqbKR 2zSWtM8CpupGhUnXmMzow41pbM+VII1jatzJypbGXabjjbtNpxrzmPwvgKmjsZBCsjvT6cYSVtob D0TvpSZPY4XJ31gZvfeYAo3VrDyHMaBHtr7Re3tO2A5MFxsPU3mZjJcaTabxxhbW73Lj8Wh9ma42 njLNNHaYbjaeNs032k0LjR7TYqPftNwYMK02njM9bLxgetx40bTReOlDsfB5e5+0p0TH4ReVsfYV O55UT/ex+ih7e17c73rO+FJMlO4PJD+RfF4eZUu0HbXFbHF/3v+sbMgNr7dURvBxcr4g1m6y5ehS 8pukGD+K3f+iYimTJ6qM7PsxMWlT+SJ+D8XoM2a+yF4Zu6/Glsei4l10Ka2JFK/3hPXdeaNzTvK3 Br4pjvpBg7MpoUFoSmmIaxxnONOUThG5D5fGk8am/IWaMiM+TOeJvj+W/E+6Nxb7s/iNfaLhfFN2 xO9pPfyO+l/0eA2DTbnPvfcWx20Ybsrf5IcxMUqKRQ2jTUWb7onoNRoTJ5pKj8qbyo4mNSkbrjRV MXpPU83RnCbD0f1NRxquNZnZZ1w/Wt7Uyq7jWsNsUyerRxtWimMwOqvpBGtzvamNzkVP8gqvopeQ xM+z38D7h8R/IPQ3oj/7L/ukZesW8jv2ROVt9kTlqHxK/mPZGfYsJcCepQywZylz7FnK37JnKX+3 7TsJaVw5e0Jymz0h+e/sCclfsyckf8uekPyKPiHZspM+IdmSS5+QbHmNPiHZUkCfkGz5PH1CsoV+ J+0CufjsOYIqgahVSlWVqkZlUB1RmVVFqlbVCVWbqhM5DzpB5VQJqjOqkOq8KkVVqhrElWHVqCqd pQngiioX+TWk66pZ1S3VHVX6V9yqJdWK6oFqXZWJ9ERN1HJ1kiqbpVxVPmahqZSNSD9lM5Shbakq lz4TUNTS76fFnHI7sC5/Tr6D8+0I0pfYibeU/IzM4Uw7j/Snsv8iu04OxM3G/ZyU0edXpIJ9B+9I lLy5ROKgFPOFJS8VZZck56NkPgOJqbwTkHMU6QpataquMR7N4PFl9n/EhOwm9HeIcpE4nKrp74Dn IcWRfPafxfTXruNxOi8h28BTBdlOlEjJBIohO0glUgqpQnqJHCJfBadfIzUkDZZnIOns94B3kjak T5IupExyGulVcgMpC7L/nPyxLFmWTD7Fvs/a9UxW3cyWQt1MZYnupm5et3DwiG5Rt6ycq/LplnWr uoe6x6jf0K3q4/QJynp9QmWePkWffrBUn4m67IOZqrzKwsoKfa4+XzmkL6K5KlmlOJipL9WXKYcO llYqVAq9Urd4sEpfpa/Rzehm9AbdAh1Vn4DxI0l/AuOwVJVTWaGc07fRUaSkUoSTck1/BD07D2Ya suhYoJ16QV91sBT0AsOC3qxvVc6B55s06RNYOqNbBX8JlG9wMV/VBKrq4BE9r1vU52K2kP687ubB TArlGsZZ1Q/qh3XzqjzdvH5UP6FbqCykI0TwWKVgQHt9HEaO019ho1/TX1fWVyr0CaowMJuIWf0t Oq40CxtRAnig0N9BuYxRAf0ZfRtNVBP6Jf1KlQ/afQB58tFuXf9Et2ogBrk0mj7OkETn3zQ3YEg1 ZOhToH1ICy5BSaA1rCdaMb7+ECwYBjbxvwmGAeWccsgwZBgxjBkmI/JG4Xn1tM4wpdrEfUQK1Bum 6SqHQXmgc0T4v1lZqM825MDGsg17YJVMMljzTUOBcs1QbNh/sMxQrls0qA2HDBrYxjKzU4XBqHts qEerJsOxg2Y9bzhJdQi9thu6qCYNNoMbtpMPy8UaGnyGflhHveGsvtToNArGM8aQ8bxx0DhsHDVO KNVGg75Tt2i8wlYTMxivGa9TGHzGK/qicA96zThrvMVsJ6LNsOb0ZyrT6Io/W1PdBmzrLPxuDXhK bct4x7jExl4xPjhYVlmibGe2GtKfoD2obioLVXlKNVJ97eXaqxLNkrp2BraTi/ImMA/55cqzNFV1 VXXVLtQu1i7XrtY+VOXVPoZ+1LUbxjhjQlV/Vb8xRc/rl5RDleO1yQczjenGTGO2Mbe2w5hvLGIz tKvyjKXwzmljGWwdcxiVlZUHUwztzJ8ws7HKWGPoh+7qK8crk40G4xGj2UCMrbrHxhN0lYxt+nwq SWUJVvCGYc5w23BXb4BU8EDDPeC+4a5hTZWnDxkeRfQVMjyt5WoVVPqDRyorJL3rlmuTw6U+vzat dmftrtrd1IukOv0DjEVq8yhqC2tLag/UVugeqpIjYL5tcNdWop36WVyIYENfShH2+9pqQFd7uLaE 2k6tqbaFxQGRZlZ0t7a69njtKUN7bYdBXXu61l7rqfXXBiTrRkRVou25sGfWXkB0raKgqxmOHbXJ tRdrL9WOVyrQogq2f/YbWTTaGtexDuvGJ8ZOI19H9GU0HoK/Vaz9AYP6YKs+G9GZyqbQlyqHwtGY rk+dXB8yltKV15di9uy6pLrUugzUZ9Xl1O2pK4B93zL46orr9teV6w116rpDdZo6Y119XZNSXXes 7mRde51at3rQjNVKoDEXMRvRqa6rzkZ1Qvmu6w9HSmrBWFVFnbvOx/bCRux7u/813EdB2hZygj09 T0dO3sCOC6S90YF0GsmO1ILkQfK/Mf9GAOkcUiHSBSQ/0kWkS0i0bhzpMtJVpMNIM0g337hJf0tU 8baiHnNsJV8hKuj1TXIQ9xVv4e5ATv4M2kuEnr9OPkFkSatJjxhH7K9eyiEie7MA5QjK4i1fUA4o 1xiGRFB6BBgTP08CU2L9NHBDrB8T68Zi+kn0nFhK9dMipqLoySj6togpsbwRdU3CXfH6ZNRYQ2Ip IVoeqZR4jB3veTxF8xaNF/WNBZX1njjn/SjZJb7GxOtzMfzGInb+sSgMRUHi7bbYb0qcU9LNdFS9 tIZjUTKuxehRKqej2kslvfYoSrfR1yQeaPk0XKq4KB6GYuYeEtdTKqN5nwyX9M7vQ/1HlJtkVCUD acDOGD6jZYnlNVYPsWXsnLFrEY1om5VkkPR3+9kYql0fMdfz5I/lIbaci1oHaX6pLrYU26h2A3nA KaDjI/Ty/0sp6VcqX7ReH1NG5P6YMlbHkp4+rtzkX7Hl9HP4l8YvVEZ8R1UCHBDpA1HtomxZVRHV pjI8PrN7MV6rqgFdlM6ibYOu/2HlJj9UmYAW4HiU3iVbOQ3YlRFfjPikR+TFr9wca0aUkVinugAE wrSaB5yAAJxRsriuDol154FBcW4aE+8/Zw0lGWLrMZc6Myxb9BzSdfVwWIZNMfDjbC023n5UvHpe XJoM86QefVavngCuANeidPWiOCTJ+rz9KaZedU7UM8VF4JJy0z6lGgcuA1djxrr9DKoZ4KZIz4fX JgJpnAWxXASWgVVR/hdA9TAMye5Uj8VyQ7lpL1XHAQnKTXFanSKW6aIeM6NklwBdqbPD8lIZ1blA vtivaLO+1KVAGaAEqoAawAAcAcxAK3ACaPs97CN6T/mouPz72ptUSr71or3nRWV0bIz29dhSWvMX lTdegI+b/+Ni7/P0F+s/z9v/P66MikXPLf+Q9Yke9wV75nPnf145HTV/lN4b05QRf1NfD/uBeha4 BXSKuBNG5H5V6i+NTW15SfnMhyeVm++PJf+T7o3F/jR+031CvfKMB+Z7CWH/ix5P/UD5/HtvcVz1 unKzH8bEKCkWqZ8oN98TTYf9+E3yTL435VF2IbZ7MynGTkR9v5nxTJeRdYv2AdomNXydfgsqMSFx O/sW1L+q5/YyH0ffFZIkSyZlhOyzAx7ADwSAc8AF4CJwSfw8DlwGroqfZ0TcFNvMAwtRWIxqswys Ag+Bx2L/DUJK4sL1JQn/BKQA6VHIBLLDfJTkAvniXEBJ0UeglJTtO7CvYl/lvup9un2H95n2tbCk i0rHI9SpfR37Tu+zi9c7AM8+/74A0jmW0zJMXRA/taBVh9j3IvpeQjq3bzwqXabf//zwd4AV5Yoa EqcwKAzkjxQdik6SrviOwkJeUVgVVpKpcChc5FX27d9d7Nu/n0t8LfF18vnEgsQCUpS4mrhKvph0 LeknpDjpp0k/JSXbX9qeTr60PWN7BnnjX3w+mSxVFv4m7SR5nZAi2FLR5RhcFaEQS9hNEWyraD4K sKsi2FXRsogZEati+TBqLNoWa1+0IeKyOLYEXCuc+Fi8XqQrOhyTTB+q+ej65yT6ThL2HW+i0Cj0 RMa+472Vfcc7gX3He7uiTfFtkqHgFTx0b1PYoXu3oofsSsxL3EuyE+8n/orsTppOmia521/e/jJ5 bfsr218he/7ZxpWRETL27K9B+X7yVuH5/HGaCgfzdYXDhaOFE4Wj7PMVWjJcA64Xzoqtxgtv0XqW 7rC6FaRbYjpPkzRi4RJGjIzH8mvhkaRx8nWsdhZtLtB+rP5KuAd9hsj107cocee5v0Jw/xH3E5LF /ZRbJp+Wvyd/j3yZxlBSkfjDxCnylcj7k/LF9yd9Hj3j0BMRkBvkJslW7jJG2claZ4pjy0g6o0V9 5OURGQWufUBzjC4jJeRAVIt0kvra7GuzeZl7h/eO5mXmZefl5lUhpeflv3YnrwgozSvLU7IxAvRb udz3uO+Bg+9z30fND7gfEI4b5UbJFu4vub8Ef/8JPG2FTDNEwaRJAH9/RRIT/zO4TIHHOWUz7Cle DXmJkL2I8nuVIqqi6GjUvKAePO2dIG/tTd3blZ+51/a5x3vdtNxj2tuer9zry8/d209p6fPruXvP 0jZ7M/YO0Lq9WXuHWLv0vSOsTdXegb05e8f+D3tnH19FdSb+c+bO3OQmuSFFxBQBAwQMIQkpIgLS kiJiREQbI0ZEDBAjYMQYXkxZimjRWkRKlVqK1LIBXUqpZWmKrEsrYqtUqVIXkCJFUEoVLKJSigi5 +zzfMyCB+6Nsd3/b/aOf+cx3nvucZ57znJc5c+bl3qtbtdW1e373Z9lHbLsXd1/bvVf3F4+vum/h 4eJUXdUna/vuG7q3L25zYpXYjq8Sm+a/N4zx2e7l3Q+E8tGiI8We5DeLvIbj5/UwrulhTI0nxbMQ 38XFOd0rux8S/e7u1cWZ3WuKWx0vf/5giaNf99e7D+i+lXKVSnmPy0O776AdH/ceNyY6OTrZ2Njw 2M3Gi90SqzTRWFWsyqTGqmO3mVhsXGycSY/dGbvTZMTqYhNNPDYldrdpcdZ92Nrl9jDtPUVmL6ZQ RsOiaeF6n6wPhuscWefJukDWRW4tHCbb5W578lq08jO5IOOzVT7bou3IVxc0yZLatVW33UX1eb0K UvOG5g0t6FHQo9uhglYi9c4bWthaPxe17NqqYEm33XmNsgwtml6YVphXpJZegac2YtW7a6u8Rtmj sWubrq26tiqaWVQu2i5dWxWmFeQUts2rLkgt7HhixWdhma7d9hb01rUwLa9XYVrRY8dXYju+EGNB gYuxsLXsV1JUrXLR9KKagj1FLbvt1kXj09hcXAVNknuWeM7SiMR7GI/413h6FA6ROGdJFHM17oJU V36xKyoaXphXWCS5yb4FXSRHkYsq5VPfwiJtJe9hT8Zo77ved03M+573PZMWuzF2o/SAkbGR0gPG xMZIDxgfm2AyY3fF7jLnpK9L/6VplX4w/aA5L/1Q+iGTnX44/bD5/H9pjLtW1mpZJzDK9eB7J8NN P/lUFo58PbCTGQEj16CT7HqwZ/4JO0/GIfIll/bkcoE+ZfAel37uSb/Wnm7o6T49PUpPT6Gnx+jp afT0dOnpU0wcj1oGQxkCytC5WdzLyfsidC5qa9aepHs1jPtku2eJ2praUJc8bv31ov9Oi2hbZGtb sI9hH8s+HvtE2CcV65g+gzk9N/yl4ynz/1kXntRFBS3o2qEnZdT3UoaHdeJ0nsmjFQc1s9M67MEv 1jvdZ62VvE7+59pQ466T/B4M47kY3bO8SzOpmS6PVqxspnuEVhxyQnd29ff3b+VkdWHNKrOBWUEb /Q+BzteeWK/uXCpLduehncs7DxdWyqfh6Kqhk0sltbRzjSyVnev4rHJpuEyXpbTzzHAtPcljVJZS 1uP+jns62U8NW02pJ/9q91nLEhsVGyVlro3JkRSbHNNec9bnJrOSFgyfceaOkHWJuTp3kSwl8KkT 20Unlqdyl5+QV8oi7LSi0+xOE3Q5yfIXnVawHv/sPC1n+5mH5Sc8OT+TctOcptMwWdd1Gt1pXe7q 3NXKTuv0yIjdGhv7t5awk1yPdPrIXN1pf6eDnY7kmtxobkZuS6Fus3Pb5+Yi5+cWC01ur9x+omuf OyC3VOShueUslWKZnVstS69w0X2iJzzW5NbB7Nx6sVFv0dDT9NBPZaeDkqaaKHvrOoCU4ZRwdGzS f+H84cm4Ksem/VJ4HPbSf8GwPWxvLbnNb6bNsx3NEtG2aqZtaaNmjnxuOllrjlrP1Mvnd5tp95iP zGj5/Hoz7UbztowD1qw5SavjSC/59NQJ3dmMDy29Bm+xWDzpPSWj4A+9H8qMerm3XPZc4a2QOlnt rTYpUifPm1Tvl1IzMe81b6OMH697/2Hi3mZvs2nhbfW2mixvm7fNfM7b6e0Un+9478iY8Wz6szJm /Fxm4+fKbPw56RPHa1vn9t+GD8PvwUfgPPgdLZH1bZrUXlZYokvQZVv9/dWjJ+vMdrU7UXNOd0Bs rNnUTLdfbPRcebJup9SxnitP1rlvhc5vpptu9FcrZzbTLTGrOKeerJtlGuTTiGa6Ktq7tJluBmem ns10rTg35ZzQfVY33+ZaTFvQMOpaRl0db2s4p9nY+JPq8FE0o+HIk2r14bBuVX87OerVm2c6yvnG 5dn7xHWdlWssZ6eskZqvN4GUK1fK8Y/1f2/Vo7jAK5ZjtIfXQ+Se3o1yXOq/tBRkdsu80RRKy2RJ ywz4u0f6f2WVI4V/8DH2Q/sXGW8/8VqYtMy0zHzTwXh+qgmko/+9Y/zH+o/1H+vfb/XM1cY95xpt xso1iD7b6iCzgJ+YTvy72IXmRZk75PGPYpfIbOttOTPulqWP+aMsffmPsUv5j7F+5pAsXzSHzSdy 1f2pLCXmmCxf5r/HBvDfY5fZqMz5BtpUGzOX23Sbbq7g38hK+TeyK/k3ssH2HHuOucqea881Q+x5 9jxzNf9PNpT/J7vGtrPtzLX8S9lX+JeyMtvJdjLX2c62sym3F9oLzfW2q+1qhtlZdpa5gX8sq7Dz 7Xxzo11gF5jhdqFdaG6yT9gnzAi7yC4yN9sG22BG2iV2ibnFPmWfMpV2qV1qRtlldpkZbZfb5WaM fdo+barsCrvC3GpX2pWm2jbaRnObXWVXmbH8I9o4++/23814+3P7c3O7fc4+Z2rs8/Z5cwf/lDbB /sr+ytzJ/6XV2l/bX5u77Cv2FVNnf2N/Yyba1+xrZhL/ozaZ/1Gbwv+o3W232q2m3m6z28xX+U+1 qfyn2j/xn2rT+E+1r8WviF9hpse/mRkz95y4e50dzmT66LwlOkSfbWauz9wimlMt+qpF+j+fweJS LBrOYNEPiyVnsPiiWrQoPcVC7z20CVfD3ZrTY21u0z9ptM1tSpLG29zmy0kjbm4zIEnMOjttj6Ur 12UnpbroT7cZ2NxGoj/d5vJTbBqS2Aw6xWZJEpsrmttI9FouvebQGS6/PC8ppUlr+lSrK9Uq842/ YjUYq61/xeoqrLb9FashxDzplBpvLdcCzrY1VlcnrfNTrYY2t5JyJLO65hSrrUmtrj3FaltSq6+c UveTuEptfcLOtVBZkuhPt7ouSfSnW5Unif50q+uTRH+61bAk0evxa6V/RWRtTz8z5oakveJ0u4qk /eJ0uxuT9ozT7YYn7RvZctVmuQ+XzT7G3JS03U+3G5G05U+3uzlp259uNzJp62efsLSh3S1JW/Z0 u8qkbXu63aikrXu63egk8fnYHbd0/WBMkviS2VUliS+Z3a1J4ktmV31afNakiW1V4o8m/KcZkyrr fSc+pcn13ufd/95wrd7srlvmIVmPmqszD2c2tfBlTWuR1aK1ULdt5XPHFnmyZLUoEvZs0Vf0JbKk iX5QiyEt2rJUhdu27Hfy0lrs0loUiZ/x4qNWtmrjh6k9ZZ3Soow0t7euZSx5LSqEFS30jsTxO+5n +1Qv05ZTwjopt8nqJWu/k9YBspbKOlTWclmHh3q123rKuiPc7g7lvbJWylota437/LkZ5uqMaVkZ WS2F2Vnts3Kz8mVpn1Wc1Stjmi5Z/bKK2Q4Qq1KxKc0amlUqn3NZ+mUNzxpOeqlbwr2Oe6zEY6Xz l1WtvvD0mZ8a+dQrKyM+QOTyeG5GVca8rHLhtIyq/7n792d5T/dt25q61+/WmnierEWy9gy3uvaV tSTcDgrT1G5IuJZJfU6Jt5dy3BfPjxfHe8X7yTIgXppxX8YUXUQewLafWOXL0j4+NF7OZ1lkWyq2 ml7ulnCvzzxWn+xPfYWejvspjrcXy/bqK6M248GMB+PD45WynZLx4N/4hOdv6rmZ0iMzpWdmSo/N lB6bKT02U3pspvTYTOmFmdILM2tCu5myzpJ1rqyPybpQ1gZZl4ZpT8taJ2t9uMrn4jXm6ti6eFm8 QjgyPl6WWlnGZ2bHp8XW6RK/Lz6Fba1YzRGbOfF58Tl81uWp+KL4ItLnuCXcq7nH8WKFP/WFp8/8 jJdP02StFXlB2vjYsti2+ALhutiy//Weq6PmEfPZPX6d5Uabao/tPr78lbuqam9pPb0Duj7B3VHu iMoIfKTy2LZmI3eGSTmy1VQl0T6YTHv4xbPUSima/vT/RSOl+HTi6TF8ui9ZZJ8+nkz7ye/OUnt6 7mJ3aEKyvf/iJ9MenHqW2qQ5HZ6XNM78ZNpDi85SK/V39IEk7f1s0vq79v9oL/j7arRmfpOsDo5e /t/pb4lzopmS1++VJuY/pzMtf5XMl36cMlC4GM6LyhHuPQ/3w22qj5yvcmQtmo3Ir8F8NN38F4QD 4ZWOqrdNyBuVdi/y83AK7Ots8JOBn/6qT3zofSianGC1sf4cf7nM8Ap8mc35f1LZfw793crgJn+Z yE0q26nKyFBSH0dzdfDvck3VEksL78DDOnxWwDiaqfj5Z2zS4DnKlMF4ewc6/w2RBi07/EFklnBz sFJrRjVeWfCyyLv9TsJnVGML/C7C7spIL+Quah9tGXr4kfAF1Xv3+O1Evjki8dg/+xeL/HP2elQZ TESuhgvhvyqjI/FzVBndSY4TVO9H0e/Fsgw5m7xykGdieamfR4TC4ENl5HWlj8a7C3lGZKvYPIDl SGxehsuV5nw7THsRjMFUu01acL/3M36rtlg0e+w64fbI+Rq5kbm53elpPTQpI+d7+8WyWGXvCeT7 I6XaH5D3w7dU4y2GG1Vj26E/rDRHInrlekTlSDXMJ3Wj30bL6/yo7C1Fvg1uw/Jl5MWwAnazcpb0 hhJPN9iXaH3kLkqzx1+hRN7lNBqD5K42/WEF+gPsexDNW8rEAb+H1OqQYIJwRdAoe91Oi0wm2mrk R5EblGIzgT4vlv6rSm8xe+WjaaOpkXexmRRqGunJjVpLWGag+boymIjcG/tH4DA8rEUer6kp52Hz COyKh0fx1qQ0CWLLUJpd+HyBmKe6fkU93+ZfJHIKfeyc4BaxuYS9+rgywlJl4m0dl7wnEq+KpnVC jnqP5/eRHJVtO1IXa6pXgbwZeSWchX1NqFf7g2iK4UDYsmmE9j21kVR9f4i3BrwueOjCXnvh3djw /oH0AKXPSPoC1P/ulONI30aQlh4nnIOf/U2rtOzYbE9ERa5VOSAXsVfLmU06MizW96vkSFA9T8z9 C5Anw6lYjvUfF8ub/LfFcpjXR2WvTGrpZ94M+DO4m9rYJdxNv4p7Mgp5lqOpDM6n113l79N5nv+O aL6vniM5+K9AfldpD6JZg2YmLFP6bdB3QbMKvgZvVwZ52HwXuRXyCuR6fK5DMwT7+bBWaY74S4Tr 4TeUNht5kVKiUnkX/AWatnibSySpoQfV4NkrRi6AG+Bq9PNgDZyBfiT7mjB3lYnTbIfL4IHQRvkY nA0nKBOVyFWwn/qJ9MQz7WWXkNdGSrqJehjkvCW2w7e1bhP/prWRWKHlgvuVoteRpFFpC9CsInUN HIh+Ltyp9IdgUwZzYAZ8F/vF2LyNz/XsdRBmw2nYzMK+FhvD/ZJB0CR+rbP7xOtG77WlIaumfeJT mTOsVU3TJrhK6bXlGJnLUZBK/1+PZiSaYuQCd9yRWoX8Q1LnwY3uSEc/DZsj7thE/gkzlt56vZG4 TCn5qtxGKT41hinwLjhBKeX9tfYlLYUcI2nIjB5aCq8Km9Vwbii7yPWqZjbcA1+Hi+AuchyLvN0w S9EjznxDfFg7OLxjpYwR80JKMTAsy2N63kGOw/5wN6XeizzLjSSwQu0jvHNrrwnrVu9mHUCzBE1L 5OudvfiQvJT2IJyrNEeQfwjXYdMFLkVTgByH/eFu9HuR18BZcL8yUkbqS3AavIZcDmDTF81guAT+ ADaRuhnWoCkn8nJqvlxbyg5Bvgb5Gm0jKbXrjdo/C6nV88OeYHj/RvsMbzr5A/D2U1gStoLOLhZg yT9m2w3wJfgDd6bA8lyO0AEwHV4Be3O8fx05ChkJzQUwKxyF9GgajOXPlMeuSkwn5gfhQjgeFsGf QT37BKF+EvyKUub+Kv8STldvnLPMscOkitz0RtAk+jejcs3d9EE0Xa8XlDJeLYOvKKPcGQ9n9Yfg PUTobPTN7nGhTDyRj5H1LqkJ3kd+Af17yK/Cf4bDmeOtQyZ+rYHE++rftCKXD5GNXwkpiy9lbHo7 RVrk2O6Uvhp5Sg2aGqItIV9GyOgHMBP+HG6BdVDHbZNyP+wLU9mXd5WjHZGPIN8Bp8HL4L16jASL 4PMyMg9L7Sl8Sem/o4z2UXrQN3Ai+mXKlIeVFnsPTSo2Ke2UxtnvI/V6uFwZQR/sQsaDvxnNr/G8 Hbk/cgA/h6YEeSr2k2ATeWXAHFI/wvIG5Bh0nm/CntRIOppPSS1C8wc07yH/CDmOfQtYDz34AaV4 Ak5A8yiswdt1kMj9auhK3Qq+gmY2rIR5sByOgJTRv51IXGyXUrpnIKmpLv6fknon8lrybYs8GBJ5 5G289UZzjzKNNorRXqlVEH1kIf7n4Kcb+kHop7PvU/jZAh9AQ/0HtIV3gH2zSX0SD1eS2ogH9EFP 5EXIFXAPLEZPD0ncpP1Q+Lxe68Fp9MxRej1o/yXaQvunHh3BS0r/HWW0j9KDvoET0S9TpjystNh7 aKSHz6eHz6dvz9ce6zyonNLOeVbZOG/7nE/VeNdjuVwZITXYhUwu/mY0vyb37cj9kQP4OTQlyFOx nwSbiDMD5pD6EZY3IMeg83wT9qRG0tF8SmoRmj+geQ/5R8hx7FvAeuhBxhnvCTgBzaOwBm/XQSL3 q6ErdSv4CprZsBLmwXI4AlJG/3YicbFdSumegaSmuvh/SuqdyGvJty3yYEjkEcZDvzeae1yb0nbb 4WaljEvzGYXmMy7Np5/P135OXlWQfSML8TCHvLqhN84eeRA208nrKfLdAh9AQ3sFtJ13AD/ZpD6J tytJbcQD+qAn8iLkCrgHFqOnXyVu0tlv4vqE9PYE39LwftR0tfAdeJcy0lZpoWdgH/TXwxeVBnuL xscmMge9s59Maj4cBmegP4CMB2883M2+E5B/gOzBVDSLkL+I3Bfeg+YBOBd+FfrQ+fwxRG/vRz5G 6nloPkJzEHkzMt68FNgPWng3NtfAS9BcCXvhrSu8AM1F0JU3Dd6KZhAshq1gEcyBF2P5Xfh9vL0J KbUfYPM7Up9B3klqJvKT8Bukfojs2us5ZeDahTbye8D+WL6Kh5fgueg7oWcv7z/g7fAy+Cz8OTb1 7DUbTRlyLvI2Up1+AfJGnSNJvxpBv1Iuh30gMyjj9B8rpReNoL+pZj7yn7HJSxzSOy3MMFfRVw8z zxwGo5C5fYQ344NlaNz3lvag4SogwnvuAd/D8vnmgd8Gby/CNU21eg+EvZ5s0vfdX0dTq7Q7makO RsO3KSI9VU7hCst2hO46ogL7TPKqx9vrWooUrssCd72Q7a6z1NIbqAz6Kf0oXIH+sNI0uvswTaU6 w1d692tskdfc/QryGgtL8MMbRjYTP1uxedddzVGf5crIckqxib2e1nsgEXfFx/v9PqOBHH2a+g7x N9Ii+/E/HA36KKWQ+pHUYL3SHwIXyvWoXKeQ4xL89yTfBuwzyD0Dn1OcB72HIyektXrFp5SyK1vC NXAGnAKLQ/0mals5D81S5BnUXhdYA/dzn6eGSPiehB/e3WqaqdfFqpfcG2gp9fCi0hwJS6GtcCD0 s4k+sIma3EStuhxVsyG038QotwnPrrfXYtmA3EDpVJ9K/exUS/+L7goID1Xw+3C966XhcdFAbxlB u7vWrKUeqH96VyNtVE/rZyE/hIdfuutT7PvSsnM5stZT9mxYR88ZS1vUse8g139cPwmPoJjID+i+ Ue4eBLM1NcpTDG+0+vHfJ5dt5Pswsc1WxuiNqR8pU7jPEF0dephK6whTuPqOjlQ5MOiXUnsvO5/k 9YQ7rtGk6p09u1fpz3T9ijjXUqIS/TZswP0N7067XfTtsJlPibKRR9C+RyjvdjQNaB7D/240ZdTn dDgetoFDSF2F5VLuIm7Bs48Haib4DUfEDDfiERvjQKQTUd3Fs5VZcDFPW3KQN/P8pSPyp3AKqWUw Bc1SeFe0nbADT206oOmC3BIPc9EMVJp9cJezQd6Ot2r3xAcW8zxoCTwHDwfRvwXnhU+jdB6ymWdP OcqgFT7nhbM7tVkTztkG6j0NZsIdQw7U2mYekhP6UV4ZLde+R44+3oqJbSb51sBU1fhD0K8iwgL0 S/F80NUGnr8E8yFzOe88UhfAS9hrFvqS4AM9K6H/RcpoHU+4CmaO5FWgv5gcu5JLHZoaai+BPAPL bTCupfDc87IIZfmta1+9mva64YeZcKQ79muoqxeRh5JaitwWmTmttJT6/Bj5n1yt4vlC4sl2sntO R+Svk+Nu2JKSrsRmGvJ+POwn323uWSGa97BfifyWK5d76hckNM6w1z2k8ejVfaSPypGZeC7A8jA2 jyJXkNdiV89Rfa+khNSppA6l7TaQGsfDTiej/4R7HfuQR7o+r3LkdpiCfp0jrXAA+U3kx+Ae1+eD +zR+lYNl8NuuP8tZS8Y0bNpSt2vI/Qk0rcInpNM4aoSW6zLxiRw+ex2jvTHsk2o5hXq7n9TryOVp NBshVzTeQHgX/X8fxw7XWZERrq0pxb3sey/yB8gfOJl9I+T4HpEchHO5dqC3pxB/dLAyhf4ZrCee HytT/5XU76DvB7mqitS6OsEPkaRQG9Gx1DbXEXaaG0nIvQuRjHae8TCb+Ge78SFaT/3U008eYnRS uSzaWzx8D5s+gY7Y9wcZjDn79VpPbcw7Kku788wRDoLc+/KKSN1O39hFnaxWP94PwvGtvR4j0bvV fzgStmcEU/38IFVnkuT1NmPICjidct1N/C9TP5noGW8DAwvRfBebBurkNaXfRhkcQbMDTTrsjeZ8 ONn10uBjkf+E5l34IZZD9D6b9MMS4qkn3xLG0hJyF6Zwdgjqyf1dbIYoxUblNtTtLLhG7WWsqGdf ZRUsVEYaOGbfha8FnGsCd3TTn+EapZ+LzQ7kdGV0SUBvUaY8Qw85j7JfTwyv4n9y4OIkqsAdZZr7 IFJX4fMT5E+oT0ZF36Mefoz+ZUrR1tlT3qOBO2bredapEW7Ez6PIFdTq+Uq/N9EOI3UTey1y5zV3 vgijLaH165FVfwV5HXWjpfMf1qTm+HXkvvg8Sqv9CZtummPKt/CznXwn0XO24PPr5PULct8BOe78 hbArrXkJ9huQ81wvcjI2v3d+4CNYUmPBfcj0dqnVVrS+anqh4RiMPo08EZ9VyGnwBVJvZK9h1PlF 8G3K9X2Ol7ZousLfwysYB0qQLXImnjkGvdvgMTysdX7ckYWcw16HkOez1yB3LlCm3I83xvmUGheP G6Wx/Daa95EZjaW2NZUzQgpnpeAXeG4ILqQ/X8jZ6jra60J674X09gs57h7Re1nkyFkyWo58OXI2 eb1K5M/B9/G/iGhfdLLzA9eS121Y9uaImwVrwv5fQuvocX2PekgbrnLsEZVTe0KPfJlFxIo4mnjT JmAmlrIYD9fSV9sgLwvHB6UNe74wbSL2vO3j3xr2bWU0cH2shKND5avQX0EuPVSOMnpHR1PDY+jt 6/X5ReT3wSZhHXUy0f+SyOn+Uu3h/iyxZLZpX1JZjohZei8OjlDakbRIP93Ln6i1JD22t94D9PWK oE41drPm4jOe++78wmh/bGj4dOZeYQvkFuFzmV6Q5yaJr8MaeC33l/Yhz9ZnHGqfOJTYhOYRPZur H+8uZaQ18iy4Bk0f5M1K2xFuQFNBahnMQTMPOQN5P5wCl6J/DXkx/B4shl3gQDzHnObY7/TsRunq kXfhoZrU/qqRqxi1Hwmb0L+FvFNTPRfDZpX9i5A3kloAs/F8BH3qsW06J0TOI5cRyDVYHsRbXxch 3oZgswoNZTfbnSWaOPaz8LlTGUlxMbuyq8Yrg2uUZg8eXiB1pWuFY0u1XHAumtvw/yZ7dcFnDv7v hpfDdfi5Cpv9sD/+f4K8GZsC5HhYLpWL0XdEnoHnmfh5w9WMa2VSV3Kldg7209AfRv88tVHrWsH5 ITUCh6K50smudcKaVD9vai+1v1VKT9AeewT9J+zVFvlG9iontlLyKkV2ddgNm8HYzKW8+1wZkR+D B7AZCb9A7i0TuUos+4aRqL4bflYrg28r/U81VeRcHU/QtHGxuWOk6UvaIvBid7wgFyttO7y1U9ns UkZak9oNOSfxbW0XroUj6J+AS12NOaKZAfu6VNgWzoMrsXyFOvmS6+cuHrgfjoZvYdnS9TQ0NcT2 Btzn7v/g5wZ3FGDzItzIvtso12A4En5AGf+AzTN4/hb6nXCsGwGQx9B/emE5xXmDEdfi1MlrLk54 G3s1Iaci15HXFvrnHt0rtafKKRzX0XJYQttdr6kpjGnRC1X236cd21OuqUR1HX2jCktGuajz77s+ 4yI/NoWeo1znYnYjA/eaItzRmo3P2Rz1T2g/kfEzl/6cy+iXqyOVG5FgH8au+/HTl/GEMc28g2aQ GxWxiblxTxmpduMh+ib4JvwtPgc25QsNchGW9UT7A3esUYcfcy+0D+T5vjef8v7ZlZo3TCr93RLP FH+oyvT257l+qeSO9/M8N+zm7o7qVaFc5c3lqlblRTzL3sNT7EUp+sZgo1JSS6Ba8pQqUhbezejC nYe2etSo7G1DUxt6foCZrciROUqZJ+s9gf08Tz8S2cQcoKPOCiLv6r1ifwjn9Ae0vQLuyuqTfW8b bzis4628VSaPUbq3jifwaThYGSlrmo+slu+qHNnk7gGqxo/qvpJTnl4HKb01SnNEKZGp/lb0+5Up 3DsN6nmProx7bgX6voQ4Kodz4RbuKem7AXv0Xoo5kLJR9fqGgKTuRV4KO2he0dXIek4/EL0Re87v 0Z1cy6+m5tEEcpY3PdzbBViagN+5471Hg6XRd/OMSXkCTTmp65G1/tcTz/qU3crUqXCmtmnqCO7+ NXD25A0KRg/T1BPWwgzmFW2wnMmorlejXKHYHkFE5I+DZcjaIjn+UT0D8o7fx9ic5/M+arSHcGug v5GzV+dCpr2vM5xCUs/3uwt7+foeRX9/ACX6AlSblv4MZN6y8C+V2c5f/FzkITAP9oaXU+pieC71 cAP04bOy72p981Dkz2P/JlRNIWUxvr730hjluIONKeq/HjZGkWFjSn/0/ZH7IffD5pvYfBP5IWS9 G9CGPtwmGAD/rIwugj6aQVBL3Rj8VvuD/zryq/jR+eGBYA7ydjgNlqC/gxgq6EuL2Yuogi9L/T+h b8sIv6MMboSrlLqvsCOaRci/MHr/87vK4DtQLZdguUSPWZE19zcCfavnjeg19PabkTWSN+ilK6Ib hM8r7TXBJ1KufH0Dx8vH5371IPJDcI4yGkCeHlIb+Sme8DH/Cj3W/O8rg68hf4o8G65XRoei3wz3 sZfOQ8bqG0HCf1MG12Kpubfxj1AbOidvE72ZsuuvLO0g8r2au+g7wOtJ1behdnD8FvjP0C6l5P4d ah5Gx0If/c/Qf4UcRe/d4w8mNR39O8h5MAPNN+AF8AXadAN9RseHvcHdSn2LSWRtzae17F48uExn bv5PdYaj9OLRO/UMwj3nacGTqofTgiHIQ5C/hvw15EeRH2Xf1To/IceC4C24mAifgx9Qlln0sQ5E +AF63Wuo/wZ94xzhTzQq0T/MaDYCag1fE3lFZ5v6fpdd4PdRBpcI3wuqlbTye9HZUHvaeykFyDfT h2X0Nn+M6m8U7/VHqRxo63QMKvXsoN9osB2jF3Om0GNtL8fIH6PDRJNGvoP8F+H7Wqt6TEk7Zuvc w3+P+H34ojK4FV4IH1ZGu5K6D01vPYNEXarT3wHvpESdhbP1is8uiOibM7MjdyBvQX4AGY3/JJrf o9mP/Bv4mtLTVn4v8hPxPMr7BvWjd+ZHRToiX4r8eeQvIp8v8jitB9MY+Sn9RMfwo0b77V4zG/Ie IL85FzM/gpPR6BnkgHlE68TcpXJCx8lGeCCRjZyNjaTa/ISOJA3mYuSFKifWI38TBnAwfBA+iZ9P 4K2wUsn55YBevYrcAZ6LJop8HXJvWAiHoNfvtu5tamn0WvVb8BOo7VLB88GKppvhfPR6pn6IaEfC hzRHYVfVwJd4UllF6mS4QGMTvb6lPy+Rx8z8Ofg75up/lLlB34Sex5do7naJ7iWz9D/BDlzX3Mt1 zVJ4zOhVktbAjmM6Q9irFD9/0n3ZKwU/BWEtaVQFWgo71jGRRaqyrkmf18QpdQ32u5p03CvRtzSF W+Gv8NyBCLOQa/FZS743oxH6RepBru41958khht9u0NrL5KYynx4FrLO1bdgs4XY3ms6KPneS0vd 25QQXu5aLbFDUm/Bsov+NonUuea+IKFv0nYhdVDi99qjmr5K6XKo7X14lrO/Xd/0L3qEqr2pb9Jj dguaAwnOcaoROQe5FKqHHzdpn/zxMRmv7C73vD6hz1z26nwmscjXN10/9XUeeySoF73P+5mP8/by EXOL2MzmvLlLR3iZv7mxegF5yfna/Jv2PTmuX+EYfwo5wlG8g2P2Q/SXY9+dqP6F3vUrRrwXwvd/ 02ylzOuCUXWjRpucMV+tqzFTb6u79XazaOyto+vM+ppRkyaYLVJf3qAvl+WYvOvLBubov1wkEnKk BqJPNR1MrulhBpoL9bvJ6KPmc8KOprO5yFwu89Q26NNMimkp7GS6mO6mpxlkuprz9V8RSc00rUxb ky99tq/pz+/TXiHjxDBzk6k0t56wamHONe1MuukmI8alEoe+0VRqyswNZoQZZapP2HnmHJOhUQ8p L80xPcvLrsoxw0MPrU17EzcF5hLTz3yZ3zm50lxnKszNZrS5DZssc565QCIqNMWmt/miGWCuMREz 2JSbG81IM8aMDa2yTY74KzJfMH3Ml8xl5lrJ/ypzveR0i6ky48z4MT0mjvGmwwfhI3AhfGrMqJpJ 3gq4Cq4ZM+aOWm8d3AC3wJ1wL/wIHlVGolU1426LZMFsmAPzqibceUekCPaEfWEJHFQ9bsKoyBBY Biuq60aNiYyEY2EdnAYfGDdh3KTIXPgYXDhu4p01kQa4FD4t2Y6KNMK1cEPNhMl3RLbCHXA33AsP 1Nw5piZyCB5V+t4dt1aN81NhJmwlhnV+G5gDu8AC2ONO2fi9YQkshdfCilplJayGNbAO1tdJiP50 OBPOmij178+Fj8GFsAEunXjHmFr/abgaroMb4JaJE4u/4O+Ee+D78CN4WNjDb1IGPkyDWbC18KKg LewI82AR7DlJog36wgFwMCyDwydPGDcmGA3HwglwEtRvWEXk2OvK74yfrXT8l5A+Y0SO5hS+p5Fc Ujt9gcKTvh800ySTPBkBzkmytXJcKz9/RqafQv0VnvP4BZSzlayJn8a0U+jLMZ0lI9g5Z5CtyT0j 3fd7XLnbw4zT2OYM9GT86XAWW2s6npGZp/H8MzAiI3YXGcfPXjqzP2vanZFtz0BPxtZOZ7E9Ux69 TZ2Zau4zs2QeucA0mGVmh9kjM8bD1thUm2WzbY7Ns8V2qK2wo+14W2en2vvsLPuIXWAb7DK70j5r 19mX7et2m33b7rUf2SOe56V5Lb02Xkcv3+vh9fUGeIO9Mm+4N9ob79WZqH7tw0vlPKT/PMI2lSt8 Y2NLjEo2tszovMSmV7nP6S/L55g5L+OXGVsy9sZNvGW8S7xfvDxeHZ8anxtfGn82/mp8d/xoZmZm x8zemddmjs6ckqkzVP09oEZ8eZmvZurdmZixLVqH21y3PbeL235+gOQm23Yj3bb9Ipd7+1+Gn5vw lHFBwQUlF6y9YHtOfc4jHQo6DOuY07G8U89O1S6f3La5+UTr5fbLLXMecme48uXONbzzmftY+PnZ cLsl3H7ktp0zw+18t+0S2nVtDLfHP4f7dQ33yw/3y88Pt4PC7ehw+6rbditw26KMcFsfbiVd2+cL T7m4v7DO1UyPHP3Ov2zD8vTYEW4/ctuL/pO9846P2tj6/hnJo11szQgwGGyMwQaMAWPWBTCmN2M6 AUIP1RTT7BhTQghg02voIVTTu+m9hwChmt4JPRBKqAkd3qOzYq/JTW5y3+dz7/PPs/NZaTQajUZn zu+r0axWCrDmday5tT6is3O7iBnOciLSnPuJOGgpH68HaPQOsL+iYFot7K8AW8vWgmKLskXRk7D+ y++O4p3NXhsLUCLUaLcmqLQo7N3UwB5UM+z9dLb0MhzGwVRIhcWwCjbADtgHR7EP+CPchPvwDN4w N6bbNoBqW25bYdtI8zTbJpqvtG2m+SrbFpyvwNhWmq+wbaN5mm07zVfadtB8lW0n2mKFbRcupWHu 3TRfYfuO5mm2PTRfafue5qtsezF3mm0fLq3E3PtpvsL2A83TbAdovtJ2kOarbIcw90rbYVxahbmP 0HyF7SjN02zpNF9pO0bzVbbjmHvV7yxivk+8Dwz8WxY5QUe+3HbSsswpyzKnLcucsSxzFvez3HbO ss95yy4XLLtctOxyybLIZcsiP1oWuWJZ5KplkWtkkeuWRW5YFrlpWeSWZZGfLIvcJovcsSzys2WR u5ZF7lkWuW9Z5MFfWGQKzIKFkPanFvnFsshDyyKPLIs8tizyxLLIU7LIM8siv1oe85tlmeeWZV5Y lnlJHvPKss9ryz5vLLu8tezyzrLIe6dF8IRMFrEzp0XsitMidtW0CBKaLGLnTovYNadF7DanRex2 p0Xsmf4Ni3wPh+EUXEKL3IUn8IopzN3u7rSI3cNpEbvutIhdOC1il06L2A3TIvbMTovYszgtYs/q tIjd02kRezanRezZTYvYvZwWsedwWsSe0+kxdm+nZew+TsvYc5keY/d12see27KPn2WfPJZdCphH as9r2cXfskuAZZd8ll3yO+3yb1vkvssigZZFCloWCbIsUsiySGHLIkXIIsGWRYpaFgmxLFLMsojD skgoWSTMski4ZZEIyyLFLYuUsCxSkiwSaVmklGWRKMsipS2PKWNZpix5TDnLMuUty1SwLFPRaRnz zGDW2zwPsAlIeh26m39/xHOCL/adHGivKnjt2UQ/iaSvbP/EbYJ+yopN1E9TrD6mnbFiE/WzGKtK +c5ZsYn6eYqZ+S5YsYn0LpT8eE0aie1RC6+fWyPVk6A/DNcvuvZ0ybWny649/eja0xXXnq669nTN tafrH/ak38NYNXtlTLtvxSbqDyhWFdN+sWL/qkY3XDW66arRLVeNfnLV6LarRndcNfrZVaO7rho9 dNXokatGj101euKqEWqfhbAQ7ET6KD7YT8un5APzDSx2YCKC+lVJ2GqT8Krjn+qM/cj56M2b4AT6 8Qv0YJ15YS+yMItg5VgMM0ei3Ty+A4XeuODmsccV+/5DTDmCsakUO+qKpbtix1yx4xRTsE+lKyfM uHIDp1No3UlXrlOu2GmKqXgUErIpZ2gLsyZjFLMWkynP2Qx5vBSzTlOUvaBizinKOVdJ512xC67Y RVfskit22RX70RW74opdpZjNGicJRA8oAWUUPEcrM3F/B2ivM5X9mGumgmdsZRYuH6TUWcoPmDpL ueYq67plC5syVhmH7ZaqLMSci5Xl4K6kKWlgKKuU1ZBZWausg6zKBmULXruqdJWQDbXG6JnGAMHg fBfhHFyxTFmGZa7D/KqyXdmOPTr0AGUSPVfOfMec6Q9If7qmNcesVGWaMg1yKzOUGeCHZeyEPPSc uPL0nDiz/Cd4TeqLR1kBOdgCuiMB58JyPCfecbahmhXLfy6agsJLWSnVKKU5peBRipYYi7LWVad1 TTLkrkEpzVy5P6PcnN6JmBOvMvPTNs9oP49FY1xbmrb5lfbzhLZpQVtn2Mbcg/LMrBVu08zMbdZH eWLmVF4492zuSfnNrJ3ylEppbNaE7PXY/McXL8VLo0eZY494DcLon134LUpvWrnLzF73qQxpqvls boZ9fLYrQypjB/G79KNt05j5u8/Uj7adhmE+pg7OkOrGBlMYi+ndPyrTvBu70UdlNjPfncqqfFRm NAbzVxnHR2U6KGDLMp+PygzBr/JRmRrzBeuJEx/KRG94wszf7S5lLBOXzGC2xb6MZYJ57ZaWsUxY Q+/umvFRmbMwmNdGwz8qczgFtAkkflTmBDCfwpOxzJZgXqnFfFRmDQzmb/kRH5UZQcF8OpWfK/3D M69V5aWKx6+6qzq4a0O1YfQky4+f0O18BrfzubbOZ21/eBY49ni0YdpQxRyjVVUSKZbkbo73Y3kK 1dy8Yg229htCNXfQc9Z9XGlmmfP+Tl3keec+1Z+13KpJfqbl0WgEhY2GPepdNY8apBZRQ9QwtYSa og5Wh6jD1ZHqWPVrdZI6Wf1WnaXOVReqS9Rl6gp1pbpaXa9uVreru9W96kH1qHpcPa2eVy+r19Rb WNZ99YH6SH3Cg3gwL8vL84q8Mq/Co3l1XoPX4fV5I96Mt+RteUfehcfzHrw3/5L35wN5Ch/Mh/Lh fCQfzcfycXwCn8Sn8Kl8Gp/BZ/FUPp8v5sv5Kr6Ob+Rb+Fa+k+/h+/khns6P81P8HL/Ir/Ab/A6/ zx/xZ/wFf83fa6pm0zw0Q8uieWo5NB/ND487r+avBWj5tUAtSCusBWshmkML14prkVpprbxWUaus tdBaa+21Hh5rPNZ5bNAVXdPddaln1b10Hz2Pnk8P1IP0wnqwHqoX10vpZfQKelW9ul5br6c31Jvo LfTWeqzeVV6VN+UdeV/+Ip/IZ/I3+Uq+MxTDzdAMu+FuSCOr4WUEGcGGw4gwIo0y2Co7VbtqdtHz qHnQEwqqBUHBVimC7VZULQpuaqgaClwtrhYHTU1Wk8GmDlIHgR1bawhkUoepw8BdHaGOAA91jDoG Wfm1+jUIdSK2uMRWnAwGtuS3kFmdqc6ELOocdQ5kVReoC8ATW3YJZMPWXQbZsYVXgBe28krIgS29 GnJia68Hb2zxzeCDrb4dcmHL7wZfbP29kFs9oB4AP/WIegTyoCcch7zoDafBHz3iPASgV1yGfOgZ 15DMt9RbUED9Wf0ZAtV76j0oiJ7yAILUh+pDKKQ+Vh9DYfSaICiCnhMMwbwMLwNFeTleDkJ4BV4B ivFKvBI40JuqQCh6VDSE8RgeA+HoWTUgAr2rDhRHD6sPJdDLGkFJ9LRmEIne1hJKoce1hSjegXeA 0rwz7wxleHfeHcryRJ4I5Xgv3gvK8768L1RAb+wPFdEjB0Il9MoUqIyeORiqoHcOharoocMhGr10 JFRDTx0NMeitY6E6euw4qIFeOwFqoudOglrovVOgNnrwVKiDXjwN6qInz4B66M2z4BP06FSoj149 HxqgZy+Ghujdy+FT9PBV0Ai9fB005hv4Bmhiejs0RX/fCc3R5/dAC/T7/fAZ+v4haIn+nw6tUAPH oTU/yU9CG36Wn4W2qIeL0A41cQViURc3oD2/zW9DB36P34OO/CF/CJ34U/4U4vhz/hw6o15eQxf+ nr+HrqgbFbqhdmzQHfXjAfGoIQMSUEdZ4HPUkickop5yQA/NW/OGJC23lht6orYCoJf5Sjnoi+oK hC9RYUHQD1VWGL5CpQVDf1RbCAxAxTlgoBamhUGyFqFFQAqqLxIGaVFaFAzWymnlYIhWQasAQ7VK WiUYhopsAcNRla1hhBarxcJILVFLhFEeqz1Ww2iPtR5rYYzHeo/1MBbVqsDXqFgNxqFq3WE8KlfC BFRvVpiICvaCSahiH5is++l+MEUP0APgG1R0IExFVQfBt6jswjAN1R0M03WH7oAZeoQeATP1SD0S ZqHay8BsVHwFSNWr6FVgjh6jx8BcvZZeC+YhAerBfKRAQ1iAJGgCC5EGLWAREqE1LEYqxMISvave FZbKK/IKLJM35A1YLm/L27BC3pP3IE0+kA9gpXwsH8Mq+VQ+hdXyV/krrJEv5UtYK9/Kt7DOYAaD 9YZqqLDB4AaHjYbNsMEmI5ORCTYbwhCwxchiZIGtRnYjO2wzChoFYbtRxCgCO4xiRjHYaYQb4bDL KGmUhN1GaaM0YA+ZSRis+quFVIcaoT5VR6nj1W/U6epsdZ66SF2rblS3qjuJ+IfVY+op9Zx6Ub2q 3lBvI+/v80LqU16IF1FH8Vq8Hm/Im/AWvDWP5Z14V57Ak3gf3o/P5Qv5Up7G16Bvb+ZF+A7+Hd/H D/Kj6imcn+EX+GV+jd/id/kv/An/jb/i7zRF0zR3Tai3eS0tuxqg5dK6aiV4Q4y11NpqHfk1j026 m27XdT2znk3PqfvqefX8eogerpfUS+vl9cp6Nb2mXlevrzfSm+kt9bZ6B727vC5/knflI/lCvjHA 0I3MRjYjp1HYCDHCjBJGlFEOWTyIKAxEYUb8VYi/KvHXjTjLibAasdVGbLUTWzMRW92JrR7EUJ0Y KoihkhhqEEMzE0OzEEOzEkM9iaHZiKHZiaFexNAcxNCcxFBvYqgPMTQX0dOX6Jmb6OlH9MxDZMxL ZPQnMgYQGfMRGfMTGQsQGQOJjAWJjEFExkJExsJExiJExmAiY1FiVggxqxgxy0HMCiVmhRGzwolZ EcSs4sSsksSsSGJWKWJWFDGrNDGrDDGrLDGrHDGrPDGrAjGrIjGrEjGrMjGrCjGrKjErmphVjZgV Q8yqTsyqQcyqScyqRcyqTcyqQ8yqS8yqh7TKA58QfeoTdxoQdxoSaz4l1jQi1jQm1jQhvjQlvjQj vjQnvrQgvnxGfGlJfGlFfGlNfGlDfGlLNGlHNIklmrQnmnQgmnQkmnQimsQRTToTTboQTboSTboR TboTTeKJJglEk8+JJolEkx5EkySiSU/iSC9iR29iRx9ixxfEiL7EiC+JEf2IEV8RI/oTIwYQIwYS I5KJESnEiEEZGFFMDf+XjDikpqsn1bPIiCvECPRUixGF/zYjNvHCfDvfzffyA/yIehLnp/l5ixE/ 8wf8Mf+Vv+RvNaZxLZOLEf7IiC7ECH9iRAdkxMY/ZESYXkKP0svplfRovYZe53eMuCZvyZ/lQ/lc vpbvDQ/DMDyNHEYho6gRahQ3Shll/48R/8eI/2PEPzHCfNqMOQLUHXbBQTgFP8IdvNJ/wzSWGdzp HanmG1JD8Lo6CswnYNRSf0XVpKjPcTpYfYnT4eprnI7VhoPCy2p9cFpe64vTilo/nFY2vEGRT4xc OH32JyX+RiW+oBJfUYlvqMQRVOIXVOKXVOJXVKIPlehLJTJw0/qbuSk2wBUb6Iolu2IprtggV2yw KzaEYjR2pD814/qzDylIxasA/C1/BwryS8HcXNNAQ465gx3504GeZmmOANiphKweh5EkY8zt1Lv/ iGvmXclMNe/nNUfM3CE/5c6MOdxced2snOYaqQ5AOmG6c07bK2ZZOA+hEnLSOO0R3OopXv9fdm4l v3Pmds7Vu7TVCtzKHLhwg8LgwK9592oZACvNbBcv6/4LgGJUzxs0nUfTJViydI6cqVnVrEjFampN yMTDeQRIHslLQ2atqlYTsml1tAaQS2ukNQZ/ranWHPJ5LPZYCYEer3WAENFYtIQII8AIhDJGeaM8 VKT92y1fiIJaUB+/5h2Era262c0RP6yvH9a6BH7LWHV0UL1m0/QyjX+rFL9C07F0zHfJjv+5etvM 0WGohNMYqAPm/0RaWLW2WX7ua3m6s86hf1LnN66a/+frbEAjrKX5u3kCfnthvB+kYGwkjMP4FGv8 zpkzGMIgklqmArZKGLZNE4y1hg4Y72odUxjVfStNr9IRlFAf/ePYPA7TmkM0feo6QnPpAU3X0vTa f/SYs9HR9oL+MBi/IzFu/sbXH2bBfFhqxVZh6gZwvlncuY2zbWtAPfw2wrhptRpWSc5YP0xNsewQ /j+0Q3IG7/1v2MQTWxHPM9AHj74P2mUk2WQGzM2wtBgSrTFe5xYuZuPX9IWWEEv2+MdSL/M+W7IH /Saljv/oeH5vjTEZjnlFBto4yXPLstV/0gqM3jSXHz7c75fZqn1xGvv1p2mCtc4c1a1CwXn3vzM1 J9IzxArOdAVUjzkecwE85ptvmzRi6I2MGUd4s4LzDT1uym1QlOXmXpRU5295QB6EOVQr3wcml6Rf d7ZiANlMtjM9CL+e1n1nPuAuO8BDeASP5Q65U8bKXXK3bP9PeZrJ5rKF/Ey2lK1ka9lGtpXt/u1y QiCbGCqGyVFytBwjR8rpcrz8Rn4rp8mx8ms5Tk6VE+UEOUlOllMwd2akiDkuXhfMfzcdgqOYdg2D Bi8w2JjEqxTzvrbMkIllZVnBnd6+6kHvXdXpvauCbWFbQLJn7BkY7D17D5kVqUjIooQqYWgjBYlU VAwWQ0Rf8aXoJ74S/cUAMVAkixQxSC6UC+QiuUQulkvlVjlTzpKz5Qy5Tm6W8+RyuUKukmvkWrle bpTLZKqcI+fKNDlfrpSr5Sa5RW6TG7B8f/Cmuzmd76wMpt/kQsgfzF8c3MgnONTGI9TwLNAQMkFj DNiTxOABcdi70mEzhqx0/J50/DngLoacZAVvpjIVfMzXl0AusogvWSQ3WcSP5WV5IQ8LwL5aXvYN +wb8yUYBZKN8ZKP8bD3bCAXIUkHsB/YDFGKn2CkozG6ym1DE5m5zN2vNYmCO6Cl6iT6it/hC9HTe Eyl60Z20RTBHUTyqYuZa5Ho4Hltx9OeS4gsohcovjbQrK7vIrrKH/EoOkp1kRxmHy51lV4jFtESZ JHvi8R2GI/IrSIfjcAw6QppMkclykPmeYczfGVbCFtwqCbfuiVvgOrgK1+Em3Iaf4R78Bi/hNbxl dtkdQ7yMZ5r8AkNf2ZcJZrAssj+GgXIgy8G8WS6Wm+Vh/nIYhuFyOCvICrGRspvsxqayabIXht4Y +sg+bC6bzxayxWwpWi4N7baGrWMb2GY5QA5g29lOtpvtYXvZfjkYwxAMQzGMkCPYcXZSJsgEdo5d YJfZFXaN3bDZ6O77/ESNILpXzoFndgXPlJHkC5+hL7SFdpAH2iNj/aET9IB80BMGYL8qGUMUpMIc tOZyWAFl8byzCsqTd1SAfdgHrwgnMERjX/wUVCNPiYEbGKrDLQw1sH9+B2qS79SC+xhqw3MMdeAV hrrwBkM9eAfv4ROmoDc1YDZmg8YsE9OhCXlWC/Ksz9CzvKAly8lyQjvmw3wglvkyX2jP/JgfdCCP 64geFwidWBALgm6sMCsM3dkoNgri2RT0wQT2LfsWEtl0Ngd6sHlsHvRlC9gC+JItYougH1vClsBX bBlbBv3ZCrYCBrCVbCUMZKvZakim+wlT0GfXwyC2ET13MHruNhjCdrAdMJztYrtgBPuOfQcj2ffs exjF9rF9MBr9+hiMYSfYCZhC3v0NO8POwlR2np2HaewiuwjT2Y/sR5jBrrKrMJNdZ9dhFilgts1u s4PFWDGcGFvLyTvRRrQV7USsaC86iI6ik4gTnX/PRIxng+zWHdnemJKL3mHLcNvOH/L8WTmii0hy 5ekiuopuoruIFwnic5Eoeoikv72vv1GOqz6xUEyWklGytCwjy8pysrysICvKSrKyrCKrymhZTcbI 6rKGrClrydqyjqwr68lPZH3ZQDaUn8pGsrFsIovIYFlUhshi0iFDZZgMlxGyuCwhS8pI2ZR+SW+m DMOdjVBG0NVIDQiQ7lJIKXNJX+knA2Q+mV8WkB54OW3IzDKLzCo9ZTaZXXrJHDKn9MF8uWUemVf6 y0KysAyUBWWQ9Dbvd2AhLBxLzqx4gqZkV4qAuzJaGY1aUpg7pMjtYoQYKUaJ0WKMGCu+FuPEeDFB TBSTxGQxRXwjpopvxTQxXcwQM8UsMVukijlirlgmlorlIk2sECvFKrFGrBZrxTqxQawXG8UmsVls FVvENrFDbBe7xE6xW3wnloh5YqGYLxUsf4F4LDWxWOwRi8QJ8UjsFz+Iw2Kv2CcOiWPiuLgqrosb 4qb4SdwV98QD8Yt4Kn4Vr8Rr6Sa5uCy+FwfEQXFEHBXp4qQ4LU6JM+KsOCfOiwviovhRXBHXxC1x W9wRP4v74qH4TTwXL8RL8Ua8RdnapF1mEu/Ee4kXheKJuIRWqovnGfP/DCZxGJ5lktFTRmCIIL4U J7KUJLJEwmkMpYgmUUST0kSTMkSTskSTckST8kSTCkSTikSTSkSTynSGqkpnqGhiSjXmjm0Rw3Qk S3UiSw0iS006Z9Vi2Vg2qM28kDJ1iDJ1iTL1iDKfEGXqE2Ua0HmtIcvP8sOnLBCJ04iI05iI04SI 05TOes2IOM2RONORYjPZTKTYbDYbKTYHGdSKGNSaGNSGGNSWGNSOGBRLDGpPDOpADOpIDOpEDIoj BnWms2cXtg1J1JVI1I1I1J1IFE8kSiASfU5n2ER2kB1E9h1mhyGJHWVHoSc7hoTqRYTqTYTqw84i ob4gQvUlQn1JhOpHhPqKCNWfCDWACDVQDEc6JVsK/lcK/J+q26ngYKUp6my4MpwUHAP+qNUsGbTr 1KQ7atjUtanijzXsTSr2zahjulOtCCuK3dbH7DnGXyoGUk1hdkj+/1RumqXYzajO70iTS1HF20mZ y1HFy1DHq1HJpo7Xo463oZJ3oYJ3/k61lyzdOlV7+H9Bt+Y4Sh1Lt/lReYzuPM1l9o6wp78ce0f5 YQuGIOwLnMJe2VUMkdg/uo7qvYkhCvtJt1G9P2Mog/2le1jGbxjKYS/yJar3NYaK8BZDJfNlUahb N4Z9EqYxDdVrZ5lQvR7MA3UrmEDdGsxA3WZhWVC3nswTdZudZUfd5mA5ULfezBt1m4vlQt3mZrlR t3lYHtStP/NH3eZj+VC3BVgB1G1BVhB1W4gVQt2OZCNRt1PYFNTtVDYVdTuNTUPdzmAzULez2CzU bSpLRd3OZXNRt/PZfNTtQrYQdbuYLUbdLmVLUbdmHzcWe2tpqFuzp9uBerodsee2DnW7gW1A3W5m m1G3W9lW1O12th11u5PtRN3uZrtRt3vYHtTtXrYXdbuf7UfdHmAHULeH2CHU7RF2BHWbztJRt8fZ cdTtSXYSdXuGnUHdnmPnULcX2AXU7WV2GXV7hV1B3V5j11C3N9gN6G/DDwwQ1UQ1GGhepWLv77SH YcR7yD/55wTDc6T5/9MA7GmXQMo675M8RPfwHXbd73jTfEc0xW65Yj99iGm9zdx/cU9gfjDwWvOA PCgPycPyiDwq0+UxeVyekCflKXkar0L/+C4kBv3BoNE2hzX64RzXakZjPs7RAkWelz/Q9ABND9L0 EE0P0/QITY/SNJ2mx2h6nKYnaHqSpqdoepqmf14nrw9Xy0ZucFPnqTfUJa5RgjDXmGtOIy/Y1cug qrPVK+pY/N79fYo13jKbruU/bOeFuWxWrjfWVhmWM2wzgbYxnwZU2Bz9MfzAUK+qj/Bq/zDmPoTx p+pdjD1Q12L8mrW+xF+s/2h73Nu/3D7jetd401iql3l/bBi0MPJAtj+pVbJ5dBnKd+b8o/r9jZxW TZLJQv9cpwhXm/mDJ667Zm1rjoOvoDa8lWHpqbWlOVqUjbbkhr+RYHxuJBo9rJEY0pc8K8/JC0bS n46x/PUYB/3bif45rtM/vwC48kjN5dbRrZNbHC3Tf9ScOX2SaCSQPj5dHSk+nbRMhYfGDH0umE1J TfFpikmfKoyFejgyabyIVBUfDo42mnsRDcGbUlJhbqkNHJ84gjOk+M71G+iL4jJDXcR/D4hHabWH JPyWM4PDP0NhbtlG15oy9sWO1vdeiPI+Py0p+8OvIxZ6paZkL+ZIcfvWkaImp6oIesUT+8sw029M wbRNT8/Rs3tgpkO4ass41usLqqb6qZvmqXzaINTTkcVcsHu6N27To1Nc945J8d1DMzukmWjztNVv H9stvntsqJ/D10xx98xeO65dYnyP+A5JeSvHJybEJ7ZJisMt8jn8zfWqp0/G9bHt8zaI69gdS81b r3JFh18OERrmKOWICAuNwHkzXAx3hLsWHcmD/iN1Ew4Pc72Hp1vtuvXqf8iu/kl2RwoLyGgz7Ouq KXiCxHR3JYUx2DK/etfMrwNmtJ/rNbX0oTZtXyUVWjFG8z7xeRPvkS0bi7i23Uuk1nkb8MXV3Pt9 2ox99WZelgJeP+xqEhw6cnhamN/wiwPKJTV+PmR+iQYHKz6M2xQ3q1uje91vrgms3eN47Ofr8pxp M3g4+D/s1GRQ8+pfr7tysviZQ+cdsxu86dtl2uAiG/07Jp36rc+GNsOmTupXOL3jz947zm9p96BM nXJfKfeeDliZbmxM7v/s9Z3n42O2fl129A+2ib5Pt/e8+aZd3kKzSz2t2DDSr2FshXWDl5ZMewqj r4tXc9YYAesXLUk7k2Oz45GSL2/mV12aGldXzJ7VOnmiWktMb+u9duuUbeObLewztNf0rkdq3c+6 PrKaoqIy5qUwgRbJ5PBEW+Yu4KY73DU7ejfnNlV15DYTpZuXW7YfP7mU64lfDV4+q+/ubXvWtg8e z6c68pir87nldHgNzHYoy52DJ9Z5NWEHSoaEe3ltrjXNPY+jkZkhj1tdR21HzdTqqdWGVu2UlJQQ VaxYu8SuId0+tFpIu/huxRK6xJmpxRIS42N7tkvqUQwbFR0P3Q49rpUjsmh4aNEwR6gjBDM5mn2o I2NudRy1HDU+LDuUoeWsXfTu3fuPdtE+8V+WnfQ7mammpxSe//yXXXsC+w5q69NnRvO9b+9n/35R H8/jORoEeehQqXykMeJSrPfg4gNiNqff6ztizpG6S65ufVAt87scF4aNyHy8VvbUR1neX5iSHpue /DZ80Z4+E2/2O91t2OdnfNtcP1wndmOP8i+/LBjxW/3y1SrvkskJDXZPYXNrbt1ZWO39ZffXx6JH 5ggKXcBveI3c9LhGXPbPwl9eGTCpTLWqudMOjtr/fLjf3Xfj9dl1bZkeBE7ovnaSN3vRKvl22oUR Xw9o1nJwq/U7+kXfqrbyXZMi4wcMuxSd55PJh/e0nbN+f6t7B+JafD5+yZhGeYOj6kx8O137esXI F536l97yRaWJpar/eqzl/YQxlXruTfl0XK71n7ZBOO1BOC3LAKcipcJidq85EPOUaFrk93Dq/R8B gD95HCo+5z/WN4zr1r5og6Q23RJ+j6bQsPAIQhMmfFh0JK/9b6CpoKOAc9Gve+W4hE7tE/NWaVA1 b9UGdaIqO6IjioY7IksUrVI1OjK0gCOf84h8//CIGrRP7BXXrv1fomzhBodU26fVaza0y5DZMXP8 Duz6pWV125CrCVP67djcqm0rLfDkqFJbcwYsCJmw4lzN4VE+K6cPSvuhZanR34V96dXnQcnIqMdt X3dKUTrdv7e1wsjV7+YEl2jbOqFU67by9b6ckfGrJpypIAYuFH1GlegydGRgjpzvV92rvWVrIc+f WsSMTYguEfguoviyiGvPL5xrcffbr0I31s7T+F6/M5NFB91PhuUoF3x64Jyj955PHa9c2t3qbeTA F6UGfBZ7sGSL0p80/2xIq6N+vq8jdrS6FfRpQsMZm+73g0+jmwdNDWpU69rjLZm8pyTHFHb88Dw8 b9fbcXvWntpTJ93hV/LU1PqnluSruiatRcXqdde17TTxA8oyoUV4BmotyBneoPzk1nMqez0cu2/l iSJbZjU59hG18kW8OF8/OsH9QYXXvV6vLbJqT/G1hqOhk1rILAcyK7Xq0Mr/FrWcq81WpEZEryRm NcnALCSWIyYDs8r8PWb9YclJf4Ru+x9hrP/hVV/eKrbjdqP16T0uLq1/3KvUvnVHXp1959d+/e2Y p9Ojh/MOnQOHtnw3rMmlfe3GRg58Zo/uV6THarmz4tJD+5dOml/yUWypa3tPvzxqO7rsZoFHcWmn oq+/6xBW5uw3e8P8X/3iUyC1pV4pOEt4VMqgtw9yr91xdPz88QU+37wscdWslTfToe2IhCWbatQb /UuxgNgFi3+q3WVysO8X9xfNC70wrvW4+d3fTVRE+eD8Yl/nwORPBtXIvLVnuypL4+z71HvX0z0e NIq6/zBxkbv+DE4GbFoZkLj29vczPIJSBx68ce1sqQ6O29E5ct5+lfKqqUffbYvFO9/36qh2a2pn VfLVLbp2yODS1+dUu5Oe3ZHCtyHG5jsx5t4mPNCH6BX6e3q1Iiy4Z5oQOGLik+BY5u2lYluEejty fJSYydVUoUUdRZw6zv8PHdePj0dIYNvFdYhr1yapfd6KPZM6xSfGJX1BlHI4IpFMYaGlwsOQUmHW Ypi5+L/Zt/sr1KxJbNrC2xG7M/e01nnzVvq2V4Ou5XKdiT986PHdLu++8cp89UpU0iCfjcVSw+6/ //G7SnXynU6Ei8Ubu484mJa3+rNHnZbXrjlmwfYvan4+vZrtwtsCV2b2HJ6+tEeVAWeTLz7d/qTE /AMtql5auaLs1aBO3/gsWpDYo9HjHJNuvi0+KTH1TK9Wfr2rDhoS6XWsR3O+pWP9MQvWxBW74O3x bkJSoeu9ijW8nM3R9MWJMW3fHjrQKjq03uaCnjcrONITC2UOCthfsk7Z1LCy447MidSGtKjTKCWo MA/bWPNs3Xa3TxRt+7hq2dvL7fBb9JxZx5uPDmxwp+/SGk+i00uWiZy1rneLBTlmjTmU5etGZXYv z9RKPfkBNS3RIs0chik9T8beu3GHirMM7PnDDpF5lshtuLmhBw51ZNUyWdcR2Zkbp4LxdOBKU8xS 3h4PrXMycOTka1Nbl14cGr+wzLZzRR3erkzZFDfdzx0aQE+89qgMFT+Cm1ye0rpCo4Lf3Crg+abw NfcGk5venO+o54RbdUc1R9XUyqkVh5b/+3BzrU5E1zapRGBrmAFsMY5oR5UMYIv8d8BmCqays9R/ 7oYpDJqWKjcgMHrlvfgKq8PWd74ni/2/6swzqqktDcOhCwEMRIr0Jr0kFJErUSnShBAEAwJKkd7J RSQoCFFAkabSQ0sA4UovXqMRGJomNGkXsCASQoeAgPQrNzrjyNxxyp9Zrvl3vr3XXuesfd79nPd7 T0Cp6ca80+VF8+MqwwYVwE+dsyrQQumua4jMKMkL5TA186f4UmTORBCRUL+JfmSK2jgxp3e9Y5xT wLuzOEdCZRuIaEN2q0yY9T8Lmi7lwjMVI98T4s/YrqTp53xYXaJNxIpr6hKQ2cvW0jGKRRiR+5RU NtEVCnwzAdcxAy6+CycJ9yej0hSD/bFCmyLL1kOeXVJ7jqLd+IQGuVr0JaQh3qp7a7bQDjmKZTxt qOa09rpyEKMesFuUBqbOe0//glduJCmBuN2Tst58xG/zyrK7H0v9EC5uRuwbR870hqULOpK1+J1G 74uaJqk0VmgaitBAfEKAC6NaDpI9mS/YaTHcCZb+3GA47JqCSQ6qb9Wvo3khqND2nm1EamKBsAmT /cbLQk+OkOKjiypqAqQplDbvWmCNridm62xtoga/uxh3/CjondtaYI/R4IDALLqNuX5gR3lMPD6v nGMHLHeqgro1/st1IyKbs7G78yl4tf4CfLEuFD3CocnuLxIFFadw24xO4nYmjUEVbpl7CH7Va00s kuGUND0579b7yWnkxBGsZCWXY84yvjLW6wanjwox1Bcgml6xwn91nf+GzJNbL31KjaFq2W8ngmHD gEhX476eW2SC4DY3KrG5EFbFeMpnzxubTgGVguq1EQeGWmEQDCsbnd9LX/nN76X5hd8iP4LfEG2I JoRObC2NLw2wOvRL+bkNpjfAP8z+/id65+P8asbemNxTvOareni8gTLRnmUljajoGRWEyxyk9ZX0 mVeEQCR45tl+s0njM00V1r9XmekIkX0N8J252rBwm+3gBjdz5vLtLvFODZm43JU1TxHl3avTt0Tn puGFuGZp647E7dMv2XsvVvVW6zPjtx743fccln9rZF0d2zspb6QqVx5ree4sJ5VJeccnJQUSELd6 HpK7HTmUUTcjmRG52Q9ePfDY2v9s/emUfBOAmbEHj5yCR2kGdYA12gy/dbOEx/gQOyb/5uK5sE8M 2aKIAzEAEMRo8fE7aSNim4pNfpVYmB70Shd27PiN+zgXxkeiXDW7G9hahh6pMzZ7WyytLRLAr/Qu o+9Iyb+j93eN4T/QG7Sf3vQRACQ686/wjU6BRCd+H7+4S0Uu/3N5YkDoCn6cWUFxhfnPdmtsYFX3 /xvq/1dWlr7XoIz4Vkcmw6Ojs/UVV970oK0sGGpUQ4Id/DnBZT2NV5MJqoO8+AR/V4ItYydcAozI Gg0/RbElVtlli4yLMsSWE8NW7vQuHGegURqTOVhIiSaUZWu+Ucuye9TpRJ/fopqnUldY1WKYZu8q ykgF7azvUsOyVLk22ChBzwThuUm+HKg0Ak4nx1Ol3Yp7ztXxJH/mHYmTFDYh9a0uqFkoFKaEApLm gmB7MRzgsRYOl6TlYYLAPPzO9XYtpYuFTfPPIoD6VwetUZI0SAcxzN3RgUGA4xB3/+tDmR91n3jY 1amoTW/FxHZZIWdyg1L9ynXMB9fRTQ8Fw10VlvBYBU3WK0KuZJiYvzhmGfhCmfjSoG5yayHi0URR aYgWAd4eLM0rGwrUPZsQbG9kcOhZXV21hScpX38vCi0ZlccH8ZjR570oRMqTkuw1mFWaJa6ZdCkP jqhHmcsqmsg42c8hlx68y8rt+CmwIVouhJWHFirZhMU0y9n8WuMDu40LdakPwIEfND00XuYN/D1e 3a/205gVKUGa7NGQKxrH68YIU6k6n0ygSk4+qu64VB9mwzKop4ooT60uDiurK0i/LPTqXhz4spSa eumBgAKHhCNNBUs3OySH5sUsydk00/cbDO6Bt4ERJG/SVMBcSUYPVGGPu93BccRCGDeyrZZ3UvUc vy8ZXPg7FMNMP8LMJYwMDBD6cftxfvn7Ue23xLcguu2zXfubftmZoJz742T6A3yrgFBuyP5Zvs9m 8OtCZigdSrmZLky2VVJLE7sT5A4u4TovPegxiNu+JZxQJMSmQDFKHmAB8AZcAqAAgV8SaQ9ACEAC YANAA4LolSd93IV+5QVA42SjZP7lYQ1BBwV6olyCvNASf/qoMGMYANo05iVTQk/v859hxa/87Mwe 9/e/ZRfSOdOGvDn5UafEEbrd7XypNC2jzitOIPLVmM5hoPwc9YR2F9eVNpz9IJHvUKWw/vldN0sq Xx5RU1Ov8oJrFCphyoati1ohf7SJ8Yiyk2j8ySc56tsrhPyh+A6V5nRjhadxKcYZTK8Xl0zK+mtP 7Hg/s4BNn6vxYFb1ZcuwkTDIwEVrH3uI023z4Blw1uhRD6XOFVTjEKVWY50eRSzDYWJ9s2+rRj4G 9uJRfqhjT1GMZS+qkS9b23fuSvtEFHfuPU/prmHazgdvtpP64yRdNed2Bi8/1zVXn2/GJmc3pmNt F9rWSzSk7BJJo++e4DCM8hAMo8y3d8QKxTDSm0xGni+qTPphLuD7Cd0+TV6ACO6XJPDbbxAG+s3/ PsMCPfg5TYNCIcfofepRqLb9Pyky0vlTkmmYITq0j2GcqqMltATC8v+J15+1wlcPIM2M+CmeIM/U T/VtSKix2FD+QuNXb/o1SKn8Vr/daoKbg05rbWmJHrDHcn1su6plmMh9pMhVuAlpsSPeUD+8tUl4 E3IX9u6G0VSkB98TTb1TzkZV8Bb9w1tV82XvPRsPip2kRgwLX8+eVuq+PT8y6zY0EYtMSVuV6wL5 WiUfONLnr4U4ONhH1qNw/WTbbKAjgpbnpKlHtbXc6KN1ixgjbl4pDC/rbhCZql1HPLX3JY/Kg+7u XjdMxqvLamD7P5bdkV9arwwm5z3cbC5UfHFkYHndqYPkMPbgWgiAAxEkweI5PIYis9UPyFNSZ4Tz E6hZMOas8LxQMdmWhMqE+A9/AAN9nssNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNTMgMCBvYmoNCjw8 L1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUwvTGVuZ3RoIDE0NjM+Pg0Kc3RyZWFtDQo8P3hwYWNr ZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pjx4OnhtcG1ldGEg eG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03MDEiPgo8cmRmOlJERiB4bWxu czpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgo8cmRm OkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiAgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29t L3hhcC8xLjAvIj4KPC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSIiICB4bWxuczp4bXBSaWdodHM9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9yaWdodHMv Ij4KPHhtcFJpZ2h0czpNYXJrZWQ+VHJ1ZTwveG1wUmlnaHRzOk1hcmtlZD48L3JkZjpEZXNjcmlw dGlvbj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8L3JkZjpSREY+ PC94OnhtcG1ldGE+PD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDQplbmRvYmoNCjE1NCAw IG9iag0KPDwvTiAzL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjU5Mz4+DQpzdHJlYW0NCnic nZZ3VFTXFofPvXd6oc0wdBh6r1IGEOkdpFdRGGYGGMoAwwzYCyIqEFFEpCmCBAUMGA1FYkUUCwFR AXtAgoASg1FsqGRG1kp8eXnv5eX3xz3f2mfvc/fZe9+1LgAkLz8uLx2WAiCNJ+AHe7rQI6Oi6dh+ AAM8wABzAJisrAz/EI9QIJK3uys9S+QE/kWvhwEkXm8ZewXS6eD/kzQrgy8AAAoU8RI2J4sl4jwR p+YIMsT2WRFT41PEDKPEzBclKGJ5MScustFnn0V2EjM7jccWsTjnDHYaW8w9It6RLeSIGPETcX42 l5Mj4tsi1koVpnFF/FYcm8ZhZgGAIontAg4rScRmIibxQ4NdRbwUABwp8QuO/4IFnNUC8aVc0zPW 8LmJSQK6Hkufbm5ry6B7cXJSOQKBcSCTlcLks+mu6WkZTN4aABbv/Fky4trSRUW2Nre1tja2MDH/ olD/dfNvStzbRXoZ9LlnEK3vD9tf+aXXAcCYE9Vm9x+2+AoAOrYBIH/vD5vWIQAkRX1rH/jiPjTx vCQJBBl2pqY5OTkmXA7LRFzQ3/U/Hf6Gvnififi438tDd+MkMIWpArq4bqz01HQhn56VwWRx6MZ/ HuJ/HPjXeRgFcxI4fA5PFBEumjIuL1HUbh6bK+Cm8+hc3n9q4j8M+5MW51okSv0nQI01AVIDVID8 3AdQFCJAYg6KdqDf++aHDweBojVCbXJx7j8L+vdT4WLxI4ub+DnONTiUzhLysxf3xJ8lQAMCkARU oABUgSbQA8bAAtgAe+AE3IEPCAChIAqsAiyQBNIAH+SA9WALyAeFYDfYBypBDagHjaAFnAAd4DS4 AC6D6+AGGAL3wSiYAM/ALHgN5iEIwkJkiAIpQGqQNmQIWUAMaBnkDvlBwVAUFAclQjxICK2HtkKF UAlUCdVCjdC30CnoAnQVGoTuQmPQNPQr9B5GYBJMhVVgHdgUZsDOsC8cCq+EE+FMeC2cB++Cy+E6 +BjcDl+Ar8ND8Cj8DJ5DAEJEaIg6YowwEFckAIlGEhA+shEpQMqQOqQF6UJ6kVvIKDKDvENhUBQU HWWMskd5ocJQLFQmaiOqCFWJOopqR/WgbqHGULOoT2gyWhltiLZDe6Mj0YnoHHQ+ugzdgG5DX0IP oSfQrzEYDA2ji7HBeGGiMMmYdZgizAFMK+Y8ZhAzjpnDYrEKWEOsAzYAy8QKsPnYCuwx7DnsTewE 9i2OiFPDWeA8cNE4Hi4XV4Zrwp3F3cRN4ubxUnhtvB0+AM/Gr8EX4+vxXfgB/AR+niBN0CU4EEIJ yYQthHJCC+ES4QHhJZFI1CDaEoOIXOJmYjnxOPEKcYz4jiRDMiC5kmJIQtIu0hHSedJd0ksymaxD diJHkwXkXeRG8kXyI/JbCYqEiYS3BFtik0SVRLvETYnnknhJbUlnyVWSayXLJE9KDkjOSOGldKRc pZhSG6WqpE5JjUjNSVOkzaUDpNOki6SbpK9KT8lgZXRk3GXYMnkyh2UuyoxTEIomxZXComyl1FMu USaoGKou1ZuaTC2kfkPtp87KyshayobLrpatkj0jO0pDaDo0b1oqrZh2gjZMey+nIucsx5HbKdci d1PujbySvJM8R75AvlV+SP69Al3BXSFFYY9Ch8JDRZSigWKQYo7iQcVLijNKVCV7JZZSgdIJpXvK sLKBcrDyOuXDyn3KcyqqKp4qGSoVKhdVZlRpqk6qyaqlqmdVp9UoasvUuGqlaufUntJl6c70VHo5 vYc+q66s7qUuVK9V71ef19DVCNPI1WjVeKhJ0GRoJmiWanZrzmqpaflrrddq1rqnjddmaCdp79fu 1X6jo6sTobNdp0NnSlde11t3rW6z7gM9sp6jXqZend5tfYw+Qz9F/4D+DQPYwMogyaDKYMAQNrQ2 5BoeMBw0QhvZGvGM6oxGjEnGzsbZxs3GYyY0Ez+TXJMOk+emWqbRpntMe00/mVmZpZrVm903lzH3 Mc817zL/1cLAgmVRZXF7CXmJx5JNSzqXvLA0tORYHrS8Y0Wx8rfabtVt9dHaxppv3WI9baNlE2dT bTPCoDICGUWMK7ZoWxfbTbanbd/ZWdsJ7E7Y/WJvbJ9i32Q/tVR3KWdp/dJxBw0HpkOtw+gy+rK4 ZYeWjTqqOzId6xwfO2k6sZ0anCad9Z2TnY85P3cxc+G7tLm8cbVz3eB63g1x83QrcOt3l3EPc690 f+Sh4ZHo0ewx62nluc7zvBfay9drj9eIt4o3y7vRe9bHxmeDT48vyTfEt9L3sZ+BH9+vyx/29/Hf 6/9gufZy3vKOABDgHbA34GGgbmBm4PdBmKDAoKqgJ8HmweuDe0MoIbEhTSGvQ11Ci0Pvh+mFCcO6 wyXDY8Ibw99EuEWURIxGmkZuiLwepRjFjeqMxkaHRzdEz61wX7FvxUSMVUx+zPBK3ZWrV15dpbgq ddWZWMlYZuzJOHRcRFxT3AdmALOOORfvHV8dP8tyZe1nPWM7sUvZ0xwHTglnMsEhoSRhKtEhcW/i dJJjUlnSDNeVW8l9keyVXJP8JiUg5UjKQmpEamsaLi0u7RRPhpfC60lXTV+dPphhmJGfMZppl7kv c5bvy2/IgrJWZnUKqKKfqT6hnnCbcCx7WXZV9tuc8JyTq6VX81b3rTFYs3PN5FqPtV+vQ61jrete r75+y/qxDc4bajdCG+M3dm/S3JS3aWKz5+ajWwhbUrb8kGuWW5L7amvE1q48lbzNeePbPLc150vk 8/NHtttvr9mB2sHd0b9zyc6KnZ8K2AXXCs0Kywo/FLGKrn1l/lX5Vwu7Enb1F1sXH9yN2c3bPbzH cc/REumStSXje/33tpfSSwtKX+2L3Xe1zLKsZj9hv3D/aLlfeWeFVsXuig+VSZVDVS5VrdXK1Tur 3xxgH7h50OlgS41KTWHN+0PcQ3dqPWvb63Tqyg5jDmcfflIfXt/7NePrxgbFhsKGj0d4R0aPBh/t abRpbGxSbipuhpuFzdPHYo7d+Mbtm84W45baVlpr4XFwXHj86bdx3w6f8D3RfZJxsuU77e+q2yht Be1Q+5r22Y6kjtHOqM7BUz6nurvsu9q+N/n+yGn101VnZM8UnyWczTu7cG7tubnzGednLiReGO+O 7b5/MfLi7Z6gnv5LvpeuXPa4fLHXuffcFYcrp6/aXT11jXGt47r19fY+q762H6x+aOu37m8fsBno vGF7o2tw6eDZm443L9xyu3X5tvft60PLhwaHw4bvjMSMjN5h35m6m3r3xb3se/P3Nz9APyh4KPWw 7JHyo7of9X9sHbUePTPmNtb3OOTx/XHW+LOfsn76MJH3hPykbFJtsnHKYur0tMf0jacrnk48y3g2 P5P/s/TP1c/1nn/3i9MvfbORsxMv+C8Wfi16qfDyyCvLV91zgXOPXqe9nn9T8Fbh7dF3jHe97yPe T87nfMB+KP+o/7Hrk++nBwtpCwu/AfeE8/sNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNTUgMCBvYmoN Cjw8L1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUwvTGVuZ3RoIDM0MDA+Pg0Kc3RyZWFtDQo8P3hw YWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pjx4OnhtcG1l dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03MDEiPgo8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgo8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUu Y29tL3BkZi8xLjMvIj4KPHBkZjpQcm9kdWNlcj5NaWNyb3NvZnTCriBXb3JkIDIwMTA8L3BkZjpQ cm9kdWNlcj48cGRmOktleXdvcmRzPjMsIDksIDEwLCAxMiwgMTQvMTU8L3BkZjpLZXl3b3Jkcz48 L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgIHhtbG5zOmRj PSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyI+CjxkYzp0aXRsZT48cmRmOkFsdD48 cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPm9MUzogQ2xvc3VyZSBvZiB0aGUgYWQtaG9jIGdy b3VwIG9uIE1QTFMtVFA8L3JkZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRsZT48ZGM6Y3JlYXRvcj48 cmRmOlNlcT48cmRmOmxpPlNHMTUgQ2hhaXJtYW48L3JkZjpsaT48L3JkZjpTZXE+PC9kYzpjcmVh dG9yPjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiAgeG1s bnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KPHhtcDpDcmVhdG9yVG9vbD5N aWNyb3NvZnTCriBXb3JkIDIwMTA8L3htcDpDcmVhdG9yVG9vbD48eG1wOkNyZWF0ZURhdGU+MjAx My0wMS0xN1QyMzo0MjozNSswMTowMDwveG1wOkNyZWF0ZURhdGU+PHhtcDpNb2RpZnlEYXRlPjIw MTMtMDEtMTdUMjM6NDI6MzUrMDE6MDA8L3htcDpNb2RpZnlEYXRlPjwvcmRmOkRlc2NyaXB0aW9u Pgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiAgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5h ZG9iZS5jb20veGFwLzEuMC9tbS8iPgo8eGFwTU06RG9jdW1lbnRJRD51dWlkOkFBNEFGREFELTc3 NUEtNDZCRS05NjI0LTE3NEQ2NzdDNTQxODwveGFwTU06RG9jdW1lbnRJRD48eGFwTU06SW5zdGFu Y2VJRD51dWlkOkFBNEFGREFELTc3NUEtNDZCRS05NjI0LTE3NEQ2NzdDNTQxODwveGFwTU06SW5z dGFuY2VJRD48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIg IHhtbG5zOnBkZmFpZD0iaHR0cDovL3d3dy5haWltLm9yZy9wZGZhL25zL2lkLyI+CjxwZGZhaWQ6 cGFydD4xPC9wZGZhaWQ6cGFydD48cGRmYWlkOmNvbmZvcm1hbmNlPkE8L3BkZmFpZDpjb25mb3Jt YW5jZT48L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjwvcmRmOlJE Rj48L3g6eG1wbWV0YT48P3hwYWNrZXQgZW5kPSJ3Ij8+DQplbmRzdHJlYW0NCmVuZG9iag0KeHJl Zg0KMCAxNTYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAwMDAw MzQyIDAwMDAwIG4NCjAwMDAwMDAzOTggMDAwMDAgbg0KMDAwMDAwMDY2MCAwMDAwMCBuDQowMDAw MDA1ODI4IDAwMDAwIG4NCjAwMDAwMDYwMTQgMDAwMDAgbg0KMDAwMDAwNjI4MiAwMDAwMCBuDQow MDAwMDA2NDYzIDAwMDAwIG4NCjAwMDAwMDY3MjYgMDAwMDAgbg0KMDAwMDAwNjg3NSAwMDAwMCBu DQowMDAwMDA2OTA1IDAwMDAwIG4NCjAwMDAwMDcwODMgMDAwMDAgbg0KMDAwMDAwNzE1NyAwMDAw MCBuDQowMDAwMDA3NDQxIDAwMDAwIG4NCjAwMDAwMDc2MTcgMDAwMDAgbg0KMDAwMDAwNzc0OSAw MDAwMCBuDQowMDAwMDA3Nzc5IDAwMDAwIG4NCjAwMDAwMDc5MzkgMDAwMDAgbg0KMDAwMDAwODAx MyAwMDAwMCBuDQowMDAwMDA4MjY2IDAwMDAwIG4NCjAwMDAwMDg0MzQgMDAwMDAgbg0KMDAwMDAw ODY4NCAwMDAwMCBuDQowMDAwMDE1NjY4IDAwMDAwIG4NCjAwMDAwMTU5NzggMDAwMDAgbg0KMDAw MDAxNjA4NyAwMDAwMCBuDQowMDAwMDE2MzQxIDAwMDAwIG4NCjAwMDAwMTYzOTIgMDAwMDAgbg0K MDAwMDAxNjUxNiAwMDAwMCBuDQowMDAwMDE2Njk0IDAwMDAwIG4NCjAwMDAwMTY3ODMgMDAwMDAg bg0KMDAwMDAxNjg1OCAwMDAwMCBuDQowMDAwMDE2OTI3IDAwMDAwIG4NCjAwMDAwMTczMjkgMDAw MDAgbg0KMDAwMDAxNzQwNCAwMDAwMCBuDQowMDAwMDE3NDczIDAwMDAwIG4NCjAwMDAwMTc1NDgg MDAwMDAgbg0KMDAwMDAxNzYxNyAwMDAwMCBuDQowMDAwMDE3NzA2IDAwMDAwIG4NCjAwMDAwMTc3 NzQgMDAwMDAgbg0KMDAwMDAxNzg1NiAwMDAwMCBuDQowMDAwMDE3OTI1IDAwMDAwIG4NCjAwMDAw MTc5OTQgMDAwMDAgbg0KMDAwMDAxODA2OSAwMDAwMCBuDQowMDAwMDE4MTM4IDAwMDAwIG4NCjAw MDAwMTgyMjcgMDAwMDAgbg0KMDAwMDAxODI5NSAwMDAwMCBuDQowMDAwMDE4MzYzIDAwMDAwIG4N CjAwMDAwMTg0NDUgMDAwMDAgbg0KMDAwMDAxODUxNCAwMDAwMCBuDQowMDAwMDE4NTgzIDAwMDAw IG4NCjAwMDAwMTg2NzkgMDAwMDAgbg0KMDAwMDAxODc1NCAwMDAwMCBuDQowMDAwMDE4ODIzIDAw MDAwIG4NCjAwMDAwMTg4OTggMDAwMDAgbg0KMDAwMDAxODk2NyAwMDAwMCBuDQowMDAwMDE5MDQy IDAwMDAwIG4NCjAwMDAwMTkxMTIgMDAwMDAgbg0KMDAwMDAxOTE4MiAwMDAwMCBuDQowMDAwMDE5 MjU3IDAwMDAwIG4NCjAwMDAwMTkzMzIgMDAwMDAgbg0KMDAwMDAxOTQwMiAwMDAwMCBuDQowMDAw MDE5NDg0IDAwMDAwIG4NCjAwMDAwMTk1NTkgMDAwMDAgbg0KMDAwMDAxOTYyOSAwMDAwMCBuDQow MDAwMDE5NzA0IDAwMDAwIG4NCjAwMDAwMTk3NzQgMDAwMDAgbg0KMDAwMDAxOTg1NiAwMDAwMCBu DQowMDAwMDE5OTMxIDAwMDAwIG4NCjAwMDAwMjAwMDEgMDAwMDAgbg0KMDAwMDAyMDA3NiAwMDAw MCBuDQowMDAwMDIwMTQ2IDAwMDAwIG4NCjAwMDAwMjAyMjggMDAwMDAgbg0KMDAwMDAyMDMwMyAw MDAwMCBuDQowMDAwMDIwMzczIDAwMDAwIG4NCjAwMDAwMjA0NDMgMDAwMDAgbg0KMDAwMDAyMDUy NSAwMDAwMCBuDQowMDAwMDIwNjAwIDAwMDAwIG4NCjAwMDAwMjA2NzAgMDAwMDAgbg0KMDAwMDAy MDc0NSAwMDAwMCBuDQowMDAwMDIwODE1IDAwMDAwIG4NCjAwMDAwMjA4OTcgMDAwMDAgbg0KMDAw MDAyMDk3MiAwMDAwMCBuDQowMDAwMDIxMDQyIDAwMDAwIG4NCjAwMDAwMjExMTcgMDAwMDAgbg0K MDAwMDAyMTE4NyAwMDAwMCBuDQowMDAwMDIxMjY5IDAwMDAwIG4NCjAwMDAwMjEzNDQgMDAwMDAg bg0KMDAwMDAyMTQxNCAwMDAwMCBuDQowMDAwMDIxNDg5IDAwMDAwIG4NCjAwMDAwMjE1NTkgMDAw MDAgbg0KMDAwMDAyMTY0MSAwMDAwMCBuDQowMDAwMDIxNzE2IDAwMDAwIG4NCjAwMDAwMjE3ODYg MDAwMDAgbg0KMDAwMDAyMTg2MSAwMDAwMCBuDQowMDAwMDIxOTMxIDAwMDAwIG4NCjAwMDAwMjIw MTMgMDAwMDAgbg0KMDAwMDAyMjA4OCAwMDAwMCBuDQowMDAwMDIyMTU4IDAwMDAwIG4NCjAwMDAw MjIyMzMgMDAwMDAgbg0KMDAwMDAyMjMwMyAwMDAwMCBuDQowMDAwMDIyNDA0IDAwMDAwIG4NCjAw MDAwMjI0ODIgMDAwMDAgbg0KMDAwMDAyMjU1NCAwMDAwMCBuDQowMDAwMDIyNjQ4IDAwMDAwIG4N CjAwMDAwMjI3MjAgMDAwMDAgbg0KMDAwMDAyMjc5MiAwMDAwMCBuDQowMDAwMDIyODY0IDAwMDAw IG4NCjAwMDAwMjI5NTAgMDAwMDAgbg0KMDAwMDAyMzAyMiAwMDAwMCBuDQowMDAwMDIzMTE1IDAw MDAwIG4NCjAwMDAwMjMxODcgMDAwMDAgbg0KMDAwMDAyMzI3NSAwMDAwMCBuDQowMDAwMDIzMzMw IDAwMDAwIG4NCjAwMDAwMjM0MDIgMDAwMDAgbg0KMDAwMDAyMzQ3NCAwMDAwMCBuDQowMDAwMDIz NTQ2IDAwMDAwIG4NCjAwMDAwMjM2MzEgMDAwMDAgbg0KMDAwMDAyMzcwOSAwMDAwMCBuDQowMDAw MDIzNzgxIDAwMDAwIG4NCjAwMDAwMjM4NTMgMDAwMDAgbg0KMDAwMDAyMzk0MyAwMDAwMCBuDQow MDAwMDI0MDE0IDAwMDAwIG4NCjAwMDAwMjQwODUgMDAwMDAgbg0KMDAwMDAyNDE5MyAwMDAwMCBu DQowMDAwMDI0MjcxIDAwMDAwIG4NCjAwMDAwMjQzNDcgMDAwMDAgbg0KMDAwMDAyNDQyNSAwMDAw MCBuDQowMDAwMDI0NTAxIDAwMDAwIG4NCjAwMDAwMjQ1NzkgMDAwMDAgbg0KMDAwMDAyNDY1NSAw MDAwMCBuDQowMDAwMDI0NzMzIDAwMDAwIG4NCjAwMDAwMjQ4MDkgMDAwMDAgbg0KMDAwMDAyNDg4 NyAwMDAwMCBuDQowMDAwMDI0OTYzIDAwMDAwIG4NCjAwMDAwMjUwMzQgMDAwMDAgbg0KMDAwMDAy NTEwNSAwMDAwMCBuDQowMDAwMDI1MTc2IDAwMDAwIG4NCjAwMDAwMjU0NzYgMDAwMDAgbg0KMDAw MDA5NzYxNiAwMDAwMCBuDQowMDAwMDk5MTYzIDAwMDAwIG4NCjAwMDAwOTk0OTAgMDAwMDAgbg0K MDAwMDA5OTU5MSAwMDAwMCBuDQowMDAwMDk5ODg5IDAwMDAwIG4NCjAwMDAxMDAyMjkgMDAwMDAg bg0KMDAwMDE4NjA5NiAwMDAwMCBuDQowMDAwMTg3NjQzIDAwMDAwIG4NCjAwMDAxODc5NDQgMDAw MDAgbg0KMDAwMDIwMDI3MyAwMDAwMCBuDQowMDAwMjAxODIwIDAwMDAwIG4NCjAwMDAyMDE4NjQg MDAwMDAgbg0KMDAwMDIwMTk1NCAwMDAwMCBuDQowMDAwMjAxOTgyIDAwMDAwIG4NCjAwMDAyNTMx ODEgMDAwMDAgbg0KMDAwMDI1NDcyOCAwMDAwMCBuDQowMDAwMjU3NDAyIDAwMDAwIG4NCnRyYWls ZXINCjw8L1NpemUgMTU2L1Jvb3QgMSAwIFIvSW5mbyAyMyAwIFIvSURbPEFERkQ0QUFBNUE3N0JF NDY5NjI0MTc0RDY3N0M1NDE4PjxBREZENEFBQTVBNzdCRTQ2OTYyNDE3NEQ2NzdDNTQxOD5dID4+ DQpzdGFydHhyZWYNCjI2MDg4Ng0KJSVFT0Y= --_005_EF35EE4B92789843B1DECBC0E24558640FF6C2eusaamb105ericsso_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 18 Jan 2013 19:09:02 GMT"; modification-date="Fri, 18 Jan 2013 19:09:02 GMT" Received: from esessmw0184.eemea.ericsson.se (153.88.115.81) by EUSAAHC001.ericsson.se (147.117.188.75) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 17 Jan 2013 19:22:45 -0500 Received: from sessmg11.ericsson.net (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.83) with Microsoft SMTP Server id 8.3.279.1; Fri, 18 Jan 2013 01:22:29 +0100 Received: from mail8.itu.ch (mail8.itu.ch [156.106.192.38]) (using TLS with cipher AES256-SHA (AES256-SHA/256 bits)) (Client did not present a certificate) by sessmg11.ericsson.net (Symantec Mail Security) with SMTP id 1D.97.10468.4C598F05; Fri, 18 Jan 2013 01:22:28 +0100 (CET) Received: from sympa1.itu.ch (sympa1.itu.ch [156.106.192.98]) by mail8.itu.ch (8.13.8/8.14.4) with ESMTP id r0I0MPhA020563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2013 01:22:25 +0100 Received: from sympa1.itu.ch (sympa1.itu.ch [127.0.0.1]) by sympa1.itu.ch (8.13.8/8.13.8) with ESMTP id r0I0MPBG012537; Fri, 18 Jan 2013 01:22:25 +0100 Received: (from sympa@localhost) by sympa1.itu.ch (8.13.8/8.13.8/Submit) id r0I0MPkC012535; Fri, 18 Jan 2013 01:22:25 +0100 From: Yoichi MAEDA To: "Jones, Greg" CC: "yoichi.maeda@ttc.or.jp" , "ahmpls-tp@lists.itu.int" , "TSBSG15, ITU" Subject: Re: [AHMPLS-TP] Closure of the ad hoc Group on MPLS-TP and associated mailing list Thread-Topic: [AHMPLS-TP] Closure of the ad hoc Group on MPLS-TP and associated mailing list Thread-Index: Ac31BT31SGjq4LRlTES4JeRz7wI6KwAM5M4A Date: Fri, 18 Jan 2013 00:01:04 +0000 Message-ID: <20130118090103.BDAA.B5F9D168@ttc.or.jp> References: <9BA9FE6D8B2F5344BF95CDAC35C8320D637E9EC5@TUCHM02.TUECSP.UNICC.ORG> List-Help: List-Subscribe: List-Unsubscribe: In-Reply-To: <9BA9FE6D8B2F5344BF95CDAC35C8320D637E9EC5@TUCHM02.TUECSP.UNICC.ORG> Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0184.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb3d-b7f646d0000028e4-83-50f895c42b3c x-brightmail-tracker: H4sIAAAAAAAAA02Sa0hTYRjHfc+Z87g8eZzaeV2JNVKjmbYom2IXrECEcNQni8yZRzedU86Z op+8pjItJS+pWxdRVmmo3UitSK1kKpFKQmHah00Jw0Kxkq1c53i8ffs9z//5v8//hQdDxc1C CUbl6ilap9JKhSKBKa0v6MDbumXlQetYhKJjZhZR1N8zI4pvC+Nuik9lFqAwvBgUnnSNsf+a ECrBBVFUMqXV5FB02PFEkXqu8wmS9ZXMtZbcFBaA32IDcMcgcRhOfXC48rwDjk53Cg1AhIkJ EwJLquwIX9gArDDMuPKFEcCRXqsbZxET+XD8hxXw9r1wdOyVG8/R8I59YY13wyJb4doKX1jb 8JPtYywHwcLes3ybhDXND1COBUQgXO4YWbUKCRl8bTQDbtyHHb9VEsBFQIliAItetqBc351Q whprOJ8mDg4NXhNwjLMfM0+Xozx7waFG22ofJUKgpW0Q5TkAPp83oXyEAGgYKEW59yFxHcCp MqeALwoAfFhiWnV7E5fgcP0CWHf0vRsR8EzA74ZHq6FdiX1woWsR4Zhg+7dbezZ45cbo2rwX tBiMaDUIbtoSsGlLwKYtAe8CtA34MhTDZKTK5aEUrbnCMJm6UB2lfwzYu+h/6jjWDSwdRweA H4ZIfXF7zbJSvD0pMzlPrWLUl+lsLcUMgJ2YQEriPZOtSjGRqtJT6RSVRdHr6i4Mk0I8r5Z1 etFUKpWbotHqN2UEcx8AEPOQ+uDl3AzOZKkyGE0qrw+DPRISv8oJBCeos3UbXu5y851O5zjw l3jjwMXFRezB7s3Q6Dd17rLnAIkBqTfewL3iodHpN16fYxcj7GKfsT/cYr1qU5IUgLr29I/n u0A8WV9zyCMhTSZpeYZYikdml8IuRpk1LY3WsL99ujbPSn9nhcneTkweIY2xnxcdSboEZcj9 pNgIc398zGlnafXKxKnQxRy1rMqvUm4Lf58SGEwXvSHNidF+xsTu0XlP2Zmlyi/xjkhrf+S2 OLJzUlt9osB8rvqfVMCoVfL9KM2o/gOc5BOJtAMAAA== list-archive: list-post: list-id: errors-to: ahmpls-tp-owner@lists.itu.int x-no-archive: yes x-sequence: 1640 x-loop: ahmpls-tp@lists.itu.int x-greylist: Delayed for 00:20:15 by milter-greylist-4.4a2 (mail8.itu.ch [156.106.192.38]); Fri, 18 Jan 2013 01:22:20 +0100 (CET) list-owner: x-originating-ip: [1.33.190.161] x-starscan-version: 6.7; banners=-,-,- x-viruschecked: Checked x-msg-ref: server-2.tower-54.messagelabs.com!1358467314!14514699!1 x-env-sender: yoichi.maeda@ttc.or.jp Content-Type: text/plain; charset="us-ascii" Content-ID: <51C654A18A4FFD4B92746CEFA031228F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Dear Greg and all; Thank you for your information. Congratulation on the closure of the ad hoc group. =20 As the ex-SG15 chairman, I am very glad to see this announcement after the long collaboration between ITU-T and IETF since 2008. I hope the remaining work on MPLS-TP will be carried out in the relevant questions under the leadership of the new SG15 Chairman, Dr. Steve Trowbridge.. I would like to express my sincere thanks to all colleagues in ITU-T and IETF who contributed to this important subject in the last study period.=20 I hope you will keep the collaborative relations with other SDOs and Fora, and will have fruitful results in your new study period of 2013-2016. Regards, Yoichi Maeda Ex-SG15 Chairman and Chairman of Review Committee On Thu, 17 Jan 2013 22:53:14 +0000 "Jones, Greg" wrote: > The ad hoc Group on MPLS-TP was formed by SG 15 in February 2008 to coord= inate work on the development of the MPLS-TP Recommendations within SG 15 a= nd to provide a focal point for communications with the IETF. > Following the approval of the several of the key Recommendation including= the OAM Recommendations (G.8113.1 and G.8113.2) approved by WTSA in Novemb= er 2012 the SG 15 management team have concluded that coordination role pro= vided by the ad hoc group is no longer required since the remaining work on= MPLS-TP can be carried out directly in the relevant questions, as describe= d below. Note that responsibility for the equipment aspects has been moved = from Q9/15 to Q10/15 effective in the 2013-2016 study period. > Q3/15: responsible for MPLS-TP Terminology > Q9/15: responsible for MPLS-TP Protection > Q10/15: responsible for MPLS-TP OAM and Equipment > Q12/15: responsible for MPLS-TP Network Architecture > Q14/15: responsible for MPLS-TP Network Management >=20 > Consequently the ad hoc Group on MPLS-TP will not be continued in the new= study period (2013-2016). Therefore, the email reflector (ahmpls-tp@lists.= itu.int) will be deactivated after this message has been transmitted. >=20 > The SG15 management team has appointed Mr. Malcolm Betts (malcolm.betts@z= te.com.cn) as the acting liaison Rapporteur to the IETF for matters related= to MPLS-TP, pending confirmation in the July 2013 plenary. He will also co= ntinue to act as the contact point for any issues on MPLS-TP that are not d= irectly related to the work of the Questions. >=20 >=20 > Regards, > Greg Jones > Counsellor, ITU-T Study Group 15 > International Telecommunication Union > Tel: +41 22 730 5515 > Mob: +41 79 249 4832 >=20 ****** New position from October 1st. 2010 ****** Yoichi MAEDA The Telecommunication Technology Committee (TTC) CEO & S.V.P. Chairman ITU-T Study Group 15,=20 Fellow of IEICE Address: 1-1-12 Shiba kouen, Minato-ku, Tokyo, 105-0011, JAPAN Tel: +81-3-5776-7730 Fax: +81-3-3432-1553 E-mail: yoichi.maeda@ttc.or.jp ************************************************** --_005_EF35EE4B92789843B1DECBC0E24558640FF6C2eusaamb105ericsso_-- From zhangfatai@huawei.com Sun Jan 20 18:43:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895FA21F87FF for ; Sun, 20 Jan 2013 18:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[J_CHICKENPOX_45=0.6, 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 fKGjQGz1U9tx for ; Sun, 20 Jan 2013 18:43:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9495921F886D for ; Sun, 20 Jan 2013 18:43:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOY51649; Mon, 21 Jan 2013 02:43:41 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 21 Jan 2013 02:43:35 +0000 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 21 Jan 2013 10:43:40 +0800 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Mon, 21 Jan 2013 10:43:26 +0800 From: Fatai Zhang To: Lou Berger Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 Thread-Index: AQHN4nqPdVRTcHuIFUSv0ekPirccYZg3rcsAgBJvoeCAABn/gIABKi7ggAIHU4CABdAXUA== Date: Mon, 21 Jan 2013 02:43:24 +0000 Message-ID: References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> <50F58A35.7040806@labn.net> <50F837FB.2010806@labn.net> In-Reply-To: <50F837FB.2010806@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 02:43:44 -0000 Hi Lou, You said: >but you're says encoded as (N*Nominal Rate) right? Wat's the value of this= vs just carrying N? [Fatai] The original way (in version 04&05) is putting (N* Nominal Rate) in= "Bit_Rate" field for ODUflex(GFP), the value is that we can generalize to = just use one single "Bit_Rate" field to carry IEEE float number for both ca= ses, it seems that you don't agree on this value, :-) . Therefore, I (was) = am saying that I am going to accept your suggestion to carry N for ODUflex(= GFP). We are discussing where to put N for ODUflex(GFP). You said: >bits in the control plane are generally cheap, IMO it's better to have sim= pler encoding than to optimize every bit (or 8 in this case). [Fatai] OK, I will add a new field (to occupy the reserved bits) to carry N= . Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, January 18, 2013 1:42 AM To: Fatai Zhang Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signal= ing-g709v3-04 On 1/15/2013 10:16 PM, Fatai Zhang wrote: > Hi Lou, > > To avoid misunderstanding, I would like to clarify more on the > following point. > > >>>>> It is better to have consistent format and the same meaning of one field for both ODUflex(CBR) and GFP. This is why we have section 5.1 &5.2 to describe the complex stuff. >>>> I actually wasn't suggesting that N be carried in the bit rate field. >>>> The bit rate field can either be set as described or to zero (i.e., >>>> ignored). At the time, I was thinking about carrying N in the reserve= d >>>> field. But perhaps the right place is MT, if my understanding is right >>>> (would always be 1 otherwise). I'm open to either... >>>> >>> [Fatai] Why not just use "bit rate"field to carry "N"because "N" >>> implies bit rate? I am OK if you like to use a new filed (like "TS >>> Number") to occupy the reserved field even though that I prefer the >>> original approach (ie., use "bit rate"field to carry "N"). >> >> Are you proposing dropping carrying bit rates represented as an IEEE >> floating point and just carrying N for ODUflex? This seems workable to >> me, but we should ensure that there are no significant objections. > > [Fatai] There are two usages for " Bit_Rate " field as described in the > lines 287-310. > > (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal bit > rate of ODUflex(CBR) expressed in bytes per second, encoded as a 32-bit > IEEE single precision floating-point number. For this case, we MUST use > 32-bit IEEE floating point instead of "N"(Please see more in section 5.1)= . I guess you really still need (to be based on) the client signal rate at the edges. > > (2) For ODUflex(GFP), we can change the text (the lines from 305 to > 310) based on your suggestion, ie., the Bit_Rate field is used to carry > "N"to indicate the nominal bit rate of the > ODUflex(GFP). but you're says encoded as (N*Nominal Rate) right? Wat's the value of this vs just carrying N? > > Therefore, I am proposing using one single filed ("Bit_Rate ") for these > two cases, in this way, we can leave the "Reserved" bits for future. bits in the control plane are generally cheap, IMO it's better to have simpler encoding than to optimize every bit (or 8 in this case). Lou > > Hope we are now at the same page. > > > Best Regards > > Fatai From daniele.ceccarelli@ericsson.com Mon Jan 21 06:41:18 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEEA21F84B2 for ; Mon, 21 Jan 2013 06:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_62=0.6, 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 CDlutTSWNh-R for ; Mon, 21 Jan 2013 06:41:17 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AA68C21F8479 for ; Mon, 21 Jan 2013 06:41:16 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-c7-50fd538bab2d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B1.98.32353.B835DF05; Mon, 21 Jan 2013 15:41:15 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.004; Mon, 21 Jan 2013 15:41:15 +0100 From: Daniele Ceccarelli To: Lou Berger Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRwFLO6lqWmk6S/LNDTw8InABmd7EAAJAH/XA= Date: Mon, 21 Jan 2013 14:41:14 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> In-Reply-To: <50F985EC.1050704@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW538N8Ag7uTdSyezLnBYtHR/JbF gcljyZKfTB4fNjWzBTBFcdmkpOZklqUW6dslcGVsPdjHVnCzvmLjVMMGxnfJXYycHBICJhLr nx5ih7DFJC7cW8/WxcjFISRwiFFi4cxHjCAJIYHFjBIrzih0MXJwsAlYSTw55AMSFhFQlPj6 cRETiM0sICVx91YXWLmwgL7Er9vzmCFqDCRmbPnEBmFbSexZ9pAFxGYRUJVY9GY92F5eAW+J 5ze3QK3KlJh38zoriM0poCGx5MNssBpGAVmJCbsXMULsEpe49WQ+E8TNAhJL9pxnhrBFJV4+ /scKYStKfHy1D6peT+LG1ClsELa2xLKFr5kh9gpKnJz5hGUCo9gsJGNnIWmZhaRlFpKWBYws qxjZcxMzc9LLzTcxAuPj4JbfBjsYN90XO8QozcGiJM4b7nohQEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVANjtdk6rkM3DPadM1SzzAhm0uu3FQ7bor9+z9Q/z+e3MNxfpLNBiVXQmTsgMdyK jalpwxv7/x+uJX8ya/h+au42q8xX50tC1Vvuiwr+v6O3IPn3m20n93m4MCX/fJt96s1UacE1 y601RZhSFe8fVJ9r6rjlUfN2wyssiqXZHI41XBe2rHOqNN6ixFKckWioxVxUnAgA1bTVh10C AAA= Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 14:41:18 -0000 Hi Lou, Please find comments in line BR Daniele=20 >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net]=20 >Sent: venerd=EC 18 gennaio 2013 18.27 >To: Daniele Ceccarelli >Cc: CCAMP >Subject: Re: [CCAMP] Overlay model framework v2 > >Daniele, > Very nice summary. Just catching up, so sorry for the=20 >(2 day) late response. > >I really like how the terminology has evolved and appreciate=20 >the summary! > >I have a few detail comments, but before I go there I'd like=20 >to cover one more open issue that I think will have some=20 >(minor) ripple effects on the details. > >I think there's still the general issue of terminology to use=20 >when referring to the entity that "uses an overlay" and the=20 >entity that "instantiates the overlay". In your mail and in=20 >discussion we have: > >- client (service)/OC/CN/customer > >and > >- server(or service)/OE/EN/provider > >I think we had discussed, and possibly agreed on, using VPN=20 >terminology which would have us use the latter options, i.e., >(overlay) customer/provider (edge). This would mean=20 >eliminating any references to client/server in the *generic=20 >overlay* definitions. Of course these terms may reemerge in=20 >other contexts as they have before, e.g., rfc6215. Yes, i think we all agreed. If there are still terms different from custome= r/provider in the text it's because i missed them during the replacing. > >I like this approach as it is aligned with the much of IETF=20 >work on overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN=20 >(e.g. RFC 4847). Importantly, RFC 4847 even has quite a few=20 >concepts that can be directly leveraged in this discussion. > >I'd even go further and say that we should base the=20 >definitions and resulting framework on RFC 4847. For example,=20 >the definitions below could start with something along the lines: > > The overlay service model, at a high level, follows Section > 7. of RFC 4847 as represented by: > > > +--------------------+ > : | | : > : | | : > +----+ : +----+ +----+ : +----+ > | CE |---:---| PE | | PE |---:---| CE | > +----+ : +----+ +----+ : +----+ > : | | : > : | | : > : +--------------------+ : > : | | : > : |<-Provider network->| : > Customer Customer > interface interface > > Figure 7.2: Overlay Service Model > > In this model, the overlay is instantiated by an overlay > "provider" and its provider edge (PE) nodes , and is used by > the overlay "customer" which is connected to the provider via > customer interfaces attached to customer edge (CE) nodes. > > ... > >The definition below would need to be tweaked slightly,=20 >notably to remove any references to client and server. The=20 >resulting framework can also refer back to RFC 4847 as needed. > >See below for some additional comments. > >On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >> Dear overlayers, >>=20 >> Please find below a new version (v2) of the framework summary=20 >> reflecting the latest discussions. Again i hope i've=20 >captured all the=20 >> comments around, sorry if anything is missing, in case just let me=20 >> know what i missed. >>=20 >> BR >> Daniele >>=20 >>=20 >> + Disclaimer: >> 1. Packet opto integration is often considered but the work can be=20 >> extented to any type of SC. Eg. TDM over LSC. >>=20 >> + Terminology: >> 1. Virtual Link: A virtual link is a potential path between two=20 >> virtual or real network elements in a provider layer network=20 > that is=20 >> maintained/controlled in and by the provider domain control=20 >plane (and=20 >> as such cannot transport any traffic/data and protected from being=20 >> de-provisioned) and which can be instantiated in the data plane (and=20 >> then can carry/transport/forward traffic/data) preserving previously=20 >> advertised attributes such as fate sharing information. >>=20 > >You say "potential path". I this this should read "potential=20 >or instantiated path". > Maybe we need to define also what "potential" stands for? At least two case= s come to my mind (which might be included under the "potential" umbrella): 1. resources reserved via signaling but not instantiated 2. resources not even signaled. In presence of a centralized entity managin= g the network (sort of PCE plus something) there is no need to reserve reso= urces via signaling as the central entity is the only thing that can reserv= e or allocate resources. I'm thinking to an opening towards the integration= with the SDN world. Just loud thinking, does it make sense? >From my perspective, I think a node in the overlay really shouldn't >*directly* distinguish between the two -- now one may have a=20 >different metric/SRLG/weight/etc, but these are abstracted=20 >representations of the tradeoffs between use of the two, that=20 >can be provided by the underlying provider network, rather=20 >than a direct indication. > >> 2. Virtual Node: Virtual node is a collection of zero or more=20 >> provider network domain nodes that are collectively=20 >represented to the=20 >> clients as a single node that exists in the customer layer=20 >network and=20 >> is capable of terminating of access, inter-domain and virtual links. >>=20 > >I'm a little uncomfortable with the linkage of real nodes to=20 >virtual nodes. I think VN is a purely abstract concept that=20 >may be instantiated using parts/whole/multiple/logical/real/etc nodes. Makes sense. What this definition adds to the one in RFC4847 is basically t= he fact that also parts of a node can be considered. What saying that it ca= n be a real node i meant 1:1 correspondance between a real and a virtual no= de. Your definition covers that case also, that's fine. > >How about something like: >Virtual Node: A virtual node is a representation of a=20 >collection of provider resources that are interconnected via=20 >virtual (and customer) links. A virtual node may be=20 >collection of zero or more, including portions of, provider=20 >nodes that are collectively represented to the customer as a=20 >single node which is available in an overlay network. Works for me. > >> 3. Virtual Topology: Virtual topology is a collection of one or more=20 >> virtual or real provider network domain nodes that exist in the=20 >> customer layer network and are interconnected via 0 or more virtual=20 >> links. > >How about: >Virtual Topology: A virtual topology is the collection of=20 >virtual links and nodes advertised by a provider to a=20 >customer. The virtual topology includes resources that are=20 >advertised as reachable within an overlay network. > >Do you mean to imply/allow for a VN which has no links? The case of "interconnected via 0 virtual links" implies the whole domain s= een as a single node. > >> 4. Overlay topology: is a superset of virtual topologies=20 >provided by=20 >> each of provider network domains, access and inter-domain links. >>=20 > >Doesn't it also include any topology information advertised by=20 >the customer/CE as well? Possibly. Do you mean advertised by the CE in the customer domain, right? > >> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It=20 >> can support any of the SCs supported by the GMPLS. >>=20 > >If we adopt RFC 4847 terminology it should be "customer interface". >Also, I suspect you mean PE and CE. Mmm, yes but what if we want to manage it as a link? i.e. All TE-parameters= that a link supports. Is it enough to call it interface only?=20 > >> 6. CE (customer Edge): Something like the CN in RFC4208=20 >teminology but=20 >> (i) receiving virtual topology from the provider network and=20 >> requesting the set up of one of them or (ii) requesting the=20 >> computation and establishment of a path accordingly to given=20 >> constraints in the provider network and receiving the parameters=20 >> characterizing such path. (ii) =3D=3D UNI. >>=20 > >humm, I'm inclined to stay away from UNI for the moment. I=20 >also suggest that we look to 4874 and even 4364 rather than 4208... Ok, we can refer to those RFC for what concerns terminology, but at the end= of the day we must put the UNI under this framework. In the new terminolog= y the UNI is a particular type of customer interface. > >> 7. PE (provider Edge): Something like the EN in RFC4208 but able to=20 >> deal with (i) and (ii) above. >>=20 > >same comment WRT RFCs. > >> 8. PE-CE interface (former ONI) : Interface allowing for=20 >signaling and=20 >> routing messages exchange between customer overlay and provider=20 >> network. Routing information consists on virtual topology=20 >> advertisement. When there is no routing adjacency across the=20 >interface=20 >> it is equivalent to the GMPLS UNI defined in 4208. >> Signaling messages are compliant with RFC4208. Information=20 >related to=20 >> path carachteristics, e.g. TE-metrics, collected SRLG, path=20 >delay etc,=20 >> either passed from CE to PE via signaling after the LSP=20 >establishment=20 >> in the core network or from CE to PE to be used as path computation=20 >> constraints, fall under the definition of signaling info and not=20 >> routing info). >>=20 > > >> 9. CE-CE (former O-NNI): Interface on the links between different=20 >> provider networks in the overlay model environment. Same features of=20 >> the CE-PE apply to this interface. >>=20 > >you mean, PE-PE, right? You're not the first one that makes me notice i'm probably affected by dysl= exia :-) > >> + Statements 1. In the context of overlay model we are aiming to >> build an overlay topology for the customer network domains >>=20 >> 2. The overlay topology is comprised of: >> a) access links (links connecting client NEs to the=20 >provider network domains). >> They can be PSC or LSC. >> b) inter-domain links (links interconnecting server=20 >network domains) >> c) virtual topology provided by the provider network domains.=20 >> Virtual Links >> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of parameters >> e.g. SRLG, optical impairments, delay etc for each entry) describing=20 >> connectivity between access links and virtual links. >>=20 >> 3. In the context of overlay model we manage hierarchy of overlay=20 >> topologies with overlay/underlay relationships >>=20 >> 4. In the context of overlay model multi-layering and inter-layer=20 >> relationships are peripheral at best, it is all about horizontal=20 >> network integration >> >> 5. The overlay model assumes one CP instance for the=20 >customer network=20 >> and a separate instance for the provider network and in the CE-PE=20 >> interface case the provider network also surreptitiously=20 >participates=20 >> in the customer network by injecting virtual topology=20 >information into=20 >> it. >>=20 > >We should ensure we're allowing for some of the=20 >existing/augmented models that permit the transport of overlay=20 >information within the provider's CP, e.g., rfc4364, 5195 and 5252. I'd say they should be already covered, but will double check > >> 6. L1VPN (and LxVPN) in general is a type of service=20 >provided over the=20 >> CE-PE interface (it falls under the UNI case as no routing adjacency=20 >> is in place between CE and PE). >>=20 >>=20 >> + Advertisement models (to be detailed in dedicated=20 >> + document/documents) >> The CE-PE interface in the overlay model context foresees=20 >two types of=20 >> advertisement models.(names still to be agreed) >>=20 >> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and=20 >augmented by=20 >> a number of actived draft (references to various drafts to=20 >be added).=20 >> The Augmented UNI is a particular type of CE-PE interface where only=20 >> signaling messages are exchanged between CE and PE. >> Messages from CE to PE can include a set of parameters to be used by=20 >> the PE as path computation constraints when computing a path in the=20 >> provider domain network, while messages from PE to CE can include a=20 >> set of parameters qualifying the LSP being established, like for=20 >> example SRLG, delay, loss etc. >>=20 > >again, we can leverage 4874 terminology if we so choose, i.e.,=20 >"basic mode" and "enhanced mode" UNI|NNI Don would be happy about that :-). I'd say yes. The goal was to cover the L= 1VPN work (enhanced mode), all the drafts-ali recently polled for wg adopt= ion (basic mode?) and the actual ENNI (enhanced mode). Is my mapping in bra= ckets correct? > >> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >> called with the general CE-PE interface term?) allowing the=20 >> establishment of signaling and routing adjacency between CE and PE. >> Routing info passed from PE to CE comprise overlay topology=20 >> information including (but not limited to) virtual links,=20 >connectivity=20 >> matrices and access links with parameters qualifying each of them in=20 >> terms of e.g. SRLG, loss, delay etc. Signaling information and=20 >> procedures are compliant with RFC4208. >>=20 > >so this is just and 4874 "enhanced mode" interface, right. Good question: the enhanced mode supports signaling and routing, so i'd say= yes, but reading section 7.3 it talks about "limited exchange of informati= on between the control planes. "permits limited exchange of information between the control planes of the provider and the customer to help such functions as discovery of customer network routing information (i.e., reachability or TE information in remote customer sites), or parameters of the part of the provider's network dedicated to the customer." Would you say this includes what we want? (i.e. Virtual links, virtual node= s, connectivity matrices, SRLG, delay, loss, etc) If yes we're done, otherwise an option could be the denition of a third VPN= service model. > >> + Open issues/questions >> 1. PCE-PCEP - do we need to include considerations about PCE=20 >and PCEP=20 >> into the overlay framework context? >>=20 >> 2. BGP-LS needs to be considered >> 3. Should potentials be included? E.g. I2RS? >> 4. Virtual links: wouldn't a different definition of virtual links=20 >> avoid the advertisement of connectivity matrices (this is out of the=20 >> fwk scope but within the advertisement models one)? >>=20 > >> Take this example: >> PE1-----CE1 CE2-----PE2 >> CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >> CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 > >I think you've reversed CE and PE here... Yes, once again. No comment on my foolish proposal? > >Much thanks! > >Lou >(hatless...) > >> i.e. There are 2 VL connecting CE1 and CE2 that could be=20 >available for=20 >> PE1 and PE2 to set up an adjacency in the customer domain.=20 >CE1 and/or=20 >> CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >> depending on the connectivity matrices of CE1 and CE2. Hence=20 >PEs need=20 >> to be aware of both VL and connectivity matrices. My point=20 >is: if CE1=20 >> advertises to PE1 only the VL that his connectivity matrix allows to=20 >> be connected to PE1 (e.g. VL1 only) and not all of them, it=20 >should be=20 >> possible to avoid the connectivity matrices advertisement. >>=20 > >> =20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> DANIELE CECCARELLI >> System & Technology - PDU Optical & Metro >>=20 >> Via E.Melen, 77 >> Genova, Italy >> Phone +390106002512 >> Mobile +393346725750 >> daniele.ceccarelli@ericsson.com >> www.ericsson.com >>=20 >= From lberger@labn.net Mon Jan 21 14:13:02 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF0121F8521 for ; Mon, 21 Jan 2013 14:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.199 X-Spam-Level: X-Spam-Status: No, score=-100.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6, 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 1ltpOGrM6sQ5 for ; Mon, 21 Jan 2013 14:13:00 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 741CF21F84DE for ; Mon, 21 Jan 2013 14:13:00 -0800 (PST) Received: (qmail 11654 invoked by uid 0); 21 Jan 2013 22:12:35 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 21 Jan 2013 22:12:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=BA2U3S27JqqkFQ8S/PoSQGdhRzWRc0mhzMcqXiAVxwU=; b=kNHHqOKpFO5fggaFSqu50pK3pH9lowrALRTtGYjbT4ZLBHiFNFtkg+IQXfAbN4NBfx4Cfnzx3Pvqo5WAEI6iosabT+wULf78SjohVug/G2koiSZuYqhprUvWkA7UdtOc; Received: from box313.bluehost.com ([69.89.31.113]:47294 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TxPbW-0002ei-HW; Mon, 21 Jan 2013 15:12:34 -0700 Message-ID: <50FDBD5B.6030307@labn.net> Date: Mon, 21 Jan 2013 17:12:43 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Daniele Ceccarelli References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 22:13:02 -0000 Thanks Daniele, See below. On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: > Hi Lou, > > Please find comments in line > > BR > Daniele > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: venerd 18 gennaio 2013 18.27 >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Daniele, >> Very nice summary. Just catching up, so sorry for the >> (2 day) late response. >> >> I really like how the terminology has evolved and appreciate >> the summary! >> >> I have a few detail comments, but before I go there I'd like >> to cover one more open issue that I think will have some >> (minor) ripple effects on the details. >> >> I think there's still the general issue of terminology to use >> when referring to the entity that "uses an overlay" and the >> entity that "instantiates the overlay". In your mail and in >> discussion we have: >> >> - client (service)/OC/CN/customer >> >> and >> >> - server(or service)/OE/EN/provider >> >> I think we had discussed, and possibly agreed on, using VPN >> terminology which would have us use the latter options, i.e., >> (overlay) customer/provider (edge). This would mean >> eliminating any references to client/server in the *generic >> overlay* definitions. Of course these terms may reemerge in >> other contexts as they have before, e.g., rfc6215. > > Yes, i think we all agreed. If there are still terms different from > customer/provider in the text it's because i missed them during the > replacing. > Great! Glad I didn't miss something over the holidays! >> >> I like this approach as it is aligned with the much of IETF >> work on overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN >> (e.g. RFC 4847). Importantly, RFC 4847 even has quite a few >> concepts that can be directly leveraged in this discussion. >> >> I'd even go further and say that we should base the >> definitions and resulting framework on RFC 4847. For example, >> the definitions below could start with something along the lines: >> >> The overlay service model, at a high level, follows Section >> 7. of RFC 4847 as represented by: >> >> >> +--------------------+ >> : | | : >> : | | : >> +----+ : +----+ +----+ : +----+ >> | CE |---:---| PE | | PE |---:---| CE | >> +----+ : +----+ +----+ : +----+ >> : | | : >> : | | : >> : +--------------------+ : >> : | | : >> : |<-Provider network->| : >> Customer Customer >> interface interface >> >> Figure 7.2: Overlay Service Model >> >> In this model, the overlay is instantiated by an overlay >> "provider" and its provider edge (PE) nodes , and is used by >> the overlay "customer" which is connected to the provider via >> customer interfaces attached to customer edge (CE) nodes. >> >> ... >> >> The definition below would need to be tweaked slightly, >> notably to remove any references to client and server. The >> resulting framework can also refer back to RFC 4847 as needed. >> >> See below for some additional comments. >> >> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>> Dear overlayers, >>> >>> Please find below a new version (v2) of the framework summary >>> reflecting the latest discussions. Again i hope i've >> captured all the >>> comments around, sorry if anything is missing, in case just let me >>> know what i missed. >>> >>> BR >>> Daniele >>> >>> >>> + Disclaimer: >>> 1. Packet opto integration is often considered but the work can be >>> extented to any type of SC. Eg. TDM over LSC. >>> >>> + Terminology: >>> 1. Virtual Link: A virtual link is a potential path between two >>> virtual or real network elements in a provider layer network >> that is >>> maintained/controlled in and by the provider domain control >> plane (and >>> as such cannot transport any traffic/data and protected from being >>> de-provisioned) and which can be instantiated in the data plane (and >>> then can carry/transport/forward traffic/data) preserving previously >>> advertised attributes such as fate sharing information. >>> >> >> You say "potential path". I this this should read "potential >> or instantiated path". >> > > Maybe we need to define also what "potential" stands for? At least > two cases come to my mind (which might be included under the > "potential" umbrella): > > 1. resources reserved via signaling but not instantiated Sure. Sounds like a RFC6001 soft FA. > 2. resources not even signaled. In presence of a centralized entity > managing the network (sort of PCE plus something) there is no need to > reserve resources via signaling as the central entity is the only > thing that can reserve or allocate resources. I'm thinking to an > opening towards the integration with the SDN world. > Sure. Sounds like a Virtual TE link (per RFC6001, 5212). > Just loud thinking, does it make sense? > >>From my perspective, I think a node in the overlay really shouldn't >> *directly* distinguish between the two -- now one may have a >> different metric/SRLG/weight/etc, but these are abstracted >> representations of the tradeoffs between use of the two, that >> can be provided by the underlying provider network, rather >> than a direct indication. >> >>> 2. Virtual Node: Virtual node is a collection of zero or more >>> provider network domain nodes that are collectively >> represented to the >>> clients as a single node that exists in the customer layer >> network and >>> is capable of terminating of access, inter-domain and virtual links. >>> >> >> I'm a little uncomfortable with the linkage of real nodes to >> virtual nodes. I think VN is a purely abstract concept that >> may be instantiated using parts/whole/multiple/logical/real/etc nodes. > > Makes sense. What this definition adds to the one in RFC4847 is > basically the fact that also parts of a node can be considered. What > saying that it can be a real node i meant 1:1 correspondance between > a real and a virtual node. Your definition covers that case also, > that's fine. > >> >> How about something like: >> Virtual Node: A virtual node is a representation of a >> collection of provider resources that are interconnected via >> virtual (and customer) links. A virtual node may be >> collection of zero or more, including portions of, provider >> nodes that are collectively represented to the customer as a >> single node which is available in an overlay network. > > Works for me. > Great. BTW I don't think 4847 precluded a single physical node being represented as multiple virtual nodes, but it doesn't hurt to make it explicit. >> >>> 3. Virtual Topology: Virtual topology is a collection of one or more >>> virtual or real provider network domain nodes that exist in the >>> customer layer network and are interconnected via 0 or more virtual >>> links. >> >> How about: >> Virtual Topology: A virtual topology is the collection of >> virtual links and nodes advertised by a provider to a >> customer. The virtual topology includes resources that are >> advertised as reachable within an overlay network. >> >> Do you mean to imply/allow for a VN which has no links? > > The case of "interconnected via 0 virtual links" implies the whole > domain seen as a single node. > Ahh, fair enough. >> >>> 4. Overlay topology: is a superset of virtual topologies >> provided by >>> each of provider network domains, access and inter-domain links. >>> >> >> Doesn't it also include any topology information advertised by >> the customer/CE as well? > > Possibly. Do you mean advertised by the CE in the customer domain, right? > That's possible too, but I was thinking more of advertised by CE (customer) to PE (provider). >> >>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It >>> can support any of the SCs supported by the GMPLS. >>> >> >> If we adopt RFC 4847 terminology it should be "customer interface". >> Also, I suspect you mean PE and CE. > > Mmm, yes but what if we want to manage it as a link? i.e. All > TE-parameters that a link supports. Is it enough to call it interface > only? > sure. Per 4847, I'd say that "customer interface" is the connection between CE/PE while [virtual] TE links are what is advertised/represented in routing. >> >>> 6. CE (customer Edge): Something like the CN in RFC4208 >> teminology but >>> (i) receiving virtual topology from the provider network and >>> requesting the set up of one of them or (ii) requesting the >>> computation and establishment of a path accordingly to given >>> constraints in the provider network and receiving the parameters >>> characterizing such path. (ii) == UNI. >>> >> >> humm, I'm inclined to stay away from UNI for the moment. I >> also suggest that we look to 4874 and even 4364 rather than 4208... > > Ok, we can refer to those RFC for what concerns terminology, but at > the end of the day we must put the UNI under this framework. In the > new terminology the UNI is a particular type of customer interface. > Fair enough. But it is a form on an overlay "customer interface" not the definitive form. >> >>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to >>> deal with (i) and (ii) above. >>> >> >> same comment WRT RFCs. >> >>> 8. PE-CE interface (former ONI) : Interface allowing for >> signaling and >>> routing messages exchange between customer overlay and provider >>> network. Routing information consists on virtual topology >>> advertisement. When there is no routing adjacency across the >> interface >>> it is equivalent to the GMPLS UNI defined in 4208. >>> Signaling messages are compliant with RFC4208. Information >> related to >>> path carachteristics, e.g. TE-metrics, collected SRLG, path >> delay etc, >>> either passed from CE to PE via signaling after the LSP >> establishment >>> in the core network or from CE to PE to be used as path computation >>> constraints, fall under the definition of signaling info and not >>> routing info). >>> >> >> >>> 9. CE-CE (former O-NNI): Interface on the links between different >>> provider networks in the overlay model environment. Same features of >>> the CE-PE apply to this interface. >>> >> >> you mean, PE-PE, right? > > You're not the first one that makes me notice i'm probably affected > by dyslexia :-) > no problem, happens to the best of us! >> >>> + Statements 1. In the context of overlay model we are aiming to >>> build an overlay topology for the customer network domains >>> >>> 2. The overlay topology is comprised of: >>> a) access links (links connecting client NEs to the >> provider network domains). >>> They can be PSC or LSC. >>> b) inter-domain links (links interconnecting server >> network domains) >>> c) virtual topology provided by the provider network domains. >>> Virtual Links >>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of parameters >>> e.g. SRLG, optical impairments, delay etc for each entry) describing >>> connectivity between access links and virtual links. >>> >>> 3. In the context of overlay model we manage hierarchy of overlay >>> topologies with overlay/underlay relationships >>> >>> 4. In the context of overlay model multi-layering and inter-layer >>> relationships are peripheral at best, it is all about horizontal >>> network integration >>> >>> 5. The overlay model assumes one CP instance for the >> customer network >>> and a separate instance for the provider network and in the CE-PE >>> interface case the provider network also surreptitiously >> participates >>> in the customer network by injecting virtual topology >> information into >>> it. >>> >> >> We should ensure we're allowing for some of the >> existing/augmented models that permit the transport of overlay >> information within the provider's CP, e.g., rfc4364, 5195 and 5252. > > I'd say they should be already covered, but will double check > great. >> >>> 6. L1VPN (and LxVPN) in general is a type of service >> provided over the >>> CE-PE interface (it falls under the UNI case as no routing adjacency >>> is in place between CE and PE). >>> >>> >>> + Advertisement models (to be detailed in dedicated >>> + document/documents) >>> The CE-PE interface in the overlay model context foresees >> two types of >>> advertisement models.(names still to be agreed) >>> >>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >> augmented by >>> a number of actived draft (references to various drafts to >> be added). >>> The Augmented UNI is a particular type of CE-PE interface where only >>> signaling messages are exchanged between CE and PE. >>> Messages from CE to PE can include a set of parameters to be used by >>> the PE as path computation constraints when computing a path in the >>> provider domain network, while messages from PE to CE can include a >>> set of parameters qualifying the LSP being established, like for >>> example SRLG, delay, loss etc. >>> >> >> again, we can leverage 4874 terminology if we so choose, i.e., >> "basic mode" and "enhanced mode" UNI|NNI > > Don would be happy about that :-). I'd say yes. The goal was to cover > the L1VPN work (enhanced mode), all the drafts-ali recently polled > for wg adoption (basic mode?) and the actual ENNI (enhanced mode). > Is my mapping in brackets correct? > Not sure f I'd break it down they way you are. I'd say basic mode is closer to the typical UNI and enhance mode is UNI+routing or perhaps even an ENNI. > >> >>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >>> called with the general CE-PE interface term?) allowing the >>> establishment of signaling and routing adjacency between CE and PE. >>> Routing info passed from PE to CE comprise overlay topology >>> information including (but not limited to) virtual links, >> connectivity >>> matrices and access links with parameters qualifying each of them in >>> terms of e.g. SRLG, loss, delay etc. Signaling information and >>> procedures are compliant with RFC4208. >>> >> >> so this is just and 4874 "enhanced mode" interface, right. > > Good question: the enhanced mode supports signaling and routing, so > i'd say yes, but reading section 7.3 it talks about "limited exchange > of information between the control planes. > > "permits limited exchange of > information between the control planes of the provider and the > customer to help such functions as discovery of customer network > routing information (i.e., reachability or TE information in remote > customer sites), or parameters of the part of the provider's network > dedicated to the customer." > > Would you say this includes what we want? (i.e. Virtual links, > virtual nodes, connectivity matrices, SRLG, delay, loss, etc) If yes > we're done, otherwise an option could be the denition of a third VPN > service model. > humm, need to think about this. Perhaps the best thing is to document the two different cases and then decide if we have something new or (two) more detailed forms of something old. >> >>> + Open issues/questions >>> 1. PCE-PCEP - do we need to include considerations about PCE >> and PCEP >>> into the overlay framework context? >>> >>> 2. BGP-LS needs to be considered >>> 3. Should potentials be included? E.g. I2RS? >>> 4. Virtual links: wouldn't a different definition of virtual links >>> avoid the advertisement of connectivity matrices (this is out of the >>> fwk scope but within the advertisement models one)? >>> >> >>> Take this example: >>> PE1-----CE1 CE2-----PE2 >>> CE1======VL1======CE2 >>> CE1======VL2======CE2 >> >> I think you've reversed CE and PE here... > > Yes, once again. > > No comment on my foolish proposal? > Which one? I liked your summary overall. Lou > >> >> Much thanks! >> >> Lou >> (hatless...) >> >>> i.e. There are 2 VL connecting CE1 and CE2 that could be >> available for >>> PE1 and PE2 to set up an adjacency in the customer domain. >> CE1 and/or >>> CE2 can be blocking nodes so VL1 and/or VL2 are available only >>> depending on the connectivity matrices of CE1 and CE2. Hence >> PEs need >>> to be aware of both VL and connectivity matrices. My point >> is: if CE1 >>> advertises to PE1 only the VL that his connectivity matrix allows to >>> be connected to PE1 (e.g. VL1 only) and not all of them, it >> should be >>> possible to avoid the connectivity matrices advertisement. >>> >> >>> >>> =================================== >>> DANIELE CECCARELLI >>> System & Technology - PDU Optical & Metro >>> >>> Via E.Melen, 77 >>> Genova, Italy >>> Phone +390106002512 >>> Mobile +393346725750 >>> daniele.ceccarelli@ericsson.com >>> www.ericsson.com >>> >> > > > From tm-otani@kddi.com Mon Jan 21 19:58:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E602511E8097 for ; Mon, 21 Jan 2013 19:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 CW4Jt-lsMi+G for ; Mon, 21 Jan 2013 19:58:56 -0800 (PST) Received: from UTMC1102.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 10C7C21F87C8 for ; Mon, 21 Jan 2013 19:58:55 -0800 (PST) Received: from UTMC1136 (unknown [10.5.16.207]) by UTMC1102.kddi.com (Postfix) with SMTP id 725392B38; Tue, 22 Jan 2013 12:58:52 +0900 (JST) Received: from UTMC1122.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id C780E5C3A; Tue, 22 Jan 2013 12:58:45 +0900 (JST) Received: from LTMC1005.kddi.com (unknown [10.5.16.216]) by UTMC1122.kddi.com (Postfix) with ESMTP id ACC4D5C39; Tue, 22 Jan 2013 12:58:45 +0900 (JST) Received: from LTMC1005.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id r0M3wjfc032241; Tue, 22 Jan 2013 12:58:45 +0900 Received: from LTMC1005.kddi.com.mid_14249889 (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id r0M3miGZ025363; Tue, 22 Jan 2013 12:48:44 +0900 Received: from KDDI0805PC0145 ([10.211.58.34] [10.211.58.34]) by post-zip.kddi.com with ESMTPA; Tue, 22 Jan 2013 12:48:44 +0900 From: "Tomohiro Otani" To: "'Lou Berger'" References: <20130115012259.6D474B1E004@rfc-editor.org> <50F58537.3050302@labn.net> In-Reply-To: <50F58537.3050302@labn.net> Date: Tue, 22 Jan 2013 12:48:43 +0900 Message-Id: <002d01cdf853$5ffdb950$1ff92bf0$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHQsGiTFGBFeTo4qemahC5iSGQ4sAMKuWU9mDbuUBA= Content-Language: ja X-SA-MID: 14249889 X-WAuditID: 1301221258450000609348 Cc: ccamp@ietf.org Subject: Re: [CCAMP] RFC 6825 on Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 03:58:57 -0000 Lou and all, Thank you very much for the patience and the support to proceed this work. When we started, we indeed could not imagine it took so long time. Honestly speaking, I am quite happy to complete this finally. With best regards, Tomo -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Wednesday, January 16, 2013 1:35 AM Cc: ccamp@ietf.org Subject: Re: [CCAMP] RFC 6825 on Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS Authors, Congratulations on getting this documented completed! I believe it is the longest tenured item that CCAMP has seen. Lou On 1/14/2013 8:22 PM, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6825 > > Title: Traffic Engineering Database Management Information > Base in Support of MPLS-TE/GMPLS > Author: M. Miyazawa, T. Otani, > K. Kumaki, T. Nadeau > Status: Standards Track > Stream: IETF > Date: January 2013 > Mailbox: ma-miyazawa@kddilabs.jp, > Tm-otani@kddi.com, > ke-kumaki@kddi.com, > tnadeau@juniper.net > Pages: 40 > Characters: 72765 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ccamp-gmpls-ted-mib-15.txt > > URL: http://www.rfc-editor.org/rfc/rfc6825.txt > > This memo defines the Management Information Base (MIB) objects for > managing the Traffic Engineering Database (TED) information with > extensions in support of the Multiprotocol Label Switching (MPLS) with > Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use > with network management protocols. [STANDARDS-TRACK] > > This document is a product of the Common Control and Measurement Plane Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions for improvements. Please refer to the current edition of > the Internet Official Protocol Standards (STD 1) for the > standardization state and status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. > Unless specifically noted otherwise on the RFC itself, all RFCs are > for unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From huawei.danli@huawei.com Mon Jan 21 23:22:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4994D21F8853; Mon, 21 Jan 2013 23:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=-3.168, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 vr01HkJ9rj0Y; Mon, 21 Jan 2013 23:22:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 07A7A21F8889; Mon, 21 Jan 2013 23:22:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOZ59716; Tue, 22 Jan 2013 07:21:22 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 22 Jan 2013 07:21:10 +0000 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 22 Jan 2013 15:21:20 +0800 Received: from szxeml555-mbx.china.huawei.com ([169.254.1.229]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Tue, 22 Jan 2013 15:21:14 +0800 From: "Lidan (Dan)" To: Julien Meuric , "rtg-ads@tools.ietf.org" Thread-Topic: [CCAMP] RtgDir review: draft-ietf-ccamp-lmp-behavior-negotiation-09 Thread-Index: AQHN9Z1YfEeXA56mpE2FuDMjaUncdphU9SHQ Date: Tue, 22 Jan 2013 07:21:13 +0000 Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A3884F3F1@szxeml555-mbx.china.huawei.com> References: <50F97FAC.3010903@orange.com> In-Reply-To: <50F97FAC.3010903@orange.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.73.151] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-ccamp-lmp-behavior-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "ccamp@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYt?= =?gb2312?b?Y2NhbXAtbG1wLWJlaGF2aW9yLW5lZ290aWF0aW9uLTA5?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 07:22:57 -0000 SnVsaWVuLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcsIHdlIHdpbGwgdXBkYXRlIHRoZSBkcmFm dCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy4gDQoNCk9uZSBjb21tZW50IG5lZWRzIHlvdXIg Y2xhcmlmaWNhdGlvbjoNCi0gcy9mdW5jdGlvbnMgZGVmaW5lZCBpbiB0aGF0IGRvY3VtZW50L2Z1 bmN0aW9ucyBzcGVjaWZpZWQgaW4gdGhhdCB2ZXJ5IGRvY3VtZW50LyAgW3JlcGV0aXRpb24gb2Yg ImRlZmluZWQiXQ0KRm9yIGFkZGluZyAidmVyeSIsIGlzIGl0IGEgdHlwbz8NCg0KRm9yIHRoZSBy ZWZlcmVuY2UgW0xNUC1URVNUXSwgd2Ugd2lsbCBjaGVjayB3aXRoIHRoZSBhdXRob3JzIG9mIGRy YWZ0LWNlY2N6aGFuZy1jY2FtcC1nbXBscy1nNzA5djMtbG1wLCB0byBzZWUgd2hhdCdzIHRoZWly IGludGVudGlvbi4NCg0KVGhhbmsgeW91IGFnYWluIQ0KDQpEYW4NCg0KLS0tLS3Tyrz+1K28/i0t LS0tDQq3orz+yMs6IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIEp1bGllbiBNZXVyaWMNCreiy83KsbzkOiAyMDEzxOox1MIxOcjVIDE6 MDANCsrVvP7IyzogcnRnLWFkc0B0b29scy5pZXRmLm9yZw0Ks63LzTogZHJhZnQtaWV0Zi1jY2Ft cC1sbXAtYmVoYXZpb3ItbmVnb3RpYXRpb24uYWxsQHRvb2xzLmlldGYub3JnOyBydGctZGlyQGll dGYub3JnOyBjY2FtcEBpZXRmLm9yZw0K1vfM4jogW0NDQU1QXSBSdGdEaXIgcmV2aWV3OiBkcmFm dC1pZXRmLWNjYW1wLWxtcC1iZWhhdmlvci1uZWdvdGlhdGlvbi0wOQ0KDQpIZWxsbywNCg0KSSBo YXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9y IHRoaXMgZHJhZnQuIA0KVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFs bCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCANCmRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3Vn aCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcuIFRoZSBwdXJwb3NlIA0Kb2YgdGhlIHJl dmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9y ZSANCmluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2Vl IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9yYXRlL3JvdXRpbmcuaHRtbA0KDQpB bHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBS b3V0aW5nIEFEcywgaXQgDQp3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0 aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgDQpMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5 b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCANCmRpc2N1c3Np b24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1jY2Ft cC1sbXAtYmVoYXZpb3ItbmVnb3RpYXRpb24tMDkNClJldmlld2VyOiBKdWxpZW4gTWV1cmljDQpS ZXZpZXcgRGF0ZTogMTggSmFudWFyeSAyMDEzDQpJRVRGIExDIEVuZCBEYXRlOiAyMSBKYW51YXJ5 IDIwMTMNCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoNCipTdW1tYXJ5OioNClRo aXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBu aXRzIHRoYXQgDQpzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBpdC4NCg0KKkNvbW1lbnRz OioNClRoaXMgZG9jdW1lbnQgaXMgY2xlYXJseSB3cml0dGVuIGFuZCBlYXN5IHRvIHVuZGVyc3Rh bmQuIFRoZSBkZWZpbmVkIA0KbWVjaGFuaXNtIGlzIHNpbXBsZSBhbmQgd2VsbCBzcGVjaWZpZWQu DQoNCipOaXRzOioNCkFic3RyYWN0DQotSW5zdGVhZCBvZiAiR01QTFMgbmV0d29ya3MiLCAiR01Q TFMtY29udHJvbGxlZCBuZXR3b3JrcyIgcmVhZHMgbW9yZSANCmFjY3VyYXRlIHRvIG1lLiBJdCB3 b3VsZCBhbHNvIGFsaWduIG9uIHRoZSBwaHJhc2UgdXNlZCBpbiB0aGUgDQppbnRyb2R1Y3Rpb24u IFRoZSByZXN1bHRpbmcgIkdlbmVyYWxpemVkIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5n IA0KKEdNUExTKS1jb250cm9sbGVkIG5ldHdvcmtzIiBtYXkgYmUgY2hlY2tlZCB3aXRoIHRoZSBS RkMgRWRpdG9yLg0KDQpJbnRyb2R1Y3Rpb24NCi0gcy9MTVAgbm9kZS9MTVAtY2FwYWJsZSBub2Rl Lw0KLSBzL2Z1bmN0aW9ucyBkZWZpbmVkIGluIHRoYXQgZG9jdW1lbnQvZnVuY3Rpb25zIHNwZWNp ZmllZCBpbiB0aGF0IHZlcnkgDQpkb2N1bWVudC8gIFtyZXBldGl0aW9uIG9mICJkZWZpbmVkIl0N Ci0gcy90aGUgbWVzc2FnZSB0eXBlcyBmcm9tL3RoZSB0eXBlcyBmcm9tLyAgW3JlcGV0aXRpb24g b2YgIm1lc3NhZ2UiXQ0KDQpTZWN0aW9uIDIuMg0KLSBzL01BWSBpbmNsdWRlLCBIZWxsb0NvbmZp Zy9NQVkgaW5jbHVkZSBIZWxsb0NvbmZpZy8NCg0KU2VjdGlvbiAzLjENCi0gcy9udW1iZXIgb2Yg TUJaIGJpdHMgZmllbGQvbnVtYmVyIG9mIGJpdHMgaW4gTUJaIGZpZWxkLw0KDQpTZWN0aW9uIDQN Ci0gcy9bUkZDNDIwMl0gZGVmaW5lZC9bUkZDNDIwMl0tZGVmaW5lZC8NCg0KU2VjdGlvbiA5LjIN Ci0gSSB0ZW5kIHRvIHRoaW5rIHRoYXQgW0xNUCBURVNUXSBzaG91bGQgbm93IHJlZmVyZW5jZSAN CmRyYWZ0LWNlY2N6aGFuZy1jY2FtcC1nbXBscy1nNzA5djMtbG1wDQoNCg0KRW5qb3kgdGhlIHdl ZWstZW5kLA0KDQpKdWxpZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== From julien.meuric@orange.com Tue Jan 22 01:08:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6533621F8526; Tue, 22 Jan 2013 01:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.797 X-Spam-Level: X-Spam-Status: No, score=-5.797 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 GEpyT3-R2jG7; Tue, 22 Jan 2013 01:08:09 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5B321F84D3; Tue, 22 Jan 2013 01:08:09 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 70BB81074003; Tue, 22 Jan 2013 10:12:57 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 658561074001; Tue, 22 Jan 2013 10:12:57 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jan 2013 10:08:07 +0100 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jan 2013 10:08:06 +0100 Message-ID: <50FE56F5.8040806@orange.com> Date: Tue, 22 Jan 2013 10:08:05 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Lidan (Dan)" References: <50F97FAC.3010903@orange.com> <92A1F6CF27D54D4DA5364E59D892A02A3884F3F1@szxeml555-mbx.china.huawei.com> In-Reply-To: <92A1F6CF27D54D4DA5364E59D892A02A3884F3F1@szxeml555-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Jan 2013 09:08:06.0150 (UTC) FILETIME=[FD850260:01CDF87F] Cc: "draft-ietf-ccamp-lmp-behavior-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "ccamp@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [CCAMP] =?utf-8?b?562U5aSNOiAgUnRnRGlyIHJldmlldzogZHJhZnQtaWV0?= =?utf-8?q?f-ccamp-lmp-behavior-negotiation-09?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 09:08:10 -0000 Hi Dan. You're welcome. I've added "very" on purpose, to emphasize what document the sentence was referring to (i.e. the RFC mentioned at the beginning of that very same sentence, not at the end of the previous one). It was just a suggestion, it isn't mandatory to keep it if you feel it's more confusing than clarifying. You may also check with a native English speaker (e.g. the RFC Editor), who I'm not. Regards, Julien Le 22/01/2013 08:21, Lidan (Dan) a 茅crit : > Julien, > > Thanks for the review, we will update the draft according to your comments. > > One comment needs your clarification: > - s/functions defined in that document/functions specified in that very document/ [repetition of "defined"] > For adding "very", is it a typo? > > For the reference [LMP-TEST], we will check with the authors of draft-cecczhang-ccamp-gmpls-g709v3-lmp, to see what's their intention. > > Thank you again! > > Dan > > -----閭欢鍘熶欢----- > 鍙戜欢浜: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 浠ｈ〃 Julien Meuric > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-ccamp-lmp-behavior-negotiation-09 > Reviewer: Julien Meuric > Review Date: 18 January 2013 > IETF LC End Date: 21 January 2013 > Intended Status: Standards Track > > *Summary:* > This document is basically ready for publication, but has nits that > should be considered prior to it. > > *Comments:* > This document is clearly written and easy to understand. The defined > mechanism is simple and well specified. > > *Nits:* > Abstract > -Instead of "GMPLS networks", "GMPLS-controlled networks" reads more > accurate to me. It would also align on the phrase used in the > introduction. The resulting "Generalized Multiprotocol Label Switching > (GMPLS)-controlled networks" may be checked with the RFC Editor. > > Introduction > - s/LMP node/LMP-capable node/ > - s/functions defined in that document/functions specified in that very > document/ [repetition of "defined"] > - s/the message types from/the types from/ [repetition of "message"] > > Section 2.2 > - s/MAY include, HelloConfig/MAY include HelloConfig/ > > Section 3.1 > - s/number of MBZ bits field/number of bits in MBZ field/ > > Section 4 > - s/[RFC4202] defined/[RFC4202]-defined/ > > Section 9.2 > - I tend to think that [LMP TEST] should now reference > draft-cecczhang-ccamp-gmpls-g709v3-lmp > > > Enjoy the week-end, > > Julien > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Tue Jan 22 06:25:48 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAB121F8937 for ; Tue, 22 Jan 2013 06:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.006 X-Spam-Level: X-Spam-Status: No, score=-101.006 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, 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 gepZnxtMOvfQ for ; Tue, 22 Jan 2013 06:25:47 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 92D7321F87FB for ; Tue, 22 Jan 2013 06:25:47 -0800 (PST) Received: (qmail 13441 invoked by uid 0); 22 Jan 2013 14:25:24 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 22 Jan 2013 14:25:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=UrxBi/j/0MewN3J9XQLWguN2GzhRnxkI4Wd42wYbJRs=; b=OKOVZisOgxDJH8I7WPw9PVjBjdxVCwtyk5nbdACsjR6FddiQkwhFenusj9RtqeHUCC777OgAwxSnVvgdTtbeD9vTZBEOp/BB2H0tBgs157QGMTrg6nRF77ncq0dGU07l; Received: from box313.bluehost.com ([69.89.31.113]:46948 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Txemy-0003aV-8d; Tue, 22 Jan 2013 07:25:24 -0700 Message-ID: <50FEA15E.6040801@labn.net> Date: Tue, 22 Jan 2013 09:25:34 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Julien Meuric References: <50F97FAC.3010903@orange.com> <92A1F6CF27D54D4DA5364E59D892A02A3884F3F1@szxeml555-mbx.china.huawei.com> <50FE56F5.8040806@orange.com> In-Reply-To: <50FE56F5.8040806@orange.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-lmp-behavior-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "ccamp@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [CCAMP] =?utf-8?b?562U5aSNOiAgUnRnRGlyIHJldmlldzogZHJhZnQtaWV0?= =?utf-8?q?f-ccamp-lmp-behavior-negotiation-09?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:25:48 -0000 Julien/Dan, Some comments below (as coauthor). On 1/22/2013 4:08 AM, Julien Meuric wrote: > Hi Dan. > > You're welcome. > > I've added "very" on purpose, to emphasize what document the sentence > was referring to (i.e. the RFC mentioned at the beginning of that very > same sentence, not at the end of the previous one). It was just a > suggestion, it isn't mandatory to keep it if you feel it's more > confusing than clarifying. You may also check with a native English > speaker (e.g. the RFC Editor), who I'm not. > IMO the use of "very" is 100% stylistic. I don't think it causes any harm or provides any substantive benefit. It also doesn't matter to me if it's included or not... > Regards, > > Julien > > > Le 22/01/2013 08:21, Lidan (Dan) a 茅crit : >> Julien, >> >> Thanks for the review, we will update the draft according to your comments. >> >> One comment needs your clarification: >> - s/functions defined in that document/functions specified in that very document/ [repetition of "defined"] >> For adding "very", is it a typo? >> >> For the reference [LMP-TEST], we will check with the authors of draft-cecczhang-ccamp-gmpls-g709v3-lmp, to see what's their intention. Rather than reference an individual draft, my suggestion is to just drop the whole sentence. It doesn't really add much in any case. The other comments all look good to me. Much thanks! Lou >> >> Thank you again! >> >> Dan >> >> -----閭欢鍘熶欢----- >> 鍙戜欢浜: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 浠ｈ〃 Julien Meuric >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review. The purpose >> of the review is to provide assistance to the Routing ADs. For more >> information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF >> Last Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >> >> Document: draft-ietf-ccamp-lmp-behavior-negotiation-09 >> Reviewer: Julien Meuric >> Review Date: 18 January 2013 >> IETF LC End Date: 21 January 2013 >> Intended Status: Standards Track >> >> *Summary:* >> This document is basically ready for publication, but has nits that >> should be considered prior to it. >> >> *Comments:* >> This document is clearly written and easy to understand. The defined >> mechanism is simple and well specified. >> >> *Nits:* >> Abstract >> -Instead of "GMPLS networks", "GMPLS-controlled networks" reads more >> accurate to me. It would also align on the phrase used in the >> introduction. The resulting "Generalized Multiprotocol Label Switching >> (GMPLS)-controlled networks" may be checked with the RFC Editor. >> >> Introduction >> - s/LMP node/LMP-capable node/ >> - s/functions defined in that document/functions specified in that very >> document/ [repetition of "defined"] >> - s/the message types from/the types from/ [repetition of "message"] >> >> Section 2.2 >> - s/MAY include, HelloConfig/MAY include HelloConfig/ >> >> Section 3.1 >> - s/number of MBZ bits field/number of bits in MBZ field/ >> >> Section 4 >> - s/[RFC4202] defined/[RFC4202]-defined/ >> >> Section 9.2 >> - I tend to think that [LMP TEST] should now reference >> draft-cecczhang-ccamp-gmpls-g709v3-lmp >> >> >> Enjoy the week-end, >> >> Julien >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > From IBryskin@advaoptical.com Tue Jan 22 07:05:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CADB21F897A for ; Tue, 22 Jan 2013 07:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6] 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 I+eHyhNMDN8j for ; Tue, 22 Jan 2013 07:05:36 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 124CA21F8984 for ; Tue, 22 Jan 2013 07:05:35 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0MF5TM8004647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jan 2013 16:05:29 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Tue, 22 Jan 2013 16:05:29 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Tue, 22 Jan 2013 10:05:27 -0500 From: Igor Bryskin To: Lou Berger , Daniele Ceccarelli Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBzClcAAJEUjQAAD8STgAAXoD7A Date: Tue, 22 Jan 2013 15:05:24 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> In-Reply-To: <50FDBD5B.6030307@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-22_06:2013-01-22, 2013-01-22, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:05:38 -0000 Lou and Daniele, Please, see my comments in-line, Cheers, Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Monday, January 21, 2013 5:13 PM To: Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Thanks Daniele, See below. On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: > Hi Lou, >=20 > Please find comments in line >=20 > BR > Daniele >=20 >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: venerd=EC 18 gennaio 2013 18.27 >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Daniele, >> Very nice summary. Just catching up, so sorry for the >> (2 day) late response. >> >> I really like how the terminology has evolved and appreciate the=20 >> summary! >> >> I have a few detail comments, but before I go there I'd like to cover=20 >> one more open issue that I think will have some >> (minor) ripple effects on the details. >> >> I think there's still the general issue of terminology to use when=20 >> referring to the entity that "uses an overlay" and the entity that=20 >> "instantiates the overlay". In your mail and in discussion we have: >> >> - client (service)/OC/CN/customer >> >> and >> >> - server(or service)/OE/EN/provider >> >> I think we had discussed, and possibly agreed on, using VPN=20 >> terminology which would have us use the latter options, i.e., >> (overlay) customer/provider (edge). This would mean eliminating any=20 >> references to client/server in the *generic >> overlay* definitions. Of course these terms may reemerge in other=20 >> contexts as they have before, e.g., rfc6215. >=20 > Yes, i think we all agreed. If there are still terms different from=20 > customer/provider in the text it's because i missed them during the=20 > replacing. >=20 Great! Glad I didn't miss something over the holidays! IB>> I personally have no problems with the VPN terminology. However, IMO t= he terminology should be aligned with the RFC 4208 and George's drafts. One= cannot use different terminology within the same framework, right? Further= more, both RFC4208 and ONTs are not necessarily about VPNs. The most import= ant goal is to provide a solution for inter-domain horizontal integration b= etween networks with possibly different switching technologies and independ= ent addressing within the overlay model.=20 >> >> I like this approach as it is aligned with the much of IETF work on=20 >> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). =20 >> Importantly, RFC 4847 even has quite a few concepts that can be=20 >> directly leveraged in this discussion. >> >> I'd even go further and say that we should base the definitions and=20 >> resulting framework on RFC 4847. For example, the definitions below=20 >> could start with something along the lines: >> >> The overlay service model, at a high level, follows Section >> 7. of RFC 4847 as represented by: >> >> >> +--------------------+ >> : | | : >> : | | : >> +----+ : +----+ +----+ : +----+ >> | CE |---:---| PE | | PE |---:---| CE | >> +----+ : +----+ +----+ : +----+ >> : | | : >> : | | : >> : +--------------------+ : >> : | | : >> : |<-Provider network->| : >> Customer Customer >> interface interface >> >> Figure 7.2: Overlay Service Model >> >> In this model, the overlay is instantiated by an overlay >> "provider" and its provider edge (PE) nodes , and is used by >> the overlay "customer" which is connected to the provider via >> customer interfaces attached to customer edge (CE) nodes. >> >> ... >> >> The definition below would need to be tweaked slightly, notably to=20 >> remove any references to client and server. The resulting framework=20 >> can also refer back to RFC 4847 as needed. >> >> See below for some additional comments. >> >> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>> Dear overlayers, >>> >>> Please find below a new version (v2) of the framework summary=20 >>> reflecting the latest discussions. Again i hope i've >> captured all the >>> comments around, sorry if anything is missing, in case just let me=20 >>> know what i missed. >>> >>> BR >>> Daniele >>> >>> >>> + Disclaimer: >>> 1. Packet opto integration is often considered but the work can be=20 >>> extented to any type of SC. Eg. TDM over LSC. >>> >>> + Terminology: >>> 1. Virtual Link: A virtual link is a potential path between two=20 >>> virtual or real network elements in a provider layer network >> that is >>> maintained/controlled in and by the provider domain control >> plane (and >>> as such cannot transport any traffic/data and protected from being >>> de-provisioned) and which can be instantiated in the data plane (and=20 >>> then can carry/transport/forward traffic/data) preserving previously=20 >>> advertised attributes such as fate sharing information. >>> >> >> You say "potential path". I this this should read "potential or=20 >> instantiated path". >> >=20 > Maybe we need to define also what "potential" stands for? At least two=20 > cases come to my mind (which might be included under the "potential"=20 > umbrella): >=20 > 1. resources reserved via signaling but not instantiated Sure. Sounds like a RFC6001 soft FA. > 2. resources not even signaled. In presence of a centralized entity=20 > managing the network (sort of PCE plus something) there is no need to=20 > reserve resources via signaling as the central entity is the only=20 > thing that can reserve or allocate resources. I'm thinking to an=20 > opening towards the integration with the SDN world. >=20 Sure. Sounds like a Virtual TE link (per RFC6001, 5212). IB>> Potential path can be defined as a feasible/provisionable path for th= e server layer trail supporting an advertised VL, which has attributes cons= istent with the ones advertised for the Virtual Link (noticeably, bandwidth= , SRLGs, etc.) and is guaranteed to be available at the moment of the set-u= p of a client LSP that has selected the VL in its path across the provider = domain. > Just loud thinking, does it make sense? >=20 >>From my perspective, I think a node in the overlay really shouldn't >> *directly* distinguish between the two -- now one may have a =20 >>different metric/SRLG/weight/etc, but these are abstracted =20 >>representations of the tradeoffs between use of the two, that can be=20 >>provided by the underlying provider network, rather than a direct=20 >>indication. IB>> It is beneficial from the client (ONT user) path computation point of = view to know whether the advertised VL is committed (the data plane is prov= isioned) or not. Selecting uncommitted VL means: a) Higher probability of a client LSP setup failure; b) Longer client LSP setup time; c) Probability of effectively removing other VLs from the ONT (those that s= hare MELGs with the VL in question) >> >>> 2. Virtual Node: Virtual node is a collection of zero or more=20 >>> provider network domain nodes that are collectively >> represented to the >>> clients as a single node that exists in the customer layer >> network and >>> is capable of terminating of access, inter-domain and virtual links. >>> >> >> I'm a little uncomfortable with the linkage of real nodes to virtual=20 >> nodes. I think VN is a purely abstract concept that may be=20 >> instantiated using parts/whole/multiple/logical/real/etc nodes. >=20 IB>> Agree completely > Makes sense. What this definition adds to the one in RFC4847 is=20 > basically the fact that also parts of a node can be considered. What=20 > saying that it can be a real node i meant 1:1 correspondance between a=20 > real and a virtual node. Your definition covers that case also, that's=20 > fine. >=20 >> >> How about something like: >> Virtual Node: A virtual node is a representation of a collection of=20 >> provider resources that are interconnected via virtual (and customer)=20 >> links. A virtual node may be collection of zero or more, including=20 >> portions of, provider nodes that are collectively represented to the=20 >> customer as a single node which is available in an overlay network. >=20 > Works for me. >=20 Great. BTW I don't think 4847 precluded a single physical node being repre= sented as multiple virtual nodes, but it doesn't hurt to make it explicit. >> >>> 3. Virtual Topology: Virtual topology is a collection of one or more=20 >>> virtual or real provider network domain nodes that exist in the=20 >>> customer layer network and are interconnected via 0 or more virtual=20 >>> links. >> >> How about: >> Virtual Topology: A virtual topology is the collection of virtual=20 >> links and nodes advertised by a provider to a customer. The virtual=20 >> topology includes resources that are advertised as reachable within=20 >> an overlay network. >> >> Do you mean to imply/allow for a VN which has no links? >=20 > The case of "interconnected via 0 virtual links" implies the whole=20 > domain seen as a single node. >=20 Ahh, fair enough. >> >>> 4. Overlay topology: is a superset of virtual topologies >> provided by >>> each of provider network domains, access and inter-domain links. >>> >> >> Doesn't it also include any topology information advertised by the=20 >> customer/CE as well? IB>> Yes, it does: the ends of access links terminated by the clients along= with the custom NEs IDs >=20 > Possibly. Do you mean advertised by the CE in the customer domain, right? >=20 That's possible too, but I was thinking more of advertised by CE (customer) to PE (provider). >> >>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It=20 >>> can support any of the SCs supported by the GMPLS. >>> >> >> If we adopt RFC 4847 terminology it should be "customer interface". >> Also, I suspect you mean PE and CE. >=20 > Mmm, yes but what if we want to manage it as a link? i.e. All=20 > TE-parameters that a link supports. Is it enough to call it interface=20 > only? >=20 sure. Per 4847, I'd say that "customer interface" is the connection betwee= n CE/PE while [virtual] TE links are what is advertised/represented in rout= ing. >> >>> 6. CE (customer Edge): Something like the CN in RFC4208 >> teminology but >>> (i) receiving virtual topology from the provider network and=20 >>> requesting the set up of one of them or (ii) requesting the=20 >>> computation and establishment of a path accordingly to given=20 >>> constraints in the provider network and receiving the parameters=20 >>> characterizing such path. (ii) =3D=3D UNI. >>> >> >> humm, I'm inclined to stay away from UNI for the moment. I also=20 >> suggest that we look to 4874 and even 4364 rather than 4208... >=20 > Ok, we can refer to those RFC for what concerns terminology, but at=20 > the end of the day we must put the UNI under this framework. In the=20 > new terminology the UNI is a particular type of customer interface. >=20 Fair enough. But it is a form on an overlay "customer interface" not the d= efinitive form. >> >>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to=20 >>> deal with (i) and (ii) above. >>> >> >> same comment WRT RFCs. >> >>> 8. PE-CE interface (former ONI) : Interface allowing for >> signaling and >>> routing messages exchange between customer overlay and provider=20 >>> network. Routing information consists on virtual topology=20 >>> advertisement. When there is no routing adjacency across the >> interface >>> it is equivalent to the GMPLS UNI defined in 4208. >>> Signaling messages are compliant with RFC4208. Information >> related to >>> path carachteristics, e.g. TE-metrics, collected SRLG, path >> delay etc, >>> either passed from CE to PE via signaling after the LSP >> establishment >>> in the core network or from CE to PE to be used as path computation=20 >>> constraints, fall under the definition of signaling info and not=20 >>> routing info). >>> >> >> >>> 9. CE-CE (former O-NNI): Interface on the links between different=20 >>> provider networks in the overlay model environment. Same features of=20 >>> the CE-PE apply to this interface. >>> >> >> you mean, PE-PE, right? >=20 > You're not the first one that makes me notice i'm probably affected by=20 > dyslexia :-) >=20 no problem, happens to the best of us! >> >>> + Statements 1. In the context of overlay model we are aiming to >>> build an overlay topology for the customer network domains >>> >>> 2. The overlay topology is comprised of: >>> a) access links (links connecting client NEs to the >> provider network domains). >>> They can be PSC or LSC. >>> b) inter-domain links (links interconnecting server >> network domains) >>> c) virtual topology provided by the provider network domains.=20 >>> Virtual Links >>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of=20 >>> + parameters >>> e.g. SRLG, optical impairments, delay etc for each entry) describing=20 >>> connectivity between access links and virtual links. >>> >>> 3. In the context of overlay model we manage hierarchy of overlay=20 >>> topologies with overlay/underlay relationships >>> >>> 4. In the context of overlay model multi-layering and inter-layer=20 >>> relationships are peripheral at best, it is all about horizontal=20 >>> network integration >>> >>> 5. The overlay model assumes one CP instance for the >> customer network >>> and a separate instance for the provider network and in the CE-PE=20 >>> interface case the provider network also surreptitiously >> participates >>> in the customer network by injecting virtual topology >> information into >>> it. >>> >> >> We should ensure we're allowing for some of the existing/augmented=20 >> models that permit the transport of overlay information within the=20 >> provider's CP, e.g., rfc4364, 5195 and 5252. >=20 > I'd say they should be already covered, but will double check >=20 great. >> >>> 6. L1VPN (and LxVPN) in general is a type of service >> provided over the >>> CE-PE interface (it falls under the UNI case as no routing adjacency=20 >>> is in place between CE and PE). >>> >>> >>> + Advertisement models (to be detailed in dedicated >>> + document/documents) >>> The CE-PE interface in the overlay model context foresees >> two types of >>> advertisement models.(names still to be agreed) >>> >>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >> augmented by >>> a number of actived draft (references to various drafts to >> be added).=20 >>> The Augmented UNI is a particular type of CE-PE interface where only=20 >>> signaling messages are exchanged between CE and PE. >>> Messages from CE to PE can include a set of parameters to be used by=20 >>> the PE as path computation constraints when computing a path in the=20 >>> provider domain network, while messages from PE to CE can include a=20 >>> set of parameters qualifying the LSP being established, like for=20 >>> example SRLG, delay, loss etc. >>> >> >> again, we can leverage 4874 terminology if we so choose, i.e., "basic=20 >> mode" and "enhanced mode" UNI|NNI >=20 > Don would be happy about that :-). I'd say yes. The goal was to cover=20 > the L1VPN work (enhanced mode), all the drafts-ali recently polled=20 > for wg adoption (basic mode?) and the actual ENNI (enhanced mode). > Is my mapping in brackets correct? >=20 Not sure f I'd break it down they way you are. I'd say basic mode is close= r to the typical UNI and enhance mode is UNI+routing or perhaps even an ENN= I. >=20 >> >>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >>> called with the general CE-PE interface term?) allowing the=20 >>> establishment of signaling and routing adjacency between CE and PE. >>> Routing info passed from PE to CE comprise overlay topology=20 >>> information including (but not limited to) virtual links, >> connectivity >>> matrices and access links with parameters qualifying each of them in=20 >>> terms of e.g. SRLG, loss, delay etc. Signaling information and=20 >>> procedures are compliant with RFC4208. >>> >> >> so this is just and 4874 "enhanced mode" interface, right. >=20 > Good question: the enhanced mode supports signaling and routing, so=20 > i'd say yes, but reading section 7.3 it talks about "limited exchange=20 > of information between the control planes. >=20 > "permits limited exchange of > information between the control planes of the provider and the > customer to help such functions as discovery of customer network > routing information (i.e., reachability or TE information in remote > customer sites), or parameters of the part of the provider's network > dedicated to the customer." >=20 > Would you say this includes what we want? (i.e. Virtual links, virtual=20 > nodes, connectivity matrices, SRLG, delay, loss, etc) If yes we're=20 > done, otherwise an option could be the denition of a third VPN service=20 > model. >=20 humm, need to think about this. Perhaps the best thing is to document the = two different cases and then decide if we have something new or (two) more detailed forms of something old. >> >>> + Open issues/questions >>> 1. PCE-PCEP - do we need to include considerations about PCE >> and PCEP >>> into the overlay framework context? >>> >>> 2. BGP-LS needs to be considered >>> 3. Should potentials be included? E.g. I2RS? >>> 4. Virtual links: wouldn't a different definition of virtual links=20 >>> avoid the advertisement of connectivity matrices (this is out of the=20 >>> fwk scope but within the advertisement models one)? >>> >> >>> Take this example: >>> PE1-----CE1 CE2-----PE2 >>> CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>> CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >> >> I think you've reversed CE and PE here... >=20 > Yes, once again. >=20 > No comment on my foolish proposal? >=20 Which one? I liked your summary overall. Lou >=20 >> >> Much thanks! >> >> Lou >> (hatless...) >> >>> i.e. There are 2 VL connecting CE1 and CE2 that could be >> available for >>> PE1 and PE2 to set up an adjacency in the customer domain.=20 >> CE1 and/or >>> CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>> depending on the connectivity matrices of CE1 and CE2. Hence >> PEs need >>> to be aware of both VL and connectivity matrices. My point >> is: if CE1 >>> advertises to PE1 only the VL that his connectivity matrix allows to=20 >>> be connected to PE1 (e.g. VL1 only) and not all of them, it >> should be >>> possible to avoid the connectivity matrices advertisement. >>> >> >>> =20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> DANIELE CECCARELLI >>> System & Technology - PDU Optical & Metro >>> >>> Via E.Melen, 77 >>> Genova, Italy >>> Phone +390106002512 >>> Mobile +393346725750 >>> daniele.ceccarelli@ericsson.com >>> www.ericsson.com >>> >> >=20 >=20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Tue Jan 22 07:51:00 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FD821F8A41 for ; Tue, 22 Jan 2013 07:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.57 X-Spam-Level: X-Spam-Status: No, score=-100.57 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6, 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 riNpJDURVmtH for ; Tue, 22 Jan 2013 07:50:58 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 6572A21F8950 for ; Tue, 22 Jan 2013 07:50:56 -0800 (PST) Received: (qmail 18914 invoked by uid 0); 22 Jan 2013 15:50:35 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 22 Jan 2013 15:50:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=94vW0tLxIDywu8rni21LCqLqO3nYI+U/mOz/kDN4WFo=; b=FoRkP+AAuDU7jkBzZT9U5jR9i7Wq7I4s8+C6fZY6gnAy/lLGXgBY9SK0EdgdUUZRXaunYLHlgsKjzbJRuF55UzrJcCZVx+fmxy3xlza2KyJH7pejqtCbeETHaAeSSaEI; Received: from box313.bluehost.com ([69.89.31.113]:58040 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Txg7O-0003mg-PP; Tue, 22 Jan 2013 08:50:35 -0700 Message-ID: <50FEB554.6010907@labn.net> Date: Tue, 22 Jan 2013 10:50:44 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Igor Bryskin References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:51:00 -0000 Igor, see below. On 1/22/2013 10:05 AM, Igor Bryskin wrote: > Lou and Daniele, > Please, see my comments in-line, > > Cheers, > Igor > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Monday, January 21, 2013 5:13 PM > To: Daniele Ceccarelli > Cc: CCAMP > Subject: Re: [CCAMP] Overlay model framework v2 > > Thanks Daniele, See below. > > On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: >> Hi Lou, >> >> Please find comments in line >> >> BR >> Daniele >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: venerd 18 gennaio 2013 18.27 >>> To: Daniele Ceccarelli >>> Cc: CCAMP >>> Subject: Re: [CCAMP] Overlay model framework v2 >>> >>> Daniele, >>> Very nice summary. Just catching up, so sorry for the >>> (2 day) late response. >>> >>> I really like how the terminology has evolved and appreciate the >>> summary! >>> >>> I have a few detail comments, but before I go there I'd like to cover >>> one more open issue that I think will have some >>> (minor) ripple effects on the details. >>> >>> I think there's still the general issue of terminology to use when >>> referring to the entity that "uses an overlay" and the entity that >>> "instantiates the overlay". In your mail and in discussion we have: >>> >>> - client (service)/OC/CN/customer >>> >>> and >>> >>> - server(or service)/OE/EN/provider >>> >>> I think we had discussed, and possibly agreed on, using VPN >>> terminology which would have us use the latter options, i.e., >>> (overlay) customer/provider (edge). This would mean eliminating any >>> references to client/server in the *generic >>> overlay* definitions. Of course these terms may reemerge in other >>> contexts as they have before, e.g., rfc6215. >> >> Yes, i think we all agreed. If there are still terms different from >> customer/provider in the text it's because i missed them during the >> replacing. >> > > Great! Glad I didn't miss something over the holidays! > > IB>> I personally have no problems with the VPN terminology. However, > IMO the terminology should be aligned with the RFC 4208 and George's > drafts. My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped to encompass the broad spectrum of overlays that are/have been discussed. > One cannot use different terminology within the same > framework, right? Unfortunately we have no shortage of terminology defining (perhaps different flavors) of the same thing! > Furthermore, both RFC4208 and ONTs are not > necessarily about VPNs. While I certainly agree that not all overlays need be VPNs, it seems to me that our discussions are best aligned with that set of terminology, and that UNI/ENNI can be described within the CE/PE/VN/VL/VT constructs. Perhaps with some tweaking in some cases. > The most important goal is to provide a > solution for inter-domain horizontal integration between networks > with possibly different switching technologies and independent > addressing within the overlay model. > Sure. It's also possible that an overlay will use the same switching technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably less likely) the same address space (if a provider so chooses). >>> >>> I like this approach as it is aligned with the much of IETF work on >>> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). >>> Importantly, RFC 4847 even has quite a few concepts that can be >>> directly leveraged in this discussion. >>> >>> I'd even go further and say that we should base the definitions and >>> resulting framework on RFC 4847. For example, the definitions below >>> could start with something along the lines: >>> >>> The overlay service model, at a high level, follows Section >>> 7. of RFC 4847 as represented by: >>> >>> >>> +--------------------+ >>> : | | : >>> : | | : >>> +----+ : +----+ +----+ : +----+ >>> | CE |---:---| PE | | PE |---:---| CE | >>> +----+ : +----+ +----+ : +----+ >>> : | | : >>> : | | : >>> : +--------------------+ : >>> : | | : >>> : |<-Provider network->| : >>> Customer Customer >>> interface interface >>> >>> Figure 7.2: Overlay Service Model >>> >>> In this model, the overlay is instantiated by an overlay >>> "provider" and its provider edge (PE) nodes , and is used by >>> the overlay "customer" which is connected to the provider via >>> customer interfaces attached to customer edge (CE) nodes. >>> >>> ... >>> >>> The definition below would need to be tweaked slightly, notably to >>> remove any references to client and server. The resulting framework >>> can also refer back to RFC 4847 as needed. >>> >>> See below for some additional comments. >>> >>> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>>> Dear overlayers, >>>> >>>> Please find below a new version (v2) of the framework summary >>>> reflecting the latest discussions. Again i hope i've >>> captured all the >>>> comments around, sorry if anything is missing, in case just let me >>>> know what i missed. >>>> >>>> BR >>>> Daniele >>>> >>>> >>>> + Disclaimer: >>>> 1. Packet opto integration is often considered but the work can be >>>> extented to any type of SC. Eg. TDM over LSC. >>>> >>>> + Terminology: >>>> 1. Virtual Link: A virtual link is a potential path between two >>>> virtual or real network elements in a provider layer network >>> that is >>>> maintained/controlled in and by the provider domain control >>> plane (and >>>> as such cannot transport any traffic/data and protected from being >>>> de-provisioned) and which can be instantiated in the data plane (and >>>> then can carry/transport/forward traffic/data) preserving previously >>>> advertised attributes such as fate sharing information. >>>> >>> >>> You say "potential path". I this this should read "potential or >>> instantiated path". >>> >> >> Maybe we need to define also what "potential" stands for? At least two >> cases come to my mind (which might be included under the "potential" >> umbrella): >> >> 1. resources reserved via signaling but not instantiated > > Sure. Sounds like a RFC6001 soft FA. > >> 2. resources not even signaled. In presence of a centralized entity >> managing the network (sort of PCE plus something) there is no need to >> reserve resources via signaling as the central entity is the only >> thing that can reserve or allocate resources. I'm thinking to an >> opening towards the integration with the SDN world. >> > > Sure. Sounds like a Virtual TE link (per RFC6001, 5212). > IB>> Potential path can be defined as a feasible/provisionable path for the server layer trail supporting an advertised VL, which has attributes consistent with the ones advertised for the Virtual Link (noticeably, bandwidth, SRLGs, etc.) and is guaranteed to be available at the moment of the set-up of a client LSP that has selected the VL in its path across the provider domain. > >> Just loud thinking, does it make sense? >> >> >From my perspective, I think a node in the overlay really shouldn't >>> *directly* distinguish between the two -- now one may have a >>> different metric/SRLG/weight/etc, but these are abstracted >>> representations of the tradeoffs between use of the two, that can be >>> provided by the underlying provider network, rather than a direct >>> indication. > IB>> It is beneficial from the client (ONT user) path computation point IB>> of view to know whether the advertised VL is committed (the data IB>> plane is provisioned) or not. Selecting uncommitted VL means: > a) Higher probability of a client LSP setup failure; > b) Longer client LSP setup time; > c) Probability of effectively removing other VLs from the ONT (those that share MELGs with the VL in question) And I'm suggesting that this be advertised using generic constructs such as TE metric, SRLG, and even MELG, rather than adding yet another special case computation/optimization parameter. > >>> >>>> 2. Virtual Node: Virtual node is a collection of zero or more >>>> provider network domain nodes that are collectively >>> represented to the >>>> clients as a single node that exists in the customer layer >>> network and >>>> is capable of terminating of access, inter-domain and virtual links. >>>> >>> >>> I'm a little uncomfortable with the linkage of real nodes to virtual >>> nodes. I think VN is a purely abstract concept that may be >>> instantiated using parts/whole/multiple/logical/real/etc nodes. >> > > IB>> Agree completely > >> Makes sense. What this definition adds to the one in RFC4847 is >> basically the fact that also parts of a node can be considered. What >> saying that it can be a real node i meant 1:1 correspondance between a >> real and a virtual node. Your definition covers that case also, that's >> fine. >> >>> >>> How about something like: >>> Virtual Node: A virtual node is a representation of a collection of >>> provider resources that are interconnected via virtual (and customer) >>> links. A virtual node may be collection of zero or more, including >>> portions of, provider nodes that are collectively represented to the >>> customer as a single node which is available in an overlay network. >> >> Works for me. >> > > Great. BTW I don't think 4847 precluded a single physical node being represented as multiple virtual nodes, but it doesn't hurt to make it explicit. > >>> >>>> 3. Virtual Topology: Virtual topology is a collection of one or more >>>> virtual or real provider network domain nodes that exist in the >>>> customer layer network and are interconnected via 0 or more virtual >>>> links. >>> >>> How about: >>> Virtual Topology: A virtual topology is the collection of virtual >>> links and nodes advertised by a provider to a customer. The virtual >>> topology includes resources that are advertised as reachable within >>> an overlay network. >>> >>> Do you mean to imply/allow for a VN which has no links? >> >> The case of "interconnected via 0 virtual links" implies the whole >> domain seen as a single node. >> > > Ahh, fair enough. > >>> >>>> 4. Overlay topology: is a superset of virtual topologies >>> provided by >>>> each of provider network domains, access and inter-domain links. >>>> >>> >>> Doesn't it also include any topology information advertised by the >>> customer/CE as well? > > IB>> Yes, it does: the ends of access links terminated by the clients along with the custom NEs IDs > sounds like some agreement here. I think that was you final comment... Lou >> >> Possibly. Do you mean advertised by the CE in the customer domain, right? >> > > That's possible too, but I was thinking more of advertised by CE > (customer) to PE (provider). > >>> >>>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It >>>> can support any of the SCs supported by the GMPLS. >>>> >>> >>> If we adopt RFC 4847 terminology it should be "customer interface". >>> Also, I suspect you mean PE and CE. >> >> Mmm, yes but what if we want to manage it as a link? i.e. All >> TE-parameters that a link supports. Is it enough to call it interface >> only? >> > > sure. Per 4847, I'd say that "customer interface" is the connection between CE/PE while [virtual] TE links are what is advertised/represented in routing. > >>> >>>> 6. CE (customer Edge): Something like the CN in RFC4208 >>> teminology but >>>> (i) receiving virtual topology from the provider network and >>>> requesting the set up of one of them or (ii) requesting the >>>> computation and establishment of a path accordingly to given >>>> constraints in the provider network and receiving the parameters >>>> characterizing such path. (ii) == UNI. >>>> >>> >>> humm, I'm inclined to stay away from UNI for the moment. I also >>> suggest that we look to 4874 and even 4364 rather than 4208... >> >> Ok, we can refer to those RFC for what concerns terminology, but at >> the end of the day we must put the UNI under this framework. In the >> new terminology the UNI is a particular type of customer interface. >> > > Fair enough. But it is a form on an overlay "customer interface" not the definitive form. > >>> >>>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to >>>> deal with (i) and (ii) above. >>>> >>> >>> same comment WRT RFCs. >>> >>>> 8. PE-CE interface (former ONI) : Interface allowing for >>> signaling and >>>> routing messages exchange between customer overlay and provider >>>> network. Routing information consists on virtual topology >>>> advertisement. When there is no routing adjacency across the >>> interface >>>> it is equivalent to the GMPLS UNI defined in 4208. >>>> Signaling messages are compliant with RFC4208. Information >>> related to >>>> path carachteristics, e.g. TE-metrics, collected SRLG, path >>> delay etc, >>>> either passed from CE to PE via signaling after the LSP >>> establishment >>>> in the core network or from CE to PE to be used as path computation >>>> constraints, fall under the definition of signaling info and not >>>> routing info). >>>> >>> >>> >>>> 9. CE-CE (former O-NNI): Interface on the links between different >>>> provider networks in the overlay model environment. Same features of >>>> the CE-PE apply to this interface. >>>> >>> >>> you mean, PE-PE, right? >> >> You're not the first one that makes me notice i'm probably affected by >> dyslexia :-) >> > > no problem, happens to the best of us! > >>> >>>> + Statements 1. In the context of overlay model we are aiming to >>>> build an overlay topology for the customer network domains >>>> >>>> 2. The overlay topology is comprised of: >>>> a) access links (links connecting client NEs to the >>> provider network domains). >>>> They can be PSC or LSC. >>>> b) inter-domain links (links interconnecting server >>> network domains) >>>> c) virtual topology provided by the provider network domains. >>>> Virtual Links >>>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of >>>> + parameters >>>> e.g. SRLG, optical impairments, delay etc for each entry) describing >>>> connectivity between access links and virtual links. >>>> >>>> 3. In the context of overlay model we manage hierarchy of overlay >>>> topologies with overlay/underlay relationships >>>> >>>> 4. In the context of overlay model multi-layering and inter-layer >>>> relationships are peripheral at best, it is all about horizontal >>>> network integration >>>> >>>> 5. The overlay model assumes one CP instance for the >>> customer network >>>> and a separate instance for the provider network and in the CE-PE >>>> interface case the provider network also surreptitiously >>> participates >>>> in the customer network by injecting virtual topology >>> information into >>>> it. >>>> >>> >>> We should ensure we're allowing for some of the existing/augmented >>> models that permit the transport of overlay information within the >>> provider's CP, e.g., rfc4364, 5195 and 5252. >> >> I'd say they should be already covered, but will double check >> > > great. > >>> >>>> 6. L1VPN (and LxVPN) in general is a type of service >>> provided over the >>>> CE-PE interface (it falls under the UNI case as no routing adjacency >>>> is in place between CE and PE). >>>> >>>> >>>> + Advertisement models (to be detailed in dedicated >>>> + document/documents) >>>> The CE-PE interface in the overlay model context foresees >>> two types of >>>> advertisement models.(names still to be agreed) >>>> >>>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >>> augmented by >>>> a number of actived draft (references to various drafts to >>> be added). >>>> The Augmented UNI is a particular type of CE-PE interface where only >>>> signaling messages are exchanged between CE and PE. >>>> Messages from CE to PE can include a set of parameters to be used by >>>> the PE as path computation constraints when computing a path in the >>>> provider domain network, while messages from PE to CE can include a >>>> set of parameters qualifying the LSP being established, like for >>>> example SRLG, delay, loss etc. >>>> >>> >>> again, we can leverage 4874 terminology if we so choose, i.e., "basic >>> mode" and "enhanced mode" UNI|NNI >> >> Don would be happy about that :-). I'd say yes. The goal was to cover >> the L1VPN work (enhanced mode), all the drafts-ali recently polled >> for wg adoption (basic mode?) and the actual ENNI (enhanced mode). > >> Is my mapping in brackets correct? >> > > Not sure f I'd break it down they way you are. I'd say basic mode is closer to the typical UNI and enhance mode is UNI+routing or perhaps even an ENNI. > >> >>> >>>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >>>> called with the general CE-PE interface term?) allowing the >>>> establishment of signaling and routing adjacency between CE and PE. >>>> Routing info passed from PE to CE comprise overlay topology >>>> information including (but not limited to) virtual links, >>> connectivity >>>> matrices and access links with parameters qualifying each of them in >>>> terms of e.g. SRLG, loss, delay etc. Signaling information and >>>> procedures are compliant with RFC4208. >>>> >>> >>> so this is just and 4874 "enhanced mode" interface, right. >> >> Good question: the enhanced mode supports signaling and routing, so >> i'd say yes, but reading section 7.3 it talks about "limited exchange >> of information between the control planes. >> >> "permits limited exchange of >> information between the control planes of the provider and the >> customer to help such functions as discovery of customer network >> routing information (i.e., reachability or TE information in remote >> customer sites), or parameters of the part of the provider's network >> dedicated to the customer." >> >> Would you say this includes what we want? (i.e. Virtual links, virtual >> nodes, connectivity matrices, SRLG, delay, loss, etc) If yes we're >> done, otherwise an option could be the denition of a third VPN service >> model. >> > > humm, need to think about this. Perhaps the best thing is to document the two different cases and then decide if we have something new or > (two) more detailed forms of something old. > >>> >>>> + Open issues/questions >>>> 1. PCE-PCEP - do we need to include considerations about PCE >>> and PCEP >>>> into the overlay framework context? >>>> >>>> 2. BGP-LS needs to be considered >>>> 3. Should potentials be included? E.g. I2RS? >>>> 4. Virtual links: wouldn't a different definition of virtual links >>>> avoid the advertisement of connectivity matrices (this is out of the >>>> fwk scope but within the advertisement models one)? >>>> >>> >>>> Take this example: >>>> PE1-----CE1 CE2-----PE2 >>>> CE1======VL1======CE2 >>>> CE1======VL2======CE2 >>> >>> I think you've reversed CE and PE here... >> >> Yes, once again. >> >> No comment on my foolish proposal? >> > > Which one? I liked your summary overall. > > Lou > >> >>> >>> Much thanks! >>> >>> Lou >>> (hatless...) >>> >>>> i.e. There are 2 VL connecting CE1 and CE2 that could be >>> available for >>>> PE1 and PE2 to set up an adjacency in the customer domain. >>> CE1 and/or >>>> CE2 can be blocking nodes so VL1 and/or VL2 are available only >>>> depending on the connectivity matrices of CE1 and CE2. Hence >>> PEs need >>>> to be aware of both VL and connectivity matrices. My point >>> is: if CE1 >>>> advertises to PE1 only the VL that his connectivity matrix allows to >>>> be connected to PE1 (e.g. VL1 only) and not all of them, it >>> should be >>>> possible to avoid the connectivity matrices advertisement. >>>> >>> >>>> >>>> =================================== >>>> DANIELE CECCARELLI >>>> System & Technology - PDU Optical & Metro >>>> >>>> Via E.Melen, 77 >>>> Genova, Italy >>>> Phone +390106002512 >>>> Mobile +393346725750 >>>> daniele.ceccarelli@ericsson.com >>>> www.ericsson.com >>>> >>> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From IBryskin@advaoptical.com Tue Jan 22 08:09:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BB121F8992 for ; Tue, 22 Jan 2013 08:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6] 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 oGQo4DQYbgPV for ; Tue, 22 Jan 2013 08:09:43 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id CE17221F8951 for ; Tue, 22 Jan 2013 08:09:42 -0800 (PST) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0MG9cHJ028796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jan 2013 17:09:38 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.516.32; Tue, 22 Jan 2013 17:09:37 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Tue, 22 Jan 2013 11:09:36 -0500 From: Igor Bryskin To: Lou Berger Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBzClcAAJEUjQAAD8STgAAXoD7AAA1TKgAAChyl0A== Date: Tue, 22 Jan 2013 16:09:31 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> In-Reply-To: <50FEB554.6010907@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-22_07:2013-01-22, 2013-01-22, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:09:45 -0000 Hi Lou, You said: And I'm suggesting that this be advertised using generic constructs such as= TE metric, SRLG, and even MELG, rather than adding yet another special cas= e computation/optimization parameter. Agree, we are already doing this via MELG sub-TLV. This is because the sub-= TLV is new (no need to change the existing ones) and because MELG is peculi= ar to VL. Igor. -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, January 22, 2013 10:51 AM To: Igor Bryskin Cc: Daniele Ceccarelli; CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Igor, see below. On 1/22/2013 10:05 AM, Igor Bryskin wrote: > Lou and Daniele, > Please, see my comments in-line, >=20 > Cheers, > Igor >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=20 > Of Lou Berger > Sent: Monday, January 21, 2013 5:13 PM > To: Daniele Ceccarelli > Cc: CCAMP > Subject: Re: [CCAMP] Overlay model framework v2 >=20 > Thanks Daniele, See below. >=20 > On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: >> Hi Lou, >> >> Please find comments in line >> >> BR >> Daniele >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: venerd=EC 18 gennaio 2013 18.27 >>> To: Daniele Ceccarelli >>> Cc: CCAMP >>> Subject: Re: [CCAMP] Overlay model framework v2 >>> >>> Daniele, >>> Very nice summary. Just catching up, so sorry for the >>> (2 day) late response. >>> >>> I really like how the terminology has evolved and appreciate the=20 >>> summary! >>> >>> I have a few detail comments, but before I go there I'd like to=20 >>> cover one more open issue that I think will have some >>> (minor) ripple effects on the details. >>> >>> I think there's still the general issue of terminology to use when=20 >>> referring to the entity that "uses an overlay" and the entity that=20 >>> "instantiates the overlay". In your mail and in discussion we have: >>> >>> - client (service)/OC/CN/customer >>> >>> and >>> >>> - server(or service)/OE/EN/provider >>> >>> I think we had discussed, and possibly agreed on, using VPN=20 >>> terminology which would have us use the latter options, i.e., >>> (overlay) customer/provider (edge). This would mean eliminating any=20 >>> references to client/server in the *generic >>> overlay* definitions. Of course these terms may reemerge in other=20 >>> contexts as they have before, e.g., rfc6215. >> >> Yes, i think we all agreed. If there are still terms different from=20 >> customer/provider in the text it's because i missed them during the=20 >> replacing. >> >=20 > Great! Glad I didn't miss something over the holidays! >=20 > IB>> I personally have no problems with the VPN terminology. However, > IMO the terminology should be aligned with the RFC 4208 and George's=20 > drafts. My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped to e= ncompass the broad spectrum of overlays that are/have been discussed. > One cannot use different terminology within the same framework, right? Unfortunately we have no shortage of terminology defining (perhaps differen= t flavors) of the same thing! > Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. While I certainly agree that not all overlays need be VPNs, it seems to me = that our discussions are best aligned with that set of terminology, and tha= t UNI/ENNI can be described within the CE/PE/VN/VL/VT constructs. Perhaps with some tweaking in some cases. > The most important goal is to provide a solution for inter-domain=20 > horizontal integration between networks with possibly different=20 > switching technologies and independent addressing within the overlay=20 > model. >=20 Sure. It's also possible that an overlay will use the same switching techn= ology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably less lik= ely) the same address space (if a provider so chooses). >>> >>> I like this approach as it is aligned with the much of IETF work on=20 >>> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). >>> Importantly, RFC 4847 even has quite a few concepts that can be=20 >>> directly leveraged in this discussion. >>> >>> I'd even go further and say that we should base the definitions and=20 >>> resulting framework on RFC 4847. For example, the definitions below=20 >>> could start with something along the lines: >>> >>> The overlay service model, at a high level, follows Section >>> 7. of RFC 4847 as represented by: >>> >>> >>> +--------------------+ >>> : | | : >>> : | | : >>> +----+ : +----+ +----+ : +----+ >>> | CE |---:---| PE | | PE |---:---| CE | >>> +----+ : +----+ +----+ : +----+ >>> : | | : >>> : | | : >>> : +--------------------+ : >>> : | | : >>> : |<-Provider network->| : >>> Customer Customer >>> interface interface >>> >>> Figure 7.2: Overlay Service Model >>> >>> In this model, the overlay is instantiated by an overlay >>> "provider" and its provider edge (PE) nodes , and is used by >>> the overlay "customer" which is connected to the provider via >>> customer interfaces attached to customer edge (CE) nodes. >>> >>> ... >>> >>> The definition below would need to be tweaked slightly, notably to=20 >>> remove any references to client and server. The resulting framework=20 >>> can also refer back to RFC 4847 as needed. >>> >>> See below for some additional comments. >>> >>> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>>> Dear overlayers, >>>> >>>> Please find below a new version (v2) of the framework summary=20 >>>> reflecting the latest discussions. Again i hope i've >>> captured all the >>>> comments around, sorry if anything is missing, in case just let me=20 >>>> know what i missed. >>>> >>>> BR >>>> Daniele >>>> >>>> >>>> + Disclaimer: >>>> 1. Packet opto integration is often considered but the work can be=20 >>>> extented to any type of SC. Eg. TDM over LSC. >>>> >>>> + Terminology: >>>> 1. Virtual Link: A virtual link is a potential path between two=20 >>>> virtual or real network elements in a provider layer network >>> that is >>>> maintained/controlled in and by the provider domain control >>> plane (and >>>> as such cannot transport any traffic/data and protected from being >>>> de-provisioned) and which can be instantiated in the data plane=20 >>>> (and then can carry/transport/forward traffic/data) preserving=20 >>>> previously advertised attributes such as fate sharing information. >>>> >>> >>> You say "potential path". I this this should read "potential or=20 >>> instantiated path". >>> >> >> Maybe we need to define also what "potential" stands for? At least=20 >> two cases come to my mind (which might be included under the "potential" >> umbrella): >> >> 1. resources reserved via signaling but not instantiated >=20 > Sure. Sounds like a RFC6001 soft FA. >=20 >> 2. resources not even signaled. In presence of a centralized entity=20 >> managing the network (sort of PCE plus something) there is no need to=20 >> reserve resources via signaling as the central entity is the only=20 >> thing that can reserve or allocate resources. I'm thinking to an=20 >> opening towards the integration with the SDN world. >> >=20 > Sure. Sounds like a Virtual TE link (per RFC6001, 5212). >=20 IB>> Potential path can be defined as a feasible/provisionable path for the server layer trail supporting an advertised VL, which has attributes co= nsistent with the ones advertised for the Virtual Link (noticeably, bandwid= th, SRLGs, etc.) and is guaranteed to be available at the moment of the set= -up of a client LSP that has selected the VL in its path across the provide= r domain. >=20 >> Just loud thinking, does it make sense? >> >> >From my perspective, I think a node in the overlay really shouldn't >>> *directly* distinguish between the two -- now one may have a=20 >>> different metric/SRLG/weight/etc, but these are abstracted=20 >>> representations of the tradeoffs between use of the two, that can=20 >>> be provided by the underlying provider network, rather than a=20 >>> direct indication. >=20 IB>> It is beneficial from the client (ONT user) path computation point=20 IB>> of view to know whether the advertised VL is committed (the data=20 IB>> plane is provisioned) or not. Selecting uncommitted VL means: > a) Higher probability of a client LSP setup failure; > b) Longer client LSP setup time; > c) Probability of effectively removing other VLs from the ONT (those=20 > that share MELGs with the VL in question) And I'm suggesting that this be advertised using generic constructs such as= TE metric, SRLG, and even MELG, rather than adding yet another special cas= e computation/optimization parameter. >=20 >>> >>>> 2. Virtual Node: Virtual node is a collection of zero or more=20 >>>> provider network domain nodes that are collectively >>> represented to the >>>> clients as a single node that exists in the customer layer >>> network and >>>> is capable of terminating of access, inter-domain and virtual links. >>>> >>> >>> I'm a little uncomfortable with the linkage of real nodes to virtual=20 >>> nodes. I think VN is a purely abstract concept that may be=20 >>> instantiated using parts/whole/multiple/logical/real/etc nodes. >> >=20 > IB>> Agree completely >=20 >> Makes sense. What this definition adds to the one in RFC4847 is=20 >> basically the fact that also parts of a node can be considered. What=20 >> saying that it can be a real node i meant 1:1 correspondance between=20 >> a real and a virtual node. Your definition covers that case also,=20 >> that's fine. >> >>> >>> How about something like: >>> Virtual Node: A virtual node is a representation of a collection of=20 >>> provider resources that are interconnected via virtual (and=20 >>> customer) links. A virtual node may be collection of zero or more,=20 >>> including portions of, provider nodes that are collectively=20 >>> represented to the customer as a single node which is available in an o= verlay network. >> >> Works for me. >> >=20 > Great. BTW I don't think 4847 precluded a single physical node being rep= resented as multiple virtual nodes, but it doesn't hurt to make it explicit= . >=20 >>> >>>> 3. Virtual Topology: Virtual topology is a collection of one or=20 >>>> more virtual or real provider network domain nodes that exist in=20 >>>> the customer layer network and are interconnected via 0 or more=20 >>>> virtual links. >>> >>> How about: >>> Virtual Topology: A virtual topology is the collection of virtual=20 >>> links and nodes advertised by a provider to a customer. The virtual=20 >>> topology includes resources that are advertised as reachable within=20 >>> an overlay network. >>> >>> Do you mean to imply/allow for a VN which has no links? >> >> The case of "interconnected via 0 virtual links" implies the whole=20 >> domain seen as a single node. >> >=20 > Ahh, fair enough. >=20 >>> >>>> 4. Overlay topology: is a superset of virtual topologies >>> provided by >>>> each of provider network domains, access and inter-domain links. >>>> >>> >>> Doesn't it also include any topology information advertised by the=20 >>> customer/CE as well? >=20 > IB>> Yes, it does: the ends of access links terminated by the clients=20 > IB>> along with the custom NEs IDs >=20 sounds like some agreement here. I think that was you final comment... Lou >> >> Possibly. Do you mean advertised by the CE in the customer domain, right= ? >> >=20 > That's possible too, but I was thinking more of advertised by CE > (customer) to PE (provider). >=20 >>> >>>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It=20 >>>> can support any of the SCs supported by the GMPLS. >>>> >>> >>> If we adopt RFC 4847 terminology it should be "customer interface". >>> Also, I suspect you mean PE and CE. >> >> Mmm, yes but what if we want to manage it as a link? i.e. All=20 >> TE-parameters that a link supports. Is it enough to call it interface=20 >> only? >> >=20 > sure. Per 4847, I'd say that "customer interface" is the connection betw= een CE/PE while [virtual] TE links are what is advertised/represented in ro= uting. >=20 >>> >>>> 6. CE (customer Edge): Something like the CN in RFC4208 >>> teminology but >>>> (i) receiving virtual topology from the provider network and=20 >>>> requesting the set up of one of them or (ii) requesting the=20 >>>> computation and establishment of a path accordingly to given=20 >>>> constraints in the provider network and receiving the parameters=20 >>>> characterizing such path. (ii) =3D=3D UNI. >>>> >>> >>> humm, I'm inclined to stay away from UNI for the moment. I also=20 >>> suggest that we look to 4874 and even 4364 rather than 4208... >> >> Ok, we can refer to those RFC for what concerns terminology, but at=20 >> the end of the day we must put the UNI under this framework. In the=20 >> new terminology the UNI is a particular type of customer interface. >> >=20 > Fair enough. But it is a form on an overlay "customer interface" not the= definitive form. >=20 >>> >>>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to=20 >>>> deal with (i) and (ii) above. >>>> >>> >>> same comment WRT RFCs. >>> >>>> 8. PE-CE interface (former ONI) : Interface allowing for >>> signaling and >>>> routing messages exchange between customer overlay and provider=20 >>>> network. Routing information consists on virtual topology=20 >>>> advertisement. When there is no routing adjacency across the >>> interface >>>> it is equivalent to the GMPLS UNI defined in 4208. >>>> Signaling messages are compliant with RFC4208. Information >>> related to >>>> path carachteristics, e.g. TE-metrics, collected SRLG, path >>> delay etc, >>>> either passed from CE to PE via signaling after the LSP >>> establishment >>>> in the core network or from CE to PE to be used as path computation=20 >>>> constraints, fall under the definition of signaling info and not=20 >>>> routing info). >>>> >>> >>> >>>> 9. CE-CE (former O-NNI): Interface on the links between different=20 >>>> provider networks in the overlay model environment. Same features=20 >>>> of the CE-PE apply to this interface. >>>> >>> >>> you mean, PE-PE, right? >> >> You're not the first one that makes me notice i'm probably affected=20 >> by dyslexia :-) >> >=20 > no problem, happens to the best of us! >=20 >>> >>>> + Statements 1. In the context of overlay model we are aiming to >>>> build an overlay topology for the customer network domains >>>> >>>> 2. The overlay topology is comprised of: >>>> a) access links (links connecting client NEs to the >>> provider network domains). >>>> They can be PSC or LSC. >>>> b) inter-domain links (links interconnecting server >>> network domains) >>>> c) virtual topology provided by the provider network domains.=20 >>>> Virtual Links >>>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of=20 >>>> + parameters >>>> e.g. SRLG, optical impairments, delay etc for each entry)=20 >>>> describing connectivity between access links and virtual links. >>>> >>>> 3. In the context of overlay model we manage hierarchy of overlay=20 >>>> topologies with overlay/underlay relationships >>>> >>>> 4. In the context of overlay model multi-layering and inter-layer=20 >>>> relationships are peripheral at best, it is all about horizontal=20 >>>> network integration >>>> >>>> 5. The overlay model assumes one CP instance for the >>> customer network >>>> and a separate instance for the provider network and in the CE-PE=20 >>>> interface case the provider network also surreptitiously >>> participates >>>> in the customer network by injecting virtual topology >>> information into >>>> it. >>>> >>> >>> We should ensure we're allowing for some of the existing/augmented=20 >>> models that permit the transport of overlay information within the=20 >>> provider's CP, e.g., rfc4364, 5195 and 5252. >> >> I'd say they should be already covered, but will double check >> >=20 > great. >=20 >>> >>>> 6. L1VPN (and LxVPN) in general is a type of service >>> provided over the >>>> CE-PE interface (it falls under the UNI case as no routing=20 >>>> adjacency is in place between CE and PE). >>>> >>>> >>>> + Advertisement models (to be detailed in dedicated >>>> + document/documents) >>>> The CE-PE interface in the overlay model context foresees >>> two types of >>>> advertisement models.(names still to be agreed) >>>> >>>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >>> augmented by >>>> a number of actived draft (references to various drafts to >>> be added).=20 >>>> The Augmented UNI is a particular type of CE-PE interface where=20 >>>> only signaling messages are exchanged between CE and PE. >>>> Messages from CE to PE can include a set of parameters to be used=20 >>>> by the PE as path computation constraints when computing a path in=20 >>>> the provider domain network, while messages from PE to CE can=20 >>>> include a set of parameters qualifying the LSP being established,=20 >>>> like for example SRLG, delay, loss etc. >>>> >>> >>> again, we can leverage 4874 terminology if we so choose, i.e.,=20 >>> "basic mode" and "enhanced mode" UNI|NNI >> >> Don would be happy about that :-). I'd say yes. The goal was to cover=20 >> the L1VPN work (enhanced mode), all the drafts-ali recently polled=20 >> for wg adoption (basic mode?) and the actual ENNI (enhanced mode). >=20 >> Is my mapping in brackets correct? >> >=20 > Not sure f I'd break it down they way you are. I'd say basic mode is clo= ser to the typical UNI and enhance mode is UNI+routing or perhaps even an E= NNI. >=20 >> >>> >>>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >>>> called with the general CE-PE interface term?) allowing the=20 >>>> establishment of signaling and routing adjacency between CE and PE. >>>> Routing info passed from PE to CE comprise overlay topology=20 >>>> information including (but not limited to) virtual links, >>> connectivity >>>> matrices and access links with parameters qualifying each of them=20 >>>> in terms of e.g. SRLG, loss, delay etc. Signaling information and=20 >>>> procedures are compliant with RFC4208. >>>> >>> >>> so this is just and 4874 "enhanced mode" interface, right. >> >> Good question: the enhanced mode supports signaling and routing, so=20 >> i'd say yes, but reading section 7.3 it talks about "limited exchange=20 >> of information between the control planes. >> >> "permits limited exchange of >> information between the control planes of the provider and the >> customer to help such functions as discovery of customer network >> routing information (i.e., reachability or TE information in remote >> customer sites), or parameters of the part of the provider's network >> dedicated to the customer." >> >> Would you say this includes what we want? (i.e. Virtual links,=20 >> virtual nodes, connectivity matrices, SRLG, delay, loss, etc) If yes=20 >> we're done, otherwise an option could be the denition of a third VPN=20 >> service model. >> >=20 > humm, need to think about this. Perhaps the best thing is to document=20 > the two different cases and then decide if we have something new or > (two) more detailed forms of something old. >=20 >>> >>>> + Open issues/questions >>>> 1. PCE-PCEP - do we need to include considerations about PCE >>> and PCEP >>>> into the overlay framework context? >>>> >>>> 2. BGP-LS needs to be considered >>>> 3. Should potentials be included? E.g. I2RS? >>>> 4. Virtual links: wouldn't a different definition of virtual links=20 >>>> avoid the advertisement of connectivity matrices (this is out of=20 >>>> the fwk scope but within the advertisement models one)? >>>> >>> >>>> Take this example: >>>> PE1-----CE1 CE2-----PE2 >>>> CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>>> CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>> >>> I think you've reversed CE and PE here... >> >> Yes, once again. >> >> No comment on my foolish proposal? >> >=20 > Which one? I liked your summary overall. >=20 > Lou >=20 >> >>> >>> Much thanks! >>> >>> Lou >>> (hatless...) >>> >>>> i.e. There are 2 VL connecting CE1 and CE2 that could be >>> available for >>>> PE1 and PE2 to set up an adjacency in the customer domain.=20 >>> CE1 and/or >>>> CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>>> depending on the connectivity matrices of CE1 and CE2. Hence >>> PEs need >>>> to be aware of both VL and connectivity matrices. My point >>> is: if CE1 >>>> advertises to PE1 only the VL that his connectivity matrix allows=20 >>>> to be connected to PE1 (e.g. VL1 only) and not all of them, it >>> should be >>>> possible to avoid the connectivity matrices advertisement. >>>> >>> >>>> =20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> DANIELE CECCARELLI >>>> System & Technology - PDU Optical & Metro >>>> >>>> Via E.Melen, 77 >>>> Genova, Italy >>>> Phone +390106002512 >>>> Mobile +393346725750 >>>> daniele.ceccarelli@ericsson.com >>>> www.ericsson.com >>>> >>> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 >=20 From lberger@labn.net Tue Jan 22 08:20:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD4921F89DA for ; Tue, 22 Jan 2013 08:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.394 X-Spam-Level: X-Spam-Status: No, score=-100.394 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6, 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 G4OiYQAPayZT for ; Tue, 22 Jan 2013 08:20:55 -0800 (PST) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 1A28421F8A11 for ; Tue, 22 Jan 2013 08:20:55 -0800 (PST) Received: (qmail 4830 invoked by uid 0); 22 Jan 2013 16:20:31 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 22 Jan 2013 16:20:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=AQG1hipQRyJq5NeijrJONztMcbL+50t1uVabfaM4BRc=; b=hZ8ljQYHHc2N/q8n/ovEnta+uuxIVJl3t1p+K4IfhcxLeffAfmxlXJMOcyGJLtYkvjyKibrSeYZ66TIaTMN3RcXdr3K5r2MTeWlu22+ZxrW+acclncl+euiYXxNpHucx; Received: from box313.bluehost.com ([69.89.31.113]:34776 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TxgaM-0006lx-IE; Tue, 22 Jan 2013 09:20:30 -0700 Message-ID: <50FEBC58.2030803@labn.net> Date: Tue, 22 Jan 2013 11:20:40 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Igor Bryskin References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:20:57 -0000 Igor, I was referring to you comment: IB>> It is beneficial from the client (ONT user) path computation point IB>> of view to know whether the advertised VL is committed (the data IB>> plane is provisioned) or not. So my point is that the U bit should be represented via an increased metric (or some other existing parameter) as this is what path computation is going to do in effect in any case. Lou On 1/22/2013 11:09 AM, Igor Bryskin wrote: > Hi Lou, > > You said: > And I'm suggesting that this be advertised using generic constructs such as TE metric, SRLG, and even MELG, rather than adding yet another special case computation/optimization parameter. > > Agree, we are already doing this via MELG sub-TLV. This is because the sub-TLV is new (no need to change the existing ones) and because MELG is peculiar to VL. > > Igor. > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, January 22, 2013 10:51 AM > To: Igor Bryskin > Cc: Daniele Ceccarelli; CCAMP > Subject: Re: [CCAMP] Overlay model framework v2 > > Igor, > > see below. > > On 1/22/2013 10:05 AM, Igor Bryskin wrote: >> Lou and Daniele, >> Please, see my comments in-line, >> >> Cheers, >> Igor >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Lou Berger >> Sent: Monday, January 21, 2013 5:13 PM >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Thanks Daniele, See below. >> >> On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: >>> Hi Lou, >>> >>> Please find comments in line >>> >>> BR >>> Daniele >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: venerd 18 gennaio 2013 18.27 >>>> To: Daniele Ceccarelli >>>> Cc: CCAMP >>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>> >>>> Daniele, >>>> Very nice summary. Just catching up, so sorry for the >>>> (2 day) late response. >>>> >>>> I really like how the terminology has evolved and appreciate the >>>> summary! >>>> >>>> I have a few detail comments, but before I go there I'd like to >>>> cover one more open issue that I think will have some >>>> (minor) ripple effects on the details. >>>> >>>> I think there's still the general issue of terminology to use when >>>> referring to the entity that "uses an overlay" and the entity that >>>> "instantiates the overlay". In your mail and in discussion we have: >>>> >>>> - client (service)/OC/CN/customer >>>> >>>> and >>>> >>>> - server(or service)/OE/EN/provider >>>> >>>> I think we had discussed, and possibly agreed on, using VPN >>>> terminology which would have us use the latter options, i.e., >>>> (overlay) customer/provider (edge). This would mean eliminating any >>>> references to client/server in the *generic >>>> overlay* definitions. Of course these terms may reemerge in other >>>> contexts as they have before, e.g., rfc6215. >>> >>> Yes, i think we all agreed. If there are still terms different from >>> customer/provider in the text it's because i missed them during the >>> replacing. >>> >> >> Great! Glad I didn't miss something over the holidays! >> >> IB>> I personally have no problems with the VPN terminology. However, >> IMO the terminology should be aligned with the RFC 4208 and George's >> drafts. > > My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped to encompass the broad spectrum of overlays that are/have been discussed. > >> One cannot use different terminology within the same framework, right? > > Unfortunately we have no shortage of terminology defining (perhaps different flavors) of the same thing! > >> Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. > > While I certainly agree that not all overlays need be VPNs, it seems to me that our discussions are best aligned with that set of terminology, and that UNI/ENNI can be described within the CE/PE/VN/VL/VT constructs. > Perhaps with some tweaking in some cases. > > >> The most important goal is to provide a solution for inter-domain >> horizontal integration between networks with possibly different >> switching technologies and independent addressing within the overlay >> model. >> > > Sure. It's also possible that an overlay will use the same switching technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably less likely) the same address space (if a provider so chooses). > >>>> >>>> I like this approach as it is aligned with the much of IETF work on >>>> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). >>>> Importantly, RFC 4847 even has quite a few concepts that can be >>>> directly leveraged in this discussion. >>>> >>>> I'd even go further and say that we should base the definitions and >>>> resulting framework on RFC 4847. For example, the definitions below >>>> could start with something along the lines: >>>> >>>> The overlay service model, at a high level, follows Section >>>> 7. of RFC 4847 as represented by: >>>> >>>> >>>> +--------------------+ >>>> : | | : >>>> : | | : >>>> +----+ : +----+ +----+ : +----+ >>>> | CE |---:---| PE | | PE |---:---| CE | >>>> +----+ : +----+ +----+ : +----+ >>>> : | | : >>>> : | | : >>>> : +--------------------+ : >>>> : | | : >>>> : |<-Provider network->| : >>>> Customer Customer >>>> interface interface >>>> >>>> Figure 7.2: Overlay Service Model >>>> >>>> In this model, the overlay is instantiated by an overlay >>>> "provider" and its provider edge (PE) nodes , and is used by >>>> the overlay "customer" which is connected to the provider via >>>> customer interfaces attached to customer edge (CE) nodes. >>>> >>>> ... >>>> >>>> The definition below would need to be tweaked slightly, notably to >>>> remove any references to client and server. The resulting framework >>>> can also refer back to RFC 4847 as needed. >>>> >>>> See below for some additional comments. >>>> >>>> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>>>> Dear overlayers, >>>>> >>>>> Please find below a new version (v2) of the framework summary >>>>> reflecting the latest discussions. Again i hope i've >>>> captured all the >>>>> comments around, sorry if anything is missing, in case just let me >>>>> know what i missed. >>>>> >>>>> BR >>>>> Daniele >>>>> >>>>> >>>>> + Disclaimer: >>>>> 1. Packet opto integration is often considered but the work can be >>>>> extented to any type of SC. Eg. TDM over LSC. >>>>> >>>>> + Terminology: >>>>> 1. Virtual Link: A virtual link is a potential path between two >>>>> virtual or real network elements in a provider layer network >>>> that is >>>>> maintained/controlled in and by the provider domain control >>>> plane (and >>>>> as such cannot transport any traffic/data and protected from being >>>>> de-provisioned) and which can be instantiated in the data plane >>>>> (and then can carry/transport/forward traffic/data) preserving >>>>> previously advertised attributes such as fate sharing information. >>>>> >>>> >>>> You say "potential path". I this this should read "potential or >>>> instantiated path". >>>> >>> >>> Maybe we need to define also what "potential" stands for? At least >>> two cases come to my mind (which might be included under the "potential" >>> umbrella): >>> >>> 1. resources reserved via signaling but not instantiated >> >> Sure. Sounds like a RFC6001 soft FA. >> >>> 2. resources not even signaled. In presence of a centralized entity >>> managing the network (sort of PCE plus something) there is no need to >>> reserve resources via signaling as the central entity is the only >>> thing that can reserve or allocate resources. I'm thinking to an >>> opening towards the integration with the SDN world. >>> >> >> Sure. Sounds like a Virtual TE link (per RFC6001, 5212). >> > IB>> Potential path can be defined as a feasible/provisionable path for > the server layer trail supporting an advertised VL, which has attributes consistent with the ones advertised for the Virtual Link (noticeably, bandwidth, SRLGs, etc.) and is guaranteed to be available at the moment of the set-up of a client LSP that has selected the VL in its path across the provider domain. >> >>> Just loud thinking, does it make sense? >>> >>> >From my perspective, I think a node in the overlay really shouldn't >>>> *directly* distinguish between the two -- now one may have a >>>> different metric/SRLG/weight/etc, but these are abstracted >>>> representations of the tradeoffs between use of the two, that can >>>> be provided by the underlying provider network, rather than a >>>> direct indication. >> > IB>> It is beneficial from the client (ONT user) path computation point > IB>> of view to know whether the advertised VL is committed (the data > IB>> plane is provisioned) or not. Selecting uncommitted VL means: >> a) Higher probability of a client LSP setup failure; >> b) Longer client LSP setup time; >> c) Probability of effectively removing other VLs from the ONT (those >> that share MELGs with the VL in question) > > And I'm suggesting that this be advertised using generic constructs such as TE metric, SRLG, and even MELG, rather than adding yet another special case computation/optimization parameter. > >> >>>> >>>>> 2. Virtual Node: Virtual node is a collection of zero or more >>>>> provider network domain nodes that are collectively >>>> represented to the >>>>> clients as a single node that exists in the customer layer >>>> network and >>>>> is capable of terminating of access, inter-domain and virtual links. >>>>> >>>> >>>> I'm a little uncomfortable with the linkage of real nodes to virtual >>>> nodes. I think VN is a purely abstract concept that may be >>>> instantiated using parts/whole/multiple/logical/real/etc nodes. >>> >> >> IB>> Agree completely >> >>> Makes sense. What this definition adds to the one in RFC4847 is >>> basically the fact that also parts of a node can be considered. What >>> saying that it can be a real node i meant 1:1 correspondance between >>> a real and a virtual node. Your definition covers that case also, >>> that's fine. >>> >>>> >>>> How about something like: >>>> Virtual Node: A virtual node is a representation of a collection of >>>> provider resources that are interconnected via virtual (and >>>> customer) links. A virtual node may be collection of zero or more, >>>> including portions of, provider nodes that are collectively >>>> represented to the customer as a single node which is available in an overlay network. >>> >>> Works for me. >>> >> >> Great. BTW I don't think 4847 precluded a single physical node being represented as multiple virtual nodes, but it doesn't hurt to make it explicit. >> >>>> >>>>> 3. Virtual Topology: Virtual topology is a collection of one or >>>>> more virtual or real provider network domain nodes that exist in >>>>> the customer layer network and are interconnected via 0 or more >>>>> virtual links. >>>> >>>> How about: >>>> Virtual Topology: A virtual topology is the collection of virtual >>>> links and nodes advertised by a provider to a customer. The virtual >>>> topology includes resources that are advertised as reachable within >>>> an overlay network. >>>> >>>> Do you mean to imply/allow for a VN which has no links? >>> >>> The case of "interconnected via 0 virtual links" implies the whole >>> domain seen as a single node. >>> >> >> Ahh, fair enough. >> >>>> >>>>> 4. Overlay topology: is a superset of virtual topologies >>>> provided by >>>>> each of provider network domains, access and inter-domain links. >>>>> >>>> >>>> Doesn't it also include any topology information advertised by the >>>> customer/CE as well? >> >> IB>> Yes, it does: the ends of access links terminated by the clients >> IB>> along with the custom NEs IDs >> > > sounds like some agreement here. > > I think that was you final comment... > > Lou > >>> >>> Possibly. Do you mean advertised by the CE in the customer domain, right? >>> >> >> That's possible too, but I was thinking more of advertised by CE >> (customer) to PE (provider). >> >>>> >>>>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It >>>>> can support any of the SCs supported by the GMPLS. >>>>> >>>> >>>> If we adopt RFC 4847 terminology it should be "customer interface". >>>> Also, I suspect you mean PE and CE. >>> >>> Mmm, yes but what if we want to manage it as a link? i.e. All >>> TE-parameters that a link supports. Is it enough to call it interface >>> only? >>> >> >> sure. Per 4847, I'd say that "customer interface" is the connection between CE/PE while [virtual] TE links are what is advertised/represented in routing. >> >>>> >>>>> 6. CE (customer Edge): Something like the CN in RFC4208 >>>> teminology but >>>>> (i) receiving virtual topology from the provider network and >>>>> requesting the set up of one of them or (ii) requesting the >>>>> computation and establishment of a path accordingly to given >>>>> constraints in the provider network and receiving the parameters >>>>> characterizing such path. (ii) == UNI. >>>>> >>>> >>>> humm, I'm inclined to stay away from UNI for the moment. I also >>>> suggest that we look to 4874 and even 4364 rather than 4208... >>> >>> Ok, we can refer to those RFC for what concerns terminology, but at >>> the end of the day we must put the UNI under this framework. In the >>> new terminology the UNI is a particular type of customer interface. >>> >> >> Fair enough. But it is a form on an overlay "customer interface" not the definitive form. >> >>>> >>>>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to >>>>> deal with (i) and (ii) above. >>>>> >>>> >>>> same comment WRT RFCs. >>>> >>>>> 8. PE-CE interface (former ONI) : Interface allowing for >>>> signaling and >>>>> routing messages exchange between customer overlay and provider >>>>> network. Routing information consists on virtual topology >>>>> advertisement. When there is no routing adjacency across the >>>> interface >>>>> it is equivalent to the GMPLS UNI defined in 4208. >>>>> Signaling messages are compliant with RFC4208. Information >>>> related to >>>>> path carachteristics, e.g. TE-metrics, collected SRLG, path >>>> delay etc, >>>>> either passed from CE to PE via signaling after the LSP >>>> establishment >>>>> in the core network or from CE to PE to be used as path computation >>>>> constraints, fall under the definition of signaling info and not >>>>> routing info). >>>>> >>>> >>>> >>>>> 9. CE-CE (former O-NNI): Interface on the links between different >>>>> provider networks in the overlay model environment. Same features >>>>> of the CE-PE apply to this interface. >>>>> >>>> >>>> you mean, PE-PE, right? >>> >>> You're not the first one that makes me notice i'm probably affected >>> by dyslexia :-) >>> >> >> no problem, happens to the best of us! >> >>>> >>>>> + Statements 1. In the context of overlay model we are aiming to >>>>> build an overlay topology for the customer network domains >>>>> >>>>> 2. The overlay topology is comprised of: >>>>> a) access links (links connecting client NEs to the >>>> provider network domains). >>>>> They can be PSC or LSC. >>>>> b) inter-domain links (links interconnecting server >>>> network domains) >>>>> c) virtual topology provided by the provider network domains. >>>>> Virtual Links >>>>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of >>>>> + parameters >>>>> e.g. SRLG, optical impairments, delay etc for each entry) >>>>> describing connectivity between access links and virtual links. >>>>> >>>>> 3. In the context of overlay model we manage hierarchy of overlay >>>>> topologies with overlay/underlay relationships >>>>> >>>>> 4. In the context of overlay model multi-layering and inter-layer >>>>> relationships are peripheral at best, it is all about horizontal >>>>> network integration >>>>> >>>>> 5. The overlay model assumes one CP instance for the >>>> customer network >>>>> and a separate instance for the provider network and in the CE-PE >>>>> interface case the provider network also surreptitiously >>>> participates >>>>> in the customer network by injecting virtual topology >>>> information into >>>>> it. >>>>> >>>> >>>> We should ensure we're allowing for some of the existing/augmented >>>> models that permit the transport of overlay information within the >>>> provider's CP, e.g., rfc4364, 5195 and 5252. >>> >>> I'd say they should be already covered, but will double check >>> >> >> great. >> >>>> >>>>> 6. L1VPN (and LxVPN) in general is a type of service >>>> provided over the >>>>> CE-PE interface (it falls under the UNI case as no routing >>>>> adjacency is in place between CE and PE). >>>>> >>>>> >>>>> + Advertisement models (to be detailed in dedicated >>>>> + document/documents) >>>>> The CE-PE interface in the overlay model context foresees >>>> two types of >>>>> advertisement models.(names still to be agreed) >>>>> >>>>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >>>> augmented by >>>>> a number of actived draft (references to various drafts to >>>> be added). >>>>> The Augmented UNI is a particular type of CE-PE interface where >>>>> only signaling messages are exchanged between CE and PE. >>>>> Messages from CE to PE can include a set of parameters to be used >>>>> by the PE as path computation constraints when computing a path in >>>>> the provider domain network, while messages from PE to CE can >>>>> include a set of parameters qualifying the LSP being established, >>>>> like for example SRLG, delay, loss etc. >>>>> >>>> >>>> again, we can leverage 4874 terminology if we so choose, i.e., >>>> "basic mode" and "enhanced mode" UNI|NNI >>> >>> Don would be happy about that :-). I'd say yes. The goal was to cover >>> the L1VPN work (enhanced mode), all the drafts-ali recently polled >>> for wg adoption (basic mode?) and the actual ENNI (enhanced mode). >> >>> Is my mapping in brackets correct? >>> >> >> Not sure f I'd break it down they way you are. I'd say basic mode is closer to the typical UNI and enhance mode is UNI+routing or perhaps even an ENNI. >> >>> >>>> >>>>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >>>>> called with the general CE-PE interface term?) allowing the >>>>> establishment of signaling and routing adjacency between CE and PE. >>>>> Routing info passed from PE to CE comprise overlay topology >>>>> information including (but not limited to) virtual links, >>>> connectivity >>>>> matrices and access links with parameters qualifying each of them >>>>> in terms of e.g. SRLG, loss, delay etc. Signaling information and >>>>> procedures are compliant with RFC4208. >>>>> >>>> >>>> so this is just and 4874 "enhanced mode" interface, right. >>> >>> Good question: the enhanced mode supports signaling and routing, so >>> i'd say yes, but reading section 7.3 it talks about "limited exchange >>> of information between the control planes. >>> >>> "permits limited exchange of >>> information between the control planes of the provider and the >>> customer to help such functions as discovery of customer network >>> routing information (i.e., reachability or TE information in remote >>> customer sites), or parameters of the part of the provider's network >>> dedicated to the customer." >>> >>> Would you say this includes what we want? (i.e. Virtual links, >>> virtual nodes, connectivity matrices, SRLG, delay, loss, etc) If yes >>> we're done, otherwise an option could be the denition of a third VPN >>> service model. >>> >> >> humm, need to think about this. Perhaps the best thing is to document >> the two different cases and then decide if we have something new or >> (two) more detailed forms of something old. >> >>>> >>>>> + Open issues/questions >>>>> 1. PCE-PCEP - do we need to include considerations about PCE >>>> and PCEP >>>>> into the overlay framework context? >>>>> >>>>> 2. BGP-LS needs to be considered >>>>> 3. Should potentials be included? E.g. I2RS? >>>>> 4. Virtual links: wouldn't a different definition of virtual links >>>>> avoid the advertisement of connectivity matrices (this is out of >>>>> the fwk scope but within the advertisement models one)? >>>>> >>>> >>>>> Take this example: >>>>> PE1-----CE1 CE2-----PE2 >>>>> CE1======VL1======CE2 >>>>> CE1======VL2======CE2 >>>> >>>> I think you've reversed CE and PE here... >>> >>> Yes, once again. >>> >>> No comment on my foolish proposal? >>> >> >> Which one? I liked your summary overall. >> >> Lou >> >>> >>>> >>>> Much thanks! >>>> >>>> Lou >>>> (hatless...) >>>> >>>>> i.e. There are 2 VL connecting CE1 and CE2 that could be >>>> available for >>>>> PE1 and PE2 to set up an adjacency in the customer domain. >>>> CE1 and/or >>>>> CE2 can be blocking nodes so VL1 and/or VL2 are available only >>>>> depending on the connectivity matrices of CE1 and CE2. Hence >>>> PEs need >>>>> to be aware of both VL and connectivity matrices. My point >>>> is: if CE1 >>>>> advertises to PE1 only the VL that his connectivity matrix allows >>>>> to be connected to PE1 (e.g. VL1 only) and not all of them, it >>>> should be >>>>> possible to avoid the connectivity matrices advertisement. >>>>> >>>> >>>>> >>>>> =================================== >>>>> DANIELE CECCARELLI >>>>> System & Technology - PDU Optical & Metro >>>>> >>>>> Via E.Melen, 77 >>>>> Genova, Italy >>>>> Phone +390106002512 >>>>> Mobile +393346725750 >>>>> daniele.ceccarelli@ericsson.com >>>>> www.ericsson.com >>>>> >>>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > > > > From IBryskin@advaoptical.com Tue Jan 22 08:41:48 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE85221F8A72 for ; Tue, 22 Jan 2013 08:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6] 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 hI2I0QczzaIO for ; Tue, 22 Jan 2013 08:41:46 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id CA0DD21F8A5A for ; Tue, 22 Jan 2013 08:41:45 -0800 (PST) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0MGffON025530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jan 2013 17:41:41 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.516.32; Tue, 22 Jan 2013 17:41:40 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Tue, 22 Jan 2013 11:41:38 -0500 From: Igor Bryskin To: Lou Berger Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBzClcAAJEUjQAAD8STgAAXoD7AAA1TKgAAChyl0P//t3cAgABQ0/A= Date: Tue, 22 Jan 2013 16:41:38 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <50FEBC58.2030803@labn.net> In-Reply-To: <50FEBC58.2030803@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-22_07:2013-01-22, 2013-01-22, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:41:49 -0000 Lou, Generally it is not a good idea to play with the TE metric.=20 It is up to client path computer (or client policy) to decide how important= the difference between a committed and uncommitted VL, and hence to defin= e the TE metric penalty. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, January 22, 2013 11:21 AM To: Igor Bryskin Cc: Daniele Ceccarelli; CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Igor, I was referring to you comment: IB>> It is beneficial from the client (ONT user) path computation point=20 IB>> of view to know whether the advertised VL is committed (the data=20 IB>> plane is provisioned) or not. So my point is that the U bit should be represented via an increased metric= (or some other existing parameter) as this is what path computation is goi= ng to do in effect in any case. Lou On 1/22/2013 11:09 AM, Igor Bryskin wrote: > Hi Lou, >=20 > You said: > And I'm suggesting that this be advertised using generic constructs such = as TE metric, SRLG, and even MELG, rather than adding yet another special c= ase computation/optimization parameter. >=20 > Agree, we are already doing this via MELG sub-TLV. This is because the su= b-TLV is new (no need to change the existing ones) and because MELG is pecu= liar to VL. >=20 > Igor. >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, January 22, 2013 10:51 AM > To: Igor Bryskin > Cc: Daniele Ceccarelli; CCAMP > Subject: Re: [CCAMP] Overlay model framework v2 >=20 > Igor, >=20 > see below. >=20 > On 1/22/2013 10:05 AM, Igor Bryskin wrote: >> Lou and Daniele, >> Please, see my comments in-line, >> >> Cheers, >> Igor >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> Behalf Of Lou Berger >> Sent: Monday, January 21, 2013 5:13 PM >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Thanks Daniele, See below. >> >> On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: >>> Hi Lou, >>> >>> Please find comments in line >>> >>> BR >>> Daniele >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: venerd=EC 18 gennaio 2013 18.27 >>>> To: Daniele Ceccarelli >>>> Cc: CCAMP >>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>> >>>> Daniele, >>>> Very nice summary. Just catching up, so sorry for the >>>> (2 day) late response. >>>> >>>> I really like how the terminology has evolved and appreciate the=20 >>>> summary! >>>> >>>> I have a few detail comments, but before I go there I'd like to=20 >>>> cover one more open issue that I think will have some >>>> (minor) ripple effects on the details. >>>> >>>> I think there's still the general issue of terminology to use when=20 >>>> referring to the entity that "uses an overlay" and the entity that=20 >>>> "instantiates the overlay". In your mail and in discussion we have: >>>> >>>> - client (service)/OC/CN/customer >>>> >>>> and >>>> >>>> - server(or service)/OE/EN/provider >>>> >>>> I think we had discussed, and possibly agreed on, using VPN=20 >>>> terminology which would have us use the latter options, i.e., >>>> (overlay) customer/provider (edge). This would mean eliminating=20 >>>> any references to client/server in the *generic >>>> overlay* definitions. Of course these terms may reemerge in other=20 >>>> contexts as they have before, e.g., rfc6215. >>> >>> Yes, i think we all agreed. If there are still terms different from=20 >>> customer/provider in the text it's because i missed them during the=20 >>> replacing. >>> >> >> Great! Glad I didn't miss something over the holidays! >> >> IB>> I personally have no problems with the VPN terminology. However, >> IMO the terminology should be aligned with the RFC 4208 and George's=20 >> drafts. >=20 > My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped to= encompass the broad spectrum of overlays that are/have been discussed. >=20 >> One cannot use different terminology within the same framework, right? >=20 > Unfortunately we have no shortage of terminology defining (perhaps differ= ent flavors) of the same thing! >=20 >> Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. >=20 > While I certainly agree that not all overlays need be VPNs, it seems to m= e that our discussions are best aligned with that set of terminology, and t= hat UNI/ENNI can be described within the CE/PE/VN/VL/VT constructs. > Perhaps with some tweaking in some cases. >=20 >=20 >> The most important goal is to provide a solution for inter-domain=20 >> horizontal integration between networks with possibly different=20 >> switching technologies and independent addressing within the overlay=20 >> model. >> >=20 > Sure. It's also possible that an overlay will use the same switching tec= hnology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably less l= ikely) the same address space (if a provider so chooses). >=20 >>>> >>>> I like this approach as it is aligned with the much of IETF work on=20 >>>> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). >>>> Importantly, RFC 4847 even has quite a few concepts that can be=20 >>>> directly leveraged in this discussion. >>>> >>>> I'd even go further and say that we should base the definitions and=20 >>>> resulting framework on RFC 4847. For example, the definitions=20 >>>> below could start with something along the lines: >>>> >>>> The overlay service model, at a high level, follows Section >>>> 7. of RFC 4847 as represented by: >>>> >>>> >>>> +--------------------+ >>>> : | | : >>>> : | | : >>>> +----+ : +----+ +----+ : +----+ >>>> | CE |---:---| PE | | PE |---:---| CE | >>>> +----+ : +----+ +----+ : +----+ >>>> : | | : >>>> : | | : >>>> : +--------------------+ : >>>> : | | : >>>> : |<-Provider network->| : >>>> Customer Customer >>>> interface interface >>>> >>>> Figure 7.2: Overlay Service Model >>>> >>>> In this model, the overlay is instantiated by an overlay >>>> "provider" and its provider edge (PE) nodes , and is used by >>>> the overlay "customer" which is connected to the provider via >>>> customer interfaces attached to customer edge (CE) nodes. >>>> >>>> ... >>>> >>>> The definition below would need to be tweaked slightly, notably to=20 >>>> remove any references to client and server. The resulting=20 >>>> framework can also refer back to RFC 4847 as needed. >>>> >>>> See below for some additional comments. >>>> >>>> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>>>> Dear overlayers, >>>>> >>>>> Please find below a new version (v2) of the framework summary=20 >>>>> reflecting the latest discussions. Again i hope i've >>>> captured all the >>>>> comments around, sorry if anything is missing, in case just let me=20 >>>>> know what i missed. >>>>> >>>>> BR >>>>> Daniele >>>>> >>>>> >>>>> + Disclaimer: >>>>> 1. Packet opto integration is often considered but the work can be=20 >>>>> extented to any type of SC. Eg. TDM over LSC. >>>>> >>>>> + Terminology: >>>>> 1. Virtual Link: A virtual link is a potential path between two=20 >>>>> virtual or real network elements in a provider layer network >>>> that is >>>>> maintained/controlled in and by the provider domain control >>>> plane (and >>>>> as such cannot transport any traffic/data and protected from being >>>>> de-provisioned) and which can be instantiated in the data plane=20 >>>>> (and then can carry/transport/forward traffic/data) preserving=20 >>>>> previously advertised attributes such as fate sharing information. >>>>> >>>> >>>> You say "potential path". I this this should read "potential or=20 >>>> instantiated path". >>>> >>> >>> Maybe we need to define also what "potential" stands for? At least=20 >>> two cases come to my mind (which might be included under the "potential= " >>> umbrella): >>> >>> 1. resources reserved via signaling but not instantiated >> >> Sure. Sounds like a RFC6001 soft FA. >> >>> 2. resources not even signaled. In presence of a centralized entity=20 >>> managing the network (sort of PCE plus something) there is no need=20 >>> to reserve resources via signaling as the central entity is the only=20 >>> thing that can reserve or allocate resources. I'm thinking to an=20 >>> opening towards the integration with the SDN world. >>> >> >> Sure. Sounds like a Virtual TE link (per RFC6001, 5212). >> > IB>> Potential path can be defined as a feasible/provisionable path=20 > IB>> for > the server layer trail supporting an advertised VL, which has attributes = consistent with the ones advertised for the Virtual Link (noticeably, bandw= idth, SRLGs, etc.) and is guaranteed to be available at the moment of the s= et-up of a client LSP that has selected the VL in its path across the provi= der domain. >> >>> Just loud thinking, does it make sense? >>> >>> >From my perspective, I think a node in the overlay really shouldn't >>>> *directly* distinguish between the two -- now one may have a=20 >>>> different metric/SRLG/weight/etc, but these are abstracted=20 >>>> representations of the tradeoffs between use of the two, that can=20 >>>> be provided by the underlying provider network, rather than a=20 >>>> direct indication. >> > IB>> It is beneficial from the client (ONT user) path computation=20 > IB>> point of view to know whether the advertised VL is committed (the=20 > IB>> data plane is provisioned) or not. Selecting uncommitted VL means: >> a) Higher probability of a client LSP setup failure; >> b) Longer client LSP setup time; >> c) Probability of effectively removing other VLs from the ONT (those=20 >> that share MELGs with the VL in question) >=20 > And I'm suggesting that this be advertised using generic constructs such = as TE metric, SRLG, and even MELG, rather than adding yet another special c= ase computation/optimization parameter. >=20 >> >>>> >>>>> 2. Virtual Node: Virtual node is a collection of zero or more=20 >>>>> provider network domain nodes that are collectively >>>> represented to the >>>>> clients as a single node that exists in the customer layer >>>> network and >>>>> is capable of terminating of access, inter-domain and virtual links. >>>>> >>>> >>>> I'm a little uncomfortable with the linkage of real nodes to=20 >>>> virtual nodes. I think VN is a purely abstract concept that may be=20 >>>> instantiated using parts/whole/multiple/logical/real/etc nodes. >>> >> >> IB>> Agree completely >> >>> Makes sense. What this definition adds to the one in RFC4847 is=20 >>> basically the fact that also parts of a node can be considered. What=20 >>> saying that it can be a real node i meant 1:1 correspondance between=20 >>> a real and a virtual node. Your definition covers that case also,=20 >>> that's fine. >>> >>>> >>>> How about something like: >>>> Virtual Node: A virtual node is a representation of a collection of=20 >>>> provider resources that are interconnected via virtual (and >>>> customer) links. A virtual node may be collection of zero or=20 >>>> more, including portions of, provider nodes that are collectively=20 >>>> represented to the customer as a single node which is available in an = overlay network. >>> >>> Works for me. >>> >> >> Great. BTW I don't think 4847 precluded a single physical node being re= presented as multiple virtual nodes, but it doesn't hurt to make it explici= t. >> >>>> >>>>> 3. Virtual Topology: Virtual topology is a collection of one or=20 >>>>> more virtual or real provider network domain nodes that exist in=20 >>>>> the customer layer network and are interconnected via 0 or more=20 >>>>> virtual links. >>>> >>>> How about: >>>> Virtual Topology: A virtual topology is the collection of virtual=20 >>>> links and nodes advertised by a provider to a customer. The virtual=20 >>>> topology includes resources that are advertised as reachable within=20 >>>> an overlay network. >>>> >>>> Do you mean to imply/allow for a VN which has no links? >>> >>> The case of "interconnected via 0 virtual links" implies the whole=20 >>> domain seen as a single node. >>> >> >> Ahh, fair enough. >> >>>> >>>>> 4. Overlay topology: is a superset of virtual topologies >>>> provided by >>>>> each of provider network domains, access and inter-domain links. >>>>> >>>> >>>> Doesn't it also include any topology information advertised by the=20 >>>> customer/CE as well? >> >> IB>> Yes, it does: the ends of access links terminated by the clients=20 >> IB>> along with the custom NEs IDs >> >=20 > sounds like some agreement here. >=20 > I think that was you final comment... >=20 > Lou >=20 >>> >>> Possibly. Do you mean advertised by the CE in the customer domain, righ= t? >>> >> >> That's possible too, but I was thinking more of advertised by CE >> (customer) to PE (provider). >> >>>> >>>>> 5. Access Link: Link between OC and OE. GMPLS runs on that link.=20 >>>>> It can support any of the SCs supported by the GMPLS. >>>>> >>>> >>>> If we adopt RFC 4847 terminology it should be "customer interface". >>>> Also, I suspect you mean PE and CE. >>> >>> Mmm, yes but what if we want to manage it as a link? i.e. All=20 >>> TE-parameters that a link supports. Is it enough to call it=20 >>> interface only? >>> >> >> sure. Per 4847, I'd say that "customer interface" is the connection bet= ween CE/PE while [virtual] TE links are what is advertised/represented in r= outing. >> >>>> >>>>> 6. CE (customer Edge): Something like the CN in RFC4208 >>>> teminology but >>>>> (i) receiving virtual topology from the provider network and=20 >>>>> requesting the set up of one of them or (ii) requesting the=20 >>>>> computation and establishment of a path accordingly to given=20 >>>>> constraints in the provider network and receiving the parameters=20 >>>>> characterizing such path. (ii) =3D=3D UNI. >>>>> >>>> >>>> humm, I'm inclined to stay away from UNI for the moment. I also=20 >>>> suggest that we look to 4874 and even 4364 rather than 4208... >>> >>> Ok, we can refer to those RFC for what concerns terminology, but at=20 >>> the end of the day we must put the UNI under this framework. In the=20 >>> new terminology the UNI is a particular type of customer interface. >>> >> >> Fair enough. But it is a form on an overlay "customer interface" not th= e definitive form. >> >>>> >>>>> 7. PE (provider Edge): Something like the EN in RFC4208 but able=20 >>>>> to deal with (i) and (ii) above. >>>>> >>>> >>>> same comment WRT RFCs. >>>> >>>>> 8. PE-CE interface (former ONI) : Interface allowing for >>>> signaling and >>>>> routing messages exchange between customer overlay and provider=20 >>>>> network. Routing information consists on virtual topology=20 >>>>> advertisement. When there is no routing adjacency across the >>>> interface >>>>> it is equivalent to the GMPLS UNI defined in 4208. >>>>> Signaling messages are compliant with RFC4208. Information >>>> related to >>>>> path carachteristics, e.g. TE-metrics, collected SRLG, path >>>> delay etc, >>>>> either passed from CE to PE via signaling after the LSP >>>> establishment >>>>> in the core network or from CE to PE to be used as path=20 >>>>> computation constraints, fall under the definition of signaling=20 >>>>> info and not routing info). >>>>> >>>> >>>> >>>>> 9. CE-CE (former O-NNI): Interface on the links between different=20 >>>>> provider networks in the overlay model environment. Same features=20 >>>>> of the CE-PE apply to this interface. >>>>> >>>> >>>> you mean, PE-PE, right? >>> >>> You're not the first one that makes me notice i'm probably affected=20 >>> by dyslexia :-) >>> >> >> no problem, happens to the best of us! >> >>>> >>>>> + Statements 1. In the context of overlay model we are aiming to >>>>> build an overlay topology for the customer network domains >>>>> >>>>> 2. The overlay topology is comprised of: >>>>> a) access links (links connecting client NEs to the >>>> provider network domains). >>>>> They can be PSC or LSC. >>>>> b) inter-domain links (links interconnecting server >>>> network domains) >>>>> c) virtual topology provided by the provider network domains.=20 >>>>> Virtual Links >>>>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of=20 >>>>> + parameters >>>>> e.g. SRLG, optical impairments, delay etc for each entry)=20 >>>>> describing connectivity between access links and virtual links. >>>>> >>>>> 3. In the context of overlay model we manage hierarchy of=20 >>>>> overlay topologies with overlay/underlay relationships >>>>> >>>>> 4. In the context of overlay model multi-layering and inter-layer=20 >>>>> relationships are peripheral at best, it is all about horizontal=20 >>>>> network integration >>>>> >>>>> 5. The overlay model assumes one CP instance for the >>>> customer network >>>>> and a separate instance for the provider network and in the CE-PE=20 >>>>> interface case the provider network also surreptitiously >>>> participates >>>>> in the customer network by injecting virtual topology >>>> information into >>>>> it. >>>>> >>>> >>>> We should ensure we're allowing for some of the existing/augmented=20 >>>> models that permit the transport of overlay information within the=20 >>>> provider's CP, e.g., rfc4364, 5195 and 5252. >>> >>> I'd say they should be already covered, but will double check >>> >> >> great. >> >>>> >>>>> 6. L1VPN (and LxVPN) in general is a type of service >>>> provided over the >>>>> CE-PE interface (it falls under the UNI case as no routing=20 >>>>> adjacency is in place between CE and PE). >>>>> >>>>> >>>>> + Advertisement models (to be detailed in dedicated >>>>> + document/documents) >>>>> The CE-PE interface in the overlay model context foresees >>>> two types of >>>>> advertisement models.(names still to be agreed) >>>>> >>>>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >>>> augmented by >>>>> a number of actived draft (references to various drafts to >>>> be added).=20 >>>>> The Augmented UNI is a particular type of CE-PE interface where=20 >>>>> only signaling messages are exchanged between CE and PE. >>>>> Messages from CE to PE can include a set of parameters to be used=20 >>>>> by the PE as path computation constraints when computing a path in=20 >>>>> the provider domain network, while messages from PE to CE can=20 >>>>> include a set of parameters qualifying the LSP being established,=20 >>>>> like for example SRLG, delay, loss etc. >>>>> >>>> >>>> again, we can leverage 4874 terminology if we so choose, i.e.,=20 >>>> "basic mode" and "enhanced mode" UNI|NNI >>> >>> Don would be happy about that :-). I'd say yes. The goal was to=20 >>> cover the L1VPN work (enhanced mode), all the drafts-ali recently=20 >>> polled for wg adoption (basic mode?) and the actual ENNI (enhanced mode= ). >> >>> Is my mapping in brackets correct? >>> >> >> Not sure f I'd break it down they way you are. I'd say basic mode is cl= oser to the typical UNI and enhance mode is UNI+routing or perhaps even an = ENNI. >> >>> >>>> >>>>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >>>>> called with the general CE-PE interface term?) allowing the=20 >>>>> establishment of signaling and routing adjacency between CE and PE. >>>>> Routing info passed from PE to CE comprise overlay topology=20 >>>>> information including (but not limited to) virtual links, >>>> connectivity >>>>> matrices and access links with parameters qualifying each of them=20 >>>>> in terms of e.g. SRLG, loss, delay etc. Signaling information and=20 >>>>> procedures are compliant with RFC4208. >>>>> >>>> >>>> so this is just and 4874 "enhanced mode" interface, right. >>> >>> Good question: the enhanced mode supports signaling and routing, so=20 >>> i'd say yes, but reading section 7.3 it talks about "limited=20 >>> exchange of information between the control planes. >>> >>> "permits limited exchange of >>> information between the control planes of the provider and the >>> customer to help such functions as discovery of customer network >>> routing information (i.e., reachability or TE information in remote >>> customer sites), or parameters of the part of the provider's network >>> dedicated to the customer." >>> >>> Would you say this includes what we want? (i.e. Virtual links,=20 >>> virtual nodes, connectivity matrices, SRLG, delay, loss, etc) If yes=20 >>> we're done, otherwise an option could be the denition of a third VPN=20 >>> service model. >>> >> >> humm, need to think about this. Perhaps the best thing is to=20 >> document the two different cases and then decide if we have something=20 >> new or >> (two) more detailed forms of something old. >> >>>> >>>>> + Open issues/questions >>>>> 1. PCE-PCEP - do we need to include considerations about PCE >>>> and PCEP >>>>> into the overlay framework context? >>>>> >>>>> 2. BGP-LS needs to be considered >>>>> 3. Should potentials be included? E.g. I2RS? >>>>> 4. Virtual links: wouldn't a different definition of virtual links=20 >>>>> avoid the advertisement of connectivity matrices (this is out of=20 >>>>> the fwk scope but within the advertisement models one)? >>>>> >>>> >>>>> Take this example: >>>>> PE1-----CE1 CE2-----PE2 >>>>> CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>>>> CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>>> >>>> I think you've reversed CE and PE here... >>> >>> Yes, once again. >>> >>> No comment on my foolish proposal? >>> >> >> Which one? I liked your summary overall. >> >> Lou >> >>> >>>> >>>> Much thanks! >>>> >>>> Lou >>>> (hatless...) >>>> >>>>> i.e. There are 2 VL connecting CE1 and CE2 that could be >>>> available for >>>>> PE1 and PE2 to set up an adjacency in the customer domain.=20 >>>> CE1 and/or >>>>> CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>>>> depending on the connectivity matrices of CE1 and CE2. Hence >>>> PEs need >>>>> to be aware of both VL and connectivity matrices. My point >>>> is: if CE1 >>>>> advertises to PE1 only the VL that his connectivity matrix allows=20 >>>>> to be connected to PE1 (e.g. VL1 only) and not all of them, it >>>> should be >>>>> possible to avoid the connectivity matrices advertisement. >>>>> >>>> >>>>> =20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> DANIELE CECCARELLI >>>>> System & Technology - PDU Optical & Metro >>>>> >>>>> Via E.Melen, 77 >>>>> Genova, Italy >>>>> Phone +390106002512 >>>>> Mobile +393346725750 >>>>> daniele.ceccarelli@ericsson.com >>>>> www.ericsson.com >>>>> >>>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> >=20 >=20 >=20 >=20 From lberger@labn.net Tue Jan 22 08:51:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9993E21F8A5E for ; Tue, 22 Jan 2013 08:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.188 X-Spam-Level: X-Spam-Status: No, score=-101.188 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_62=0.6, 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 ALGR3oU9w7pg for ; Tue, 22 Jan 2013 08:51:22 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id D22B721F8A54 for ; Tue, 22 Jan 2013 08:51:22 -0800 (PST) Received: (qmail 1151 invoked by uid 0); 22 Jan 2013 16:51:01 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 22 Jan 2013 16:51:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=qoVp043rdX+/Y/Y8eScoT1W02mrCjb2HpLxVt+mDiLI=; b=usebcbnwtzgpV6eh6CLdKXzjHt0WN5a55kEckneCUMN/CDf/HE2VJT/8+W50r6tuTYROv74Vwx31z9FzHZKlxIRYR6wU5dGOqiQkcr20tJd+S38vxJnG2r791he7RyAu; Received: from box313.bluehost.com ([69.89.31.113]:39683 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Txh3t-0001tF-5Z; Tue, 22 Jan 2013 09:51:01 -0700 Message-ID: <50FEC37F.8090605@labn.net> Date: Tue, 22 Jan 2013 11:51:11 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John E Drake References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:51:23 -0000 >From my perspective, at a high-level the discussion is really about how best to revise/update MLN(MRN) to align with current (and desired) usage. Lou On 1/22/2013 11:38 AM, John E Drake wrote: > Lou, > > Snipped. I think this discussion is pointing out that we may be having charter creep in the sense that we are starting to impinge upon the work of the L3/L2 VPN and MPLS WGs. > > I am also having a hard time remembering what problem we are trying to solve. We have been through enhancements to the overlay model, the GMPLS ENNI, and enhancements to virtual links, as well as one or two I have probably forgotten. > > Irrespectively Yours, > > John > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Lou Berger >> Sent: Tuesday, January 22, 2013 7:51 AM >> To: Igor Bryskin >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Igor, >> >> see below. >> >> On 1/22/2013 10:05 AM, Igor Bryskin wrote: >>> Lou and Daniele, >>> Please, see my comments in-line, >>> >>> Cheers, >>> Igor >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> Behalf >>> Of Lou Berger >>> Sent: Monday, January 21, 2013 5:13 PM >>> To: Daniele Ceccarelli >>> Cc: CCAMP >>> Subject: Re: [CCAMP] Overlay model framework v2 >>> >>> Thanks Daniele, See below. >>> >>> On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: >>>> Hi Lou, >>>> >>>> Please find comments in line >>>> >>>> BR >>>> Daniele >>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: venerd 18 gennaio 2013 18.27 >>>>> To: Daniele Ceccarelli >>>>> Cc: CCAMP >>>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>>> >>>>> Daniele, >>>>> Very nice summary. Just catching up, so sorry for the >>>>> (2 day) late response. >>>>> >>>>> I really like how the terminology has evolved and appreciate the >>>>> summary! >>>>> >>>>> I have a few detail comments, but before I go there I'd like to >>>>> cover one more open issue that I think will have some >>>>> (minor) ripple effects on the details. >>>>> >>>>> I think there's still the general issue of terminology to use when >>>>> referring to the entity that "uses an overlay" and the entity that >>>>> "instantiates the overlay". In your mail and in discussion we >> have: >>>>> >>>>> - client (service)/OC/CN/customer >>>>> >>>>> and >>>>> >>>>> - server(or service)/OE/EN/provider >>>>> >>>>> I think we had discussed, and possibly agreed on, using VPN >>>>> terminology which would have us use the latter options, i.e., >>>>> (overlay) customer/provider (edge). This would mean eliminating >> any >>>>> references to client/server in the *generic >>>>> overlay* definitions. Of course these terms may reemerge in other >>>>> contexts as they have before, e.g., rfc6215. >>>> >>>> Yes, i think we all agreed. If there are still terms different from >>>> customer/provider in the text it's because i missed them during the >>>> replacing. >>>> >>> >>> Great! Glad I didn't miss something over the holidays! >>> >>> IB>> I personally have no problems with the VPN terminology. However, >>> IMO the terminology should be aligned with the RFC 4208 and George's >>> drafts. >> >> My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped >> to encompass the broad spectrum of overlays that are/have been >> discussed. >> >>> One cannot use different terminology within the same framework, >> right? >> >> Unfortunately we have no shortage of terminology defining (perhaps >> different flavors) of the same thing! >> >>> Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. >> >> While I certainly agree that not all overlays need be VPNs, it seems to >> me that our discussions are best aligned with that set of terminology, >> and that UNI/ENNI can be described within the CE/PE/VN/VL/VT >> constructs. >> Perhaps with some tweaking in some cases. >> >> >>> The most important goal is to provide a solution for inter-domain >>> horizontal integration between networks with possibly different >>> switching technologies and independent addressing within the overlay >>> model. >>> >> >> Sure. It's also possible that an overlay will use the same switching >> technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably >> less likely) the same address space (if a provider so chooses). >> > > > > > From IBryskin@advaoptical.com Tue Jan 22 09:07:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB84621F8415 for ; Tue, 22 Jan 2013 09:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, J_CHICKENPOX_62=0.6] 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 4I5FrJfoWzlv for ; Tue, 22 Jan 2013 09:07:21 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id AC52121F84E6 for ; Tue, 22 Jan 2013 09:07:20 -0800 (PST) Received: from MUC-SRV-MBX1.advaoptical.com ([172.20.1.95]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0MH7H4m008301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jan 2013 18:07:17 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.516.32; Tue, 22 Jan 2013 18:07:16 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Tue, 22 Jan 2013 12:07:15 -0500 From: Igor Bryskin To: Lou Berger , John E Drake Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBzClcAAJEUjQAAD8STgAAXoD7AAA1TKgAAAa8XgAAAbWCAAAoY4YA= Date: Tue, 22 Jan 2013 17:07:14 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> In-Reply-To: <50FEC37F.8090605@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-22_07:2013-01-22, 2013-01-22, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 17:07:26 -0000 I was about to commend you on having stopped referring to MLN/MRN. I was wr= ong and I agree with John that we are basically quite lost in this discussi= on and may be should drop it precisely to not produce another framework as = useful as MLN/MRN. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, January 22, 2013 11:51 AM To: John E Drake Cc: Igor Bryskin; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George Swall= ow (swallow)' Subject: Re: [CCAMP] Overlay model framework v2 >From my perspective, at a high-level the discussion is really about how bes= t to revise/update MLN(MRN) to align with current (and desired) usage. Lou On 1/22/2013 11:38 AM, John E Drake wrote: > Lou, >=20 > Snipped. I think this discussion is pointing out that we may be having c= harter creep in the sense that we are starting to impinge upon the work of = the L3/L2 VPN and MPLS WGs. >=20 > I am also having a hard time remembering what problem we are trying to so= lve. We have been through enhancements to the overlay model, the GMPLS ENN= I, and enhancements to virtual links, as well as one or two I have probably= forgotten. >=20 > Irrespectively Yours, >=20 > John >=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> Behalf Of Lou Berger >> Sent: Tuesday, January 22, 2013 7:51 AM >> To: Igor Bryskin >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Igor, >> >> see below. >> >> On 1/22/2013 10:05 AM, Igor Bryskin wrote: >>> Lou and Daniele, >>> Please, see my comments in-line, >>> >>> Cheers, >>> Igor >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> Behalf >>> Of Lou Berger >>> Sent: Monday, January 21, 2013 5:13 PM >>> To: Daniele Ceccarelli >>> Cc: CCAMP >>> Subject: Re: [CCAMP] Overlay model framework v2 >>> >>> Thanks Daniele, See below. >>> >>> On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: >>>> Hi Lou, >>>> >>>> Please find comments in line >>>> >>>> BR >>>> Daniele >>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: venerd=EC 18 gennaio 2013 18.27 >>>>> To: Daniele Ceccarelli >>>>> Cc: CCAMP >>>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>>> >>>>> Daniele, >>>>> Very nice summary. Just catching up, so sorry for the >>>>> (2 day) late response. >>>>> >>>>> I really like how the terminology has evolved and appreciate the=20 >>>>> summary! >>>>> >>>>> I have a few detail comments, but before I go there I'd like to=20 >>>>> cover one more open issue that I think will have some >>>>> (minor) ripple effects on the details. >>>>> >>>>> I think there's still the general issue of terminology to use when=20 >>>>> referring to the entity that "uses an overlay" and the entity that=20 >>>>> "instantiates the overlay". In your mail and in discussion we >> have: >>>>> >>>>> - client (service)/OC/CN/customer >>>>> >>>>> and >>>>> >>>>> - server(or service)/OE/EN/provider >>>>> >>>>> I think we had discussed, and possibly agreed on, using VPN=20 >>>>> terminology which would have us use the latter options, i.e., >>>>> (overlay) customer/provider (edge). This would mean eliminating >> any >>>>> references to client/server in the *generic >>>>> overlay* definitions. Of course these terms may reemerge in other=20 >>>>> contexts as they have before, e.g., rfc6215. >>>> >>>> Yes, i think we all agreed. If there are still terms different from=20 >>>> customer/provider in the text it's because i missed them during the=20 >>>> replacing. >>>> >>> >>> Great! Glad I didn't miss something over the holidays! >>> >>> IB>> I personally have no problems with the VPN terminology.=20 >>> IB>> However, >>> IMO the terminology should be aligned with the RFC 4208 and George's=20 >>> drafts. >> >> My issue with 4208 is that UNI (and ENNI) are just too narrowly=20 >> scoped to encompass the broad spectrum of overlays that are/have been=20 >> discussed. >> >>> One cannot use different terminology within the same framework, >> right? >> >> Unfortunately we have no shortage of terminology defining (perhaps=20 >> different flavors) of the same thing! >> >>> Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. >> >> While I certainly agree that not all overlays need be VPNs, it seems=20 >> to me that our discussions are best aligned with that set of=20 >> terminology, and that UNI/ENNI can be described within the=20 >> CE/PE/VN/VL/VT constructs. >> Perhaps with some tweaking in some cases. >> >> >>> The most important goal is to provide a solution for inter-domain=20 >>> horizontal integration between networks with possibly different=20 >>> switching technologies and independent addressing within the overlay=20 >>> model. >>> >> >> Sure. It's also possible that an overlay will use the same switching=20 >> technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but=20 >> probably less likely) the same address space (if a provider so chooses). >> >=20 >=20 >=20 >=20 >=20 From lberger@labn.net Tue Jan 22 09:31:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C1121F8800 for ; Tue, 22 Jan 2013 09:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_62=0.6, 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 xlQwaKwz1rxM for ; Tue, 22 Jan 2013 09:31:33 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 4C97121F84D9 for ; Tue, 22 Jan 2013 09:31:33 -0800 (PST) Received: (qmail 15338 invoked by uid 0); 22 Jan 2013 17:31:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 22 Jan 2013 17:31:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=crefSFNQ1tdfD1PS7WI+Ibg62Pc17da/ak5mTyHcUWE=; b=bz9UnFq6KzzXtBpRQ21CU6R+NGqpQuju67YY8Cu65lrDty149dI5nGryItK/wBxkqYhAyEtkr4sdBizt0M2LT8bHcEpm22UU4b2HVR1rKvpZbstjdLiUpJmA48MChhNU; Received: from pool-108-28-89-162.washdc.fios.verizon.net ([108.28.89.162]:50254 helo=[127.0.0.1]) by box313.bluehost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1Txhgk-000429-Fa; Tue, 22 Jan 2013 10:31:10 -0700 From: Lou Berger To: Igor Bryskin , John E Drake Date: Tue, 22 Jan 2013 12:31:09 -0500 Message-ID: <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.2.1.2 (build: 2100174) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 108.28.89.162 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 17:31:34 -0000 Igor, Sorry to disappoint. I still see a relationship whether we reuse the terminology or not. I suspect that I am not alone in this. Lou On January 22, 2013 12:07:14 PM Igor Bryskin wrote: > I was about to commend you on having stopped referring to MLN/MRN. I > was wrong and I agree with John that we are basically quite lost in > this discussion and may be should drop it precisely to not produce > another framework as useful as MLN/MRN. > > Igor > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, January 22, 2013 11:51 AM > To: John E Drake > Cc: Igor Bryskin; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George > Swallow (swallow)' > Subject: Re: [CCAMP] Overlay model framework v2 > > From my perspective, at a high-level the discussion is really about how > best to revise/update MLN(MRN) to align with current (and desired) usage. > > Lou > > On 1/22/2013 11:38 AM, John E Drake wrote: > > Lou, > > > > Snipped. I think this discussion is pointing out that we may be > having charter creep in the sense that we are starting to impinge upon > the work of the L3/L2 VPN and MPLS WGs. > > > > I am also having a hard time remembering what problem we are trying > to solve. We have been through enhancements to the overlay model, the > GMPLS ENNI, and enhancements to virtual links, as well as one or two I > have probably forgotten. > > > > Irrespectively Yours, > > > > John > > > >> -----Original Message----- > >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >> Behalf Of Lou Berger > >> Sent: Tuesday, January 22, 2013 7:51 AM > >> To: Igor Bryskin > >> Cc: CCAMP > >> Subject: Re: [CCAMP] Overlay model framework v2 > >> > >> Igor, > >> > >> see below. > >> > >> On 1/22/2013 10:05 AM, Igor Bryskin wrote: > >>> Lou and Daniele, > >>> Please, see my comments in-line, > >>> > >>> Cheers, > >>> Igor > >>> > >>> -----Original Message----- > >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >> Behalf > >>> Of Lou Berger > >>> Sent: Monday, January 21, 2013 5:13 PM > >>> To: Daniele Ceccarelli > >>> Cc: CCAMP > >>> Subject: Re: [CCAMP] Overlay model framework v2 > >>> > >>> Thanks Daniele, See below. > >>> > >>> On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: > >>>> Hi Lou, > >>>> > >>>> Please find comments in line > >>>> > >>>> BR > >>>> Daniele > >>>> > >>>>> -----Original Message----- > >>>>> From: Lou Berger [mailto:lberger@labn.net] > >>>>> Sent: venerd矛 18 gennaio 2013 18.27 > >>>>> To: Daniele Ceccarelli > >>>>> Cc: CCAMP > >>>>> Subject: Re: [CCAMP] Overlay model framework v2 > >>>>> > >>>>> Daniele, > >>>>> Very nice summary. Just catching up, so sorry for the > >>>>> (2 day) late response. > >>>>> > >>>>> I really like how the terminology has evolved and appreciate the > >>>>> summary! > >>>>> > >>>>> I have a few detail comments, but before I go there I'd like to > >>>>> cover one more open issue that I think will have some > >>>>> (minor) ripple effects on the details. > >>>>> > >>>>> I think there's still the general issue of terminology to use when > >>>>> referring to the entity that "uses an overlay" and the entity that > >>>>> "instantiates the overlay". In your mail and in discussion we > >> have: > >>>>> > >>>>> - client (service)/OC/CN/customer > >>>>> > >>>>> and > >>>>> > >>>>> - server(or service)/OE/EN/provider > >>>>> > >>>>> I think we had discussed, and possibly agreed on, using VPN > >>>>> terminology which would have us use the latter options, i.e., > >>>>> (overlay) customer/provider (edge). This would mean eliminating > >> any > >>>>> references to client/server in the *generic > >>>>> overlay* definitions. Of course these terms may reemerge in other > >>>>> contexts as they have before, e.g., rfc6215. > >>>> > >>>> Yes, i think we all agreed. If there are still terms different from > >>>> customer/provider in the text it's because i missed them during the > >>>> replacing. > >>>> > >>> > >>> Great! Glad I didn't miss something over the holidays! > >>> > >>> IB>> I personally have no problems with the VPN terminology. > >>> IB>> However, > >>> IMO the terminology should be aligned with the RFC 4208 and George's > >>> drafts. > >> > >> My issue with 4208 is that UNI (and ENNI) are just too narrowly > >> scoped to encompass the broad spectrum of overlays that are/have been > >> discussed. > >> > >>> One cannot use different terminology within the same framework, > >> right? > >> > >> Unfortunately we have no shortage of terminology defining (perhaps > >> different flavors) of the same thing! > >> > >>> Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. > >> > >> While I certainly agree that not all overlays need be VPNs, it seems > >> to me that our discussions are best aligned with that set of > >> terminology, and that UNI/ENNI can be described within the > >> CE/PE/VN/VL/VT constructs. > >> Perhaps with some tweaking in some cases. > >> > >> > >>> The most important goal is to provide a solution for inter-domain > >>> horizontal integration between networks with possibly different > >>> switching technologies and independent addressing within the overlay > >>> model. > >>> > >> > >> Sure. It's also possible that an overlay will use the same switching > >> technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but > >> probably less likely) the same address space (if a provider so chooses). > >> > > > > > > > > > > > From jdrake@juniper.net Tue Jan 22 10:00:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAD621F8A03 for ; Tue, 22 Jan 2013 10:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 ACaTjzoQhpug for ; Tue, 22 Jan 2013 10:00:02 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5313721F8A05 for ; Tue, 22 Jan 2013 10:00:02 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUP7Top2ASAIVARGvJikbl2+YpNBUnCjM@postini.com; Tue, 22 Jan 2013 10:00:02 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 22 Jan 2013 08:39:13 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 22 Jan 2013 08:39:12 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.181) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 22 Jan 2013 08:41:41 -0800 Received: from mail83-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 22 Jan 2013 16:39:05 +0000 Received: from mail83-ch1 (localhost [127.0.0.1]) by mail83-ch1-R.bigfish.com (Postfix) with ESMTP id C81312C01F1 for ; Tue, 22 Jan 2013 16:39:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371Ic89bh542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail83-ch1 (localhost.localdomain [127.0.0.1]) by mail83-ch1 (MessageSwitch) id 135887274393376_15156; Tue, 22 Jan 2013 16:39:03 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail83-ch1.bigfish.com (Postfix) with ESMTP id 08DB9440252; Tue, 22 Jan 2013 16:39:03 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 22 Jan 2013 16:39:01 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.12]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0257.004; Tue, 22 Jan 2013 16:38:58 +0000 From: John E Drake To: Lou Berger , Igor Bryskin Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBokCIAAJEUjAAAD8STgAAjXhkAAAGVTwAAAW6bkA== Date: Tue, 22 Jan 2013 16:38:57 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> In-Reply-To: <50FEB554.6010907@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:00:03 -0000 Lou, Snipped. I think this discussion is pointing out that we may be having cha= rter creep in the sense that we are starting to impinge upon the work of th= e L3/L2 VPN and MPLS WGs. I am also having a hard time remembering what problem we are trying to solv= e. We have been through enhancements to the overlay model, the GMPLS ENNI,= and enhancements to virtual links, as well as one or two I have probably f= orgotten. Irrespectively Yours, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Tuesday, January 22, 2013 7:51 AM > To: Igor Bryskin > Cc: CCAMP > Subject: Re: [CCAMP] Overlay model framework v2 >=20 > Igor, >=20 > see below. >=20 > On 1/22/2013 10:05 AM, Igor Bryskin wrote: > > Lou and Daniele, > > Please, see my comments in-line, > > > > Cheers, > > Igor > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Lou Berger > > Sent: Monday, January 21, 2013 5:13 PM > > To: Daniele Ceccarelli > > Cc: CCAMP > > Subject: Re: [CCAMP] Overlay model framework v2 > > > > Thanks Daniele, See below. > > > > On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: > >> Hi Lou, > >> > >> Please find comments in line > >> > >> BR > >> Daniele > >> > >>> -----Original Message----- > >>> From: Lou Berger [mailto:lberger@labn.net] > >>> Sent: venerd=EC 18 gennaio 2013 18.27 > >>> To: Daniele Ceccarelli > >>> Cc: CCAMP > >>> Subject: Re: [CCAMP] Overlay model framework v2 > >>> > >>> Daniele, > >>> Very nice summary. Just catching up, so sorry for the > >>> (2 day) late response. > >>> > >>> I really like how the terminology has evolved and appreciate the > >>> summary! > >>> > >>> I have a few detail comments, but before I go there I'd like to > >>> cover one more open issue that I think will have some > >>> (minor) ripple effects on the details. > >>> > >>> I think there's still the general issue of terminology to use when > >>> referring to the entity that "uses an overlay" and the entity that > >>> "instantiates the overlay". In your mail and in discussion we > have: > >>> > >>> - client (service)/OC/CN/customer > >>> > >>> and > >>> > >>> - server(or service)/OE/EN/provider > >>> > >>> I think we had discussed, and possibly agreed on, using VPN > >>> terminology which would have us use the latter options, i.e., > >>> (overlay) customer/provider (edge). This would mean eliminating > any > >>> references to client/server in the *generic > >>> overlay* definitions. Of course these terms may reemerge in other > >>> contexts as they have before, e.g., rfc6215. > >> > >> Yes, i think we all agreed. If there are still terms different from > >> customer/provider in the text it's because i missed them during the > >> replacing. > >> > > > > Great! Glad I didn't miss something over the holidays! > > > > IB>> I personally have no problems with the VPN terminology. However, > > IMO the terminology should be aligned with the RFC 4208 and George's > > drafts. >=20 > My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped > to encompass the broad spectrum of overlays that are/have been > discussed. >=20 > > One cannot use different terminology within the same framework, > right? >=20 > Unfortunately we have no shortage of terminology defining (perhaps > different flavors) of the same thing! >=20 > > Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. >=20 > While I certainly agree that not all overlays need be VPNs, it seems to > me that our discussions are best aligned with that set of terminology, > and that UNI/ENNI can be described within the CE/PE/VN/VL/VT > constructs. > Perhaps with some tweaking in some cases. >=20 >=20 > > The most important goal is to provide a solution for inter-domain > > horizontal integration between networks with possibly different > > switching technologies and independent addressing within the overlay > > model. > > >=20 > Sure. It's also possible that an overlay will use the same switching > technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably > less likely) the same address space (if a provider so chooses). >=20 From lberger@labn.net Tue Jan 22 10:11:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFCC21F8A6F for ; Tue, 22 Jan 2013 10:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.968 X-Spam-Level: X-Spam-Status: No, score=-100.968 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 PMCtIHDPRhjB for ; Tue, 22 Jan 2013 10:11:27 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id B3FB721F8A42 for ; Tue, 22 Jan 2013 10:11:27 -0800 (PST) Received: (qmail 1637 invoked by uid 0); 22 Jan 2013 18:11:05 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 22 Jan 2013 18:11:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=epNZGOwcE4HvKZn//49Y4AUHQ83uebaIiQ5V2uR7A74=; b=wTuMGxjbn3Dygv+mOpVyrFHRFy+A1UIIviAEIafXXBXBU2o2pU9IAOrqTrWtUgbsq5iE+ock//klsO1zQVsnMF2mCLlb33QpHfgs/gaPpToINovoUnEeaUehwzz8VU94; Received: from box313.bluehost.com ([69.89.31.113]:51093 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TxiJM-000663-WF; Tue, 22 Jan 2013 11:11:05 -0700 Message-ID: <50FED643.6020708@labn.net> Date: Tue, 22 Jan 2013 13:11:15 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fatai Zhang References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> <50F58A35.7040806@labn.net> <50F837FB.2010806@labn.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:11:34 -0000 Fatai, On 1/20/2013 9:43 PM, Fatai Zhang wrote: > Hi Lou, > > You said: >> but you're says encoded as (N*Nominal Rate) right? Wat's the value of this vs just carrying N? > > [Fatai] The original way (in version 04&05) is putting (N* Nominal > Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can > generalize to just use one single "Bit_Rate" field to carry IEEE > float number for both cases, it seems that you don't agree on this > value, :-) I've seen differences in calculated floating point values from different implementations, so I just want to ensure that such cases are avoided. I'm open to specific solutions and certainly will deffer on the specifics assuming there is no opportunity for misinterpretation/interop issues. I don't think the original passed this threshold, i.e.,: N = Ceiling of ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) --------------------------------------------------------------------- ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) > . Therefore, I (was) am saying that I am going to accept > your suggestion to carry N for ODUflex(GFP). We are discussing where > to put N for ODUflex(GFP). > > You said: >> bits in the control plane are generally cheap, IMO it's better to have simpler encoding than to optimize every bit (or 8 in this case). > > [Fatai] OK, I will add a new field (to occupy the reserved bits) to carry N. As you see fit. Just to clarify my understanding, ODUflex and Virtual concatenation can never be combined for the same signal type/level, right? (Although an ODUflex client signal could be carried over a virtual concatenated ODUk). Is this correct or did I miss something in G709? Thanks, Lou > > > > Best Regards > > Fatai > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, January 18, 2013 1:42 AM > To: Fatai Zhang > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 > > > > On 1/15/2013 10:16 PM, Fatai Zhang wrote: >> Hi Lou, >> >> To avoid misunderstanding, I would like to clarify more on the >> following point. >> >> >>>>>> It is better to have consistent format and the same meaning of one > field for both ODUflex(CBR) and GFP. This is why we have section 5.1 > &5.2 to describe the complex stuff. >>>>> I actually wasn't suggesting that N be carried in the bit rate field. >>>>> The bit rate field can either be set as described or to zero (i.e., >>>>> ignored). At the time, I was thinking about carrying N in the reserved >>>>> field. But perhaps the right place is MT, if my understanding is right >>>>> (would always be 1 otherwise). I'm open to either... >>>>> >>>> [Fatai] Why not just use "bit rate"field to carry "N"because "N" >>>> implies bit rate? I am OK if you like to use a new filed (like "TS >>>> Number") to occupy the reserved field even though that I prefer the >>>> original approach (ie., use "bit rate"field to carry "N"). >>> >>> Are you proposing dropping carrying bit rates represented as an IEEE >>> floating point and just carrying N for ODUflex? This seems workable to >>> me, but we should ensure that there are no significant objections. >> >> [Fatai] There are two usages for " Bit_Rate " field as described in the >> lines 287-310. >> >> (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal bit >> rate of ODUflex(CBR) expressed in bytes per second, encoded as a 32-bit >> IEEE single precision floating-point number. For this case, we MUST use >> 32-bit IEEE floating point instead of "N"(Please see more in section 5.1). > > I guess you really still need (to be based on) the client signal rate at > the edges. > >> >> (2) For ODUflex(GFP), we can change the text (the lines from 305 to >> 310) based on your suggestion, ie., the Bit_Rate field is used to carry >> "N"to indicate the nominal bit rate of the >> ODUflex(GFP). > > but you're says encoded as (N*Nominal Rate) right? Wat's the value of > this vs just carrying N? > > >> >> Therefore, I am proposing using one single filed ("Bit_Rate ") for these >> two cases, in this way, we can leave the "Reserved" bits for future. > > bits in the control plane are generally cheap, IMO it's better to have > simpler encoding than to optimize every bit (or 8 in this case). > > Lou > >> >> Hope we are now at the same page. >> >> >> Best Regards >> >> Fatai > > > > From IBryskin@advaoptical.com Tue Jan 22 10:58:53 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDA221F87B6 for ; Tue, 22 Jan 2013 10:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, J_CHICKENPOX_62=0.6] 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 8Su+F3uGiwHj for ; Tue, 22 Jan 2013 10:58:53 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 61C5621F8A45 for ; Tue, 22 Jan 2013 10:58:51 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0MIwiNI016668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jan 2013 19:58:44 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Tue, 22 Jan 2013 19:58:44 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Tue, 22 Jan 2013 13:58:42 -0500 From: Igor Bryskin To: Lou Berger , John E Drake Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBzClcAAJEUjQAAD8STgAAXoD7AAA1TKgAAAa8XgAAAbWCAAAoY4YD//7pjgIAAQYOQ Date: Tue, 22 Jan 2013 18:58:42 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-22_07:2013-01-22, 2013-01-22, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:58:53 -0000 TG91LA0KDQpBdCBteSBob21lIHdlIGhhdmUgYSBydWxlOiBpZiBzb21ldGhpbmcgaXMgbm90IGJl aW5nIHVzZWQgZm9yIG9uZSB5ZWFyLCBpdCBpcyBwcm9ub3VuY2VkICB0cmFzaCB0aGF0IGlzIHVu bGlrZWx5IHRvIGJlIGV2ZXIgdXNlZCwgd2hpY2ggaXMganVzdCB0YWtpbmcgc3BhY2Ugb2Ygc29t ZXRoaW5nIGJldHRlciBhbmQgbW9yZSBjb250ZW1wb3JhcnkgYW5kIGhlbmNlIG11c3QgYmUgdGhy b3duIGF3YXkuICBTbyBJIHN1Z2dlc3QgaW1wbGVtZW50aW5nIHRoZSBzYW1lIG9yIHNpbWlsYXIg cnVsZSBpbiBvdXIgQ0NBTVAgaG9tZTogIGxldCdzIG1ha2UgYW4gaW52ZW50b3J5IG9mIGV4aXN0 aW5nIENDQU1QIFJGQ3MgYW5kIHRocm93IGF3YXkgdGhvc2UgdGhhdCBoYXZlIG5ldmVyIHNlZW4g YW55IGludGVyb3BlcmFiaWxpdHkgdGVzdHMgYW5kIHdlcmUgbmV2ZXIgcGFydCBvZiBhbnkgcHJv ZHVjdCBvciBzb2x1dGlvbi4NCg0KQmVzaWRlcywgSSBiZWxpZXZlIG5vdGhpbmcgKHRlcm1pbm9s b2d5LCBhcmNoaXRlY3R1cmUsICBwcm90b2NvbCBzb2x1dGlvbnMsIGV0Yy4pICBvZiBNTE4vTVJO IGlzIHJlbGV2YW50IHRvIHdoYXQgd2UgYXJlL3dlcmUgdHJ5aW5nIHRvIGFjaGlldmUgd2l0aCBP TlRzLiANCg0KSWdvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG91IEJl cmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0KU2VudDogVHVlc2RheSwgSmFudWFyeSAy MiwgMjAxMyAxMjozMSBQTQ0KVG86IElnb3IgQnJ5c2tpbjsgSm9obiBFIERyYWtlDQpDYzogQ0NB TVA7IFN0ZXdhcnQgQnJ5YW50OyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyAnR2VvcmdlIFN3YWxsb3cg KHN3YWxsb3cpJw0KU3ViamVjdDogUkU6IFtDQ0FNUF0gT3ZlcmxheSBtb2RlbCBmcmFtZXdvcmsg djINCg0KSWdvciwNCg0KU29ycnkgdG8gZGlzYXBwb2ludC4gSSBzdGlsbCBzZWUgYSByZWxhdGlv bnNoaXAgd2hldGhlciB3ZSByZXVzZSB0aGUgdGVybWlub2xvZ3kgb3Igbm90LiBJIHN1c3BlY3Qg dGhhdCBJIGFtIG5vdCBhbG9uZSBpbiB0aGlzLg0KDQpMb3UNCg0KDQoNCk9uIEphbnVhcnkgMjIs IDIwMTMgMTI6MDc6MTQgUE0gSWdvciBCcnlza2luIDxJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb20+ IHdyb3RlOg0KPiBJIHdhcyBhYm91dCB0byBjb21tZW5kIHlvdSBvbiBoYXZpbmcgc3RvcHBlZCBy ZWZlcnJpbmcgdG8gTUxOL01STi4gSSANCj4gd2FzIHdyb25nIGFuZCBJIGFncmVlIHdpdGggSm9o biB0aGF0IHdlIGFyZSBiYXNpY2FsbHkgcXVpdGUgbG9zdCBpbiANCj4gdGhpcyBkaXNjdXNzaW9u IGFuZCBtYXkgYmUgc2hvdWxkIGRyb3AgaXQgcHJlY2lzZWx5IHRvIG5vdCBwcm9kdWNlIA0KPiBh bm90aGVyIGZyYW1ld29yayBhcyB1c2VmdWwgYXMgTUxOL01STi4NCj4NCj4gSWdvcg0KPg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJl cmdlckBsYWJuLm5ldF0NCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyMiwgMjAxMyAxMTo1MSBB TQ0KPiBUbzogSm9obiBFIERyYWtlDQo+IENjOiBJZ29yIEJyeXNraW47IENDQU1QOyBTdGV3YXJ0 IEJyeWFudDsgYWRyaWFuQG9sZGRvZy5jby51azsgJ0dlb3JnZSANCj4gU3dhbGxvdyAoc3dhbGxv dyknDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIE92ZXJsYXkgbW9kZWwgZnJhbWV3b3JrIHYyDQo+ DQo+IEZyb20gbXkgcGVyc3BlY3RpdmUsIGF0IGEgaGlnaC1sZXZlbCB0aGUgZGlzY3Vzc2lvbiBp cyByZWFsbHkgYWJvdXQgDQo+IGhvdyBiZXN0IHRvIHJldmlzZS91cGRhdGUgTUxOKE1STikgdG8g YWxpZ24gd2l0aCBjdXJyZW50IChhbmQgZGVzaXJlZCkgdXNhZ2UuDQo+DQo+IExvdQ0KPg0KPiBP biAxLzIyLzIwMTMgMTE6MzggQU0sIEpvaG4gRSBEcmFrZSB3cm90ZToNCj4gPiBMb3UsDQo+ID4N Cj4gPiBTbmlwcGVkLiAgSSB0aGluayB0aGlzIGRpc2N1c3Npb24gaXMgcG9pbnRpbmcgb3V0IHRo YXQgd2UgbWF5IGJlDQo+IGhhdmluZyBjaGFydGVyIGNyZWVwIGluIHRoZSBzZW5zZSB0aGF0IHdl IGFyZSBzdGFydGluZyB0byBpbXBpbmdlIHVwb24gDQo+IHRoZSB3b3JrIG9mIHRoZSBMMy9MMiBW UE4gYW5kIE1QTFMgV0dzLg0KPiA+DQo+ID4gSSBhbSBhbHNvIGhhdmluZyBhIGhhcmQgdGltZSBy ZW1lbWJlcmluZyB3aGF0IHByb2JsZW0gd2UgYXJlIHRyeWluZw0KPiB0byBzb2x2ZS4gIFdlIGhh dmUgYmVlbiB0aHJvdWdoIGVuaGFuY2VtZW50cyB0byB0aGUgb3ZlcmxheSBtb2RlbCwgdGhlIA0K PiBHTVBMUyBFTk5JLCBhbmQgZW5oYW5jZW1lbnRzIHRvIHZpcnR1YWwgbGlua3MsIGFzIHdlbGwg YXMgb25lIG9yIHR3byBJIA0KPiBoYXZlIHByb2JhYmx5IGZvcmdvdHRlbi4NCj4gPg0KPiA+IEly cmVzcGVjdGl2ZWx5IFlvdXJzLA0KPiA+DQo+ID4gSm9obg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4gPj4gQmVoYWxmIE9mIExvdSBCZXJnZXIN Cj4gPj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyMiwgMjAxMyA3OjUxIEFNDQo+ID4+IFRvOiBJ Z29yIEJyeXNraW4NCj4gPj4gQ2M6IENDQU1QDQo+ID4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIE92 ZXJsYXkgbW9kZWwgZnJhbWV3b3JrIHYyDQo+ID4+DQo+ID4+IElnb3IsDQo+ID4+DQo+ID4+IHNl ZSBiZWxvdy4NCj4gPj4NCj4gPj4gT24gMS8yMi8yMDEzIDEwOjA1IEFNLCBJZ29yIEJyeXNraW4g d3JvdGU6DQo+ID4+PiBMb3UgYW5kIERhbmllbGUsDQo+ID4+PiBQbGVhc2UsIHNlZSBteSBjb21t ZW50cyBpbi1saW5lLA0KPiA+Pj4NCj4gPj4+IENoZWVycywNCj4gPj4+IElnb3INCj4gPj4+DQo+ ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogY2NhbXAtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+IEJlaGFs Zg0KPiA+Pj4gT2YgTG91IEJlcmdlcg0KPiA+Pj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDIxLCAy MDEzIDU6MTMgUE0NCj4gPj4+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGkNCj4gPj4+IENjOiBDQ0FN UA0KPiA+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gT3ZlcmxheSBtb2RlbCBmcmFtZXdvcmsgdjIN Cj4gPj4+DQo+ID4+PiBUaGFua3MgRGFuaWVsZSwgU2VlIGJlbG93Lg0KPiA+Pj4NCj4gPj4+IE9u IDEvMjEvMjAxMyA5OjQxIEFNLCBEYW5pZWxlIENlY2NhcmVsbGkgd3JvdGU6DQo+ID4+Pj4gSGkg TG91LA0KPiA+Pj4+DQo+ID4+Pj4gUGxlYXNlIGZpbmQgY29tbWVudHMgaW4gbGluZQ0KPiA+Pj4+ DQo+ID4+Pj4gQlINCj4gPj4+PiBEYW5pZWxlDQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJA bGFibi5uZXRdDQo+ID4+Pj4+IFNlbnQ6IHZlbmVyZMOsIDE4IGdlbm5haW8gMjAxMyAxOC4yNw0K PiA+Pj4+PiBUbzogRGFuaWVsZSBDZWNjYXJlbGxpDQo+ID4+Pj4+IENjOiBDQ0FNUA0KPiA+Pj4+ PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBPdmVybGF5IG1vZGVsIGZyYW1ld29yayB2Mg0KPiA+Pj4+ Pg0KPiA+Pj4+PiBEYW5pZWxlLA0KPiA+Pj4+PiAJVmVyeSBuaWNlIHN1bW1hcnkuICBKdXN0IGNh dGNoaW5nIHVwLCBzbyBzb3JyeSBmb3IgdGhlDQo+ID4+Pj4+ICgyIGRheSkgbGF0ZSByZXNwb25z ZS4NCj4gPj4+Pj4NCj4gPj4+Pj4gSSByZWFsbHkgbGlrZSBob3cgdGhlIHRlcm1pbm9sb2d5IGhh cyBldm9sdmVkIGFuZCBhcHByZWNpYXRlIHRoZSANCj4gPj4+Pj4gc3VtbWFyeSENCj4gPj4+Pj4N Cj4gPj4+Pj4gSSBoYXZlIGEgZmV3IGRldGFpbCBjb21tZW50cywgYnV0IGJlZm9yZSBJIGdvIHRo ZXJlIEknZCBsaWtlIHRvIA0KPiA+Pj4+PiBjb3ZlciBvbmUgbW9yZSBvcGVuIGlzc3VlIHRoYXQg SSB0aGluayB3aWxsIGhhdmUgc29tZQ0KPiA+Pj4+PiAobWlub3IpIHJpcHBsZSBlZmZlY3RzIG9u IHRoZSBkZXRhaWxzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIHRoaW5rIHRoZXJlJ3Mgc3RpbGwgdGhl IGdlbmVyYWwgaXNzdWUgb2YgdGVybWlub2xvZ3kgdG8gdXNlIA0KPiA+Pj4+PiB3aGVuIHJlZmVy cmluZyB0byB0aGUgZW50aXR5IHRoYXQgInVzZXMgYW4gb3ZlcmxheSIgYW5kIHRoZSANCj4gPj4+ Pj4gZW50aXR5IHRoYXQgImluc3RhbnRpYXRlcyB0aGUgb3ZlcmxheSIuICBJbiB5b3VyIG1haWwg YW5kIGluIA0KPiA+Pj4+PiBkaXNjdXNzaW9uIHdlDQo+ID4+IGhhdmU6DQo+ID4+Pj4+DQo+ID4+ Pj4+IC0gY2xpZW50IChzZXJ2aWNlKS9PQy9DTi9jdXN0b21lcg0KPiA+Pj4+Pg0KPiA+Pj4+PiBh bmQNCj4gPj4+Pj4NCj4gPj4+Pj4gLSBzZXJ2ZXIob3Igc2VydmljZSkvT0UvRU4vcHJvdmlkZXIN Cj4gPj4+Pj4NCj4gPj4+Pj4gSSB0aGluayB3ZSBoYWQgZGlzY3Vzc2VkLCBhbmQgcG9zc2libHkg YWdyZWVkIG9uLCB1c2luZyBWUE4gDQo+ID4+Pj4+IHRlcm1pbm9sb2d5IHdoaWNoIHdvdWxkIGhh dmUgdXMgdXNlIHRoZSBsYXR0ZXIgb3B0aW9ucywgaS5lLiwNCj4gPj4+Pj4gKG92ZXJsYXkpIGN1 c3RvbWVyL3Byb3ZpZGVyIChlZGdlKS4gIFRoaXMgd291bGQgbWVhbiBlbGltaW5hdGluZw0KPiA+ PiBhbnkNCj4gPj4+Pj4gcmVmZXJlbmNlcyB0byBjbGllbnQvc2VydmVyIGluIHRoZSAqZ2VuZXJp Yw0KPiA+Pj4+PiBvdmVybGF5KiBkZWZpbml0aW9ucy4gIE9mIGNvdXJzZSB0aGVzZSB0ZXJtcyBt YXkgcmVlbWVyZ2UgaW4gDQo+ID4+Pj4+IG90aGVyIGNvbnRleHRzIGFzIHRoZXkgaGF2ZSBiZWZv cmUsIGUuZy4sIHJmYzYyMTUuDQo+ID4+Pj4NCj4gPj4+PiBZZXMsIGkgdGhpbmsgd2UgYWxsIGFn cmVlZC4gSWYgdGhlcmUgYXJlIHN0aWxsIHRlcm1zIGRpZmZlcmVudCANCj4gPj4+PiBmcm9tIGN1 c3RvbWVyL3Byb3ZpZGVyIGluIHRoZSB0ZXh0IGl0J3MgYmVjYXVzZSBpIG1pc3NlZCB0aGVtIA0K PiA+Pj4+IGR1cmluZyB0aGUgcmVwbGFjaW5nLg0KPiA+Pj4+DQo+ID4+Pg0KPiA+Pj4gR3JlYXQh ICBHbGFkIEkgZGlkbid0IG1pc3Mgc29tZXRoaW5nIG92ZXIgdGhlIGhvbGlkYXlzIQ0KPiA+Pj4N Cj4gPj4+IElCPj4gSSBwZXJzb25hbGx5IGhhdmUgbm8gcHJvYmxlbXMgd2l0aCB0aGUgVlBOIHRl cm1pbm9sb2d5Lg0KPiA+Pj4gSUI+PiBIb3dldmVyLA0KPiA+Pj4gSU1PIHRoZSB0ZXJtaW5vbG9n eSBzaG91bGQgYmUgYWxpZ25lZCB3aXRoIHRoZSBSRkMgNDIwOCBhbmQgDQo+ID4+PiBHZW9yZ2Un cyBkcmFmdHMuDQo+ID4+DQo+ID4+IE15IGlzc3VlIHdpdGggNDIwOCBpcyB0aGF0IFVOSSAoYW5k IEVOTkkpIGFyZSBqdXN0IHRvbyBuYXJyb3dseSANCj4gPj4gc2NvcGVkIHRvIGVuY29tcGFzcyB0 aGUgYnJvYWQgc3BlY3RydW0gb2Ygb3ZlcmxheXMgdGhhdCBhcmUvaGF2ZSANCj4gPj4gYmVlbiBk aXNjdXNzZWQuDQo+ID4+DQo+ID4+PiBPbmUgY2Fubm90IHVzZSBkaWZmZXJlbnQgdGVybWlub2xv Z3kgd2l0aGluIHRoZSBzYW1lIGZyYW1ld29yaywNCj4gPj4gcmlnaHQ/DQo+ID4+DQo+ID4+IFVu Zm9ydHVuYXRlbHkgd2UgaGF2ZSBubyBzaG9ydGFnZSBvZiB0ZXJtaW5vbG9neSBkZWZpbmluZyAo cGVyaGFwcyANCj4gPj4gZGlmZmVyZW50IGZsYXZvcnMpIG9mIHRoZSBzYW1lIHRoaW5nIQ0KPiA+ Pg0KPiA+Pj4gRnVydGhlcm1vcmUsIGJvdGggUkZDNDIwOCBhbmQgT05UcyBhcmUgbm90IG5lY2Vz c2FyaWx5IGFib3V0IFZQTnMuDQo+ID4+DQo+ID4+IFdoaWxlIEkgY2VydGFpbmx5IGFncmVlIHRo YXQgbm90IGFsbCBvdmVybGF5cyBuZWVkIGJlIFZQTnMsIGl0IA0KPiA+PiBzZWVtcyB0byBtZSB0 aGF0IG91ciBkaXNjdXNzaW9ucyBhcmUgYmVzdCBhbGlnbmVkIHdpdGggdGhhdCBzZXQgb2YgDQo+ ID4+IHRlcm1pbm9sb2d5LCBhbmQgdGhhdCBVTkkvRU5OSSBjYW4gYmUgZGVzY3JpYmVkIHdpdGhp biB0aGUgDQo+ID4+IENFL1BFL1ZOL1ZML1ZUIGNvbnN0cnVjdHMuDQo+ID4+IFBlcmhhcHMgd2l0 aCBzb21lIHR3ZWFraW5nIGluIHNvbWUgY2FzZXMuDQo+ID4+DQo+ID4+DQo+ID4+PiBUaGUgbW9z dCBpbXBvcnRhbnQgZ29hbCBpcyB0byBwcm92aWRlIGEgc29sdXRpb24gZm9yIGludGVyLWRvbWFp biANCj4gPj4+IGhvcml6b250YWwgaW50ZWdyYXRpb24gYmV0d2VlbiBuZXR3b3JrcyB3aXRoIHBv c3NpYmx5IGRpZmZlcmVudCANCj4gPj4+IHN3aXRjaGluZyB0ZWNobm9sb2dpZXMgYW5kIGluZGVw ZW5kZW50IGFkZHJlc3Npbmcgd2l0aGluIHRoZSANCj4gPj4+IG92ZXJsYXkgbW9kZWwuDQo+ID4+ Pg0KPiA+Pg0KPiA+PiBTdXJlLiAgSXQncyBhbHNvIHBvc3NpYmxlIHRoYXQgYW4gb3ZlcmxheSB3 aWxsIHVzZSB0aGUgc2FtZSANCj4gPj4gc3dpdGNoaW5nIHRlY2hub2xvZ3kgKGUuZy4sIE1QTFMg b3ZlciBNUExTLCBPRFUxIG92ZXIgT0RVNCkgb3IgZXZlbiANCj4gPj4gKGJ1dCBwcm9iYWJseSBs ZXNzIGxpa2VseSkgdGhlIHNhbWUgYWRkcmVzcyBzcGFjZSAoaWYgYSBwcm92aWRlciBzbyBjaG9v c2VzKS4NCj4gPj4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+DQoNCg0K From ggrammel@juniper.net Tue Jan 22 14:36:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F183E21F8949 for ; Tue, 22 Jan 2013 14:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 rH8uNea5vb18 for ; Tue, 22 Jan 2013 14:36:31 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id D50A821F8992 for ; Tue, 22 Jan 2013 14:36:27 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUP8Ua0Fh6fsvUopB4QuehNNAXGvmAgHa@postini.com; Tue, 22 Jan 2013 14:36:27 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 22 Jan 2013 14:34:03 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 22 Jan 2013 14:34:02 -0800 Received: from CO9EHSOBE012.bigfish.com (207.46.163.24) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 22 Jan 2013 14:42:01 -0800 Received: from mail125-co9-R.bigfish.com (10.236.132.244) by CO9EHSOBE012.bigfish.com (10.236.130.75) with Microsoft SMTP Server id 14.1.225.23; Tue, 22 Jan 2013 22:34:00 +0000 Received: from mail125-co9 (localhost [127.0.0.1]) by mail125-co9-R.bigfish.com (Postfix) with ESMTP id A33552E0413 for ; Tue, 22 Jan 2013 22:34:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -31 X-BigFish: PS-31(zzbb2dI98dI9371Ic89bhd6eah103dK168aJ148cI542Ic85dh1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275dh18c673h1954cbh18602eh8275bhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail125-co9 (localhost.localdomain [127.0.0.1]) by mail125-co9 (MessageSwitch) id 1358894038101841_21814; Tue, 22 Jan 2013 22:33:58 +0000 (UTC) Received: from CO9EHSMHS020.bigfish.com (unknown [10.236.132.236]) by mail125-co9.bigfish.com (Postfix) with ESMTP id 14E8C40006D; Tue, 22 Jan 2013 22:33:58 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS020.bigfish.com (10.236.130.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 22 Jan 2013 22:33:57 +0000 Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.8.63]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0257.004; Tue, 22 Jan 2013 22:33:56 +0000 From: Gert Grammel To: Lou Berger , Daniele Ceccarelli Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBokCIAAJEUjAAAD8STgAAm5+/A Date: Tue, 22 Jan 2013 22:33:55 +0000 Message-ID: <305443B66F0CD946A3107753337A031113F8F831@CH1PRD0511MB431.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> In-Reply-To: <50FDBD5B.6030307@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: multipart/alternative; boundary="_000_305443B66F0CD946A3107753337A031113F8F831CH1PRD0511MB431_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 22:36:41 -0000 --_000_305443B66F0CD946A3107753337A031113F8F831CH1PRD0511MB431_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lou, Daniele, Thanks for summarizing, seems we are converging. Related to terminology I s= till think that 'customer' and 'provider' give the wrong connotation for ov= erlay networks. While a VPN can be seen as a service, hence both terms migh= t have some justification, a Overlay-UNI/ENNI does not. It's simply a name = for a control interface that can be used internally in a network without ne= cessarily providing a customer with any new service. Having to choose betwe= en 'Customer-Provider' or 'Client-Server' terminology , the latter fits muc= h better to what we call Overlay. To move on with terminology we may want to preserve the abbreviations by ad= ding 'overlay': 1. Overlay-Provider-edge (OPE) - at least it provides a topology to t= he client 2. Overlay-Client-edge (OCE) - Note there is no customer here, it's a= client About Virtual topology 3): =B7 real-nodes vs. virtual nodes: from a OCE perspective there shal= l be no difference. In other words there shall be no difference between an = OPE Network exposing virtual nodes and an equivalent OPE network where each= virtual node is replaced by a real node of equal characteristic. I would support the connotation of a UNI, an augmented UNI and an O(verlay)= NNI (or OCE-OPE interface): 1. UNI: signaling only, no topology information exchanged (targeted f= or a customer/provider interface where Client=3Dcustomer) 2. Augmented-UNI: signaling only, with post-provisioned topology info= rmation of LSPs 3. ONNI: signaling and routing , where routing injects topology infor= mation independent of LSPs Best Gert -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Montag, 21. Januar 2013 23:13 To: Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Thanks Daniele, See below. On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: > Hi Lou, > > Please find comments in line > > BR > Daniele > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: venerd=EC 18 gennaio 2013 18.27 >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Daniele, >> Very nice summary. Just catching up, so sorry for the >> (2 day) late response. >> >> I really like how the terminology has evolved and appreciate the >> summary! >> >> I have a few detail comments, but before I go there I'd like to cover >> one more open issue that I think will have some >> (minor) ripple effects on the details. >> >> I think there's still the general issue of terminology to use when >> referring to the entity that "uses an overlay" and the entity that >> "instantiates the overlay". In your mail and in discussion we have: >> >> - client (service)/OC/CN/customer >> >> and >> >> - server(or service)/OE/EN/provider >> >> I think we had discussed, and possibly agreed on, using VPN >> terminology which would have us use the latter options, i.e., >> (overlay) customer/provider (edge). This would mean eliminating any >> references to client/server in the *generic >> overlay* definitions. Of course these terms may reemerge in other >> contexts as they have before, e.g., rfc6215. > > Yes, i think we all agreed. If there are still terms different from > customer/provider in the text it's because i missed them during the > replacing. > Great! Glad I didn't miss something over the holidays! >> >> I like this approach as it is aligned with the much of IETF work on >> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). >> Importantly, RFC 4847 even has quite a few concepts that can be >> directly leveraged in this discussion. >> >> I'd even go further and say that we should base the definitions and >> resulting framework on RFC 4847. For example, the definitions below >> could start with something along the lines: >> >> The overlay service model, at a high level, follows Section >> 7. of RFC 4847 as represented by: >> >> >> +--------------------+ >> : | | : >> : | | : >> +----+ : +----+ +----+ : +----+ >> | CE |---:---| PE | | PE |---:---| CE | >> +----+ : +----+ +----+ : +----+ >> : | | : >> : | | : >> : +--------------------+ : >> : | | : >> : |<-Provider network->| : >> Customer Customer >> interface interface >> >> Figure 7.2: Overlay Service Model >> >> In this model, the overlay is instantiated by an overlay >> "provider" and its provider edge (PE) nodes , and is used by >> the overlay "customer" which is connected to the provider via >> customer interfaces attached to customer edge (CE) nodes. >> >> ... >> >> The definition below would need to be tweaked slightly, notably to >> remove any references to client and server. The resulting framework >> can also refer back to RFC 4847 as needed. >> >> See below for some additional comments. >> >> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>> Dear overlayers, >>> >>> Please find below a new version (v2) of the framework summary >>> reflecting the latest discussions. Again i hope i've >> captured all the >>> comments around, sorry if anything is missing, in case just let me >>> know what i missed. >>> >>> BR >>> Daniele >>> >>> >>> + Disclaimer: >>> 1. Packet opto integration is often considered but the work can be >>> extented to any type of SC. Eg. TDM over LSC. >>> >>> + Terminology: >>> 1. Virtual Link: A virtual link is a potential path between two >>> virtual or real network elements in a provider layer network >> that is >>> maintained/controlled in and by the provider domain control >> plane (and >>> as such cannot transport any traffic/data and protected from being >>> de-provisioned) and which can be instantiated in the data plane (and >>> then can carry/transport/forward traffic/data) preserving previously >>> advertised attributes such as fate sharing information. >>> >> >> You say "potential path". I this this should read "potential or >> instantiated path". >> > > Maybe we need to define also what "potential" stands for? At least two > cases come to my mind (which might be included under the "potential" > umbrella): > > 1. resources reserved via signaling but not instantiated Sure. Sounds like a RFC6001 soft FA. > 2. resources not even signaled. In presence of a centralized entity > managing the network (sort of PCE plus something) there is no need to > reserve resources via signaling as the central entity is the only > thing that can reserve or allocate resources. I'm thinking to an > opening towards the integration with the SDN world. > Sure. Sounds like a Virtual TE link (per RFC6001, 5212). > Just loud thinking, does it make sense? > >>From my perspective, I think a node in the overlay really shouldn't >> *directly* distinguish between the two -- now one may have a >>different metric/SRLG/weight/etc, but these are abstracted >>representations of the tradeoffs between use of the two, that can be >>provided by the underlying provider network, rather than a direct >>indication. >> >>> 2. Virtual Node: Virtual node is a collection of zero or more >>> provider network domain nodes that are collectively >> represented to the >>> clients as a single node that exists in the customer layer >> network and >>> is capable of terminating of access, inter-domain and virtual links. >>> >> >> I'm a little uncomfortable with the linkage of real nodes to virtual >> nodes. I think VN is a purely abstract concept that may be >> instantiated using parts/whole/multiple/logical/real/etc nodes. > > Makes sense. What this definition adds to the one in RFC4847 is > basically the fact that also parts of a node can be considered. What > saying that it can be a real node i meant 1:1 correspondance between a > real and a virtual node. Your definition covers that case also, that's > fine. > >> >> How about something like: >> Virtual Node: A virtual node is a representation of a collection of >> provider resources that are interconnected via virtual (and customer) >> links. A virtual node may be collection of zero or more, including >> portions of, provider nodes that are collectively represented to the >> customer as a single node which is available in an overlay network. > > Works for me. > Great. BTW I don't think 4847 precluded a single physical node being repre= sented as multiple virtual nodes, but it doesn't hurt to make it explicit. >> >>> 3. Virtual Topology: Virtual topology is a collection of one or more >>> virtual or real provider network domain nodes that exist in the >>> customer layer network and are interconnected via 0 or more virtual >>> links. >> >> How about: >> Virtual Topology: A virtual topology is the collection of virtual >> links and nodes advertised by a provider to a customer. The virtual >> topology includes resources that are advertised as reachable within >> an overlay network. >> >> Do you mean to imply/allow for a VN which has no links? > > The case of "interconnected via 0 virtual links" implies the whole > domain seen as a single node. > Ahh, fair enough. >> >>> 4. Overlay topology: is a superset of virtual topologies >> provided by >>> each of provider network domains, access and inter-domain links. >>> >> >> Doesn't it also include any topology information advertised by the >> customer/CE as well? > > Possibly. Do you mean advertised by the CE in the customer domain, right? > That's possible too, but I was thinking more of advertised by CE (customer) to PE (provider). >> >>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It >>> can support any of the SCs supported by the GMPLS. >>> >> >> If we adopt RFC 4847 terminology it should be "customer interface". >> Also, I suspect you mean PE and CE. > > Mmm, yes but what if we want to manage it as a link? i.e. All > TE-parameters that a link supports. Is it enough to call it interface > only? > sure. Per 4847, I'd say that "customer interface" is the connection betwee= n CE/PE while [virtual] TE links are what is advertised/represented in rout= ing. >> >>> 6. CE (customer Edge): Something like the CN in RFC4208 >> teminology but >>> (i) receiving virtual topology from the provider network and >>> requesting the set up of one of them or (ii) requesting the >>> computation and establishment of a path accordingly to given >>> constraints in the provider network and receiving the parameters >>> characterizing such path. (ii) =3D=3D UNI. >>> >> >> humm, I'm inclined to stay away from UNI for the moment. I also >> suggest that we look to 4874 and even 4364 rather than 4208... > > Ok, we can refer to those RFC for what concerns terminology, but at > the end of the day we must put the UNI under this framework. In the > new terminology the UNI is a particular type of customer interface. > Fair enough. But it is a form on an overlay "customer interface" not the d= efinitive form. >> >>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to >>> deal with (i) and (ii) above. >>> >> >> same comment WRT RFCs. >> >>> 8. PE-CE interface (former ONI) : Interface allowing for >> signaling and >>> routing messages exchange between customer overlay and provider >>> network. Routing information consists on virtual topology >>> advertisement. When there is no routing adjacency across the >> interface >>> it is equivalent to the GMPLS UNI defined in 4208. >>> Signaling messages are compliant with RFC4208. Information >> related to >>> path carachteristics, e.g. TE-metrics, collected SRLG, path >> delay etc, >>> either passed from CE to PE via signaling after the LSP >> establishment >>> in the core network or from CE to PE to be used as path computation >>> constraints, fall under the definition of signaling info and not >>> routing info). >>> >> >> >>> 9. CE-CE (former O-NNI): Interface on the links between different >>> provider networks in the overlay model environment. Same features of >>> the CE-PE apply to this interface. >>> >> >> you mean, PE-PE, right? > > You're not the first one that makes me notice i'm probably affected by > dyslexia :-) > no problem, happens to the best of us! >> >>> + Statements 1. In the context of overlay model we are aiming to >>> build an overlay topology for the customer network domains >>> >>> 2. The overlay topology is comprised of: >>> a) access links (links connecting client NEs to the >> provider network domains). >>> They can be PSC or LSC. >>> b) inter-domain links (links interconnecting server >> network domains) >>> c) virtual topology provided by the provider network domains. >>> Virtual Links >>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of >>> + parameters >>> e.g. SRLG, optical impairments, delay etc for each entry) describing >>> connectivity between access links and virtual links. >>> >>> 3. In the context of overlay model we manage hierarchy of overlay >>> topologies with overlay/underlay relationships >>> >>> 4. In the context of overlay model multi-layering and inter-layer >>> relationships are peripheral at best, it is all about horizontal >>> network integration >>> >>> 5. The overlay model assumes one CP instance for the >> customer network >>> and a separate instance for the provider network and in the CE-PE >>> interface case the provider network also surreptitiously >> participates >>> in the customer network by injecting virtual topology >> information into >>> it. >>> >> >> We should ensure we're allowing for some of the existing/augmented >> models that permit the transport of overlay information within the >> provider's CP, e.g., rfc4364, 5195 and 5252. > > I'd say they should be already covered, but will double check > great. >> >>> 6. L1VPN (and LxVPN) in general is a type of service >> provided over the >>> CE-PE interface (it falls under the UNI case as no routing adjacency >>> is in place between CE and PE). >>> >>> >>> + Advertisement models (to be detailed in dedicated >>> + document/documents) >>> The CE-PE interface in the overlay model context foresees >> two types of >>> advertisement models.(names still to be agreed) >>> >>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >> augmented by >>> a number of actived draft (references to various drafts to >> be added). >>> The Augmented UNI is a particular type of CE-PE interface where only >>> signaling messages are exchanged between CE and PE. >>> Messages from CE to PE can include a set of parameters to be used by >>> the PE as path computation constraints when computing a path in the >>> provider domain network, while messages from PE to CE can include a >>> set of parameters qualifying the LSP being established, like for >>> example SRLG, delay, loss etc. >>> >> >> again, we can leverage 4874 terminology if we so choose, i.e., "basic >> mode" and "enhanced mode" UNI|NNI > > Don would be happy about that :-). I'd say yes. The goal was to cover > the L1VPN work (enhanced mode), all the drafts-ali recently polled > for wg adoption (basic mode?) and the actual ENNI (enhanced mode). > Is my mapping in brackets correct? > Not sure f I'd break it down they way you are. I'd say basic mode is close= r to the typical UNI and enhance mode is UNI+routing or perhaps even an ENN= I. > >> >>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >>> called with the general CE-PE interface term?) allowing the >>> establishment of signaling and routing adjacency between CE and PE. >>> Routing info passed from PE to CE comprise overlay topology >>> information including (but not limited to) virtual links, >> connectivity >>> matrices and access links with parameters qualifying each of them in >>> terms of e.g. SRLG, loss, delay etc. Signaling information and >>> procedures are compliant with RFC4208. >>> >> >> so this is just and 4874 "enhanced mode" interface, right. > > Good question: the enhanced mode supports signaling and routing, so > i'd say yes, but reading section 7.3 it talks about "limited exchange > of information between the control planes. > > "permits limited exchange of > information between the control planes of the provider and the > customer to help such functions as discovery of customer network > routing information (i.e., reachability or TE information in remote > customer sites), or parameters of the part of the provider's network > dedicated to the customer." > > Would you say this includes what we want? (i.e. Virtual links, virtual > nodes, connectivity matrices, SRLG, delay, loss, etc) If yes we're > done, otherwise an option could be the denition of a third VPN service > model. > humm, need to think about this. Perhaps the best thing is to document the = two different cases and then decide if we have something new or (two) more detailed forms of something old. >> >>> + Open issues/questions >>> 1. PCE-PCEP - do we need to include considerations about PCE >> and PCEP >>> into the overlay framework context? >>> >>> 2. BGP-LS needs to be considered >>> 3. Should potentials be included? E.g. I2RS? >>> 4. Virtual links: wouldn't a different definition of virtual links >>> avoid the advertisement of connectivity matrices (this is out of the >>> fwk scope but within the advertisement models one)? >>> >> >>> Take this example: >>> PE1-----CE1 CE2-----PE2 >>> CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>> CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >> >> I think you've reversed CE and PE here... > > Yes, once again. > > No comment on my foolish proposal? > Which one? I liked your summary overall. Lou > >> >> Much thanks! >> >> Lou >> (hatless...) >> >>> i.e. There are 2 VL connecting CE1 and CE2 that could be >> available for >>> PE1 and PE2 to set up an adjacency in the customer domain. >> CE1 and/or >>> CE2 can be blocking nodes so VL1 and/or VL2 are available only >>> depending on the connectivity matrices of CE1 and CE2. Hence >> PEs need >>> to be aware of both VL and connectivity matrices. My point >> is: if CE1 >>> advertises to PE1 only the VL that his connectivity matrix allows to >>> be connected to PE1 (e.g. VL1 only) and not all of them, it >> should be >>> possible to avoid the connectivity matrices advertisement. >>> >> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> DANIELE CECCARELLI >>> System & Technology - PDU Optical & Metro >>> >>> Via E.Melen, 77 >>> Genova, Italy >>> Phone +390106002512 >>> Mobile +393346725750 >>> daniele.ceccarelli@ericsson.com >>> www.ericsson.com >>> >> > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_305443B66F0CD946A3107753337A031113F8F831CH1PRD0511MB431_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Lou, Daniele,

 

Thanks for summarizing, seem= s we are converging. Related to terminology I still think that 'customer' a= nd 'provider' give the wrong connotation for overlay networks. While a VPN = can be seen as a service, hence both terms might have some justification, a Overlay-UNI/ENNI does not. It's sim= ply a name for a control interface that can be used internally in a network= without necessarily providing a customer with any new service. Having to c= hoose between ‘Customer-Provider’ or ‘Client-Server’ terminology , the latter fits much better t= o what we call Overlay.  

 

To move on with terminology = we may want to preserve the abbreviations by adding 'overlay':

1= .   &= nbsp;   Overlay-Provider-edge (= OPE) – at least it provides a topology to the client

2= .   &= nbsp;   Overlay-Client-edge (OC= E) - Note there is no customer here, it’s a client<= /p>

 

About Virtual topology 3):

=B7         real-nodes vs. virtual = nodes: from a OCE perspective there shall be no difference. In other words = there shall be no difference between an OPE Network exposing virtual nodes = and an equivalent OPE network where each virtual node is replaced by a real node of equal characteristic.=

 

I would support the connotat= ion of a UNI, an augmented UNI and an O(verlay)NNI (or OCE-OPE interface):<= o:p>

1= .   &= nbsp;   UNI: signaling only, no= topology information exchanged (targeted for a customer/provider interface= where Client=3Dcustomer)

2= .   &= nbsp;   Augmented-UNI: signalin= g only, with post-provisioned topology information of LSPs

3= .   &= nbsp;   ONNI: signaling and rou= ting , where routing injects topology information independent of LSPs<= /o:p>

 

Best

 

Gert

 

 

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger
Sent: Montag, 21. Januar 2013 23:13
To: Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

 

Thanks Daniele, See below.

 

On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote:

> Hi Lou,

>

> Please find comments in line

>

> BR

> Daniele

>

>> -----Original Message-----

>> From: Lou Berger [<= /span>mailto:lberger@labn.net]

>> Sent: venerd=EC 18 gennaio 2013 18.27

>> To: Daniele Ceccarelli

>> Cc: CCAMP

>> Subject: Re: [CCAMP] Overlay model frame= work v2

>> 

>> Daniele,

>>       &nbs= p;  Very nice summary.  Just catching up, so sorry for the

>> (2 day) late response.

>> 

>> I really like how the terminology has ev= olved and appreciate the

>> summary!

>> 

>> I have a few detail comments, but before= I go there I'd like to cover

>> one more open issue that I think will ha= ve some

>> (minor) ripple effects on the details.

>> 

>> I think there's still the general issue = of terminology to use when

>> referring to the entity that "uses = an overlay" and the entity that

>> "instantiates the overlay".&nb= sp; In your mail and in discussion we have:

>> 

>> - client (service)/OC/CN/customer

>> 

>> and

>> 

>> - server(or service)/OE/EN/provider=

>> 

>> I think we had discussed, and possibly a= greed on, using VPN

>> terminology which would have us use the = latter options, i.e.,

>> (overlay) customer/provider (edge). = ; This would mean eliminating any

>> references to client/server in the *gene= ric

>> overlay* definitions.  Of course th= ese terms may reemerge in other

>> contexts as they have before, e.g., rfc6= 215.

>

> Yes, i think we all agreed. If there are sti= ll terms different from

> customer/provider in the text it's because i= missed them during the

> replacing.

>

 

Great!  Glad I didn't miss something over th= e holidays!

 

>> 

>> I like this approach as it is aligned wi= th the much of IETF work on

>> overlays (e.g., BGP L3/L2 VPNs) as well = as the L1VPN (e.g. RFC 4847). 

>> Importantly, RFC 4847 even has quite a f= ew concepts that can be

>> directly leveraged in this discussion.

>> 

>> I'd even go further and say that we shou= ld base the definitions and

>> resulting framework on RFC 4847.  F= or example, the definitions below

>> could start with something along the lin= es:

>> 

>>    The overlay service mo= del, at a high level, follows Section

>>    7. of RFC 4847 as repr= esented by:

>> 

>> 

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

>>       = ;           :  =    |          &= nbsp;         |   &n= bsp; :

>>       = ;           :  =    |          &= nbsp;         |   &n= bsp; :

>>       = ;  +----+   :   +----+  =             +---= -+   :   +----+

>>       = ;  | CE |---:---| PE |        =       | PE |---:---| CE |

>>       = ;  +----+   :   +----+  =             +---= -+   :   +----+

>>       = ;           :  =    |          &= nbsp;         |   &n= bsp; :

>>       = ;           :  =    |          &= nbsp;         |   &n= bsp; :

>>       = ;           :  =    +--------------------+     :<= /o:p>

>>       = ;           :  =    |          &= nbsp;         |   &n= bsp; :

>>       = ;           :  =    |<-Provider network->|     :

>>       = ;      Customer      = ;            &n= bsp;        Customer

>>       = ;      interface     &nbs= p;             =        interface

>> 

>>       = ;           Figure 7.2: O= verlay Service Model

>> 

>>    In this model, the ove= rlay is instantiated by an overlay

>>    "provider" a= nd its provider edge (PE) nodes , and is used by

>>    the overlay "cust= omer" which is connected to the provider via

>>    customer interfaces at= tached to customer edge (CE) nodes.

>> 

>>    ...

>> 

>> The definition below would need to be tw= eaked slightly, notably to

>> remove any references to client and serv= er.  The resulting framework

>> can also refer back to RFC 4847 as neede= d.

>> 

>> See below for some additional comments.<= o:p>

>> 

>> On 1/16/2013 10:33 AM, Daniele Ceccarell= i wrote:

>>> Dear overlayers,

>>> 

>>> Please find below a new version (v2)= of the framework summary

>>> reflecting the latest discussions. A= gain i hope i've

>> captured all the

>>> comments around, sorry if anything i= s missing, in case just let me

>>> know what i missed.

>>> 

>>> BR

>>> Daniele

>>> 

>>> 

>>> + Disclaimer:

>>> 1. Packet opto integration is often = considered but the work can be

>>> extented to any type of SC. Eg. TDM = over LSC.

>>> 

>>> + Terminology:

>>> 1. Virtual Link: A virtual link is a= potential path between two

>>> virtual or real network elements in = a provider layer network

>> that is

>>> maintained/controlled in and by the = provider domain control

>> plane (and

>>> as such cannot transport any traffic= /data and protected from being

>>> de-provisioned) and which can be ins= tantiated in the data plane (and

>>> then can carry/transport/forward tra= ffic/data) preserving previously

>>> advertised attributes such as fate s= haring information.

>>> 

>> 

>> You say "potential path". = ; I this this should read  "potential or

>> instantiated path".

>> 

>

> Maybe we need to define also what "pote= ntial" stands for? At least two

> cases come to my mind (which might be includ= ed under the "potential"

> umbrella):

>

> 1. resources reserved via signaling but not = instantiated

 

Sure.  Sounds like a RFC6001 soft FA.

 

> 2. resources not even signaled. In presence = of a centralized entity

> managing the network (sort of PCE plus somet= hing) there is no need to

> reserve resources via signaling as the centr= al entity is the only

> thing that can reserve or allocate resources= . I'm thinking to an

> opening towards the integration with the SDN= world.

>

 

Sure.  Sounds like a Virtual TE link (per RF= C6001, 5212).

 

> Just loud thinking, does it make sense?=

>

>>From my perspective, I think a node in th= e overlay really shouldn't

>> *directly* distinguish between the two -= - now one may have a 

>>different metric/SRLG/weight/etc, but the= se are abstracted 

>>representations of the tradeoffs between = use of the two, that  can be

>>provided by the underlying provider netwo= rk, rather  than a direct

>>indication.

>> 

>>> 2.  Virtual Node: Virtual node = is a collection of zero or more

>>> provider network domain nodes that a= re collectively

>> represented to the

>>> clients as a single node that exists= in the customer layer

>> network and

>>> is capable of terminating of access,= inter-domain and virtual links.

>>> 

>> 

>> I'm a little uncomfortable with the link= age of real nodes to virtual

>> nodes.  I think VN is a purely abst= ract concept that may be

>> instantiated using parts/whole/multiple/= logical/real/etc nodes.

>

> Makes sense. What this definition adds to th= e one in RFC4847 is

> basically the fact that also parts of a node= can be considered. What

> saying that it can be a real node i meant 1:= 1 correspondance between a

> real and a virtual node. Your definition cov= ers that case also, that's

> fine.

>

>> 

>> How about something like:

>> Virtual Node: A virtual node is a repres= entation of a collection of

>> provider resources that are interconnect= ed via virtual (and customer)

>> links.  A virtual node may be colle= ction of zero or more, including

>> portions of, provider nodes that are col= lectively represented to the

>> customer as a single node which is avail= able in an overlay network.

>

> Works for me.

>

 

Great.  BTW I don't think 4847 precluded a s= ingle physical node being represented as multiple virtual nodes, but it doe= sn't hurt to make it explicit.

 

>> 

>>> 3. Virtual Topology: Virtual topolog= y is a collection of one or more

>>> virtual or real provider network dom= ain nodes that exist in the

>>> customer layer network and are inter= connected via 0 or more virtual

>>> links.

>> 

>> How about:

>> Virtual Topology: A virtual topology is = the collection of virtual

>> links and nodes advertised by a provider= to a customer. The virtual

>> topology includes resources that are adv= ertised as reachable within

>> an overlay network.

>> 

>> Do you mean to imply/allow for a VN whic= h has no links?

>

> The case of "interconnected via 0 virtu= al links" implies the whole

> domain seen as a single node.

>

 

Ahh, fair enough.

 

>> 

>>> 4. Overlay topology:  is a supe= rset of virtual topologies

>> provided by

>>> each of provider network domains, ac= cess and inter-domain links.

>>> 

>> 

>> Doesn't it also include any topology inf= ormation advertised by the

>> customer/CE as well?

>

> Possibly. Do you mean advertised by the CE i= n the customer domain, right?

>

 

That's possible too, but I was thinking more of a= dvertised by CE

(customer) to PE (provider).

 

>> 

>>> 5. Access Link: Link between OC and = OE. GMPLS runs on that link. It

>>> can support any of the SCs supported= by the GMPLS.

>>> 

>> 

>> If we adopt RFC 4847 terminology it shou= ld be "customer interface".

>> Also, I suspect you mean PE and CE.=

>

> Mmm, yes but what if we want to manage it as= a link? i.e. All

> TE-parameters that a link supports. Is it en= ough to call it interface

> only?

>

 

sure.  Per 4847, I'd say that "customer= interface" is the connection between CE/PE while [virtual] TE links a= re what is advertised/represented in routing.

 

>> 

>>> 6. CE (customer Edge): Something lik= e the CN in RFC4208

>> teminology but

>>> (i) receiving virtual topology from = the provider network and

>>> requesting the set up of one of them= or (ii) requesting the

>>> computation and establishment of a p= ath accordingly to given

>>> constraints in the provider network = and receiving the parameters

>>> characterizing such path. (ii) =3D= =3D UNI.

>>> 

>> 

>> humm, I'm inclined to stay away from UNI= for the moment.  I also

>> suggest that we look to 4874 and even 43= 64 rather than 4208...

>

> Ok, we can refer to those RFC for what conce= rns terminology, but at

> the end of the day we must put the UNI under= this framework. In the

> new terminology the UNI is a particular type= of customer interface.

>

 

Fair enough.  But it is a form on an overlay= "customer interface" not the definitive form.

 

>> 

>>> 7. PE (provider Edge): Something lik= e the EN in RFC4208 but able to

>>> deal with (i) and (ii) above.

>>> 

>> 

>> same comment WRT RFCs.

>> 

>>> 8. PE-CE interface (former ONI) : In= terface allowing for

>> signaling and

>>> routing messages exchange between cu= stomer overlay and provider

>>> network. Routing information consist= s on virtual topology

>>> advertisement. When there is no rout= ing adjacency across the

>> interface

>>> it is equivalent to the GMPLS UNI de= fined in 4208.

>>> Signaling messages are compliant wit= h RFC4208. Information

>> related to

>>> path carachteristics, e.g. TE-metric= s, collected SRLG, path

>> delay etc,

>>> either passed from CE to PE via sign= aling after the LSP

>> establishment

>>> in the core network or from CE to PE= to be used as path computation

>>> constraints, fall under the definiti= on of signaling info and not

>>> routing info).

>>> 

>> 

>> 

>>> 9. CE-CE (former O-NNI): Interface o= n the links between different

>>> provider networks in the overlay mod= el environment. Same features of

>>> the CE-PE apply to this interface.

>>> 

>> 

>> you mean, PE-PE, right?

>

> You're not the first one that makes me notic= e i'm probably affected by

> dyslexia :-)

>

 

no problem, happens to the best of us!=

 

>> 

>>> + Statements 1. In the context o= f overlay model we are aiming to

>>> build an overlay topology for the cu= stomer network domains

>>> 

>>>  2. The overlay topology is com= prised of:

>>>     a) access li= nks (links connecting client NEs to the

>> provider network domains).

>>>  They can be PSC or LSC.

>>>     b) inter-dom= ain links (links interconnecting server

>> network domains)

>>>     c) virtual t= opology provided by the provider network domains.

>>> Virtual Links

>>> + Virtual Nodes (TBD) + Conn= ectivity Matrix (with a set of

>>> + parameters

>>> e.g. SRLG, optical impairments, dela= y etc for each entry) describing

>>> connectivity between access links an= d virtual links.

>>> 

>>> 3. In the context of overlay model w= e manage  hierarchy  of overlay

>>> topologies with overlay/underlay rel= ationships

>>> 

>>> 4. In the context of overlay model m= ulti-layering and inter-layer

>>> relationships are peripheral at best= , it is all about horizontal

>>> network integration

>>> 

>>> 5. The overlay model assumes one CP = instance for the

>> customer network

>>> and a separate instance for the prov= ider network and in the CE-PE

>>> interface case the provider network = also surreptitiously

>> participates

>>> in the customer network by injecting= virtual topology

>> information into

>>> it.

>>> 

>> 

>> We should ensure we're allowing for some= of the existing/augmented

>> models that permit the transport of over= lay information within the

>> provider's CP, e.g., rfc4364, 5195 and 5= 252.

>

> I'd say they should be already covered, but = will double check

>

 

great.

 

>> 

>>> 6. L1VPN (and LxVPN) in general is a= type of service

>> provided over the

>>> CE-PE interface (it falls under the = UNI case as no routing adjacency

>>> is in place between CE and PE).=

>>> 

>>> 

>>> + Advertisement models (to be de= tailed in dedicated

>>> + document/documents)=

>>> The CE-PE interface in the overlay m= odel context foresees

>> two types of

>>> advertisement models.(names still to= be agreed)

>>> 

>>> A. Augmented UNI: The GMPLS UNI is d= efined in RFC4208 and

>> augmented by

>>> a number of actived draft (reference= s to various drafts to

>> be added).

>>> The Augmented UNI is a particular ty= pe of CE-PE interface where only

>>> signaling messages are exchanged bet= ween CE and PE.

>>> Messages from CE to PE can include a= set of parameters to be used by

>>> the PE as path computation constrain= ts when computing a path in the

>>> provider domain network, while messa= ges from PE to CE can include a

>>> set of parameters qualifying the LSP= being established, like for

>>> example SRLG, delay, loss etc.<= /o:p>

>>> 

>> 

>> again, we can leverage 4874 terminology = if we so choose, i.e., "basic

>> mode" and "enhanced mode"= UNI|NNI

>

> Don would be happy about that :-). I'd say y= es. The goal was to cover

> the L1VPN work (enhanced mode),  all th= e drafts-ali recently polled

> for wg adoption (basic mode?) and the actual= ENNI (enhanced mode).

 

> Is my mapping in brackets correct?

>

 

Not sure f I'd break it down they way you are.&nb= sp; I'd say basic mode is closer to the typical UNI and enhance mode is UNI= +routing or perhaps even an ENNI.

 

>

>> 

>>> B. ONI: The GMPLS ONI is a CE-PE int= erface (this could be simply

>>> called with the general CE-PE interf= ace term?) allowing the

>>> establishment of signaling and routi= ng adjacency between CE and PE.

>>> Routing info passed from PE to CE co= mprise overlay topology

>>> information including (but not limit= ed to) virtual links,

>> connectivity

>>> matrices and access links with param= eters qualifying each of them in

>>> terms of e.g. SRLG, loss, delay etc.= Signaling information and

>>> procedures are compliant with RFC420= 8.

>>> 

>> 

>> so this is just and 4874 "enhanced = mode" interface, right.

>

> Good question: the enhanced mode supports si= gnaling and routing, so

> i'd say yes, but reading section 7.3 it talk= s about "limited exchange

> of information between the control planes.

>

>    "permits limited exch= ange of

>    information between the co= ntrol planes of the provider and the

>    customer to help such func= tions as discovery of customer network

>    routing information (i.e.,= reachability or TE information in remote

>    customer sites), or parame= ters of the part of the provider's network

>    dedicated to the customer.= "

>

> Would you say this includes what we want? (i= .e. Virtual links, virtual

> nodes, connectivity matrices, SRLG, delay, l= oss, etc) If yes we're

> done, otherwise an option could be the denit= ion of a third VPN service

> model.

>

 

humm, need to think about this.  Perhaps the= best thing is to document the two different cases and then decide if we ha= ve something new or

(two) more detailed forms of something old.<= /o:p>

 

>> 

>>> + Open issues/questions

>>> 1. PCE-PCEP - do we need to include = considerations about PCE

>> and PCEP

>>> into the overlay framework context?<= o:p>

>>> 

>>>  2. BGP-LS needs to be consider= ed

>>>  3. Should potentials be includ= ed? E.g. I2RS?

>>> 4. Virtual links: wouldn't a differe= nt definition of virtual links

>>> avoid the advertisement of connectiv= ity matrices (this is out of the

>>> fwk scope but within the advertiseme= nt models one)?

>>> 

>> 

>>> Take this example:

>>> PE1-----CE1    &= nbsp;          CE2-----PE2

>>>      &= nbsp;  CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2

>>>      &= nbsp;  CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2

>> 

>> I think you've reversed CE and PE here..= .

>

> Yes, once again.

>

> No comment on my foolish proposal?

>

 

Which one?  I liked your summary overall.

 

Lou

 

>

>> 

>> Much thanks!

>> 

>> Lou

>> (hatless...)

>> 

>>> i.e. There are 2 VL connecting CE1 a= nd CE2 that could be

>> available for

>>> PE1 and PE2 to set up an adjacency i= n the customer domain.

>> CE1 and/or

>>> CE2 can be blocking nodes so VL1 and= /or VL2 are available only

>>> depending on the connectivity matric= es of CE1 and CE2. Hence

>> PEs need

>>> to be aware of both VL and connectiv= ity matrices. My point

>> is: if CE1

>>> advertises to PE1 only the VL that h= is connectivity matrix allows to

>>> be connected to PE1 (e.g. VL1 only) = and not all of them, it

>> should be

>>> possible to avoid the connectivity m= atrices advertisement.

>>> 

>> 

>>> 

>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

>>> DANIELE CECCARELLI

>>> System & Technology - PDU Optica= l & Metro

>>> 

>>> Via E.Melen, 77

>>> Genova, Italy

>>> Phone +390106002512

>>> Mobile +393346725750<= /p>

>>> daniel= e.ceccarelli@ericsson.com

>>> = www.ericsson.com

>>> 

>> 

>

>

>

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org=

https://www.ie= tf.org/mailman/listinfo/ccamp

 

--_000_305443B66F0CD946A3107753337A031113F8F831CH1PRD0511MB431_-- From ggrammel@juniper.net Tue Jan 22 15:05:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034A221F8A48 for ; Tue, 22 Jan 2013 15:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 JYBMb+8TSpmO for ; Tue, 22 Jan 2013 15:05:52 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7417521F8A66 for ; Tue, 22 Jan 2013 15:05:37 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUP8bP+LteFtH1T+eG4HqS6wgYWWUFcwn@postini.com; Tue, 22 Jan 2013 15:05:38 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 22 Jan 2013 15:04:02 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 22 Jan 2013 15:04:02 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.14) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 22 Jan 2013 15:12:03 -0800 Received: from mail77-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Tue, 22 Jan 2013 23:04:01 +0000 Received: from mail77-tx2 (localhost [127.0.0.1]) by mail77-tx2-R.bigfish.com (Postfix) with ESMTP id B20814201D1 for ; Tue, 22 Jan 2013 23:04:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -31 X-BigFish: PS-31(zzbb2dI98dI9371Ic89bhd6eah103dK168aJ542I1432I1418Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dh18602eh8275bhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail77-tx2 (localhost.localdomain [127.0.0.1]) by mail77-tx2 (MessageSwitch) id 1358895839613155_31164; Tue, 22 Jan 2013 23:03:59 +0000 (UTC) Received: from TX2EHSMHS013.bigfish.com (unknown [10.9.14.238]) by mail77-tx2.bigfish.com (Postfix) with ESMTP id 9151F60062; Tue, 22 Jan 2013 23:03:59 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by TX2EHSMHS013.bigfish.com (10.9.99.113) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 22 Jan 2013 23:03:57 +0000 Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.8.63]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0257.004; Tue, 22 Jan 2013 23:03:56 +0000 From: Gert Grammel To: Igor Bryskin , Lou Berger Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBokCIAAJEUjAAAD8STgAAjXhkAAAGVTwAAAKfwgAAAY7AAAAC7dQAADTFzwA== Date: Tue, 22 Jan 2013 23:03:55 +0000 Message-ID: <305443B66F0CD946A3107753337A031113F8F928@CH1PRD0511MB431.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <50FEBC58.2030803@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:05:59 -0000 Lou, playing with TE metric is indeed not the best idea. However representing th= e server U-bit in a client domain admin color might be interesting. (sorry = for still using the old acronyms) Gert =20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Dienstag, 22. Januar 2013 17:42 To: Lou Berger Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Lou, Generally it is not a good idea to play with the TE metric.=20 It is up to client path computer (or client policy) to decide how important= the difference between a committed and uncommitted VL, and hence to defin= e the TE metric penalty. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Tuesday, January 22, 2013 11:21 AM To: Igor Bryskin Cc: Daniele Ceccarelli; CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Igor, I was referring to you comment: IB>> It is beneficial from the client (ONT user) path computation point=20 IB>> of view to know whether the advertised VL is committed (the data=20 IB>> plane is provisioned) or not. So my point is that the U bit should be represented via an increased metric= (or some other existing parameter) as this is what path computation is goi= ng to do in effect in any case. Lou On 1/22/2013 11:09 AM, Igor Bryskin wrote: > Hi Lou, >=20 > You said: > And I'm suggesting that this be advertised using generic constructs such = as TE metric, SRLG, and even MELG, rather than adding yet another special c= ase computation/optimization parameter. >=20 > Agree, we are already doing this via MELG sub-TLV. This is because the su= b-TLV is new (no need to change the existing ones) and because MELG is pecu= liar to VL. >=20 > Igor. >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, January 22, 2013 10:51 AM > To: Igor Bryskin > Cc: Daniele Ceccarelli; CCAMP > Subject: Re: [CCAMP] Overlay model framework v2 >=20 > Igor, >=20 > see below. >=20 > On 1/22/2013 10:05 AM, Igor Bryskin wrote: >> Lou and Daniele, >> Please, see my comments in-line, >> >> Cheers, >> Igor >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> Behalf Of Lou Berger >> Sent: Monday, January 21, 2013 5:13 PM >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Thanks Daniele, See below. >> >> On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: >>> Hi Lou, >>> >>> Please find comments in line >>> >>> BR >>> Daniele >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: venerd=EC 18 gennaio 2013 18.27 >>>> To: Daniele Ceccarelli >>>> Cc: CCAMP >>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>> >>>> Daniele, >>>> Very nice summary. Just catching up, so sorry for the >>>> (2 day) late response. >>>> >>>> I really like how the terminology has evolved and appreciate the=20 >>>> summary! >>>> >>>> I have a few detail comments, but before I go there I'd like to=20 >>>> cover one more open issue that I think will have some >>>> (minor) ripple effects on the details. >>>> >>>> I think there's still the general issue of terminology to use when=20 >>>> referring to the entity that "uses an overlay" and the entity that=20 >>>> "instantiates the overlay". In your mail and in discussion we have: >>>> >>>> - client (service)/OC/CN/customer >>>> >>>> and >>>> >>>> - server(or service)/OE/EN/provider >>>> >>>> I think we had discussed, and possibly agreed on, using VPN=20 >>>> terminology which would have us use the latter options, i.e., >>>> (overlay) customer/provider (edge). This would mean eliminating=20 >>>> any references to client/server in the *generic >>>> overlay* definitions. Of course these terms may reemerge in other=20 >>>> contexts as they have before, e.g., rfc6215. >>> >>> Yes, i think we all agreed. If there are still terms different from=20 >>> customer/provider in the text it's because i missed them during the=20 >>> replacing. >>> >> >> Great! Glad I didn't miss something over the holidays! >> >> IB>> I personally have no problems with the VPN terminology. However, >> IMO the terminology should be aligned with the RFC 4208 and George's=20 >> drafts. >=20 > My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped to= encompass the broad spectrum of overlays that are/have been discussed. >=20 >> One cannot use different terminology within the same framework, right? >=20 > Unfortunately we have no shortage of terminology defining (perhaps differ= ent flavors) of the same thing! >=20 >> Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. >=20 > While I certainly agree that not all overlays need be VPNs, it seems to m= e that our discussions are best aligned with that set of terminology, and t= hat UNI/ENNI can be described within the CE/PE/VN/VL/VT constructs. > Perhaps with some tweaking in some cases. >=20 >=20 >> The most important goal is to provide a solution for inter-domain=20 >> horizontal integration between networks with possibly different=20 >> switching technologies and independent addressing within the overlay=20 >> model. >> >=20 > Sure. It's also possible that an overlay will use the same switching tec= hnology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably less l= ikely) the same address space (if a provider so chooses). >=20 >>>> >>>> I like this approach as it is aligned with the much of IETF work on=20 >>>> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). >>>> Importantly, RFC 4847 even has quite a few concepts that can be=20 >>>> directly leveraged in this discussion. >>>> >>>> I'd even go further and say that we should base the definitions and=20 >>>> resulting framework on RFC 4847. For example, the definitions=20 >>>> below could start with something along the lines: >>>> >>>> The overlay service model, at a high level, follows Section >>>> 7. of RFC 4847 as represented by: >>>> >>>> >>>> +--------------------+ >>>> : | | : >>>> : | | : >>>> +----+ : +----+ +----+ : +----+ >>>> | CE |---:---| PE | | PE |---:---| CE | >>>> +----+ : +----+ +----+ : +----+ >>>> : | | : >>>> : | | : >>>> : +--------------------+ : >>>> : | | : >>>> : |<-Provider network->| : >>>> Customer Customer >>>> interface interface >>>> >>>> Figure 7.2: Overlay Service Model >>>> >>>> In this model, the overlay is instantiated by an overlay >>>> "provider" and its provider edge (PE) nodes , and is used by >>>> the overlay "customer" which is connected to the provider via >>>> customer interfaces attached to customer edge (CE) nodes. >>>> >>>> ... >>>> >>>> The definition below would need to be tweaked slightly, notably to=20 >>>> remove any references to client and server. The resulting=20 >>>> framework can also refer back to RFC 4847 as needed. >>>> >>>> See below for some additional comments. >>>> >>>> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>>>> Dear overlayers, >>>>> >>>>> Please find below a new version (v2) of the framework summary=20 >>>>> reflecting the latest discussions. Again i hope i've >>>> captured all the >>>>> comments around, sorry if anything is missing, in case just let me=20 >>>>> know what i missed. >>>>> >>>>> BR >>>>> Daniele >>>>> >>>>> >>>>> + Disclaimer: >>>>> 1. Packet opto integration is often considered but the work can be=20 >>>>> extented to any type of SC. Eg. TDM over LSC. >>>>> >>>>> + Terminology: >>>>> 1. Virtual Link: A virtual link is a potential path between two=20 >>>>> virtual or real network elements in a provider layer network >>>> that is >>>>> maintained/controlled in and by the provider domain control >>>> plane (and >>>>> as such cannot transport any traffic/data and protected from being >>>>> de-provisioned) and which can be instantiated in the data plane=20 >>>>> (and then can carry/transport/forward traffic/data) preserving=20 >>>>> previously advertised attributes such as fate sharing information. >>>>> >>>> >>>> You say "potential path". I this this should read "potential or=20 >>>> instantiated path". >>>> >>> >>> Maybe we need to define also what "potential" stands for? At least=20 >>> two cases come to my mind (which might be included under the "potential= " >>> umbrella): >>> >>> 1. resources reserved via signaling but not instantiated >> >> Sure. Sounds like a RFC6001 soft FA. >> >>> 2. resources not even signaled. In presence of a centralized entity=20 >>> managing the network (sort of PCE plus something) there is no need=20 >>> to reserve resources via signaling as the central entity is the only=20 >>> thing that can reserve or allocate resources. I'm thinking to an=20 >>> opening towards the integration with the SDN world. >>> >> >> Sure. Sounds like a Virtual TE link (per RFC6001, 5212). >> > IB>> Potential path can be defined as a feasible/provisionable path=20 > IB>> for > the server layer trail supporting an advertised VL, which has attributes = consistent with the ones advertised for the Virtual Link (noticeably, bandw= idth, SRLGs, etc.) and is guaranteed to be available at the moment of the s= et-up of a client LSP that has selected the VL in its path across the provi= der domain. >> >>> Just loud thinking, does it make sense? >>> >>> >From my perspective, I think a node in the overlay really shouldn't >>>> *directly* distinguish between the two -- now one may have a=20 >>>> different metric/SRLG/weight/etc, but these are abstracted=20 >>>> representations of the tradeoffs between use of the two, that can=20 >>>> be provided by the underlying provider network, rather than a=20 >>>> direct indication. >> > IB>> It is beneficial from the client (ONT user) path computation=20 > IB>> point of view to know whether the advertised VL is committed (the=20 > IB>> data plane is provisioned) or not. Selecting uncommitted VL means: >> a) Higher probability of a client LSP setup failure; >> b) Longer client LSP setup time; >> c) Probability of effectively removing other VLs from the ONT (those=20 >> that share MELGs with the VL in question) >=20 > And I'm suggesting that this be advertised using generic constructs such = as TE metric, SRLG, and even MELG, rather than adding yet another special c= ase computation/optimization parameter. >=20 >> >>>> >>>>> 2. Virtual Node: Virtual node is a collection of zero or more=20 >>>>> provider network domain nodes that are collectively >>>> represented to the >>>>> clients as a single node that exists in the customer layer >>>> network and >>>>> is capable of terminating of access, inter-domain and virtual links. >>>>> >>>> >>>> I'm a little uncomfortable with the linkage of real nodes to=20 >>>> virtual nodes. I think VN is a purely abstract concept that may be=20 >>>> instantiated using parts/whole/multiple/logical/real/etc nodes. >>> >> >> IB>> Agree completely >> >>> Makes sense. What this definition adds to the one in RFC4847 is=20 >>> basically the fact that also parts of a node can be considered. What=20 >>> saying that it can be a real node i meant 1:1 correspondance between=20 >>> a real and a virtual node. Your definition covers that case also,=20 >>> that's fine. >>> >>>> >>>> How about something like: >>>> Virtual Node: A virtual node is a representation of a collection of=20 >>>> provider resources that are interconnected via virtual (and >>>> customer) links. A virtual node may be collection of zero or=20 >>>> more, including portions of, provider nodes that are collectively=20 >>>> represented to the customer as a single node which is available in an = overlay network. >>> >>> Works for me. >>> >> >> Great. BTW I don't think 4847 precluded a single physical node being re= presented as multiple virtual nodes, but it doesn't hurt to make it explici= t. >> >>>> >>>>> 3. Virtual Topology: Virtual topology is a collection of one or=20 >>>>> more virtual or real provider network domain nodes that exist in=20 >>>>> the customer layer network and are interconnected via 0 or more=20 >>>>> virtual links. >>>> >>>> How about: >>>> Virtual Topology: A virtual topology is the collection of virtual=20 >>>> links and nodes advertised by a provider to a customer. The virtual=20 >>>> topology includes resources that are advertised as reachable within=20 >>>> an overlay network. >>>> >>>> Do you mean to imply/allow for a VN which has no links? >>> >>> The case of "interconnected via 0 virtual links" implies the whole=20 >>> domain seen as a single node. >>> >> >> Ahh, fair enough. >> >>>> >>>>> 4. Overlay topology: is a superset of virtual topologies >>>> provided by >>>>> each of provider network domains, access and inter-domain links. >>>>> >>>> >>>> Doesn't it also include any topology information advertised by the=20 >>>> customer/CE as well? >> >> IB>> Yes, it does: the ends of access links terminated by the clients=20 >> IB>> along with the custom NEs IDs >> >=20 > sounds like some agreement here. >=20 > I think that was you final comment... >=20 > Lou >=20 >>> >>> Possibly. Do you mean advertised by the CE in the customer domain, righ= t? >>> >> >> That's possible too, but I was thinking more of advertised by CE >> (customer) to PE (provider). >> >>>> >>>>> 5. Access Link: Link between OC and OE. GMPLS runs on that link.=20 >>>>> It can support any of the SCs supported by the GMPLS. >>>>> >>>> >>>> If we adopt RFC 4847 terminology it should be "customer interface". >>>> Also, I suspect you mean PE and CE. >>> >>> Mmm, yes but what if we want to manage it as a link? i.e. All=20 >>> TE-parameters that a link supports. Is it enough to call it=20 >>> interface only? >>> >> >> sure. Per 4847, I'd say that "customer interface" is the connection bet= ween CE/PE while [virtual] TE links are what is advertised/represented in r= outing. >> >>>> >>>>> 6. CE (customer Edge): Something like the CN in RFC4208 >>>> teminology but >>>>> (i) receiving virtual topology from the provider network and=20 >>>>> requesting the set up of one of them or (ii) requesting the=20 >>>>> computation and establishment of a path accordingly to given=20 >>>>> constraints in the provider network and receiving the parameters=20 >>>>> characterizing such path. (ii) =3D=3D UNI. >>>>> >>>> >>>> humm, I'm inclined to stay away from UNI for the moment. I also=20 >>>> suggest that we look to 4874 and even 4364 rather than 4208... >>> >>> Ok, we can refer to those RFC for what concerns terminology, but at=20 >>> the end of the day we must put the UNI under this framework. In the=20 >>> new terminology the UNI is a particular type of customer interface. >>> >> >> Fair enough. But it is a form on an overlay "customer interface" not th= e definitive form. >> >>>> >>>>> 7. PE (provider Edge): Something like the EN in RFC4208 but able=20 >>>>> to deal with (i) and (ii) above. >>>>> >>>> >>>> same comment WRT RFCs. >>>> >>>>> 8. PE-CE interface (former ONI) : Interface allowing for >>>> signaling and >>>>> routing messages exchange between customer overlay and provider=20 >>>>> network. Routing information consists on virtual topology=20 >>>>> advertisement. When there is no routing adjacency across the >>>> interface >>>>> it is equivalent to the GMPLS UNI defined in 4208. >>>>> Signaling messages are compliant with RFC4208. Information >>>> related to >>>>> path carachteristics, e.g. TE-metrics, collected SRLG, path >>>> delay etc, >>>>> either passed from CE to PE via signaling after the LSP >>>> establishment >>>>> in the core network or from CE to PE to be used as path=20 >>>>> computation constraints, fall under the definition of signaling=20 >>>>> info and not routing info). >>>>> >>>> >>>> >>>>> 9. CE-CE (former O-NNI): Interface on the links between different=20 >>>>> provider networks in the overlay model environment. Same features=20 >>>>> of the CE-PE apply to this interface. >>>>> >>>> >>>> you mean, PE-PE, right? >>> >>> You're not the first one that makes me notice i'm probably affected=20 >>> by dyslexia :-) >>> >> >> no problem, happens to the best of us! >> >>>> >>>>> + Statements 1. In the context of overlay model we are aiming to >>>>> build an overlay topology for the customer network domains >>>>> >>>>> 2. The overlay topology is comprised of: >>>>> a) access links (links connecting client NEs to the >>>> provider network domains). >>>>> They can be PSC or LSC. >>>>> b) inter-domain links (links interconnecting server >>>> network domains) >>>>> c) virtual topology provided by the provider network domains.=20 >>>>> Virtual Links >>>>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of=20 >>>>> + parameters >>>>> e.g. SRLG, optical impairments, delay etc for each entry)=20 >>>>> describing connectivity between access links and virtual links. >>>>> >>>>> 3. In the context of overlay model we manage hierarchy of=20 >>>>> overlay topologies with overlay/underlay relationships >>>>> >>>>> 4. In the context of overlay model multi-layering and inter-layer=20 >>>>> relationships are peripheral at best, it is all about horizontal=20 >>>>> network integration >>>>> >>>>> 5. The overlay model assumes one CP instance for the >>>> customer network >>>>> and a separate instance for the provider network and in the CE-PE=20 >>>>> interface case the provider network also surreptitiously >>>> participates >>>>> in the customer network by injecting virtual topology >>>> information into >>>>> it. >>>>> >>>> >>>> We should ensure we're allowing for some of the existing/augmented=20 >>>> models that permit the transport of overlay information within the=20 >>>> provider's CP, e.g., rfc4364, 5195 and 5252. >>> >>> I'd say they should be already covered, but will double check >>> >> >> great. >> >>>> >>>>> 6. L1VPN (and LxVPN) in general is a type of service >>>> provided over the >>>>> CE-PE interface (it falls under the UNI case as no routing=20 >>>>> adjacency is in place between CE and PE). >>>>> >>>>> >>>>> + Advertisement models (to be detailed in dedicated >>>>> + document/documents) >>>>> The CE-PE interface in the overlay model context foresees >>>> two types of >>>>> advertisement models.(names still to be agreed) >>>>> >>>>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >>>> augmented by >>>>> a number of actived draft (references to various drafts to >>>> be added).=20 >>>>> The Augmented UNI is a particular type of CE-PE interface where=20 >>>>> only signaling messages are exchanged between CE and PE. >>>>> Messages from CE to PE can include a set of parameters to be used=20 >>>>> by the PE as path computation constraints when computing a path in=20 >>>>> the provider domain network, while messages from PE to CE can=20 >>>>> include a set of parameters qualifying the LSP being established,=20 >>>>> like for example SRLG, delay, loss etc. >>>>> >>>> >>>> again, we can leverage 4874 terminology if we so choose, i.e.,=20 >>>> "basic mode" and "enhanced mode" UNI|NNI >>> >>> Don would be happy about that :-). I'd say yes. The goal was to=20 >>> cover the L1VPN work (enhanced mode), all the drafts-ali recently=20 >>> polled for wg adoption (basic mode?) and the actual ENNI (enhanced mode= ). >> >>> Is my mapping in brackets correct? >>> >> >> Not sure f I'd break it down they way you are. I'd say basic mode is cl= oser to the typical UNI and enhance mode is UNI+routing or perhaps even an = ENNI. >> >>> >>>> >>>>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >>>>> called with the general CE-PE interface term?) allowing the=20 >>>>> establishment of signaling and routing adjacency between CE and PE. >>>>> Routing info passed from PE to CE comprise overlay topology=20 >>>>> information including (but not limited to) virtual links, >>>> connectivity >>>>> matrices and access links with parameters qualifying each of them=20 >>>>> in terms of e.g. SRLG, loss, delay etc. Signaling information and=20 >>>>> procedures are compliant with RFC4208. >>>>> >>>> >>>> so this is just and 4874 "enhanced mode" interface, right. >>> >>> Good question: the enhanced mode supports signaling and routing, so=20 >>> i'd say yes, but reading section 7.3 it talks about "limited=20 >>> exchange of information between the control planes. >>> >>> "permits limited exchange of >>> information between the control planes of the provider and the >>> customer to help such functions as discovery of customer network >>> routing information (i.e., reachability or TE information in remote >>> customer sites), or parameters of the part of the provider's network >>> dedicated to the customer." >>> >>> Would you say this includes what we want? (i.e. Virtual links,=20 >>> virtual nodes, connectivity matrices, SRLG, delay, loss, etc) If yes=20 >>> we're done, otherwise an option could be the denition of a third VPN=20 >>> service model. >>> >> >> humm, need to think about this. Perhaps the best thing is to=20 >> document the two different cases and then decide if we have something=20 >> new or >> (two) more detailed forms of something old. >> >>>> >>>>> + Open issues/questions >>>>> 1. PCE-PCEP - do we need to include considerations about PCE >>>> and PCEP >>>>> into the overlay framework context? >>>>> >>>>> 2. BGP-LS needs to be considered >>>>> 3. Should potentials be included? E.g. I2RS? >>>>> 4. Virtual links: wouldn't a different definition of virtual links=20 >>>>> avoid the advertisement of connectivity matrices (this is out of=20 >>>>> the fwk scope but within the advertisement models one)? >>>>> >>>> >>>>> Take this example: >>>>> PE1-----CE1 CE2-----PE2 >>>>> CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>>>> CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>>> >>>> I think you've reversed CE and PE here... >>> >>> Yes, once again. >>> >>> No comment on my foolish proposal? >>> >> >> Which one? I liked your summary overall. >> >> Lou >> >>> >>>> >>>> Much thanks! >>>> >>>> Lou >>>> (hatless...) >>>> >>>>> i.e. There are 2 VL connecting CE1 and CE2 that could be >>>> available for >>>>> PE1 and PE2 to set up an adjacency in the customer domain.=20 >>>> CE1 and/or >>>>> CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>>>> depending on the connectivity matrices of CE1 and CE2. Hence >>>> PEs need >>>>> to be aware of both VL and connectivity matrices. My point >>>> is: if CE1 >>>>> advertises to PE1 only the VL that his connectivity matrix allows=20 >>>>> to be connected to PE1 (e.g. VL1 only) and not all of them, it >>>> should be >>>>> possible to avoid the connectivity matrices advertisement. >>>>> >>>> >>>>> =20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> DANIELE CECCARELLI >>>>> System & Technology - PDU Optical & Metro >>>>> >>>>> Via E.Melen, 77 >>>>> Genova, Italy >>>>> Phone +390106002512 >>>>> Mobile +393346725750 >>>>> daniele.ceccarelli@ericsson.com >>>>> www.ericsson.com >>>>> >>>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> >=20 >=20 >=20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From SBardalai@infinera.com Tue Jan 22 15:06:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755B121F8A66 for ; Tue, 22 Jan 2013 15:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6] 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 j5K53c3kz4nj for ; Tue, 22 Jan 2013 15:05:56 -0800 (PST) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7B37221F8A7B for ; Tue, 22 Jan 2013 15:05:38 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0318.004; Tue, 22 Jan 2013 15:05:37 -0800 From: Snigdho Bardalai To: Gert Grammel , Lou Berger , Daniele Ceccarelli Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBokCIAAJEUjAAAD8STgAAm5+/AAA0LBcA= Date: Tue, 22 Jan 2013 23:05:36 +0000 Message-ID: <6386D6323049044BA592CB99AB04BACB3F949213@SV-EXDB-PROD1.infinera.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <305443B66F0CD946A3107753337A031113F8F831@CH1PRD0511MB431.namprd05.prod.outlook.com> In-Reply-To: <305443B66F0CD946A3107753337A031113F8F831@CH1PRD0511MB431.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_6386D6323049044BA592CB99AB04BACB3F949213SVEXDBPROD1infi_" MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:06:07 -0000 --_000_6386D6323049044BA592CB99AB04BACB3F949213SVEXDBPROD1infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gert, Sorry, but I have to disagree with your statement (BTW - are we going in ci= rcles - I thought we had already beaten this topic to death :)). It is poss= ible to have client-server relationships totally contained within a custome= r or provider network and not visible across the CE-PE or PE-PE interface. = That is the reason why we need to keep client/server and customer/provider = boundaries completely independent of each other. Thanks Snigdho From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= ert Grammel Sent: Tuesday, January 22, 2013 2:34 PM To: Lou Berger; Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Hi Lou, Daniele, Thanks for summarizing, seems we are converging. Related to terminology I s= till think that 'customer' and 'provider' give the wrong connotation for ov= erlay networks. While a VPN can be seen as a service, hence both terms migh= t have some justification, a Overlay-UNI/ENNI does not. It's simply a name = for a control interface that can be used internally in a network without ne= cessarily providing a customer with any new service. Having to choose betwe= en 'Customer-Provider' or 'Client-Server' terminology , the latter fits muc= h better to what we call Overlay. To move on with terminology we may want to preserve the abbreviations by ad= ding 'overlay': 1. Overlay-Provider-edge (OPE) - at least it provides a topology to t= he client 2. Overlay-Client-edge (OCE) - Note there is no customer here, it's a= client About Virtual topology 3): =B7 real-nodes vs. virtual nodes: from a OCE perspective there shal= l be no difference. In other words there shall be no difference between an = OPE Network exposing virtual nodes and an equivalent OPE network where each= virtual node is replaced by a real node of equal characteristic. I would support the connotation of a UNI, an augmented UNI and an O(verlay)= NNI (or OCE-OPE interface): 1. UNI: signaling only, no topology information exchanged (targeted f= or a customer/provider interface where Client=3Dcustomer) 2. Augmented-UNI: signaling only, with post-provisioned topology info= rmation of LSPs 3. ONNI: signaling and routing , where routing injects topology infor= mation independent of LSPs Best Gert -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Lou Berger Sent: Montag, 21. Januar 2013 23:13 To: Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Thanks Daniele, See below. On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: > Hi Lou, > > Please find comments in line > > BR > Daniele > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: venerd=EC 18 gennaio 2013 18.27 >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Daniele, >> Very nice summary. Just catching up, so sorry for the >> (2 day) late response. >> >> I really like how the terminology has evolved and appreciate the >> summary! >> >> I have a few detail comments, but before I go there I'd like to cover >> one more open issue that I think will have some >> (minor) ripple effects on the details. >> >> I think there's still the general issue of terminology to use when >> referring to the entity that "uses an overlay" and the entity that >> "instantiates the overlay". In your mail and in discussion we have: >> >> - client (service)/OC/CN/customer >> >> and >> >> - server(or service)/OE/EN/provider >> >> I think we had discussed, and possibly agreed on, using VPN >> terminology which would have us use the latter options, i.e., >> (overlay) customer/provider (edge). This would mean eliminating any >> references to client/server in the *generic >> overlay* definitions. Of course these terms may reemerge in other >> contexts as they have before, e.g., rfc6215. > > Yes, i think we all agreed. If there are still terms different from > customer/provider in the text it's because i missed them during the > replacing. > Great! Glad I didn't miss something over the holidays! >> >> I like this approach as it is aligned with the much of IETF work on >> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). >> Importantly, RFC 4847 even has quite a few concepts that can be >> directly leveraged in this discussion. >> >> I'd even go further and say that we should base the definitions and >> resulting framework on RFC 4847. For example, the definitions below >> could start with something along the lines: >> >> The overlay service model, at a high level, follows Section >> 7. of RFC 4847 as represented by: >> >> >> +--------------------+ >> : | | : >> : | | : >> +----+ : +----+ +----+ : +----+ >> | CE |---:---| PE | | PE |---:---| CE | >> +----+ : +----+ +----+ : +----+ >> : | | : >> : | | : >> : +--------------------+ : >> : | | : >> : |<-Provider network->| : >> Customer Customer >> interface interface >> >> Figure 7.2: Overlay Service Model >> >> In this model, the overlay is instantiated by an overlay >> "provider" and its provider edge (PE) nodes , and is used by >> the overlay "customer" which is connected to the provider via >> customer interfaces attached to customer edge (CE) nodes. >> >> ... >> >> The definition below would need to be tweaked slightly, notably to >> remove any references to client and server. The resulting framework >> can also refer back to RFC 4847 as needed. >> >> See below for some additional comments. >> >> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>> Dear overlayers, >>> >>> Please find below a new version (v2) of the framework summary >>> reflecting the latest discussions. Again i hope i've >> captured all the >>> comments around, sorry if anything is missing, in case just let me >>> know what i missed. >>> >>> BR >>> Daniele >>> >>> >>> + Disclaimer: >>> 1. Packet opto integration is often considered but the work can be >>> extented to any type of SC. Eg. TDM over LSC. >>> >>> + Terminology: >>> 1. Virtual Link: A virtual link is a potential path between two >>> virtual or real network elements in a provider layer network >> that is >>> maintained/controlled in and by the provider domain control >> plane (and >>> as such cannot transport any traffic/data and protected from being >>> de-provisioned) and which can be instantiated in the data plane (and >>> then can carry/transport/forward traffic/data) preserving previously >>> advertised attributes such as fate sharing information. >>> >> >> You say "potential path". I this this should read "potential or >> instantiated path". >> > > Maybe we need to define also what "potential" stands for? At least two > cases come to my mind (which might be included under the "potential" > umbrella): > > 1. resources reserved via signaling but not instantiated Sure. Sounds like a RFC6001 soft FA. > 2. resources not even signaled. In presence of a centralized entity > managing the network (sort of PCE plus something) there is no need to > reserve resources via signaling as the central entity is the only > thing that can reserve or allocate resources. I'm thinking to an > opening towards the integration with the SDN world. > Sure. Sounds like a Virtual TE link (per RFC6001, 5212). > Just loud thinking, does it make sense? > >>From my perspective, I think a node in the overlay really shouldn't >> *directly* distinguish between the two -- now one may have a >>different metric/SRLG/weight/etc, but these are abstracted >>representations of the tradeoffs between use of the two, that can be >>provided by the underlying provider network, rather than a direct >>indication. >> >>> 2. Virtual Node: Virtual node is a collection of zero or more >>> provider network domain nodes that are collectively >> represented to the >>> clients as a single node that exists in the customer layer >> network and >>> is capable of terminating of access, inter-domain and virtual links. >>> >> >> I'm a little uncomfortable with the linkage of real nodes to virtual >> nodes. I think VN is a purely abstract concept that may be >> instantiated using parts/whole/multiple/logical/real/etc nodes. > > Makes sense. What this definition adds to the one in RFC4847 is > basically the fact that also parts of a node can be considered. What > saying that it can be a real node i meant 1:1 correspondance between a > real and a virtual node. Your definition covers that case also, that's > fine. > >> >> How about something like: >> Virtual Node: A virtual node is a representation of a collection of >> provider resources that are interconnected via virtual (and customer) >> links. A virtual node may be collection of zero or more, including >> portions of, provider nodes that are collectively represented to the >> customer as a single node which is available in an overlay network. > > Works for me. > Great. BTW I don't think 4847 precluded a single physical node being repre= sented as multiple virtual nodes, but it doesn't hurt to make it explicit. >> >>> 3. Virtual Topology: Virtual topology is a collection of one or more >>> virtual or real provider network domain nodes that exist in the >>> customer layer network and are interconnected via 0 or more virtual >>> links. >> >> How about: >> Virtual Topology: A virtual topology is the collection of virtual >> links and nodes advertised by a provider to a customer. The virtual >> topology includes resources that are advertised as reachable within >> an overlay network. >> >> Do you mean to imply/allow for a VN which has no links? > > The case of "interconnected via 0 virtual links" implies the whole > domain seen as a single node. > Ahh, fair enough. >> >>> 4. Overlay topology: is a superset of virtual topologies >> provided by >>> each of provider network domains, access and inter-domain links. >>> >> >> Doesn't it also include any topology information advertised by the >> customer/CE as well? > > Possibly. Do you mean advertised by the CE in the customer domain, right? > That's possible too, but I was thinking more of advertised by CE (customer) to PE (provider). >> >>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It >>> can support any of the SCs supported by the GMPLS. >>> >> >> If we adopt RFC 4847 terminology it should be "customer interface". >> Also, I suspect you mean PE and CE. > > Mmm, yes but what if we want to manage it as a link? i.e. All > TE-parameters that a link supports. Is it enough to call it interface > only? > sure. Per 4847, I'd say that "customer interface" is the connection betwee= n CE/PE while [virtual] TE links are what is advertised/represented in rout= ing. >> >>> 6. CE (customer Edge): Something like the CN in RFC4208 >> teminology but >>> (i) receiving virtual topology from the provider network and >>> requesting the set up of one of them or (ii) requesting the >>> computation and establishment of a path accordingly to given >>> constraints in the provider network and receiving the parameters >>> characterizing such path. (ii) =3D=3D UNI. >>> >> >> humm, I'm inclined to stay away from UNI for the moment. I also >> suggest that we look to 4874 and even 4364 rather than 4208... > > Ok, we can refer to those RFC for what concerns terminology, but at > the end of the day we must put the UNI under this framework. In the > new terminology the UNI is a particular type of customer interface. > Fair enough. But it is a form on an overlay "customer interface" not the d= efinitive form. >> >>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to >>> deal with (i) and (ii) above. >>> >> >> same comment WRT RFCs. >> >>> 8. PE-CE interface (former ONI) : Interface allowing for >> signaling and >>> routing messages exchange between customer overlay and provider >>> network. Routing information consists on virtual topology >>> advertisement. When there is no routing adjacency across the >> interface >>> it is equivalent to the GMPLS UNI defined in 4208. >>> Signaling messages are compliant with RFC4208. Information >> related to >>> path carachteristics, e.g. TE-metrics, collected SRLG, path >> delay etc, >>> either passed from CE to PE via signaling after the LSP >> establishment >>> in the core network or from CE to PE to be used as path computation >>> constraints, fall under the definition of signaling info and not >>> routing info). >>> >> >> >>> 9. CE-CE (former O-NNI): Interface on the links between different >>> provider networks in the overlay model environment. Same features of >>> the CE-PE apply to this interface. >>> >> >> you mean, PE-PE, right? > > You're not the first one that makes me notice i'm probably affected by > dyslexia :-) > no problem, happens to the best of us! >> >>> + Statements 1. In the context of overlay model we are aiming to >>> build an overlay topology for the customer network domains >>> >>> 2. The overlay topology is comprised of: >>> a) access links (links connecting client NEs to the >> provider network domains). >>> They can be PSC or LSC. >>> b) inter-domain links (links interconnecting server >> network domains) >>> c) virtual topology provided by the provider network domains. >>> Virtual Links >>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of >>> + parameters >>> e.g. SRLG, optical impairments, delay etc for each entry) describing >>> connectivity between access links and virtual links. >>> >>> 3. In the context of overlay model we manage hierarchy of overlay >>> topologies with overlay/underlay relationships >>> >>> 4. In the context of overlay model multi-layering and inter-layer >>> relationships are peripheral at best, it is all about horizontal >>> network integration >>> >>> 5. The overlay model assumes one CP instance for the >> customer network >>> and a separate instance for the provider network and in the CE-PE >>> interface case the provider network also surreptitiously >> participates >>> in the customer network by injecting virtual topology >> information into >>> it. >>> >> >> We should ensure we're allowing for some of the existing/augmented >> models that permit the transport of overlay information within the >> provider's CP, e.g., rfc4364, 5195 and 5252. > > I'd say they should be already covered, but will double check > great. >> >>> 6. L1VPN (and LxVPN) in general is a type of service >> provided over the >>> CE-PE interface (it falls under the UNI case as no routing adjacency >>> is in place between CE and PE). >>> >>> >>> + Advertisement models (to be detailed in dedicated >>> + document/documents) >>> The CE-PE interface in the overlay model context foresees >> two types of >>> advertisement models.(names still to be agreed) >>> >>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >> augmented by >>> a number of actived draft (references to various drafts to >> be added). >>> The Augmented UNI is a particular type of CE-PE interface where only >>> signaling messages are exchanged between CE and PE. >>> Messages from CE to PE can include a set of parameters to be used by >>> the PE as path computation constraints when computing a path in the >>> provider domain network, while messages from PE to CE can include a >>> set of parameters qualifying the LSP being established, like for >>> example SRLG, delay, loss etc. >>> >> >> again, we can leverage 4874 terminology if we so choose, i.e., "basic >> mode" and "enhanced mode" UNI|NNI > > Don would be happy about that :-). I'd say yes. The goal was to cover > the L1VPN work (enhanced mode), all the drafts-ali recently polled > for wg adoption (basic mode?) and the actual ENNI (enhanced mode). > Is my mapping in brackets correct? > Not sure f I'd break it down they way you are. I'd say basic mode is close= r to the typical UNI and enhance mode is UNI+routing or perhaps even an ENN= I. > >> >>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >>> called with the general CE-PE interface term?) allowing the >>> establishment of signaling and routing adjacency between CE and PE. >>> Routing info passed from PE to CE comprise overlay topology >>> information including (but not limited to) virtual links, >> connectivity >>> matrices and access links with parameters qualifying each of them in >>> terms of e.g. SRLG, loss, delay etc. Signaling information and >>> procedures are compliant with RFC4208. >>> >> >> so this is just and 4874 "enhanced mode" interface, right. > > Good question: the enhanced mode supports signaling and routing, so > i'd say yes, but reading section 7.3 it talks about "limited exchange > of information between the control planes. > > "permits limited exchange of > information between the control planes of the provider and the > customer to help such functions as discovery of customer network > routing information (i.e., reachability or TE information in remote > customer sites), or parameters of the part of the provider's network > dedicated to the customer." > > Would you say this includes what we want? (i.e. Virtual links, virtual > nodes, connectivity matrices, SRLG, delay, loss, etc) If yes we're > done, otherwise an option could be the denition of a third VPN service > model. > humm, need to think about this. Perhaps the best thing is to document the = two different cases and then decide if we have something new or (two) more detailed forms of something old. >> >>> + Open issues/questions >>> 1. PCE-PCEP - do we need to include considerations about PCE >> and PCEP >>> into the overlay framework context? >>> >>> 2. BGP-LS needs to be considered >>> 3. Should potentials be included? E.g. I2RS? >>> 4. Virtual links: wouldn't a different definition of virtual links >>> avoid the advertisement of connectivity matrices (this is out of the >>> fwk scope but within the advertisement models one)? >>> >> >>> Take this example: >>> PE1-----CE1 CE2-----PE2 >>> CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>> CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >> >> I think you've reversed CE and PE here... > > Yes, once again. > > No comment on my foolish proposal? > Which one? I liked your summary overall. Lou > >> >> Much thanks! >> >> Lou >> (hatless...) >> >>> i.e. There are 2 VL connecting CE1 and CE2 that could be >> available for >>> PE1 and PE2 to set up an adjacency in the customer domain. >> CE1 and/or >>> CE2 can be blocking nodes so VL1 and/or VL2 are available only >>> depending on the connectivity matrices of CE1 and CE2. Hence >> PEs need >>> to be aware of both VL and connectivity matrices. My point >> is: if CE1 >>> advertises to PE1 only the VL that his connectivity matrix allows to >>> be connected to PE1 (e.g. VL1 only) and not all of them, it >> should be >>> possible to avoid the connectivity matrices advertisement. >>> >> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> DANIELE CECCARELLI >>> System & Technology - PDU Optical & Metro >>> >>> Via E.Melen, 77 >>> Genova, Italy >>> Phone +390106002512 >>> Mobile +393346725750 >>> daniele.ceccarelli@ericsson.com >>> www.ericsson.com >>> >> > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_6386D6323049044BA592CB99AB04BACB3F949213SVEXDBPROD1infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Gert,

 

Sorry, but I have to d= isagree with your statement (BTW - are we going in circles – I though= t we had already beaten this topic to death J). It is possible to have client-server relationships= totally contained within a customer or provider network and not visible ac= ross the CE-PE or PE-PE interface. That is the reason why we need to keep client/server and customer/provider boun= daries completely independent of each other.

 

Thanks

Snigdho

 

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Gert Grammel
Sent: Tuesday, January 22, 2013 2:34 PM
To: Lou Berger; Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

 

Hi Lou, Daniele,

 

Thanks for summarizing, seems we are converging. = Related to terminology I still think that 'customer' and 'provider' give th= e wrong connotation for overlay networks. While a VPN can be seen as a serv= ice, hence both terms might have some justification, a Overlay-UNI/ENNI does not. It's simply a name for a contr= ol interface that can be used internally in a network without necessarily p= roviding a customer with any new service. Having to choose between ‘C= ustomer-Provider’ or ‘Client-Server’ terminology , the latter fits much better to what we call Overlay.  

 

To move on with terminology we may want to preser= ve the abbreviations by adding 'overlay':

1.       Overlay-Provider-edge (OPE) – at least it pro= vides a topology to the client

2.       Overlay-Client-edge (OCE) - Note there is no custom= er here, it’s a client

 

About Virtual topology 3):

=B7&nbs= p;        real-nodes vs. virtual nodes: from a OCE per= spective there shall be no difference. In other words there shall be no dif= ference between an OPE Network exposing virtual nodes and an equivalent OPE= network where each virtual node is replaced by a real node of equal characteristic.

 

I would support the connotation of a UNI, an augm= ented UNI and an O(verlay)NNI (or OCE-OPE interface):

1.       UNI: signaling only, no topology information exchan= ged (targeted for a customer/provider interface where Client=3Dcustomer)

2.       Augmented-UNI: signaling only, with post-provisione= d topology information of LSPs

3.       ONNI: signaling and routing , where routing injects= topology information independent of LSPs

 

Best

 

Gert

 

 

-----Original Message-----
From: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Montag, 21. Januar 2013 23:13
To: Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

 

Thanks Daniele, See below.=

 

On 1/21/2013 9:41 AM, Daniele C= eccarelli wrote:

> Hi Lou,<= /p>

>

> Please find comments in li= ne

>

> BR

> Daniele<= /p>

>

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

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

>> Sent: venerd=EC 18 gen= naio 2013 18.27

>> To: Daniele Ceccarelli=

>> Cc: CCAMP

>> Subject: Re: [CCAMP] O= verlay model framework v2

>> 

>> Daniele,

>>    &nbs= p;     Very nice summary.  Just catching up, so so= rry for the

>> (2 day) late response.=

>> 

>> I really like how the = terminology has evolved and appreciate the

>> summary!

>> 

>> I have a few detail co= mments, but before I go there I'd like to cover

>> one more open issue th= at I think will have some

>> (minor) ripple effects= on the details.

>> 

>> I think there's still = the general issue of terminology to use when

>> referring to the entit= y that "uses an overlay" and the entity that

>> "instantiates the= overlay".  In your mail and in discussion we have:

>> 

>> - client (service)/OC/= CN/customer

>> 

>> and<= /p>

>> 

>> - server(or service)/O= E/EN/provider

>> 

>> I think we had discuss= ed, and possibly agreed on, using VPN

>> terminology which woul= d have us use the latter options, i.e.,

>> (overlay) customer/pro= vider (edge).  This would mean eliminating any

>> references to client/s= erver in the *generic

>> overlay* definitions.&= nbsp; Of course these terms may reemerge in other

>> contexts as they have = before, e.g., rfc6215.

>

> Yes, i think we all agreed= . If there are still terms different from

> customer/provider in the t= ext it's because i missed them during the

> replacing.

>

 

Great!  Glad I didn't miss= something over the holidays!

 

>> 

>> I like this approach a= s it is aligned with the much of IETF work on

>> overlays (e.g., BGP L3= /L2 VPNs) as well as the L1VPN (e.g. RFC 4847). 

>> Importantly, RFC 4847 = even has quite a few concepts that can be

>> directly leveraged in = this discussion.

>> 

>> I'd even go further an= d say that we should base the definitions and

>> resulting framework on= RFC 4847.  For example, the definitions below

>> could start with somet= hing along the lines:

>> 

>>    The = overlay service model, at a high level, follows Section

>>    7. o= f RFC 4847 as represented by:

>> 

>> 

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

>>    = ;            &n= bsp; :     |       &= nbsp;            |&n= bsp;    :

>>    = ;            &n= bsp; :     |       &= nbsp;            |&n= bsp;    :

>>    = ;     +----+   :   +---= -+           &nb= sp;  +----+   :   +----+

>>    = ;     | CE |---:---| PE |     =          | PE |---:---| CE |

>>    = ;     +----+   :   +---= -+           &nb= sp;  +----+   :   +----+

>>    = ;            &n= bsp; :     |       &= nbsp;            |&n= bsp;    :

>>    = ;            &n= bsp; :     |       &= nbsp;            |&n= bsp;    :

>>    = ;            &n= bsp; :     +--------------------+  &n= bsp;  :

>>    = ;            &n= bsp; :     |       &= nbsp;            |&n= bsp;    :

>>    = ;            &n= bsp; :     |<-Provider network->|  &nbs= p;  :

>>    = ;         Customer   = ;            &n= bsp;           Customer

>>    = ;         interface  &nbs= p;             =           interface<= /o:p>

>> 

>>    = ;            &n= bsp; Figure 7.2: Overlay Service Model

>> 

>>    In t= his model, the overlay is instantiated by an overlay

>>    &quo= t;provider" and its provider edge (PE) nodes , and is used by

>>    the = overlay "customer" which is connected to the provider via

>>    cust= omer interfaces attached to customer edge (CE) nodes.

>> 

>>    ...<= o:p>

>> 

>> The definition below w= ould need to be tweaked slightly, notably to

>> remove any references = to client and server.  The resulting framework

>> can also refer back to= RFC 4847 as needed.

>> 

>> See below for some add= itional comments.

>> 

>> On 1/16/2013 10:33 AM,= Daniele Ceccarelli wrote:

>>> Dear overlayers,

>>> 

>>> Please find below = a new version (v2) of the framework summary

>>> reflecting the lat= est discussions. Again i hope i've

>> captured all the<= /o:p>

>>> comments around, s= orry if anything is missing, in case just let me

>>> know what i missed= .

>>> 

>>> BR

>>> Daniele=

>>> 

>>> 

>>> + Disclaimer:<= o:p>

>>> 1. Packet opto int= egration is often considered but the work can be

>>> extented to any ty= pe of SC. Eg. TDM over LSC.

>>> 

>>> + Terminology:=

>>> 1. Virtual Link: A= virtual link is a potential path between two

>>> virtual or real ne= twork elements in a provider layer network

>> that is

>>> maintained/control= led in and by the provider domain control

>> plane (and<= /span>

>>> as such cannot tra= nsport any traffic/data and protected from being

>>> de-provisioned) an= d which can be instantiated in the data plane (and

>>> then can carry/tra= nsport/forward traffic/data) preserving previously

>>> advertised attribu= tes such as fate sharing information.

>>> 

>> 

>> You say "potentia= l path".  I this this should read  "potential or

>> instantiated path"= ;.

>> 

>

> Maybe we need to define al= so what "potential" stands for? At least two

> cases come to my mind (whi= ch might be included under the "potential"

> umbrella):

>

> 1. resources reserved via = signaling but not instantiated

 

Sure.  Sounds like a RFC60= 01 soft FA.

 

> 2. resources not even sign= aled. In presence of a centralized entity

> managing the network (sort= of PCE plus something) there is no need to

> reserve resources via sign= aling as the central entity is the only

> thing that can reserve or = allocate resources. I'm thinking to an

> opening towards the integr= ation with the SDN world.

>

 

Sure.  Sounds like a Virtu= al TE link (per RFC6001, 5212).

 

> Just loud thinking, does i= t make sense?

>

>>From my perspective, I = think a node in the overlay really shouldn't

>> *directly* distinguish= between the two -- now one may have a 

>>different metric/SRLG/w= eight/etc, but these are abstracted 

>>representations of the = tradeoffs between use of the two, that  can be

>>provided by the underly= ing provider network, rather  than a direct

>>indication.<= /span>

>> 

>>> 2.  Virtual N= ode: Virtual node is a collection of zero or more

>>> provider network d= omain nodes that are collectively

>> represented to the

>>> clients as a singl= e node that exists in the customer layer

>> network and=

>>> is capable of term= inating of access, inter-domain and virtual links.

>>> 

>> 

>> I'm a little uncomfort= able with the linkage of real nodes to virtual

>> nodes.  I think V= N is a purely abstract concept that may be

>> instantiated using par= ts/whole/multiple/logical/real/etc nodes.

>

> Makes sense. What this def= inition adds to the one in RFC4847 is

> basically the fact that al= so parts of a node can be considered. What

> saying that it can be a re= al node i meant 1:1 correspondance between a

> real and a virtual node. Y= our definition covers that case also, that's

> fine.

>

>> 

>> How about something li= ke:

>> Virtual Node: A virtua= l node is a representation of a collection of

>> provider resources tha= t are interconnected via virtual (and customer)

>> links.  A virtual= node may be collection of zero or more, including

>> portions of, provider = nodes that are collectively represented to the

>> customer as a single n= ode which is available in an overlay network.

>

> Works for me.

>

 

Great.  BTW I don't think = 4847 precluded a single physical node being represented as multiple virtual= nodes, but it doesn't hurt to make it explicit.

 

>> 

>>> 3. Virtual Topolog= y: Virtual topology is a collection of one or more

>>> virtual or real pr= ovider network domain nodes that exist in the

>>> customer layer net= work and are interconnected via 0 or more virtual

>>> links.<= /span>

>> 

>> How about:<= /span>

>> Virtual Topology: A vi= rtual topology is the collection of virtual

>> links and nodes advert= ised by a provider to a customer. The virtual

>> topology includes reso= urces that are advertised as reachable within

>> an overlay network.

>> 

>> Do you mean to imply/a= llow for a VN which has no links?

>

> The case of "intercon= nected via 0 virtual links" implies the whole

> domain seen as a single no= de.

>

 

Ahh, fair enough.

 

>> 

>>> 4. Overlay topolog= y:  is a superset of virtual topologies

>> provided by=

>>> each of provider n= etwork domains, access and inter-domain links.

>>> 

>> 

>> Doesn't it also includ= e any topology information advertised by the

>> customer/CE as well?

>

> Possibly. Do you mean adve= rtised by the CE in the customer domain, right?

>

 

That's possible too, but I was = thinking more of advertised by CE

(customer) to PE (provider).

 

>> 

>>> 5. Access Link: Li= nk between OC and OE. GMPLS runs on that link. It

>>> can support any of= the SCs supported by the GMPLS.

>>> 

>> 

>> If we adopt RFC 4847 t= erminology it should be "customer interface".

>> Also, I suspect you me= an PE and CE.

>

> Mmm, yes but what if we wa= nt to manage it as a link? i.e. All

> TE-parameters that a link = supports. Is it enough to call it interface

> only?

>

 

sure.  Per 4847, I'd say t= hat "customer interface" is the connection between CE/PE while [v= irtual] TE links are what is advertised/represented in routing.<= /span>

 

>> 

>>> 6. CE (customer Ed= ge): Something like the CN in RFC4208

>> teminology but

>>> (i) receiving virt= ual topology from the provider network and

>>> requesting the set= up of one of them or (ii) requesting the

>>> computation and es= tablishment of a path accordingly to given

>>> constraints in the= provider network and receiving the parameters

>>> characterizing suc= h path. (ii) =3D=3D UNI.

>>> 

>> 

>> humm, I'm inclined to = stay away from UNI for the moment.  I also

>> suggest that we look t= o 4874 and even 4364 rather than 4208...

>

> Ok, we can refer to those = RFC for what concerns terminology, but at

> the end of the day we must= put the UNI under this framework. In the

> new terminology the UNI is= a particular type of customer interface.

>

 

Fair enough.  But it is a = form on an overlay "customer interface" not the definitive form.<= o:p>

 

>> 

>>> 7. PE (provider Ed= ge): Something like the EN in RFC4208 but able to

>>> deal with (i) and = (ii) above.

>>> 

>> 

>> same comment WRT RFCs.=

>> 

>>> 8. PE-CE interface= (former ONI) : Interface allowing for

>> signaling and

>>> routing messages e= xchange between customer overlay and provider

>>> network. Routing i= nformation consists on virtual topology

>>> advertisement. Whe= n there is no routing adjacency across the

>> interface

>>> it is equivalent t= o the GMPLS UNI defined in 4208.

>>> Signaling messages= are compliant with RFC4208. Information

>> related to<= /span>

>>> path carachteristi= cs, e.g. TE-metrics, collected SRLG, path

>> delay etc,<= /span>

>>> either passed from= CE to PE via signaling after the LSP

>> establishment

>>> in the core networ= k or from CE to PE to be used as path computation

>>> constraints, fall = under the definition of signaling info and not

>>> routing info).

>>> 

>> 

>> 

>>> 9. CE-CE (former O= -NNI): Interface on the links between different

>>> provider networks = in the overlay model environment. Same features of

>>> the CE-PE apply to= this interface.

>>> 

>> 

>> you mean, PE-PE, right= ?

>

> You're not the first one t= hat makes me notice i'm probably affected by

> dyslexia :-)

>

 

no problem, happens to the best= of us!

 

>> 

>>> + Statements 1= . In the context of overlay model we are aiming to

>>> build an overlay t= opology for the customer network domains

>>> 

>>>  2. The overl= ay topology is comprised of:

>>>   &= nbsp; a) access links (links connecting client NEs to the=

>> provider network domai= ns).

>>>  They can be = PSC or LSC.

>>>   &= nbsp; b) inter-domain links (links interconnecting server=

>> network domains)<= /o:p>

>>>   &= nbsp; c) virtual topology provided by the provider network domains.

>>> Virtual Links=

>>> + Virtual Node= s (TBD) + Connectivity Matrix (with a set of

>>> + parameters

>>> e.g. SRLG, optical= impairments, delay etc for each entry) describing

>>> connectivity betwe= en access links and virtual links.

>>> 

>>> 3. In the context = of overlay model we manage  hierarchy  of overlay

>>> topologies with ov= erlay/underlay relationships

>>> 

>>> 4. In the context = of overlay model multi-layering and inter-layer

>>> relationships are = peripheral at best, it is all about horizontal

>>> network integratio= n

>>> 

>>> 5. The overlay mod= el assumes one CP instance for the

>> customer network<= /o:p>

>>> and a separate ins= tance for the provider network and in the CE-PE

>>> interface case the= provider network also surreptitiously

>> participates

>>> in the customer ne= twork by injecting virtual topology

>> information into<= /o:p>

>>> it.

>>> 

>> 

>> We should ensure we're= allowing for some of the existing/augmented

>> models that permit the= transport of overlay information within the

>> provider's CP, e.g., r= fc4364, 5195 and 5252.

>

> I'd say they should be alr= eady covered, but will double check

>

 

great.

 

>> 

>>> 6. L1VPN (and LxVP= N) in general is a type of service

>> provided over the=

>>> CE-PE interface (i= t falls under the UNI case as no routing adjacency

>>> is in place betwee= n CE and PE).

>>> 

>>> 

>>> + Advertisemen= t models (to be detailed in dedicated

>>> + document/doc= uments)

>>> The CE-PE interfac= e in the overlay model context foresees

>> two types of

>>> advertisement mode= ls.(names still to be agreed)

>>> 

>>> A. Augmented UNI: = The GMPLS UNI is defined in RFC4208 and

>> augmented by

>>> a number of active= d draft (references to various drafts to

>> be added). =

>>> The Augmented UNI = is a particular type of CE-PE interface where only

>>> signaling messages= are exchanged between CE and PE.

>>> Messages from CE t= o PE can include a set of parameters to be used by

>>> the PE as path com= putation constraints when computing a path in the

>>> provider domain ne= twork, while messages from PE to CE can include a

>>> set of parameters = qualifying the LSP being established, like for

>>> example SRLG, dela= y, loss etc.

>>> 

>> 

>> again, we can leverage= 4874 terminology if we so choose, i.e., "basic

>> mode" and "e= nhanced mode" UNI|NNI

>

> Don would be happy about t= hat :-). I'd say yes. The goal was to cover

> the L1VPN work (enhanced m= ode),  all the drafts-ali recently polled

> for wg adoption (basic mod= e?) and the actual ENNI (enhanced mode).

 

> Is my mapping in brackets = correct?

>

 

Not sure f I'd break it down th= ey way you are.  I'd say basic mode is closer to the typical UNI and e= nhance mode is UNI+routing or perhaps even an ENNI.

 

>

>> 

>>> B. ONI: The GMPLS = ONI is a CE-PE interface (this could be simply

>>> called with the ge= neral CE-PE interface term?) allowing the

>>> establishment of s= ignaling and routing adjacency between CE and PE.

>>> Routing info passe= d from PE to CE comprise overlay topology

>>> information includ= ing (but not limited to) virtual links,

>> connectivity

>>> matrices and acces= s links with parameters qualifying each of them in

>>> terms of e.g. SRLG= , loss, delay etc. Signaling information and

>>> procedures are com= pliant with RFC4208.

>>> 

>> 

>> so this is just and 48= 74 "enhanced mode" interface, right.

>

> Good question: the enhance= d mode supports signaling and routing, so

> i'd say yes, but reading s= ection 7.3 it talks about "limited exchange

> of information between the= control planes.

>

>    "pe= rmits limited exchange of

>    informat= ion between the control planes of the provider and the

>    customer= to help such functions as discovery of customer network<= /p>

>    routing = information (i.e., reachability or TE information in remote

>    customer= sites), or parameters of the part of the provider's network

>    dedicate= d to the customer."

>

> Would you say this include= s what we want? (i.e. Virtual links, virtual

> nodes, connectivity matric= es, SRLG, delay, loss, etc) If yes we're

> done, otherwise an option = could be the denition of a third VPN service

> model.

>

 

humm, need to think about this.=   Perhaps the best thing is to document the two different cases and th= en decide if we have something new or

(two) more detailed forms of so= mething old.

 

>> 

>>> + Open issues/= questions

>>> 1. PCE-PCEP - do w= e need to include considerations about PCE

>> and PCEP

>>> into the overlay f= ramework context?

>>> 

>>>  2. BGP-LS ne= eds to be considered

>>>  3. Should po= tentials be included? E.g. I2RS?

>>> 4. Virtual links: = wouldn't a different definition of virtual links

>>> avoid the advertis= ement of connectivity matrices (this is out of the

>>> fwk scope but with= in the advertisement models one)?

>>> 

>> 

>>> Take this example:=

>>> PE1-----CE1 &= nbsp;           &nbs= p; CE2-----PE2

>>>   &= nbsp;     CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2=

>>>   &= nbsp;     CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2=

>> 

>> I think you've reverse= d CE and PE here...

>

> Yes, once again.

>

> No comment on my foolish p= roposal?

>

 

Which one?  I liked your s= ummary overall.

 

Lou

 

>

>> 

>> Much thanks!

>> 

>> Lou<= /p>

>> (hatless...)

>> 

>>> i.e. There are 2 V= L connecting CE1 and CE2 that could be

>> available for

>>> PE1 and PE2 to set= up an adjacency in the customer domain.

>> CE1 and/or<= /span>

>>> CE2 can be blockin= g nodes so VL1 and/or VL2 are available only

>>> depending on the c= onnectivity matrices of CE1 and CE2. Hence

>> PEs need

>>> to be aware of bot= h VL and connectivity matrices. My point

>> is: if CE1<= /span>

>>> advertises to PE1 = only the VL that his connectivity matrix allows to

>>> be connected to PE= 1 (e.g. VL1 only) and not all of them, it

>> should be

>>> possible to avoid = the connectivity matrices advertisement.

>>> 

>> 

>>>  <= /span>

>>> =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

>>> DANIELE CECCARELLI=

>>> System & Techn= ology - PDU Optical & Metro

>>> 

>>> Via E.Melen, 77

>>> Genova, Italy=

>>> Phone +3901060= 02512

>>> Mobile +393346= 725750

>>> daniele.ceccarelli@er= icsson.com

>>> www= .ericsson.com

>>> 

>> 

>

>

>

_______________________________= ________________

CCAMP mailing list

CCAMP@ietf.org

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

 

--_000_6386D6323049044BA592CB99AB04BACB3F949213SVEXDBPROD1infi_-- From ggrammel@juniper.net Tue Jan 22 15:56:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C06C21F8B38 for ; Tue, 22 Jan 2013 15:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 5j5Zj0HDunzM for ; Tue, 22 Jan 2013 15:56:19 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id A903C21F8AF4 for ; Tue, 22 Jan 2013 15:56:18 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUP8nItLHEpJdCvmtU6Hy+ShoU/QO4cI1@postini.com; Tue, 22 Jan 2013 15:56:18 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 22 Jan 2013 15:51:40 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 22 Jan 2013 15:51:39 -0800 Received: from CO9EHSOBE013.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 22 Jan 2013 15:54:13 -0800 Received: from mail118-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE013.bigfish.com (10.236.130.76) with Microsoft SMTP Server id 14.1.225.23; Tue, 22 Jan 2013 23:51:39 +0000 Received: from mail118-co9 (localhost [127.0.0.1]) by mail118-co9-R.bigfish.com (Postfix) with ESMTP id 64059680069 for ; Tue, 22 Jan 2013 23:51:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -32 X-BigFish: PS-32(zzbb2dI98dI9371Ic89bhd6eah1454I103dK168aJ148cI542Ic85dh1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275dh18c673h1954cbh18602eh8275bhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail118-co9 (localhost.localdomain [127.0.0.1]) by mail118-co9 (MessageSwitch) id 1358898695384558_31691; Tue, 22 Jan 2013 23:51:35 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.248]) by mail118-co9.bigfish.com (Postfix) with ESMTP id 5A7F154005C; Tue, 22 Jan 2013 23:51:35 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 22 Jan 2013 23:51:35 +0000 Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.8.63]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0257.004; Tue, 22 Jan 2013 23:51:30 +0000 From: Gert Grammel To: Snigdho Bardalai , Lou Berger , Daniele Ceccarelli Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBokCIAAJEUjAAAD8STgAAm5+/AAA0LBcAAAYn9gA== Date: Tue, 22 Jan 2013 23:51:29 +0000 Message-ID: <305443B66F0CD946A3107753337A031113F8F989@CH1PRD0511MB431.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <305443B66F0CD946A3107753337A031113F8F831@CH1PRD0511MB431.namprd05.prod.outlook.com> <6386D6323049044BA592CB99AB04BACB3F949213@SV-EXDB-PROD1.infinera.com> In-Reply-To: <6386D6323049044BA592CB99AB04BACB3F949213@SV-EXDB-PROD1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: multipart/alternative; boundary="_000_305443B66F0CD946A3107753337A031113F8F989CH1PRD0511MB431_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:56:28 -0000 --_000_305443B66F0CD946A3107753337A031113F8F989CH1PRD0511MB431_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Snigdho, Not sure why you disagree, it rather seems we are saying the same thing. Cl= ient/server is *not* customer/provider. That's why I am struggling to accep= t the notion of 'Customer-Edge' and 'Provider-Edge' for a relationship that= has nothing to do with customers. As a consequence VPN wording (=3Dcustome= r/provider) as proposed by Lou has not the right semantic for an overlay ne= twork. Yet by just making such statements, we are no inch closer to an acce= ptable terminology. If you are not happy with client-Edge and provider-edge= feel free to propose other terms. Eventually we have to come to a conclusi= on. Best Gert From: Snigdho Bardalai [mailto:SBardalai@infinera.com] Sent: Mittwoch, 23. Januar 2013 00:06 To: Gert Grammel; Lou Berger; Daniele Ceccarelli Cc: CCAMP Subject: RE: [CCAMP] Overlay model framework v2 Hi Gert, Sorry, but I have to disagree with your statement (BTW - are we going in ci= rcles - I thought we had already beaten this topic to death :)). It is poss= ible to have client-server relationships totally contained within a custome= r or provider network and not visible across the CE-PE or PE-PE interface. = That is the reason why we need to keep client/server and customer/provider = boundaries completely independent of each other. Thanks Snigdho From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Gert Grammel Sent: Tuesday, January 22, 2013 2:34 PM To: Lou Berger; Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Hi Lou, Daniele, Thanks for summarizing, seems we are converging. Related to terminology I s= till think that 'customer' and 'provider' give the wrong connotation for ov= erlay networks. While a VPN can be seen as a service, hence both terms migh= t have some justification, a Overlay-UNI/ENNI does not. It's simply a name = for a control interface that can be used internally in a network without ne= cessarily providing a customer with any new service. Having to choose betwe= en 'Customer-Provider' or 'Client-Server' terminology , the latter fits muc= h better to what we call Overlay. To move on with terminology we may want to preserve the abbreviations by ad= ding 'overlay': 1. Overlay-Provider-edge (OPE) - at least it provides a topology to t= he client 2. Overlay-Client-edge (OCE) - Note there is no customer here, it's a= client About Virtual topology 3): =B7 real-nodes vs. virtual nodes: from a OCE perspective there shal= l be no difference. In other words there shall be no difference between an = OPE Network exposing virtual nodes and an equivalent OPE network where each= virtual node is replaced by a real node of equal characteristic. I would support the connotation of a UNI, an augmented UNI and an O(verlay)= NNI (or OCE-OPE interface): 1. UNI: signaling only, no topology information exchanged (targeted f= or a customer/provider interface where Client=3Dcustomer) 2. Augmented-UNI: signaling only, with post-provisioned topology info= rmation of LSPs 3. ONNI: signaling and routing , where routing injects topology infor= mation independent of LSPs Best Gert -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Lou Berger Sent: Montag, 21. Januar 2013 23:13 To: Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Thanks Daniele, See below. On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: > Hi Lou, > > Please find comments in line > > BR > Daniele > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: venerd=EC 18 gennaio 2013 18.27 >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Daniele, >> Very nice summary. Just catching up, so sorry for the >> (2 day) late response. >> >> I really like how the terminology has evolved and appreciate the >> summary! >> >> I have a few detail comments, but before I go there I'd like to cover >> one more open issue that I think will have some >> (minor) ripple effects on the details. >> >> I think there's still the general issue of terminology to use when >> referring to the entity that "uses an overlay" and the entity that >> "instantiates the overlay". In your mail and in discussion we have: >> >> - client (service)/OC/CN/customer >> >> and >> >> - server(or service)/OE/EN/provider >> >> I think we had discussed, and possibly agreed on, using VPN >> terminology which would have us use the latter options, i.e., >> (overlay) customer/provider (edge). This would mean eliminating any >> references to client/server in the *generic >> overlay* definitions. Of course these terms may reemerge in other >> contexts as they have before, e.g., rfc6215. > > Yes, i think we all agreed. If there are still terms different from > customer/provider in the text it's because i missed them during the > replacing. > Great! Glad I didn't miss something over the holidays! >> >> I like this approach as it is aligned with the much of IETF work on >> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). >> Importantly, RFC 4847 even has quite a few concepts that can be >> directly leveraged in this discussion. >> >> I'd even go further and say that we should base the definitions and >> resulting framework on RFC 4847. For example, the definitions below >> could start with something along the lines: >> >> The overlay service model, at a high level, follows Section >> 7. of RFC 4847 as represented by: >> >> >> +--------------------+ >> : | | : >> : | | : >> +----+ : +----+ +----+ : +----+ >> | CE |---:---| PE | | PE |---:---| CE | >> +----+ : +----+ +----+ : +----+ >> : | | : >> : | | : >> : +--------------------+ : >> : | | : >> : |<-Provider network->| : >> Customer Customer >> interface interface >> >> Figure 7.2: Overlay Service Model >> >> In this model, the overlay is instantiated by an overlay >> "provider" and its provider edge (PE) nodes , and is used by >> the overlay "customer" which is connected to the provider via >> customer interfaces attached to customer edge (CE) nodes. >> >> ... >> >> The definition below would need to be tweaked slightly, notably to >> remove any references to client and server. The resulting framework >> can also refer back to RFC 4847 as needed. >> >> See below for some additional comments. >> >> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>> Dear overlayers, >>> >>> Please find below a new version (v2) of the framework summary >>> reflecting the latest discussions. Again i hope i've >> captured all the >>> comments around, sorry if anything is missing, in case just let me >>> know what i missed. >>> >>> BR >>> Daniele >>> >>> >>> + Disclaimer: >>> 1. Packet opto integration is often considered but the work can be >>> extented to any type of SC. Eg. TDM over LSC. >>> >>> + Terminology: >>> 1. Virtual Link: A virtual link is a potential path between two >>> virtual or real network elements in a provider layer network >> that is >>> maintained/controlled in and by the provider domain control >> plane (and >>> as such cannot transport any traffic/data and protected from being >>> de-provisioned) and which can be instantiated in the data plane (and >>> then can carry/transport/forward traffic/data) preserving previously >>> advertised attributes such as fate sharing information. >>> >> >> You say "potential path". I this this should read "potential or >> instantiated path". >> > > Maybe we need to define also what "potential" stands for? At least two > cases come to my mind (which might be included under the "potential" > umbrella): > > 1. resources reserved via signaling but not instantiated Sure. Sounds like a RFC6001 soft FA. > 2. resources not even signaled. In presence of a centralized entity > managing the network (sort of PCE plus something) there is no need to > reserve resources via signaling as the central entity is the only > thing that can reserve or allocate resources. I'm thinking to an > opening towards the integration with the SDN world. > Sure. Sounds like a Virtual TE link (per RFC6001, 5212). > Just loud thinking, does it make sense? > >>From my perspective, I think a node in the overlay really shouldn't >> *directly* distinguish between the two -- now one may have a >>different metric/SRLG/weight/etc, but these are abstracted >>representations of the tradeoffs between use of the two, that can be >>provided by the underlying provider network, rather than a direct >>indication. >> >>> 2. Virtual Node: Virtual node is a collection of zero or more >>> provider network domain nodes that are collectively >> represented to the >>> clients as a single node that exists in the customer layer >> network and >>> is capable of terminating of access, inter-domain and virtual links. >>> >> >> I'm a little uncomfortable with the linkage of real nodes to virtual >> nodes. I think VN is a purely abstract concept that may be >> instantiated using parts/whole/multiple/logical/real/etc nodes. > > Makes sense. What this definition adds to the one in RFC4847 is > basically the fact that also parts of a node can be considered. What > saying that it can be a real node i meant 1:1 correspondance between a > real and a virtual node. Your definition covers that case also, that's > fine. > >> >> How about something like: >> Virtual Node: A virtual node is a representation of a collection of >> provider resources that are interconnected via virtual (and customer) >> links. A virtual node may be collection of zero or more, including >> portions of, provider nodes that are collectively represented to the >> customer as a single node which is available in an overlay network. > > Works for me. > Great. BTW I don't think 4847 precluded a single physical node being repre= sented as multiple virtual nodes, but it doesn't hurt to make it explicit. >> >>> 3. Virtual Topology: Virtual topology is a collection of one or more >>> virtual or real provider network domain nodes that exist in the >>> customer layer network and are interconnected via 0 or more virtual >>> links. >> >> How about: >> Virtual Topology: A virtual topology is the collection of virtual >> links and nodes advertised by a provider to a customer. The virtual >> topology includes resources that are advertised as reachable within >> an overlay network. >> >> Do you mean to imply/allow for a VN which has no links? > > The case of "interconnected via 0 virtual links" implies the whole > domain seen as a single node. > Ahh, fair enough. >> >>> 4. Overlay topology: is a superset of virtual topologies >> provided by >>> each of provider network domains, access and inter-domain links. >>> >> >> Doesn't it also include any topology information advertised by the >> customer/CE as well? > > Possibly. Do you mean advertised by the CE in the customer domain, right? > That's possible too, but I was thinking more of advertised by CE (customer) to PE (provider). >> >>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It >>> can support any of the SCs supported by the GMPLS. >>> >> >> If we adopt RFC 4847 terminology it should be "customer interface". >> Also, I suspect you mean PE and CE. > > Mmm, yes but what if we want to manage it as a link? i.e. All > TE-parameters that a link supports. Is it enough to call it interface > only? > sure. Per 4847, I'd say that "customer interface" is the connection betwee= n CE/PE while [virtual] TE links are what is advertised/represented in rout= ing. >> >>> 6. CE (customer Edge): Something like the CN in RFC4208 >> teminology but >>> (i) receiving virtual topology from the provider network and >>> requesting the set up of one of them or (ii) requesting the >>> computation and establishment of a path accordingly to given >>> constraints in the provider network and receiving the parameters >>> characterizing such path. (ii) =3D=3D UNI. >>> >> >> humm, I'm inclined to stay away from UNI for the moment. I also >> suggest that we look to 4874 and even 4364 rather than 4208... > > Ok, we can refer to those RFC for what concerns terminology, but at > the end of the day we must put the UNI under this framework. In the > new terminology the UNI is a particular type of customer interface. > Fair enough. But it is a form on an overlay "customer interface" not the d= efinitive form. >> >>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to >>> deal with (i) and (ii) above. >>> >> >> same comment WRT RFCs. >> >>> 8. PE-CE interface (former ONI) : Interface allowing for >> signaling and >>> routing messages exchange between customer overlay and provider >>> network. Routing information consists on virtual topology >>> advertisement. When there is no routing adjacency across the >> interface >>> it is equivalent to the GMPLS UNI defined in 4208. >>> Signaling messages are compliant with RFC4208. Information >> related to >>> path carachteristics, e.g. TE-metrics, collected SRLG, path >> delay etc, >>> either passed from CE to PE via signaling after the LSP >> establishment >>> in the core network or from CE to PE to be used as path computation >>> constraints, fall under the definition of signaling info and not >>> routing info). >>> >> >> >>> 9. CE-CE (former O-NNI): Interface on the links between different >>> provider networks in the overlay model environment. Same features of >>> the CE-PE apply to this interface. >>> >> >> you mean, PE-PE, right? > > You're not the first one that makes me notice i'm probably affected by > dyslexia :-) > no problem, happens to the best of us! >> >>> + Statements 1. In the context of overlay model we are aiming to >>> build an overlay topology for the customer network domains >>> >>> 2. The overlay topology is comprised of: >>> a) access links (links connecting client NEs to the >> provider network domains). >>> They can be PSC or LSC. >>> b) inter-domain links (links interconnecting server >> network domains) >>> c) virtual topology provided by the provider network domains. >>> Virtual Links >>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of >>> + parameters >>> e.g. SRLG, optical impairments, delay etc for each entry) describing >>> connectivity between access links and virtual links. >>> >>> 3. In the context of overlay model we manage hierarchy of overlay >>> topologies with overlay/underlay relationships >>> >>> 4. In the context of overlay model multi-layering and inter-layer >>> relationships are peripheral at best, it is all about horizontal >>> network integration >>> >>> 5. The overlay model assumes one CP instance for the >> customer network >>> and a separate instance for the provider network and in the CE-PE >>> interface case the provider network also surreptitiously >> participates >>> in the customer network by injecting virtual topology >> information into >>> it. >>> >> >> We should ensure we're allowing for some of the existing/augmented >> models that permit the transport of overlay information within the >> provider's CP, e.g., rfc4364, 5195 and 5252. > > I'd say they should be already covered, but will double check > great. >> >>> 6. L1VPN (and LxVPN) in general is a type of service >> provided over the >>> CE-PE interface (it falls under the UNI case as no routing adjacency >>> is in place between CE and PE). >>> >>> >>> + Advertisement models (to be detailed in dedicated >>> + document/documents) >>> The CE-PE interface in the overlay model context foresees >> two types of >>> advertisement models.(names still to be agreed) >>> >>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >> augmented by >>> a number of actived draft (references to various drafts to >> be added). >>> The Augmented UNI is a particular type of CE-PE interface where only >>> signaling messages are exchanged between CE and PE. >>> Messages from CE to PE can include a set of parameters to be used by >>> the PE as path computation constraints when computing a path in the >>> provider domain network, while messages from PE to CE can include a >>> set of parameters qualifying the LSP being established, like for >>> example SRLG, delay, loss etc. >>> >> >> again, we can leverage 4874 terminology if we so choose, i.e., "basic >> mode" and "enhanced mode" UNI|NNI > > Don would be happy about that :-). I'd say yes. The goal was to cover > the L1VPN work (enhanced mode), all the drafts-ali recently polled > for wg adoption (basic mode?) and the actual ENNI (enhanced mode). > Is my mapping in brackets correct? > Not sure f I'd break it down they way you are. I'd say basic mode is close= r to the typical UNI and enhance mode is UNI+routing or perhaps even an ENN= I. > >> >>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >>> called with the general CE-PE interface term?) allowing the >>> establishment of signaling and routing adjacency between CE and PE. >>> Routing info passed from PE to CE comprise overlay topology >>> information including (but not limited to) virtual links, >> connectivity >>> matrices and access links with parameters qualifying each of them in >>> terms of e.g. SRLG, loss, delay etc. Signaling information and >>> procedures are compliant with RFC4208. >>> >> >> so this is just and 4874 "enhanced mode" interface, right. > > Good question: the enhanced mode supports signaling and routing, so > i'd say yes, but reading section 7.3 it talks about "limited exchange > of information between the control planes. > > "permits limited exchange of > information between the control planes of the provider and the > customer to help such functions as discovery of customer network > routing information (i.e., reachability or TE information in remote > customer sites), or parameters of the part of the provider's network > dedicated to the customer." > > Would you say this includes what we want? (i.e. Virtual links, virtual > nodes, connectivity matrices, SRLG, delay, loss, etc) If yes we're > done, otherwise an option could be the denition of a third VPN service > model. > humm, need to think about this. Perhaps the best thing is to document the = two different cases and then decide if we have something new or (two) more detailed forms of something old. >> >>> + Open issues/questions >>> 1. PCE-PCEP - do we need to include considerations about PCE >> and PCEP >>> into the overlay framework context? >>> >>> 2. BGP-LS needs to be considered >>> 3. Should potentials be included? E.g. I2RS? >>> 4. Virtual links: wouldn't a different definition of virtual links >>> avoid the advertisement of connectivity matrices (this is out of the >>> fwk scope but within the advertisement models one)? >>> >> >>> Take this example: >>> PE1-----CE1 CE2-----PE2 >>> CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>> CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >> >> I think you've reversed CE and PE here... > > Yes, once again. > > No comment on my foolish proposal? > Which one? I liked your summary overall. Lou > >> >> Much thanks! >> >> Lou >> (hatless...) >> >>> i.e. There are 2 VL connecting CE1 and CE2 that could be >> available for >>> PE1 and PE2 to set up an adjacency in the customer domain. >> CE1 and/or >>> CE2 can be blocking nodes so VL1 and/or VL2 are available only >>> depending on the connectivity matrices of CE1 and CE2. Hence >> PEs need >>> to be aware of both VL and connectivity matrices. My point >> is: if CE1 >>> advertises to PE1 only the VL that his connectivity matrix allows to >>> be connected to PE1 (e.g. VL1 only) and not all of them, it >> should be >>> possible to avoid the connectivity matrices advertisement. >>> >> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> DANIELE CECCARELLI >>> System & Technology - PDU Optical & Metro >>> >>> Via E.Melen, 77 >>> Genova, Italy >>> Phone +390106002512 >>> Mobile +393346725750 >>> daniele.ceccarelli@ericsson.com >>> www.ericsson.com >>> >> > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_305443B66F0CD946A3107753337A031113F8F989CH1PRD0511MB431_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Snigdho= ,

&n= bsp;

Not sur= e why you disagree, it rather seems we are saying the same thing. Client/se= rver is *not* customer/provider. That’s why I am struggling to= accept the notion of ‘Customer-Edge’ and ‘Provider-Edge&= #8217; for a relationship that has nothing to do with customers. As a consequence= VPN wording (=3Dcustomer/provider) as proposed by Lou has not the right se= mantic for an overlay network. Yet by just making such statements, we are n= o inch closer to an acceptable terminology. If you are not happy with client-Edge and provider-edge feel free to propo= se other terms. Eventually we have to come to a conclusion.

&n= bsp;

Best

&n= bsp;

Gert

&n= bsp;

From: Snigdho Bardalai [mailto:SBardalai@infinera.com]
Sent: Mittwoch, 23. Januar 2013 00:06
To: Gert Grammel; Lou Berger; Daniele Ceccarelli
Cc: CCAMP
Subject: RE: [CCAMP] Overlay model framework v2

 

Hi Gert= ,

&n= bsp;

Sorry, = but I have to disagree with your statement (BTW - are we going in circles &= #8211; I thought we had already beaten this topic to death J= ). It is possible to ha= ve client-server relationships totally contained within a customer or provi= der network and not visible across the CE-PE or PE-PE interface. That is the reason why we need to keep client/server a= nd customer/provider boundaries completely independent of each other.<= /o:p>

&n= bsp;

Thanks<= o:p>

Snigdho=

&n= bsp;

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Gert Grammel
Sent: Tuesday, January 22, 2013 2:34 PM
To: Lou Berger; Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

 

Hi Lou, Daniele,

 

Thanks for summarizing, seem= s we are converging. Related to terminology I still think that 'customer' a= nd 'provider' give the wrong connotation for overlay networks. While a VPN = can be seen as a service, hence both terms might have some justification, a Overlay-UNI/ENNI does not. It's sim= ply a name for a control interface that can be used internally in a network= without necessarily providing a customer with any new service. Having to c= hoose between ‘Customer-Provider’ or ‘Client-Server’ terminology , the latter fits much better t= o what we call Overlay.  

 

To move on with terminology = we may want to preserve the abbreviations by adding 'overlay':

1= .   &= nbsp;   Overlay-Provider-edge (= OPE) – at least it provides a topology to the client

2= .   &= nbsp;   Overlay-Client-edge (OC= E) - Note there is no customer here, it’s a client<= /p>

 

About Virtual topology 3):

=B7         real-nodes vs. virtual = nodes: from a OCE perspective there shall be no difference. In other words = there shall be no difference between an OPE Network exposing virtual nodes = and an equivalent OPE network where each virtual node is replaced by a real node of equal characteristic.=

 

I would support the connotat= ion of a UNI, an augmented UNI and an O(verlay)NNI (or OCE-OPE interface):<= o:p>

1= .   &= nbsp;   UNI: signaling only, no= topology information exchanged (targeted for a customer/provider interface= where Client=3Dcustomer)

2= .   &= nbsp;   Augmented-UNI: signalin= g only, with post-provisioned topology information of LSPs

3= .   &= nbsp;   ONNI: signaling and rou= ting , where routing injects topology information independent of LSPs<= /o:p>

 

Best

 

Gert

 

 

-----Original Message----- From: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Montag, 21. Januar 2013 23:13
To: Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

 

Thanks Daniele, See below.

 

On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote:

> Hi Lou,

>

> Please find comments in line

>

> BR

> Daniele

>

>> -----Original Message-----

>> From: Lou Berger [<= /span>mailto:lberger@labn.net]

>> Sent: venerd=EC 18 gennaio 2013 18.27

>> To: Daniele Ceccarelli

>> Cc: CCAMP

>> Subject: Re: [CCAMP] Overlay model frame= work v2

>> 

>> Daniele,

>>       &nbs= p;  Very nice summary.  Just catching up, so sorry for the

>> (2 day) late response.

>> 

>> I really like how the terminology has ev= olved and appreciate the

>> summary!

>> 

>> I have a few detail comments, but before= I go there I'd like to cover

>> one more open issue that I think will ha= ve some

>> (minor) ripple effects on the details.

>> 

>> I think there's still the general issue = of terminology to use when

>> referring to the entity that "uses = an overlay" and the entity that

>> "instantiates the overlay".&nb= sp; In your mail and in discussion we have:

>> 

>> - client (service)/OC/CN/customer

>> 

>> and

>> 

>> - server(or service)/OE/EN/provider=

>> 

>> I think we had discussed, and possibly a= greed on, using VPN

>> terminology which would have us use the = latter options, i.e.,

>> (overlay) customer/provider (edge). = ; This would mean eliminating any

>> references to client/server in the *gene= ric

>> overlay* definitions.  Of course th= ese terms may reemerge in other

>> contexts as they have before, e.g., rfc6= 215.

>

> Yes, i think we all agreed. If there are sti= ll terms different from

> customer/provider in the text it's because i= missed them during the

> replacing.

>

 

Great!  Glad I didn't miss something over th= e holidays!

 

>> 

>> I like this approach as it is aligned wi= th the much of IETF work on

>> overlays (e.g., BGP L3/L2 VPNs) as well = as the L1VPN (e.g. RFC 4847). 

>> Importantly, RFC 4847 even has quite a f= ew concepts that can be

>> directly leveraged in this discussion.

>> 

>> I'd even go further and say that we shou= ld base the definitions and

>> resulting framework on RFC 4847.  F= or example, the definitions below

>> could start with something along the lin= es:

>> 

>>    The overlay service mo= del, at a high level, follows Section

>>    7. of RFC 4847 as repr= esented by:

>> 

>> 

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

>>       = ;           :  =    |          &= nbsp;         |   &n= bsp; :

>>       = ;           :  =    |          &= nbsp;         |   &n= bsp; :

>>       = ;  +----+   :   +----+  =             +---= -+   :   +----+

>>       = ;  | CE |---:---| PE |        =       | PE |---:---| CE |

>>       = ;  +----+   :   +----+  =             +---= -+   :   +----+

>>       = ;           :  =    |          &= nbsp;         |   &n= bsp; :

>>       = ;           :  =    |          &= nbsp;         |   &n= bsp; :

>>       = ;           :  =    +--------------------+     :<= /o:p>

>>       = ;           :  =    |          &= nbsp;         |   &n= bsp; :

>>       = ;           :  =    |<-Provider network->|     :

>>       = ;      Customer      = ;            &n= bsp;        Customer

>>       = ;      interface     &nbs= p;             =        interface

>> 

>>       = ;           Figure 7.2: O= verlay Service Model

>> 

>>    In this model, the ove= rlay is instantiated by an overlay

>>    "provider" a= nd its provider edge (PE) nodes , and is used by

>>    the overlay "cust= omer" which is connected to the provider via

>>    customer interfaces at= tached to customer edge (CE) nodes.

>> 

>>    ...

>> 

>> The definition below would need to be tw= eaked slightly, notably to

>> remove any references to client and serv= er.  The resulting framework

>> can also refer back to RFC 4847 as neede= d.

>> 

>> See below for some additional comments.<= o:p>

>> 

>> On 1/16/2013 10:33 AM, Daniele Ceccarell= i wrote:

>>> Dear overlayers,

>>> 

>>> Please find below a new version (v2)= of the framework summary

>>> reflecting the latest discussions. A= gain i hope i've

>> captured all the

>>> comments around, sorry if anything i= s missing, in case just let me

>>> know what i missed.

>>> 

>>> BR

>>> Daniele

>>> 

>>> 

>>> + Disclaimer:

>>> 1. Packet opto integration is often = considered but the work can be

>>> extented to any type of SC. Eg. TDM = over LSC.

>>> 

>>> + Terminology:

>>> 1. Virtual Link: A virtual link is a= potential path between two

>>> virtual or real network elements in = a provider layer network

>> that is

>>> maintained/controlled in and by the = provider domain control

>> plane (and

>>> as such cannot transport any traffic= /data and protected from being

>>> de-provisioned) and which can be ins= tantiated in the data plane (and

>>> then can carry/transport/forward tra= ffic/data) preserving previously

>>> advertised attributes such as fate s= haring information.

>>> 

>> 

>> You say "potential path". = ; I this this should read  "potential or

>> instantiated path".

>> 

>

> Maybe we need to define also what "pote= ntial" stands for? At least two

> cases come to my mind (which might be includ= ed under the "potential"

> umbrella):

>

> 1. resources reserved via signaling but not = instantiated

 

Sure.  Sounds like a RFC6001 soft FA.

 

> 2. resources not even signaled. In presence = of a centralized entity

> managing the network (sort of PCE plus somet= hing) there is no need to

> reserve resources via signaling as the centr= al entity is the only

> thing that can reserve or allocate resources= . I'm thinking to an

> opening towards the integration with the SDN= world.

>

 

Sure.  Sounds like a Virtual TE link (per RF= C6001, 5212).

 

> Just loud thinking, does it make sense?=

>

>>From my perspective, I think a node in th= e overlay really shouldn't

>> *directly* distinguish between the two -= - now one may have a 

>>different metric/SRLG/weight/etc, but the= se are abstracted 

>>representations of the tradeoffs between = use of the two, that  can be

>>provided by the underlying provider netwo= rk, rather  than a direct

>>indication.

>> 

>>> 2.  Virtual Node: Virtual node = is a collection of zero or more

>>> provider network domain nodes that a= re collectively

>> represented to the

>>> clients as a single node that exists= in the customer layer

>> network and

>>> is capable of terminating of access,= inter-domain and virtual links.

>>> 

>> 

>> I'm a little uncomfortable with the link= age of real nodes to virtual

>> nodes.  I think VN is a purely abst= ract concept that may be

>> instantiated using parts/whole/multiple/= logical/real/etc nodes.

>

> Makes sense. What this definition adds to th= e one in RFC4847 is

> basically the fact that also parts of a node= can be considered. What

> saying that it can be a real node i meant 1:= 1 correspondance between a

> real and a virtual node. Your definition cov= ers that case also, that's

> fine.

>

>> 

>> How about something like:

>> Virtual Node: A virtual node is a repres= entation of a collection of

>> provider resources that are interconnect= ed via virtual (and customer)

>> links.  A virtual node may be colle= ction of zero or more, including

>> portions of, provider nodes that are col= lectively represented to the

>> customer as a single node which is avail= able in an overlay network.

>

> Works for me.

>

 

Great.  BTW I don't think 4847 precluded a s= ingle physical node being represented as multiple virtual nodes, but it doe= sn't hurt to make it explicit.

 

>> 

>>> 3. Virtual Topology: Virtual topolog= y is a collection of one or more

>>> virtual or real provider network dom= ain nodes that exist in the

>>> customer layer network and are inter= connected via 0 or more virtual

>>> links.

>> 

>> How about:

>> Virtual Topology: A virtual topology is = the collection of virtual

>> links and nodes advertised by a provider= to a customer. The virtual

>> topology includes resources that are adv= ertised as reachable within

>> an overlay network.

>> 

>> Do you mean to imply/allow for a VN whic= h has no links?

>

> The case of "interconnected via 0 virtu= al links" implies the whole

> domain seen as a single node.

>

 

Ahh, fair enough.

 

>> 

>>> 4. Overlay topology:  is a supe= rset of virtual topologies

>> provided by

>>> each of provider network domains, ac= cess and inter-domain links.

>>> 

>> 

>> Doesn't it also include any topology inf= ormation advertised by the

>> customer/CE as well?

>

> Possibly. Do you mean advertised by the CE i= n the customer domain, right?

>

 

That's possible too, but I was thinking more of a= dvertised by CE

(customer) to PE (provider).

 

>> 

>>> 5. Access Link: Link between OC and = OE. GMPLS runs on that link. It

>>> can support any of the SCs supported= by the GMPLS.

>>> 

>> 

>> If we adopt RFC 4847 terminology it shou= ld be "customer interface".

>> Also, I suspect you mean PE and CE.=

>

> Mmm, yes but what if we want to manage it as= a link? i.e. All

> TE-parameters that a link supports. Is it en= ough to call it interface

> only?

>

 

sure.  Per 4847, I'd say that "customer= interface" is the connection between CE/PE while [virtual] TE links a= re what is advertised/represented in routing.

 

>> 

>>> 6. CE (customer Edge): Something lik= e the CN in RFC4208

>> teminology but

>>> (i) receiving virtual topology from = the provider network and

>>> requesting the set up of one of them= or (ii) requesting the

>>> computation and establishment of a p= ath accordingly to given

>>> constraints in the provider network = and receiving the parameters

>>> characterizing such path. (ii) =3D= =3D UNI.

>>> 

>> 

>> humm, I'm inclined to stay away from UNI= for the moment.  I also

>> suggest that we look to 4874 and even 43= 64 rather than 4208...

>

> Ok, we can refer to those RFC for what conce= rns terminology, but at

> the end of the day we must put the UNI under= this framework. In the

> new terminology the UNI is a particular type= of customer interface.

>

 

Fair enough.  But it is a form on an overlay= "customer interface" not the definitive form.

 

>> 

>>> 7. PE (provider Edge): Something lik= e the EN in RFC4208 but able to

>>> deal with (i) and (ii) above.

>>> 

>> 

>> same comment WRT RFCs.

>> 

>>> 8. PE-CE interface (former ONI) : In= terface allowing for

>> signaling and

>>> routing messages exchange between cu= stomer overlay and provider

>>> network. Routing information consist= s on virtual topology

>>> advertisement. When there is no rout= ing adjacency across the

>> interface

>>> it is equivalent to the GMPLS UNI de= fined in 4208.

>>> Signaling messages are compliant wit= h RFC4208. Information

>> related to

>>> path carachteristics, e.g. TE-metric= s, collected SRLG, path

>> delay etc,

>>> either passed from CE to PE via sign= aling after the LSP

>> establishment

>>> in the core network or from CE to PE= to be used as path computation

>>> constraints, fall under the definiti= on of signaling info and not

>>> routing info).

>>> 

>> 

>> 

>>> 9. CE-CE (former O-NNI): Interface o= n the links between different

>>> provider networks in the overlay mod= el environment. Same features of

>>> the CE-PE apply to this interface.

>>> 

>> 

>> you mean, PE-PE, right?

>

> You're not the first one that makes me notic= e i'm probably affected by

> dyslexia :-)

>

 

no problem, happens to the best of us!=

 

>> 

>>> + Statements 1. In the context o= f overlay model we are aiming to

>>> build an overlay topology for the cu= stomer network domains

>>> 

>>>  2. The overlay topology is com= prised of:

>>>     a) access li= nks (links connecting client NEs to the

>> provider network domains).

>>>  They can be PSC or LSC.

>>>     b) inter-dom= ain links (links interconnecting server

>> network domains)

>>>     c) virtual t= opology provided by the provider network domains.

>>> Virtual Links

>>> + Virtual Nodes (TBD) + Conn= ectivity Matrix (with a set of

>>> + parameters

>>> e.g. SRLG, optical impairments, dela= y etc for each entry) describing

>>> connectivity between access links an= d virtual links.

>>> 

>>> 3. In the context of overlay model w= e manage  hierarchy  of overlay

>>> topologies with overlay/underlay rel= ationships

>>> 

>>> 4. In the context of overlay model m= ulti-layering and inter-layer

>>> relationships are peripheral at best= , it is all about horizontal

>>> network integration

>>> 

>>> 5. The overlay model assumes one CP = instance for the

>> customer network

>>> and a separate instance for the prov= ider network and in the CE-PE

>>> interface case the provider network = also surreptitiously

>> participates

>>> in the customer network by injecting= virtual topology

>> information into

>>> it.

>>> 

>> 

>> We should ensure we're allowing for some= of the existing/augmented

>> models that permit the transport of over= lay information within the

>> provider's CP, e.g., rfc4364, 5195 and 5= 252.

>

> I'd say they should be already covered, but = will double check

>

 

great.

 

>> 

>>> 6. L1VPN (and LxVPN) in general is a= type of service

>> provided over the

>>> CE-PE interface (it falls under the = UNI case as no routing adjacency

>>> is in place between CE and PE).=

>>> 

>>> 

>>> + Advertisement models (to be de= tailed in dedicated

>>> + document/documents)=

>>> The CE-PE interface in the overlay m= odel context foresees

>> two types of

>>> advertisement models.(names still to= be agreed)

>>> 

>>> A. Augmented UNI: The GMPLS UNI is d= efined in RFC4208 and

>> augmented by

>>> a number of actived draft (reference= s to various drafts to

>> be added).

>>> The Augmented UNI is a particular ty= pe of CE-PE interface where only

>>> signaling messages are exchanged bet= ween CE and PE.

>>> Messages from CE to PE can include a= set of parameters to be used by

>>> the PE as path computation constrain= ts when computing a path in the

>>> provider domain network, while messa= ges from PE to CE can include a

>>> set of parameters qualifying the LSP= being established, like for

>>> example SRLG, delay, loss etc.<= /o:p>

>>> 

>> 

>> again, we can leverage 4874 terminology = if we so choose, i.e., "basic

>> mode" and "enhanced mode"= UNI|NNI

>

> Don would be happy about that :-). I'd say y= es. The goal was to cover

> the L1VPN work (enhanced mode),  all th= e drafts-ali recently polled

> for wg adoption (basic mode?) and the actual= ENNI (enhanced mode).

 

> Is my mapping in brackets correct?

>

 

Not sure f I'd break it down they way you are.&nb= sp; I'd say basic mode is closer to the typical UNI and enhance mode is UNI= +routing or perhaps even an ENNI.

 

>

>> 

>>> B. ONI: The GMPLS ONI is a CE-PE int= erface (this could be simply

>>> called with the general CE-PE interf= ace term?) allowing the

>>> establishment of signaling and routi= ng adjacency between CE and PE.

>>> Routing info passed from PE to CE co= mprise overlay topology

>>> information including (but not limit= ed to) virtual links,

>> connectivity

>>> matrices and access links with param= eters qualifying each of them in

>>> terms of e.g. SRLG, loss, delay etc.= Signaling information and

>>> procedures are compliant with RFC420= 8.

>>> 

>> 

>> so this is just and 4874 "enhanced = mode" interface, right.

>

> Good question: the enhanced mode supports si= gnaling and routing, so

> i'd say yes, but reading section 7.3 it talk= s about "limited exchange

> of information between the control planes.

>

>    "permits limited exch= ange of

>    information between the co= ntrol planes of the provider and the

>    customer to help such func= tions as discovery of customer network

>    routing information (i.e.,= reachability or TE information in remote

>    customer sites), or parame= ters of the part of the provider's network

>    dedicated to the customer.= "

>

> Would you say this includes what we want? (i= .e. Virtual links, virtual

> nodes, connectivity matrices, SRLG, delay, l= oss, etc) If yes we're

> done, otherwise an option could be the denit= ion of a third VPN service

> model.

>

 

humm, need to think about this.  Perhaps the= best thing is to document the two different cases and then decide if we ha= ve something new or

(two) more detailed forms of something old.<= /o:p>

 

>> 

>>> + Open issues/questions

>>> 1. PCE-PCEP - do we need to include = considerations about PCE

>> and PCEP

>>> into the overlay framework context?<= o:p>

>>> 

>>>  2. BGP-LS needs to be consider= ed

>>>  3. Should potentials be includ= ed? E.g. I2RS?

>>> 4. Virtual links: wouldn't a differe= nt definition of virtual links

>>> avoid the advertisement of connectiv= ity matrices (this is out of the

>>> fwk scope but within the advertiseme= nt models one)?

>>> 

>> 

>>> Take this example:

>>> PE1-----CE1    &= nbsp;          CE2-----PE2

>>>      &= nbsp;  CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2

>>>      &= nbsp;  CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2

>> 

>> I think you've reversed CE and PE here..= .

>

> Yes, once again.

>

> No comment on my foolish proposal?

>

 

Which one?  I liked your summary overall.

 

Lou

 

>

>> 

>> Much thanks!

>> 

>> Lou

>> (hatless...)

>> 

>>> i.e. There are 2 VL connecting CE1 a= nd CE2 that could be

>> available for

>>> PE1 and PE2 to set up an adjacency i= n the customer domain.

>> CE1 and/or

>>> CE2 can be blocking nodes so VL1 and= /or VL2 are available only

>>> depending on the connectivity matric= es of CE1 and CE2. Hence

>> PEs need

>>> to be aware of both VL and connectiv= ity matrices. My point

>> is: if CE1

>>> advertises to PE1 only the VL that h= is connectivity matrix allows to

>>> be connected to PE1 (e.g. VL1 only) = and not all of them, it

>> should be

>>> possible to avoid the connectivity m= atrices advertisement.

>>> 

>> 

>>> 

>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

>>> DANIELE CECCARELLI

>>> System & Technology - PDU Optica= l & Metro

>>> 

>>> Via E.Melen, 77

>>> Genova, Italy

>>> Phone +390106002512

>>> Mobile +393346725750<= /p>

>>> daniel= e.ceccarelli@ericsson.com

>>> = www.ericsson.com

>>> 

>> 

>

>

>

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org=

https://www.ie= tf.org/mailman/listinfo/ccamp

 

--_000_305443B66F0CD946A3107753337A031113F8F989CH1PRD0511MB431_-- From Dieter.Beller@alcatel-lucent.com Wed Jan 23 01:43:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBFB21F8706 for ; Wed, 23 Jan 2013 01:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.741 X-Spam-Level: X-Spam-Status: No, score=-6.741 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8] 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 xQ64YzIu7YoH for ; Wed, 23 Jan 2013 01:43:28 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id BAFFE21F86C8 for ; Wed, 23 Jan 2013 01:43:27 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r0N9hLm9009590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Jan 2013 03:43:22 -0600 (CST) Received: from destgsu0709.de.alcatel-lucent.com (slsv7at.de.alcatel-lucent.com [149.204.245.107]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r0N9hJU7003042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2013 10:43:20 +0100 Received: from [149.204.106.184] ([149.204.106.184]) (authenticated bits=0) by destgsu0709.de.alcatel-lucent.com (8.14.3/8.13.8) with ESMTP id r0N9hHwD010360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2013 10:43:18 +0100 (CET) Message-ID: <50FFB0B5.5000008@alcatel-lucent.com> Date: Wed, 23 Jan 2013 10:43:17 +0100 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gert Grammel , Snigdho Bardalai References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <305443B66F0CD946A3107753337A031113F8F831@CH1PRD0511MB431.namprd05.prod.outlook.com> <6386D6323049044BA592CB99AB04BACB3F949213@SV-EXDB-PROD1.infinera.com> <305443B66F0CD946A3107753337A031113F8F989@CH1PRD0511MB431.namprd05.prod.outlook.com> In-Reply-To: <305443B66F0CD946A3107753337A031113F8F989@CH1PRD0511MB431.namprd05.prod.outlook.com> Content-Type: multipart/related; boundary="------------080801060808080507050500" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 09:43:33 -0000 This is a multi-part message in MIME format. --------------080801060808080507050500 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Gert, Snigdho, all,

I agree with the statement that:

"we need to keep client/server and customer/provider boundaries completely independent of each other"

At least the "customer-edge/provider-edge" terminology originally defined for VPNs does reflect
the fact that this is a horizontal interface as opposed to client/server in the multi-layer context.


Thanks,
Dieter

On 23.01.2013 00:51, Gert Grammel wrote:

Snigdho,

Not sure why you disagree, it rather seems we are saying the same thing. Client/server is *not* customer/provider. That抯 why I am struggling to accept the notion of 慍ustomer-Edge and 慞rovider-Edge for a relationship that has nothing to do with customers. As a consequence VPN wording (=customer/provider) as proposed by Lou has not the right semantic for an overlay network. Yet by just making such statements, we are no inch closer to an acceptable terminology. If you are not happy with client-Edge and provider-edge feel free to propose other terms. Eventually we have to come to a conclusion.

Best

Gert

From: Snigdho Bardalai [mailto:SBardalai@infinera.com]
Sent: Mittwoch, 23. Januar 2013 00:06
To: Gert Grammel; Lou Berger; Daniele Ceccarelli
Cc: CCAMP
Subject: RE: [CCAMP] Overlay model framework v2

Hi Gert,

Sorry, but I have to disagree with your statement (BTW - are we going in circles I thought we had already beaten this topic to death ☺). It is possible to have client-server relationships totally contained within a customer or provider network and not visible across the CE-PE or PE-PE interface. That is the reason why we need to keep client/server and customer/provider boundaries completely independent of each other.

Thanks

Snigdho

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Gert Grammel
Sent: Tuesday, January 22, 2013 2:34 PM
To: Lou Berger; Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Hi Lou, Daniele,

Thanks for summarizing, seems we are converging. Related to terminology I still think that 'customer' and 'provider' give the wrong connotation for overlay networks. While a VPN can be seen as a service, hence both terms might have some justification, a Overlay-UNI/ENNI does not. It's simply a name for a control interface that can be used internally in a network without necessarily providing a customer with any new service. Having to choose between 慍ustomer-Provider or 慍lient-Server terminology , the latter fits much better to what we call Overlay.

To move on with terminology we may want to preserve the abbreviations by adding 'overlay':

1.牋牋牋 Overlay-Provider-edge (OPE) at least it provides a topology to the client

2.牋牋牋 Overlay-Client-edge (OCE) - Note there is no customer here, it抯 a client

About Virtual topology 3):

牋牋牋牋 real-nodes vs. virtual nodes: from a OCE perspective there shall be no difference. In other words there shall be no difference between an OPE Network exposing virtual nodes and an equivalent OPE network where each virtual node is replaced by a real node of equal characteristic.

I would support the connotation of a UNI, an augmented UNI and an O(verlay)NNI (or OCE-OPE interface):

1.牋牋牋 UNI: signaling only, no topology information exchanged (targeted for a customer/provider interface where Client=customer)

2.牋牋牋 Augmented-UNI: signaling only, with post-provisioned topology information of LSPs

3.牋牋牋 ONNI: signaling and routing , where routing injects topology information independent of LSPs

Best

Gert

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Montag, 21. Januar 2013 23:13
To: Daniele Ceccarelli
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework v2

Thanks Daniele, See below.

On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote:

> Hi Lou,

>

> Please find comments in line

>

> BR

> Daniele

>

>> -----Original Message-----

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

>> Sent: venerd 18 gennaio 2013 18.27

>> To: Daniele Ceccarelli

>> Cc: CCAMP

>> Subject: Re: [CCAMP] Overlay model framework v2

>>

>> Daniele,

>> 牋牋牋牋 Very nice summary. Just catching up, so sorry for the

>> (2 day) late response.

>>

>> I really like how the terminology has evolved and appreciate the

>> summary!

>>

>> I have a few detail comments, but before I go there I'd like to cover

>> one more open issue that I think will have some

>> (minor) ripple effects on the details.

>>

>> I think there's still the general issue of terminology to use when

>> referring to the entity that "uses an overlay" and the entity that

>> "instantiates the overlay". In your mail and in discussion we have:

>>

>> - client (service)/OC/CN/customer

>>

>> and

>>

>> - server(or service)/OE/EN/provider

>>

>> I think we had discussed, and possibly agreed on, using VPN

>> terminology which would have us use the latter options, i.e.,

>> (overlay) customer/provider (edge). This would mean eliminating any

>> references to client/server in the *generic

>> overlay* definitions. Of course these terms may reemerge in other

>> contexts as they have before, e.g., rfc6215.

>

> Yes, i think we all agreed. If there are still terms different from

> customer/provider in the text it's because i missed them during the

> replacing.

>

Great! Glad I didn't miss something over the holidays!

>>

>> I like this approach as it is aligned with the much of IETF work on

>> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847).

>> Importantly, RFC 4847 even has quite a few concepts that can be

>> directly leveraged in this discussion.

>>

>> I'd even go further and say that we should base the definitions and

>> resulting framework on RFC 4847. For example, the definitions below

>> could start with something along the lines:

>>

>>牋 The overlay service model, at a high level, follows Section

>>牋 7. of RFC 4847 as represented by:

>>

>>

>>牋牋牋牋牋牋牋牋牋牋牋 +--------------------+

>>牋牋牋牋牋牋牋牋 :牋牋 |牋牋牋牋牋牋牋牋牋 |牋牋 :

>>牋牋牋牋牋牋牋牋 :牋牋 |牋牋牋牋牋牋牋牋牋 |牋牋 :

>>牋牋牋牋 +----+牋 :牋 +----+牋牋牋牋牋牋 +----+牋 :牋 +----+

>>牋牋牋牋 | CE |---:---| PE |牋牋牋牋牋牋 | PE |---:---| CE |

>>牋牋牋牋 +----+牋 :牋 +----+牋牋牋牋牋牋 +----+牋 :牋 +----+

>>牋牋牋牋牋牋牋牋 :牋牋 |牋牋牋牋牋牋牋牋牋 |牋牋 :

>>牋牋牋牋牋牋牋牋 :牋牋 |牋牋牋牋牋牋牋牋牋 |牋牋 :

>>牋牋牋牋牋牋牋牋 :牋牋 +--------------------+牋牋 :

>>牋牋牋牋牋牋牋牋 :牋牋 |牋牋牋牋牋牋牋牋牋 |牋牋 :

>>牋牋牋牋牋牋牋牋 :牋牋 |<-Provider network->|牋牋 :

>>牋牋牋牋牋牋 Customer牋牋牋牋牋牋牋牋牋牋牋牋牋 Customer

>>牋牋牋牋牋牋 interface牋牋牋 牋牋牋牋牋牋牋牋牋interface

>>

>>牋牋牋牋牋牋牋牋 Figure 7.2: Overlay Service Model

>>

>>牋 In this model, the overlay is instantiated by an overlay

>>牋 "provider" and its provider edge (PE) nodes , and is used by

>>牋 the overlay "customer" which is connected to the provider via

>>牋 customer interfaces attached to customer edge (CE) nodes.

>>

>>牋 ...

>>

>> The definition below would need to be tweaked slightly, notably to

>> remove any references to client and server. The resulting framework

>> can also refer back to RFC 4847 as needed.

>>

>> See below for some additional comments.

>>

>> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote:

>>> Dear overlayers,

>>>

>>> Please find below a new version (v2) of the framework summary

>>> reflecting the latest discussions. Again i hope i've

>> captured all the

>>> comments around, sorry if anything is missing, in case just let me

>>> know what i missed.

>>>

>>> BR

>>> Daniele

>>>

>>>

>>> + Disclaimer:

>>> 1. Packet opto integration is often considered but the work can be

>>> extented to any type of SC. Eg. TDM over LSC.

>>>

>>> + Terminology:

>>> 1. Virtual Link: A virtual link is a potential path between two

>>> virtual or real network elements in a provider layer network

>> that is

>>> maintained/controlled in and by the provider domain control

>> plane (and

>>> as such cannot transport any traffic/data and protected from being

>>> de-provisioned) and which can be instantiated in the data plane (and

>>> then can carry/transport/forward traffic/data) preserving previously

>>> advertised attributes such as fate sharing information.

>>>

>>

>> You say "potential path". I this this should read "potential or

>> instantiated path".

>>

>

> Maybe we need to define also what "potential" stands for? At least two

> cases come to my mind (which might be included under the "potential"

> umbrella):

>

> 1. resources reserved via signaling but not instantiated

Sure. Sounds like a RFC6001 soft FA.

> 2. resources not even signaled. In presence of a centralized entity

> managing the network (sort of PCE plus something) there is no need to

> reserve resources via signaling as the central entity is the only

> thing that can reserve or allocate resources. I'm thinking to an

> opening towards the integration with the SDN world.

>

Sure. Sounds like a Virtual TE link (per RFC6001, 5212).

> Just loud thinking, does it make sense?

>

>>From my perspective, I think a node in the overlay really shouldn't

>> *directly* distinguish between the two -- now one may have a

>>different metric/SRLG/weight/etc, but these are abstracted

>>representations of the tradeoffs between use of the two, that can be

>>provided by the underlying provider network, rather than a direct

>>indication.

>>

>>> 2. Virtual Node: Virtual node is a collection of zero or more

>>> provider network domain nodes that are collectively

>> represented to the

>>> clients as a single node that exists in the customer layer

>> network and

>>> is capable of terminating of access, inter-domain and virtual links.

>>>

>>

>> I'm a little uncomfortable with the linkage of real nodes to virtual

>> nodes. I think VN is a purely abstract concept that may be

>> instantiated using parts/whole/multiple/logical/real/etc nodes.

>

> Makes sense. What this definition adds to the one in RFC4847 is

> basically the fact that also parts of a node can be considered. What

> saying that it can be a real node i meant 1:1 correspondance between a

> real and a virtual node. Your definition covers that case also, that's

> fine.

>

>>

>> How about something like:

>> Virtual Node: A virtual node is a representation of a collection of

>> provider resources that are interconnected via virtual (and customer)

>> links. A virtual node may be collection of zero or more, including

>> portions of, provider nodes that are collectively represented to the

>> customer as a single node which is available in an overlay network.

>

> Works for me.

>

Great. BTW I don't think 4847 precluded a single physical node being represented as multiple virtual nodes, but it doesn't hurt to make it explicit.

>>

>>> 3. Virtual Topology: Virtual topology is a collection of one or more

>>> virtual or real provider network domain nodes that exist in the

>>> customer layer network and are interconnected via 0 or more virtual

>>> links.

>>

>> How about:

>> Virtual Topology: A virtual topology is the collection of virtual

>> links and nodes advertised by a provider to a customer. The virtual

>> topology includes resources that are advertised as reachable within

>> an overlay network.

>>

>> Do you mean to imply/allow for a VN which has no links?

>

> The case of "interconnected via 0 virtual links" implies the whole

> domain seen as a single node.

>

Ahh, fair enough.

>>

>>> 4. Overlay topology: is a superset of virtual topologies

>> provided by

>>> each of provider network domains, access and inter-domain links.

>>>

>>

>> Doesn't it also include any topology information advertised by the

>> customer/CE as well?

>

> Possibly. Do you mean advertised by the CE in the customer domain, right?

>

That's possible too, but I was thinking more of advertised by CE

(customer) to PE (provider).

>>

>>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It

>>> can support any of the SCs supported by the GMPLS.

>>>

>>

>> If we adopt RFC 4847 terminology it should be "customer interface".

>> Also, I suspect you mean PE and CE.

>

> Mmm, yes but what if we want to manage it as a link? i.e. All

> TE-parameters that a link supports. Is it enough to call it interface

> only?

>

sure. Per 4847, I'd say that "customer interface" is the connection between CE/PE while [virtual] TE links are what is advertised/represented in routing.

>>

>>> 6. CE (customer Edge): Something like the CN in RFC4208

>> teminology but

>>> (i) receiving virtual topology from the provider network and

>>> requesting the set up of one of them or (ii) requesting the

>>> computation and establishment of a path accordingly to given

>>> constraints in the provider network and receiving the parameters

>>> characterizing such path. (ii) == UNI.

>>>

>>

>> humm, I'm inclined to stay away from UNI for the moment. I also

>> suggest that we look to 4874 and even 4364 rather than 4208...

>

> Ok, we can refer to those RFC for what concerns terminology, but at

> the end of the day we must put the UNI under this framework. In the

> new terminology the UNI is a particular type of customer interface.

>

Fair enough. But it is a form on an overlay "customer interface" not the definitive form.

>>

>>> 7. PE (provider Edge): Something like the EN in RFC4208 but able to

>>> deal with (i) and (ii) above.

>>>

>>

>> same comment WRT RFCs.

>>

>>> 8. PE-CE interface (former ONI) : Interface allowing for

>> signaling and

>>> routing messages exchange between customer overlay and provider

>>> network. Routing information consists on virtual topology

>>> advertisement. When there is no routing adjacency across the

>> interface

>>> it is equivalent to the GMPLS UNI defined in 4208.

>>> Signaling messages are compliant with RFC4208. Information

>> related to

>>> path carachteristics, e.g. TE-metrics, collected SRLG, path

>> delay etc,

>>> either passed from CE to PE via signaling after the LSP

>> establishment

>>> in the core network or from CE to PE to be used as path computation

>>> constraints, fall under the definition of signaling info and not

>>> routing info).

>>>

>>

>>

>>> 9. CE-CE (former O-NNI): Interface on the links between different

>>> provider networks in the overlay model environment. Same features of

>>> the CE-PE apply to this interface.

>>>

>>

>> you mean, PE-PE, right?

>

> You're not the first one that makes me notice i'm probably affected by

> dyslexia :-)

>

no problem, happens to the best of us!

>>

>>> + Statements 1. In the context of overlay model we are aiming to

>>> build an overlay topology for the customer network domains

>>>

>>> 2. The overlay topology is comprised of:

>>>牋牋 a) access links (links connecting client NEs to the

>> provider network domains).

>>> They can be PSC or LSC.

>>>牋牋 b) inter-domain links (links interconnecting server

>> network domains)

>>>牋牋 c) virtual topology provided by the provider network domains.

>>> Virtual Links

>>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of

>>> + parameters

>>> e.g. SRLG, optical impairments, delay etc for each entry) describing

>>> connectivity between access links and virtual links.

>>>

>>> 3. In the context of overlay model we manage hierarchy of overlay

>>> topologies with overlay/underlay relationships

>>>

>>> 4. In the context of overlay model multi-layering and inter-layer

>>> relationships are peripheral at best, it is all about horizontal

>>> network integration

>>>

>>> 5. The overlay model assumes one CP instance for the

>> customer network

>>> and a separate instance for the provider network and in the CE-PE

>>> interface case the provider network also surreptitiously

>> participates

>>> in the customer network by injecting virtual topology

>> information into

>>> it.

>>>

>>

>> We should ensure we're allowing for some of the existing/augmented

>> models that permit the transport of overlay information within the

>> provider's CP, e.g., rfc4364, 5195 and 5252.

>

> I'd say they should be already covered, but will double check

>

great.

>>

>>> 6. L1VPN (and LxVPN) in general is a type of service

>> provided over the

>>> CE-PE interface (it falls under the UNI case as no routing adjacency

>>> is in place between CE and PE).

>>>

>>>

>>> + Advertisement models (to be detailed in dedicated

>>> + document/documents)

>>> The CE-PE interface in the overlay model context foresees

>> two types of

>>> advertisement models.(names still to be agreed)

>>>

>>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and

>> augmented by

>>> a number of actived draft (references to various drafts to

>> be added).

>>> The Augmented UNI is a particular type of CE-PE interface where only

>>> signaling messages are exchanged between CE and PE.

>>> Messages from CE to PE can include a set of parameters to be used by

>>> the PE as path computation constraints when computing a path in the

>>> provider domain network, while messages from PE to CE can include a

>>> set of parameters qualifying the LSP being established, like for

>>> example SRLG, delay, loss etc.

>>>

>>

>> again, we can leverage 4874 terminology if we so choose, i.e., "basic

>> mode" and "enhanced mode" UNI|NNI

>

> Don would be happy about that :-). I'd say yes. The goal was to cover

> the L1VPN work (enhanced mode), all the drafts-ali recently polled

> for wg adoption (basic mode?) and the actual ENNI (enhanced mode).

> Is my mapping in brackets correct?

>

Not sure f I'd break it down they way you are. I'd say basic mode is closer to the typical UNI and enhance mode is UNI+routing or perhaps even an ENNI.

>

>>

>>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply

>>> called with the general CE-PE interface term?) allowing the

>>> establishment of signaling and routing adjacency between CE and PE.

>>> Routing info passed from PE to CE comprise overlay topology

>>> information including (but not limited to) virtual links,

>> connectivity

>>> matrices and access links with parameters qualifying each of them in

>>> terms of e.g. SRLG, loss, delay etc. Signaling information and

>>> procedures are compliant with RFC4208.

>>>

>>

>> so this is just and 4874 "enhanced mode" interface, right.

>

> Good question: the enhanced mode supports signaling and routing, so

> i'd say yes, but reading section 7.3 it talks about "limited exchange

> of information between the control planes.

>

>牋 "permits limited exchange of

>牋 information between the control planes of the provider and the

>牋 customer to help such functions as discovery of customer network

>牋 routing information (i.e., reachability or TE information in remote

>牋 customer sites), or parameters of the part of the provider's network

>牋 dedicated to the customer."

>

> Would you say this includes what we want? (i.e. Virtual links, virtual

> nodes, connectivity matrices, SRLG, delay, loss, etc) If yes we're

> done, otherwise an option could be the denition of a third VPN service

> model.

>

humm, need to think about this. Perhaps the best thing is to document the two different cases and then decide if we have something new or

(two) more detailed forms of something old.

>>

>>> + Open issues/questions

>>> 1. PCE-PCEP - do we need to include considerations about PCE

>> and PCEP

>>> into the overlay framework context?

>>>

>>> 2. BGP-LS needs to be considered

>>> 3. Should potentials be included? E.g. I2RS?

>>> 4. Virtual links: wouldn't a different definition of virtual links

>>> avoid the advertisement of connectivity matrices (this is out of the

>>> fwk scope but within the advertisement models one)?

>>>

>>

>>> Take this example:

>>> PE1-----CE1牋牋牋牋牋牋牋 CE2-----PE2

>>>牋牋牋牋 CE1======VL1======CE2

>>>牋牋牋牋 CE1======VL2======CE2

>>

>> I think you've reversed CE and PE here...

>

> Yes, once again.

>

> No comment on my foolish proposal?

>

Which one? I liked your summary overall.

Lou

>

>>

>> Much thanks!

>>

>> Lou

>> (hatless...)

>>

>>> i.e. There are 2 VL connecting CE1 and CE2 that could be

>> available for

>>> PE1 and PE2 to set up an adjacency in the customer domain.

>> CE1 and/or

>>> CE2 can be blocking nodes so VL1 and/or VL2 are available only

>>> depending on the connectivity matrices of CE1 and CE2. Hence

>> PEs need

>>> to be aware of both VL and connectivity matrices. My point

>> is: if CE1

>>> advertises to PE1 only the VL that his connectivity matrix allows to

>>> be connected to PE1 (e.g. VL1 only) and not all of them, it

>> should be

>>> possible to avoid the connectivity matrices advertisement.

>>>

>>

>>>

>>> ===================================

>>> DANIELE CECCARELLI

>>> System & Technology - PDU Optical & Metro

>>>

>>> Via E.Melen, 77

>>> Genova, Italy

>>> Phone +390106002512

>>> Mobile +393346725750

>>> daniele.ceccarelli@ericsson.com

>>> www.ericsson.com

>>>

>>

>

>

>

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

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


--

DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) Hans-J鰎g Daub Dr. Rainer Fechner Andreas Gehe

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.
--------------080801060808080507050500 Content-Type: image/jpeg; name="Corporate-sig-logo.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Corporate-sig-logo.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoL EAACAQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOh sfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5 OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX 2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRx CEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVW N4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiI mKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A3+Pfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69 1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvnsm0T1ExVp4aKgx+P pIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBVRQWdjhVBPl09 bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnDsnYeNhlS t353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs6eNO xxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ 7Acje43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BIN KHjT7QSPl1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3 PH4/Pq/b0eT0e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT 51rSnRWch3x82aXqD5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7 jxFdV1j4TJaq6J6L7a/lkQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1 +i9/YvC0VVt7r6j2f9umY7C/jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4K Yys7u617g3DtL45dIN8iev44/kN1HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWp jPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72i yUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfPqn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0d L3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkFWRjEDeM1aInut0WtK46Hyr7F+REPyX2R 1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvWb0i7jz1LWYYx1K5iFkpWMrKQhgZZ PdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh1/HTdgdV0u+MRhIO0YOz5aBN t4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0HFV/Gyr6SrN75T5Mnsfb0 E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/In5+r8YMp2ZT/AAAo JPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6Pfut0WtK4+zox q9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNESRCCZCQv utUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9ppiTtr KyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y 8h8B8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm 1HVSyx+/dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr 5+uzTrn9ttjaeJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b3 10AfkPsCeDoPqKv3bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaH yVl787t2HP8AGeli6R2R1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoW YI8c6BPdaoKcc9BLi++PnVU9IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq 0W8o6WTC9mVWJ29j8dkP4JjmWtL5E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11t fcXx07THcm1UqPkPv7J7Xq8luHYNbtE0L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q9 5/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Ti z91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZn ObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8AY6S1D3l8yKjY/wAOs3UfC+Cm3h3H urA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0zOT4L+V1ce63Rc5+zrXk/m+/N PFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27fkrt/dO69n7RzOydsQYf 4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQveG1+kG+YX8475J7R HyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWqqJI09+69QUqR Wi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou3N0bl7bh 7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP/n3f If4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D 2f1juzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1q iUOe2or506MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7ox c9PgMzNkcNHFkIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi0 6hgjpyeOGOR0t38SEEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2f Uz/7L/2dlPieazAU9AaOT+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z 9H8DvlB/M/h762NkqPau5e3uv9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7c FNU1VJjK2i/ap6emp5EqT7reldQT+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F /HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0 w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cu LyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7/hQ7W75qfjn8beq9vy1mal7A7yo6KvpK KlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+8sfulw7fFzVu283xVTabWSHbgiNI pkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt742fyrYqvMb7+RvyK33s7fPy0o NgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHkq9o6Srnp8od3vMvNvOF3 vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXbS7xhbWJSI9Qr8u0c Kk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5Jtr9LVf9/cbi 8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WVoZGuKSXY 8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv/u5/ EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r 3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf uvde9+691737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7Ahl pnTdC5HaVFFjpVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w 8FNt+u3vjtqYfY2O3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjN z7Oqcl8PuhpZthbewm09sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63 rb1PSw3N8BfhPvPcvbe8N2fFforce5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3 FUlcKtl+7NZSQTmQywxuvuvam9TjpWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP 2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7i fx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/ g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSxHX2Dx22tgxYlkpBTRVmx9vYejosPVtG1 XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+3Oz9uZ/aXY2+JuvduT5TfO392U70 m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnTL13/AC+vhL1NjosR1z8Yen9p 4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4o8aaiT7dYw7X91ssx4np T9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ33Xzz0xqTuyh2hQxY pK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7LVQlpsPg947Zo 6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBcotNTQuQSV BoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ2D2x HndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3 b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U 49O+U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN 25jcvXfa4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMi apnXUqqFLJErN1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h /wANi+4/0ufxn++n9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sN WPpdHg+Bq4avB/Hpp4v6mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697 917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X uve/de697917r3v3XugA+RP/AB59D/zID/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/ ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8A N3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/an4/9v8X59C17IumOv//Z --------------080801060808080507050500-- From zhangfatai@huawei.com Wed Jan 23 03:50:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86B621F8951 for ; Wed, 23 Jan 2013 03:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 r54Px-NDjH8R for ; Wed, 23 Jan 2013 03:50:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA5721F894C for ; Wed, 23 Jan 2013 03:50:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANU51263; Wed, 23 Jan 2013 11:50:00 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 23 Jan 2013 11:49:45 +0000 Received: from SZXEML462-HUB.china.huawei.com (10.82.67.205) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 23 Jan 2013 11:49:57 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by szxeml462-hub.china.huawei.com ([10.82.67.205]) with mapi id 14.01.0323.007; Wed, 23 Jan 2013 19:49:52 +0800 From: Fatai Zhang To: Lou Berger Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 Thread-Index: AQHN4nqPdVRTcHuIFUSv0ekPirccYZg3rcsAgBJvoeCAABn/gIABKi7ggAIHU4CABdAXUIACE6eAgAGrfQA= Date: Wed, 23 Jan 2013 11:49:52 +0000 Message-ID: References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> <50F58A35.7040806@labn.net> <50F837FB.2010806@labn.net> <50FED643.6020708@labn.net> In-Reply-To: <50FED643.6020708@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 11:50:04 -0000 Hi Lou, For ODUflex(CBR), the formula is from [G.709-2012] and it has been discusse= d before, so please trust that there is no opportunity for misinterpretatio= n. (Note that there are two cases, one is ODUflex(CBR) and another one is ODUf= lex(GFP)).=20 In addtion, ODUflex cannot be concatenated by [G.709-2012]. I will issue a new version tomorrow to capture all your comments. Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, January 23, 2013 2:11 AM To: Fatai Zhang Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signal= ing-g709v3-04 Fatai, On 1/20/2013 9:43 PM, Fatai Zhang wrote: > Hi Lou, >=20 > You said: >> but you're says encoded as (N*Nominal Rate) right? Wat's the value of th= is vs just carrying N? >=20 > [Fatai] The original way (in version 04&05) is putting (N* Nominal > Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can > generalize to just use one single "Bit_Rate" field to carry IEEE > float number for both cases, it seems that you don't agree on this > value, :-) I've seen differences in calculated floating point values from different implementations, so I just want to ensure that such cases are avoided. I'm open to specific solutions and certainly will deffer on the specifics assuming there is no opportunity for misinterpretation/interop issues. I don't think the original passed this threshold, i.e.,: N =3D Ceiling of ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) --------------------------------------------------------------------- ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) > . Therefore, I (was) am saying that I am going to accept > your suggestion to carry N for ODUflex(GFP). We are discussing where > to put N for ODUflex(GFP). >=20 > You said: >> bits in the control plane are generally cheap, IMO it's better to have s= impler encoding than to optimize every bit (or 8 in this case). >=20 > [Fatai] OK, I will add a new field (to occupy the reserved bits) to carry= N. As you see fit. Just to clarify my understanding, ODUflex and Virtual concatenation can never be combined for the same signal type/level, right? (Although an ODUflex client signal could be carried over a virtual concatenated ODUk). Is this correct or did I miss something in G709? Thanks, Lou >=20 >=20 >=20 > Best Regards >=20 > Fatai >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Friday, January 18, 2013 1:42 AM > To: Fatai Zhang > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-sign= aling-g709v3-04 >=20 >=20 >=20 > On 1/15/2013 10:16 PM, Fatai Zhang wrote: >> Hi Lou, >> >> To avoid misunderstanding, I would like to clarify more on the >> following point. >> >> >>>>>> It is better to have consistent format and the same meaning of one > field for both ODUflex(CBR) and GFP. This is why we have section 5.1 > &5.2 to describe the complex stuff. >>>>> I actually wasn't suggesting that N be carried in the bit rate field. >>>>> The bit rate field can either be set as described or to zero (i.e., >>>>> ignored). At the time, I was thinking about carrying N in the reserv= ed >>>>> field. But perhaps the right place is MT, if my understanding is righ= t >>>>> (would always be 1 otherwise). I'm open to either... >>>>> >>>> [Fatai] Why not just use "bit rate"field to carry "N"because "N" >>>> implies bit rate? I am OK if you like to use a new filed (like "TS >>>> Number") to occupy the reserved field even though that I prefer the >>>> original approach (ie., use "bit rate"field to carry "N"). >>> >>> Are you proposing dropping carrying bit rates represented as an IEEE >>> floating point and just carrying N for ODUflex? This seems workable to >>> me, but we should ensure that there are no significant objections. >> >> [Fatai] There are two usages for " Bit_Rate " field as described in the >> lines 287-310. >> >> (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal bit >> rate of ODUflex(CBR) expressed in bytes per second, encoded as a 32-bit >> IEEE single precision floating-point number. For this case, we MUST use >> 32-bit IEEE floating point instead of "N"(Please see more in section 5.1= ). >=20 > I guess you really still need (to be based on) the client signal rate at > the edges. >=20 >> >> (2) For ODUflex(GFP), we can change the text (the lines from 305 to >> 310) based on your suggestion, ie., the Bit_Rate field is used to carry >> "N"to indicate the nominal bit rate of the >> ODUflex(GFP). >=20 > but you're says encoded as (N*Nominal Rate) right? Wat's the value of > this vs just carrying N? >=20 >=20 >> >> Therefore, I am proposing using one single filed ("Bit_Rate ") for these >> two cases, in this way, we can leave the "Reserved" bits for future. >=20 > bits in the control plane are generally cheap, IMO it's better to have > simpler encoding than to optimize every bit (or 8 in this case). >=20 > Lou >=20 >> >> Hope we are now at the same page. >> >> >> Best Regards >> >> Fatai >=20 >=20 >=20 >=20 From lberger@labn.net Wed Jan 23 07:08:24 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2050621F869A for ; Wed, 23 Jan 2013 07:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.981 X-Spam-Level: X-Spam-Status: No, score=-100.981 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 o2q-+cHjx75V for ; Wed, 23 Jan 2013 07:08:23 -0800 (PST) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 457AF21F869F for ; Wed, 23 Jan 2013 07:08:23 -0800 (PST) Received: (qmail 7908 invoked by uid 0); 23 Jan 2013 15:07:59 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 23 Jan 2013 15:07:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Hr6tJ0vrMIXm0hqzQMg5tFEHbcHloz+VBVjjCCCLSbo=; b=Sv1Gw9b3BvqDOoCE7HQQ2waeN2s+e5vVWNwUIyJ+NbyTkV9s66ZAGL21J73i16veGt7dw44sU/8NXDH01uD5xbBYMV86MJpWp6hvKIWDEacMiImIq31wQ8Ak+U5+6oaB; Received: from box313.bluehost.com ([69.89.31.113]:37340 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ty1vi-00059B-QJ; Wed, 23 Jan 2013 08:07:59 -0700 Message-ID: <50FFFCD6.5010004@labn.net> Date: Wed, 23 Jan 2013 10:08:06 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fatai Zhang References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> <50F58A35.7040806@labn.net> <50F837FB.2010806@labn.net> <50FED643.6020708@labn.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:08:24 -0000 Fatai, On 1/23/2013 6:49 AM, Fatai Zhang wrote: > Hi Lou, > > For ODUflex(CBR), the formula is from [G.709-2012] and it has been > discussed before, so please trust that there is no opportunity for > misinterpretation. (Note that there are two cases, one is > ODUflex(CBR) and another one is ODUflex(GFP)). > > In addtion, ODUflex cannot be concatenated by [G.709-2012]. Thanks for confirming my understanding. This raises the question of if the new traffic should just apply to ODUFlex? Correct me if I'm wrong, but I believe the [RFC4328] is sufficient in all other cases. This may also make it easier for early implementations of the draft as then they can limit code changes from the (-03) rev to only ODUflex LSPs. Just to be clear, I'm really just *asking* about this. As I said before, I'm open on specifics... Any thoughts/comments? Authors? Implementors? Thanks, Lou > I will issue a new version tomorrow to capture all your comments. > > > Best Regards > > Fatai > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, January 23, 2013 2:11 AM > To: Fatai Zhang > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 > > Fatai, > > On 1/20/2013 9:43 PM, Fatai Zhang wrote: >> Hi Lou, >> >> You said: >>> but you're says encoded as (N*Nominal Rate) right? Wat's the value of this vs just carrying N? >> >> [Fatai] The original way (in version 04&05) is putting (N* Nominal >> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can >> generalize to just use one single "Bit_Rate" field to carry IEEE >> float number for both cases, it seems that you don't agree on this >> value, :-) > > I've seen differences in calculated floating point values from different > implementations, so I just want to ensure that such cases are avoided. > I'm open to specific solutions and certainly will deffer on the > specifics assuming there is no opportunity for misinterpretation/interop > issues. I don't think the original passed this threshold, i.e.,: > > N = Ceiling of > > ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) > --------------------------------------------------------------------- > ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) > >> . Therefore, I (was) am saying that I am going to accept >> your suggestion to carry N for ODUflex(GFP). We are discussing where >> to put N for ODUflex(GFP). >> > >> You said: >>> bits in the control plane are generally cheap, IMO it's better to have simpler encoding than to optimize every bit (or 8 in this case). >> >> [Fatai] OK, I will add a new field (to occupy the reserved bits) to carry N. > > As you see fit. > > Just to clarify my understanding, ODUflex and Virtual concatenation can > never be combined for the same signal type/level, right? (Although an > ODUflex client signal could be carried over a virtual concatenated > ODUk). Is this correct or did I miss something in G709? > > Thanks, > Lou > >> >> >> >> Best Regards >> >> Fatai >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, January 18, 2013 1:42 AM >> To: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 >> >> >> >> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> To avoid misunderstanding, I would like to clarify more on the >>> following point. >>> >>> >>>>>>> It is better to have consistent format and the same meaning of one >> field for both ODUflex(CBR) and GFP. This is why we have section 5.1 >> &5.2 to describe the complex stuff. >>>>>> I actually wasn't suggesting that N be carried in the bit rate field. >>>>>> The bit rate field can either be set as described or to zero (i.e., >>>>>> ignored). At the time, I was thinking about carrying N in the reserved >>>>>> field. But perhaps the right place is MT, if my understanding is right >>>>>> (would always be 1 otherwise). I'm open to either... >>>>>> >>>>> [Fatai] Why not just use "bit rate"field to carry "N"because "N" >>>>> implies bit rate? I am OK if you like to use a new filed (like "TS >>>>> Number") to occupy the reserved field even though that I prefer the >>>>> original approach (ie., use "bit rate"field to carry "N"). >>>> >>>> Are you proposing dropping carrying bit rates represented as an IEEE >>>> floating point and just carrying N for ODUflex? This seems workable to >>>> me, but we should ensure that there are no significant objections. >>> >>> [Fatai] There are two usages for " Bit_Rate " field as described in the >>> lines 287-310. >>> >>> (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal bit >>> rate of ODUflex(CBR) expressed in bytes per second, encoded as a 32-bit >>> IEEE single precision floating-point number. For this case, we MUST use >>> 32-bit IEEE floating point instead of "N"(Please see more in section 5.1). >> >> I guess you really still need (to be based on) the client signal rate at >> the edges. >> >>> >>> (2) For ODUflex(GFP), we can change the text (the lines from 305 to >>> 310) based on your suggestion, ie., the Bit_Rate field is used to carry >>> "N"to indicate the nominal bit rate of the >>> ODUflex(GFP). >> >> but you're says encoded as (N*Nominal Rate) right? Wat's the value of >> this vs just carrying N? >> >> >>> >>> Therefore, I am proposing using one single filed ("Bit_Rate ") for these >>> two cases, in this way, we can leave the "Reserved" bits for future. >> >> bits in the control plane are generally cheap, IMO it's better to have >> simpler encoding than to optimize every bit (or 8 in this case). >> >> Lou >> >>> >>> Hope we are now at the same page. >>> >>> >>> Best Regards >>> >>> Fatai >> >> >> >> > > > > From lberger@labn.net Wed Jan 23 07:11:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59CD21F8698 for ; Wed, 23 Jan 2013 07:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.059 X-Spam-Level: X-Spam-Status: No, score=-101.059 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1, 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 lezH4tvUnSHm for ; Wed, 23 Jan 2013 07:11:19 -0800 (PST) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id DAF5121F8697 for ; Wed, 23 Jan 2013 07:11:18 -0800 (PST) Received: (qmail 30002 invoked by uid 0); 23 Jan 2013 15:10:56 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 23 Jan 2013 15:10:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=KfBjGJN7P/4ogK9rkXsCmQ6RODdibTHpkC8Vm/sT50c=; b=RDIE4P7nR18ZCF28z5rKUsSJjbOB5YLAPAQo4ZmmJsWILf5SCxNiJTxtwlWFP09UeiDpKwr0qtvFT+O0sA5eLyD5budXzvpOCRGbRLMl5RKpUeDCQagXgpisSMXpeibz; Received: from box313.bluehost.com ([69.89.31.113]:37789 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ty1ya-0007Gf-2S; Wed, 23 Jan 2013 08:10:56 -0700 Message-ID: <50FFFD87.6010201@labn.net> Date: Wed, 23 Jan 2013 10:11:03 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gert Grammel References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <50FEBC58.2030803@labn.net> <305443B66F0CD946A3107753337A031113F8F928@CH1PRD0511MB431.namprd05.prod.outlook.com> In-Reply-To: <305443B66F0CD946A3107753337A031113F8F928@CH1PRD0511MB431.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:11:21 -0000 Gert, Sure. (As I mentioned) reuse of existing *generic* parameters would be preferable to adding a new, and very use case specific, one. Lou On 1/22/2013 6:03 PM, Gert Grammel wrote: > Lou, > > playing with TE metric is indeed not the best idea. However representing the server U-bit in a client domain admin color might be interesting. (sorry for still using the old acronyms) > > Gert > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin > Sent: Dienstag, 22. Januar 2013 17:42 > To: Lou Berger > Cc: CCAMP > Subject: Re: [CCAMP] Overlay model framework v2 > > Lou, > Generally it is not a good idea to play with the TE metric. > It is up to client path computer (or client policy) to decide how important the difference between a committed and uncommitted VL, and hence to define the TE metric penalty. > Igor > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, January 22, 2013 11:21 AM > To: Igor Bryskin > Cc: Daniele Ceccarelli; CCAMP > Subject: Re: [CCAMP] Overlay model framework v2 > > Igor, > I was referring to you comment: > > IB>> It is beneficial from the client (ONT user) path computation point > IB>> of view to know whether the advertised VL is committed (the data > IB>> plane is provisioned) or not. > > So my point is that the U bit should be represented via an increased metric (or some other existing parameter) as this is what path computation is going to do in effect in any case. > > Lou > > On 1/22/2013 11:09 AM, Igor Bryskin wrote: >> Hi Lou, >> >> You said: >> And I'm suggesting that this be advertised using generic constructs such as TE metric, SRLG, and even MELG, rather than adding yet another special case computation/optimization parameter. >> >> Agree, we are already doing this via MELG sub-TLV. This is because the sub-TLV is new (no need to change the existing ones) and because MELG is peculiar to VL. >> >> Igor. >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, January 22, 2013 10:51 AM >> To: Igor Bryskin >> Cc: Daniele Ceccarelli; CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Igor, >> >> see below. >> >> On 1/22/2013 10:05 AM, Igor Bryskin wrote: >>> Lou and Daniele, >>> Please, see my comments in-line, >>> >>> Cheers, >>> Igor >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Monday, January 21, 2013 5:13 PM >>> To: Daniele Ceccarelli >>> Cc: CCAMP >>> Subject: Re: [CCAMP] Overlay model framework v2 >>> >>> Thanks Daniele, See below. >>> >>> On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: >>>> Hi Lou, >>>> >>>> Please find comments in line >>>> >>>> BR >>>> Daniele >>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: venerd 18 gennaio 2013 18.27 >>>>> To: Daniele Ceccarelli >>>>> Cc: CCAMP >>>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>>> >>>>> Daniele, >>>>> Very nice summary. Just catching up, so sorry for the >>>>> (2 day) late response. >>>>> >>>>> I really like how the terminology has evolved and appreciate the >>>>> summary! >>>>> >>>>> I have a few detail comments, but before I go there I'd like to >>>>> cover one more open issue that I think will have some >>>>> (minor) ripple effects on the details. >>>>> >>>>> I think there's still the general issue of terminology to use when >>>>> referring to the entity that "uses an overlay" and the entity that >>>>> "instantiates the overlay". In your mail and in discussion we have: >>>>> >>>>> - client (service)/OC/CN/customer >>>>> >>>>> and >>>>> >>>>> - server(or service)/OE/EN/provider >>>>> >>>>> I think we had discussed, and possibly agreed on, using VPN >>>>> terminology which would have us use the latter options, i.e., >>>>> (overlay) customer/provider (edge). This would mean eliminating >>>>> any references to client/server in the *generic >>>>> overlay* definitions. Of course these terms may reemerge in other >>>>> contexts as they have before, e.g., rfc6215. >>>> >>>> Yes, i think we all agreed. If there are still terms different from >>>> customer/provider in the text it's because i missed them during the >>>> replacing. >>>> >>> >>> Great! Glad I didn't miss something over the holidays! >>> >>> IB>> I personally have no problems with the VPN terminology. However, >>> IMO the terminology should be aligned with the RFC 4208 and George's >>> drafts. >> >> My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped to encompass the broad spectrum of overlays that are/have been discussed. >> >>> One cannot use different terminology within the same framework, right? >> >> Unfortunately we have no shortage of terminology defining (perhaps different flavors) of the same thing! >> >>> Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. >> >> While I certainly agree that not all overlays need be VPNs, it seems to me that our discussions are best aligned with that set of terminology, and that UNI/ENNI can be described within the CE/PE/VN/VL/VT constructs. >> Perhaps with some tweaking in some cases. >> >> >>> The most important goal is to provide a solution for inter-domain >>> horizontal integration between networks with possibly different >>> switching technologies and independent addressing within the overlay >>> model. >>> >> >> Sure. It's also possible that an overlay will use the same switching technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably less likely) the same address space (if a provider so chooses). >> >>>>> >>>>> I like this approach as it is aligned with the much of IETF work on >>>>> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). >>>>> Importantly, RFC 4847 even has quite a few concepts that can be >>>>> directly leveraged in this discussion. >>>>> >>>>> I'd even go further and say that we should base the definitions and >>>>> resulting framework on RFC 4847. For example, the definitions >>>>> below could start with something along the lines: >>>>> >>>>> The overlay service model, at a high level, follows Section >>>>> 7. of RFC 4847 as represented by: >>>>> >>>>> >>>>> +--------------------+ >>>>> : | | : >>>>> : | | : >>>>> +----+ : +----+ +----+ : +----+ >>>>> | CE |---:---| PE | | PE |---:---| CE | >>>>> +----+ : +----+ +----+ : +----+ >>>>> : | | : >>>>> : | | : >>>>> : +--------------------+ : >>>>> : | | : >>>>> : |<-Provider network->| : >>>>> Customer Customer >>>>> interface interface >>>>> >>>>> Figure 7.2: Overlay Service Model >>>>> >>>>> In this model, the overlay is instantiated by an overlay >>>>> "provider" and its provider edge (PE) nodes , and is used by >>>>> the overlay "customer" which is connected to the provider via >>>>> customer interfaces attached to customer edge (CE) nodes. >>>>> >>>>> ... >>>>> >>>>> The definition below would need to be tweaked slightly, notably to >>>>> remove any references to client and server. The resulting >>>>> framework can also refer back to RFC 4847 as needed. >>>>> >>>>> See below for some additional comments. >>>>> >>>>> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>>>>> Dear overlayers, >>>>>> >>>>>> Please find below a new version (v2) of the framework summary >>>>>> reflecting the latest discussions. Again i hope i've >>>>> captured all the >>>>>> comments around, sorry if anything is missing, in case just let me >>>>>> know what i missed. >>>>>> >>>>>> BR >>>>>> Daniele >>>>>> >>>>>> >>>>>> + Disclaimer: >>>>>> 1. Packet opto integration is often considered but the work can be >>>>>> extented to any type of SC. Eg. TDM over LSC. >>>>>> >>>>>> + Terminology: >>>>>> 1. Virtual Link: A virtual link is a potential path between two >>>>>> virtual or real network elements in a provider layer network >>>>> that is >>>>>> maintained/controlled in and by the provider domain control >>>>> plane (and >>>>>> as such cannot transport any traffic/data and protected from being >>>>>> de-provisioned) and which can be instantiated in the data plane >>>>>> (and then can carry/transport/forward traffic/data) preserving >>>>>> previously advertised attributes such as fate sharing information. >>>>>> >>>>> >>>>> You say "potential path". I this this should read "potential or >>>>> instantiated path". >>>>> >>>> >>>> Maybe we need to define also what "potential" stands for? At least >>>> two cases come to my mind (which might be included under the "potential" >>>> umbrella): >>>> >>>> 1. resources reserved via signaling but not instantiated >>> >>> Sure. Sounds like a RFC6001 soft FA. >>> >>>> 2. resources not even signaled. In presence of a centralized entity >>>> managing the network (sort of PCE plus something) there is no need >>>> to reserve resources via signaling as the central entity is the only >>>> thing that can reserve or allocate resources. I'm thinking to an >>>> opening towards the integration with the SDN world. >>>> >>> >>> Sure. Sounds like a Virtual TE link (per RFC6001, 5212). >>> >> IB>> Potential path can be defined as a feasible/provisionable path >> IB>> for >> the server layer trail supporting an advertised VL, which has attributes consistent with the ones advertised for the Virtual Link (noticeably, bandwidth, SRLGs, etc.) and is guaranteed to be available at the moment of the set-up of a client LSP that has selected the VL in its path across the provider domain. >>> >>>> Just loud thinking, does it make sense? >>>> >>>> >From my perspective, I think a node in the overlay really shouldn't >>>>> *directly* distinguish between the two -- now one may have a >>>>> different metric/SRLG/weight/etc, but these are abstracted >>>>> representations of the tradeoffs between use of the two, that can >>>>> be provided by the underlying provider network, rather than a >>>>> direct indication. >>> >> IB>> It is beneficial from the client (ONT user) path computation >> IB>> point of view to know whether the advertised VL is committed (the >> IB>> data plane is provisioned) or not. Selecting uncommitted VL means: >>> a) Higher probability of a client LSP setup failure; >>> b) Longer client LSP setup time; >>> c) Probability of effectively removing other VLs from the ONT (those >>> that share MELGs with the VL in question) >> >> And I'm suggesting that this be advertised using generic constructs such as TE metric, SRLG, and even MELG, rather than adding yet another special case computation/optimization parameter. >> >>> >>>>> >>>>>> 2. Virtual Node: Virtual node is a collection of zero or more >>>>>> provider network domain nodes that are collectively >>>>> represented to the >>>>>> clients as a single node that exists in the customer layer >>>>> network and >>>>>> is capable of terminating of access, inter-domain and virtual links. >>>>>> >>>>> >>>>> I'm a little uncomfortable with the linkage of real nodes to >>>>> virtual nodes. I think VN is a purely abstract concept that may be >>>>> instantiated using parts/whole/multiple/logical/real/etc nodes. >>>> >>> >>> IB>> Agree completely >>> >>>> Makes sense. What this definition adds to the one in RFC4847 is >>>> basically the fact that also parts of a node can be considered. What >>>> saying that it can be a real node i meant 1:1 correspondance between >>>> a real and a virtual node. Your definition covers that case also, >>>> that's fine. >>>> >>>>> >>>>> How about something like: >>>>> Virtual Node: A virtual node is a representation of a collection of >>>>> provider resources that are interconnected via virtual (and >>>>> customer) links. A virtual node may be collection of zero or >>>>> more, including portions of, provider nodes that are collectively >>>>> represented to the customer as a single node which is available in an overlay network. >>>> >>>> Works for me. >>>> >>> >>> Great. BTW I don't think 4847 precluded a single physical node being represented as multiple virtual nodes, but it doesn't hurt to make it explicit. >>> >>>>> >>>>>> 3. Virtual Topology: Virtual topology is a collection of one or >>>>>> more virtual or real provider network domain nodes that exist in >>>>>> the customer layer network and are interconnected via 0 or more >>>>>> virtual links. >>>>> >>>>> How about: >>>>> Virtual Topology: A virtual topology is the collection of virtual >>>>> links and nodes advertised by a provider to a customer. The virtual >>>>> topology includes resources that are advertised as reachable within >>>>> an overlay network. >>>>> >>>>> Do you mean to imply/allow for a VN which has no links? >>>> >>>> The case of "interconnected via 0 virtual links" implies the whole >>>> domain seen as a single node. >>>> >>> >>> Ahh, fair enough. >>> >>>>> >>>>>> 4. Overlay topology: is a superset of virtual topologies >>>>> provided by >>>>>> each of provider network domains, access and inter-domain links. >>>>>> >>>>> >>>>> Doesn't it also include any topology information advertised by the >>>>> customer/CE as well? >>> >>> IB>> Yes, it does: the ends of access links terminated by the clients >>> IB>> along with the custom NEs IDs >>> >> >> sounds like some agreement here. >> >> I think that was you final comment... >> >> Lou >> >>>> >>>> Possibly. Do you mean advertised by the CE in the customer domain, right? >>>> >>> >>> That's possible too, but I was thinking more of advertised by CE >>> (customer) to PE (provider). >>> >>>>> >>>>>> 5. Access Link: Link between OC and OE. GMPLS runs on that link. >>>>>> It can support any of the SCs supported by the GMPLS. >>>>>> >>>>> >>>>> If we adopt RFC 4847 terminology it should be "customer interface". >>>>> Also, I suspect you mean PE and CE. >>>> >>>> Mmm, yes but what if we want to manage it as a link? i.e. All >>>> TE-parameters that a link supports. Is it enough to call it >>>> interface only? >>>> >>> >>> sure. Per 4847, I'd say that "customer interface" is the connection between CE/PE while [virtual] TE links are what is advertised/represented in routing. >>> >>>>> >>>>>> 6. CE (customer Edge): Something like the CN in RFC4208 >>>>> teminology but >>>>>> (i) receiving virtual topology from the provider network and >>>>>> requesting the set up of one of them or (ii) requesting the >>>>>> computation and establishment of a path accordingly to given >>>>>> constraints in the provider network and receiving the parameters >>>>>> characterizing such path. (ii) == UNI. >>>>>> >>>>> >>>>> humm, I'm inclined to stay away from UNI for the moment. I also >>>>> suggest that we look to 4874 and even 4364 rather than 4208... >>>> >>>> Ok, we can refer to those RFC for what concerns terminology, but at >>>> the end of the day we must put the UNI under this framework. In the >>>> new terminology the UNI is a particular type of customer interface. >>>> >>> >>> Fair enough. But it is a form on an overlay "customer interface" not the definitive form. >>> >>>>> >>>>>> 7. PE (provider Edge): Something like the EN in RFC4208 but able >>>>>> to deal with (i) and (ii) above. >>>>>> >>>>> >>>>> same comment WRT RFCs. >>>>> >>>>>> 8. PE-CE interface (former ONI) : Interface allowing for >>>>> signaling and >>>>>> routing messages exchange between customer overlay and provider >>>>>> network. Routing information consists on virtual topology >>>>>> advertisement. When there is no routing adjacency across the >>>>> interface >>>>>> it is equivalent to the GMPLS UNI defined in 4208. >>>>>> Signaling messages are compliant with RFC4208. Information >>>>> related to >>>>>> path carachteristics, e.g. TE-metrics, collected SRLG, path >>>>> delay etc, >>>>>> either passed from CE to PE via signaling after the LSP >>>>> establishment >>>>>> in the core network or from CE to PE to be used as path >>>>>> computation constraints, fall under the definition of signaling >>>>>> info and not routing info). >>>>>> >>>>> >>>>> >>>>>> 9. CE-CE (former O-NNI): Interface on the links between different >>>>>> provider networks in the overlay model environment. Same features >>>>>> of the CE-PE apply to this interface. >>>>>> >>>>> >>>>> you mean, PE-PE, right? >>>> >>>> You're not the first one that makes me notice i'm probably affected >>>> by dyslexia :-) >>>> >>> >>> no problem, happens to the best of us! >>> >>>>> >>>>>> + Statements 1. In the context of overlay model we are aiming to >>>>>> build an overlay topology for the customer network domains >>>>>> >>>>>> 2. The overlay topology is comprised of: >>>>>> a) access links (links connecting client NEs to the >>>>> provider network domains). >>>>>> They can be PSC or LSC. >>>>>> b) inter-domain links (links interconnecting server >>>>> network domains) >>>>>> c) virtual topology provided by the provider network domains. >>>>>> Virtual Links >>>>>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of >>>>>> + parameters >>>>>> e.g. SRLG, optical impairments, delay etc for each entry) >>>>>> describing connectivity between access links and virtual links. >>>>>> >>>>>> 3. In the context of overlay model we manage hierarchy of >>>>>> overlay topologies with overlay/underlay relationships >>>>>> >>>>>> 4. In the context of overlay model multi-layering and inter-layer >>>>>> relationships are peripheral at best, it is all about horizontal >>>>>> network integration >>>>>> >>>>>> 5. The overlay model assumes one CP instance for the >>>>> customer network >>>>>> and a separate instance for the provider network and in the CE-PE >>>>>> interface case the provider network also surreptitiously >>>>> participates >>>>>> in the customer network by injecting virtual topology >>>>> information into >>>>>> it. >>>>>> >>>>> >>>>> We should ensure we're allowing for some of the existing/augmented >>>>> models that permit the transport of overlay information within the >>>>> provider's CP, e.g., rfc4364, 5195 and 5252. >>>> >>>> I'd say they should be already covered, but will double check >>>> >>> >>> great. >>> >>>>> >>>>>> 6. L1VPN (and LxVPN) in general is a type of service >>>>> provided over the >>>>>> CE-PE interface (it falls under the UNI case as no routing >>>>>> adjacency is in place between CE and PE). >>>>>> >>>>>> >>>>>> + Advertisement models (to be detailed in dedicated >>>>>> + document/documents) >>>>>> The CE-PE interface in the overlay model context foresees >>>>> two types of >>>>>> advertisement models.(names still to be agreed) >>>>>> >>>>>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >>>>> augmented by >>>>>> a number of actived draft (references to various drafts to >>>>> be added). >>>>>> The Augmented UNI is a particular type of CE-PE interface where >>>>>> only signaling messages are exchanged between CE and PE. >>>>>> Messages from CE to PE can include a set of parameters to be used >>>>>> by the PE as path computation constraints when computing a path in >>>>>> the provider domain network, while messages from PE to CE can >>>>>> include a set of parameters qualifying the LSP being established, >>>>>> like for example SRLG, delay, loss etc. >>>>>> >>>>> >>>>> again, we can leverage 4874 terminology if we so choose, i.e., >>>>> "basic mode" and "enhanced mode" UNI|NNI >>>> >>>> Don would be happy about that :-). I'd say yes. The goal was to >>>> cover the L1VPN work (enhanced mode), all the drafts-ali recently >>>> polled for wg adoption (basic mode?) and the actual ENNI (enhanced mode). >>> >>>> Is my mapping in brackets correct? >>>> >>> >>> Not sure f I'd break it down they way you are. I'd say basic mode is closer to the typical UNI and enhance mode is UNI+routing or perhaps even an ENNI. >>> >>>> >>>>> >>>>>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply >>>>>> called with the general CE-PE interface term?) allowing the >>>>>> establishment of signaling and routing adjacency between CE and PE. >>>>>> Routing info passed from PE to CE comprise overlay topology >>>>>> information including (but not limited to) virtual links, >>>>> connectivity >>>>>> matrices and access links with parameters qualifying each of them >>>>>> in terms of e.g. SRLG, loss, delay etc. Signaling information and >>>>>> procedures are compliant with RFC4208. >>>>>> >>>>> >>>>> so this is just and 4874 "enhanced mode" interface, right. >>>> >>>> Good question: the enhanced mode supports signaling and routing, so >>>> i'd say yes, but reading section 7.3 it talks about "limited >>>> exchange of information between the control planes. >>>> >>>> "permits limited exchange of >>>> information between the control planes of the provider and the >>>> customer to help such functions as discovery of customer network >>>> routing information (i.e., reachability or TE information in remote >>>> customer sites), or parameters of the part of the provider's network >>>> dedicated to the customer." >>>> >>>> Would you say this includes what we want? (i.e. Virtual links, >>>> virtual nodes, connectivity matrices, SRLG, delay, loss, etc) If yes >>>> we're done, otherwise an option could be the denition of a third VPN >>>> service model. >>>> >>> >>> humm, need to think about this. Perhaps the best thing is to >>> document the two different cases and then decide if we have something >>> new or >>> (two) more detailed forms of something old. >>> >>>>> >>>>>> + Open issues/questions >>>>>> 1. PCE-PCEP - do we need to include considerations about PCE >>>>> and PCEP >>>>>> into the overlay framework context? >>>>>> >>>>>> 2. BGP-LS needs to be considered >>>>>> 3. Should potentials be included? E.g. I2RS? >>>>>> 4. Virtual links: wouldn't a different definition of virtual links >>>>>> avoid the advertisement of connectivity matrices (this is out of >>>>>> the fwk scope but within the advertisement models one)? >>>>>> >>>>> >>>>>> Take this example: >>>>>> PE1-----CE1 CE2-----PE2 >>>>>> CE1======VL1======CE2 >>>>>> CE1======VL2======CE2 >>>>> >>>>> I think you've reversed CE and PE here... >>>> >>>> Yes, once again. >>>> >>>> No comment on my foolish proposal? >>>> >>> >>> Which one? I liked your summary overall. >>> >>> Lou >>> >>>> >>>>> >>>>> Much thanks! >>>>> >>>>> Lou >>>>> (hatless...) >>>>> >>>>>> i.e. There are 2 VL connecting CE1 and CE2 that could be >>>>> available for >>>>>> PE1 and PE2 to set up an adjacency in the customer domain. >>>>> CE1 and/or >>>>>> CE2 can be blocking nodes so VL1 and/or VL2 are available only >>>>>> depending on the connectivity matrices of CE1 and CE2. Hence >>>>> PEs need >>>>>> to be aware of both VL and connectivity matrices. My point >>>>> is: if CE1 >>>>>> advertises to PE1 only the VL that his connectivity matrix allows >>>>>> to be connected to PE1 (e.g. VL1 only) and not all of them, it >>>>> should be >>>>>> possible to avoid the connectivity matrices advertisement. >>>>>> >>>>> >>>>>> >>>>>> =================================== >>>>>> DANIELE CECCARELLI >>>>>> System & Technology - PDU Optical & Metro >>>>>> >>>>>> Via E.Melen, 77 >>>>>> Genova, Italy >>>>>> Phone +390106002512 >>>>>> Mobile +393346725750 >>>>>> daniele.ceccarelli@ericsson.com >>>>>> www.ericsson.com >>>>>> >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > From lberger@labn.net Wed Jan 23 07:22:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06E521F841C for ; Wed, 23 Jan 2013 07:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.607 X-Spam-Level: X-Spam-Status: No, score=-101.607 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 xtfHdgx2XtLJ for ; Wed, 23 Jan 2013 07:22:33 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 193ED21F841A for ; Wed, 23 Jan 2013 07:22:33 -0800 (PST) Received: (qmail 8029 invoked by uid 0); 23 Jan 2013 15:22:04 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 23 Jan 2013 15:22:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=CcxFZeTBGs0PhAfvv1IBaloxDTzufK5o3GbCv7MXpro=; b=x/QcUyLxQhPZISO3XhF09vEs4BzfmTR91QegE6d0/vq3zLZV+SCo+Q1RBUTiDZIG+4F3iXVckUhg8HtMhkewmcOdR6l/Uyo/tKSlhoUyZ7QoJtWSQu7sMVh6pns+sQD5; Received: from box313.bluehost.com ([69.89.31.113]:39213 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ty29M-0007tx-Lj; Wed, 23 Jan 2013 08:22:04 -0700 Message-ID: <51000024.8010700@labn.net> Date: Wed, 23 Jan 2013 10:22:12 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Igor Bryskin References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:22:33 -0000 On 1/22/2013 1:58 PM, Igor Bryskin wrote: >... > Besides, I believe nothing (terminology, architecture, protocol > solutions, etc.) of MLN/MRN is relevant to what we are/were trying > to achieve with ONTs. > > Igor > ... Igor, Can we take a step back for a moment from the (seemingly endless) terminology/architecture/framework debate? What additional (i.e., not already covered in a standalone draft, e.g., draft-ali-...) *protocol extensions* do you think need to be standardized (as PS)? Is it more than just MELG? Lou From IBryskin@advaoptical.com Wed Jan 23 07:26:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8774521F86DE for ; Wed, 23 Jan 2013 07:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_62=0.6] 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 n1GZAJmLpfTl for ; Wed, 23 Jan 2013 07:26:56 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 47F5A21F8428 for ; Wed, 23 Jan 2013 07:26:55 -0800 (PST) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0NFQpl8024066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jan 2013 16:26:52 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 23 Jan 2013 16:26:51 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Wed, 23 Jan 2013 10:26:49 -0500 From: Igor Bryskin To: Gert Grammel , Lou Berger Thread-Topic: [CCAMP] Overlay model framework v2 Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQBzClcAAJEUjQAAD8STgAAXoD7AAA1TKgAAChyl0P//t3cAgABQ0/CAAB/YgP//RLZg Date: Wed, 23 Jan 2013 15:26:48 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <50FEBC58.2030803@labn.net> <305443B66F0CD946A3107753337A031113F8F928@CH1PRD0511MB431.namprd05.prod.outlook.com> In-Reply-To: <305443B66F0CD946A3107753337A031113F8F928@CH1PRD0511MB431.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-23_05:2013-01-23, 2013-01-23, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:26:57 -0000 Gert, Changing color every time when a VL becomes committed/uncommitted is as bad= as changing VL's TE metric. Besides, you have only 32 colors for the entir= e domain (scarce resource). Furthermore, colors are used as constraints, wh= ile here you need actually a conscious (well understood and selected by a c= lient path computer) penalty for using an uncommitted VL for the path selec= tion optimization. Finally, this is a particularity of a Virtual Link that = has never been addresses before (even in the MLN/MRN documents!) and hence = requires a dedicated piece of advertisement. Igor -----Original Message----- From: Gert Grammel [mailto:ggrammel@juniper.net]=20 Sent: Tuesday, January 22, 2013 6:04 PM To: Igor Bryskin; Lou Berger Cc: CCAMP Subject: RE: [CCAMP] Overlay model framework v2 Lou, playing with TE metric is indeed not the best idea. However representing th= e server U-bit in a client domain admin color might be interesting. (sorry = for still using the old acronyms) Gert =20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of I= gor Bryskin Sent: Dienstag, 22. Januar 2013 17:42 To: Lou Berger Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Lou, Generally it is not a good idea to play with the TE metric.=20 It is up to client path computer (or client policy) to decide how important= the difference between a committed and uncommitted VL, and hence to defin= e the TE metric penalty. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Tuesday, January 22, 2013 11:21 AM To: Igor Bryskin Cc: Daniele Ceccarelli; CCAMP Subject: Re: [CCAMP] Overlay model framework v2 Igor, I was referring to you comment: IB>> It is beneficial from the client (ONT user) path computation point=20 IB>> of view to know whether the advertised VL is committed (the data=20 IB>> plane is provisioned) or not. So my point is that the U bit should be represented via an increased metric= (or some other existing parameter) as this is what path computation is goi= ng to do in effect in any case. Lou On 1/22/2013 11:09 AM, Igor Bryskin wrote: > Hi Lou, >=20 > You said: > And I'm suggesting that this be advertised using generic constructs such = as TE metric, SRLG, and even MELG, rather than adding yet another special c= ase computation/optimization parameter. >=20 > Agree, we are already doing this via MELG sub-TLV. This is because the su= b-TLV is new (no need to change the existing ones) and because MELG is pecu= liar to VL. >=20 > Igor. >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, January 22, 2013 10:51 AM > To: Igor Bryskin > Cc: Daniele Ceccarelli; CCAMP > Subject: Re: [CCAMP] Overlay model framework v2 >=20 > Igor, >=20 > see below. >=20 > On 1/22/2013 10:05 AM, Igor Bryskin wrote: >> Lou and Daniele, >> Please, see my comments in-line, >> >> Cheers, >> Igor >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> Behalf Of Lou Berger >> Sent: Monday, January 21, 2013 5:13 PM >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework v2 >> >> Thanks Daniele, See below. >> >> On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote: >>> Hi Lou, >>> >>> Please find comments in line >>> >>> BR >>> Daniele >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: venerd=EC 18 gennaio 2013 18.27 >>>> To: Daniele Ceccarelli >>>> Cc: CCAMP >>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>> >>>> Daniele, >>>> Very nice summary. Just catching up, so sorry for the >>>> (2 day) late response. >>>> >>>> I really like how the terminology has evolved and appreciate the=20 >>>> summary! >>>> >>>> I have a few detail comments, but before I go there I'd like to=20 >>>> cover one more open issue that I think will have some >>>> (minor) ripple effects on the details. >>>> >>>> I think there's still the general issue of terminology to use when=20 >>>> referring to the entity that "uses an overlay" and the entity that=20 >>>> "instantiates the overlay". In your mail and in discussion we have: >>>> >>>> - client (service)/OC/CN/customer >>>> >>>> and >>>> >>>> - server(or service)/OE/EN/provider >>>> >>>> I think we had discussed, and possibly agreed on, using VPN=20 >>>> terminology which would have us use the latter options, i.e., >>>> (overlay) customer/provider (edge). This would mean eliminating=20 >>>> any references to client/server in the *generic >>>> overlay* definitions. Of course these terms may reemerge in other=20 >>>> contexts as they have before, e.g., rfc6215. >>> >>> Yes, i think we all agreed. If there are still terms different from=20 >>> customer/provider in the text it's because i missed them during the=20 >>> replacing. >>> >> >> Great! Glad I didn't miss something over the holidays! >> >> IB>> I personally have no problems with the VPN terminology. However, >> IMO the terminology should be aligned with the RFC 4208 and George's=20 >> drafts. >=20 > My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped to= encompass the broad spectrum of overlays that are/have been discussed. >=20 >> One cannot use different terminology within the same framework, right? >=20 > Unfortunately we have no shortage of terminology defining (perhaps differ= ent flavors) of the same thing! >=20 >> Furthermore, both RFC4208 and ONTs are not necessarily about VPNs. >=20 > While I certainly agree that not all overlays need be VPNs, it seems to m= e that our discussions are best aligned with that set of terminology, and t= hat UNI/ENNI can be described within the CE/PE/VN/VL/VT constructs. > Perhaps with some tweaking in some cases. >=20 >=20 >> The most important goal is to provide a solution for inter-domain=20 >> horizontal integration between networks with possibly different=20 >> switching technologies and independent addressing within the overlay=20 >> model. >> >=20 > Sure. It's also possible that an overlay will use the same switching tec= hnology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably less l= ikely) the same address space (if a provider so chooses). >=20 >>>> >>>> I like this approach as it is aligned with the much of IETF work on=20 >>>> overlays (e.g., BGP L3/L2 VPNs) as well as the L1VPN (e.g. RFC 4847). >>>> Importantly, RFC 4847 even has quite a few concepts that can be=20 >>>> directly leveraged in this discussion. >>>> >>>> I'd even go further and say that we should base the definitions and=20 >>>> resulting framework on RFC 4847. For example, the definitions=20 >>>> below could start with something along the lines: >>>> >>>> The overlay service model, at a high level, follows Section >>>> 7. of RFC 4847 as represented by: >>>> >>>> >>>> +--------------------+ >>>> : | | : >>>> : | | : >>>> +----+ : +----+ +----+ : +----+ >>>> | CE |---:---| PE | | PE |---:---| CE | >>>> +----+ : +----+ +----+ : +----+ >>>> : | | : >>>> : | | : >>>> : +--------------------+ : >>>> : | | : >>>> : |<-Provider network->| : >>>> Customer Customer >>>> interface interface >>>> >>>> Figure 7.2: Overlay Service Model >>>> >>>> In this model, the overlay is instantiated by an overlay >>>> "provider" and its provider edge (PE) nodes , and is used by >>>> the overlay "customer" which is connected to the provider via >>>> customer interfaces attached to customer edge (CE) nodes. >>>> >>>> ... >>>> >>>> The definition below would need to be tweaked slightly, notably to=20 >>>> remove any references to client and server. The resulting=20 >>>> framework can also refer back to RFC 4847 as needed. >>>> >>>> See below for some additional comments. >>>> >>>> On 1/16/2013 10:33 AM, Daniele Ceccarelli wrote: >>>>> Dear overlayers, >>>>> >>>>> Please find below a new version (v2) of the framework summary=20 >>>>> reflecting the latest discussions. Again i hope i've >>>> captured all the >>>>> comments around, sorry if anything is missing, in case just let me=20 >>>>> know what i missed. >>>>> >>>>> BR >>>>> Daniele >>>>> >>>>> >>>>> + Disclaimer: >>>>> 1. Packet opto integration is often considered but the work can be=20 >>>>> extented to any type of SC. Eg. TDM over LSC. >>>>> >>>>> + Terminology: >>>>> 1. Virtual Link: A virtual link is a potential path between two=20 >>>>> virtual or real network elements in a provider layer network >>>> that is >>>>> maintained/controlled in and by the provider domain control >>>> plane (and >>>>> as such cannot transport any traffic/data and protected from being >>>>> de-provisioned) and which can be instantiated in the data plane=20 >>>>> (and then can carry/transport/forward traffic/data) preserving=20 >>>>> previously advertised attributes such as fate sharing information. >>>>> >>>> >>>> You say "potential path". I this this should read "potential or=20 >>>> instantiated path". >>>> >>> >>> Maybe we need to define also what "potential" stands for? At least=20 >>> two cases come to my mind (which might be included under the "potential= " >>> umbrella): >>> >>> 1. resources reserved via signaling but not instantiated >> >> Sure. Sounds like a RFC6001 soft FA. >> >>> 2. resources not even signaled. In presence of a centralized entity=20 >>> managing the network (sort of PCE plus something) there is no need=20 >>> to reserve resources via signaling as the central entity is the only=20 >>> thing that can reserve or allocate resources. I'm thinking to an=20 >>> opening towards the integration with the SDN world. >>> >> >> Sure. Sounds like a Virtual TE link (per RFC6001, 5212). >> > IB>> Potential path can be defined as a feasible/provisionable path=20 > IB>> for > the server layer trail supporting an advertised VL, which has attributes = consistent with the ones advertised for the Virtual Link (noticeably, bandw= idth, SRLGs, etc.) and is guaranteed to be available at the moment of the s= et-up of a client LSP that has selected the VL in its path across the provi= der domain. >> >>> Just loud thinking, does it make sense? >>> >>> >From my perspective, I think a node in the overlay really shouldn't >>>> *directly* distinguish between the two -- now one may have a=20 >>>> different metric/SRLG/weight/etc, but these are abstracted=20 >>>> representations of the tradeoffs between use of the two, that can=20 >>>> be provided by the underlying provider network, rather than a=20 >>>> direct indication. >> > IB>> It is beneficial from the client (ONT user) path computation=20 > IB>> point of view to know whether the advertised VL is committed (the=20 > IB>> data plane is provisioned) or not. Selecting uncommitted VL means: >> a) Higher probability of a client LSP setup failure; >> b) Longer client LSP setup time; >> c) Probability of effectively removing other VLs from the ONT (those=20 >> that share MELGs with the VL in question) >=20 > And I'm suggesting that this be advertised using generic constructs such = as TE metric, SRLG, and even MELG, rather than adding yet another special c= ase computation/optimization parameter. >=20 >> >>>> >>>>> 2. Virtual Node: Virtual node is a collection of zero or more=20 >>>>> provider network domain nodes that are collectively >>>> represented to the >>>>> clients as a single node that exists in the customer layer >>>> network and >>>>> is capable of terminating of access, inter-domain and virtual links. >>>>> >>>> >>>> I'm a little uncomfortable with the linkage of real nodes to=20 >>>> virtual nodes. I think VN is a purely abstract concept that may be=20 >>>> instantiated using parts/whole/multiple/logical/real/etc nodes. >>> >> >> IB>> Agree completely >> >>> Makes sense. What this definition adds to the one in RFC4847 is=20 >>> basically the fact that also parts of a node can be considered. What=20 >>> saying that it can be a real node i meant 1:1 correspondance between=20 >>> a real and a virtual node. Your definition covers that case also,=20 >>> that's fine. >>> >>>> >>>> How about something like: >>>> Virtual Node: A virtual node is a representation of a collection of=20 >>>> provider resources that are interconnected via virtual (and >>>> customer) links. A virtual node may be collection of zero or=20 >>>> more, including portions of, provider nodes that are collectively=20 >>>> represented to the customer as a single node which is available in an = overlay network. >>> >>> Works for me. >>> >> >> Great. BTW I don't think 4847 precluded a single physical node being re= presented as multiple virtual nodes, but it doesn't hurt to make it explici= t. >> >>>> >>>>> 3. Virtual Topology: Virtual topology is a collection of one or=20 >>>>> more virtual or real provider network domain nodes that exist in=20 >>>>> the customer layer network and are interconnected via 0 or more=20 >>>>> virtual links. >>>> >>>> How about: >>>> Virtual Topology: A virtual topology is the collection of virtual=20 >>>> links and nodes advertised by a provider to a customer. The virtual=20 >>>> topology includes resources that are advertised as reachable within=20 >>>> an overlay network. >>>> >>>> Do you mean to imply/allow for a VN which has no links? >>> >>> The case of "interconnected via 0 virtual links" implies the whole=20 >>> domain seen as a single node. >>> >> >> Ahh, fair enough. >> >>>> >>>>> 4. Overlay topology: is a superset of virtual topologies >>>> provided by >>>>> each of provider network domains, access and inter-domain links. >>>>> >>>> >>>> Doesn't it also include any topology information advertised by the=20 >>>> customer/CE as well? >> >> IB>> Yes, it does: the ends of access links terminated by the clients=20 >> IB>> along with the custom NEs IDs >> >=20 > sounds like some agreement here. >=20 > I think that was you final comment... >=20 > Lou >=20 >>> >>> Possibly. Do you mean advertised by the CE in the customer domain, righ= t? >>> >> >> That's possible too, but I was thinking more of advertised by CE >> (customer) to PE (provider). >> >>>> >>>>> 5. Access Link: Link between OC and OE. GMPLS runs on that link.=20 >>>>> It can support any of the SCs supported by the GMPLS. >>>>> >>>> >>>> If we adopt RFC 4847 terminology it should be "customer interface". >>>> Also, I suspect you mean PE and CE. >>> >>> Mmm, yes but what if we want to manage it as a link? i.e. All=20 >>> TE-parameters that a link supports. Is it enough to call it=20 >>> interface only? >>> >> >> sure. Per 4847, I'd say that "customer interface" is the connection bet= ween CE/PE while [virtual] TE links are what is advertised/represented in r= outing. >> >>>> >>>>> 6. CE (customer Edge): Something like the CN in RFC4208 >>>> teminology but >>>>> (i) receiving virtual topology from the provider network and=20 >>>>> requesting the set up of one of them or (ii) requesting the=20 >>>>> computation and establishment of a path accordingly to given=20 >>>>> constraints in the provider network and receiving the parameters=20 >>>>> characterizing such path. (ii) =3D=3D UNI. >>>>> >>>> >>>> humm, I'm inclined to stay away from UNI for the moment. I also=20 >>>> suggest that we look to 4874 and even 4364 rather than 4208... >>> >>> Ok, we can refer to those RFC for what concerns terminology, but at=20 >>> the end of the day we must put the UNI under this framework. In the=20 >>> new terminology the UNI is a particular type of customer interface. >>> >> >> Fair enough. But it is a form on an overlay "customer interface" not th= e definitive form. >> >>>> >>>>> 7. PE (provider Edge): Something like the EN in RFC4208 but able=20 >>>>> to deal with (i) and (ii) above. >>>>> >>>> >>>> same comment WRT RFCs. >>>> >>>>> 8. PE-CE interface (former ONI) : Interface allowing for >>>> signaling and >>>>> routing messages exchange between customer overlay and provider=20 >>>>> network. Routing information consists on virtual topology=20 >>>>> advertisement. When there is no routing adjacency across the >>>> interface >>>>> it is equivalent to the GMPLS UNI defined in 4208. >>>>> Signaling messages are compliant with RFC4208. Information >>>> related to >>>>> path carachteristics, e.g. TE-metrics, collected SRLG, path >>>> delay etc, >>>>> either passed from CE to PE via signaling after the LSP >>>> establishment >>>>> in the core network or from CE to PE to be used as path=20 >>>>> computation constraints, fall under the definition of signaling=20 >>>>> info and not routing info). >>>>> >>>> >>>> >>>>> 9. CE-CE (former O-NNI): Interface on the links between different=20 >>>>> provider networks in the overlay model environment. Same features=20 >>>>> of the CE-PE apply to this interface. >>>>> >>>> >>>> you mean, PE-PE, right? >>> >>> You're not the first one that makes me notice i'm probably affected=20 >>> by dyslexia :-) >>> >> >> no problem, happens to the best of us! >> >>>> >>>>> + Statements 1. In the context of overlay model we are aiming to >>>>> build an overlay topology for the customer network domains >>>>> >>>>> 2. The overlay topology is comprised of: >>>>> a) access links (links connecting client NEs to the >>>> provider network domains). >>>>> They can be PSC or LSC. >>>>> b) inter-domain links (links interconnecting server >>>> network domains) >>>>> c) virtual topology provided by the provider network domains.=20 >>>>> Virtual Links >>>>> + Virtual Nodes (TBD) + Connectivity Matrix (with a set of=20 >>>>> + parameters >>>>> e.g. SRLG, optical impairments, delay etc for each entry)=20 >>>>> describing connectivity between access links and virtual links. >>>>> >>>>> 3. In the context of overlay model we manage hierarchy of=20 >>>>> overlay topologies with overlay/underlay relationships >>>>> >>>>> 4. In the context of overlay model multi-layering and inter-layer=20 >>>>> relationships are peripheral at best, it is all about horizontal=20 >>>>> network integration >>>>> >>>>> 5. The overlay model assumes one CP instance for the >>>> customer network >>>>> and a separate instance for the provider network and in the CE-PE=20 >>>>> interface case the provider network also surreptitiously >>>> participates >>>>> in the customer network by injecting virtual topology >>>> information into >>>>> it. >>>>> >>>> >>>> We should ensure we're allowing for some of the existing/augmented=20 >>>> models that permit the transport of overlay information within the=20 >>>> provider's CP, e.g., rfc4364, 5195 and 5252. >>> >>> I'd say they should be already covered, but will double check >>> >> >> great. >> >>>> >>>>> 6. L1VPN (and LxVPN) in general is a type of service >>>> provided over the >>>>> CE-PE interface (it falls under the UNI case as no routing=20 >>>>> adjacency is in place between CE and PE). >>>>> >>>>> >>>>> + Advertisement models (to be detailed in dedicated >>>>> + document/documents) >>>>> The CE-PE interface in the overlay model context foresees >>>> two types of >>>>> advertisement models.(names still to be agreed) >>>>> >>>>> A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and >>>> augmented by >>>>> a number of actived draft (references to various drafts to >>>> be added).=20 >>>>> The Augmented UNI is a particular type of CE-PE interface where=20 >>>>> only signaling messages are exchanged between CE and PE. >>>>> Messages from CE to PE can include a set of parameters to be used=20 >>>>> by the PE as path computation constraints when computing a path in=20 >>>>> the provider domain network, while messages from PE to CE can=20 >>>>> include a set of parameters qualifying the LSP being established,=20 >>>>> like for example SRLG, delay, loss etc. >>>>> >>>> >>>> again, we can leverage 4874 terminology if we so choose, i.e.,=20 >>>> "basic mode" and "enhanced mode" UNI|NNI >>> >>> Don would be happy about that :-). I'd say yes. The goal was to=20 >>> cover the L1VPN work (enhanced mode), all the drafts-ali recently=20 >>> polled for wg adoption (basic mode?) and the actual ENNI (enhanced mode= ). >> >>> Is my mapping in brackets correct? >>> >> >> Not sure f I'd break it down they way you are. I'd say basic mode is cl= oser to the typical UNI and enhance mode is UNI+routing or perhaps even an = ENNI. >> >>> >>>> >>>>> B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply=20 >>>>> called with the general CE-PE interface term?) allowing the=20 >>>>> establishment of signaling and routing adjacency between CE and PE. >>>>> Routing info passed from PE to CE comprise overlay topology=20 >>>>> information including (but not limited to) virtual links, >>>> connectivity >>>>> matrices and access links with parameters qualifying each of them=20 >>>>> in terms of e.g. SRLG, loss, delay etc. Signaling information and=20 >>>>> procedures are compliant with RFC4208. >>>>> >>>> >>>> so this is just and 4874 "enhanced mode" interface, right. >>> >>> Good question: the enhanced mode supports signaling and routing, so=20 >>> i'd say yes, but reading section 7.3 it talks about "limited=20 >>> exchange of information between the control planes. >>> >>> "permits limited exchange of >>> information between the control planes of the provider and the >>> customer to help such functions as discovery of customer network >>> routing information (i.e., reachability or TE information in remote >>> customer sites), or parameters of the part of the provider's network >>> dedicated to the customer." >>> >>> Would you say this includes what we want? (i.e. Virtual links,=20 >>> virtual nodes, connectivity matrices, SRLG, delay, loss, etc) If yes=20 >>> we're done, otherwise an option could be the denition of a third VPN=20 >>> service model. >>> >> >> humm, need to think about this. Perhaps the best thing is to=20 >> document the two different cases and then decide if we have something=20 >> new or >> (two) more detailed forms of something old. >> >>>> >>>>> + Open issues/questions >>>>> 1. PCE-PCEP - do we need to include considerations about PCE >>>> and PCEP >>>>> into the overlay framework context? >>>>> >>>>> 2. BGP-LS needs to be considered >>>>> 3. Should potentials be included? E.g. I2RS? >>>>> 4. Virtual links: wouldn't a different definition of virtual links=20 >>>>> avoid the advertisement of connectivity matrices (this is out of=20 >>>>> the fwk scope but within the advertisement models one)? >>>>> >>>> >>>>> Take this example: >>>>> PE1-----CE1 CE2-----PE2 >>>>> CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 >>>>> CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 >>>> >>>> I think you've reversed CE and PE here... >>> >>> Yes, once again. >>> >>> No comment on my foolish proposal? >>> >> >> Which one? I liked your summary overall. >> >> Lou >> >>> >>>> >>>> Much thanks! >>>> >>>> Lou >>>> (hatless...) >>>> >>>>> i.e. There are 2 VL connecting CE1 and CE2 that could be >>>> available for >>>>> PE1 and PE2 to set up an adjacency in the customer domain.=20 >>>> CE1 and/or >>>>> CE2 can be blocking nodes so VL1 and/or VL2 are available only=20 >>>>> depending on the connectivity matrices of CE1 and CE2. Hence >>>> PEs need >>>>> to be aware of both VL and connectivity matrices. My point >>>> is: if CE1 >>>>> advertises to PE1 only the VL that his connectivity matrix allows=20 >>>>> to be connected to PE1 (e.g. VL1 only) and not all of them, it >>>> should be >>>>> possible to avoid the connectivity matrices advertisement. >>>>> >>>> >>>>> =20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> DANIELE CECCARELLI >>>>> System & Technology - PDU Optical & Metro >>>>> >>>>> Via E.Melen, 77 >>>>> Genova, Italy >>>>> Phone +390106002512 >>>>> Mobile +393346725750 >>>>> daniele.ceccarelli@ericsson.com >>>>> www.ericsson.com >>>>> >>>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> >=20 >=20 >=20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Wed Jan 23 08:42:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CFF21F84D9 for ; Wed, 23 Jan 2013 08:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 fogNP5um+UXW for ; Wed, 23 Jan 2013 08:42:51 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB4E21F84A1 for ; Wed, 23 Jan 2013 08:42:50 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0NGghog004732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jan 2013 17:42:43 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Wed, 23 Jan 2013 17:42:43 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Wed, 23 Jan 2013 11:42:41 -0500 From: Igor Bryskin To: Lou Berger Thread-Topic: Additional overlay protocol extensions? (Was: Re: [CCAMP] Overlay model framework v2) Thread-Index: AQHN+X1sS6yKTJql/0O4GWvFKiY/4JhXCk8g Date: Wed, 23 Jan 2013 16:42:40 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> In-Reply-To: <51000024.8010700@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-23_05:2013-01-23, 2013-01-23, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 16:42:52 -0000 TG91LA0KDQpSZXF1aXJlZCBwcm90b2NvbCBleHRlbnNpb25zIChqdXN0IHRvIHN0YXJ0IHdpdGgp Og0KMS4gTUVMR3MgK1ZMJ3MgY29tbWl0dGVkL3VuY29tbWl0dGVkIHN0YXR1cyBhZHZlcnRpc2lu Zw0KMi4gU2lnbmFsaW5nIGV4dGVuc2lvbnMgdG8gc2V0IGNvcnJlY3RseSBjbGllbnQgZGV2aWNl IFJTVlAgdGltZXJzIGFuZCB0byBjb21tdW5pY2F0ZSB0aGUgc3RhdGUgYW5kIHN0YXR1cyBvZiB1 bmRlcmx5aW5nIHNlcnZlciB0cmFpbCAoZS5nLiB0YWtpbmcgaW50byBhY2NvdW50IGRlbGF5cyBk dWUgdG8gdGhlIHNlcnZlciB0cmFpbCBzZXR1cCkuIElzc3VlIG9mIFJST3M6IGEgY2xpZW50IGRl dmljZSBzaWduYWxzIHRoZSBMU1AgcGF0aCBpbiB0ZXJtcyBvZiBWTHMvVk5zLCB3aGF0IGFib3V0 IFJST3M/Ow0KMy4gT05UICBPQU0gZXh0ZW5zaW9ucyBhbmQgcHJvY2VkdXJlcyAoaG93IHRvIGFz c29jaWF0ZSBEUCBhbGFybXMvZmFpbHVyZXMgaGFwcGVuZWQgb24gcmVhbCBsaW5rcyBhbmQgbm9k ZXMgd2l0aCBWTHMgYW5kIFZOcyB0aGF0IGRlcGVuZCBvbiB0aGVtLCBzbyB0aGF0IGNsaWVudCBM U1AgcmVzdG9yYXRpb24gY291bGQgYmUgY29udHJvbGxlZCBieSB0aGUgY2xpZW50Pyk7DQo0LiBW TiByZWxhdGVkIGV4dGVuc2lvbnMgKGRvIHdlIG5lZWQgdG8gYWR2ZXJ0aXNlIFRFIFJUUiBUTFYg b24gYmVoYWxmIG9mIGEgVk4sIHdoYXQgYXJlIHRoZSBwcm9jZWR1cmVzIGlmIHNldmVyYWwgcmVh bCBub2RlcyBjb25zdGl0dXRlIFZOLCB3aGF0IGlzIHRoZSBzaWduYWxpbmcgYWRkcmVzcyB0byB1 c2UgaWYgYSBWTiBpcyBzZWxlY3RlZCwgZXRjLik7DQo1LiBWTiBjb25uZWN0aXZpdHkgbWF0cml4 IGZvciBhZGRyZXNzaW5nIFZOJ3MgYmxvY2tpbmcvYXN5bW1ldHJpYyBuYXR1cmUsIGluY2x1ZGlu ZyB0aGUgZGV0YWlsZWQgY29ubmVjdGl2aXR5IG1hdHJpeCAoZW50cmllcyB3aXRoIGFzc29jaWF0 ZWQgY29zdHMsIHdoaWNoIHdpbGwgYWxzbyByZXF1aXJlIHNpZ25hbGluZyBleHRlbnNpb25zOiBl LmcuIGhvdyB0byBzcGVjaWZ5IGluIHRoZSBFUk8gdGhhdCBhIGdpdmVuIGNvbm5lY3Rpdml0eSBt YXRyaXggZW50cnkgaXMgc2VsZWN0ZWQ/KTsNCjYuIFJvdXRpbmcgZXh0ZW5zaW9ucyB0byBzZXBh cmF0ZSBWTidzIGludGVybmFscyBmcm9tIHRoZSBvdXRzaWRlIHdvcmxkOw0KNy4gQWNjZXNzL2lu dGVyLWRvbWFpbiBsaW5rcyBMTVAgZXh0ZW5zaW9uczsNCjguIFNwbGl0LVZOIHNwZWNpZmljIGV4 dGVuc2lvbnMgKCB3aGVuIGEgYmxvY2tpbmcgcmVhbCBub2RlIGlzIHByZXNlbnRlZCB2aWEgc2V2 ZXJhbCBzeW1tZXRyaWNhbCBWTnMsIHRoZSBWTiBJRHMgY291bGQgYmUgYXNzaWduZWQgYW5kIGNo YW5nZWQgIGF1dG9tYXRpY2FsbHkgKHRvIHJlbW92ZSBleHRyYSBjb25maWd1cmF0aW9uIGJ1cmRl biksIGhvdyB0aGUgY2xpZW50IE5FcyBsZWFybiB0aGF0IHRoZSByZW1vdGUgbm9kZSBJRCBvZiBh biBhY2Nlc3MgbGluayBpcyAocmUtKWFzc2lnbmVkPykNCjkuIFJvdXRpbmcgZXh0ZW5zaW9ucyB0 byBhZGRyZXNzIGluZGVwZW5kZW50IGFkZHJlc3Mgc3BhY2VzOw0KMTAuIFZQTiByZWxhdGVkIGV4 dGVuc2lvbnM6IGhvdyB0byBhZHZlcnRpc2UgVkwncyBhc3NvY2lhdGlvbiB3aXRoIG9uZSBvciBz ZXZlcmFsIFZQTnM/IEhvdyB0byBwcm92aWRlIFZQTi1zcGVjaWZpYyBWTidzIGNvbm5lY3Rpdml0 eSBtYXRyaXg7DQoxMS4gRXRjLg0KDQpBbGwgb2YgdGhlIGFib3ZlIG1lbnRpb25lZCB0aGluZ3Mg b2J2aW91c2x5IGNhbm5vdCBiZSBkb25lIHdpdGhvdXQgYSB3ZWxsLXVuZGVyc3Rvb2QgZnJhbWV3 b3JrIHdpdGgsIHllcywgdGlnaHRseSBkZWZpbmVkIGRlZmluaXRpb25zLg0KSGVuY2UgdGhlIGRl ZmluaXRpb25zIGlzIGEgdmVyeSBpbXBvcnRhbnQgc3RhcnQuDQoNCkNoZWVycywNCklnb3INCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVy Z2VyQGxhYm4ubmV0XSANClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMywgMjAxMyAxMDoyMiBB TQ0KVG86IElnb3IgQnJ5c2tpbg0KQ2M6IEpvaG4gRSBEcmFrZTsgQ0NBTVA7IFN0ZXdhcnQgQnJ5 YW50OyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyAnR2VvcmdlIFN3YWxsb3cgKHN3YWxsb3cpJw0KU3Vi amVjdDogQWRkaXRpb25hbCBvdmVybGF5IHByb3RvY29sIGV4dGVuc2lvbnM/IChXYXM6IFJlOiBb Q0NBTVBdIE92ZXJsYXkgbW9kZWwgZnJhbWV3b3JrIHYyKQ0KDQoNCg0KT24gMS8yMi8yMDEzIDE6 NTggUE0sIElnb3IgQnJ5c2tpbiB3cm90ZToNCj4uLi4NCj4gQmVzaWRlcywgSSBiZWxpZXZlIG5v dGhpbmcgKHRlcm1pbm9sb2d5LCBhcmNoaXRlY3R1cmUsICBwcm90b2NvbCAgDQo+c29sdXRpb25z LCBldGMuKSAgb2YgTUxOL01STiBpcyByZWxldmFudCB0byB3aGF0IHdlIGFyZS93ZXJlIHRyeWlu ZyAgdG8gDQo+YWNoaWV2ZSB3aXRoIE9OVHMuDQo+IA0KPiBJZ29yDQo+IC4uLg0KDQpJZ29yLA0K DQpDYW4gd2UgdGFrZSBhIHN0ZXAgYmFjayBmb3IgYSBtb21lbnQgZnJvbSB0aGUgKHNlZW1pbmds eSBlbmRsZXNzKSB0ZXJtaW5vbG9neS9hcmNoaXRlY3R1cmUvZnJhbWV3b3JrIGRlYmF0ZT8NCg0K V2hhdCBhZGRpdGlvbmFsIChpLmUuLCBub3QgYWxyZWFkeSBjb3ZlcmVkIGluIGEgc3RhbmRhbG9u ZSBkcmFmdCwgZS5nLiwNCmRyYWZ0LWFsaS0uLi4pICpwcm90b2NvbCBleHRlbnNpb25zKiBkbyB5 b3UgdGhpbmsgbmVlZCB0byBiZSBzdGFuZGFyZGl6ZWQgKGFzIFBTKT8NCg0KSXMgaXQgbW9yZSB0 aGFuIGp1c3QgTUVMRz8NCg0KTG91DQo= From Steve.Balls@metaswitch.com Wed Jan 23 09:37:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0642021F85EA for ; Wed, 23 Jan 2013 09:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv5k-PiKMEYl for ; Wed, 23 Jan 2013 09:37:05 -0800 (PST) Received: from SFPETS2.metaswitch.com (sfpets2.metaswitch.com [198.147.226.9]) by ietfa.amsl.com (Postfix) with ESMTP id 73CA321F854F for ; Wed, 23 Jan 2013 09:37:05 -0800 (PST) Received: from SFPCAS1.datcon.co.uk (172.24.4.3) by SFPETS2.metaswitch.com (172.24.4.12) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 23 Jan 2013 09:36:10 -0800 Received: from SFPMBX1.datcon.co.uk ([fe80::8471:982f:7fd5:35ef]) by SFPCAS1.datcon.co.uk ([fe80::1924:e6dd:b536:8f10%12]) with mapi id 14.02.0328.009; Wed, 23 Jan 2013 09:37:04 -0800 From: Steve Balls To: "ccamp@ietf.org" Thread-Topic: [CCAMP] FW: New Version Notification for draft-balls-ccamp-relax-loop-check-02.txt Thread-Index: AQHNx3PomofvY/1SAEib1f4nraNE3phDfQog Date: Wed, 23 Jan 2013 17:37:02 +0000 Deferred-Delivery: Wed, 23 Jan 2013 17:37:00 +0000 Message-ID: <1508F62A2F511042B45D315CFF74E229D880F27F@SFPMBX1.datcon.co.uk> References: <1508F62A2F511042B45D315CFF74E229D265B9E1@SFPMBX1.datcon.co.uk> In-Reply-To: <1508F62A2F511042B45D315CFF74E229D265B9E1@SFPMBX1.datcon.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.112.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] FW: New Version Notification for draft-balls-ccamp-relax-loop-check-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:37:06 -0000 Hi CCAMP, We would like to progress this draft, but need support from the list that i= t is valid. =20 To summarize, RSVP currently prevents an LSP from passing through the same = control plane node more than once. This draft relaxes the current strict R= SVP loop checking rules to allow an LSP "spiral" - one that passes through = a control plane node more than once, but is still following a different pat= h (input to output ). The draft presents several use cases where spiral paths provide important b= ehaviour. - WDM networks with restricted wavelength conversions - Networks where nodes have restricted connectivity - WDM networks where nodes have restricted wavelength switching capabiliti= es - Distributed networks where one control plane instance is controlling mul= tiple data plane nodes - Ingress protection. We therefore believe this draft addresses genuine problems which are not cu= rrently solved by standard RSVP. As such we would like to request the CCAM= P group consider this draft for WG adoption. Please let us know if you agr= ee. Thanks, Steve, Jon and Cyril. (Authors) -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of S= teve Balls Sent: 20 November 2012 15:06 To: ccamp@ietf.org Subject: [CCAMP] FW: New Version Notification for draft-balls-ccamp-relax-l= oop-check-02.txt Hi CCAMP, We have updated draft-balls-ccamp-relax-loop-check with some further exampl= es demonstrating why we believe an update to RSVP is required, and modified= the language to clarify the proposed solution does not introduce loops. We would like to discuss this on the list. Specifically, do you agree that= the use cases described in the draft are valid and that modifications to R= SVP are required to support them? Thanks, Steve, Jon and Cyril. (Authors) -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, November 19, 2012 10:02 AM To: Steve Balls Cc: Jonathan Hardwick; NSN - Cyril Margaria Subject: New Version Notification for draft-balls-ccamp-relax-loop-check-02= .txt A new version of I-D, draft-balls-ccamp-relax-loop-check-02.txt has been successfully submitted by Steve Balls and posted to the IETF repos= itory. Filename: draft-balls-ccamp-relax-loop-check Revision: 02 Title: Relaxing RSVP Loop Checking Creation date: 2012-11-19 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-balls-ccamp-rela= x-loop-check-02.txt Status: http://datatracker.ietf.org/doc/draft-balls-ccamp-relax-lo= op-check Htmlized: http://tools.ietf.org/html/draft-balls-ccamp-relax-loop-ch= eck-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-balls-ccamp-relax= -loop-check-02 Abstract: This specification relaxes the rules governing loop checking within RSVP. These were originally defined in RFC3209 and are too strict for the requirements of today's data planes. = =20 The IETF Secretariat _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Wed Jan 23 09:48:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE48221F8558 for ; Wed, 23 Jan 2013 09:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, 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 evAFIHpAAvsG for ; Wed, 23 Jan 2013 09:48:06 -0800 (PST) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 2651621F8550 for ; Wed, 23 Jan 2013 09:48:04 -0800 (PST) Received: (qmail 25075 invoked by uid 0); 23 Jan 2013 17:47:41 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 23 Jan 2013 17:47:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=EgDT90bKo017FMgqObrbWYi0bPmAaC3KKzIKYof8gbo=; b=bLdss516ZPBOSBvQjKZzh6IEHbLNgfQIc/jRMvbUXWgOsEl7mK7RjswX7lmaW9kUFp6UsfPRXjvePgpi+aGAcgdpTKYFJ4C4YGbGT2dMenBAlsWWC9UaQ85kv3warStM; Received: from pool-108-28-89-162.washdc.fios.verizon.net ([108.28.89.162]:36539 helo=[127.0.0.1]) by box313.bluehost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1Ty4QG-0005RL-P4; Wed, 23 Jan 2013 10:47:41 -0700 From: Lou Berger To: Igor Bryskin Date: Wed, 23 Jan 2013 12:47:39 -0500 Message-ID: <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <13c685c78c3.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.2.1.2 (build: 2100174) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 108.28.89.162 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:48:07 -0000 Igor, See below for responses in line. On January 23, 2013 11:42:40 AM Igor Bryskin wrote: > Lou, > > Required protocol extensions (just to start with): > 1. MELGs +VL's committed/uncommitted status advertising Understood, although you and I may not agree on some of the details, but that discussion can wait. > 2. Signaling extensions to set correctly client device RSVP timers and > to communicate the state and status of underlying server trail (e.g. > taking into account delays due to the server trail setup). Isn't this possible with any H-LSP), I.e. not unique to ONTs (or whatever you call it)? > Issue of RROs: a client device signals the LSP path in terms of > VLs/VNs, what about RROs?; How is this a new problem? The issue is present/covered in 4208. > 3. ONT OAM extensions and procedures (how to associate DP > alarms/failures happened on real links and nodes with VLs and VNs that > depend on them, so that client LSP restoration could be controlled by > the client?); This too seems like a generic problem, I.e., one present in H-LSPs, L1VPNs, and MLN. > 4. VN related extensions (do we need to advertise TE RTR TLV on behalf > of a VN, what are the procedures if several real nodes constitute VN, > what is the signaling address to use if a VN is selected, etc.); My understanding of existing RFCs (and discussion) is that virtual nodes/links are advertised just like real nodes/links. This sounds like an informational, or at most a BCP, document. > 5. VN connectivity matrix for addressing VN's blocking/asymmetric > nature, including the detailed connectivity matrix (entries with > associated costs, which will also require signaling extensions: e.g. > how to specify in the ERO that a given connectivity matrix entry is selected?); What as a VN connectivity matrix? Does it differ from the connectivity matrix already defined by this group? If yes, it sounds like an extension to the existing work. If no, sounds like another informational/BCP. > 6. Routing extensions to separate VN's internals from the outside world; Sounds like information exchanged between overlay edge nodes (PEs). Basically the information that would be needed to support L1VPN enhanced mode. > 7. Access/inter-domain links LMP extensions; Isn't this the same as is needed when using rfc5251 or 4208? > 8. Split-VN specific extensions ( when a blocking real node is > presented via several symmetrical VNs, the VN IDs could be assigned and > changed automatically (to remove extra configuration burden), how the > client NEs learn that the remote node ID of an access link is (re-)assigned?) This is a specific example of item 6 above, right? > 9. Routing extensions to address independent address spaces; Part of this is already covered by L1VPN basic mode, and the rest is also required by L1VPN enhanced mode. > 10. VPN related extensions: how to advertise VL's association with one > or several VPNs? How to provide VPN-specific VN's connectivity matrix; I think you already covered this above. > 11. Etc. > > All of the above mentioned things obviously cannot be done without a > well-understood framework with, yes, tightly defined definitions. > Hence the definitions is a very important start. > Wow that's a long list! It seems to me that a number/most of the items above, can be done as focused and incremental extensions to existing RFCs/WG products, in a generic way, without any further discussion/agreement on the high level overlay topic. Just like the other (soon to be) new WG documents. Certainly the informational/BCP documents would require good understanding of the target use cases. Given the clear, and seemingly circular, disagreements on basic terminology it might make most sense to spend some time documenting the different use cases/models before continuing the definitions discussion. Lou (as contributor) > Cheers, > Igor > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, January 23, 2013 10:22 AM > To: Igor Bryskin > Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George > Swallow (swallow)' > Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP] > Overlay model framework v2) > > > > On 1/22/2013 1:58 PM, Igor Bryskin wrote: > >... > > Besides, I believe nothing (terminology, architecture, protocol > >solutions, etc.) of MLN/MRN is relevant to what we are/were trying to > >achieve with ONTs. > > > > Igor > > ... > > Igor, > > Can we take a step back for a moment from the (seemingly endless) > terminology/architecture/framework debate? > > What additional (i.e., not already covered in a standalone draft, e.g., > draft-ali-...) *protocol extensions* do you think need to be > standardized (as PS)? > > Is it more than just MELG? > > Lou From lberger@labn.net Wed Jan 23 10:47:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE9921F8461 for ; Wed, 23 Jan 2013 10:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.673 X-Spam-Level: X-Spam-Status: No, score=-101.673 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 9X5qAmegcooN for ; Wed, 23 Jan 2013 10:47:42 -0800 (PST) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 537D621F8B60 for ; Wed, 23 Jan 2013 10:47:42 -0800 (PST) Received: (qmail 16662 invoked by uid 0); 23 Jan 2013 18:47:14 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 23 Jan 2013 18:47:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ObHxLjovwVPRdKqEgYbJ507r7a7IJymRoMNgsa6y5P0=; b=vVeA0wkxzVGTg9EH9bwwZ3gD0cUHh/5amMTZ3kRMU7YCEcVg0SdymIXFfQs6OYE2klYhfHo3EM5uGwjUJPoCD0qUWBa9cWGfzm0chjbH9ly2+ln6u9R+xeFl6FgHjg/X; Received: from box313.bluehost.com ([69.89.31.113]:42379 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ty5Lu-0005U3-20; Wed, 23 Jan 2013 11:47:14 -0700 Message-ID: <51003039.3040809@labn.net> Date: Wed, 23 Jan 2013 13:47:21 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Margaria, Cyril (NSN - DE/Munich)" , dirk.schroetter@nutsix.de, "Giovanni Martinelli (giomarti)" , Steve.Balls@metaswitch.com, Ben.Wright@metaswitch.com References: <50BE808B.8070808@labn.net> <50F43AE4.6090807@labn.net> In-Reply-To: <50F43AE4.6090807@labn.net> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Regarding IPR on draft-margaria-ccamp-lsp-attribute-ero-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 18:47:43 -0000 Authors, WG, It seems that Dirk is no longer active in our WG or on the draft. We'd like to propose the following in order to unblock progress on this draft: 1) That Dirk's name be removed from the Authors/Contributor's section 2) That Dirk's contribution to this draft to date be recognized in the Acknowledgments section 3) That these changes be made in draft-margaria-ccamp-lsp-attribute-ero-03 4) That draft-margaria-ccamp-lsp-attribute-ero-03 then be accepted as a WG document based the results of last month's poll (http://www.ietf.org/mail-archive/web/ccamp/current/msg14293.html) 5) That, baring any substantive objections, that the above take place on or after Jan 31. We can revisit 1 & 2 if Dirk responds to the IPR poll in future. Thoughts/comments? Lou (and Deborah) On 1/14/2013 12:05 PM, Lou Berger wrote: > Dirk, > Please respond so that we can move this draft forward. > > Thank you, > Lou > > PS CCAMP, if anyone knows how to contact Dirk please forward this > message to him, or let us know who to reach him. > > On 12/4/2012 6:00 PM, Lou Berger wrote: >> Authors, Contributors, (CCAMP) >> >> As part of the preparation for the poll on making this document a WG >> document: >> >> Are you aware of any IPR that applies to >> draft-margaria-ccamp-lsp-attribute-ero-02? >> >> Please state either: >> >> "No, I'm not aware of any IPR that applies to this draft" >> or >> "Yes, I'm aware of IPR that applies to this draft" >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details)? >> >> If yes to the above, please state either: >> >> "Yes, the IPR has been disclosed in compliance with IETF IPR rules" >> or >> "No, the IPR has not been disclosed" >> >> If you answer no, please provide any additional details you think >> appropriate. >> >> If you are listed as a document author or contributor please answer the >> above by responding to this email regardless of whether or not you are >> aware of any relevant IPR. This document will not advance to the next >> stage until a response has been received from each author and listed >> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS >> MESSAGE'S TO LINES. >> >> If you are on the CCAMP WG email list but are not listed as an author or >> contributor, we remind you of your obligations under the IETF IPR rules >> which encourages you to notify the IETF if you are aware of IPR of >> others on an IETF contribution, or to refrain from participating in any >> contribution or discussion related to your undisclosed IPR. For more >> information, please see the RFCs listed above and >> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >> >> Thank you, >> CCAMP WG Chairs >> >> PS Please include all listed in the headers of this message in your >> response. >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From SBardalai@infinera.com Wed Jan 23 11:03:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487C421F869F for ; Wed, 23 Jan 2013 11:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6] 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 fYKDCmrqQwvE for ; Wed, 23 Jan 2013 11:03:19 -0800 (PST) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7760121F85D4 for ; Wed, 23 Jan 2013 11:03:19 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 11:03:18 -0800 From: Snigdho Bardalai To: Lou Berger , Igor Bryskin Thread-Topic: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) Thread-Index: AQHN+ZHQb8QMYQmPakSWYQav74usa5hXQ+cg Date: Wed, 23 Jan 2013 19:03:17 +0000 Message-ID: <6386D6323049044BA592CB99AB04BACB3F9498AB@SV-EXDB-PROD1.infinera.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 19:03:20 -0000 There is one use-case I don't see being mentioned - signaling LSPs that are= diverse in the provider network and do not have common CE nodes as head-en= d or tail-end. I believe this will require some extensions, not sure what yet!! Regards Snigdho > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Wednesday, January 23, 2013 9:48 AM > To: Igor Bryskin > Cc: CCAMP > Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: > Overlay model framework v2) >=20 > Igor, >=20 > See below for responses in line. >=20 > On January 23, 2013 11:42:40 AM Igor Bryskin > wrote: > > Lou, > > > > Required protocol extensions (just to start with): > > 1. MELGs +VL's committed/uncommitted status advertising >=20 > Understood, although you and I may not agree on some of the details, > but that discussion can wait. >=20 > > 2. Signaling extensions to set correctly client device RSVP timers > and > > to communicate the state and status of underlying server trail (e.g. > > taking into account delays due to the server trail setup). >=20 > Isn't this possible with any H-LSP), I.e. not unique to ONTs (or > whatever you call it)? >=20 > > Issue of RROs: a client device signals the LSP path in terms of > > VLs/VNs, what about RROs?; >=20 > How is this a new problem? The issue is present/covered in 4208. >=20 > > 3. ONT OAM extensions and procedures (how to associate DP > > alarms/failures happened on real links and nodes with VLs and VNs > that > > depend on them, so that client LSP restoration could be controlled by > > the client?); >=20 > This too seems like a generic problem, I.e., one present in H-LSPs, > L1VPNs, and MLN. >=20 > > 4. VN related extensions (do we need to advertise TE RTR TLV on > behalf > > of a VN, what are the procedures if several real nodes constitute VN, > > what is the signaling address to use if a VN is selected, etc.); >=20 > My understanding of existing RFCs (and discussion) is that virtual > nodes/links are advertised just like real nodes/links. This sounds > like an informational, or at most a BCP, document. >=20 > > 5. VN connectivity matrix for addressing VN's blocking/asymmetric > > nature, including the detailed connectivity matrix (entries with > > associated costs, which will also require signaling extensions: e.g. > > how to specify in the ERO that a given connectivity matrix entry is > > selected?); >=20 > What as a VN connectivity matrix? Does it differ from the connectivity > matrix already defined by this group? >=20 > If yes, it sounds like an extension to the existing work. >=20 > If no, sounds like another informational/BCP. >=20 > > 6. Routing extensions to separate VN's internals from the outside > > world; >=20 > Sounds like information exchanged between overlay edge nodes (PEs). > Basically the information that would be needed to support L1VPN > enhanced mode. >=20 > > 7. Access/inter-domain links LMP extensions; >=20 > Isn't this the same as is needed when using rfc5251 or 4208? >=20 > > 8. Split-VN specific extensions ( when a blocking real node is > > presented via several symmetrical VNs, the VN IDs could be assigned > > and changed automatically (to remove extra configuration burden), > how > > the client NEs learn that the remote node ID of an access link is > > (re-)assigned?) >=20 > This is a specific example of item 6 above, right? >=20 > > 9. Routing extensions to address independent address spaces; >=20 > Part of this is already covered by L1VPN basic mode, and the rest is > also required by L1VPN enhanced mode. >=20 > > 10. VPN related extensions: how to advertise VL's association with > one > > or several VPNs? How to provide VPN-specific VN's connectivity > matrix; >=20 > I think you already covered this above. >=20 > > 11. Etc. > > > > All of the above mentioned things obviously cannot be done without a > > well-understood framework with, yes, tightly defined definitions. > > Hence the definitions is a very important start. > > >=20 > Wow that's a long list! >=20 > It seems to me that a number/most of the items above, can be done as > focused and incremental extensions to existing RFCs/WG products, in a > generic way, without any further discussion/agreement on the high level > overlay topic. Just like the other (soon to be) new WG documents. >=20 > Certainly the informational/BCP documents would require good > understanding of the target use cases. Given the clear, and seemingly > circular, disagreements on basic terminology it might make most sense > to spend some time documenting the different use cases/models before > continuing the definitions discussion. >=20 > Lou (as contributor) >=20 > > Cheers, > > Igor > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, January 23, 2013 10:22 AM > > To: Igor Bryskin > > Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George > > Swallow (swallow)' > > Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP] > > Overlay model framework v2) > > > > > > > > On 1/22/2013 1:58 PM, Igor Bryskin wrote: > > >... > > > Besides, I believe nothing (terminology, architecture, protocol > > >solutions, etc.) of MLN/MRN is relevant to what we are/were trying > > >to achieve with ONTs. > > > > > > Igor > > > ... > > > > Igor, > > > > Can we take a step back for a moment from the (seemingly endless) > > terminology/architecture/framework debate? > > > > What additional (i.e., not already covered in a standalone draft, > > e.g., > > draft-ali-...) *protocol extensions* do you think need to be > > standardized (as PS)? > > > > Is it more than just MELG? > > > > Lou >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Wed Jan 23 11:54:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799B521F876E for ; Wed, 23 Jan 2013 11:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6] 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 Y4pxCmkXs4sn for ; Wed, 23 Jan 2013 11:54:25 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 230D321F85D4 for ; Wed, 23 Jan 2013 11:54:24 -0800 (PST) Received: from MUC-SRV-MBX1.advaoptical.com ([172.20.1.95]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0NJsFHu030166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jan 2013 20:54:15 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 23 Jan 2013 20:54:15 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Wed, 23 Jan 2013 14:54:13 -0500 From: Igor Bryskin To: Lou Berger Thread-Topic: Additional overlay protocol extensions? (Was: Re: [CCAMP] Overlay model framework v2) Thread-Index: AQHN+X1sS6yKTJql/0O4GWvFKiY/4JhXCk8ggAAmN62AAA/8gA== Date: Wed, 23 Jan 2013 19:54:13 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-23_06:2013-01-23, 2013-01-23, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 19:54:26 -0000 Please, see in line. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, January 23, 2013 12:48 PM To: Igor Bryskin Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George Swall= ow (swallow)' Subject: RE: Additional overlay protocol extensions? (Was: Re: [CCAMP] Over= lay model framework v2) Igor, See below for responses in line. On January 23, 2013 11:42:40 AM Igor Bryskin wro= te: > Lou, > > Required protocol extensions (just to start with): > 1. MELGs +VL's committed/uncommitted status advertising Understood, although you and I may not agree on some of the details, but th= at discussion can wait. IB>>Ok > 2. Signaling extensions to set correctly client device RSVP timers and=20 > to communicate the state and status of underlying server trail (e.g. > taking into account delays due to the server trail setup). Isn't this possible with any H-LSP), I.e. not unique to ONTs (or whatever y= ou call it)? IB>> Is this covered? Where? We (ADVA, JNPR) had an issue with that and cou= ld not find the answer. > Issue of RROs: a client device signals the LSP path in terms of=20 > VLs/VNs, what about RROs?; How is this a new problem? The issue is present/covered in 4208. IB>> 4208 does not have a notion of VL or VN, so it cannot possibly cover i= t. When ERO is signaled in terms of VLs, how does RRO returned to the clien= t should look like: virtual links? real links? both? encrypted with some ke= y? > 3. ONT OAM extensions and procedures (how to associate DP=20 > alarms/failures happened on real links and nodes with VLs and VNs that=20 > depend on them, so that client LSP restoration could be controlled by=20 > the client?); This too seems like a generic problem, I.e., one present in H-LSPs, L1VPNs,= and MLN. IB>> Where is exactly described how the faults are associated with VLs and = VNs? When, say, a fault happens inside a VN, how exactly outside world know= s about that to perform an alternative path computation? Please, provide a = quote. > 4. VN related extensions (do we need to advertise TE RTR TLV on behalf=20 > of a VN, what are the procedures if several real nodes constitute VN,=20 > what is the signaling address to use if a VN is selected, etc.); My understanding of existing RFCs (and discussion) is that virtual nodes/li= nks are advertised just like real nodes/links. This sounds like an informa= tional, or at most a BCP, document. IB>> Disagree. If a VN is comprised of two real nodes handled by separate O= SPF speakers, which of them (or both) generate TE RTR TLV on behalf of VN? = My solution, for example, is to deprecate completely TE RTR TLV, because it= is redundant. In any case, if you know where the issue is covered, please,= provide the quote. > 5. VN connectivity matrix for addressing VN's blocking/asymmetric=20 > nature, including the detailed connectivity matrix (entries with=20 > associated costs, which will also require signaling extensions: e.g. > how to specify in the ERO that a given connectivity matrix entry is=20 > selected?); What as a VN connectivity matrix? Does it differ from the connectivity matr= ix already defined by this group? IB>> Yes, it does: the detailed VN connectivity matrix should include a set= of costs (in terms of SRLGs, delay, TE matric, etc.) for cross-connecting = two interfaces, similar to what Giovanni suggests for OI (optical impairmen= ts) vector. The consequence is that there could be more than one entry for = the same pair of interfaces, with a consequence of the necessity of signali= ng extensions. Also, which of the speakers should advertise the connectivit= y matrix? I have the solution for that which is quite different from the wa= y it is " already defined by this group" If yes, it sounds like an extension to the existing work. If no, sounds like another informational/BCP. > 6. Routing extensions to separate VN's internals from the outside=20 > world; Sounds like information exchanged between overlay edge nodes (PEs). =20 Basically the information that would be needed to support L1VPN enhanced m= ode. IB>> The point of VN as a powerful scalability tool is to present a network= to the outside of the world as a single node (i.e. to hide internals) whil= e still exposing in some way an IP connectivity to each of the internal nod= es for the management purposes. Considering that VNs can encompass domains = made of VNs, I see this as a big challenge with big benefits if solved. If= you know where this issue is covered, please, provide a quote. > 7. Access/inter-domain links LMP extensions; Isn't this the same as is needed when using rfc5251 or 4208? IB>> Access/inter-domain links can be terminated by VNs, so, no, this is no= t covered > 8. Split-VN specific extensions ( when a blocking real node is=20 > presented via several symmetrical VNs, the VN IDs could be assigned=20 > and changed automatically (to remove extra configuration burden), how=20 > the client NEs learn that the remote node ID of an access link is=20 > (re-)assigned?) This is a specific example of item 6 above, right? IB>> No. Normally VN requires quite a bit of manual configuration. This is = the case when this could be fully automated. > 9. Routing extensions to address independent address spaces; Part of this is already covered by L1VPN basic mode, and the rest is also r= equired by L1VPN enhanced mode. IB>> I am talking about routing extensions for virtual topology which is no= t part of L1VPN basic mode. If this covered for L1VPN enhanced mode, please, provide the quote as to h= ow this could be handled using OSPF. > 10. VPN related extensions: how to advertise VL's association with one=20 > or several VPNs? How to provide VPN-specific VN's connectivity matrix; I think you already covered this above. IB>> No, I didn't. I don't know yet how to advertise association of a VL wi= th one or multiple VPNs, nor how to advertise VPN specific connectivity mat= rices, nor how to filter the information from the users of different VPNs > 11. Etc. > > All of the above mentioned things obviously cannot be done without a=20 > well-understood framework with, yes, tightly defined definitions. > Hence the definitions is a very important start. > Wow that's a long list! It seems to me that a number/most of the items above, can be done as focus= ed and incremental extensions to existing RFCs/WG products, in a generic w= ay, without any further discussion/agreement on the high level overlay topi= c. Just like the other (soon to be) new WG documents. Certainly the informational/BCP documents would require good understanding = of the target use cases. Given the clear, and seemingly circular, disagree= ments on basic terminology it might make most sense to spend some time docu= menting the different use cases/models before continuing the definitions di= scussion. IB>> Lou, as you see I disagreed with pretty much everything you said. The = way I see it, one huge reason why we keep going in circles is you and your = desire to make it look like CCAMP work has a continuity of developing new t= hings based on existing RFCs. I am not against continuity when it calls for= . This work was not started because CCAMP WG has initiated it. Let me remin= d you that the work has started because we (ADVA and JNPR) have a product t= hat as we believe could be developed into a wider framework. It was always = meant to be built up as a continuation of RFC4208. I personally have full r= espect for this work as well as for what George is doing to enhance it. Wha= t I have problem with is some CCAMP dead stuff such as MLN/MRN and your con= tra-productive attempts to make it look bigger than it is actually worth of= . I also couldn't help but notice that the discussions proceed quite well u= ntil you wake up with your comments, so could you wake up a bit less freque= ntly?:=3D) Igor (as contributor) Lou (as contributor) > Cheers, > Igor > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, January 23, 2013 10:22 AM > To: Igor Bryskin > Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George=20 > Swallow (swallow)' > Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP]=20 > Overlay model framework v2) > > > > On 1/22/2013 1:58 PM, Igor Bryskin wrote: > >... > > Besides, I believe nothing (terminology, architecture, protocol=20 > >solutions, etc.) of MLN/MRN is relevant to what we are/were trying =20 > >to achieve with ONTs. > > > > Igor > > ... > > Igor, > > Can we take a step back for a moment from the (seemingly endless)=20 > terminology/architecture/framework debate? > > What additional (i.e., not already covered in a standalone draft,=20 > e.g., > draft-ali-...) *protocol extensions* do you think need to be=20 > standardized (as PS)? > > Is it more than just MELG? > > Lou From swallow@cisco.com Wed Jan 23 12:51:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2143821F87FF for ; Wed, 23 Jan 2013 12:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 8EZjiTHOOddR for ; Wed, 23 Jan 2013 12:51:37 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2515721F8800 for ; Wed, 23 Jan 2013 12:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2702; q=dns/txt; s=iport; t=1358974297; x=1360183897; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=23H5eqvepDAkdgavEjmYbrpP1ZIu5zRi76KJm2UjxUo=; b=BKA494rYlXlGmPhLjNj/3PPbiU5JLB2v5DV1l1iWVovXTqbkWQCaJ0yM WM6D+RdceeQMQzIky0xlkOVq0TDacOLDcvtL05Mui9KO8zd3xeZg3i0AC VL9hw+bnGpzvNvFTPspbFkkpfGuxoC8HOzagn2lipb4+H2kk5sp7TBaJL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMFMAFGtJV2Y/2dsb2JhbABEvjoWc4IeAQEBAwE6OgUFBwQCAQgRBAEBCxQJBzIUCQgBAQQOBQiIDAYMvXeMcAuDV2EDlyiPLYJ1gW81 X-IronPort-AV: E=Sophos;i="4.84,523,1355097600"; d="scan'208";a="164027637" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 23 Jan 2013 20:51:36 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0NKpZnZ002348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jan 2013 20:51:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 14:51:34 -0600 From: "George Swallow (swallow)" To: "Zafar Ali (zali)" Thread-Topic: Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 Thread-Index: Ac3a3hHWdN58nFnYuka2piGzhB9Mzwe/6ciA Date: Wed, 23 Jan 2013 20:51:33 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0F709E4A@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.32.174] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Clarence Filsfils \(cfilsfil\)" , CCAMP , "Ori Gerstel \(ogerstel\)" , Rudiger Kunze Subject: Re: [CCAMP] Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 20:51:45 -0000 I'm aware of no IPR except as cited by Zafar below. George On Dec 15, 2012, at 11:06 AM, Zafar Ali (zali) wrote: > Hi Lou, et al-=20 >=20 > Yes, I'm aware of IPR that applies to this draft. > Yes, the IPR has been disclosed in compliance with IETF IPR rules . Pleas= e see https://datatracker.ietf.org/ipr/1943/=20 >=20 > Thanks >=20 > Regards...Zafar >=20 >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, December 04, 2012 6:01 PM >> To: Zafar Ali (zali); George Swallow (swallow); Clarence Filsfils (cfils= fil); Matt Hartley (mhartley); >> Ori Gerstel (ogerstel); Gabriele Maria Galimberti (ggalimbe); Kenji Kuma= ki; Rudiger Kunze; Julien >> Meuric >> Cc: CCAMP >> Subject: Regarding IPR on draft-ali-ccamp-xro-lsp-subobject-02 >>=20 >> Authors, Contributors, (CCAMP) >>=20 >> As part of the preparation for the poll on making this document a WG >> document: >>=20 >> Are you aware of any IPR that applies to draft-ali-ccamp-xro-lsp-subobje= ct-02? >>=20 >> Please state either: >>=20 >> "No, I'm not aware of any IPR that applies to this draft" >> or >> "Yes, I'm aware of IPR that applies to this draft" >>=20 >> If so, has this IPR been disclosed in compliance with IETF IPR rules (se= e RFCs 3979, 4879, >> 3669 and 5378 for more details)? >>=20 >> If yes to the above, please state either: >>=20 >> "Yes, the IPR has been disclosed in compliance with IETF IPR rules" >> or >> "No, the IPR has not been disclosed" >>=20 >> If you answer no, please provide any additional details you think >> appropriate. >>=20 >> If you are listed as a document author or contributor please answer the = above by responding to >> this email regardless of whether or not you are aware of any relevant IP= R. This document will not >> advance to the next stage until a response has been received from each a= uthor and listed >> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S = TO >> LINES. >>=20 >> If you are on the CCAMP WG email list but are not listed as an author or= contributor, we remind >> you of your obligations under the IETF IPR rules which encourages you to= notify the IETF if you >> are aware of IPR of others on an IETF contribution, or to refrain from p= articipating in any >> contribution or discussion related to your undisclosed IPR. For more in= formation, please see the >> RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/In= tellectualProperty. >>=20 >> Thank you, >> CCAMP WG Chairs >>=20 >> PS Please include all listed in the headers of this message in your resp= onse. >=20 From lberger@labn.net Wed Jan 23 14:25:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB0C21F8769 for ; Wed, 23 Jan 2013 14:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.127 X-Spam-Level: X-Spam-Status: No, score=-101.127 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 VpdKB3Bom4hE for ; Wed, 23 Jan 2013 14:25:14 -0800 (PST) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 2D38321F871F for ; Wed, 23 Jan 2013 14:25:09 -0800 (PST) Received: (qmail 26684 invoked by uid 0); 23 Jan 2013 22:24:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 23 Jan 2013 22:24:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=5uFCzkC6DW94UqWC0KH4aY26GrtCg+3Atbsh2/1B2GY=; b=j0X7hgHhL7vreUGb0WDcUvqJFPdnOS13RWWRZYijO+CRX/BEdmlUBVqh/hSiL9aUTYVYlmxigOTDWYBEySmehYGctmmlBazpRfbSOCwNB56oyk2u9EnM3Xzq7AEJLJJ+; Received: from box313.bluehost.com ([69.89.31.113]:47926 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ty8kP-00043J-KL; Wed, 23 Jan 2013 15:24:45 -0700 Message-ID: <51006334.30106@labn.net> Date: Wed, 23 Jan 2013 17:24:52 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Igor Bryskin References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 22:25:15 -0000 It seems I failed to make my perspective clear to you in my previous mail. While this may or may not be the case, I believe your mail has moved outside acceptable IETF conduct. Lou On 1/23/2013 2:54 PM, Igor Bryskin wrote: > Please, see in line. > Igor > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, January 23, 2013 12:48 PM > To: Igor Bryskin > Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George Swallow (swallow)' > Subject: RE: Additional overlay protocol extensions? (Was: Re: [CCAMP] Overlay model framework v2) > > Igor, > > See below for responses in line. > > On January 23, 2013 11:42:40 AM Igor Bryskin wrote: >> Lou, >> >> Required protocol extensions (just to start with): >> 1. MELGs +VL's committed/uncommitted status advertising > > Understood, although you and I may not agree on some of the details, but that discussion can wait. > IB>>Ok > >> 2. Signaling extensions to set correctly client device RSVP timers and >> to communicate the state and status of underlying server trail (e.g. >> taking into account delays due to the server trail setup). > > Isn't this possible with any H-LSP), I.e. not unique to ONTs (or whatever you call it)? > IB>> Is this covered? Where? We (ADVA, JNPR) had an issue with that and could not find the answer. > > >> Issue of RROs: a client device signals the LSP path in terms of >> VLs/VNs, what about RROs?; > > How is this a new problem? The issue is present/covered in 4208. > IB>> 4208 does not have a notion of VL or VN, so it cannot possibly cover it. When ERO is signaled in terms of VLs, how does RRO returned to the client should look like: virtual links? real links? both? encrypted with some key? > >> 3. ONT OAM extensions and procedures (how to associate DP >> alarms/failures happened on real links and nodes with VLs and VNs that >> depend on them, so that client LSP restoration could be controlled by >> the client?); > > This too seems like a generic problem, I.e., one present in H-LSPs, L1VPNs, and MLN. > IB>> Where is exactly described how the faults are associated with VLs and VNs? When, say, a fault happens inside a VN, how exactly outside world knows about that to perform an alternative path computation? Please, provide a quote. > >> 4. VN related extensions (do we need to advertise TE RTR TLV on behalf >> of a VN, what are the procedures if several real nodes constitute VN, >> what is the signaling address to use if a VN is selected, etc.); > > My understanding of existing RFCs (and discussion) is that virtual nodes/links are advertised just like real nodes/links. This sounds like an informational, or at most a BCP, document. > > IB>> Disagree. If a VN is comprised of two real nodes handled by separate OSPF speakers, which of them (or both) generate TE RTR TLV on behalf of VN? My solution, for example, is to deprecate completely TE RTR TLV, because it is redundant. In any case, if you know where the issue is covered, please, provide the quote. > >> 5. VN connectivity matrix for addressing VN's blocking/asymmetric >> nature, including the detailed connectivity matrix (entries with >> associated costs, which will also require signaling extensions: e.g. >> how to specify in the ERO that a given connectivity matrix entry is >> selected?); > > What as a VN connectivity matrix? Does it differ from the connectivity matrix already defined by this group? > IB>> Yes, it does: the detailed VN connectivity matrix should include a set of costs (in terms of SRLGs, delay, TE matric, etc.) for cross-connecting two interfaces, similar to what Giovanni suggests for OI (optical impairments) vector. The consequence is that there could be more than one entry for the same pair of interfaces, with a consequence of the necessity of signaling extensions. Also, which of the speakers should advertise the connectivity matrix? I have the solution for that which is quite different from the way it is " already defined by this group" > > If yes, it sounds like an extension to the existing work. > > If no, sounds like another informational/BCP. > >> 6. Routing extensions to separate VN's internals from the outside >> world; > > Sounds like information exchanged between overlay edge nodes (PEs). > Basically the information that would be needed to support L1VPN enhanced mode. > IB>> The point of VN as a powerful scalability tool is to present a network to the outside of the world as a single node (i.e. to hide internals) while still exposing in some way an IP connectivity to each of the internal nodes for the management purposes. Considering that VNs can encompass domains made of VNs, I see this as a big challenge with big benefits if solved. If you know where this issue is covered, please, provide a quote. > >> 7. Access/inter-domain links LMP extensions; > > Isn't this the same as is needed when using rfc5251 or 4208? > IB>> Access/inter-domain links can be terminated by VNs, so, no, this is not covered > >> 8. Split-VN specific extensions ( when a blocking real node is >> presented via several symmetrical VNs, the VN IDs could be assigned >> and changed automatically (to remove extra configuration burden), how >> the client NEs learn that the remote node ID of an access link is >> (re-)assigned?) > > This is a specific example of item 6 above, right? > IB>> No. Normally VN requires quite a bit of manual configuration. This is the case when this could be fully automated. > >> 9. Routing extensions to address independent address spaces; > > Part of this is already covered by L1VPN basic mode, and the rest is also required by L1VPN enhanced mode. > IB>> I am talking about routing extensions for virtual topology which is not part of L1VPN basic mode. > If this covered for L1VPN enhanced mode, please, provide the quote as to how this could be handled using OSPF. > >> 10. VPN related extensions: how to advertise VL's association with one >> or several VPNs? How to provide VPN-specific VN's connectivity matrix; > > I think you already covered this above. > IB>> No, I didn't. I don't know yet how to advertise association of a VL with one or multiple VPNs, nor how to advertise VPN specific connectivity matrices, nor how to filter the information from the users of different VPNs > >> 11. Etc. >> >> All of the above mentioned things obviously cannot be done without a >> well-understood framework with, yes, tightly defined definitions. >> Hence the definitions is a very important start. >> > > Wow that's a long list! > > It seems to me that a number/most of the items above, can be done as focused and incremental extensions to existing RFCs/WG products, in a generic way, without any further discussion/agreement on the high level overlay topic. Just like the other (soon to be) new WG documents. > > Certainly the informational/BCP documents would require good understanding of the target use cases. Given the clear, and seemingly circular, disagreements on basic terminology it might make most sense to spend some time documenting the different use cases/models before continuing the definitions discussion. > > IB>> Lou, as you see I disagreed with pretty much everything you said. The way I see it, one huge reason why we keep going in circles is you and your desire to make it look like CCAMP work has a continuity of developing new things based on existing RFCs. I am not against continuity when it calls for. This work was not started because CCAMP WG has initiated it. Let me remind you that the work has started because we (ADVA and JNPR) have a product that as we believe could be developed into a wider framework. It was always meant to be built up as a continuation of RFC4208. I personally have full respect for this work as well as for what George is doing to enhance it. What I have problem with is some CCAMP dead stuff such as MLN/MRN and your contra-productive attempts to make it look bigger than it is actually worth of. I also couldn't help but notice that the discussions proceed quite well until you wake up with your comments, so could you wake up a bit less frequently?:=) > > Igor (as contributor) > > Lou (as contributor) > >> Cheers, >> Igor >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, January 23, 2013 10:22 AM >> To: Igor Bryskin >> Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George >> Swallow (swallow)' >> Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP] >> Overlay model framework v2) >> >> >> >> On 1/22/2013 1:58 PM, Igor Bryskin wrote: >>> ... >>> Besides, I believe nothing (terminology, architecture, protocol >>> solutions, etc.) of MLN/MRN is relevant to what we are/were trying >>> to achieve with ONTs. >>> >>> Igor >>> ... >> >> Igor, >> >> Can we take a step back for a moment from the (seemingly endless) >> terminology/architecture/framework debate? >> >> What additional (i.e., not already covered in a standalone draft, >> e.g., >> draft-ali-...) *protocol extensions* do you think need to be >> standardized (as PS)? >> >> Is it more than just MELG? >> >> Lou > > > > > > From db3546@att.com Wed Jan 23 14:42:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C1F21F84F8 for ; Wed, 23 Jan 2013 14:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, 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 iAaphqAhNRZz for ; Wed, 23 Jan 2013 14:42:27 -0800 (PST) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id DCAE021F84CC for ; Wed, 23 Jan 2013 14:42:26 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 25760015.2aaacfc05940.1517446.00-593.4250225.nbfkord-smmo04.seg.att.com (envelope-from ); Wed, 23 Jan 2013 22:42:26 +0000 (UTC) X-MXL-Hash: 510067524510941c-9565054d241f0ba2e2d0b5651f6199f1612ca81d Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f4760015.0.1517414.00-463.4250122.nbfkord-smmo04.seg.att.com (envelope-from ); Wed, 23 Jan 2013 22:42:25 +0000 (UTC) X-MXL-Hash: 510067515a84a86d-1ee8d3225a1f91205425f148e7e9c0759fb030d3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0NMgMAV022135; Wed, 23 Jan 2013 17:42:23 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0NMgGTX022127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2013 17:42:17 -0500 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint01.pst.cso.att.com (RSA Interceptor); Wed, 23 Jan 2013 17:42:02 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0328.009; Wed, 23 Jan 2013 17:42:02 -0500 From: "BRUNGARD, DEBORAH A" To: Lou Berger , Igor Bryskin Thread-Topic: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) Thread-Index: AQHN+aN/JZn1TfD1IEuchRXtbKNUMphX0XcA//+uMOA= Date: Wed, 23 Jan 2013 22:42:02 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51006334.30106@labn.net> In-Reply-To: <51006334.30106@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=WMjIqAQR c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=QlfpTN8ik9gA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=qrvc8Cqe2PkA:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8] X-AnalysisOut: [ a=AEDFM0qtAAAA:8 a=pmb6BNNbAAAA:8 a=XG6A7RLgtF64Vp7-sCEA:] X-AnalysisOut: [9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=33rK67OTR_gA:10 a=] X-AnalysisOut: [jqlaW5bC1iAA:10 a=7N0VDwPMIj8A:10 a=EeglPmxw6as-RPJm:21 a=] X-AnalysisOut: [v1OWqoa-Oo4LfEVo:21] Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 22:42:28 -0000 Agree - please keep the discussion technically focused and avoid any person= al comments. Deborah (with CCAMP Co-Chair hat on) -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Wednesday, January 23, 2013 5:25 PM To: Igor Bryskin Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Over= lay model framework v2) It seems I failed to make my perspective clear to you in my previous mail. While this may or may not be the case, I believe your mail has moved outside acceptable IETF conduct. Lou On 1/23/2013 2:54 PM, Igor Bryskin wrote: > Please, see in line. > Igor >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Wednesday, January 23, 2013 12:48 PM > To: Igor Bryskin > Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George Swa= llow (swallow)' > Subject: RE: Additional overlay protocol extensions? (Was: Re: [CCAMP] Ov= erlay model framework v2) >=20 > Igor, >=20 > See below for responses in line. >=20 > On January 23, 2013 11:42:40 AM Igor Bryskin w= rote: >> Lou, >> >> Required protocol extensions (just to start with): >> 1. MELGs +VL's committed/uncommitted status advertising >=20 > Understood, although you and I may not agree on some of the details, but = that discussion can wait. > IB>>Ok >=20 >> 2. Signaling extensions to set correctly client device RSVP timers and=20 >> to communicate the state and status of underlying server trail (e.g. >> taking into account delays due to the server trail setup). >=20 > Isn't this possible with any H-LSP), I.e. not unique to ONTs (or whatever= you call it)? > IB>> Is this covered? Where? We (ADVA, JNPR) had an issue with that and c= ould not find the answer. >=20 >=20 >> Issue of RROs: a client device signals the LSP path in terms of=20 >> VLs/VNs, what about RROs?; >=20 > How is this a new problem? The issue is present/covered in 4208. > IB>> 4208 does not have a notion of VL or VN, so it cannot possibly cover= it. When ERO is signaled in terms of VLs, how does RRO returned to the cli= ent should look like: virtual links? real links? both? encrypted with some = key? >=20 >> 3. ONT OAM extensions and procedures (how to associate DP=20 >> alarms/failures happened on real links and nodes with VLs and VNs that=20 >> depend on them, so that client LSP restoration could be controlled by=20 >> the client?); >=20 > This too seems like a generic problem, I.e., one present in H-LSPs, L1VPN= s, and MLN. > IB>> Where is exactly described how the faults are associated with VLs an= d VNs? When, say, a fault happens inside a VN, how exactly outside world kn= ows about that to perform an alternative path computation? Please, provide = a quote. >=20 >> 4. VN related extensions (do we need to advertise TE RTR TLV on behalf=20 >> of a VN, what are the procedures if several real nodes constitute VN,=20 >> what is the signaling address to use if a VN is selected, etc.); >=20 > My understanding of existing RFCs (and discussion) is that virtual nodes/= links are advertised just like real nodes/links. This sounds like an infor= mational, or at most a BCP, document. >=20 > IB>> Disagree. If a VN is comprised of two real nodes handled by separate= OSPF speakers, which of them (or both) generate TE RTR TLV on behalf of VN= ? My solution, for example, is to deprecate completely TE RTR TLV, because = it is redundant. In any case, if you know where the issue is covered, pleas= e, provide the quote. >=20 >> 5. VN connectivity matrix for addressing VN's blocking/asymmetric=20 >> nature, including the detailed connectivity matrix (entries with=20 >> associated costs, which will also require signaling extensions: e.g. >> how to specify in the ERO that a given connectivity matrix entry is=20 >> selected?); >=20 > What as a VN connectivity matrix? Does it differ from the connectivity ma= trix already defined by this group? > IB>> Yes, it does: the detailed VN connectivity matrix should include a s= et of costs (in terms of SRLGs, delay, TE matric, etc.) for cross-connectin= g two interfaces, similar to what Giovanni suggests for OI (optical impairm= ents) vector. The consequence is that there could be more than one entry fo= r the same pair of interfaces, with a consequence of the necessity of signa= ling extensions. Also, which of the speakers should advertise the connectiv= ity matrix? I have the solution for that which is quite different from the = way it is " already defined by this group" >=20 > If yes, it sounds like an extension to the existing work. >=20 > If no, sounds like another informational/BCP. >=20 >> 6. Routing extensions to separate VN's internals from the outside=20 >> world; >=20 > Sounds like information exchanged between overlay edge nodes (PEs). =20 > Basically the information that would be needed to support L1VPN enhanced= mode. > IB>> The point of VN as a powerful scalability tool is to present a netwo= rk to the outside of the world as a single node (i.e. to hide internals) wh= ile still exposing in some way an IP connectivity to each of the internal n= odes for the management purposes. Considering that VNs can encompass domain= s made of VNs, I see this as a big challenge with big benefits if solved. = If you know where this issue is covered, please, provide a quote. >=20 >> 7. Access/inter-domain links LMP extensions; >=20 > Isn't this the same as is needed when using rfc5251 or 4208? > IB>> Access/inter-domain links can be terminated by VNs, so, no, this is = not covered >=20 >> 8. Split-VN specific extensions ( when a blocking real node is=20 >> presented via several symmetrical VNs, the VN IDs could be assigned=20 >> and changed automatically (to remove extra configuration burden), how=20 >> the client NEs learn that the remote node ID of an access link is=20 >> (re-)assigned?) >=20 > This is a specific example of item 6 above, right? > IB>> No. Normally VN requires quite a bit of manual configuration. This i= s the case when this could be fully automated. >=20 >> 9. Routing extensions to address independent address spaces; >=20 > Part of this is already covered by L1VPN basic mode, and the rest is also= required by L1VPN enhanced mode. > IB>> I am talking about routing extensions for virtual topology which is = not part of L1VPN basic mode. > If this covered for L1VPN enhanced mode, please, provide the quote as to= how this could be handled using OSPF. >=20 >> 10. VPN related extensions: how to advertise VL's association with one=20 >> or several VPNs? How to provide VPN-specific VN's connectivity matrix; >=20 > I think you already covered this above. > IB>> No, I didn't. I don't know yet how to advertise association of a VL = with one or multiple VPNs, nor how to advertise VPN specific connectivity m= atrices, nor how to filter the information from the users of different VPNs >=20 >> 11. Etc. >> >> All of the above mentioned things obviously cannot be done without a=20 >> well-understood framework with, yes, tightly defined definitions. >> Hence the definitions is a very important start. >> >=20 > Wow that's a long list! >=20 > It seems to me that a number/most of the items above, can be done as foc= used and incremental extensions to existing RFCs/WG products, in a generic= way, without any further discussion/agreement on the high level overlay to= pic. Just like the other (soon to be) new WG documents. >=20 > Certainly the informational/BCP documents would require good understandin= g of the target use cases. Given the clear, and seemingly circular, disagr= eements on basic terminology it might make most sense to spend some time do= cumenting the different use cases/models before continuing the definitions = discussion. >=20 > IB>> Lou, as you see I disagreed with pretty much everything you said. Th= e way I see it, one huge reason why we keep going in circles is you and you= r desire to make it look like CCAMP work has a continuity of developing new= things based on existing RFCs. I am not against continuity when it calls f= or. This work was not started because CCAMP WG has initiated it. Let me rem= ind you that the work has started because we (ADVA and JNPR) have a product= that as we believe could be developed into a wider framework. It was alway= s meant to be built up as a continuation of RFC4208. I personally have full= respect for this work as well as for what George is doing to enhance it. W= hat I have problem with is some CCAMP dead stuff such as MLN/MRN and your c= ontra-productive attempts to make it look bigger than it is actually worth = of. I also couldn't help but notice that the discussions proceed quite well= until you wake up with your comments, so could you wake up a bit less freq= uently?:=3D) >=20 > Igor (as contributor) >=20 > Lou (as contributor) >=20 >> Cheers, >> Igor >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, January 23, 2013 10:22 AM >> To: Igor Bryskin >> Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George=20 >> Swallow (swallow)' >> Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP]=20 >> Overlay model framework v2) >> >> >> >> On 1/22/2013 1:58 PM, Igor Bryskin wrote: >>> ... >>> Besides, I believe nothing (terminology, architecture, protocol=20 >>> solutions, etc.) of MLN/MRN is relevant to what we are/were trying =20 >>> to achieve with ONTs. >>> >>> Igor >>> ... >> >> Igor, >> >> Can we take a step back for a moment from the (seemingly endless)=20 >> terminology/architecture/framework debate? >> >> What additional (i.e., not already covered in a standalone draft,=20 >> e.g., >> draft-ali-...) *protocol extensions* do you think need to be=20 >> standardized (as PS)? >> >> Is it more than just MELG? >> >> Lou >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Wed Jan 23 14:55:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C5321F8828 for ; Wed, 23 Jan 2013 14:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6] 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 sbGfLF2++m+0 for ; Wed, 23 Jan 2013 14:55:11 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB8C21F8786 for ; Wed, 23 Jan 2013 14:55:10 -0800 (PST) Received: from MUC-SRV-MBX1.advaoptical.com ([172.20.1.95]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0NMt3XS028316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jan 2013 23:55:03 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.516.32; Wed, 23 Jan 2013 23:55:02 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Wed, 23 Jan 2013 17:55:00 -0500 From: Igor Bryskin To: Lou Berger Thread-Topic: Additional overlay protocol extensions? (Was: Re: [CCAMP] Overlay model framework v2) Thread-Index: AQHN+X1sS6yKTJql/0O4GWvFKiY/4JhXCk8ggAAmN62AAA/8gIAAkUEA//+uGQA= Date: Wed, 23 Jan 2013 22:55:00 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51006334.30106@labn.net> In-Reply-To: <51006334.30106@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-23_07:2013-01-23, 2013-01-23, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 22:55:12 -0000 Lou, What in your opinion would be an acceptable way to say that you have not ta= ken time to understand what a group of people within CCAMP WG is trying to = accomplish and because of that has wasted 1 year of people's time by guidin= g the discussion in circles from UNI to ENNI to MLN/MRN to L1VPN to L3VPN = to MLN/MRN again ? Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, January 23, 2013 5:25 PM To: Igor Bryskin Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George Swall= ow (swallow)' Subject: Re: Additional overlay protocol extensions? (Was: Re: [CCAMP] Over= lay model framework v2) It seems I failed to make my perspective clear to you in my previous mail. = While this may or may not be the case, I believe your mail has moved outsid= e acceptable IETF conduct. Lou On 1/23/2013 2:54 PM, Igor Bryskin wrote: > Please, see in line. > Igor >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, January 23, 2013 12:48 PM > To: Igor Bryskin > Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George Swa= llow (swallow)' > Subject: RE: Additional overlay protocol extensions? (Was: Re: [CCAMP]=20 > Overlay model framework v2) >=20 > Igor, >=20 > See below for responses in line. >=20 > On January 23, 2013 11:42:40 AM Igor Bryskin w= rote: >> Lou, >> >> Required protocol extensions (just to start with): >> 1. MELGs +VL's committed/uncommitted status advertising >=20 > Understood, although you and I may not agree on some of the details, but = that discussion can wait. > IB>>Ok >=20 >> 2. Signaling extensions to set correctly client device RSVP timers=20 >> and to communicate the state and status of underlying server trail (e.g. >> taking into account delays due to the server trail setup). >=20 > Isn't this possible with any H-LSP), I.e. not unique to ONTs (or whatever= you call it)? > IB>> Is this covered? Where? We (ADVA, JNPR) had an issue with that and c= ould not find the answer. >=20 >=20 >> Issue of RROs: a client device signals the LSP path in terms of=20 >> VLs/VNs, what about RROs?; >=20 > How is this a new problem? The issue is present/covered in 4208. > IB>> 4208 does not have a notion of VL or VN, so it cannot possibly cover= it. When ERO is signaled in terms of VLs, how does RRO returned to the cli= ent should look like: virtual links? real links? both? encrypted with some = key? >=20 >> 3. ONT OAM extensions and procedures (how to associate DP=20 >> alarms/failures happened on real links and nodes with VLs and VNs=20 >> that depend on them, so that client LSP restoration could be=20 >> controlled by the client?); >=20 > This too seems like a generic problem, I.e., one present in H-LSPs, L1VPN= s, and MLN. > IB>> Where is exactly described how the faults are associated with VLs an= d VNs? When, say, a fault happens inside a VN, how exactly outside world kn= ows about that to perform an alternative path computation? Please, provide = a quote. >=20 >> 4. VN related extensions (do we need to advertise TE RTR TLV on=20 >> behalf of a VN, what are the procedures if several real nodes=20 >> constitute VN, what is the signaling address to use if a VN is=20 >> selected, etc.); >=20 > My understanding of existing RFCs (and discussion) is that virtual nodes/= links are advertised just like real nodes/links. This sounds like an infor= mational, or at most a BCP, document. >=20 > IB>> Disagree. If a VN is comprised of two real nodes handled by separate= OSPF speakers, which of them (or both) generate TE RTR TLV on behalf of VN= ? My solution, for example, is to deprecate completely TE RTR TLV, because = it is redundant. In any case, if you know where the issue is covered, pleas= e, provide the quote. >=20 >> 5. VN connectivity matrix for addressing VN's blocking/asymmetric=20 >> nature, including the detailed connectivity matrix (entries with=20 >> associated costs, which will also require signaling extensions: e.g. >> how to specify in the ERO that a given connectivity matrix entry is=20 >> selected?); >=20 > What as a VN connectivity matrix? Does it differ from the connectivity ma= trix already defined by this group? > IB>> Yes, it does: the detailed VN connectivity matrix should include a s= et of costs (in terms of SRLGs, delay, TE matric, etc.) for cross-connectin= g two interfaces, similar to what Giovanni suggests for OI (optical impairm= ents) vector. The consequence is that there could be more than one entry fo= r the same pair of interfaces, with a consequence of the necessity of signa= ling extensions. Also, which of the speakers should advertise the connectiv= ity matrix? I have the solution for that which is quite different from the = way it is " already defined by this group" >=20 > If yes, it sounds like an extension to the existing work. >=20 > If no, sounds like another informational/BCP. >=20 >> 6. Routing extensions to separate VN's internals from the outside=20 >> world; >=20 > Sounds like information exchanged between overlay edge nodes (PEs). =20 > Basically the information that would be needed to support L1VPN enhanced= mode. > IB>> The point of VN as a powerful scalability tool is to present a netwo= rk to the outside of the world as a single node (i.e. to hide internals) wh= ile still exposing in some way an IP connectivity to each of the internal n= odes for the management purposes. Considering that VNs can encompass domain= s made of VNs, I see this as a big challenge with big benefits if solved. = If you know where this issue is covered, please, provide a quote. >=20 >> 7. Access/inter-domain links LMP extensions; >=20 > Isn't this the same as is needed when using rfc5251 or 4208? > IB>> Access/inter-domain links can be terminated by VNs, so, no, this=20 > IB>> is not covered >=20 >> 8. Split-VN specific extensions ( when a blocking real node is=20 >> presented via several symmetrical VNs, the VN IDs could be assigned=20 >> and changed automatically (to remove extra configuration burden),=20 >> how the client NEs learn that the remote node ID of an access link is >> (re-)assigned?) >=20 > This is a specific example of item 6 above, right? > IB>> No. Normally VN requires quite a bit of manual configuration. This i= s the case when this could be fully automated. >=20 >> 9. Routing extensions to address independent address spaces; >=20 > Part of this is already covered by L1VPN basic mode, and the rest is also= required by L1VPN enhanced mode. > IB>> I am talking about routing extensions for virtual topology which is = not part of L1VPN basic mode. > If this covered for L1VPN enhanced mode, please, provide the quote as to= how this could be handled using OSPF. >=20 >> 10. VPN related extensions: how to advertise VL's association with=20 >> one or several VPNs? How to provide VPN-specific VN's connectivity=20 >> matrix; >=20 > I think you already covered this above. > IB>> No, I didn't. I don't know yet how to advertise association of a=20 > IB>> VL with one or multiple VPNs, nor how to advertise VPN specific=20 > IB>> connectivity matrices, nor how to filter the information from the=20 > IB>> users of different VPNs >=20 >> 11. Etc. >> >> All of the above mentioned things obviously cannot be done without a=20 >> well-understood framework with, yes, tightly defined definitions. >> Hence the definitions is a very important start. >> >=20 > Wow that's a long list! >=20 > It seems to me that a number/most of the items above, can be done as foc= used and incremental extensions to existing RFCs/WG products, in a generic= way, without any further discussion/agreement on the high level overlay to= pic. Just like the other (soon to be) new WG documents. >=20 > Certainly the informational/BCP documents would require good understandin= g of the target use cases. Given the clear, and seemingly circular, disagr= eements on basic terminology it might make most sense to spend some time do= cumenting the different use cases/models before continuing the definitions = discussion. >=20 > IB>> Lou, as you see I disagreed with pretty much everything you said.=20 > IB>> The way I see it, one huge reason why we keep going in circles is=20 > IB>> you and your desire to make it look like CCAMP work has a=20 > IB>> continuity of developing new things based on existing RFCs. I am=20 > IB>> not against continuity when it calls for. This work was not=20 > IB>> started because CCAMP WG has initiated it. Let me remind you that=20 > IB>> the work has started because we (ADVA and JNPR) have a product=20 > IB>> that as we believe could be developed into a wider framework. It=20 > IB>> was always meant to be built up as a continuation of RFC4208. I=20 > IB>> personally have full respect for this work as well as for what=20 > IB>> George is doing to enhance it. What I have problem with is some=20 > IB>> CCAMP dead stuff such as MLN/MRN and your contra-productive=20 > IB>> attempts to make it look bigger than it is actually worth of. I=20 > IB>> also couldn't help but notice that the discussions proceed quite=20 > IB>> well until you wake up with your comments, so could you wake up a=20 > IB>> bit less frequently?:=3D) >=20 > Igor (as contributor) >=20 > Lou (as contributor) >=20 >> Cheers, >> Igor >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, January 23, 2013 10:22 AM >> To: Igor Bryskin >> Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George=20 >> Swallow (swallow)' >> Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP]=20 >> Overlay model framework v2) >> >> >> >> On 1/22/2013 1:58 PM, Igor Bryskin wrote: >>> ... >>> Besides, I believe nothing (terminology, architecture, protocol=20 >>> solutions, etc.) of MLN/MRN is relevant to what we are/were trying=20 >>> to achieve with ONTs. >>> >>> Igor >>> ... >> >> Igor, >> >> Can we take a step back for a moment from the (seemingly endless)=20 >> terminology/architecture/framework debate? >> >> What additional (i.e., not already covered in a standalone draft,=20 >> e.g., >> draft-ali-...) *protocol extensions* do you think need to be=20 >> standardized (as PS)? >> >> Is it more than just MELG? >> >> Lou >=20 >=20 >=20 >=20 >=20 >=20 From Ben.Wright@metaswitch.com Thu Jan 24 01:51:37 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E421F855D for ; Thu, 24 Jan 2013 01:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPIpvwzl2C9M for ; Thu, 24 Jan 2013 01:51:36 -0800 (PST) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7B74721F867A for ; Thu, 24 Jan 2013 01:51:35 -0800 (PST) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 24 Jan 2013 09:51:10 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%19]) with mapi id 14.02.0328.009; Thu, 24 Jan 2013 09:51:33 +0000 From: Ben Wright To: labn - Lou Berger , NSN - Cyril Margaria , "dirk.schroetter@nutsix.de" , Cisco - Giovanni Martinelli , Steve Balls Thread-Topic: [CCAMP] Regarding IPR on draft-margaria-ccamp-lsp-attribute-ero-02 Thread-Index: AQHN0nMqWUC/tgvCJUqLXPkc5McwsJhJTdwAgA5BZICAAPwwQA== Date: Thu, 24 Jan 2013 09:51:33 +0000 Message-ID: References: <50BE808B.8070808@labn.net> <50F43AE4.6090807@labn.net> <51003039.3040809@labn.net> In-Reply-To: <51003039.3040809@labn.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.72.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Regarding IPR on draft-margaria-ccamp-lsp-attribute-ero-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:51:37 -0000 Hi Lou,=20 Yes - that works for me. It would be good to progress this draft. =20 Ben -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: 23 January 2013 18:47 To: NSN - Cyril Margaria; dirk.schroetter@nutsix.de; Cisco - Giovanni Marti= nelli; Steve Balls; Ben Wright Cc: CCAMP Subject: Re: [CCAMP] Regarding IPR on draft-margaria-ccamp-lsp-attribute-er= o-02 Authors, WG, It seems that Dirk is no longer active in our WG or on the draft. We'd lik= e to propose the following in order to unblock progress on this draft: 1) That Dirk's name be removed from the Authors/Contributor's section 2) That Dirk's contribution to this draft to date be recognized in the Acknowledgments section 3) That these changes be made in draft-margaria-ccamp-lsp-attribute-ero-03 4) That draft-margaria-ccamp-lsp-attribute-ero-03 then be accepted as a WG document based the results of last month's poll (http://www.ietf.org/mail-archive/web/ccamp/current/msg14293.html) 5) That, baring any substantive objections, that the above take place on or after Jan 31. We can revisit 1 & 2 if Dirk responds to the IPR poll in future. Thoughts/comments? Lou (and Deborah) On 1/14/2013 12:05 PM, Lou Berger wrote: > Dirk, > Please respond so that we can move this draft forward. >=20 > Thank you, > Lou >=20 > PS CCAMP, if anyone knows how to contact Dirk please forward this=20 > message to him, or let us know who to reach him. >=20 > On 12/4/2012 6:00 PM, Lou Berger wrote: >> Authors, Contributors, (CCAMP) >> >> As part of the preparation for the poll on making this document a WG >> document: >> >> Are you aware of any IPR that applies to=20 >> draft-margaria-ccamp-lsp-attribute-ero-02? >> >> Please state either: >> >> "No, I'm not aware of any IPR that applies to this draft" >> or >> "Yes, I'm aware of IPR that applies to this draft" >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules=20 >> (see RFCs 3979, 4879, 3669 and 5378 for more details)? >> >> If yes to the above, please state either: >> >> "Yes, the IPR has been disclosed in compliance with IETF IPR rules" >> or >> "No, the IPR has not been disclosed" >> >> If you answer no, please provide any additional details you think >> appropriate. >> >> If you are listed as a document author or contributor please answer=20 >> the above by responding to this email regardless of whether or not=20 >> you are aware of any relevant IPR. This document will not advance to=20 >> the next stage until a response has been received from each author=20 >> and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN=20 >> THIS MESSAGE'S TO LINES. >> >> If you are on the CCAMP WG email list but are not listed as an author=20 >> or contributor, we remind you of your obligations under the IETF IPR=20 >> rules which encourages you to notify the IETF if you are aware of IPR=20 >> of others on an IETF contribution, or to refrain from participating=20 >> in any contribution or discussion related to your undisclosed IPR. =20 >> For more information, please see the RFCs listed above and=20 >> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >> >> Thank you, >> CCAMP WG Chairs >> >> PS Please include all listed in the headers of this message in your=20 >> response. >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 >=20 From swallow@cisco.com Thu Jan 24 08:57:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760E721F8443 for ; Thu, 24 Jan 2013 08:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 sgL1z4gwsdE8 for ; Thu, 24 Jan 2013 08:57:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CF72E21F89A4 for ; Thu, 24 Jan 2013 08:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1937; q=dns/txt; s=iport; t=1359046644; x=1360256244; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=QEWQFIO3GwHQzVgVmTOlPJlyQ7Jcux6QlTKIG9BnXZw=; b=KuVokn/B2wP+Y+BUuoOQnNQuogjD2Toyig82jG2OEYaPbVcGa97L6AsM hKjR4K067zr3oXjREJfdIx30eZNGrUKbURnKk82/qb4pNinrVVUl+xN1p igCwi6ywHl3ujUKD8hhrxMW4wXzikKBKauINgWVGPLuNo3tHG59TpvBst E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAElnAVGtJXHA/2dsb2JhbABEvkgWc4IgAQQ6OhcBCA4UFEIlAgQBEgiIEgy+Fo0DgxdhA5cojyyCeIFvNQ X-IronPort-AV: E=Sophos;i="4.84,530,1355097600"; d="scan'208";a="167576843" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jan 2013 16:57:23 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0OGvNFs029476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 16:57:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 10:57:23 -0600 From: "George Swallow (swallow)" To: Lou Berger , "Zafar Ali (zali)" , "Matt Hartley (mhartley)" , CCAMP , "BRUNGARD, DEBORAH A (ATTLABS)" Thread-Topic: Regarding IPR on draft-ali-ccamp-te-metric-recording-03 Thread-Index: AQHN0nMtTPkEIaqu9k29NU54fIuEA5hZE5sA Date: Thu, 24 Jan 2013 16:57:22 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0F70CA2B@xmb-rcd-x10.cisco.com> In-Reply-To: <50BE8093.7090800@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.98.32.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <9BD33E0A87EA394B99D4366042DDF7B8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Regarding IPR on draft-ali-ccamp-te-metric-recording-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:57:25 -0000 Lou, Deborah, Yes, I'm aware of IPR that applies to this draft. No, the IPR is still being documented. George On 12/4/12 6:00 PM, "Lou Berger" wrote: >Authors, Contributors, (CCAMP) > >As part of the preparation for the poll on making this document a WG >document: > >Are you aware of any IPR that applies to >draft-ali-ccamp-te-metric-recording-03? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > >If you are listed as a document author or contributor please answer the >above by responding to this email regardless of whether or not you are >aware of any relevant IPR. This document will not advance to the next >stage until a response has been received from each author and listed >contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS >MESSAGE'S TO LINES. > >If you are on the CCAMP WG email list but are not listed as an author or >contributor, we remind you of your obligations under the IETF IPR rules >which encourages you to notify the IETF if you are aware of IPR of >others on an IETF contribution, or to refrain from participating in any >contribution or discussion related to your undisclosed IPR. For more >information, please see the RFCs listed above and >http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > >Thank you, >CCAMP WG Chairs > >PS Please include all listed in the headers of this message in your >response. > From db3546@att.com Thu Jan 24 10:28:46 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4614121F868E for ; Thu, 24 Jan 2013 10:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 bo5f+KHp5nih for ; Thu, 24 Jan 2013 10:28:45 -0800 (PST) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 1A10621F8596 for ; Thu, 24 Jan 2013 10:28:45 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id c5d71015.0.433256.00-176.1215712.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 24 Jan 2013 18:28:45 +0000 (UTC) X-MXL-Hash: 51017d5d2f7ae97c-173ea66096dd99738277c8855ed61acda94313f6 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OISggx028423 for ; Thu, 24 Jan 2013 10:28:44 -0800 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OISZx8028303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jan 2013 10:28:40 -0800 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by fflint04.pst.cso.att.com (RSA Interceptor) for ; Thu, 24 Jan 2013 10:28:30 -0800 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0328.009; Thu, 24 Jan 2013 13:28:30 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-te-metric-recording-03 Thread-Index: AQHN8oVm6+dSKWjafU2NEr/lRp3lkZhYsBUAgAAoTrCAAAN7YA== Date: Thu, 24 Jan 2013 18:28:30 +0000 Message-ID: References: <50BE8093.7090800@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=A73bydqG c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=dBC_91PBIbYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=ayvALioMZqQA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=yhhXeKMGUOdnFLW8KwwA:9 a=wPNLvfGTeEIA:10 a=2TSDkfqdCjIA] X-AnalysisOut: [:10 a=p3EP0m9KMXkA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 ] X-AnalysisOut: [a=pxhGCsheKAaN_1Ub:21 a=iqzQd-7jM7VGDoNp:21] Subject: [CCAMP] FW: FW: Regarding IPR on draft-ali-ccamp-te-metric-recording-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:28:46 -0000 -----Original Message----- From: RKunze@telekom.de [mailto:RKunze@telekom.de]=20 Sent: Thursday, January 24, 2013 1:16 PM To: BRUNGARD, DEBORAH A; swallow@cisco.com Subject: AW: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-te-metric-recordi= ng-03 Hi Deborah, Sorry for answering so late. "No, I'm not aware of any IPR that applies to this draft" Br, R=FCdiger -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Monday, January 14, 2013 1:31 PM To: George Swallow (swallow@cisco.com); 'ruediger.kunze@telekom.de' (ruedig= er.kunze@telekom.de) Cc: ccamp@ietf.org Subject: [CCAMP] FW: Regarding IPR on draft-ali-ccamp-te-metric-recording-0= 3 *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Authors, Can you please respond on IPR for this draft so we can start the poll? Thanks, Deborah -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Tuesday, December 04, 2012 6:01 PM To: Zafar Ali (zali); George Swallow (swallow); cfilsfil@cisco.com; mhartle= y@cisco.com; Kenji Kumaki; Rudiger Kunze; CCAMP Subject: [CCAMP] Regarding IPR on draft-ali-ccamp-te-metric-recording-03 Authors, Contributors, (CCAMP) As part of the preparation for the poll on making this document a WG document: Are you aware of any IPR that applies to draft-ali-ccamp-te-metric-recording-03? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Thu Jan 24 10:41:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D59311E8097 for ; Thu, 24 Jan 2013 10:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.289 X-Spam-Level: X-Spam-Status: No, score=-101.289 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, 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 clOhwDBt3Igy for ; Thu, 24 Jan 2013 10:41:18 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id BA61821F8650 for ; Thu, 24 Jan 2013 10:41:18 -0800 (PST) Received: (qmail 18439 invoked by uid 0); 24 Jan 2013 18:40:53 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 24 Jan 2013 18:40:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=h7b3mskRLa8Af/OA3Me5iSk07NN236vxRZXlO3cejZk=; b=Lbw+rKSuMFmzWqLj7vYaNRz3dWlq9fxtam1hIiyaXlUL+TBszJYztYiP/JWPbS8qCb8tTYFQLEHKOMh7EPY9sNaCOoSSgnvQJocP6Dlh9jTHOrZyCkoF9yXoXaUX3hAA; Received: from box313.bluehost.com ([69.89.31.113]:51508 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TyRjI-0005aG-Nb; Thu, 24 Jan 2013 11:40:53 -0700 Message-ID: <5101803A.4000308@labn.net> Date: Thu, 24 Jan 2013 13:40:58 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Igor Bryskin References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51006334.30106@labn.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:41:20 -0000 Igor, Frustration that one's proposal isn't immediately adopted as rough consensus, or that progress takes longer than the contributor thinks, is understandable. Expressing such frustration is certainly within one's prevue. Whatever you feel personally, making public statements on *any* individuals (perceived or otherwise) faults and any other form of ad hominem attack is outside of acceptable IETF conduct. Period. It is the chair's role to encourage open discussion and consensus. Being chair also does not remove the chair's ability to participate as an individual technical contributor. This includes my ability to express my technical or WG-related views which I have done and, when doing so, I have indicated "as contributor". If you have objections to my execution of the CCAMP WG Co-chair position, the right next step is to discuss your concerns with the other CCAMP chair or our AD. Lou On 1/23/2013 5:55 PM, Igor Bryskin wrote: > Lou, > > What in your opinion would be an acceptable way to say that you have > not taken time to understand what a group of people within CCAMP WG > is trying to accomplish and because of that has wasted 1 year of > people's time by guiding the discussion in circles from UNI to ENNI > to MLN/MRN to L1VPN to L3VPN to MLN/MRN again ? > > Igor > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, January 23, 2013 5:25 PM > To: Igor Bryskin > Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George Swallow (swallow)' > Subject: Re: Additional overlay protocol extensions? (Was: Re: [CCAMP] Overlay model framework v2) > > > It seems I failed to make my perspective clear to you in my previous > mail. While this may or may not be the case, I believe your mail has > moved outside acceptable IETF conduct. > > Lou > > On 1/23/2013 2:54 PM, Igor Bryskin wrote: >> Please, see in line. >> Igor >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, January 23, 2013 12:48 PM >> To: Igor Bryskin >> Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George Swallow (swallow)' >> Subject: RE: Additional overlay protocol extensions? (Was: Re: [CCAMP] >> Overlay model framework v2) >> >> Igor, >> >> See below for responses in line. >> >> On January 23, 2013 11:42:40 AM Igor Bryskin wrote: >>> Lou, >>> >>> Required protocol extensions (just to start with): >>> 1. MELGs +VL's committed/uncommitted status advertising >> >> Understood, although you and I may not agree on some of the details, but that discussion can wait. >> IB>>Ok >> >>> 2. Signaling extensions to set correctly client device RSVP timers >>> and to communicate the state and status of underlying server trail (e.g. >>> taking into account delays due to the server trail setup). >> >> Isn't this possible with any H-LSP), I.e. not unique to ONTs (or whatever you call it)? >> IB>> Is this covered? Where? We (ADVA, JNPR) had an issue with that and could not find the answer. >> >> >>> Issue of RROs: a client device signals the LSP path in terms of >>> VLs/VNs, what about RROs?; >> >> How is this a new problem? The issue is present/covered in 4208. >> IB>> 4208 does not have a notion of VL or VN, so it cannot possibly cover it. When ERO is signaled in terms of VLs, how does RRO returned to the client should look like: virtual links? real links? both? encrypted with some key? >> >>> 3. ONT OAM extensions and procedures (how to associate DP >>> alarms/failures happened on real links and nodes with VLs and VNs >>> that depend on them, so that client LSP restoration could be >>> controlled by the client?); >> >> This too seems like a generic problem, I.e., one present in H-LSPs, L1VPNs, and MLN. >> IB>> Where is exactly described how the faults are associated with VLs and VNs? When, say, a fault happens inside a VN, how exactly outside world knows about that to perform an alternative path computation? Please, provide a quote. >> >>> 4. VN related extensions (do we need to advertise TE RTR TLV on >>> behalf of a VN, what are the procedures if several real nodes >>> constitute VN, what is the signaling address to use if a VN is >>> selected, etc.); >> >> My understanding of existing RFCs (and discussion) is that virtual nodes/links are advertised just like real nodes/links. This sounds like an informational, or at most a BCP, document. >> >> IB>> Disagree. If a VN is comprised of two real nodes handled by separate OSPF speakers, which of them (or both) generate TE RTR TLV on behalf of VN? My solution, for example, is to deprecate completely TE RTR TLV, because it is redundant. In any case, if you know where the issue is covered, please, provide the quote. >> >>> 5. VN connectivity matrix for addressing VN's blocking/asymmetric >>> nature, including the detailed connectivity matrix (entries with >>> associated costs, which will also require signaling extensions: e.g. >>> how to specify in the ERO that a given connectivity matrix entry is >>> selected?); >> >> What as a VN connectivity matrix? Does it differ from the connectivity matrix already defined by this group? >> IB>> Yes, it does: the detailed VN connectivity matrix should include a set of costs (in terms of SRLGs, delay, TE matric, etc.) for cross-connecting two interfaces, similar to what Giovanni suggests for OI (optical impairments) vector. The consequence is that there could be more than one entry for the same pair of interfaces, with a consequence of the necessity of signaling extensions. Also, which of the speakers should advertise the connectivity matrix? I have the solution for that which is quite different from the way it is " already defined by this group" >> >> If yes, it sounds like an extension to the existing work. >> >> If no, sounds like another informational/BCP. >> >>> 6. Routing extensions to separate VN's internals from the outside >>> world; >> >> Sounds like information exchanged between overlay edge nodes (PEs). >> Basically the information that would be needed to support L1VPN enhanced mode. >> IB>> The point of VN as a powerful scalability tool is to present a network to the outside of the world as a single node (i.e. to hide internals) while still exposing in some way an IP connectivity to each of the internal nodes for the management purposes. Considering that VNs can encompass domains made of VNs, I see this as a big challenge with big benefits if solved. If you know where this issue is covered, please, provide a quote. >> >>> 7. Access/inter-domain links LMP extensions; >> >> Isn't this the same as is needed when using rfc5251 or 4208? >> IB>> Access/inter-domain links can be terminated by VNs, so, no, this >> IB>> is not covered >> >>> 8. Split-VN specific extensions ( when a blocking real node is >>> presented via several symmetrical VNs, the VN IDs could be assigned >>> and changed automatically (to remove extra configuration burden), >>> how the client NEs learn that the remote node ID of an access link is >>> (re-)assigned?) >> >> This is a specific example of item 6 above, right? >> IB>> No. Normally VN requires quite a bit of manual configuration. This is the case when this could be fully automated. >> >>> 9. Routing extensions to address independent address spaces; >> >> Part of this is already covered by L1VPN basic mode, and the rest is also required by L1VPN enhanced mode. >> IB>> I am talking about routing extensions for virtual topology which is not part of L1VPN basic mode. >> If this covered for L1VPN enhanced mode, please, provide the quote as to how this could be handled using OSPF. >> >>> 10. VPN related extensions: how to advertise VL's association with >>> one or several VPNs? How to provide VPN-specific VN's connectivity >>> matrix; >> >> I think you already covered this above. >> IB>> No, I didn't. I don't know yet how to advertise association of a >> IB>> VL with one or multiple VPNs, nor how to advertise VPN specific >> IB>> connectivity matrices, nor how to filter the information from the >> IB>> users of different VPNs >> >>> 11. Etc. >>> >>> All of the above mentioned things obviously cannot be done without a >>> well-understood framework with, yes, tightly defined definitions. >>> Hence the definitions is a very important start. >>> >> >> Wow that's a long list! >> >> It seems to me that a number/most of the items above, can be done as focused and incremental extensions to existing RFCs/WG products, in a generic way, without any further discussion/agreement on the high level overlay topic. Just like the other (soon to be) new WG documents. >> >> Certainly the informational/BCP documents would require good understanding of the target use cases. Given the clear, and seemingly circular, disagreements on basic terminology it might make most sense to spend some time documenting the different use cases/models before continuing the definitions discussion. >> >> IB>> Lou, as you see I disagreed with pretty much everything you said. >> IB>> The way I see it, one huge reason why we keep going in circles is >> IB>> you and your desire to make it look like CCAMP work has a >> IB>> continuity of developing new things based on existing RFCs. I am >> IB>> not against continuity when it calls for. This work was not >> IB>> started because CCAMP WG has initiated it. Let me remind you that >> IB>> the work has started because we (ADVA and JNPR) have a product >> IB>> that as we believe could be developed into a wider framework. It >> IB>> was always meant to be built up as a continuation of RFC4208. I >> IB>> personally have full respect for this work as well as for what >> IB>> George is doing to enhance it. What I have problem with is some >> IB>> CCAMP dead stuff such as MLN/MRN and your contra-productive >> IB>> attempts to make it look bigger than it is actually worth of. I >> IB>> also couldn't help but notice that the discussions proceed quite >> IB>> well until you wake up with your comments, so could you wake up a >> IB>> bit less frequently?:=) >> >> Igor (as contributor) >> >> Lou (as contributor) >> >>> Cheers, >>> Igor >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Wednesday, January 23, 2013 10:22 AM >>> To: Igor Bryskin >>> Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George >>> Swallow (swallow)' >>> Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP] >>> Overlay model framework v2) >>> >>> >>> >>> On 1/22/2013 1:58 PM, Igor Bryskin wrote: >>>> ... >>>> Besides, I believe nothing (terminology, architecture, protocol >>>> solutions, etc.) of MLN/MRN is relevant to what we are/were trying >>>> to achieve with ONTs. >>>> >>>> Igor >>>> ... >>> >>> Igor, >>> >>> Can we take a step back for a moment from the (seemingly endless) >>> terminology/architecture/framework debate? >>> >>> What additional (i.e., not already covered in a standalone draft, >>> e.g., >>> draft-ali-...) *protocol extensions* do you think need to be >>> standardized (as PS)? >>> >>> Is it more than just MELG? >>> >>> Lou >> >> >> >> >> >> > > > > From db3546@att.com Thu Jan 24 10:43:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BEE21F8650 for ; Thu, 24 Jan 2013 10:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 5yq5vzeqFvSm for ; Thu, 24 Jan 2013 10:43:19 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id A5BAE21F8635 for ; Thu, 24 Jan 2013 10:43:18 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id fb081015.0.1645393.00-491.4608571.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 24 Jan 2013 18:43:18 +0000 (UTC) X-MXL-Hash: 510180c639e40b91-6897803049fc382cd5422af3714a9d51002f6b5b Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OIh9HK018361 for ; Thu, 24 Jan 2013 10:43:10 -0800 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OIh6gu018340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jan 2013 10:43:07 -0800 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by fflint03.pst.cso.att.com (RSA Interceptor) for ; Thu, 24 Jan 2013 10:42:53 -0800 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0328.009; Thu, 24 Jan 2013 13:42:52 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: Ac36YpzyB19srrPaSouArquCC8tVHQ== Date: Thu, 24 Jan 2013 18:42:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8257FA6MISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=e62xv9V/ c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=D1pp4Crjj-oA:10 a=ofMgfj31e3cA:10 a=mr0] X-AnalysisOut: [z9-7qMpwA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=_SritnmU6KkA:10 a=6395D88C4xZvPChkB50A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=G4hXeTeRMBVNXPh0jloA:9 a=_W_S_7VecoQA:10 a=frz] X-AnalysisOut: [4AuCg-hUA:10 a=IvD7PF4KtCVX-VqT:21] Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:43:21 -0000 --_000_F64C10EAA68C8044B33656FA214632C8257FA6MISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = "yes/support" or "no/do not support". If indicating no, please state your t= echnical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_F64C10EAA68C8044B33656FA214632C8257FA6MISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobj= ect-02 a ccamp working group document. Please send email to the list indica= ting “yes/support” or “no/do not support”. If indic= ating no, please state your technical reservations with the document.
 
The poll ends Thursday, January 31st.
 
Note, as stated by some of the authors, IPR has been disclosed in comp= liance with IETF IPR rules.
 
Thanks,
Deborah and Lou
 
 
 --_000_F64C10EAA68C8044B33656FA214632C8257FA6MISOUT7MSGUSR9OIT_-- From db3546@att.com Thu Jan 24 10:47:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D372C21F868F for ; Thu, 24 Jan 2013 10:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.398 X-Spam-Level: X-Spam-Status: No, score=-106.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 6-zGwu+m9Dfm for ; Thu, 24 Jan 2013 10:47:57 -0800 (PST) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id F137121F863A for ; Thu, 24 Jan 2013 10:47:56 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id cd181015.0.443718.00-380.1244450.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 24 Jan 2013 18:47:56 +0000 (UTC) X-MXL-Hash: 510181dc26ffc3ea-4b63f985c07b89859ebb991ee7a6ca8685b12ec6 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OIlu2U032178 for ; Thu, 24 Jan 2013 13:47:56 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OIlqTa031963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jan 2013 13:47:53 -0500 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 24 Jan 2013 13:47:34 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0328.009; Thu, 24 Jan 2013 13:47:34 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: Ac36Y0THF366bQJXRBinToGRQUxfKQ== Date: Thu, 24 Jan 2013 18:47:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8257FBAMISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=A73bydqG c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=CcMzz_j2NSUA:10 a=ofMgfj31e3cA:10 a=FR2] X-AnalysisOut: [c6yUlWR8A:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=WxzbSAqOKzoA:10 a=6395D88C4xZvPChkB50A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=R0MEGxHUGu3fhWDgg4QA:9 a=_W_S_7VecoQA:10 a=frz] X-AnalysisOut: [4AuCg-hUA:10 a=IvD7PF4KtCVX-VqT:21] Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:47:57 -0000 --_000_F64C10EAA68C8044B33656FA214632C8257FBAMISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g "yes/support" or "no/do not support". If indicating no, please state your= technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR "still being documente= d". Thanks, Deborah and Lou --_000_F64C10EAA68C8044B33656FA214632C8257FBAMISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
This is start a two week poll on making draft-ali-ccamp-te-metric-reco= rding-03 a ccamp working group document. Please send email to the list indi= cating “yes/support” or “no/do not support”. If ind= icating no, please state your technical reservations with the document.
 
The poll ends Thursday, Feb. 7th.
 
Note, as stated by some of the authors, there is IPR “still bein= g documented”.
 
Thanks,
Deborah and Lou
 
 
 --_000_F64C10EAA68C8044B33656FA214632C8257FBAMISOUT7MSGUSR9OIT_-- From db3546@att.com Thu Jan 24 10:51:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA94321F86BA for ; Thu, 24 Jan 2013 10:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 oDtwLaiBq-A1 for ; Thu, 24 Jan 2013 10:51:26 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 229CA21F8706 for ; Thu, 24 Jan 2013 10:51:25 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ca281015.0.1881984.00-324.5254143.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 24 Jan 2013 18:51:26 +0000 (UTC) X-MXL-Hash: 510182ae73a9770a-3a8ad479213faf09906ac9405a133aec4a912828 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OIpMbq031364 for ; Thu, 24 Jan 2013 10:51:24 -0800 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OIpIl3031308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jan 2013 10:51:19 -0800 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by fflint03.pst.cso.att.com (RSA Interceptor) for ; Thu, 24 Jan 2013 10:51:03 -0800 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0328.009; Thu, 24 Jan 2013 13:51:03 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: Ac36YpzyB19srrPaSouArquCC8tVHQAAKy+A Date: Thu, 24 Jan 2013 18:51:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8257FDDMISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=PtskmXw3 c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=oPSoWJTevZYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=oYA3HnB44] X-AnalysisOut: [cwA:10 a=48vgC7mUAAAA:8 a=6395D88C4xZvPChkB50A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=2TSDkfqdCjIA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAA] X-AnalysisOut: [A:8 a=SSmOFEACAAAA:8 a=f7ccaxmNqhkpjHNWXGoA:9 a=gKO2Hq4RSV] X-AnalysisOut: [kA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:1] X-AnalysisOut: [0 a=oyS7rLQ-ISOrJANb:21] Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:51:27 -0000 --_000_F64C10EAA68C8044B33656FA214632C8257FDDMISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry - it's Feb. 7th (my mind is too focused on Super Bowl weekend)- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:43 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = "yes/support" or "no/do not support". If indicating no, please state your t= echnical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_F64C10EAA68C8044B33656FA214632C8257FDDMISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry – it’s = Feb. 7th (my mind is too focused on Super Bowl weekend)-

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:43 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02= a WG document

 

***Security Advisory: This Message Originated Outside of= AT&T ***
Reference http://cso= .att.com/EmailSecurity/IDSP.html for more information.

All,

 

This is start a two week poll on making= draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. Pleas= e send email to the list indicating “yes/support” or “no/= do not support”. If indicating no, please state your technical reservat= ions with the document.

 

The poll ends Thursday, January 31st.

 

Note, as stated by some of the authors,= IPR has been disclosed in compliance with IETF IPR rules.

 

Thanks,

Deborah and Lou

 

 

--_000_F64C10EAA68C8044B33656FA214632C8257FDDMISOUT7MSGUSR9OIT_-- From db3546@att.com Thu Jan 24 11:47:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7DD11E8097 for ; Thu, 24 Jan 2013 11:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 SZp7QhWfy0H6 for ; Thu, 24 Jan 2013 11:47:39 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8403F21F850C for ; Thu, 24 Jan 2013 11:47:39 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id bdf81015.0.1681229.00-120.4710181.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 24 Jan 2013 19:47:39 +0000 (UTC) X-MXL-Hash: 51018fdb58cd5296-e71e2b64d72a7422d95775c15d1bdc74ab0f13a8 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OJlbB8008579 for ; Thu, 24 Jan 2013 14:47:39 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OJlUW2008468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jan 2013 14:47:34 -0500 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Thu, 24 Jan 2013 14:47:24 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0328.009; Thu, 24 Jan 2013 14:47:24 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: AQHN+mPa/1L5V+tpOUui6WtYKSWwgZhY4g4A Date: Thu, 24 Jan 2013 19:47:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C825812BMISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=e62xv9V/ c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=oPSoWJTevZYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=oYA3HnB44] X-AnalysisOut: [cwA:10 a=48vgC7mUAAAA:8 a=v8ySuWTr0Uanj0cEI10A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=E1CRuzRG8yJ1T6Zz:21 a=jPbTiLA] X-AnalysisOut: [gLkasjKAN:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=eNjJeqNvC] X-AnalysisOut: [TrJI2XBXjwA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7] X-AnalysisOut: [Yk6K0A:10 a=frz4AuCg-hUA:10 a=AlqxlkZWcJwjysYd:21 a=9-v7D2] X-AnalysisOut: [sySE_mrOUB:21 a=jfLhDMcEtcWYM7aD:21] Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 19:47:41 -0000 --_000_F64C10EAA68C8044B33656FA214632C825812BMISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft just expired - the authors will re-post with -03 (no changes). He= re's a link until they do: http://tools.ietf.org/html/draft-ali-ccamp-xro-lsp-subobject-02 From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:51 PM To: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a = WG document Sorry - it's Feb. 7th (my mind is too focused on Super Bowl weekend)- From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:43 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = "yes/support" or "no/do not support". If indicating no, please state your t= echnical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_F64C10EAA68C8044B33656FA214632C825812BMISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft just expired &#= 8211; the authors will re-post with -03 (no changes). Here’s a link u= ntil they do:

http://tools.ietf.org/ht= ml/draft-ali-ccamp-xro-lsp-subobject-02

 <= /p>

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:51 PM
To: ccamp@ietf.org
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobjec= t-02 a WG document

 

Sorry – it’s = Feb. 7th (my mind is too focused on Super Bowl weekend)-

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:43 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02= a WG document

 

All,

 

This is start a two week poll on making= draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. Pleas= e send email to the list indicating “yes/support” or “no/= do not support”. If indicating no, please state your technical reservat= ions with the document.

 

The poll ends Thursday, January 31st.

 

Note, as stated by some of the authors,= IPR has been disclosed in compliance with IETF IPR rules.

 

Thanks,

Deborah and Lou

 

 

--_000_F64C10EAA68C8044B33656FA214632C825812BMISOUT7MSGUSR9OIT_-- From db3546@att.com Thu Jan 24 12:04:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F62D11E80A2 for ; Thu, 24 Jan 2013 12:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 o-J9w5WU3xFx for ; Thu, 24 Jan 2013 12:04:12 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 50A2911E809B for ; Thu, 24 Jan 2013 12:04:12 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id bb391015.0.1923317.00-375.5370636.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 24 Jan 2013 20:04:12 +0000 (UTC) X-MXL-Hash: 510193bc3517b382-0d4514c90c6d7a2a806c950e6f9f909f680876cc Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OK4BBR018183 for ; Thu, 24 Jan 2013 12:04:11 -0800 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0OK42Jf017864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jan 2013 12:04:05 -0800 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by fflint03.pst.cso.att.com (RSA Interceptor) for ; Thu, 24 Jan 2013 12:03:46 -0800 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0328.009; Thu, 24 Jan 2013 15:03:45 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Next steps on overlay Thread-Index: Ac36bemQNHMdz+KeTBOfZZLP6sIh3g== Date: Thu, 24 Jan 2013 20:03:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8258164MISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=PtskmXw3 c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=0P-fCPFO7h4A:10 a=2hAAqV_Ix] X-AnalysisOut: [He8B6NFahwA:9 a=CjuIK1q_8ugA:10 a=aQOE6LbfdNX71LlqzVEA:9 a] X-AnalysisOut: [=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=KvjZj2Bhhaga2eQJ:21] Subject: [CCAMP] Next steps on overlay X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 20:04:13 -0000 --_000_F64C10EAA68C8044B33656FA214632C8258164MISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCAMP, There's been quite a bit of discussion on the list, we'd like to see progre= ss on this topic. Perhaps we've reached the point where it's time to update= /author drafts to reflect current positions. This can either be done in one= document or in multiple (authors' choice). We also note that multiple viewpoints on how overlays may be deployed/opera= ted have been discussed. We suggest that documenting these use cases, inclu= ding data plane and control plane relationships/boundaries, would be helpfu= l. Thanks, Deborah and Lou CCAMP Chairs --_000_F64C10EAA68C8044B33656FA214632C8258164MISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
CCAMP,
 
There’s been quite a bit of discussion on the list, we’d l= ike to see progress on this topic. Perhaps we’ve reached the point wh= ere it’s time to update/author drafts to reflect current positions. T= his can either be done in one document or in multiple (authors’ choice).
 
We also note that multiple viewpoints on how overlays may be deployed/= operated have been discussed. We suggest that documenting these use cases, = including data plane and control plane relationships/boundaries, would be h= elpful.
 
Thanks,
Deborah and Lou
CCAMP Chairs
 
 
 --_000_F64C10EAA68C8044B33656FA214632C8258164MISOUT7MSGUSR9OIT_-- From IBryskin@advaoptical.com Thu Jan 24 12:53:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F5521F8518 for ; Thu, 24 Jan 2013 12:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.266 X-Spam-Level: X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6] 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 KV3rSOSTEXd2 for ; Thu, 24 Jan 2013 12:53:41 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id CB2C021F84F6 for ; Thu, 24 Jan 2013 12:53:40 -0800 (PST) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0OKrVhX029932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 21:53:31 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 24 Jan 2013 21:53:31 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Thu, 24 Jan 2013 15:53:29 -0500 From: Igor Bryskin To: "BRUNGARD, DEBORAH A" , Lou Berger Thread-Topic: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) Thread-Index: AQHN+brsnBVv26plaUm2mTp6rn8hCJhY3LJA Date: Thu, 24 Jan 2013 20:53:29 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51006334.30106@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-24_07:2013-01-24, 2013-01-24, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 20:53:42 -0000 Deborah, I am not sure what are you agreeing with. You know me long enough to know t= hat all emails I send on the list are nothing but "technically focused". Wh= ile you have your "CCAMP Co-Chair hat on" I'd like to communicate with you = as the CCAMP Co-Chair. Yesterday, Lou asked me to take a step back and explain what protocol exten= sions beyond MELGs we have in mind for the ONTs work. The way I interpreted= his request is that he was trying to understand in some depth what exactly= we are trying to do. This would be a reasonable request coming, say, from = Adrian, but coming from Lou it did sound a bit strange timing-wise because = starting from the Paris IETF (March 2012) he's been making statements/guide= lines (periodically once in 3-4 months) like the following: "This is definitely neither BCP nor UNI. ENNI - this is exactly what you, = guys, are doing"; " There are some serious problems with ENNI definitions, so this is not ENN= I. VNT/MLN/MRN - isn't this is exactly what you are doing?"; "This is L1VPN Basic mode, Enhanced mode, whatever mode, that's what you ar= e doing"; "I still believe that ONTs or whatever you call it must be built on top of = MLN/MRN ". Also get this: we have not yet finalized the definitions of Virtual Link, V= irtual Node, Virtual Topology, Overlay Topology, etc., but the good news is= that at least one thing we are certain: whatever definitions we will end u= p with they will be based on MLN/MRN. This is because Lou told us so (actua= lly, insisted): quite unambiguously, on many occasions both on the list and= the face-to-face meeting. This was far stronger than an advice, to me it s= eemed as a condition on which the work could be progressed in CCAMP. Why is= such a bias? Could it be the case, for example, that MLN/MRN, brilliant as= it is, defines one "thing" for Virtual Link, while we call VL something to= tally different?=20 After I provided the list of things that IMO need to be solved, I asked Lou= to give me pointers/quotes from RFCs that according to Lou have solved alr= eady almost each and every problem I identified, and what is needed (also a= ccording to Lou) is a bunch of BCPs (Gert, you must love this!). Did I get = these quotes? No, not so far. Instead, Lou has chosen to feel offended by m= y email. Why is that? Did I use a foul language? No. Did I personally attac= k or humiliate him? No. I did criticize him, though, for a case of WG chair= power abuse via bullying the discussion and wasting people's time and aske= d (quite politely and not for the first time) to stop doing that. That's it= . I hope criticizing of an IETF WG chair is a right of an IETF WG member an= d well within the IETF rules of conduct. The only thing that could be said = is that my criticism is unfair. But then again, so far I haven't seen a sin= gle email on the list expressing the outrage. Knowing you, I am pretty sure= that deep in your heart you agree that there is at least some truth in wha= t I am saying. Anyway I still hope that I'll get these quotes that I asked. Cheers, Igor -----Original Message----- From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]=20 Sent: Wednesday, January 23, 2013 5:42 PM To: Lou Berger; Igor Bryskin Cc: CCAMP Subject: RE: [CCAMP] Additional overlay protocol extensions? (Was: Re: Over= lay model framework v2) Agree - please keep the discussion technically focused and avoid any person= al comments. Deborah (with CCAMP Co-Chair hat on) -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Wednesday, January 23, 2013 5:25 PM To: Igor Bryskin Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Over= lay model framework v2) It seems I failed to make my perspective clear to you in my previous mail. = While this may or may not be the case, I believe your mail has moved outsid= e acceptable IETF conduct. Lou On 1/23/2013 2:54 PM, Igor Bryskin wrote: > Please, see in line. > Igor >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, January 23, 2013 12:48 PM > To: Igor Bryskin > Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George Swa= llow (swallow)' > Subject: RE: Additional overlay protocol extensions? (Was: Re: [CCAMP]=20 > Overlay model framework v2) >=20 > Igor, >=20 > See below for responses in line. >=20 > On January 23, 2013 11:42:40 AM Igor Bryskin w= rote: >> Lou, >> >> Required protocol extensions (just to start with): >> 1. MELGs +VL's committed/uncommitted status advertising >=20 > Understood, although you and I may not agree on some of the details, but = that discussion can wait. > IB>>Ok >=20 >> 2. Signaling extensions to set correctly client device RSVP timers=20 >> and to communicate the state and status of underlying server trail (e.g. >> taking into account delays due to the server trail setup). >=20 > Isn't this possible with any H-LSP), I.e. not unique to ONTs (or whatever= you call it)? > IB>> Is this covered? Where? We (ADVA, JNPR) had an issue with that and c= ould not find the answer. >=20 >=20 >> Issue of RROs: a client device signals the LSP path in terms of=20 >> VLs/VNs, what about RROs?; >=20 > How is this a new problem? The issue is present/covered in 4208. > IB>> 4208 does not have a notion of VL or VN, so it cannot possibly cover= it. When ERO is signaled in terms of VLs, how does RRO returned to the cli= ent should look like: virtual links? real links? both? encrypted with some = key? >=20 >> 3. ONT OAM extensions and procedures (how to associate DP=20 >> alarms/failures happened on real links and nodes with VLs and VNs=20 >> that depend on them, so that client LSP restoration could be=20 >> controlled by the client?); >=20 > This too seems like a generic problem, I.e., one present in H-LSPs, L1VPN= s, and MLN. > IB>> Where is exactly described how the faults are associated with VLs an= d VNs? When, say, a fault happens inside a VN, how exactly outside world kn= ows about that to perform an alternative path computation? Please, provide = a quote. >=20 >> 4. VN related extensions (do we need to advertise TE RTR TLV on=20 >> behalf of a VN, what are the procedures if several real nodes=20 >> constitute VN, what is the signaling address to use if a VN is=20 >> selected, etc.); >=20 > My understanding of existing RFCs (and discussion) is that virtual nodes/= links are advertised just like real nodes/links. This sounds like an infor= mational, or at most a BCP, document. >=20 > IB>> Disagree. If a VN is comprised of two real nodes handled by separate= OSPF speakers, which of them (or both) generate TE RTR TLV on behalf of VN= ? My solution, for example, is to deprecate completely TE RTR TLV, because = it is redundant. In any case, if you know where the issue is covered, pleas= e, provide the quote. >=20 >> 5. VN connectivity matrix for addressing VN's blocking/asymmetric=20 >> nature, including the detailed connectivity matrix (entries with=20 >> associated costs, which will also require signaling extensions: e.g. >> how to specify in the ERO that a given connectivity matrix entry is=20 >> selected?); >=20 > What as a VN connectivity matrix? Does it differ from the connectivity ma= trix already defined by this group? > IB>> Yes, it does: the detailed VN connectivity matrix should include a s= et of costs (in terms of SRLGs, delay, TE matric, etc.) for cross-connectin= g two interfaces, similar to what Giovanni suggests for OI (optical impairm= ents) vector. The consequence is that there could be more than one entry fo= r the same pair of interfaces, with a consequence of the necessity of signa= ling extensions. Also, which of the speakers should advertise the connectiv= ity matrix? I have the solution for that which is quite different from the = way it is " already defined by this group" >=20 > If yes, it sounds like an extension to the existing work. >=20 > If no, sounds like another informational/BCP. >=20 >> 6. Routing extensions to separate VN's internals from the outside=20 >> world; >=20 > Sounds like information exchanged between overlay edge nodes (PEs). =20 > Basically the information that would be needed to support L1VPN enhanced= mode. > IB>> The point of VN as a powerful scalability tool is to present a netwo= rk to the outside of the world as a single node (i.e. to hide internals) wh= ile still exposing in some way an IP connectivity to each of the internal n= odes for the management purposes. Considering that VNs can encompass domain= s made of VNs, I see this as a big challenge with big benefits if solved. = If you know where this issue is covered, please, provide a quote. >=20 >> 7. Access/inter-domain links LMP extensions; >=20 > Isn't this the same as is needed when using rfc5251 or 4208? > IB>> Access/inter-domain links can be terminated by VNs, so, no, this=20 > IB>> is not covered >=20 >> 8. Split-VN specific extensions ( when a blocking real node is=20 >> presented via several symmetrical VNs, the VN IDs could be assigned=20 >> and changed automatically (to remove extra configuration burden),=20 >> how the client NEs learn that the remote node ID of an access link is >> (re-)assigned?) >=20 > This is a specific example of item 6 above, right? > IB>> No. Normally VN requires quite a bit of manual configuration. This i= s the case when this could be fully automated. >=20 >> 9. Routing extensions to address independent address spaces; >=20 > Part of this is already covered by L1VPN basic mode, and the rest is also= required by L1VPN enhanced mode. > IB>> I am talking about routing extensions for virtual topology which is = not part of L1VPN basic mode. > If this covered for L1VPN enhanced mode, please, provide the quote as to= how this could be handled using OSPF. >=20 >> 10. VPN related extensions: how to advertise VL's association with=20 >> one or several VPNs? How to provide VPN-specific VN's connectivity=20 >> matrix; >=20 > I think you already covered this above. > IB>> No, I didn't. I don't know yet how to advertise association of a=20 > IB>> VL with one or multiple VPNs, nor how to advertise VPN specific=20 > IB>> connectivity matrices, nor how to filter the information from the=20 > IB>> users of different VPNs >=20 >> 11. Etc. >> >> All of the above mentioned things obviously cannot be done without a=20 >> well-understood framework with, yes, tightly defined definitions. >> Hence the definitions is a very important start. >> >=20 > Wow that's a long list! >=20 > It seems to me that a number/most of the items above, can be done as foc= used and incremental extensions to existing RFCs/WG products, in a generic= way, without any further discussion/agreement on the high level overlay to= pic. Just like the other (soon to be) new WG documents. >=20 > Certainly the informational/BCP documents would require good understandin= g of the target use cases. Given the clear, and seemingly circular, disagr= eements on basic terminology it might make most sense to spend some time do= cumenting the different use cases/models before continuing the definitions = discussion. >=20 > IB>> Lou, as you see I disagreed with pretty much everything you said.=20 > IB>> The way I see it, one huge reason why we keep going in circles is=20 > IB>> you and your desire to make it look like CCAMP work has a=20 > IB>> continuity of developing new things based on existing RFCs. I am=20 > IB>> not against continuity when it calls for. This work was not=20 > IB>> started because CCAMP WG has initiated it. Let me remind you that=20 > IB>> the work has started because we (ADVA and JNPR) have a product=20 > IB>> that as we believe could be developed into a wider framework. It=20 > IB>> was always meant to be built up as a continuation of RFC4208. I=20 > IB>> personally have full respect for this work as well as for what=20 > IB>> George is doing to enhance it. What I have problem with is some=20 > IB>> CCAMP dead stuff such as MLN/MRN and your contra-productive=20 > IB>> attempts to make it look bigger than it is actually worth of. I=20 > IB>> also couldn't help but notice that the discussions proceed quite=20 > IB>> well until you wake up with your comments, so could you wake up a=20 > IB>> bit less frequently?:=3D) >=20 > Igor (as contributor) >=20 > Lou (as contributor) >=20 >> Cheers, >> Igor >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, January 23, 2013 10:22 AM >> To: Igor Bryskin >> Cc: John E Drake; CCAMP; Stewart Bryant; adrian@olddog.co.uk; 'George=20 >> Swallow (swallow)' >> Subject: Additional overlay protocol extensions? (Was: Re: [CCAMP]=20 >> Overlay model framework v2) >> >> >> >> On 1/22/2013 1:58 PM, Igor Bryskin wrote: >>> ... >>> Besides, I believe nothing (terminology, architecture, protocol=20 >>> solutions, etc.) of MLN/MRN is relevant to what we are/were trying=20 >>> to achieve with ONTs. >>> >>> Igor >>> ... >> >> Igor, >> >> Can we take a step back for a moment from the (seemingly endless)=20 >> terminology/architecture/framework debate? >> >> What additional (i.e., not already covered in a standalone draft,=20 >> e.g., >> draft-ali-...) *protocol extensions* do you think need to be=20 >> standardized (as PS)? >> >> Is it more than just MELG? >> >> Lou >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From zali@cisco.com Thu Jan 24 13:58:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A7321F8635 for ; Thu, 24 Jan 2013 13:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 aJL4U95xFsXm for ; Thu, 24 Jan 2013 13:58:03 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2F91621F84C7 for ; Thu, 24 Jan 2013 13:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11153; q=dns/txt; s=iport; t=1359064683; x=1360274283; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=/JGyV52LMoXIQj5VuW29+u0Is6DvLAhFDiql44YjAzc=; b=mW8EvpQ6hvAWEpjMMFOP3pjAeOwiAluN9NOhkns6xZ82BjArpgDF9TEf 0StYsgdytBEZoCL10oe5RKztY/bHs6A8PNktpaV6REQrpgpZ6sUP8JCdw bypsc0nrIT8ZNQWy3yTCxMhtpwz9xdp0tKNSiZfHb/BQXZdbaD1cg5jxO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAGWtAVGtJXHB/2dsb2JhbABEgkiFGK1IiSIWc4IeAQEBBC1MEgEIEQMBAQELHTkUCQgCBAENBQgBiBEMvh2NA4MXYQOXKI8sgniBbzU X-IronPort-AV: E=Sophos;i="4.84,532,1355097600"; d="scan'208,217";a="167513294" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jan 2013 21:58:02 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0OLw2Xe006554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 21:58:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 15:58:02 -0600 From: "Zafar Ali (zali)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: AQHN+n3hnIkTsq/ejE2Rg5EO01gyxQ== Date: Thu, 24 Jan 2013 21:58:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.254.2] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D3B32D17xmbrcdx14ciscocom_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 21:58:04 -0000 --_000_B6585D85A128FD47857D0FD58D8120D3B32D17xmbrcdx14ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Fellows: We have posted =9603 (without any change). The latest version is at: http://www.ietf.org/id/draft-ali-ccamp-xro-lsp-subobject-03.txt Thanks Regards =85 Zafar From: , DEBORAH A > Date: Thursday, January 24, 2013 2:47 PM To: "ccamp@ietf.org" > Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a = WG document The draft just expired =96 the authors will re-post with -03 (no changes). = Here=92s a link until they do: http://tools.ietf.org/html/draft-ali-ccamp-xro-lsp-subobject-02 From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:51 PM To: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a = WG document Sorry =96 it=92s Feb. 7th (my mind is too focused on Super Bowl weekend)- From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:43 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = =93yes/support=94 or =93no/do not support=94. If indicating no, please stat= e your technical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_B6585D85A128FD47857D0FD58D8120D3B32D17xmbrcdx14ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1C6ED3DCD9DA1A45AABFABA6ADCDA069@cisco.com> Content-Transfer-Encoding: quoted-printable
Dear Fellows:

We have posted =9603 (without any change). The latest version is at:
http://www.ietf.org/id/draft-ali-ccamp-xro-lsp-subobject-03.txt

Thanks

Regards =85 Zafar

From: <BRUNGARD>, DEBORAH A &= lt;db3546@att.com>
Date: Thursday, January 24, 2013 2:= 47 PM
To: "ccamp@ietf.org" <cca= mp@ietf.org>
Subject: Re: [CCAMP] Poll on making= draft-ali-ccamp-xro-lsp-subobject-02 a WG document

The draft just expired =96 the aut= hors will re-post with -03 (no changes). Here=92s a link until they do:

http://tools.ietf.org/html/draft-= ali-ccamp-xro-lsp-subobject-02

 

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:51 PM
To: ccamp@ietf.org
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobjec= t-02 a WG document

 

Sorry =96 it=92s Feb. 7th (my mind is too focused on Super Bowl weekend)-

 

From:ccamp-b= ounces@ietf.org [mailto:ccamp= -bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:43 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02= a WG document

 

All,

 

This is start a two week poll on making draft-ali-ccamp-xro= -lsp-subobject-02 a ccamp working group document. Please send email to the = list indicating =93yes/support=94 or =93no/do not support=94. If indicating no, please state your technical reservations= with the document.

 

The poll ends Thursday, January 31st.

 

Note, as stated by some of the authors, IPR has been disclo= sed in compliance with IETF IPR rules.

 

Thanks,

Deborah and Lou

 

 

 --_000_B6585D85A128FD47857D0FD58D8120D3B32D17xmbrcdx14ciscocom_-- From rrao@infinera.com Thu Jan 24 17:04:00 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F233121F857C for ; Thu, 24 Jan 2013 17:03:59 -0800 (PST) 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 VRUSZ9QQ8APA for ; Thu, 24 Jan 2013 17:03:59 -0800 (PST) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF4E21F8570 for ; Thu, 24 Jan 2013 17:03:59 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 17:03:58 -0800 From: Rajan Rao To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: Ac36Y0THF366bQJXRBinToGRQUxfKQAM/dXg Date: Fri, 25 Jan 2013 01:03:57 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D3FADF8AE@SV-EXDB-PROD1.infinera.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_650AA355E323C34D9D4AAEED952E053D3FADF8AESVEXDBPROD1infi_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 01:04:00 -0000 --_000_650AA355E323C34D9D4AAEED952E053D3FADF8AESVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Question: What is the scheme for informing endpoints for the update case (= sec 2.3)? Is it refresh mechanism or something else? Thanks Rajan From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 10:48 AM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g "yes/support" or "no/do not support". If indicating no, please state your= technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR "still being documente= d". Thanks, Deborah and Lou --_000_650AA355E323C34D9D4AAEED952E053D3FADF8AESVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors,

 <= /p>

Question:  What is t= he scheme for informing endpoints for the update case (sec 2.3)?  &nbs= p;Is it refresh mechanism or something else?

 <= /p>

Thanks<= /p>

Rajan

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 10:48 AM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-= 03 WG document

 

All,

 

This is start a two week poll on making= draft-ali-ccamp-te-metric-recording-03 a ccamp working group document. Ple= ase send email to the list indicating “yes/support” or “n= o/do not support”. If indicating no, please state your technical reservat= ions with the document.

 

The poll ends Thursday, Feb= . 7th.

 

Note, as stated by some of the authors,= there is IPR “still being documented”.

 

Thanks,

Deborah and Lou

 

 

--_000_650AA355E323C34D9D4AAEED952E053D3FADF8AESVEXDBPROD1infi_-- From internet-drafts@ietf.org Thu Jan 24 17:25:49 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF67A11E80E4; Thu, 24 Jan 2013 17:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, 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 oE5zgityiMAx; Thu, 24 Jan 2013 17:25:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B27311E80D9; Thu, 24 Jan 2013 17:25:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130125012549.24171.15687.idtracker@ietfa.amsl.com> Date: Thu, 24 Jan 2013 17:25:49 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-lmp-behavior-negotiation-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 01:25:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Link Management Protocol Behavior Negotiation and Config= uration Modifications Author(s) : Dan Li Daniele Ceccarelli Lou Berger Filename : draft-ietf-ccamp-lmp-behavior-negotiation-10.txt Pages : 11 Date : 2013-01-24 Abstract: The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS)-controlled networks. This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations. This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-lmp-behavior-negotiation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-lmp-behavior-negotiation-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-lmp-behavior-negotiatio= n-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From huawei.danli@huawei.com Thu Jan 24 17:36:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA1C21F8230 for ; Thu, 24 Jan 2013 17:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.204 X-Spam-Level: * X-Spam-Status: No, score=1.204 tagged_above=-999 required=5 tests=[AWL=-1.584, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 pgBU7ri6hZHN for ; Thu, 24 Jan 2013 17:36:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0040E21F8200 for ; Thu, 24 Jan 2013 17:36:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APB98189; Fri, 25 Jan 2013 01:36:09 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 25 Jan 2013 01:35:49 +0000 Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 25 Jan 2013 09:36:08 +0800 Received: from szxeml555-mbx.china.huawei.com ([169.254.1.229]) by szxeml457-hub.china.huawei.com ([10.82.67.200]) with mapi id 14.01.0323.007; Fri, 25 Jan 2013 09:36:02 +0800 From: "Lidan (Dan)" To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-lmp-behavior-negotiation-10.txt Thread-Index: AQHN+pr/jhx+P1LxDkO0dhOcRRe8PphZQTHQ Date: Fri, 25 Jan 2013 01:36:02 +0000 Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A3884FEF7@szxeml555-mbx.china.huawei.com> References: <20130125012549.24171.15687.idtracker@ietfa.amsl.com> In-Reply-To: <20130125012549.24171.15687.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.73.151] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh?= =?gb2312?b?bXAtbG1wLWJlaGF2aW9yLW5lZ290aWF0aW9uLTEwLnR4dA==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 01:36:12 -0000 RGVhciBhbGwsDQoNCldlIGp1c3QgdXBkYXRlZCB0aGlzIGRyYWZ0IGJhc2VkIG9uIHRoZSByZXN1 bHRzIG9mIElFU0cgTEM6DQoxKSBGaXhlZCB0aGUgcHJvYmxlbSByYWlzZWQgYnkgSUFOQSByZXZp ZXc6IHMvYmVoYXZpb3VyL2JlaGF2aW9yLw0KMikgRWRpdG9yaWFsIGNoYW5nZXMgYmFzZWQgb24g dGhlIFJURyBkaXJlY3RvcmF0ZSByZXZpZXcgcmVzdWx0OiBzZXZlcmFsIHdvcmRzIGNoYW5nZXMg YW5kIHJlbW92ZWQgdGhlIHJlZmVyZW5jZSBbTE1QIFRFU1RdIGFuZCByZWxhdGVkIHNlbnRlbmNl IGluICJJbnRyb2R1Y3Rpb24iIHNlY3Rpb24uDQozKSBBZGRlZCB0aGUgcmVmZXJlbmNlIFtSRkM1 NTExXSBiYXNlZCBvbiB0aGUgUlRHIEFEIGNvbW1lbnQuDQoNClRoYW5rcywNCg0KRGFuDQoNCi0t LS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCrei y83KsbzkOiAyMDEzxOox1MIyNcjVIDk6MjYNCsrVvP7IyzogaS1kLWFubm91bmNlQGlldGYub3Jn DQqzrcvNOiBjY2FtcEBpZXRmLm9yZw0K1vfM4jogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWNjYW1wLWxtcC1iZWhhdmlvci1uZWdvdGlhdGlvbi0xMC50eHQNCg0KDQpBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuDQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENv bnRyb2wgYW5kIE1lYXN1cmVtZW50IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoN CglUaXRsZSAgICAgICAgICAgOiBMaW5rIE1hbmFnZW1lbnQgUHJvdG9jb2wgQmVoYXZpb3IgTmVn b3RpYXRpb24gYW5kIENvbmZpZ3VyYXRpb24gTW9kaWZpY2F0aW9ucw0KCUF1dGhvcihzKSAgICAg ICA6IERhbiBMaQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBEYW5pZWxlIENlY2NhcmVsbGkN CiAgICAgICAgICAgICAgICAgICAgICAgICAgTG91IEJlcmdlcg0KCUZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtY2NhbXAtbG1wLWJlaGF2aW9yLW5lZ290aWF0aW9uLTEwLnR4dA0KCVBhZ2Vz ICAgICAgICAgICA6IDExDQoJRGF0ZSAgICAgICAgICAgIDogMjAxMy0wMS0yNA0KDQpBYnN0cmFj dDoNCiAgIFRoZSBMaW5rIE1hbmFnZW1lbnQgUHJvdG9jb2wgKExNUCkgaXMgdXNlZCB0byBjb29y ZGluYXRlIHRoZQ0KICAgcHJvcGVydGllcywgdXNlLCBhbmQgZmF1bHRzIG9mIGRhdGEgbGlua3Mg aW4gR2VuZXJhbGl6ZWQNCiAgIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChHTVBMUykt Y29udHJvbGxlZCBuZXR3b3Jrcy4gVGhpcw0KICAgZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbnNp b24gdG8gTE1QIHRvIG5lZ290aWF0ZSBjYXBhYmlsaXRpZXMgYW5kDQogICBpbmRpY2F0ZSBzdXBw b3J0IGZvciBMTVAgZXh0ZW5zaW9ucy4gVGhlIGRlZmluZWQgZXh0ZW5zaW9uIGlzDQogICBjb21w YXRpYmxlIHdpdGggbm9uLXN1cHBvcnRpbmcgaW1wbGVtZW50YXRpb25zLg0KDQogICBUaGlzIGRv Y3VtZW50IHVwZGF0ZXMgUkZDIDQyMDQsIFJGQyA0MjA3LCBSRkMgNDIwOSBhbmQgUkZDIDU4MTgu DQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLWxtcC1i ZWhhdmlvci1uZWdvdGlhdGlvbg0KDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2 YWlsYWJsZSBhdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAt bG1wLWJlaGF2aW9yLW5lZ290aWF0aW9uLTEwDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtY2NhbXAtbG1wLWJlaGF2aW9yLW5lZ290aWF0aW9uLTEwDQoNCg0KSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== From zali@cisco.com Thu Jan 24 21:28:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA6411E80E1 for ; Thu, 24 Jan 2013 21:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 uQTJjPoMNECa for ; Thu, 24 Jan 2013 21:28:24 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5870911E80DE for ; Thu, 24 Jan 2013 21:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10541; q=dns/txt; s=iport; t=1359091704; x=1360301304; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=unIegmoTxiYGYI+3KG4TvQax1AWeEYfCzXqn7ycb66s=; b=dSzogY6CPxWmDsPmn1YKh88YDZrtI7lR62O2I/jxXTJEEbOm+Ibx0B6w irDEGps4PyqutjKG/aVSNybNo1MgDtnLtPu5DeqabbbonoN1uqhgdIgFV hIgBapbPKAbAG223aHBjHGw7wlULpJFjkAg0KD4rFBVSjiI7pIerbcBij c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKYWAlGtJXG9/2dsb2JhbABEgki8DxZzgh4BAQEELV4BCA4DAwEBAQsdORQJCAIEARIIiBK+CI0Dg1phA6ZUgniBbzU X-IronPort-AV: E=Sophos;i="4.84,535,1355097600"; d="scan'208,217";a="167880865" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jan 2013 05:28:24 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0P5SNBA015364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 05:28:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 23:28:23 -0600 From: "Zafar Ali (zali)" To: Rajan Rao , "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: AQHN+rzLhH5htMp+m0CrjJ+QGe3ueQ== Date: Fri, 25 Jan 2013 05:28:23 +0000 Message-ID: In-Reply-To: <650AA355E323C34D9D4AAEED952E053D3FADF8AE@SV-EXDB-PROD1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.247.171] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D3B3320Fxmbrcdx14ciscocom_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 05:28:25 -0000 --_000_B6585D85A128FD47857D0FD58D8120D3B3320Fxmbrcdx14ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rajan: RFC3209 covers this. Specifically a path change is triggered on the fly (no= need to wait for refresh). I am cutting and pasting some relevant text fro= m Section 4.4.3 of RFC3209. "An RSVP router can decide to send Path messages before its refresh time if the RRO in the next Path message is different from the previous one. This can happen if the contents of the RRO received from the previous hop router changes or if this RRO is newly added to (or deleted from) the Path message." Thanks Regards=85Zafar From: Rajan Rao > Date: Thursday, January 24, 2013 8:03 PM To: "BRUNGARD, DEBORAH A" >, "ccamp@i= etf.org" > Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 = WG document Authors, Question: What is the scheme for informing endpoints for the update case (= sec 2.3)? Is it refresh mechanism or something else? Thanks Rajan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 10:48 AM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g =93yes/support=94 or =93no/do not support=94. If indicating no, please st= ate your technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR =93still being documen= ted=94. Thanks, Deborah and Lou --_000_B6585D85A128FD47857D0FD58D8120D3B3320Fxmbrcdx14ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Rajan:

RFC3209 covers this. Specifically a path change is triggered on the fl= y (no need to wait for refresh). I am cutting and pasting some relevant tex= t from Section 4.4.3 of RFC3209. 

"An RSVP router can decide to se= nd Path messages before its refresh
   time if th=
e RRO in the next Path message is different from the
   previous one.  This can happen if the contents of the RRO received
   from the previous hop router changes or if this RRO is newly added to
   (or deleted from) the Path message."

Thanks

Regards=85Zafar 

From: Rajan Rao <rrao@infinera.com>
Date: Thursday, January 24, 2013 8:= 03 PM
To: "BRUNGARD, DEBORAH A"= <db3546@att.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Poll on making= draft-ali-ccamp-te-metric-recording-03 WG document

Authors,

 

Question:  What is the scheme= for informing endpoints for the update case (sec 2.3)?   Is it r= efresh mechanism or something else?

 

Thanks

Rajan

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 10:48 AM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-= 03 WG document

 

All,

 

This is start a two week poll on making draft-ali-ccamp-te-= metric-recording-03 a ccamp working group document. Please send email to th= e list indicating =93yes/support=94 or =93no/do not support=94. If indicating no, please state your technical reservations= with the document.

 

The poll ends Thursday, Feb. 7th.

 

Note, as stated by some of the authors, there is IPR =93sti= ll being documented=94.

 

Thanks,

Deborah and Lou

 

 

 --_000_B6585D85A128FD47857D0FD58D8120D3B3320Fxmbrcdx14ciscocom_-- From internet-drafts@ietf.org Fri Jan 25 01:31:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7281121F880E; Fri, 25 Jan 2013 01:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, 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 3tHUnlHVRjlU; Fri, 25 Jan 2013 01:31:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C808D21F87B2; Fri, 25 Jan 2013 01:31:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130125093144.27836.48689.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2013 01:31:44 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 09:31:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Signa= ling Extensions for the evolving G.709 Optical Transport Networks Control Author(s) : Fatai Zhang Guoying Zhang Sergio Belotti Daniele Ceccarelli Khuzema Pithewan Filename : draft-ietf-ccamp-gmpls-signaling-g709v3-06.txt Pages : 28 Date : 2013-01-25 Abstract: ITU-T Recommendation G.709 [G709-2012] has introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. This document updates RFC4328 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the evolving OTN addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3-= 06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhangfatai@huawei.com Fri Jan 25 01:40:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BBD21F84BA for ; Fri, 25 Jan 2013 01:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, 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 fahCcebPucoy for ; Fri, 25 Jan 2013 01:40:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 63CC921F848B for ; Fri, 25 Jan 2013 01:40:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APC27898; Fri, 25 Jan 2013 09:40:32 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 25 Jan 2013 09:40:09 +0000 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 25 Jan 2013 09:40:29 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.01.0323.007; Fri, 25 Jan 2013 17:40:21 +0800 From: Fatai Zhang To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-06.txt Thread-Index: AQHN+t7sz/qbrDTPuUiToSx4dME7fphZyhJw Date: Fri, 25 Jan 2013 09:40:20 +0000 Message-ID: References: <20130125093144.27836.48689.idtracker@ietfa.amsl.com> In-Reply-To: <20130125093144.27836.48689.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 09:40:35 -0000 Hi Lou and CCAMPers, Please see the new version to check whether all your comments have been add= ressed.=20 Note: There is one warning nit about pre-RFC5378 disclaimer. It said that i= t may need to add pre-RFC5378 disclaimer when version 05 was submitted. How= ever, it asks whehter it really need pre-RFC5378 disclaimer this time. :-) Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Friday, January 25, 2013 5:32 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Signa= ling Extensions for the evolving G.709 Optical Transport Networks Control Author(s) : Fatai Zhang Guoying Zhang Sergio Belotti Daniele Ceccarelli Khuzema Pithewan Filename : draft-ietf-ccamp-gmpls-signaling-g709v3-06.txt Pages : 28 Date : 2013-01-25 Abstract: ITU-T Recommendation G.709 [G709-2012] has introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. This document updates RFC4328 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the evolving OTN addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3-= 06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From adrian@olddog.co.uk Fri Jan 25 02:37:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95ADF21F8795 for ; Fri, 25 Jan 2013 02:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[AWL=-1.421, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] 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 Sq3tJG80Wjf5 for ; Fri, 25 Jan 2013 02:37:47 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEAD21F8732 for ; Fri, 25 Jan 2013 02:37:43 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0PAbaFp025242; Fri, 25 Jan 2013 10:37:36 GMT Received: from 950129200 (089144192091.atnat0001.highway.a1.net [89.144.192.91]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0PAbYoU025199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 10:37:35 GMT From: "Adrian Farrel" To: "'Lidan \(Dan\)'" , References: <20130125012549.24171.15687.idtracker@ietfa.amsl.com> <92A1F6CF27D54D4DA5364E59D892A02A3884FEF7@szxeml555-mbx.china.huawei.com> In-Reply-To: <92A1F6CF27D54D4DA5364E59D892A02A3884FEF7@szxeml555-mbx.china.huawei.com> Date: Fri, 25 Jan 2013 10:37:33 -0000 Message-ID: <00c401cdfae7$fdcf40e0$f96dc2a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEHxIAdEF+PnFZXurMXB3gFE5M5NwIgyS7umdVAYUA= Content-Language: en-gb Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-lmp-behavior-negotiation-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 10:37:47 -0000 Thanks Dan, I will move this on for IESG evaluation. Adrian > -----Original Message----- > From: Lidan (Dan) [mailto:huawei.danli@huawei.com] > Sent: 25 January 2013 01:36 > To: ccamp@ietf.org > Cc: Lou Berger; BRUNGARD, DEBORAH A; adrian@olddog.co.uk > Subject: =B4=F0=B8=B4: [CCAMP] I-D Action: = draft-ietf-ccamp-lmp-behavior-negotiation- > 10.txt >=20 > Dear all, >=20 > We just updated this draft based on the results of IESG LC: > 1) Fixed the problem raised by IANA review: s/behaviour/behavior/ > 2) Editorial changes based on the RTG directorate review result: = several words > changes and removed the reference [LMP TEST] and related sentence in > "Introduction" section. > 3) Added the reference [RFC5511] based on the RTG AD comment. >=20 > Thanks, >=20 > Dan >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] =B4=FA=B1=ED > internet-drafts@ietf.org > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA1=D4=C225=C8=D5 9:26 > =CA=D5=BC=FE=C8=CB: i-d-announce@ietf.org > =B3=AD=CB=CD: ccamp@ietf.org > =D6=F7=CC=E2: [CCAMP] I-D Action: = draft-ietf-ccamp-lmp-behavior-negotiation-10.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. >=20 > Title : Link Management Protocol Behavior Negotiation and > Configuration Modifications > Author(s) : Dan Li > Daniele Ceccarelli > Lou Berger > Filename : draft-ietf-ccamp-lmp-behavior-negotiation-10.txt > Pages : 11 > Date : 2013-01-24 >=20 > Abstract: > The Link Management Protocol (LMP) is used to coordinate the > properties, use, and faults of data links in Generalized > Multiprotocol Label Switching (GMPLS)-controlled networks. This > document defines an extension to LMP to negotiate capabilities and > indicate support for LMP extensions. The defined extension is > compatible with non-supporting implementations. >=20 > This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-ccamp-lmp-behavior-negotiatio= n >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-ccamp-lmp-behavior-negotiation-10 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-lmp-behavior-negotiat= ion-10 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From internet-drafts@ietf.org Fri Jan 25 03:46:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A08821F880E; Fri, 25 Jan 2013 03:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, 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 3WEBIIwt53im; Fri, 25 Jan 2013 03:46:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C696121F86DA; Fri, 25 Jan 2013 03:46:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130125114642.26387.84014.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2013 03:46:42 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-oam-configuration-fwk-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 11:46:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : GMPLS RSVP-TE extensions for OAM Configuration Author(s) : Attila Takacs Don Fedyk Jia He Filename : draft-ietf-ccamp-oam-configuration-fwk-09.txt Pages : 18 Date : 2013-01-25 Abstract: OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-oam-configuration-fwk There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-oam-configuration-fwk-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From agmalis@gmail.com Fri Jan 25 07:37:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8686721F8948 for ; Fri, 25 Jan 2013 07:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 4Tz4iwIn9B97 for ; Fri, 25 Jan 2013 07:37:35 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id F328F21F8947 for ; Fri, 25 Jan 2013 07:37:34 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id z24so245218qcq.33 for ; Fri, 25 Jan 2013 07:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Vv0aQSIZSAr+R9zsyJpDR8JVx7RH2Cp4bsKcnmJzugw=; b=YJdcYk+wBT3+Sxi1pEwg67jdSvd/r5iEN0TRUftUiFvVQAzf7+2s7YysIODIGLZcIu rmKvmnDAYelQtwlRjo/6Es+jNElzCAtX2yd08gLV0iSyF4gnpY8AGHFJAvIPeLgXoNhZ LMSnJQZbi6nPR18g5yYTBZBn2CwPyL2/pWjOwk0pTvp10WaJUyue6fq0OK6CZNpLQsKH 0msM/M5ck8SR0t1P04pH+eBhz2DHo4LNhJs7phrz9miDG9oAHv/fZ+4OzArj4xsxeQAK dh8Bhk1RhyqiGIX816v0YVEZLVKanD+FfHX8gTJbGwT0aXcAy/rM4BajsYygK4REesJZ o4OQ== X-Received: by 10.224.72.197 with SMTP id n5mr6385158qaj.38.1359128254462; Fri, 25 Jan 2013 07:37:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.78.72 with HTTP; Fri, 25 Jan 2013 07:37:14 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 25 Jan 2013 10:37:14 -0500 Message-ID: To: "BRUNGARD, DEBORAH A" Content-Type: multipart/alternative; boundary=20cf3071d1dacfba1d04d41eb4c2 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:37:35 -0000 --20cf3071d1dacfba1d04d41eb4c2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 24, 2013 at 1:42 PM, BRUNGARD, DEBORAH A wrote: > yes/support yes/support, this is useful functionality. Cheers, Andy --20cf3071d1dacfba1d04d41eb4c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Jan 24, 2013 at 1:42 PM, BRUNGARD, DEBORAH A <= db3546@att.com><= /span> wrote:
yes/support
<= /div>

yes/supp= ort, this is useful functionality.

Cheers,
Andy
--20cf3071d1dacfba1d04d41eb4c2-- From giomarti@cisco.com Fri Jan 25 07:48:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB28A21F88A2 for ; Fri, 25 Jan 2013 07:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Nf9VFcKbon9M for ; Fri, 25 Jan 2013 07:48:12 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E4D0C21F87B1 for ; Fri, 25 Jan 2013 07:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3599; q=dns/txt; s=iport; t=1359128892; x=1360338492; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=asGtA6iyYPwEeZRrSu5L7gb/R2VEcsO+MtX1wensw+E=; b=Md/Hy5FNN5wojgn5jvRFmJPYJpQEQYKJOKNhSZ9nciK0D75YKHLczMIv Sbn0kKzjMRUaAao2gP6Dk3a8e7peOy7eLjrM8tVWR/T+BmLQi9Rj3MRmp fdPqjgxLWaLgmaSASgroxPi7nM6TybBcY1Ao2M+DRmPNtQPS1M+Tz+gf8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKaoAlGtJV2c/2dsb2JhbABEvlMWc4IeAQEBAwEBAQFrBgUFCwIBCA4KCiQnCyUCBA4FCAGIAAYMvkWMeQsQg0phA4gsgyaHCIRPhT2Jb4J3gW81 X-IronPort-AV: E=Sophos;i="4.84,539,1355097600"; d="scan'208";a="168104695" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jan 2013 15:48:11 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0PFmAxX018825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 15:48:10 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 09:48:10 -0600 From: "Giovanni Martinelli (giomarti)" To: Lou Berger Thread-Topic: [CCAMP] Regarding IPR on draft-margaria-ccamp-lsp-attribute-ero-02 Thread-Index: AQHN+ZoScJ829bF/YE+8vJbQq67F7phamCCA Date: Fri, 25 Jan 2013 15:48:10 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D242095@xmb-rcd-x14.cisco.com> References: <50BE808B.8070808@labn.net> <50F43AE4.6090807@labn.net> <51003039.3040809@labn.net> In-Reply-To: <51003039.3040809@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.172.227] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Regarding IPR on draft-margaria-ccamp-lsp-attribute-ero-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:48:12 -0000 Lou, I'm ok with your proposal cheers G On Jan 23, 2013, at 19:47 , Lou Berger wrote: > Authors, WG, > It seems that Dirk is no longer active in our WG or on the > draft. We'd like to propose the following in order to unblock progress > on this draft: >=20 > 1) That Dirk's name be removed from the Authors/Contributor's section >=20 > 2) That Dirk's contribution to this draft to date be recognized in the > Acknowledgments section >=20 > 3) That these changes be made in > draft-margaria-ccamp-lsp-attribute-ero-03 >=20 > 4) That draft-margaria-ccamp-lsp-attribute-ero-03 then be accepted as > a WG document based the results of last month's poll > (http://www.ietf.org/mail-archive/web/ccamp/current/msg14293.html) >=20 > 5) That, baring any substantive objections, that the above take place > on or after Jan 31. >=20 > We can revisit 1 & 2 if Dirk responds to the IPR poll in future. >=20 > Thoughts/comments? >=20 > Lou (and Deborah) >=20 > On 1/14/2013 12:05 PM, Lou Berger wrote: >> Dirk, >> Please respond so that we can move this draft forward. >>=20 >> Thank you, >> Lou >>=20 >> PS CCAMP, if anyone knows how to contact Dirk please forward this >> message to him, or let us know who to reach him. >>=20 >> On 12/4/2012 6:00 PM, Lou Berger wrote: >>> Authors, Contributors, (CCAMP) >>>=20 >>> As part of the preparation for the poll on making this document a WG >>> document: >>>=20 >>> Are you aware of any IPR that applies to >>> draft-margaria-ccamp-lsp-attribute-ero-02? >>>=20 >>> Please state either: >>>=20 >>> "No, I'm not aware of any IPR that applies to this draft" >>> or >>> "Yes, I'm aware of IPR that applies to this draft" >>>=20 >>> If so, has this IPR been disclosed in compliance with IETF IPR rules >>> (see RFCs 3979, 4879, 3669 and 5378 for more details)? >>>=20 >>> If yes to the above, please state either: >>>=20 >>> "Yes, the IPR has been disclosed in compliance with IETF IPR rules" >>> or >>> "No, the IPR has not been disclosed" >>>=20 >>> If you answer no, please provide any additional details you think >>> appropriate. >>>=20 >>> If you are listed as a document author or contributor please answer the >>> above by responding to this email regardless of whether or not you are >>> aware of any relevant IPR. This document will not advance to the next >>> stage until a response has been received from each author and listed >>> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS >>> MESSAGE'S TO LINES. >>>=20 >>> If you are on the CCAMP WG email list but are not listed as an author o= r >>> contributor, we remind you of your obligations under the IETF IPR rules >>> which encourages you to notify the IETF if you are aware of IPR of >>> others on an IETF contribution, or to refrain from participating in any >>> contribution or discussion related to your undisclosed IPR. For more >>> information, please see the RFCs listed above and >>> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >>>=20 >>> Thank you, >>> CCAMP WG Chairs >>>=20 >>> PS Please include all listed in the headers of this message in your >>> response. >>>=20 >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>>=20 >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >>=20 >>=20 >>=20 >>=20 From rrao@infinera.com Fri Jan 25 08:54:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB7C21F8858 for ; Fri, 25 Jan 2013 08:54:15 -0800 (PST) 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 4G8e3ZExDp3P for ; Fri, 25 Jan 2013 08:54:13 -0800 (PST) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id B68CF21F850B for ; Fri, 25 Jan 2013 08:54:13 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 08:54:12 -0800 From: Rajan Rao To: "Zafar Ali (zali)" , "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: AQHN+rzMQU/JMaM870e01HbIcOjHIZhaQ0Ug Date: Fri, 25 Jan 2013 16:54:11 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D3FADFB90@SV-EXDB-PROD1.infinera.com> References: <650AA355E323C34D9D4AAEED952E053D3FADF8AE@SV-EXDB-PROD1.infinera.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.108] Content-Type: multipart/alternative; boundary="_000_650AA355E323C34D9D4AAEED952E053D3FADFB90SVEXDBPROD1infi_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:54:15 -0000 --_000_650AA355E323C34D9D4AAEED952E053D3FADFB90SVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/Support Zafar, Got it. Will be useful if you can clarify this in the section. Thanks Rajan From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Thursday, January 24, 2013 9:28 PM To: Rajan Rao; BRUNGARD, DEBORAH A; ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 = WG document Rajan: RFC3209 covers this. Specifically a path change is triggered on the fly (no= need to wait for refresh). I am cutting and pasting some relevant text fro= m Section 4.4.3 of RFC3209. "An RSVP router can decide to send Path messages before its refresh time if the RRO in the next Path message is different from the previous one. This can happen if the contents of the RRO received from the previous hop router changes or if this RRO is newly added to (or deleted from) the Path message." Thanks Regards...Zafar From: Rajan Rao > Date: Thursday, January 24, 2013 8:03 PM To: "BRUNGARD, DEBORAH A" >, "ccamp@i= etf.org" > Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 = WG document Authors, Question: What is the scheme for informing endpoints for the update case (= sec 2.3)? Is it refresh mechanism or something else? Thanks Rajan From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 10:48 AM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g "yes/support" or "no/do not support". If indicating no, please state your= technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR "still being documente= d". Thanks, Deborah and Lou --_000_650AA355E323C34D9D4AAEED952E053D3FADFB90SVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/Support

 <= /p>

Zafar,<= /p>

 <= /p>

Got it.  Will be use= ful if you can clarify this in the section.

 <= /p>

Thanks<= /p>

Rajan

 <= /p>

From: Zafar Al= i (zali) [mailto:zali@cisco.com]
Sent: Thursday, January 24, 2013 9:28 PM
To: Rajan Rao; BRUNGARD, DEBORAH A; ccamp@ietf.org
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-record= ing-03 WG document

 

Rajan:<= o:p>

&n= bsp;

RFC3209= covers this. Specifically a path change is triggered on the fly (no need t= o wait for refresh). I am cutting and pasting some relevant text from = Section 4.4.3 of RFC3209. 

&n= bsp;

"A= n RSVP router can decide to send Path messages before its refresh

 &nbs=
p; time if the RRO in the next Path message is different from the
 &nbs=
p; previous one.  This can happen if the contents of the RRO received<=
o:p>
 &nbs=
p; from the previous hop router changes or if this RRO is newly added to
 &nbs=
p; (or deleted from) the Path message."

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= …Zafar 

 

 

Authors,

 

Question:  What is t= he scheme for informing endpoints for the update case (sec 2.3)?  &nbs= p;Is it refresh mechanism or something else?

 

Thanks

Rajan

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 10:48 AM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-= 03 WG document

 =

All,

 

This is start a two week po= ll on making draft-ali-ccamp-te-metric-recording-03 a ccamp working group d= ocument. Please send email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your te= chnical reservations with the document.<= o:p>

 

The poll ends Thursday, Feb= . 7th.

 

Note, as stated by some of = the authors, there is IPR “still being documented”.

 

Thanks,

Deborah and Lou

 

 

--_000_650AA355E323C34D9D4AAEED952E053D3FADFB90SVEXDBPROD1infi_-- From zali@cisco.com Fri Jan 25 08:58:02 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1ED521F8946 for ; Fri, 25 Jan 2013 08:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 GKwFlMCRxBuU for ; Fri, 25 Jan 2013 08:58:01 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CC17A21F891C for ; Fri, 25 Jan 2013 08:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18375; q=dns/txt; s=iport; t=1359133080; x=1360342680; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Li/JMVf487BHbJ/Vzv1mJKFRpgQFdQkRyv9p2h2bRh0=; b=DZiWNz3pYjtBRE5bXG7eRGcINAVg1eRwheZ6zY/74dATh3YYYQ0tE1+L kr+5uAooKq9rlahpqUgJC9ID7I/bDMbBf0C3LgorqYpMg0DZrsoN2VUZD wQm8D26BOwkm5MtWwS531RsE3utK89UaKNNu6y+EAkXH3MKe9Ojg9TilV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEi4AlGtJXG+/2dsb2JhbABEgki8CxZzgh4BAQEELV4BCA4DAwEBAQsdORQJCAIEARIIiAe+Wo0Eg1phA6ZVgneBbzU X-IronPort-AV: E=Sophos;i="4.84,539,1355097600"; d="scan'208,217";a="168165982" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jan 2013 16:58:00 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0PGw0Op017180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 16:58:00 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 10:57:59 -0600 From: "Zafar Ali (zali)" To: Rajan Rao , "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: AQHN+rzLhH5htMp+m0CrjJ+QGe3ueZhaqE2A//+tPIA= Date: Fri, 25 Jan 2013 16:57:59 +0000 Message-ID: In-Reply-To: <650AA355E323C34D9D4AAEED952E053D3FADFB90@SV-EXDB-PROD1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.244.54] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D3B3378Bxmbrcdx14ciscocom_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:58:02 -0000 --_000_B6585D85A128FD47857D0FD58D8120D3B3378Bxmbrcdx14ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Rajan: Sure, in a following revision we will add a text referencing Section 4.4.3 = of RFC3209. Thanks Regards =85 Zafar From: Rajan Rao > Date: Friday, January 25, 2013 11:54 AM To: zali >, "BRUNGARD, DEBORAH A" >, "ccamp@ietf.org" > Subject: RE: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 = WG document Yes/Support Zafar, Got it. Will be useful if you can clarify this in the section. Thanks Rajan From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Thursday, January 24, 2013 9:28 PM To: Rajan Rao; BRUNGARD, DEBORAH A; ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 = WG document Rajan: RFC3209 covers this. Specifically a path change is triggered on the fly (no= need to wait for refresh). I am cutting and pasting some relevant text fro= m Section 4.4.3 of RFC3209. "An RSVP router can decide to send Path messages before its refresh time if the RRO in the next Path message is different from the previous one. This can happen if the contents of the RRO received from the previous hop router changes or if this RRO is newly added to (or deleted from) the Path message." Thanks Regards=85Zafar From: Rajan Rao > Date: Thursday, January 24, 2013 8:03 PM To: "BRUNGARD, DEBORAH A" >, "ccamp@i= etf.org" > Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 = WG document Authors, Question: What is the scheme for informing endpoints for the update case (= sec 2.3)? Is it refresh mechanism or something else? Thanks Rajan From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 10:48 AM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g =93yes/support=94 or =93no/do not support=94. If indicating no, please st= ate your technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR =93still being documen= ted=94. Thanks, Deborah and Lou --_000_B6585D85A128FD47857D0FD58D8120D3B3378Bxmbrcdx14ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <398A4BFC5345954794F674EE9EEB8C96@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Rajan: 

Sure, in a following revision we will add a text referencing Section 4.4.3 of RFC320= 9. 

Thanks

Regards =85 Zafar 

From: Rajan Rao <rrao@infinera.com>
Date: Friday, January 25, 2013 11:5= 4 AM
To: zali <zali@cisco.com>, "BRUNGARD, DEBORAH A" <db3546@att.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] Poll on making= draft-ali-ccamp-te-metric-recording-03 WG document

Yes/Support

 

Zafar,

 

Got it.  Will be useful if yo= u can clarify this in the section.

 

Thanks

Rajan

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Thursday, January 24, 2013 9:28 PM
To: Rajan Rao; BRUNGARD, DEBORAH A; ccamp@ietf.org
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-record= ing-03 WG document

 

Rajan:<= o:p>

&n= bsp;

RFC3209= covers this. Specifically a path change is triggered on the fly (no need t= o wait for refresh). I am cutting and pasting some relevant text from = Section 4.4.3 of RFC3209. 

&n= bsp;

"A= n RSVP router can decide to send Path messages before its refresh

   time if the R=
RO in the next Path message is different from the
   previous one.=
  This can happen if the contents of the RRO received
   from the prev=
ious hop router changes or if this RRO is newly added to<=
/pre>

   (or deleted f=
rom) the Path message." 




&n=
bsp;






Thanks<=
o:p>






&n=
bsp;






Regards=
=85Zafar 






 







 








Authors,


 


Question:  What is the scheme=
 for informing endpoints for the update case (sec 2.3)?   Is it r=
efresh mechanism or something else?=



 


Thanks


Rajan


 



 =





All,<=
/o:p>






 






This is start a two week poll on making draft=
-ali-ccamp-te-metric-recording-03 a ccamp working group document. Please se=
nd email to the list indicating =93yes/support=94
 or =93no/do not support=94. If indicating no, please state your technical =
reservations with the document.






 






The poll ends Thursday, Feb7th.






 






Note, as stated by some of the authors, there=
 is IPR =93still being documented=94.






 






Thanks,






Deborah and Lou






 






 
--_000_B6585D85A128FD47857D0FD58D8120D3B3378Bxmbrcdx14ciscocom_-- From db3546@att.com Fri Jan 25 09:26:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F39221F88A6 for ; Fri, 25 Jan 2013 09:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 23wa5kOTg2Ze for ; Fri, 25 Jan 2013 09:26:56 -0800 (PST) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 8460B21F87FA for ; Fri, 25 Jan 2013 09:26:56 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 060c2015.2aaad9c15940.2301096.00-596.6439141.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 25 Jan 2013 17:26:56 +0000 (UTC) X-MXL-Hash: 5102c060363c3b03-ec1d47af01e5a60ce550fdca241d38de77f2e2a1 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id d50c2015.0.2301081.00-350.6439081.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 25 Jan 2013 17:26:55 +0000 (UTC) X-MXL-Hash: 5102c05f52eef061-719a5033993f56591ec166d475baf19ddee3e617 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0PHQqKa005977; Fri, 25 Jan 2013 09:26:52 -0800 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0PHQj3c005840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jan 2013 09:26:47 -0800 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 25 Jan 2013 09:26:38 -0800 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0328.009; Fri, 25 Jan 2013 12:26:37 -0500 From: "BRUNGARD, DEBORAH A" To: Igor Bryskin Thread-Topic: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) Thread-Index: AQHN+aN/JZn1TfD1IEuchRXtbKNUMphX0XcA//+uMOCAAcqdgIABA6mQ Date: Fri, 25 Jan 2013 17:26:35 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51006334.30106@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=WMjIqAQR c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=QlfpTN8ik9gA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=qrvc8Cqe2PkA:10 a=k3smo-zvbe5_L9LZEMQA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 17:26:57 -0000 Igor, >I am not sure what are you agreeing with. You know me long enough to know = that all emails I send on the list are nothing but "technically focused". W= hile you have your "CCAMP Co-Chair hat on" I'd like to communicate with you= as the CCAMP Co-Chair. Let's take this off-list. Deborah From jdrake@juniper.net Fri Jan 25 09:38:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE14021F8746 for ; Fri, 25 Jan 2013 09:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 deCYDbtIhq6J for ; Fri, 25 Jan 2013 09:38:26 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDB721F8436 for ; Fri, 25 Jan 2013 09:38:26 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUQLDEtcavrOMUxr1f6UWMUZ/yK9RgM9G@postini.com; Fri, 25 Jan 2013 09:38:26 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 25 Jan 2013 09:35:46 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 25 Jan 2013 09:35:46 -0800 Received: from CO9EHSOBE009.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 Jan 2013 09:38:13 -0800 Received: from mail35-co9-R.bigfish.com (10.236.132.251) by CO9EHSOBE009.bigfish.com (10.236.130.72) with Microsoft SMTP Server id 14.1.225.23; Fri, 25 Jan 2013 17:35:45 +0000 Received: from mail35-co9 (localhost [127.0.0.1]) by mail35-co9-R.bigfish.com (Postfix) with ESMTP id CD9484E019E for ; Fri, 25 Jan 2013 17:35:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz9371I542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail35-co9 (localhost.localdomain [127.0.0.1]) by mail35-co9 (MessageSwitch) id 1359135343964507_2569; Fri, 25 Jan 2013 17:35:43 +0000 (UTC) Received: from CO9EHSMHS008.bigfish.com (unknown [10.236.132.239]) by mail35-co9.bigfish.com (Postfix) with ESMTP id DFB01320062; Fri, 25 Jan 2013 17:35:43 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS008.bigfish.com (10.236.130.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 25 Jan 2013 17:35:42 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.86]) by BL2PRD0510HT004.namprd05.prod.outlook.com ([10.255.100.39]) with mapi id 14.16.0257.004; Fri, 25 Jan 2013 17:35:37 +0000 From: John E Drake To: "BRUNGARD, DEBORAH A" , Igor Bryskin Thread-Topic: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) Thread-Index: AQHN+br1UqPMu6q7TUuacbogbA/DXJhY9kOAgAFYhoCAAAIXAA== Date: Fri, 25 Jan 2013 17:35:36 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E0B70BA84@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51006334.30106@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ATT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 17:38:27 -0000 I disagree. Airing dirty laundry in public is too entertaining to stop. Irrespectively Yours, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of BRUNGARD, DEBORAH A > Sent: Friday, January 25, 2013 9:27 AM > To: Igor Bryskin > Cc: CCAMP > Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: > Overlay model framework v2) >=20 > Igor, >=20 > >I am not sure what are you agreeing with. You know me long enough to > know that all emails I send on the list are nothing but "technically > focused". While you have your "CCAMP Co-Chair hat on" I'd like to > communicate with you as the CCAMP Co-Chair. >=20 > Let's take this off-list. >=20 > Deborah >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From mhartley@cisco.com Fri Jan 25 09:47:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B1321F874B for ; Fri, 25 Jan 2013 09:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ciMJNM-FGQkd for ; Fri, 25 Jan 2013 09:47:27 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BE3D921F883A for ; Fri, 25 Jan 2013 09:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11871; q=dns/txt; s=iport; t=1359136046; x=1360345646; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=He9hnvhCRA34EpDfBTRSbsDxjzRDFV1A+IdZ5zC0IEg=; b=hZtz15o1P33cYPr8gqVRhhsvL9YeWsznTiE3dNdZDcfFO2KbhdhF0W4m gEdtj5i/9tDKpybQ3AWeUPb1aX6JgSOcB/cMHal8x/YJ+t3wmItFm038E usWZtpWDNfuidRWVOqbADS7JnV3zH7frYNB7f15AqhmwXW53FKj9oY98Z k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUFAG3EAlGtJV2Y/2dsb2JhbABFgkiycAGJGhZzgh4BAQEELUwQAgEIEQQBAQsdBzIUCQgBAQQBDQUIiAcMvkuNBINaYQOXKY8sgneBbzU X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208,217";a="168193216" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jan 2013 17:47:26 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0PHlQxt003136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 17:47:26 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 11:47:26 -0600 From: "Matt Hartley (mhartley)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: Ac36YpzyB19srrPaSouArquCC8tVHQAAKy+AAA6oboAAIYPi8A== Date: Fri, 25 Jan 2013 17:47:25 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC102D60A0@xmb-rcd-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.95] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC102D60A0xmbrcdx03ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 17:47:28 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC102D60A0xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support (as co-author). Cheers Matt From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 2:47 PM To: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a = WG document The draft just expired - the authors will re-post with -03 (no changes). He= re's a link until they do: http://tools.ietf.org/html/draft-ali-ccamp-xro-lsp-subobject-02 From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:51 PM To: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a = WG document Sorry - it's Feb. 7th (my mind is too focused on Super Bowl weekend)- From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:43 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = "yes/support" or "no/do not support". If indicating no, please state your t= echnical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_9D50FCE7413E3D4EA5E42331115FB5BC102D60A0xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/support (as co-au= thor).

 

Cheers

 

Matt

 

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 2:47 PM
To: ccamp@ietf.org
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobjec= t-02 a WG document

 

The draft just expired &#= 8211; the authors will re-post with -03 (no changes). Here’s a link u= ntil they do:

http://tools.ietf.org/ht= ml/draft-ali-ccamp-xro-lsp-subobject-02

 <= /p>

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:51 PM
To: ccamp@ietf.org
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobjec= t-02 a WG document

 

Sorry – it’s = Feb. 7th (my mind is too focused on Super Bowl weekend)-

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:43 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02= a WG document

 

All,

 

This is start a two week poll on making= draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. Pleas= e send email to the list indicating “yes/support” or “no/= do not support”. If indicating no, please state your technical reservat= ions with the document.

 

The poll ends Thursday, January 31st.

 

Note, as stated by some of the authors,= IPR has been disclosed in compliance with IETF IPR rules.

 

Thanks,

Deborah and Lou

 

 

--_000_9D50FCE7413E3D4EA5E42331115FB5BC102D60A0xmbrcdx03ciscoc_-- From mhartley@cisco.com Fri Jan 25 09:49:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274C421F885B for ; Fri, 25 Jan 2013 09:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 8wZ2Y7jxz6Z8 for ; Fri, 25 Jan 2013 09:49:10 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 951AA21F8844 for ; Fri, 25 Jan 2013 09:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7507; q=dns/txt; s=iport; t=1359136150; x=1360345750; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Iiylbm1MaPThzfJi5+8d/C6RLBKasWJG/Wayr4Pqbm0=; b=IJhuzxLiBrLGErbAuUKOhSzUjjsIqFDMbj0L1+av8r8aMUcRzJIiXgtf HNbdqRelkg66npaJ7X/SvpOuGbJT7TswzsIoIr5DU5N+pu1J1d3gCkd/Q 4U93Txd7BxBTzqvS5A7ItDkLMtRos6o5B0NdFfG/dla9CmuU1a8FWc/PX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACzEAlGtJXHB/2dsb2JhbABFgki8CxZzgh4BAQEELUwQAgEIEQQBAQsdBzIUCQgBAQQBDQUIiAe+V40Eg1phA6ZVgneBbzU X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208,217";a="168228098" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jan 2013 17:49:09 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0PHn9Eb011660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 17:49:09 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 11:49:09 -0600 From: "Matt Hartley (mhartley)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: Ac36Y0THF366bQJXRBinToGRQUxfKQAwPpTQ Date: Fri, 25 Jan 2013 17:49:09 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC102D60B8@xmb-rcd-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.95] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC102D60B8xmbrcdx03ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 17:49:12 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC102D60B8xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support (as co-author) Cheers Matt From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:48 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g "yes/support" or "no/do not support". If indicating no, please state your= technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR "still being documente= d". Thanks, Deborah and Lou --_000_9D50FCE7413E3D4EA5E42331115FB5BC102D60B8xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/support (as co-au= thor)

 

Cheers

 

Matt

 

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:48 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-= 03 WG document

 

All,

 

This is start a two week poll on making= draft-ali-ccamp-te-metric-recording-03 a ccamp working group document. Ple= ase send email to the list indicating “yes/support” or “n= o/do not support”. If indicating no, please state your technical reservat= ions with the document.

 

The poll ends Thursday, Feb= . 7th.

 

Note, as stated by some of the authors,= there is IPR “still being documented”.

 

Thanks,

Deborah and Lou

 

 

--_000_9D50FCE7413E3D4EA5E42331115FB5BC102D60B8xmbrcdx03ciscoc_-- From ggalimbe@cisco.com Fri Jan 25 09:58:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8665B21F845E for ; Fri, 25 Jan 2013 09:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 CGKtvXzrqsxj for ; Fri, 25 Jan 2013 09:58:04 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C4CEA21F8200 for ; Fri, 25 Jan 2013 09:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14679; q=dns/txt; s=iport; t=1359136684; x=1360346284; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=52hHXbf8qnaY8KRtD2v0snJTqNVMQuuMWwBq4h8+Cww=; b=DKXRQGem8HFHQ8WjqR1d4w02iQrTpwW6eqsqLvdP1Vm/qKNRNHSm1RnS wVevBEP5LYbZD2rQQFDD6hPteja98PTRhxNaypZdLfjgtKYObGuDpC1QM TzeOMdlBU/xDkPMYKEWdgt0Q2WfGpSwqEYLrGXCrBUbTcqg+aEtCLJPin 8=; X-Files: 273031C1-0F11-4D42-9226-D16B7CB14162[367].png : 1632 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOXGAlGtJV2a/2dsb2JhbABFgki8CxZzgh4BAQEEBSgcPgQBCBEDAQIGAQEBAh0JBRABAwsMFAkIAgQBEQEGAgaIAQy+TgSNAINaYQOQLJYpgneBbzU X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="png'150?scan'150,208,217,150";a="168233120" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jan 2013 17:58:03 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0PHw3v3019623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 17:58:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 11:58:02 -0600 From: "Gabriele Maria Galimberti (ggalimbe)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: AQHN+yWE1YkCP9+drE+K5pVUz2ulMA== Date: Fri, 25 Jan 2013 17:58:02 +0000 Message-ID: <7802FF1A01070C449CCE96E5CD2CC77969D011@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [144.254.166.76] Content-Type: multipart/related; boundary="_004_7802FF1A01070C449CCE96E5CD2CC77969D011xmbrcdx09ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 17:58:04 -0000 --_004_7802FF1A01070C449CCE96E5CD2CC77969D011xmbrcdx09ciscocom_ Content-Type: multipart/alternative; boundary="_000_7802FF1A01070C449CCE96E5CD2CC77969D011xmbrcdx09ciscocom_" --_000_7802FF1A01070C449CCE96E5CD2CC77969D011xmbrcdx09ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable yes/support [http://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Technical Leader Cisco Photonics Srl Via Philips, 12 20900 - Monza (MI) Italy www.cisco.com/global/IT/ ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: , DEBORAH A > Date: Thursday, January 24, 2013 7:47 PM To: "ccamp@ietf.org" > Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g =93yes/support=94 or =93no/do not support=94. If indicating no, please st= ate your technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR =93still being documen= ted=94. Thanks, Deborah and Lou --_000_7802FF1A01070C449CCE96E5CD2CC77969D011xmbrcdx09ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B2ADACEFD506F40B17F05FAE5C3842E@cisco.com> Content-Transfer-Encoding: quoted-printable

yes/support

3D"http://www.cisco.com/swa/i/logo.gif"



Gabriele Galimberti
Technical Leader=
Cisco Photonics Srl


=

Via Philips, 12

20900 - Monza (MI)
Italy
www.cisco.= com/global/IT/


ggalimbe@cisco.com
Phone :+39 039 2091462+39 335 7481947
Fax :+39 039 2092049













From: <BRUNGARD>, DEBORAH A &= lt;db3546@att.com>
Date: Thursday, January 24, 2013 7:= 47 PM
To: "ccamp@ietf.org" <cca= mp@ietf.org>
Subject: [CCAMP] Poll on making dra= ft-ali-ccamp-te-metric-recording-03 WG document

All,
 
This is start a two week poll on making draft-ali-ccamp-te-metric-reco= rding-03 a ccamp working group document. Please send email to the list indi= cating =93yes/support=94 or =93no/do not support=94. If indicating no, plea= se state your technical reservations with the document.
 
The poll ends Thursday, Feb. 7th.
 
Note, as stated by some of the authors, there is IPR =93still being do= cumented=94.
 
Thanks,
Deborah and Lou
 
 
 --_000_7802FF1A01070C449CCE96E5CD2CC77969D011xmbrcdx09ciscocom_-- --_004_7802FF1A01070C449CCE96E5CD2CC77969D011xmbrcdx09ciscocom_ Content-Type: image/png; name="273031C1-0F11-4D42-9226-D16B7CB14162[367].png" Content-Description: 273031C1-0F11-4D42-9226-D16B7CB14162[367].png Content-Disposition: inline; filename="273031C1-0F11-4D42-9226-D16B7CB14162[367].png"; size=1632; creation-date="Fri, 25 Jan 2013 17:58:02 GMT"; modification-date="Fri, 25 Jan 2013 17:58:02 GMT" Content-ID: <4F6446CE-A431-4A61-AF63-9937C660BE4D> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAG4AAABJCAIAAABTkIQiAAAGJ0lEQVR4nO2be0xTVxzHv30gcHk5 bRmKyMCJrhDsNi0xzldikE2dZr5mSEnm/poylxi3ZAuOkhhjspANZ0zUhT9GyNwMzoHDSHD4GEGI QGtGAQ10iEyg1a1Cy50tdH9cd7kqRVp+5WHO54/m9HDOl3M+nHvP6W2QeTweMCiQT/YAXhyYSjKY SjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjImQWXLnXvTOt8bE62yxtz2 XfnvNea2aZo/CsoJ/n0lVxsqG5sBLNcsmI75ozDRq1KYp/A6HfNHgW07ZDCVZDCVZARQpa+HkqnW 3lcCpdLXQ8lUa+8HgToM+XoomWrt/SBQq9LXQ8lUa+8HBCqn+wdBqvzxqpzuHwQJ88d7r/yooBhA ZWOz8cSX4x/NtM5n50oymEoymEoyxqty3euvia9jqafKCXS+H4x329m66g3xdSz1VDmBzveD8apc rlnwUji3eP6cMdZT5QQ63w8I7pXexjFi/SgXlE85E5DvKxP9hQThBTUp+aMgm/h/Nmm5c49qIUxK vjcmQeWLCjtXksFUkhHYbeevy5fF8tw1a8g7jqWZ32PwlYCodPN8x5Wrt4qL79fXO81NADhNctL2 bTqDwTM4KFMoANQZDMa8PADa3NxlBw8KlQBsLa2N3x7ruVwldnx5zdoVhlxOrRoxn7daAYSo1Unb t2kPfDojPExs1lVb13Wh3FJRaa+plqujI15dmJC+LvH9XarFiwIxa3qVbp5vOHnK+Mk+aaXT3HS3 PlEHeAAZgCf3useVgK2l9dLuD+011dKOFnPTss8OcFBJ828eOjRk7R1uZu29W5+YMjAgqmy7WFGz f7/w9wAwZO21W3uNNdW3z/2y9puvA7E86VU+5TFsiVbJhUntAIBM9mxHz+Bge0WF2DJOn6WMiATw oLFxBje81hpOnmr4/Au5sx8AgoLCNMlKLsx+o04a1VVbdyljvbRGro4W1DtMxt/2ZmeUlJCvTWKV TqvtdmGh+FZbcDQxPR2AvaPjkd2O/1ffiLgGeHvrLaGs2rhpdX6+cFE7rbbgmVHSfMGjXB2dmpMj zVeGhgJw87z5+yIxNmFPdvL2rQCazpRYTp2Ay+U0N7Wf/kFlMFDOnFxlR1WVw2QUytqCo7p9Hwtl cQmI98QRhhIaEqWeLZRt58uqDXnzVq+ak6abGR8vzf/3TwsABAWl5uQ8ne/xAOjv6bEcPybUJ+zJ Xpv/lTIkBMDM5BR338POou8BWCoqddQqiQ9Dfd3dYjll1y7fhqJQxL79jvjWcvzYtZ07ft28pfmn M9J8t9MJQMlxI+TLZAAc3T1ihSZLL3gEwKlVSZmZCAoCwHfTf/UWwHOlcLn5xNylb264XqvauEms cZiM13buaLtYQZIfUIhVRsTEiOW28nJfu8sUitg03ZZzP2+4XqvNzRXr20vLPIODQr6S4wC4nU5v +cFRUWK560K50BHAo35He2kZXC4AyshIX8f2XIhVqlNTw5ZohXLD4cNtFyucVpvTarO1tHbV1gEQ JzYCHo+b5908LwNi03S63Fxxebr7Hg4NDQn5wa8kAIDL9Wy+m+cBRM6bF6fPEjoa8/JaSs46rbZ/ OjqMhYWdxY+3o+gVb9FOHOTbjmrxooVbNhtNRgAOk/FSxnpBx0BnZ2hc3HtlpR7vm/ig2327tOzu latRi5IA4MF92/myx6OMiJTL5cP55ia4XA6TsUqvn5WWJuZnFBYqQ0JmhIct2f2BsL0AuLZzx83l KwDYb9QJSzI4IVGTpaedOAJxrkzZm32/3SLORNQRGhc33MjL46g+c5O4+YpwmmRNll7c+oX8jpKz cmf/kLV3xPyYlSu1BUfF4630VBuckKg7ciQ2Tefv/LxCr5JTq1bn5/+xdKnl9I/SOUTMj4eXJSlU yuVyzJr91I/i9FlJmZnSmUvz/zaZhDPmEBceMT9e3IjkCsWyvXsiYmKai4qGl3ZU1Jx3NydlZi5Y n0412SdmEdDnlX48SpB2eW6vKfU4gz36JYM9rySDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSD qSSDqSSDqSSDqSSDqSTjP8P5+2z4huMfAAAAAElFTkSuQmCC --_004_7802FF1A01070C449CCE96E5CD2CC77969D011xmbrcdx09ciscocom_-- From ggalimbe@cisco.com Fri Jan 25 10:10:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0173221F884B for ; Fri, 25 Jan 2013 10:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 r4pZrfukP2AP for ; Fri, 25 Jan 2013 10:10:25 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EFAEA21F8831 for ; Fri, 25 Jan 2013 10:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21758; q=dns/txt; s=iport; t=1359137417; x=1360347017; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Ttv5UXUCmDsysqfI0cRvNbGaVy5G8CfOW+ifcdkZcXc=; b=hRzfVDaLzrPj3VJUtlzoo+6zGXbaZMIuqxXGr4c7jriCQdLxHD2HiDN1 Ne2LncJWnnb2YEUI8c6d3XeZjx+GTH9lA2jpWxUebD6X0FEFHc/t0lrqG KGAGAHrYynSu4T65KZCgSdAisfLYbt73NAvoDj6UHKMVm1BEmWCZHMPR2 I=; X-Files: 273031C1-0F11-4D42-9226-D16B7CB14162[369].png : 1632 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAHLJAlGtJV2c/2dsb2JhbABFgkiycAGJGhZzgh4BAQEEBSgcPgQBCBEDAQEBBgEBAQIWBwkFEAEDCwwUCQgCBAERAQYCBogBDL5UBI0Ag1phA5Ashn2PLIJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="png'150?scan'150,208,217,150";a="167992614" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jan 2013 18:10:16 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0PIAGuC008745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 18:10:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 12:10:16 -0600 From: "Gabriele Maria Galimberti (ggalimbe)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: AQHN+yc5V8Vd0Zc9sEGsK9vssdBTAw== Date: Fri, 25 Jan 2013 18:10:15 +0000 Message-ID: <7802FF1A01070C449CCE96E5CD2CC77969D0A9@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [144.254.166.76] Content-Type: multipart/related; boundary="_004_7802FF1A01070C449CCE96E5CD2CC77969D0A9xmbrcdx09ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:10:27 -0000 --_004_7802FF1A01070C449CCE96E5CD2CC77969D0A9xmbrcdx09ciscocom_ Content-Type: multipart/alternative; boundary="_000_7802FF1A01070C449CCE96E5CD2CC77969D0A9xmbrcdx09ciscocom_" --_000_7802FF1A01070C449CCE96E5CD2CC77969D0A9xmbrcdx09ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable yes/support [http://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Technical Leader Cisco Photonics Srl Via Philips, 12 20900 - Monza (MI) Italy www.cisco.com/global/IT/ ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: , DEBORAH A > Date: Thursday, January 24, 2013 8:47 PM To: "ccamp@ietf.org" > Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a = WG document The draft just expired =96 the authors will re-post with -03 (no changes). = Here=92s a link until they do: http://tools.ietf.org/html/draft-ali-ccamp-xro-lsp-subobject-02 From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:51 PM To: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a = WG document Sorry =96 it=92s Feb. 7th (my mind is too focused on Super Bowl weekend)- From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:43 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = =93yes/support=94 or =93no/do not support=94. If indicating no, please stat= e your technical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_7802FF1A01070C449CCE96E5CD2CC77969D0A9xmbrcdx09ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
yes/suppo= rt

3D"http://www.cisco.com/swa/i/logo.gif"



Gabriele Galimberti
Technical Leader=
Cisco Photonics Srl


=

Via Philips, 12

20900 - Monza (MI)
Italy
www.cisco.= com/global/IT/


ggalimbe@cisco.com
Phone :+39 039 2091462+39 335 7481947
Fax :+39 039 2092049













From: <BRUNGARD>, DEBORAH A &= lt;db3546@att.com>
Date: Thursday, January 24, 2013 8:= 47 PM
To: "ccamp@ietf.org" <cca= mp@ietf.org>
Subject: Re: [CCAMP] Poll on making= draft-ali-ccamp-xro-lsp-subobject-02 a WG document

The draft just expired =96 the aut= hors will re-post with -03 (no changes). Here=92s a link until they do:

http://tools.ietf.org/html/draft-= ali-ccamp-xro-lsp-subobject-02

 

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:51 PM
To: ccamp@ietf.org
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobjec= t-02 a WG document

 

Sorry =96 it=92s Feb. 7th (my mind is too focused on Super Bowl weekend)-

 

From:ccamp-b= ounces@ietf.org [mailto:ccamp= -bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:43 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02= a WG document

 

All,

 

This is start a two week poll on making draft-ali-ccamp-xro= -lsp-subobject-02 a ccamp working group document. Please send email to the = list indicating =93yes/support=94 or =93no/do not support=94. If indicating no, please state your technical reservations= with the document.

 

The poll ends Thursday, January 31st.

 

Note, as stated by some of the authors, IPR has been disclo= sed in compliance with IETF IPR rules.

 

Thanks,

Deborah and Lou

 

 

 --_000_7802FF1A01070C449CCE96E5CD2CC77969D0A9xmbrcdx09ciscocom_-- --_004_7802FF1A01070C449CCE96E5CD2CC77969D0A9xmbrcdx09ciscocom_ Content-Type: image/png; name="273031C1-0F11-4D42-9226-D16B7CB14162[369].png" Content-Description: 273031C1-0F11-4D42-9226-D16B7CB14162[369].png Content-Disposition: inline; filename="273031C1-0F11-4D42-9226-D16B7CB14162[369].png"; size=1632; creation-date="Fri, 25 Jan 2013 18:10:15 GMT"; modification-date="Fri, 25 Jan 2013 18:10:15 GMT" Content-ID: <9F43E97A-3BA5-499D-8DCD-45E4C2C5BD19> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAG4AAABJCAIAAABTkIQiAAAGJ0lEQVR4nO2be0xTVxzHv30gcHk5 bRmKyMCJrhDsNi0xzldikE2dZr5mSEnm/poylxi3ZAuOkhhjspANZ0zUhT9GyNwMzoHDSHD4GEGI QGtGAQ10iEyg1a1Cy50tdH9cd7kqRVp+5WHO54/m9HDOl3M+nHvP6W2QeTweMCiQT/YAXhyYSjKY SjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjImQWXLnXvTOt8bE62yxtz2 XfnvNea2aZo/CsoJ/n0lVxsqG5sBLNcsmI75ozDRq1KYp/A6HfNHgW07ZDCVZDCVZARQpa+HkqnW 3lcCpdLXQ8lUa+8HgToM+XoomWrt/SBQq9LXQ8lUa+8HBCqn+wdBqvzxqpzuHwQJ88d7r/yooBhA ZWOz8cSX4x/NtM5n50oymEoymEoyxqty3euvia9jqafKCXS+H4x329m66g3xdSz1VDmBzveD8apc rlnwUji3eP6cMdZT5QQ63w8I7pXexjFi/SgXlE85E5DvKxP9hQThBTUp+aMgm/h/Nmm5c49qIUxK vjcmQeWLCjtXksFUkhHYbeevy5fF8tw1a8g7jqWZ32PwlYCodPN8x5Wrt4qL79fXO81NADhNctL2 bTqDwTM4KFMoANQZDMa8PADa3NxlBw8KlQBsLa2N3x7ruVwldnx5zdoVhlxOrRoxn7daAYSo1Unb t2kPfDojPExs1lVb13Wh3FJRaa+plqujI15dmJC+LvH9XarFiwIxa3qVbp5vOHnK+Mk+aaXT3HS3 PlEHeAAZgCf3useVgK2l9dLuD+011dKOFnPTss8OcFBJ828eOjRk7R1uZu29W5+YMjAgqmy7WFGz f7/w9wAwZO21W3uNNdW3z/2y9puvA7E86VU+5TFsiVbJhUntAIBM9mxHz+Bge0WF2DJOn6WMiATw oLFxBje81hpOnmr4/Au5sx8AgoLCNMlKLsx+o04a1VVbdyljvbRGro4W1DtMxt/2ZmeUlJCvTWKV TqvtdmGh+FZbcDQxPR2AvaPjkd2O/1ffiLgGeHvrLaGs2rhpdX6+cFE7rbbgmVHSfMGjXB2dmpMj zVeGhgJw87z5+yIxNmFPdvL2rQCazpRYTp2Ay+U0N7Wf/kFlMFDOnFxlR1WVw2QUytqCo7p9Hwtl cQmI98QRhhIaEqWeLZRt58uqDXnzVq+ak6abGR8vzf/3TwsABAWl5uQ8ne/xAOjv6bEcPybUJ+zJ Xpv/lTIkBMDM5BR338POou8BWCoqddQqiQ9Dfd3dYjll1y7fhqJQxL79jvjWcvzYtZ07ft28pfmn M9J8t9MJQMlxI+TLZAAc3T1ihSZLL3gEwKlVSZmZCAoCwHfTf/UWwHOlcLn5xNylb264XqvauEms cZiM13buaLtYQZIfUIhVRsTEiOW28nJfu8sUitg03ZZzP2+4XqvNzRXr20vLPIODQr6S4wC4nU5v +cFRUWK560K50BHAo35He2kZXC4AyshIX8f2XIhVqlNTw5ZohXLD4cNtFyucVpvTarO1tHbV1gEQ JzYCHo+b5908LwNi03S63Fxxebr7Hg4NDQn5wa8kAIDL9Wy+m+cBRM6bF6fPEjoa8/JaSs46rbZ/ OjqMhYWdxY+3o+gVb9FOHOTbjmrxooVbNhtNRgAOk/FSxnpBx0BnZ2hc3HtlpR7vm/ig2327tOzu latRi5IA4MF92/myx6OMiJTL5cP55ia4XA6TsUqvn5WWJuZnFBYqQ0JmhIct2f2BsL0AuLZzx83l KwDYb9QJSzI4IVGTpaedOAJxrkzZm32/3SLORNQRGhc33MjL46g+c5O4+YpwmmRNll7c+oX8jpKz cmf/kLV3xPyYlSu1BUfF4630VBuckKg7ciQ2Tefv/LxCr5JTq1bn5/+xdKnl9I/SOUTMj4eXJSlU yuVyzJr91I/i9FlJmZnSmUvz/zaZhDPmEBceMT9e3IjkCsWyvXsiYmKai4qGl3ZU1Jx3NydlZi5Y n0412SdmEdDnlX48SpB2eW6vKfU4gz36JYM9rySDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSD qSSDqSSDqSSDqSSDqSTjP8P5+2z4huMfAAAAAElFTkSuQmCC --_004_7802FF1A01070C449CCE96E5CD2CC77969D0A9xmbrcdx09ciscocom_-- From ggrammel@juniper.net Fri Jan 25 10:38:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5561D21F84CA for ; Fri, 25 Jan 2013 10:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 wUD6IW4B5tqO for ; Fri, 25 Jan 2013 10:38:07 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id B997321F8432 for ; Fri, 25 Jan 2013 10:38:07 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUQLRDy3uF0qVxgTy9qWXUhhWKRzaeZdq@postini.com; Fri, 25 Jan 2013 10:38:07 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 25 Jan 2013 10:36:27 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 25 Jan 2013 10:36:27 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 Jan 2013 10:38:48 -0800 Received: from mail157-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Fri, 25 Jan 2013 18:36:20 +0000 Received: from mail157-ch1 (localhost [127.0.0.1]) by mail157-ch1-R.bigfish.com (Postfix) with ESMTP id C470C3603DD for ; Fri, 25 Jan 2013 18:36:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz9371I542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail157-ch1 (localhost.localdomain [127.0.0.1]) by mail157-ch1 (MessageSwitch) id 1359138978762454_13208; Fri, 25 Jan 2013 18:36:18 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail157-ch1.bigfish.com (Postfix) with ESMTP id 8C9422A00C2; Fri, 25 Jan 2013 18:36:18 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 25 Jan 2013 18:36:16 +0000 Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.8.63]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0257.004; Fri, 25 Jan 2013 18:36:15 +0000 From: Gert Grammel To: John E Drake , "BRUNGARD, DEBORAH A" , Igor Bryskin Thread-Topic: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) Thread-Index: AQHN+aObNzC8bMBQG0O9Bkbw+p4ZKZhXfaUAgAAEzACAAXQBgIABWIaAgAAChQCAABDxXg== Date: Fri, 25 Jan 2013 18:36:14 +0000 Message-ID: <305443B66F0CD946A3107753337A031113F92E95@CH1PRD0511MB431.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51006334.30106@labn.net> , <0182DEA5604B3A44A2EE61F3EE3ED69E0B70BA84@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E0B70BA84@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ATT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:38:08 -0000 Hi John, Would you mind to draft the charter for a dirty laundry BOF? Guess we are still in time for the next IETF. Gert ________________________________________ From: ccamp-bounces@ietf.org on behalf of John E Drake Sent: Friday, January 25, 2013 6:35:36 PM To: BRUNGARD, DEBORAH A; Igor Bryskin Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Over= lay model framework v2) I disagree. Airing dirty laundry in public is too entertaining to stop. Irrespectively Yours, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of BRUNGARD, DEBORAH A > Sent: Friday, January 25, 2013 9:27 AM > To: Igor Bryskin > Cc: CCAMP > Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: > Overlay model framework v2) > > Igor, > > >I am not sure what are you agreeing with. You know me long enough to > know that all emails I send on the list are nothing but "technically > focused". While you have your "CCAMP Co-Chair hat on" I'd like to > communicate with you as the CCAMP Co-Chair. > > Let's take this off-list. > > Deborah > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Fri Jan 25 10:56:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4C921F8795 for ; Fri, 25 Jan 2013 10:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 uO2YnSoI3ghu for ; Fri, 25 Jan 2013 10:56:03 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 3470B21F8782 for ; Fri, 25 Jan 2013 10:56:02 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUQLVOs1/gfy9FltLnHlK3cc/6eEcrdIl@postini.com; Fri, 25 Jan 2013 10:56:02 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 25 Jan 2013 10:54:35 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 25 Jan 2013 10:54:35 -0800 Received: from CH1EHSOBE020.bigfish.com (216.32.181.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 Jan 2013 11:02:33 -0800 Received: from mail89-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Fri, 25 Jan 2013 18:54:34 +0000 Received: from mail89-ch1 (localhost [127.0.0.1]) by mail89-ch1-R.bigfish.com (Postfix) with ESMTP id 66773800CC for ; Fri, 25 Jan 2013 18:54:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz9371I542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail89-ch1 (localhost.localdomain [127.0.0.1]) by mail89-ch1 (MessageSwitch) id 1359140072812185_23562; Fri, 25 Jan 2013 18:54:32 +0000 (UTC) Received: from CH1EHSMHS033.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail89-ch1.bigfish.com (Postfix) with ESMTP id C313E100046; Fri, 25 Jan 2013 18:54:32 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 25 Jan 2013 18:54:32 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.86]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0257.004; Fri, 25 Jan 2013 18:54:31 +0000 From: John E Drake To: Gert Grammel , "BRUNGARD, DEBORAH A" , Igor Bryskin Thread-Topic: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) Thread-Index: AQHN+br1UqPMu6q7TUuacbogbA/DXJhY9kOAgAFYhoCAAAIXAIAAEV8AgAAE80A= Date: Fri, 25 Jan 2013 18:54:31 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E0B70BCCB@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <50F985EC.1050704@labn.net> <4A1562797D64E44993C5CBF38CF1BE4806E708@ESESSMB301.ericsson.se> <50FDBD5B.6030307@labn.net> <50FEB554.6010907@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70806B@BL2PRD0510MB349.namprd05.prod.outlook.com> <50FEC37F.8090605@labn.net> <13c634f0092.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51000024.8010700@labn.net> <13c6884e536.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <51006334.30106@labn.net> , <0182DEA5604B3A44A2EE61F3EE3ED69E0B70BA84@BL2PRD0510MB349.namprd05.prod.outlook.com> <305443B66F0CD946A3107753337A031113F92E95@CH1PRD0511MB431.namprd05.prod.outlook.com> In-Reply-To: <305443B66F0CD946A3107753337A031113F92E95@CH1PRD0511MB431.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ATT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: Overlay model framework v2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:56:04 -0000 What a great idea. Pet Peeves and Grievances too! Irrespectively Yours, John > -----Original Message----- > From: Gert Grammel > Sent: Friday, January 25, 2013 10:36 AM > To: John E Drake; BRUNGARD, DEBORAH A; Igor Bryskin > Cc: CCAMP > Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: > Overlay model framework v2) >=20 > Hi John, >=20 > Would you mind to draft the charter for a dirty laundry BOF? >=20 > Guess we are still in time for the next IETF. >=20 > Gert > ________________________________________ > From: ccamp-bounces@ietf.org on behalf of John E Drake > Sent: Friday, January 25, 2013 6:35:36 PM > To: BRUNGARD, DEBORAH A; Igor Bryskin > Cc: CCAMP > Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: Re: > Overlay model framework v2) >=20 > I disagree. Airing dirty laundry in public is too entertaining to > stop. >=20 > Irrespectively Yours, >=20 > John >=20 >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of BRUNGARD, DEBORAH A > > Sent: Friday, January 25, 2013 9:27 AM > > To: Igor Bryskin > > Cc: CCAMP > > Subject: Re: [CCAMP] Additional overlay protocol extensions? (Was: > Re: > > Overlay model framework v2) > > > > Igor, > > > > >I am not sure what are you agreeing with. You know me long enough to > > know that all emails I send on the list are nothing but "technically > > focused". While you have your "CCAMP Co-Chair hat on" I'd like to > > communicate with you as the CCAMP Co-Chair. > > > > Let's take this off-list. > > > > Deborah > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From tsaad@cisco.com Fri Jan 25 11:31:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF4621F87F5 for ; Fri, 25 Jan 2013 11:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 qkwinw8+HbzA for ; Fri, 25 Jan 2013 11:31:11 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C10F221F8AB0 for ; Fri, 25 Jan 2013 11:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3587; q=dns/txt; s=iport; t=1359142272; x=1360351872; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Qoal5bVUE3OgHqbAJ8yxZvvmrJW6+ODx7dkUEFWFYok=; b=ZA1rBUzzm8n8F1rSsjOeJa+/ykoyz3wD3Vmmg8X8F/TIlq42rJDVBoti LY+WZb5gbK5Z4hNnPqaBAD4vNawvbF/cYdNAjmkuQI7L9oYGDt7J7Y63z AcpABNkpkzagxKSXtyLTNhkIVyhYB+2eif3gLRgUMDhrUTcKHCcaUAai3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAE7cAlGtJV2a/2dsb2JhbABFgki8CxZzgh4BAQEELV4BCAQNAwECCx05FAkIAgQBEgiIB75xjQSDWmEDplWCd4FvNQ X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208,217";a="168245897" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jan 2013 19:31:11 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0PJVB7R008144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 19:31:11 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.107]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 13:31:11 -0600 From: "Tarek Saad (tsaad)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: AQHN+zKHA/mvBIiz/kOY/e6OiAUzOQ== Date: Fri, 25 Jan 2013 19:31:10 +0000 Message-ID: <2170E89B881FEA48B3A35413AB6FC4300FA09A83@xmb-aln-x08.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [161.44.213.207] Content-Type: multipart/alternative; boundary="_000_2170E89B881FEA48B3A35413AB6FC4300FA09A83xmbalnx08ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:31:13 -0000 --_000_2170E89B881FEA48B3A35413AB6FC4300FA09A83xmbalnx08ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes/support. Thanks, Tarek From: , DEBORAH A > Date: Thursday, January 24, 2013 1:42 PM To: "ccamp@ietf.org" > Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = =93yes/support=94 or =93no/do not support=94. If indicating no, please stat= e your technical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_2170E89B881FEA48B3A35413AB6FC4300FA09A83xmbalnx08ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Yes/support.

Thanks,
Tarek

From: <BRUNGARD>, DEBORAH A &= lt;db3546@att.com>
Date: Thursday, January 24, 2013 1:= 42 PM
To: "ccamp@ietf.org" <cca= mp@ietf.org>
Subject: [CCAMP] Poll on making dra= ft-ali-ccamp-xro-lsp-subobject-02 a WG document

All,
 
This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobj= ect-02 a ccamp working group document. Please send email to the list indica= ting =93yes/support=94 or =93no/do not support=94. If indicating no, please= state your technical reservations with the document.
 
The poll ends Thursday, January 31st.
 
Note, as stated by some of the authors, IPR has been disclosed in comp= liance with IETF IPR rules.
 
Thanks,
Deborah and Lou
 
 
 --_000_2170E89B881FEA48B3A35413AB6FC4300FA09A83xmbalnx08ciscoc_-- From msiva@cisco.com Fri Jan 25 11:39:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6DA21F8745 for ; Fri, 25 Jan 2013 11:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 0mPRSc7jnlYk for ; Fri, 25 Jan 2013 11:39:19 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D9CBD21F863C for ; Fri, 25 Jan 2013 11:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6575; q=dns/txt; s=iport; t=1359142759; x=1360352359; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=mTgBg3LVf/7BAUDYaRdx0uzpUzvNp3u/1gOjuylK7t0=; b=YL1ASf1gLSEHrgoPb+EZRrYbFCuLQjWURFN4+6W9u4DbuSwqRhGq4jMG hjseRwUagpizNBFcWCnOgntW4Ab8MaSZ+6BfsF6EoVdXS7jFfKOCOXBls sKsSReJlHbCL89t/TkBILNBgzwS3qc4m43G206VeURlQD+D4YVFgBsSDN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKneAlGtJXG//2dsb2JhbABFgki8CxZzgh4BAQEELVwCAQgRBAEBCx0HMhQJCAEBBAESCIgHvnCNBINaYQOmVYJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208,217";a="168252929" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 25 Jan 2013 19:39:18 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0PJdIx0005592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 19:39:18 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.125]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 13:39:18 -0600 From: "Siva Sivabalan (msiva)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: Ac36YpzyB19srrPaSouArquCC8tVHQA0P9aw Date: Fri, 25 Jan 2013 19:39:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.235] Content-Type: multipart/alternative; boundary="_000_E2529AC6415F6B4197901F2B67212E9A12107Axmbrcdx13ciscocom_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:39:20 -0000 --_000_E2529AC6415F6B4197901F2B67212E9A12107Axmbrcdx13ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes/support. From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:43 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = "yes/support" or "no/do not support". If indicating no, please state your t= echnical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_E2529AC6415F6B4197901F2B67212E9A12107Axmbrcdx13ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

yes/support.

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:43 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02= a WG document

 

All,

 

This is start a two week poll on making= draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. Pleas= e send email to the list indicating “yes/support” or “no/= do not support”. If indicating no, please state your technical reservat= ions with the document.

 

The poll ends Thursday, January 31st.

 

Note, as stated by some of the authors,= IPR has been disclosed in compliance with IETF IPR rules.

 

Thanks,

Deborah and Lou

 

 

--_000_E2529AC6415F6B4197901F2B67212E9A12107Axmbrcdx13ciscocom_-- From rrahman@cisco.com Fri Jan 25 11:51:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615EF21F84D8 for ; Fri, 25 Jan 2013 11:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 A34roL4MBMo6 for ; Fri, 25 Jan 2013 11:51:06 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D4BB721F84D1 for ; Fri, 25 Jan 2013 11:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7437; q=dns/txt; s=iport; t=1359143466; x=1360353066; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=V1Md99Xie3BiA8BSqAPXe3f7IzGTof0J1GEoVZkKsQU=; b=gdnQ/FLEMuLF4Av0myCce+BsAS5Y9x8+hn1W0Zq5KHrsSSgMzjTI5Kci ZLJINygtjNCxN8ZH3N2eGhQffz7kLRuoLpijmaOwvP+QqZd21GYMHowJs K2XwdwAj6TB9ZIcwhumTPjb+ravyyKBrtwfxzeSPzUuOaVhIi8Lk+c4pr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMrhAlGtJXG8/2dsb2JhbABFgki8CxZzgh4BAQEELVwCAQgRAwECCx0HMhQJCAIEARIIiAe+aY0Eg1phA6ZVgneBbzU X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208,217";a="168289986" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jan 2013 19:51:05 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0PJp5Xi003884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 19:51:05 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 13:51:04 -0600 From: "Reshad Rahman (rrahman)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: AQHN+zKOJSvgiyeXLkOWjiZ61xC0z5hadABg Date: Fri, 25 Jan 2013 19:51:03 +0000 Message-ID: <21C6C799DE4CA442891D3EF732AA1F4C105D7129@xmb-rcd-x03.cisco.com> References: <2170E89B881FEA48B3A35413AB6FC4300FA09A83@xmb-aln-x08.cisco.com> In-Reply-To: <2170E89B881FEA48B3A35413AB6FC4300FA09A83@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.39] Content-Type: multipart/alternative; boundary="_000_21C6C799DE4CA442891D3EF732AA1F4C105D7129xmbrcdx03ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:51:08 -0000 --_000_21C6C799DE4CA442891D3EF732AA1F4C105D7129xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. From: , DEBORAH A > Date: Thursday, January 24, 2013 1:42 PM To: "ccamp@ietf.org" > Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = "yes/support" or "no/do not support". If indicating no, please state your t= echnical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_21C6C799DE4CA442891D3EF732AA1F4C105D7129xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

From: <BRUNGARD>, DEBORAH A <db3546@att.com>
Date: Thursday, January 24, 2013 1:42 PM
To: "ccamp@ietf.org"= <ccamp@ietf.org>
Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02= a WG document

 

All,

 

This is start a two week po= ll on making draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group doc= ument. Please send email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your te= chnical reservations with the document.

 

The poll ends Thursday, Jan= uary 31st.

 

Note, as stated by some of = the authors, IPR has been disclosed in compliance with IETF IPR rules.=

 

Thanks,

Deborah and Lou<= /span>

 

 

--_000_21C6C799DE4CA442891D3EF732AA1F4C105D7129xmbrcdx03ciscoc_-- From rgandhi@cisco.com Fri Jan 25 11:59:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1180121F886C for ; Fri, 25 Jan 2013 11:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 AnszAenuCGZN for ; Fri, 25 Jan 2013 11:59:40 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A6E1621F886A for ; Fri, 25 Jan 2013 11:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12677; q=dns/txt; s=iport; t=1359143980; x=1360353580; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=v45fUQkrgmcUCRo34p+10ShISFXhqeURoqYXhcCjxJo=; b=jpNS71TRj8zoAfqiFGS3z40z2VVvw9+XJ5F0RfB7leX7ZbxmA1XwSK/s OfjCeuob/f9ridKFmn1r4aQR6vri/28fY9G1kmYy204zRzzLvIXuKm39L u/naOPe7rJoxuQJtmnlH9kleEW1362dQQ5QTCh79Kk/3BZRMVkBXJY/3i E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUFAKTiAlGtJXHB/2dsb2JhbABFgkiycAGJGhZzgh4BAQEELVwCAQgRAwEBAQsdBzIUCQgCBAESCIgHDL5XjQSDWmEDlymPLIJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208,217";a="168259870" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jan 2013 19:59:40 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0PJxenp022555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 19:59:40 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.12]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 13:59:39 -0600 From: "Rakesh Gandhi (rgandhi)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: AQHN+ydGKbznfQsbP0Cm/+rOwi2bZ5hadnZA Date: Fri, 25 Jan 2013 19:59:39 +0000 Message-ID: References: <7802FF1A01070C449CCE96E5CD2CC77969D0A9@xmb-rcd-x09.cisco.com> In-Reply-To: <7802FF1A01070C449CCE96E5CD2CC77969D0A9@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.244.218] Content-Type: multipart/alternative; boundary="_000_B7D2A316AA32B6469D9670B6A81B7C241F16A3xmbalnx07ciscocom_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:59:42 -0000 --_000_B7D2A316AA32B6469D9670B6A81B7C241F16A3xmbalnx07ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/Support. From: , DEBORAH A > Date: Thursday, January 24, 2013 8:47 PM To: "ccamp@ietf.org" > Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a = WG document The draft just expired - the authors will re-post with -03 (no changes). He= re's a link until they do: http://tools.ietf.org/html/draft-ali-ccamp-xro-lsp-subobject-02 From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:51 PM To: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a = WG document Sorry - it's Feb. 7th (my mind is too focused on Super Bowl weekend)- From:ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:43 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = "yes/support" or "no/do not support". If indicating no, please state your t= echnical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_B7D2A316AA32B6469D9670B6A81B7C241F16A3xmbalnx07ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/Support.

 <= /p>

 

From: <BRUNGARD>, DEBORAH A <db3546@att.com>
Date: Thursday, January 24, 2013 8:47 PM
To: "ccamp@ietf.org"= <ccamp@ietf.org>
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobjec= t-02 a WG document

 

The draft just expired &#= 8211; the authors will re-post with -03 (no changes). Here’s a link u= ntil they do:

http://tools.ietf.org/ht= ml/draft-ali-ccamp-xro-lsp-subobject-02

 

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:51 PM
To: ccamp@ietf.org
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobjec= t-02 a WG document

 =

Sorry – it’s = Feb. 7th (my mind is too focused on Super Bowl weekend)-<= span style=3D"color:black">

 

 =

All,

 

This is start a two week po= ll on making draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group doc= ument. Please send email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your te= chnical reservations with the document.<= o:p>

 

The poll ends Thursday, Jan= uary 31st.

 

Note, as stated by some of = the authors, IPR has been disclosed in compliance with IETF IPR rules.

 

Thanks,

Deborah and Lou

 

 

--_000_B7D2A316AA32B6469D9670B6A81B7C241F16A3xmbalnx07ciscocom_-- From rgandhi@cisco.com Fri Jan 25 11:59:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB6F21F8884 for ; Fri, 25 Jan 2013 11:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 F74ELUHVnmC8 for ; Fri, 25 Jan 2013 11:59:46 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B416D21F887F for ; Fri, 25 Jan 2013 11:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7823; q=dns/txt; s=iport; t=1359143986; x=1360353586; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=+4EgutSL+EsjBEKF41n+xNU9h59GcX+nUgK14qk6oZw=; b=FdiYss3LXTBql1JyoRfHQbO1iJlg8AeM6heZtImDrYe4fTkGfTnb2k9u a/76PhiK04dDjwEpRRgvor+Ci2h5YsCrNTgXowc518UkAxez7l6viBZOJ WsYXgfVr1TsHv1me6TCzIi+6kFMTvePaMlZ4pt3uXcwLOzZ0aCNI7qTDO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAErjAlGtJXG//2dsb2JhbABFgki8CxZzgh4BAQEELVwCAQgRAwECCx0HMhQJCAIEARIIiAe+XY0Eg1phA6ZVgneBbzU X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208,217";a="168237306" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jan 2013 19:59:46 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0PJxkg9024417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 19:59:46 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.12]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 13:59:46 -0600 From: "Rakesh Gandhi (rgandhi)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: AQHN+yWKn+J8EcvaM028cBBKDHN/R5hadlcQ Date: Fri, 25 Jan 2013 19:59:45 +0000 Message-ID: References: <7802FF1A01070C449CCE96E5CD2CC77969D011@xmb-rcd-x09.cisco.com> In-Reply-To: <7802FF1A01070C449CCE96E5CD2CC77969D011@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.244.218] Content-Type: multipart/alternative; boundary="_000_B7D2A316AA32B6469D9670B6A81B7C241F16ABxmbalnx07ciscocom_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:59:47 -0000 --_000_B7D2A316AA32B6469D9670B6A81B7C241F16ABxmbalnx07ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support. From: , DEBORAH A > Date: Thursday, January 24, 2013 7:47 PM To: "ccamp@ietf.org" > Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g "yes/support" or "no/do not support". If indicating no, please state your= technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR "still being documente= d". Thanks, Deborah and Lou --_000_B7D2A316AA32B6469D9670B6A81B7C241F16ABxmbalnx07ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/support.

 <= /p>

 <= /p>

From: <BRUNGARD>, DEBORAH A <db3546@att.com>
Date: Thursday, January 24, 2013 7:47 PM
To: "ccamp@ietf.org"= <ccamp@ietf.org>
Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-= 03 WG document

 

All,

 

This is start a two week po= ll on making draft-ali-ccamp-te-metric-recording-03 a ccamp working group d= ocument. Please send email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your te= chnical reservations with the document.

 

The poll ends Thursday, Feb= . 7th.

 

Note, as stated by some of = the authors, there is IPR “still being documented”.<= /span>

 

Thanks,

Deborah and Lou<= /span>

 

 

--_000_B7D2A316AA32B6469D9670B6A81B7C241F16ABxmbalnx07ciscocom_-- From rrahman@cisco.com Fri Jan 25 12:00:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8FC21F88A6 for ; Fri, 25 Jan 2013 12:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 v9IDQ73Ei65p for ; Fri, 25 Jan 2013 12:00:06 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F032D21F88A3 for ; Fri, 25 Jan 2013 12:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7413; q=dns/txt; s=iport; t=1359144006; x=1360353606; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qMjKwmrvkaBjXw7N28yTeGf/ooSSvqrX1dwSV5ecnSg=; b=X86S6aRtJSC7KjUF62bOnQK6fKgs+JJEJzutOfCvV24XC8B09l5r8hor IDqdhCkr/4HL9guqBUAmhvNrguK6xjb2a8YmksbYJB7KFMxsF0/rO+s+/ 7aZyX2+Wb95ztDTc8a5TaPjJTevYMJ8bE6yvTYbu5L0FKxreZz4JDwSlR I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAN3jAlGtJXHA/2dsb2JhbABFgki8CxZzgh4BAQEELVwCAQgRBAEBCx0HMhQJCAEBBAESCIgHvleNBINaYQOmVYJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208,217";a="168262606" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 25 Jan 2013 20:00:05 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0PK0521018786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 20:00:05 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 14:00:05 -0600 From: "Reshad Rahman (rrahman)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: Ac36Y0THF366bQJXRBinToGRQUxfKQAwPpTQAASK2CA= Date: Fri, 25 Jan 2013 20:00:04 +0000 Message-ID: <21C6C799DE4CA442891D3EF732AA1F4C105D7166@xmb-rcd-x03.cisco.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC102D60B8@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC102D60B8@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.39] Content-Type: multipart/alternative; boundary="_000_21C6C799DE4CA442891D3EF732AA1F4C105D7166xmbrcdx03ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:00:09 -0000 --_000_21C6C799DE4CA442891D3EF732AA1F4C105D7166xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:48 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g "yes/support" or "no/do not support". If indicating no, please state your= technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR "still being documente= d". Thanks, Deborah and Lou --_000_21C6C799DE4CA442891D3EF732AA1F4C105D7166xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/support

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, January 24, 2013 1:48 PM
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-= 03 WG document

 

All,

 

This is start a two week poll on making= draft-ali-ccamp-te-metric-recording-03 a ccamp working group document. Ple= ase send email to the list indicating “yes/support” or “n= o/do not support”. If indicating no, please state your technical reservat= ions with the document.

 

The poll ends Thursday, Feb= . 7th.

 

Note, as stated by some of the authors,= there is IPR “still being documented”.

 

Thanks,

Deborah and Lou

 

 

--_000_21C6C799DE4CA442891D3EF732AA1F4C105D7166xmbrcdx03ciscoc_-- From fred.gruman@us.fujitsu.com Sun Jan 27 07:28:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB52621F868B for ; Sun, 27 Jan 2013 07:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8, 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 4Vx4fW7H2pWy for ; Sun, 27 Jan 2013 07:28:36 -0800 (PST) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) by ietfa.amsl.com (Postfix) with ESMTP id 034C921F8684 for ; Sun, 27 Jan 2013 07:28:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,547,1355119200"; d="scan'208";a="26869372" Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 27 Jan 2013 09:28:31 -0600 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.98]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.02.0298.004; Sun, 27 Jan 2013 09:28:30 -0600 From: "Gruman, Fred" To: Lou Berger , Fatai Zhang , Daniele Ceccarelli Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 Thread-Index: AQHN+XvkAlR2ZdjCKkOjwHzPHcwFmphdUBNA Date: Sun, 27 Jan 2013 15:28:29 +0000 Message-ID: <5DF87403A81B0C43AF3EB1626511B2923C32F253@RCHEXMBP1.fnc.net.local> References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> <50F58A35.7040806@labn.net> <50F837FB.2010806@labn.net> <50FED643.6020708@labn.net> <50FFFCD6.5010004@labn.net> In-Reply-To: <50FFFCD6.5010004@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19594.000 x-tm-as-result: No--49.183400-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 15:28:36 -0000 Hi Lou, Fatai, Daniele, I understand the latest change to the way bandwidth is signaled for ODUflex= (GFP), i.e., signaling the number of tributary slots N instead of the bandw= idth rate in bps. I believe that this simplifies the signaling and interop= erability so I'm in agreement with this change. However, it seems we are now inconsistent between how we represent bandwidt= h in routing and signaling for ODUflex(GFP). Routing advertises the bandwi= dth using a floating point representation of bandwidth, while signaling is = using the number of tributary slots. It seems the same benefits would be ob= tained by advertising the max LSP bandwidth and unreserved bandwidth for OD= Uflex(GFP) in terms of the number of tributary slots. Fred -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Wednesday, January 23, 2013 9:08 AM To: Fatai Zhang Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signal= ing-g709v3-04 Fatai, On 1/23/2013 6:49 AM, Fatai Zhang wrote: > Hi Lou, >=20 > For ODUflex(CBR), the formula is from [G.709-2012] and it has been > discussed before, so please trust that there is no opportunity for > misinterpretation. (Note that there are two cases, one is > ODUflex(CBR) and another one is ODUflex(GFP)). >=20 > In addtion, ODUflex cannot be concatenated by [G.709-2012]. Thanks for confirming my understanding. This raises the question of if the new traffic should just apply to ODUFlex? Correct me if I'm wrong, but I believe the [RFC4328] is sufficient in all other cases. This may also make it easier for early implementations of the draft as then they can limit code changes from the (-03) rev to only ODUflex LSPs. Just to be clear, I'm really just *asking* about this. As I said before, I'm open on specifics... Any thoughts/comments? Authors? Implementors? Thanks, Lou > I will issue a new version tomorrow to capture all your comments. >=20 >=20 > Best Regards >=20 > Fatai >=20 >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Wednesday, January 23, 2013 2:11 AM > To: Fatai Zhang > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-sign= aling-g709v3-04 >=20 > Fatai, >=20 > On 1/20/2013 9:43 PM, Fatai Zhang wrote: >> Hi Lou, >> >> You said: >>> but you're says encoded as (N*Nominal Rate) right? Wat's the value of t= his vs just carrying N? >> >> [Fatai] The original way (in version 04&05) is putting (N* Nominal >> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can >> generalize to just use one single "Bit_Rate" field to carry IEEE >> float number for both cases, it seems that you don't agree on this >> value, :-) >=20 > I've seen differences in calculated floating point values from different > implementations, so I just want to ensure that such cases are avoided. > I'm open to specific solutions and certainly will deffer on the > specifics assuming there is no opportunity for misinterpretation/interop > issues. I don't think the original passed this threshold, i.e.,: >=20 > N =3D Ceiling of >=20 > ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) > --------------------------------------------------------------------- > ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) >=20 >> . Therefore, I (was) am saying that I am going to accept >> your suggestion to carry N for ODUflex(GFP). We are discussing where >> to put N for ODUflex(GFP). >> >=20 >> You said: >>> bits in the control plane are generally cheap, IMO it's better to have = simpler encoding than to optimize every bit (or 8 in this case). >> >> [Fatai] OK, I will add a new field (to occupy the reserved bits) to carr= y N. >=20 > As you see fit. >=20 > Just to clarify my understanding, ODUflex and Virtual concatenation can > never be combined for the same signal type/level, right? (Although an > ODUflex client signal could be carried over a virtual concatenated > ODUk). Is this correct or did I miss something in G709? >=20 > Thanks, > Lou >=20 >> >> >> >> Best Regards >> >> Fatai >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net]=20 >> Sent: Friday, January 18, 2013 1:42 AM >> To: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-sig= naling-g709v3-04 >> >> >> >> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> To avoid misunderstanding, I would like to clarify more on the >>> following point. >>> >>> >>>>>>> It is better to have consistent format and the same meaning of one >> field for both ODUflex(CBR) and GFP. This is why we have section 5.1 >> &5.2 to describe the complex stuff. >>>>>> I actually wasn't suggesting that N be carried in the bit rate field= . >>>>>> The bit rate field can either be set as described or to zero (i.e., >>>>>> ignored). At the time, I was thinking about carrying N in the reser= ved >>>>>> field. But perhaps the right place is MT, if my understanding is rig= ht >>>>>> (would always be 1 otherwise). I'm open to either... >>>>>> >>>>> [Fatai] Why not just use "bit rate"field to carry "N"because "N" >>>>> implies bit rate? I am OK if you like to use a new filed (like "TS >>>>> Number") to occupy the reserved field even though that I prefer the >>>>> original approach (ie., use "bit rate"field to carry "N"). >>>> >>>> Are you proposing dropping carrying bit rates represented as an IEEE >>>> floating point and just carrying N for ODUflex? This seems workable to >>>> me, but we should ensure that there are no significant objections. >>> >>> [Fatai] There are two usages for " Bit_Rate " field as described in the >>> lines 287-310. >>> >>> (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal bit >>> rate of ODUflex(CBR) expressed in bytes per second, encoded as a 32-bit >>> IEEE single precision floating-point number. For this case, we MUST use >>> 32-bit IEEE floating point instead of "N"(Please see more in section 5.= 1). >> >> I guess you really still need (to be based on) the client signal rate at >> the edges. >> >>> >>> (2) For ODUflex(GFP), we can change the text (the lines from 305 to >>> 310) based on your suggestion, ie., the Bit_Rate field is used to carry >>> "N"to indicate the nominal bit rate of the >>> ODUflex(GFP). >> >> but you're says encoded as (N*Nominal Rate) right? Wat's the value of >> this vs just carrying N? >> >> >>> >>> Therefore, I am proposing using one single filed ("Bit_Rate ") for thes= e >>> two cases, in this way, we can leave the "Reserved" bits for future. >> >> bits in the control plane are generally cheap, IMO it's better to have >> simpler encoding than to optimize every bit (or 8 in this case). >> >> Lou >> >>> >>> Hope we are now at the same page. >>> >>> >>> Best Regards >>> >>> Fatai >> >> >> >> >=20 >=20 >=20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From mkattan@cisco.com Sun Jan 27 08:21:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775E721F86EA for ; Sun, 27 Jan 2013 08:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Zmo2KvHlfmlF for ; Sun, 27 Jan 2013 08:21:07 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E18C321F86E8 for ; Sun, 27 Jan 2013 08:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17103; q=dns/txt; s=iport; t=1359303667; x=1360513267; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=UkJiHPiMaPB7id9fNFEm7jsT8Z+Zc6vxlmjlwfKbM3c=; b=KDzH7Hrngx843lbN/kwjXCYA4s2G1Kvipzj+YbM/oWzvTQhmvP4GYmWj ZISTmAt31JsGmg/p0jDI0YzwratZeUjCHEuntu22bZyPfVCsyP8cpHJAg t8V0T6iB1x0ZuixDQdmvK773BPAEHheDck15I/L/PTEP+YSEX8BWRRuA+ w=; X-Files: image001.png : 1632 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAItTBVGtJXHB/2dsb2JhbABFgki8GBZzgh4BAQEEBQEfCAEbPgICAQgRAwEBAQYBAQECHQcCBRABAwsMFAkIAgQBEQEGAgaIAwy+NgSNBoM1YQOQKwGWKYJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,547,1355097600"; d="png'150?scan'150,208,217,150";a="165818465" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 27 Jan 2013 16:21:06 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0RGL6sg010229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Jan 2013 16:21:06 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.20]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Sun, 27 Jan 2013 10:21:06 -0600 From: "Moustafa Kattan (mkattan)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: AQHN+yWEQU/JMaM870e01HbIcOjHIZhdXjnw Date: Sun, 27 Jan 2013 16:21:05 +0000 Message-ID: <62F90F515D6344418F40C9828AF3AAB823329F@xmb-aln-x14.cisco.com> References: <7802FF1A01070C449CCE96E5CD2CC77969D011@xmb-rcd-x09.cisco.com> In-Reply-To: <7802FF1A01070C449CCE96E5CD2CC77969D011@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.38.218] Content-Type: multipart/related; boundary="_004_62F90F515D6344418F40C9828AF3AAB823329Fxmbalnx14ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 16:21:08 -0000 --_004_62F90F515D6344418F40C9828AF3AAB823329Fxmbalnx14ciscocom_ Content-Type: multipart/alternative; boundary="_000_62F90F515D6344418F40C9828AF3AAB823329Fxmbalnx14ciscocom_" --_000_62F90F515D6344418F40C9828AF3AAB823329Fxmbalnx14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, support. From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= abriele Maria Galimberti (ggalimbe) Sent: Friday, January 25, 2013 9:58 PM To: BRUNGARD, DEBORAH A; ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 = WG document yes/support [http://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Technical Leader Cisco Photonics Srl Via Philips, 12 20900 - Monza (MI) Italy www.cisco.com/global/IT/ ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: , DEBORAH A > Date: Thursday, January 24, 2013 7:47 PM To: "ccamp@ietf.org" > Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g "yes/support" or "no/do not support". If indicating no, please state your= technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR "still being documente= d". Thanks, Deborah and Lou --_000_62F90F515D6344418F40C9828AF3AAB823329Fxmbalnx14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, support.<= /span>

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Gabriele Maria Galimberti (ggalimbe)
Sent: Friday, January 25, 2013 9:58 PM
To: BRUNGARD, DEBORAH A; ccamp@ietf.org
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-record= ing-03 WG document

 

 

yes/support<= /p>

3D"http://www.=

 

 

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

 

Via Philips, 12

20900 - Monza (MI)
Italy
w= ww.cisco.com/global/IT/

 

ggalimbe@cisco.com
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

&nb= sp;

 

 

 

 

 

 

 

 

 

From: <BRUNGARD>, DEBORAH A <db3546@att.com>
Date: Thursday, January 24, 2013 7:47 PM
To: "ccamp@ietf.org"= <ccamp@ietf.org>
Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-= 03 WG document

 

All,

 

This is start a two week po= ll on making draft-ali-ccamp-te-metric-recording-03 a ccamp working group d= ocument. Please send email to the list indicating “yes/support” or “no/do not support”. If indicating no, please state your te= chnical reservations with the document.

 

The poll ends Thursday, Feb= . 7th.

 

Note, as stated by some of = the authors, there is IPR “still being documented”.<= /span>

 

Thanks,

Deborah and Lou<= /span>

 

 

--_000_62F90F515D6344418F40C9828AF3AAB823329Fxmbalnx14ciscocom_-- --_004_62F90F515D6344418F40C9828AF3AAB823329Fxmbalnx14ciscocom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=1632; creation-date="Sun, 27 Jan 2013 16:21:03 GMT"; modification-date="Sun, 27 Jan 2013 16:21:03 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAG4AAABJCAIAAABTkIQiAAAGJ0lEQVR4nO2be0xTVxzHv30gcHk5 bRmKyMCJrhDsNi0xzldikE2dZr5mSEnm/poylxi3ZAuOkhhjspANZ0zUhT9GyNwMzoHDSHD4GEGI QGtGAQ10iEyg1a1Cy50tdH9cd7kqRVp+5WHO54/m9HDOl3M+nHvP6W2QeTweMCiQT/YAXhyYSjKY SjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjImQWXLnXvTOt8bE62yxtz2 XfnvNea2aZo/CsoJ/n0lVxsqG5sBLNcsmI75ozDRq1KYp/A6HfNHgW07ZDCVZDCVZARQpa+HkqnW 3lcCpdLXQ8lUa+8HgToM+XoomWrt/SBQq9LXQ8lUa+8HBCqn+wdBqvzxqpzuHwQJ88d7r/yooBhA ZWOz8cSX4x/NtM5n50oymEoymEoyxqty3euvia9jqafKCXS+H4x329m66g3xdSz1VDmBzveD8apc rlnwUji3eP6cMdZT5QQ63w8I7pXexjFi/SgXlE85E5DvKxP9hQThBTUp+aMgm/h/Nmm5c49qIUxK vjcmQeWLCjtXksFUkhHYbeevy5fF8tw1a8g7jqWZ32PwlYCodPN8x5Wrt4qL79fXO81NADhNctL2 bTqDwTM4KFMoANQZDMa8PADa3NxlBw8KlQBsLa2N3x7ruVwldnx5zdoVhlxOrRoxn7daAYSo1Unb t2kPfDojPExs1lVb13Wh3FJRaa+plqujI15dmJC+LvH9XarFiwIxa3qVbp5vOHnK+Mk+aaXT3HS3 PlEHeAAZgCf3useVgK2l9dLuD+011dKOFnPTss8OcFBJ828eOjRk7R1uZu29W5+YMjAgqmy7WFGz f7/w9wAwZO21W3uNNdW3z/2y9puvA7E86VU+5TFsiVbJhUntAIBM9mxHz+Bge0WF2DJOn6WMiATw oLFxBje81hpOnmr4/Au5sx8AgoLCNMlKLsx+o04a1VVbdyljvbRGro4W1DtMxt/2ZmeUlJCvTWKV TqvtdmGh+FZbcDQxPR2AvaPjkd2O/1ffiLgGeHvrLaGs2rhpdX6+cFE7rbbgmVHSfMGjXB2dmpMj zVeGhgJw87z5+yIxNmFPdvL2rQCazpRYTp2Ay+U0N7Wf/kFlMFDOnFxlR1WVw2QUytqCo7p9Hwtl cQmI98QRhhIaEqWeLZRt58uqDXnzVq+ak6abGR8vzf/3TwsABAWl5uQ8ne/xAOjv6bEcPybUJ+zJ Xpv/lTIkBMDM5BR338POou8BWCoqddQqiQ9Dfd3dYjll1y7fhqJQxL79jvjWcvzYtZ07ft28pfmn M9J8t9MJQMlxI+TLZAAc3T1ihSZLL3gEwKlVSZmZCAoCwHfTf/UWwHOlcLn5xNylb264XqvauEms cZiM13buaLtYQZIfUIhVRsTEiOW28nJfu8sUitg03ZZzP2+4XqvNzRXr20vLPIODQr6S4wC4nU5v +cFRUWK560K50BHAo35He2kZXC4AyshIX8f2XIhVqlNTw5ZohXLD4cNtFyucVpvTarO1tHbV1gEQ JzYCHo+b5908LwNi03S63Fxxebr7Hg4NDQn5wa8kAIDL9Wy+m+cBRM6bF6fPEjoa8/JaSs46rbZ/ OjqMhYWdxY+3o+gVb9FOHOTbjmrxooVbNhtNRgAOk/FSxnpBx0BnZ2hc3HtlpR7vm/ig2327tOzu latRi5IA4MF92/myx6OMiJTL5cP55ia4XA6TsUqvn5WWJuZnFBYqQ0JmhIct2f2BsL0AuLZzx83l KwDYb9QJSzI4IVGTpaedOAJxrkzZm32/3SLORNQRGhc33MjL46g+c5O4+YpwmmRNll7c+oX8jpKz cmf/kLV3xPyYlSu1BUfF4630VBuckKg7ciQ2Tefv/LxCr5JTq1bn5/+xdKnl9I/SOUTMj4eXJSlU yuVyzJr91I/i9FlJmZnSmUvz/zaZhDPmEBceMT9e3IjkCsWyvXsiYmKai4qGl3ZU1Jx3NydlZi5Y n0412SdmEdDnlX48SpB2eW6vKfU4gz36JYM9rySDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSD qSSDqSSDqSSDqSSDqSTjP8P5+2z4huMfAAAAAElFTkSuQmCC --_004_62F90F515D6344418F40C9828AF3AAB823329Fxmbalnx14ciscocom_-- From lufang@cisco.com Sun Jan 27 09:39:39 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB39121F84DE for ; Sun, 27 Jan 2013 09:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 zvci7LmgVQQW for ; Sun, 27 Jan 2013 09:39:39 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 14AB421F84CC for ; Sun, 27 Jan 2013 09:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5344; q=dns/txt; s=iport; t=1359308379; x=1360517979; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=n7hlnBV9YVF7sKaeJuORymvzBWQhwqYDavy9K1aaUBA=; b=nKpB9epJrGm2C4ottCQHMtFuSMrivc+WQ7DPEkxwk23pSeyYojTADs5I pfyYoD/aY66Sf6/d1iaxTNi7p5dJw/vBiIS2DRWxTJ0qzqhISsai65GUw nHMMSp4bg0vSAF1DhF6mDwhjhoLtux0PAlVYSysActOLOC9lsnQo9cnuy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF9lBVGtJXG8/2dsb2JhbABFgki8GBZzgh4BAQEEgQsBCBEDAQILHTkUCQgCBAESCIgJvkuNCoM1YQOmVYJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,547,1355097600"; d="scan'208,217";a="168831401" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jan 2013 17:39:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0RHdcYA004060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Jan 2013 17:39:38 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.232]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Sun, 27 Jan 2013 11:39:38 -0600 From: "Luyuan Fang (lufang)" To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: AQHN+yWKLlWQtuTKaEKaiUzsSQCGxJhdwuaA///CHgA= Date: Sun, 27 Jan 2013 17:39:37 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931026EE04@xmb-rcd-x03.cisco.com> In-Reply-To: <62F90F515D6344418F40C9828AF3AAB823329F@xmb-aln-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.213.161] Content-Type: multipart/alternative; boundary="_000_0DB8F45437AB844CBB5102F807A0AD931026EE04xmbrcdx03ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 17:39:40 -0000 --_000_0DB8F45437AB844CBB5102F807A0AD931026EE04xmbrcdx03ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes/support. Luyuan From: , DEBORAH A > Date: Thursday, January 24, 2013 7:47 PM To: "ccamp@ietf.org" > Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g =93yes/support=94 or =93no/do not support=94. If indicating no, please st= ate your technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR =93still being documen= ted=94. Thanks, Deborah and Lou --_000_0DB8F45437AB844CBB5102F807A0AD931026EE04xmbrcdx03ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Yes/support.
Luyuan

From: <BRUNGARD>, DEBORAH A <db3546@att.com>
Date: Thursday, January 24, 2013 7:47 PM
To: "ccamp@ietf.org"= <ccamp@ietf.org>
Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-= 03 WG document

 

All,

 

This is start a two week poll on making draft= -ali-ccamp-te-metric-recording-03 a ccamp working group document. Please se= nd email to the list indicating =93yes/support=94 or =93no/do not support=94. If indicating no, please state your technical = reservations with the document.

 

The poll ends Thursday, Feb7th.

 

Note, as stated by some of the authors, there= is IPR =93still being documented=94.

 

Thanks,

Deborah and Lou

 

 

 --_000_0DB8F45437AB844CBB5102F807A0AD931026EE04xmbrcdx03ciscoc_-- From jdrake@juniper.net Sun Jan 27 09:48:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75FE21F87F7 for ; Sun, 27 Jan 2013 09:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] 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 QH3X2PZbhJfa for ; Sun, 27 Jan 2013 09:48:05 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id AFB9021F85BF for ; Sun, 27 Jan 2013 09:48:05 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUQVoVchyu8o+GhCOOIHJqloNNBF8Z2wg@postini.com; Sun, 27 Jan 2013 09:48:05 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 27 Jan 2013 09:47:32 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Sun, 27 Jan 2013 09:47:31 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.11) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 27 Jan 2013 09:55:27 -0800 Received: from mail45-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.23; Sun, 27 Jan 2013 17:47:30 +0000 Received: from mail45-tx2 (localhost [127.0.0.1]) by mail45-tx2-R.bigfish.com (Postfix) with ESMTP id BC8734A0419 for ; Sun, 27 Jan 2013 17:47:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -28 X-BigFish: PS-28(zzbb2dI98dI9371I148cI542I1432I4015Idf9Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail45-tx2 (localhost.localdomain [127.0.0.1]) by mail45-tx2 (MessageSwitch) id 1359308842895223_27368; Sun, 27 Jan 2013 17:47:22 +0000 (UTC) Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.247]) by mail45-tx2.bigfish.com (Postfix) with ESMTP id D51E02A0052; Sun, 27 Jan 2013 17:47:22 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 27 Jan 2013 17:47:18 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.86]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0263.000; Sun, 27 Jan 2013 17:47:18 +0000 From: John E Drake To: "Gruman, Fred" , Lou Berger , Fatai Zhang , Daniele Ceccarelli Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 Thread-Index: AQHN/KMC0vYLDn+EsUelyHWFkT4LF5hdc1lw Date: Sun, 27 Jan 2013 17:47:17 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E0B70F3A9@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> <50F58A35.7040806@labn.net> <50F837FB.2010806@labn.net> <50FED643.6020708@labn.net> <50FFFCD6.5010004@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C32F253@RCHEXMBP1.fnc.net.local> In-Reply-To: <5DF87403A81B0C43AF3EB1626511B2923C32F253@RCHEXMBP1.fnc.net.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%US.FUJITSU.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 17:48:06 -0000 Good catch. Irrespectively Yours, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Gruman, Fred > Sent: Sunday, January 27, 2013 7:28 AM > To: Lou Berger; Fatai Zhang; Daniele Ceccarelli > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls- > signaling-g709v3-04 >=20 > Hi Lou, Fatai, Daniele, >=20 > I understand the latest change to the way bandwidth is signaled for > ODUflex(GFP), i.e., signaling the number of tributary slots N instead > of the bandwidth rate in bps. I believe that this simplifies the > signaling and interoperability so I'm in agreement with this change. >=20 > However, it seems we are now inconsistent between how we represent > bandwidth in routing and signaling for ODUflex(GFP). Routing > advertises the bandwidth using a floating point representation of > bandwidth, while signaling is using the number of tributary slots. It > seems the same benefits would be obtained by advertising the max LSP > bandwidth and unreserved bandwidth for ODUflex(GFP) in terms of the > number of tributary slots. >=20 > Fred >=20 >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Wednesday, January 23, 2013 9:08 AM > To: Fatai Zhang > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls- > signaling-g709v3-04 >=20 > Fatai, >=20 > On 1/23/2013 6:49 AM, Fatai Zhang wrote: > > Hi Lou, > > > > For ODUflex(CBR), the formula is from [G.709-2012] and it has been > > discussed before, so please trust that there is no opportunity for > > misinterpretation. (Note that there are two cases, one is > > ODUflex(CBR) and another one is ODUflex(GFP)). > > > > In addtion, ODUflex cannot be concatenated by [G.709-2012]. >=20 > Thanks for confirming my understanding. This raises the question of if > the new traffic should just apply to ODUFlex? Correct me if I'm wrong, > but I believe the [RFC4328] is sufficient in all other cases. This may > also make it easier for early implementations of the draft as then they > can limit code changes from the (-03) rev to only ODUflex LSPs. >=20 > Just to be clear, I'm really just *asking* about this. As I said > before, I'm open on specifics... >=20 > Any thoughts/comments? Authors? Implementors? >=20 > Thanks, > Lou >=20 >=20 > > I will issue a new version tomorrow to capture all your comments. > > > > > > Best Regards > > > > Fatai > > > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, January 23, 2013 2:11 AM > > To: Fatai Zhang > > Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > > Subject: Re: [CCAMP] WG Last Call comments on > > draft-ietf-ccamp-gmpls-signaling-g709v3-04 > > > > Fatai, > > > > On 1/20/2013 9:43 PM, Fatai Zhang wrote: > >> Hi Lou, > >> > >> You said: > >>> but you're says encoded as (N*Nominal Rate) right? Wat's the value > of this vs just carrying N? > >> > >> [Fatai] The original way (in version 04&05) is putting (N* Nominal > >> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can > >> generalize to just use one single "Bit_Rate" field to carry IEEE > >> float number for both cases, it seems that you don't agree on this > >> value, :-) > > > > I've seen differences in calculated floating point values from > > different implementations, so I just want to ensure that such cases > are avoided. > > I'm open to specific solutions and certainly will deffer on the > > specifics assuming there is no opportunity for > > misinterpretation/interop issues. I don't think the original passed > this threshold, i.e.,: > > > > N =3D Ceiling of > > > > ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate > tolerance) > > ------------------------------------------------------------------ > --- > > ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) > > > >> . Therefore, I (was) am saying that I am going to accept your > >> suggestion to carry N for ODUflex(GFP). We are discussing where to > >> put N for ODUflex(GFP). > >> > > > >> You said: > >>> bits in the control plane are generally cheap, IMO it's better to > have simpler encoding than to optimize every bit (or 8 in this case). > >> > >> [Fatai] OK, I will add a new field (to occupy the reserved bits) to > carry N. > > > > As you see fit. > > > > Just to clarify my understanding, ODUflex and Virtual concatenation > > can never be combined for the same signal type/level, right? > (Although > > an ODUflex client signal could be carried over a virtual concatenated > > ODUk). Is this correct or did I miss something in G709? > > > > Thanks, > > Lou > > > >> > >> > >> > >> Best Regards > >> > >> Fatai > >> > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Friday, January 18, 2013 1:42 AM > >> To: Fatai Zhang > >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > >> Subject: Re: [CCAMP] WG Last Call comments on > >> draft-ietf-ccamp-gmpls-signaling-g709v3-04 > >> > >> > >> > >> On 1/15/2013 10:16 PM, Fatai Zhang wrote: > >>> Hi Lou, > >>> > >>> To avoid misunderstanding, I would like to clarify more on the > >>> following point. > >>> > >>> > >>>>>>> It is better to have consistent format and the same meaning of > >>>>>>> one > >> field for both ODUflex(CBR) and GFP. This is why we have section 5.1 > >> &5.2 to describe the complex stuff. > >>>>>> I actually wasn't suggesting that N be carried in the bit rate > field. > >>>>>> The bit rate field can either be set as described or to zero > >>>>>> (i.e., ignored). At the time, I was thinking about carrying N > in > >>>>>> the reserved field. But perhaps the right place is MT, if my > >>>>>> understanding is right (would always be 1 otherwise). I'm open > to either... > >>>>>> > >>>>> [Fatai] Why not just use "bit rate"field to carry "N"because "N" > >>>>> implies bit rate? I am OK if you like to use a new filed (like > >>>>> "TS > >>>>> Number") to occupy the reserved field even though that I prefer > >>>>> the original approach (ie., use "bit rate"field to carry "N"). > >>>> > >>>> Are you proposing dropping carrying bit rates represented as an > >>>> IEEE floating point and just carrying N for ODUflex? This seems > >>>> workable to me, but we should ensure that there are no significant > objections. > >>> > >>> [Fatai] There are two usages for " Bit_Rate " field as described in > >>> the lines 287-310. > >>> > >>> (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal > bit > >>> rate of ODUflex(CBR) expressed in bytes per second, encoded as a > >>> 32-bit IEEE single precision floating-point number. For this case, > >>> we MUST use 32-bit IEEE floating point instead of "N"(Please see > more in section 5.1). > >> > >> I guess you really still need (to be based on) the client signal > rate > >> at the edges. > >> > >>> > >>> (2) For ODUflex(GFP), we can change the text (the lines from 305 > to > >>> 310) based on your suggestion, ie., the Bit_Rate field is used to > >>> carry "N"to indicate the nominal bit rate of the ODUflex(GFP). > >> > >> but you're says encoded as (N*Nominal Rate) right? Wat's the value > >> of this vs just carrying N? > >> > >> > >>> > >>> Therefore, I am proposing using one single filed ("Bit_Rate ") for > >>> these two cases, in this way, we can leave the "Reserved" bits for > future. > >> > >> bits in the control plane are generally cheap, IMO it's better to > >> have simpler encoding than to optimize every bit (or 8 in this > case). > >> > >> Lou > >> > >>> > >>> Hope we are now at the same page. > >>> > >>> > >>> Best Regards > >>> > >>> Fatai > >> > >> > >> > >> > > > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Sun Jan 27 14:29:49 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779DA21F8887 for ; Sun, 27 Jan 2013 14:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.13 X-Spam-Level: X-Spam-Status: No, score=-101.13 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 k103scdQS8qH for ; Sun, 27 Jan 2013 14:29:48 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 1D91421F8770 for ; Sun, 27 Jan 2013 14:29:47 -0800 (PST) Received: (qmail 15109 invoked by uid 0); 27 Jan 2013 22:29:25 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 27 Jan 2013 22:29:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=QO3WETQHZMcho8qqZ3uHPxE4nes41nsHVKVAYgZ2ulA=; b=Foadjbq5Y7Yh+Ci02bs6lY5z8VspyBbzO53467bw9CaOAzcldppA5u0H6rm8OCPGzZ44Ogm9XI9rzL/2LmSLnB0NUP+K/C24mgbeV4NFlM318YB8qId+orP6NRESbZMu; Received: from box313.bluehost.com ([69.89.31.113]:55869 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Tzaj7-0008LK-G8; Sun, 27 Jan 2013 15:29:25 -0700 Message-ID: <5105AA4F.2050304@labn.net> Date: Sun, 27 Jan 2013 17:29:35 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John E Drake References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <50D31CB7.9000704@labn.net> <50E5FD4A.1080207@labn.net> <50F58A35.7040806@labn.net> <50F837FB.2010806@labn.net> <50FED643.6020708@labn.net> <50FFFCD6.5010004@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C32F253@RCHEXMBP1.fnc.net.local> <0182DEA5604B3A44A2EE61F3EE3ED69E0B70F3A9@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E0B70F3A9@BL2PRD0510MB349.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 22:29:49 -0000 Agreed. Just a heads-up to all, immediately following the conclusion of the LC discussion on the signaling document. Given the technical changes, there will be a second last call conducted. Lou On 1/27/2013 12:47 PM, John E Drake wrote: > Good catch. > > Irrespectively Yours, > > John > > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Gruman, Fred >> Sent: Sunday, January 27, 2013 7:28 AM >> To: Lou Berger; Fatai Zhang; Daniele Ceccarelli >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls- >> signaling-g709v3-04 >> >> Hi Lou, Fatai, Daniele, >> >> I understand the latest change to the way bandwidth is signaled for >> ODUflex(GFP), i.e., signaling the number of tributary slots N instead >> of the bandwidth rate in bps. I believe that this simplifies the >> signaling and interoperability so I'm in agreement with this change. >> >> However, it seems we are now inconsistent between how we represent >> bandwidth in routing and signaling for ODUflex(GFP). Routing >> advertises the bandwidth using a floating point representation of >> bandwidth, while signaling is using the number of tributary slots. It >> seems the same benefits would be obtained by advertising the max LSP >> bandwidth and unreserved bandwidth for ODUflex(GFP) in terms of the >> number of tributary slots. >> >> Fred >> >> >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Lou Berger >> Sent: Wednesday, January 23, 2013 9:08 AM >> To: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls- >> signaling-g709v3-04 >> >> Fatai, >> >> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> For ODUflex(CBR), the formula is from [G.709-2012] and it has been >>> discussed before, so please trust that there is no opportunity for >>> misinterpretation. (Note that there are two cases, one is >>> ODUflex(CBR) and another one is ODUflex(GFP)). >>> >>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >> >> Thanks for confirming my understanding. This raises the question of if >> the new traffic should just apply to ODUFlex? Correct me if I'm wrong, >> but I believe the [RFC4328] is sufficient in all other cases. This may >> also make it easier for early implementations of the draft as then they >> can limit code changes from the (-03) rev to only ODUflex LSPs. >> >> Just to be clear, I'm really just *asking* about this. As I said >> before, I'm open on specifics... >> >> Any thoughts/comments? Authors? Implementors? >> >> Thanks, >> Lou >> >> >>> I will issue a new version tomorrow to capture all your comments. >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Wednesday, January 23, 2013 2:11 AM >>> To: Fatai Zhang >>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: [CCAMP] WG Last Call comments on >>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>> >>> Fatai, >>> >>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>> Hi Lou, >>>> >>>> You said: >>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the value >> of this vs just carrying N? >>>> >>>> [Fatai] The original way (in version 04&05) is putting (N* Nominal >>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can >>>> generalize to just use one single "Bit_Rate" field to carry IEEE >>>> float number for both cases, it seems that you don't agree on this >>>> value, :-) >>> >>> I've seen differences in calculated floating point values from >>> different implementations, so I just want to ensure that such cases >> are avoided. >>> I'm open to specific solutions and certainly will deffer on the >>> specifics assuming there is no opportunity for >>> misinterpretation/interop issues. I don't think the original passed >> this threshold, i.e.,: >>> >>> N = Ceiling of >>> >>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate >> tolerance) >>> ------------------------------------------------------------------ >> --- >>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) >>> >>>> . Therefore, I (was) am saying that I am going to accept your >>>> suggestion to carry N for ODUflex(GFP). We are discussing where to >>>> put N for ODUflex(GFP). >>>> >>> >>>> You said: >>>>> bits in the control plane are generally cheap, IMO it's better to >> have simpler encoding than to optimize every bit (or 8 in this case). >>>> >>>> [Fatai] OK, I will add a new field (to occupy the reserved bits) to >> carry N. >>> >>> As you see fit. >>> >>> Just to clarify my understanding, ODUflex and Virtual concatenation >>> can never be combined for the same signal type/level, right? >> (Although >>> an ODUflex client signal could be carried over a virtual concatenated >>> ODUk). Is this correct or did I miss something in G709? >>> >>> Thanks, >>> Lou >>> >>>> >>>> >>>> >>>> Best Regards >>>> >>>> Fatai >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Friday, January 18, 2013 1:42 AM >>>> To: Fatai Zhang >>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: Re: [CCAMP] WG Last Call comments on >>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>> >>>> >>>> >>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>> Hi Lou, >>>>> >>>>> To avoid misunderstanding, I would like to clarify more on the >>>>> following point. >>>>> >>>>> >>>>>>>>> It is better to have consistent format and the same meaning of >>>>>>>>> one >>>> field for both ODUflex(CBR) and GFP. This is why we have section 5.1 >>>> &5.2 to describe the complex stuff. >>>>>>>> I actually wasn't suggesting that N be carried in the bit rate >> field. >>>>>>>> The bit rate field can either be set as described or to zero >>>>>>>> (i.e., ignored). At the time, I was thinking about carrying N >> in >>>>>>>> the reserved field. But perhaps the right place is MT, if my >>>>>>>> understanding is right (would always be 1 otherwise). I'm open >> to either... >>>>>>>> >>>>>>> [Fatai] Why not just use "bit rate"field to carry "N"because "N" >>>>>>> implies bit rate? I am OK if you like to use a new filed (like >>>>>>> "TS >>>>>>> Number") to occupy the reserved field even though that I prefer >>>>>>> the original approach (ie., use "bit rate"field to carry "N"). >>>>>> >>>>>> Are you proposing dropping carrying bit rates represented as an >>>>>> IEEE floating point and just carrying N for ODUflex? This seems >>>>>> workable to me, but we should ensure that there are no significant >> objections. >>>>> >>>>> [Fatai] There are two usages for " Bit_Rate " field as described in >>>>> the lines 287-310. >>>>> >>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal >> bit >>>>> rate of ODUflex(CBR) expressed in bytes per second, encoded as a >>>>> 32-bit IEEE single precision floating-point number. For this case, >>>>> we MUST use 32-bit IEEE floating point instead of "N"(Please see >> more in section 5.1). >>>> >>>> I guess you really still need (to be based on) the client signal >> rate >>>> at the edges. >>>> >>>>> >>>>> (2) For ODUflex(GFP), we can change the text (the lines from 305 >> to >>>>> 310) based on your suggestion, ie., the Bit_Rate field is used to >>>>> carry "N"to indicate the nominal bit rate of the ODUflex(GFP). >>>> >>>> but you're says encoded as (N*Nominal Rate) right? Wat's the value >>>> of this vs just carrying N? >>>> >>>> >>>>> >>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") for >>>>> these two cases, in this way, we can leave the "Reserved" bits for >> future. >>>> >>>> bits in the control plane are generally cheap, IMO it's better to >>>> have simpler encoding than to optimize every bit (or 8 in this >> case). >>>> >>>> Lou >>>> >>>>> >>>>> Hope we are now at the same page. >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> Fatai >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > From zali@cisco.com Sun Jan 27 16:46:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D026021F869E for ; Sun, 27 Jan 2013 16:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] 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 OijJawe5C7EP for ; Sun, 27 Jan 2013 16:46:54 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE1221F8549 for ; Sun, 27 Jan 2013 16:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8348; q=dns/txt; s=iport; t=1359334014; x=1360543614; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LZmBzPAVUn5ql+apFtex8+wRO1s0s0hnM3ZoKcB8QLI=; b=ch0dU5X50XCJDBM9r5d43jPhg/fGfXbUEL5L9ojzL/CX0qSdBvy19Yz7 B8teGGyZQPws6HoHK9Eid4bP1ki6YzsUF5/7BWYYzTjEJi4oAG/3glE5e 2TSKiPDTsbIUo50IO44O5h6V65XBmCRldqkwM/9abtzdyaUSwBmlF2AH5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIXJBVGtJXHA/2dsb2JhbABFvmEWc4IeAQEBBAEBAWQHBgUMBgEIEQQBAQEKHS4LFAkIAgQBDQUIE4d2DL5NBIx/FoMqYQOmVYJ3gWc9 X-IronPort-AV: E=Sophos;i="4.84,548,1355097600"; d="scan'208";a="168693279" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 28 Jan 2013 00:46:54 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0S0krKA025110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 00:46:53 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sun, 27 Jan 2013 18:46:53 -0600 From: "Zafar Ali (zali)" To: "Gruman, Fred" , Lou Berger , Fatai Zhang , Daniele Ceccarelli Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 Thread-Index: AQHN/PD3fL8LDW+r4EWqGcc8ulg1mw== Date: Mon, 28 Jan 2013 00:46:53 +0000 Message-ID: In-Reply-To: <5DF87403A81B0C43AF3EB1626511B2923C32F253@RCHEXMBP1.fnc.net.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.255.41] Content-Type: text/plain; charset="Windows-1252" Content-ID: <43BF1B927E56844CBEB549F40463CCDA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 00:46:55 -0000 All- This impacts existing implementations based on draft versions (and hence interop with these implementations moving forward). IMO this is a bigger change for us to assume at the last call stage. Furthermore we have been using IEEE floating point format for Unreserved Bandwidth/ Max LSP BW in IEEE floating point format for other technologies. Overall, I think this change suffers from the "law of diminishing returns". Thanks Regards =8A Zafar On 1/27/13 10:28 AM, "Gruman, Fred" wrote: >Hi Lou, Fatai, Daniele, > >I understand the latest change to the way bandwidth is signaled for >ODUflex(GFP), i.e., signaling the number of tributary slots N instead of >the bandwidth rate in bps. I believe that this simplifies the signaling >and interoperability so I'm in agreement with this change. > >However, it seems we are now inconsistent between how we represent >bandwidth in routing and signaling for ODUflex(GFP). Routing advertises >the bandwidth using a floating point representation of bandwidth, while >signaling is using the number of tributary slots. It seems the same >benefits would be obtained by advertising the max LSP bandwidth and >unreserved bandwidth for ODUflex(GFP) in terms of the number of tributary >slots. > >Fred > > > >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >Lou Berger >Sent: Wednesday, January 23, 2013 9:08 AM >To: Fatai Zhang >Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >Subject: Re: [CCAMP] WG Last Call comments on >draft-ietf-ccamp-gmpls-signaling-g709v3-04 > >Fatai, > >On 1/23/2013 6:49 AM, Fatai Zhang wrote: >> Hi Lou, >>=20 >> For ODUflex(CBR), the formula is from [G.709-2012] and it has been >> discussed before, so please trust that there is no opportunity for >> misinterpretation. (Note that there are two cases, one is >> ODUflex(CBR) and another one is ODUflex(GFP)). >>=20 >> In addtion, ODUflex cannot be concatenated by [G.709-2012]. > >Thanks for confirming my understanding. This raises the question of if >the new traffic should just apply to ODUFlex? Correct me if I'm wrong, >but I believe the [RFC4328] is sufficient in all other cases. This may >also make it easier for early implementations of the draft as then they >can limit code changes from the (-03) rev to only ODUflex LSPs. > >Just to be clear, I'm really just *asking* about this. As I said >before, I'm open on specifics... > >Any thoughts/comments? Authors? Implementors? > >Thanks, >Lou > > >> I will issue a new version tomorrow to capture all your comments. >>=20 >>=20 >> Best Regards >>=20 >> Fatai >>=20 >>=20 >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, January 23, 2013 2:11 AM >> To: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] WG Last Call comments on >>draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>=20 >> Fatai, >>=20 >> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> You said: >>>> but you're says encoded as (N*Nominal Rate) right? Wat's the value of >>>>this vs just carrying N? >>> >>> [Fatai] The original way (in version 04&05) is putting (N* Nominal >>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can >>> generalize to just use one single "Bit_Rate" field to carry IEEE >>> float number for both cases, it seems that you don't agree on this >>> value, :-) >>=20 >> I've seen differences in calculated floating point values from different >> implementations, so I just want to ensure that such cases are avoided. >> I'm open to specific solutions and certainly will deffer on the >> specifics assuming there is no opportunity for misinterpretation/interop >> issues. I don't think the original passed this threshold, i.e.,: >>=20 >> N =3D Ceiling of >>=20 >> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) >> --------------------------------------------------------------------- >> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) >>=20 >>> . Therefore, I (was) am saying that I am going to accept >>> your suggestion to carry N for ODUflex(GFP). We are discussing where >>> to put N for ODUflex(GFP). >>> >>=20 >>> You said: >>>> bits in the control plane are generally cheap, IMO it's better to >>>>have simpler encoding than to optimize every bit (or 8 in this case). >>> >>> [Fatai] OK, I will add a new field (to occupy the reserved bits) to >>>carry N. >>=20 >> As you see fit. >>=20 >> Just to clarify my understanding, ODUflex and Virtual concatenation can >> never be combined for the same signal type/level, right? (Although an >> ODUflex client signal could be carried over a virtual concatenated >> ODUk). Is this correct or did I miss something in G709? >>=20 >> Thanks, >> Lou >>=20 >>> >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Friday, January 18, 2013 1:42 AM >>> To: Fatai Zhang >>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: [CCAMP] WG Last Call comments on >>>draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>> >>> >>> >>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>> Hi Lou, >>>> >>>> To avoid misunderstanding, I would like to clarify more on the >>>> following point. >>>> >>>> >>>>>>>> It is better to have consistent format and the same meaning of one >>> field for both ODUflex(CBR) and GFP. This is why we have section 5.1 >>> &5.2 to describe the complex stuff. >>>>>>> I actually wasn't suggesting that N be carried in the bit rate >>>>>>>field. >>>>>>> The bit rate field can either be set as described or to zero (i.e., >>>>>>> ignored). At the time, I was thinking about carrying N in the >>>>>>>reserved >>>>>>> field. But perhaps the right place is MT, if my understanding is >>>>>>>right >>>>>>> (would always be 1 otherwise). I'm open to either... >>>>>>> >>>>>> [Fatai] Why not just use "bit rate"field to carry "N"because "N" >>>>>> implies bit rate? I am OK if you like to use a new filed (like "TS >>>>>> Number") to occupy the reserved field even though that I prefer the >>>>>> original approach (ie., use "bit rate"field to carry "N"). >>>>> >>>>> Are you proposing dropping carrying bit rates represented as an IEEE >>>>> floating point and just carrying N for ODUflex? This seems workable >>>>>to >>>>> me, but we should ensure that there are no significant objections. >>>> >>>> [Fatai] There are two usages for " Bit_Rate " field as described in >>>>the >>>> lines 287-310. >>>> >>>> (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal bit >>>> rate of ODUflex(CBR) expressed in bytes per second, encoded as a >>>>32-bit >>>> IEEE single precision floating-point number. For this case, we MUST >>>>use >>>> 32-bit IEEE floating point instead of "N"(Please see more in section >>>>5.1). >>> >>> I guess you really still need (to be based on) the client signal rate >>>at >>> the edges. >>> >>>> >>>> (2) For ODUflex(GFP), we can change the text (the lines from 305 to >>>> 310) based on your suggestion, ie., the Bit_Rate field is used to >>>>carry >>>> "N"to indicate the nominal bit rate of the >>>> ODUflex(GFP). >>> >>> but you're says encoded as (N*Nominal Rate) right? Wat's the value of >>> this vs just carrying N? >>> >>> >>>> >>>> Therefore, I am proposing using one single filed ("Bit_Rate ") for >>>>these >>>> two cases, in this way, we can leave the "Reserved" bits for future. >>> >>> bits in the control plane are generally cheap, IMO it's better to have >>> simpler encoding than to optimize every bit (or 8 in this case). >>> >>> Lou >>> >>>> >>>> Hope we are now at the same page. >>>> >>>> >>>> Best Regards >>>> >>>> Fatai >>> >>> >>> >>> >>=20 >>=20 >>=20 >>=20 >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Sun Jan 27 18:46:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1857921F87C4 for ; Sun, 27 Jan 2013 18:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.793 X-Spam-Level: X-Spam-Status: No, score=-101.793 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, 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 0hR10F46I+nt for ; Sun, 27 Jan 2013 18:46:42 -0800 (PST) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 06A1C21F841C for ; Sun, 27 Jan 2013 18:46:41 -0800 (PST) Received: (qmail 9686 invoked by uid 0); 28 Jan 2013 02:46:19 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 28 Jan 2013 02:46:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=CHEZwanQNJALHjYNzELJrPGhGVIn5/Ga3U2y8Mvknso=; b=jqlH8acHsufAFc/5N7ZmDuJSD/w4ep1P4OZf0SlQGHxlOf9NeDGlxqewa779sYmhb9M3Y7V8Q6GgWckRViLlH+6ZurAefWZliVcl0qw9hmCYDtE7ZyYaHZaqGnUIb8tm; Received: from box313.bluehost.com ([69.89.31.113]:54287 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Tzeji-0001ze-SX; Sun, 27 Jan 2013 19:46:19 -0700 Message-ID: <5105E684.4030607@labn.net> Date: Sun, 27 Jan 2013 21:46:28 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Zafar Ali (zali)" References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 02:46:43 -0000 Zafar, Is your comment with respect to just routing or both signaling and routing? Also, when you say "implementations based on draft versions", do these implementations include support for ODUflex? (Which has really been the focus of the discussion.) BTW I took Fred's comments as related to just the new OTN-specific ISCD definitions (section 4.1.2 of ospf-g709v3-05, in particular). Note that section 4.1.1 already carries N (number of ODUs) not IEEE floating point representations of available bandwidth. Much thanks, Lou On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote: > All- > > This impacts existing implementations based on draft versions (and hence > interop with these implementations moving forward). IMO this is a bigger > change for us to assume at the last call stage. Furthermore we have been > using IEEE floating point format for Unreserved Bandwidth/ Max LSP BW in > IEEE floating point format for other technologies. Overall, I think this > change suffers from the "law of diminishing returns". > > Thanks > > Regards Zafar > > > On 1/27/13 10:28 AM, "Gruman, Fred" wrote: > >> Hi Lou, Fatai, Daniele, >> >> I understand the latest change to the way bandwidth is signaled for >> ODUflex(GFP), i.e., signaling the number of tributary slots N instead of >> the bandwidth rate in bps. I believe that this simplifies the signaling >> and interoperability so I'm in agreement with this change. >> >> However, it seems we are now inconsistent between how we represent >> bandwidth in routing and signaling for ODUflex(GFP). Routing advertises >> the bandwidth using a floating point representation of bandwidth, while >> signaling is using the number of tributary slots. It seems the same >> benefits would be obtained by advertising the max LSP bandwidth and >> unreserved bandwidth for ODUflex(GFP) in terms of the number of tributary >> slots. >> >> Fred >> >> >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >> Lou Berger >> Sent: Wednesday, January 23, 2013 9:08 AM >> To: Fatai Zhang >> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] WG Last Call comments on >> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >> >> Fatai, >> >> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>> Hi Lou, >>> >>> For ODUflex(CBR), the formula is from [G.709-2012] and it has been >>> discussed before, so please trust that there is no opportunity for >>> misinterpretation. (Note that there are two cases, one is >>> ODUflex(CBR) and another one is ODUflex(GFP)). >>> >>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >> >> Thanks for confirming my understanding. This raises the question of if >> the new traffic should just apply to ODUFlex? Correct me if I'm wrong, >> but I believe the [RFC4328] is sufficient in all other cases. This may >> also make it easier for early implementations of the draft as then they >> can limit code changes from the (-03) rev to only ODUflex LSPs. >> >> Just to be clear, I'm really just *asking* about this. As I said >> before, I'm open on specifics... >> >> Any thoughts/comments? Authors? Implementors? >> >> Thanks, >> Lou >> >> >>> I will issue a new version tomorrow to capture all your comments. >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Wednesday, January 23, 2013 2:11 AM >>> To: Fatai Zhang >>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: [CCAMP] WG Last Call comments on >>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>> >>> Fatai, >>> >>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>> Hi Lou, >>>> >>>> You said: >>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the value of >>>>> this vs just carrying N? >>>> >>>> [Fatai] The original way (in version 04&05) is putting (N* Nominal >>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can >>>> generalize to just use one single "Bit_Rate" field to carry IEEE >>>> float number for both cases, it seems that you don't agree on this >>>> value, :-) >>> >>> I've seen differences in calculated floating point values from different >>> implementations, so I just want to ensure that such cases are avoided. >>> I'm open to specific solutions and certainly will deffer on the >>> specifics assuming there is no opportunity for misinterpretation/interop >>> issues. I don't think the original passed this threshold, i.e.,: >>> >>> N = Ceiling of >>> >>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) >>> --------------------------------------------------------------------- >>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) >>> >>>> . Therefore, I (was) am saying that I am going to accept >>>> your suggestion to carry N for ODUflex(GFP). We are discussing where >>>> to put N for ODUflex(GFP). >>>> >>> >>>> You said: >>>>> bits in the control plane are generally cheap, IMO it's better to >>>>> have simpler encoding than to optimize every bit (or 8 in this case). >>>> >>>> [Fatai] OK, I will add a new field (to occupy the reserved bits) to >>>> carry N. >>> >>> As you see fit. >>> >>> Just to clarify my understanding, ODUflex and Virtual concatenation can >>> never be combined for the same signal type/level, right? (Although an >>> ODUflex client signal could be carried over a virtual concatenated >>> ODUk). Is this correct or did I miss something in G709? >>> >>> Thanks, >>> Lou >>> >>>> >>>> >>>> >>>> Best Regards >>>> >>>> Fatai >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Friday, January 18, 2013 1:42 AM >>>> To: Fatai Zhang >>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: Re: [CCAMP] WG Last Call comments on >>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>> >>>> >>>> >>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>> Hi Lou, >>>>> >>>>> To avoid misunderstanding, I would like to clarify more on the >>>>> following point. >>>>> >>>>> >>>>>>>>> It is better to have consistent format and the same meaning of one >>>> field for both ODUflex(CBR) and GFP. This is why we have section 5.1 >>>> &5.2 to describe the complex stuff. >>>>>>>> I actually wasn't suggesting that N be carried in the bit rate >>>>>>>> field. >>>>>>>> The bit rate field can either be set as described or to zero (i.e., >>>>>>>> ignored). At the time, I was thinking about carrying N in the >>>>>>>> reserved >>>>>>>> field. But perhaps the right place is MT, if my understanding is >>>>>>>> right >>>>>>>> (would always be 1 otherwise). I'm open to either... >>>>>>>> >>>>>>> [Fatai] Why not just use "bit rate"field to carry "N"because "N" >>>>>>> implies bit rate? I am OK if you like to use a new filed (like "TS >>>>>>> Number") to occupy the reserved field even though that I prefer the >>>>>>> original approach (ie., use "bit rate"field to carry "N"). >>>>>> >>>>>> Are you proposing dropping carrying bit rates represented as an IEEE >>>>>> floating point and just carrying N for ODUflex? This seems workable >>>>>> to >>>>>> me, but we should ensure that there are no significant objections. >>>>> >>>>> [Fatai] There are two usages for " Bit_Rate " field as described in >>>>> the >>>>> lines 287-310. >>>>> >>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal bit >>>>> rate of ODUflex(CBR) expressed in bytes per second, encoded as a >>>>> 32-bit >>>>> IEEE single precision floating-point number. For this case, we MUST >>>>> use >>>>> 32-bit IEEE floating point instead of "N"(Please see more in section >>>>> 5.1). >>>> >>>> I guess you really still need (to be based on) the client signal rate >>>> at >>>> the edges. >>>> >>>>> >>>>> (2) For ODUflex(GFP), we can change the text (the lines from 305 to >>>>> 310) based on your suggestion, ie., the Bit_Rate field is used to >>>>> carry >>>>> "N"to indicate the nominal bit rate of the >>>>> ODUflex(GFP). >>>> >>>> but you're says encoded as (N*Nominal Rate) right? Wat's the value of >>>> this vs just carrying N? >>>> >>>> >>>>> >>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") for >>>>> these >>>>> two cases, in this way, we can leave the "Reserved" bits for future. >>>> >>>> bits in the control plane are generally cheap, IMO it's better to have >>>> simpler encoding than to optimize every bit (or 8 in this case). >>>> >>>> Lou >>>> >>>>> >>>>> Hope we are now at the same page. >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> Fatai >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > From zali@cisco.com Sun Jan 27 19:47:00 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED7121F85B2 for ; Sun, 27 Jan 2013 19:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] 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 JyLLyxu8BzWs for ; Sun, 27 Jan 2013 19:46:58 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A5DEF21F8626 for ; Sun, 27 Jan 2013 19:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10046; q=dns/txt; s=iport; t=1359344818; x=1360554418; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=E403fxs++Fqht531lj8Uibdhezbjyznq86SMWxKwPrI=; b=JB1uJXi0jNYAkS0qhfulDN/GQIq5BnmmsVepuEmWesZsLcERnNRnCKc4 +iQS+1PpjIeniXK4FrUfcQh+DK00+DRFrwNAxYEtNAzh6C89PiXOt7//w VTtiq3Rh6feowV+wN7Q0dXFl74JJfB7trI9QWEBA/ayIOsze88ysTCPVS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHv0BVGtJV2b/2dsb2JhbABFvmMWc4IeAQEBBAEBAWQHBgUMBgEIDgMEAQEBCh0uCxQJCAIEDgUIE4d2DL5fBIx/FoMqYQOmVYJ3gWc9 X-IronPort-AV: E=Sophos;i="4.84,548,1355097600"; d="scan'208";a="165949419" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jan 2013 03:46:56 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0S3kuho018271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 03:46:56 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Sun, 27 Jan 2013 21:46:56 -0600 From: "Zafar Ali (zali)" To: Lou Berger Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 Thread-Index: AQHN/PD3fL8LDW+r4EWqGcc8ulg1m5hebgoA//+9EQA= Date: Mon, 28 Jan 2013 03:46:55 +0000 Message-ID: In-Reply-To: <5105E684.4030607@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.254.84] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <029FA5CB60DCBD4B829F834E2C6A4FC1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 03:47:00 -0000 Hi Lou-=20 Please see in-line. Thanks Regards...Zafar On 1/27/13 9:46 PM, "Lou Berger" wrote: >Zafar, > Is your comment with respect to just routing or both signaling and >routing? Both, including consistency between signaling and routing attributes. > >Also, when you say "implementations based on draft versions", do these >implementations include support for ODUflex? (Which has really been the >focus of the discussion.) Yes, I was referring to ODUFlex. As you know, fixed ODU is signaled via level (0 BW) so its not an issue. > >BTW I took Fred's comments as related to just the new OTN-specific ISCD >definitions (section 4.1.2 of ospf-g709v3-05, in particular). Note that >section 4.1.1 already carries N (number of ODUs) not IEEE floating point >representations of available bandwidth. What I meant is Unreserved Bandwidth at priority x and Max LSP Bandwidth at priority x.=20 > >Much thanks, >Lou > >On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote: >> All- >>=20 >> This impacts existing implementations based on draft versions (and hence >> interop with these implementations moving forward). IMO this is a bigger >> change for us to assume at the last call stage. Furthermore we have been >> using IEEE floating point format for Unreserved Bandwidth/ Max LSP BW in >> IEEE floating point format for other technologies. Overall, I think this >> change suffers from the "law of diminishing returns". >>=20 >> Thanks >>=20 >> Regards =A9 Zafar >>=20 >>=20 >> On 1/27/13 10:28 AM, "Gruman, Fred" wrote: >>=20 >>> Hi Lou, Fatai, Daniele, >>> >>> I understand the latest change to the way bandwidth is signaled for >>> ODUflex(GFP), i.e., signaling the number of tributary slots N instead >>>of >>> the bandwidth rate in bps. I believe that this simplifies the >>>signaling >>> and interoperability so I'm in agreement with this change. >>> >>> However, it seems we are now inconsistent between how we represent >>> bandwidth in routing and signaling for ODUflex(GFP). Routing >>>advertises >>> the bandwidth using a floating point representation of bandwidth, while >>> signaling is using the number of tributary slots. It seems the same >>> benefits would be obtained by advertising the max LSP bandwidth and >>> unreserved bandwidth for ODUflex(GFP) in terms of the number of >>>tributary >>> slots. >>> >>> Fred >>> >>> >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>Of >>> Lou Berger >>> Sent: Wednesday, January 23, 2013 9:08 AM >>> To: Fatai Zhang >>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: [CCAMP] WG Last Call comments on >>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>> >>> Fatai, >>> >>> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>>> Hi Lou, >>>> >>>> For ODUflex(CBR), the formula is from [G.709-2012] and it has been >>>> discussed before, so please trust that there is no opportunity for >>>> misinterpretation. (Note that there are two cases, one is >>>> ODUflex(CBR) and another one is ODUflex(GFP)). >>>> >>>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >>> >>> Thanks for confirming my understanding. This raises the question of if >>> the new traffic should just apply to ODUFlex? Correct me if I'm wrong, >>> but I believe the [RFC4328] is sufficient in all other cases. This may >>> also make it easier for early implementations of the draft as then they >>> can limit code changes from the (-03) rev to only ODUflex LSPs. >>> >>> Just to be clear, I'm really just *asking* about this. As I said >>> before, I'm open on specifics... >>> >>> Any thoughts/comments? Authors? Implementors? >>> >>> Thanks, >>> Lou >>> >>> >>>> I will issue a new version tomorrow to capture all your comments. >>>> >>>> >>>> Best Regards >>>> >>>> Fatai >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Wednesday, January 23, 2013 2:11 AM >>>> To: Fatai Zhang >>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: Re: [CCAMP] WG Last Call comments on >>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>> >>>> Fatai, >>>> >>>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>>> Hi Lou, >>>>> >>>>> You said: >>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the value >>>>>>of >>>>>> this vs just carrying N? >>>>> >>>>> [Fatai] The original way (in version 04&05) is putting (N* Nominal >>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can >>>>> generalize to just use one single "Bit_Rate" field to carry IEEE >>>>> float number for both cases, it seems that you don't agree on this >>>>> value, :-) >>>> >>>> I've seen differences in calculated floating point values from >>>>different >>>> implementations, so I just want to ensure that such cases are avoided. >>>> I'm open to specific solutions and certainly will deffer on the >>>> specifics assuming there is no opportunity for >>>>misinterpretation/interop >>>> issues. I don't think the original passed this threshold, i.e.,: >>>> >>>> N =3D Ceiling of >>>> >>>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate >>>>tolerance) >>>> =20 >>>>--------------------------------------------------------------------- >>>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) >>>> >>>>> . Therefore, I (was) am saying that I am going to accept >>>>> your suggestion to carry N for ODUflex(GFP). We are discussing where >>>>> to put N for ODUflex(GFP). >>>>> >>>> >>>>> You said: >>>>>> bits in the control plane are generally cheap, IMO it's better to >>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>case). >>>>> >>>>> [Fatai] OK, I will add a new field (to occupy the reserved bits) to >>>>> carry N. >>>> >>>> As you see fit. >>>> >>>> Just to clarify my understanding, ODUflex and Virtual concatenation >>>>can >>>> never be combined for the same signal type/level, right? (Although an >>>> ODUflex client signal could be carried over a virtual concatenated >>>> ODUk). Is this correct or did I miss something in G709? >>>> >>>> Thanks, >>>> Lou >>>> >>>>> >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> Fatai >>>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Friday, January 18, 2013 1:42 AM >>>>> To: Fatai Zhang >>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>> >>>>> >>>>> >>>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>>> Hi Lou, >>>>>> >>>>>> To avoid misunderstanding, I would like to clarify more on the >>>>>> following point. >>>>>> >>>>>> >>>>>>>>>> It is better to have consistent format and the same meaning of >>>>>>>>>>one >>>>> field for both ODUflex(CBR) and GFP. This is why we have section 5.1 >>>>> &5.2 to describe the complex stuff. >>>>>>>>> I actually wasn't suggesting that N be carried in the bit rate >>>>>>>>> field. >>>>>>>>> The bit rate field can either be set as described or to zero >>>>>>>>>(i.e., >>>>>>>>> ignored). At the time, I was thinking about carrying N in the >>>>>>>>> reserved >>>>>>>>> field. But perhaps the right place is MT, if my understanding is >>>>>>>>> right >>>>>>>>> (would always be 1 otherwise). I'm open to either... >>>>>>>>> >>>>>>>> [Fatai] Why not just use "bit rate"field to carry "N"because "N" >>>>>>>> implies bit rate? I am OK if you like to use a new filed (like >>>>>>>>"TS >>>>>>>> Number") to occupy the reserved field even though that I prefer >>>>>>>>the >>>>>>>> original approach (ie., use "bit rate"field to carry "N"). >>>>>>> >>>>>>> Are you proposing dropping carrying bit rates represented as an >>>>>>>IEEE >>>>>>> floating point and just carrying N for ODUflex? This seems workable >>>>>>> to >>>>>>> me, but we should ensure that there are no significant objections. >>>>>> >>>>>> [Fatai] There are two usages for " Bit_Rate " field as described in >>>>>> the >>>>>> lines 287-310. >>>>>> >>>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates the nominal >>>>>>bit >>>>>> rate of ODUflex(CBR) expressed in bytes per second, encoded as a >>>>>> 32-bit >>>>>> IEEE single precision floating-point number. For this case, we MUST >>>>>> use >>>>>> 32-bit IEEE floating point instead of "N"(Please see more in section >>>>>> 5.1). >>>>> >>>>> I guess you really still need (to be based on) the client signal rate >>>>> at >>>>> the edges. >>>>> >>>>>> >>>>>> (2) For ODUflex(GFP), we can change the text (the lines from 305 >>>>>>to >>>>>> 310) based on your suggestion, ie., the Bit_Rate field is used to >>>>>> carry >>>>>> "N"to indicate the nominal bit rate of the >>>>>> ODUflex(GFP). >>>>> >>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the value >>>>>of >>>>> this vs just carrying N? >>>>> >>>>> >>>>>> >>>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") for >>>>>> these >>>>>> two cases, in this way, we can leave the "Reserved" bits for future. >>>>> >>>>> bits in the control plane are generally cheap, IMO it's better to >>>>>have >>>>> simpler encoding than to optimize every bit (or 8 in this case). >>>>> >>>>> Lou >>>>> >>>>>> >>>>>> Hope we are now at the same page. >>>>>> >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Fatai >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>=20 >>=20 >>=20 >>=20 >>=20 From zhangfatai@huawei.com Sun Jan 27 19:54:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1598D21F87CB for ; Sun, 27 Jan 2013 19:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.733, 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 4i8AMxeUylmV for ; Sun, 27 Jan 2013 19:54:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 37E0F21F87C6 for ; Sun, 27 Jan 2013 19:54:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANX62329; Mon, 28 Jan 2013 03:54:40 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 28 Jan 2013 03:54:12 +0000 Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 28 Jan 2013 03:54:38 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.01.0323.007; Mon, 28 Jan 2013 11:54:34 +0800 From: Fatai Zhang To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: Next steps on overlay Thread-Index: Ac36bemQNHMdz+KeTBOfZZLP6sIh3gCnPQEQ Date: Mon, 28 Jan 2013 03:54:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF8358592F9SZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] Next steps on overlay X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 03:54:44 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF8358592F9SZXEML552MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Deborah, Thanks for your mail, which reminds me to resume my draft [draft-zhang-ccam= p-gmpls-uni-app], :) Best Regards Fatai From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Friday, January 25, 2013 4:04 AM To: ccamp@ietf.org Subject: [CCAMP] Next steps on overlay CCAMP, There's been quite a bit of discussion on the list, we'd like to see progre= ss on this topic. Perhaps we've reached the point where it's time to update= /author drafts to reflect current positions. This can either be done in one= document or in multiple (authors' choice). We also note that multiple viewpoints on how overlays may be deployed/opera= ted have been discussed. We suggest that documenting these use cases, inclu= ding data plane and control plane relationships/boundaries, would be helpfu= l. Thanks, Deborah and Lou CCAMP Chairs --_000_F82A4B6D50F9464B8EBA55651F541CF8358592F9SZXEML552MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Deborah= ,

 = ;

Thanks for= your mail, which reminds me to resume my draft [draft-zhang-ccamp-gmpls-un= i-app], J

 = ;

 

 

 

Best Regards

 

Fatai

 = ;

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org= ] On Behalf Of BRUNGARD, DEBORAH A
Sent: Friday, January 25, 2013 4:04 AM
To: ccamp@ietf.org
Subject: [CCAMP] Next steps on overlay

 

CCAMP,=

 =

There’s been quite= a bit of discussion on the list, we’d like to see progress on this t= opic. Perhaps we’ve reached the point where it’s time to update= /author drafts to reflect current positions. This can either be done in one docume= nt or in multiple (authors’ choice).

 =

We also note that multip= le viewpoints on how overlays may be deployed/operated have been discussed.= We suggest that documenting these use cases, including data plane and control plane relationships/boundaries, would be helpful.

 =

Thanks,

Deborah and Lou

CCAMP Chairs<= /span>

 =

 =

--_000_F82A4B6D50F9464B8EBA55651F541CF8358592F9SZXEML552MBXchi_-- From cyril.margaria@nsn.com Mon Jan 28 00:36:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D20021F8505 for ; Mon, 28 Jan 2013 00:36:38 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XcMPkkB8ocl for ; Mon, 28 Jan 2013 00:36:37 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3316121F8501 for ; Mon, 28 Jan 2013 00:36:35 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r0S8a06i027479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Jan 2013 09:36:30 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r0S8Ze03023284; Mon, 28 Jan 2013 09:35:52 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 09:35:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jan 2013 09:35:08 +0100 Message-ID: In-Reply-To: <51003039.3040809@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Regarding IPR on draft-margaria-ccamp-lsp-attribute-ero-02 Thread-Index: Ac35mhMkPeoBrp+YQZ+QgExvrnYoLwDmCp7Q References: <50BE808B.8070808@labn.net> <50F43AE4.6090807@labn.net> <51003039.3040809@labn.net> From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext Lou Berger" , , "Giovanni Martinelli (giomarti)" , , X-OriginalArrivalTime: 28 Jan 2013 08:35:44.0140 (UTC) FILETIME=[76784CC0:01CDFD32] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4032 X-purgate-ID: 151667::1359362190-00003C02-554EEB41/0-0/0-0 Cc: CCAMP Subject: Re: [CCAMP] Regarding IPR on draft-margaria-ccamp-lsp-attribute-ero-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 08:36:38 -0000 Hi Lou,=20 The proposal is reasonable, I agree. Best regards / Mit freundlichen Gr=FC=DFen Cyril Margaria > -----Original Message----- > From: ext Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, January 23, 2013 7:47 PM > To: Margaria, Cyril (NSN - DE/Munich); dirk.schroetter@nutsix.de; > Giovanni Martinelli (giomarti); Steve.Balls@metaswitch.com; > Ben.Wright@metaswitch.com > Cc: CCAMP > Subject: Re: [CCAMP] Regarding IPR on draft-margaria-ccamp-lsp- > attribute-ero-02 >=20 > Authors, WG, > It seems that Dirk is no longer active in our WG or on the draft. > We'd like to propose the following in order to unblock progress on = this > draft: >=20 > 1) That Dirk's name be removed from the Authors/Contributor's section >=20 > 2) That Dirk's contribution to this draft to date be recognized in the > Acknowledgments section >=20 > 3) That these changes be made in > draft-margaria-ccamp-lsp-attribute-ero-03 >=20 > 4) That draft-margaria-ccamp-lsp-attribute-ero-03 then be accepted as > a WG document based the results of last month's poll > (http://www.ietf.org/mail-archive/web/ccamp/current/msg14293.html) >=20 > 5) That, baring any substantive objections, that the above take place > on or after Jan 31. >=20 > We can revisit 1 & 2 if Dirk responds to the IPR poll in future. >=20 > Thoughts/comments? >=20 > Lou (and Deborah) >=20 > On 1/14/2013 12:05 PM, Lou Berger wrote: > > Dirk, > > Please respond so that we can move this draft forward. > > > > Thank you, > > Lou > > > > PS CCAMP, if anyone knows how to contact Dirk please forward this > > message to him, or let us know who to reach him. > > > > On 12/4/2012 6:00 PM, Lou Berger wrote: > >> Authors, Contributors, (CCAMP) > >> > >> As part of the preparation for the poll on making this document a = WG > >> document: > >> > >> Are you aware of any IPR that applies to > >> draft-margaria-ccamp-lsp-attribute-ero-02? > >> > >> Please state either: > >> > >> "No, I'm not aware of any IPR that applies to this draft" > >> or > >> "Yes, I'm aware of IPR that applies to this draft" > >> > >> If so, has this IPR been disclosed in compliance with IETF IPR = rules > >> (see RFCs 3979, 4879, 3669 and 5378 for more details)? > >> > >> If yes to the above, please state either: > >> > >> "Yes, the IPR has been disclosed in compliance with IETF IPR > rules" > >> or > >> "No, the IPR has not been disclosed" > >> > >> If you answer no, please provide any additional details you think > >> appropriate. > >> > >> If you are listed as a document author or contributor please answer > >> the above by responding to this email regardless of whether or not > >> you are aware of any relevant IPR. This document will not advance > to > >> the next stage until a response has been received from each author > >> and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN > >> THIS MESSAGE'S TO LINES. > >> > >> If you are on the CCAMP WG email list but are not listed as an > author > >> or contributor, we remind you of your obligations under the IETF = IPR > >> rules which encourages you to notify the IETF if you are aware of > IPR > >> of others on an IETF contribution, or to refrain from participating > >> in any contribution or discussion related to your undisclosed IPR. > >> For more information, please see the RFCs listed above and > >> > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > >> > >> Thank you, > >> CCAMP WG Chairs > >> > >> PS Please include all listed in the headers of this message in your > >> response. > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > >> > >> > >> > >> > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > From daniele.ceccarelli@ericsson.com Mon Jan 28 02:08:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387D721F85B2 for ; Mon, 28 Jan 2013 02:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 vhfFBQOzJZHv for ; Mon, 28 Jan 2013 02:08:26 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C93A21F857D for ; Mon, 28 Jan 2013 02:08:21 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-c4-51064e14cb2c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 45.A5.10459.41E46015; Mon, 28 Jan 2013 11:08:20 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 11:08:19 +0100 From: Daniele Ceccarelli To: "Zafar Ali (zali)" , Lou Berger Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 Thread-Index: AQHN/PEB2kkAp9jOOkCmeb/zzouJx5hd+LEAgAAQ5ICAAHeoUA== Date: Mon, 28 Jan 2013 10:08:19 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48073D01@ESESSMB301.ericsson.se> References: <5105E684.4030607@labn.net> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvra6IH1ugwdZLohZP5txgsdg6+z6z RX/rbFaLjua3LBavd3xlt+hrPs/qwOYx5fdGVo+WI29ZPZYs+cnk8WFTM5vHl8uf2Tym/VrD FsAWxWWTkpqTWZZapG+XwJXx59ZUloKW8orNrb9ZGhj/FHcxcnJICJhIPJzzlhHCFpO4cG89 G4gtJHCIUWLzz/ouRi4gezGjxKqHD1i6GDk42ASsJJ4c8gGpERFwk9gwaTtYL7PAU0aJ+9t1 QWxhgSiJ3Xums0DUREssWtTHDGE7SWw51glWzyKgKvH3/GKwXbwC3hJP3jawQuzNkLg9rw+s lxMofvTyLCYQm1FAVmLC7kVQu8Qlbj2ZzwRxs4DEkj3nmSFsUYmXj/+xQtiKEjvPtjODnMws oCmxfpc+RKuixJTuh+wQawUlTs58wjKBUWwWkqmzEDpmIemYhaRjASPLKkb23MTMnPRyw02M wGg7uOW37g7GU+dEDjFKc7AoifOGuV4IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBYwm+0 p0nU88nNLb/ZcsqziyelKnousTnw0f/k86D36efdOCd+e34o67g2Q9HC8ksXvy/LP55j1B03 /+AGzb1TGS3PblvPdWtO5Nolc69eqwlgaeJ7/NGPlfvYn4A+88WndwneaE6R0Zjlob7pUoW8 8/aDP+fVH2E0tV9q4KapHrgqcCNLkeUWJZbijERDLeai4kQAZfK9F4QCAAA= Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" , CCAMP Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 10:08:27 -0000 IEFsbCwNCg0KSSB0aGluayB0aGUgY2hhbmdlcyBwcm9wb3NlZCBhcmUgbWVhbmluZ2Z1bCBhbmQg d291bGQgc3VwcG9ydCB0aGVtIGluIGFuIGluZGl2aWR1YWwgb3IgZWFybHkgV0cgZHJhZnQsIGJ1 dCB0aGV5IGRvbid0IHNlZW0gdG8gcHJvdmlkZSBzaWduaWZpY2F0aXZlIGFkdmFudGFnZXMgdG8g cmlzayBpbnRlcndvcmtpbmcgaXNzdWVzIHdpdGggZWFybHkgaW1wbGVtZW50YXRpb25zLg0KTW9y ZW92ZXIgdGhlIGNoYW5nZXMgZG9uJ3QgYWxsb3cgdXMgZ2V0dGluZyB0b3RhbGx5IHJpZCBvZiBv ZiB0aGUgYml0X3JhdGUgZmllbGQgYXMgaXQgaXMgc3RpbGwgbmVlZGVkIGZvciBPRFVmbGV4IChD QlIpLg0KDQpNeSAyYw0KRGFuaWVsZQ0KDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PkZyb206IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxpQGNpc2NvLmNvbV0gDQo+U2VudDog bHVuZWTDrCAyOCBnZW5uYWlvIDIwMTMgNC40Nw0KPlRvOiBMb3UgQmVyZ2VyDQo+Q2M6IEdydW1h biwgRnJlZDsgRmF0YWkgWmhhbmc7IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVA7IA0KPmRyYWZ0 LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZw0KPlN1Ympl Y3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbiANCj5kcmFmdC1pZXRmLWNj YW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4NCj5IaSBMb3UtIA0KPg0KPlBsZWFzZSBz ZWUgaW4tbGluZS4NCj4NCj5UaGFua3MNCj4NCj5SZWdhcmRzLi4uWmFmYXINCj4NCj5PbiAxLzI3 LzEzIDk6NDYgUE0sICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+DQo+ PlphZmFyLA0KPj4JSXMgeW91ciBjb21tZW50IHdpdGggcmVzcGVjdCB0byBqdXN0IHJvdXRpbmcg b3IgYm90aCANCj5zaWduYWxpbmcgYW5kIA0KPj5yb3V0aW5nPw0KPg0KPkJvdGgsIGluY2x1ZGlu ZyBjb25zaXN0ZW5jeSBiZXR3ZWVuIHNpZ25hbGluZyBhbmQgcm91dGluZyBhdHRyaWJ1dGVzLg0K Pg0KPj4NCj4+QWxzbywgd2hlbiB5b3Ugc2F5ICJpbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZHJh ZnQgdmVyc2lvbnMiLCANCj5kbyB0aGVzZSANCj4+aW1wbGVtZW50YXRpb25zIGluY2x1ZGUgc3Vw cG9ydCBmb3IgT0RVZmxleD8gIChXaGljaCBoYXMgcmVhbGx5IGJlZW4gDQo+PnRoZSBmb2N1cyBv ZiB0aGUgZGlzY3Vzc2lvbi4pDQo+DQo+WWVzLCBJIHdhcyByZWZlcnJpbmcgdG8gT0RVRmxleC4g QXMgeW91IGtub3csIGZpeGVkIE9EVSBpcyANCj5zaWduYWxlZCB2aWEgbGV2ZWwgKDAgQlcpIHNv IGl0cyBub3QgYW4gaXNzdWUuDQo+DQo+Pg0KPj5CVFcgSSB0b29rIEZyZWQncyBjb21tZW50cyBh cyByZWxhdGVkIHRvIGp1c3QgdGhlIG5ldyANCj5PVE4tc3BlY2lmaWMgSVNDRCANCj4+ZGVmaW5p dGlvbnMgKHNlY3Rpb24gNC4xLjIgb2Ygb3NwZi1nNzA5djMtMDUsIGluIHBhcnRpY3VsYXIpLiAg Tm90ZSANCj4+dGhhdCBzZWN0aW9uIDQuMS4xIGFscmVhZHkgY2FycmllcyBOIChudW1iZXIgb2Yg T0RVcykgbm90IA0KPklFRUUgZmxvYXRpbmcgDQo+PnBvaW50IHJlcHJlc2VudGF0aW9ucyBvZiBh dmFpbGFibGUgYmFuZHdpZHRoLg0KPg0KPldoYXQgSSBtZWFudCBpcyBVbnJlc2VydmVkIEJhbmR3 aWR0aCBhdCBwcmlvcml0eSB4IGFuZCBNYXggTFNQIA0KPkJhbmR3aWR0aCBhdCBwcmlvcml0eSB4 LiANCj4NCj4+DQo+Pk11Y2ggdGhhbmtzLA0KPj5Mb3UNCj4+DQo+Pk9uIDEvMjcvMjAxMyA3OjQ2 IFBNLCBaYWZhciBBbGkgKHphbGkpIHdyb3RlOg0KPj4+IEFsbC0NCj4+PiANCj4+PiBUaGlzIGlt cGFjdHMgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIGRyYWZ0IHZlcnNpb25zIChh bmQgDQo+Pj4gaGVuY2UgaW50ZXJvcCB3aXRoIHRoZXNlIGltcGxlbWVudGF0aW9ucyBtb3Zpbmcg Zm9yd2FyZCkuIA0KPklNTyB0aGlzIGlzIA0KPj4+IGEgYmlnZ2VyIGNoYW5nZSBmb3IgdXMgdG8g YXNzdW1lIGF0IHRoZSBsYXN0IGNhbGwgc3RhZ2UuIA0KPkZ1cnRoZXJtb3JlIA0KPj4+IHdlIGhh dmUgYmVlbiB1c2luZyBJRUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCBmb3IgVW5yZXNlcnZlZCAN Cj4+PiBCYW5kd2lkdGgvIE1heCBMU1AgQlcgaW4gSUVFRSBmbG9hdGluZyBwb2ludCBmb3JtYXQg Zm9yIG90aGVyIA0KPj4+IHRlY2hub2xvZ2llcy4gT3ZlcmFsbCwgSSB0aGluayB0aGlzIGNoYW5n ZSBzdWZmZXJzIGZyb20gdGhlIA0KPiJsYXcgb2YgZGltaW5pc2hpbmcgcmV0dXJucyIuDQo+Pj4g DQo+Pj4gVGhhbmtzDQo+Pj4gDQo+Pj4gUmVnYXJkcyDFoCBaYWZhcg0KPj4+IA0KPj4+IA0KPj4+ IE9uIDEvMjcvMTMgMTA6MjggQU0sICJHcnVtYW4sIEZyZWQiIA0KPjxmcmVkLmdydW1hbkB1cy5m dWppdHN1LmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4+IEhpIExvdSwgRmF0YWksIERhbmllbGUsDQo+ Pj4+DQo+Pj4+IEkgdW5kZXJzdGFuZCB0aGUgbGF0ZXN0IGNoYW5nZSB0byB0aGUgd2F5IGJhbmR3 aWR0aCBpcyANCj5zaWduYWxlZCBmb3IgIA0KPj4+Pk9EVWZsZXgoR0ZQKSwgaS5lLiwgc2lnbmFs aW5nIHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3RzIA0KPk4gaW5zdGVhZCANCj4+Pj5vZiAg dGhlIGJhbmR3aWR0aCByYXRlIGluIGJwcy4gIEkgYmVsaWV2ZSB0aGF0IHRoaXMgc2ltcGxpZmll cyB0aGUgDQo+Pj4+c2lnbmFsaW5nICBhbmQgaW50ZXJvcGVyYWJpbGl0eSBzbyBJJ20gaW4gYWdy ZWVtZW50IHdpdGggDQo+dGhpcyBjaGFuZ2UuDQo+Pj4+DQo+Pj4+IEhvd2V2ZXIsIGl0IHNlZW1z IHdlIGFyZSBub3cgaW5jb25zaXN0ZW50IGJldHdlZW4gaG93IHdlIA0KPnJlcHJlc2VudCAgDQo+ Pj4+YmFuZHdpZHRoIGluIHJvdXRpbmcgYW5kIHNpZ25hbGluZyBmb3IgT0RVZmxleChHRlApLiAg Um91dGluZyANCj4+Pj5hZHZlcnRpc2VzICB0aGUgYmFuZHdpZHRoIHVzaW5nIGEgZmxvYXRpbmcg cG9pbnQgcmVwcmVzZW50YXRpb24gb2YgDQo+Pj4+YmFuZHdpZHRoLCB3aGlsZSAgc2lnbmFsaW5n IGlzIHVzaW5nIHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3RzLiANCj4+Pj5JdCBzZWVtcyB0 aGUgc2FtZSAgYmVuZWZpdHMgd291bGQgYmUgb2J0YWluZWQgYnkgDQo+YWR2ZXJ0aXNpbmcgdGhl IG1heCANCj4+Pj5MU1AgYmFuZHdpZHRoIGFuZCAgdW5yZXNlcnZlZCBiYW5kd2lkdGggZm9yIE9E VWZsZXgoR0ZQKSBpbiANCj50ZXJtcyBvZiANCj4+Pj50aGUgbnVtYmVyIG9mIHRyaWJ1dGFyeSAg c2xvdHMuDQo+Pj4+DQo+Pj4+IEZyZWQNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4+PkJlaGFsZiBPZiAgTG91IEJlcmdl cg0KPj4+PiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgOTowOCBBTQ0KPj4+PiBU bzogRmF0YWkgWmhhbmcNCj4+Pj4gQ2M6IENDQU1QOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNp Z25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0g V0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2ln bmFsaW5nLWc3MDl2My0wNA0KPj4+Pg0KPj4+PiBGYXRhaSwNCj4+Pj4NCj4+Pj4gT24gMS8yMy8y MDEzIDY6NDkgQU0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4gSGkgTG91LA0KPj4+Pj4NCj4+ Pj4+IEZvciBPRFVmbGV4KENCUiksIHRoZSBmb3JtdWxhIGlzIGZyb20gW0cuNzA5LTIwMTJdIGFu ZCBpdCANCj5oYXMgYmVlbiANCj4+Pj4+IGRpc2N1c3NlZCBiZWZvcmUsIHNvIHBsZWFzZSB0cnVz dCB0aGF0IHRoZXJlIGlzIG5vIA0KPm9wcG9ydHVuaXR5IGZvciANCj4+Pj4+IG1pc2ludGVycHJl dGF0aW9uLiAoTm90ZSB0aGF0IHRoZXJlIGFyZSB0d28gY2FzZXMsIG9uZSBpcw0KPj4+Pj4gT0RV ZmxleChDQlIpIGFuZCBhbm90aGVyIG9uZSBpcyBPRFVmbGV4KEdGUCkpLg0KPj4+Pj4NCj4+Pj4+ IEluIGFkZHRpb24sIE9EVWZsZXggY2Fubm90IGJlIGNvbmNhdGVuYXRlZCBieSBbRy43MDktMjAx Ml0uDQo+Pj4+DQo+Pj4+IFRoYW5rcyBmb3IgY29uZmlybWluZyBteSB1bmRlcnN0YW5kaW5nLiAg VGhpcyByYWlzZXMgdGhlIA0KPnF1ZXN0aW9uIG9mIA0KPj4+PiBpZiB0aGUgbmV3IHRyYWZmaWMg c2hvdWxkIGp1c3QgYXBwbHkgdG8gT0RVRmxleD8gIENvcnJlY3QgDQo+bWUgaWYgSSdtIA0KPj4+ PiB3cm9uZywgYnV0IEkgYmVsaWV2ZSB0aGUgW1JGQzQzMjhdIGlzIHN1ZmZpY2llbnQgaW4gYWxs IA0KPm90aGVyIGNhc2VzLiAgDQo+Pj4+IFRoaXMgbWF5IGFsc28gbWFrZSBpdCBlYXNpZXIgZm9y IGVhcmx5IGltcGxlbWVudGF0aW9ucyBvZiANCj50aGUgZHJhZnQgDQo+Pj4+IGFzIHRoZW4gdGhl eSBjYW4gbGltaXQgY29kZSBjaGFuZ2VzIGZyb20gdGhlICgtMDMpIHJldiB0byANCj5vbmx5IE9E VWZsZXggTFNQcy4NCj4+Pj4NCj4+Pj4gSnVzdCB0byBiZSBjbGVhciwgSSdtIHJlYWxseSBqdXN0 ICphc2tpbmcqIGFib3V0IHRoaXMuICBBcyBJIHNhaWQgDQo+Pj4+IGJlZm9yZSwgSSdtIG9wZW4g b24gc3BlY2lmaWNzLi4uDQo+Pj4+DQo+Pj4+IEFueSB0aG91Z2h0cy9jb21tZW50cz8gQXV0aG9y cz8gIEltcGxlbWVudG9ycz8NCj4+Pj4NCj4+Pj4gVGhhbmtzLA0KPj4+PiBMb3UNCj4+Pj4NCj4+ Pj4NCj4+Pj4+IEkgd2lsbCBpc3N1ZSBhIG5ldyB2ZXJzaW9uIHRvbW9ycm93IHRvIGNhcHR1cmUg YWxsIHlvdXIgY29tbWVudHMuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+ Pj4NCj4+Pj4+IEZhdGFpDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0N Cj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMywgMjAxMyAyOjExIEFNDQo+Pj4+PiBU bzogRmF0YWkgWmhhbmcNCj4+Pj4+IENjOiBDQ0FNUDsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1z aWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1Q XSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24NCj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt c2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4NCj4+Pj4+IEZhdGFpLA0KPj4+Pj4NCj4+Pj4+IE9u IDEvMjAvMjAxMyA5OjQzIFBNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+PiBIaSBMb3UsDQo+ Pj4+Pj4NCj4+Pj4+PiBZb3Ugc2FpZDoNCj4+Pj4+Pj4gYnV0IHlvdSdyZSBzYXlzIGVuY29kZWQg YXMgKE4qTm9taW5hbCBSYXRlKSByaWdodD8gV2F0J3MgdGhlIA0KPj4+Pj4+PnZhbHVlIG9mICB0 aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+Pj4+Pg0KPj4+Pj4+IFtGYXRhaV0gVGhlIG9yaWdp bmFsIHdheSAoaW4gdmVyc2lvbiAwNCYwNSkgaXMgcHV0dGluZyANCj4oTiogTm9taW5hbA0KPj4+ Pj4+IFJhdGUpIGluICJCaXRfUmF0ZSIgZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSwgdGhlIHZhbHVl IGlzIHRoYXQgd2UgDQo+Pj4+Pj4gY2FuIGdlbmVyYWxpemUgdG8ganVzdCB1c2Ugb25lIHNpbmds ZSAiQml0X1JhdGUiIGZpZWxkIHRvIGNhcnJ5IA0KPj4+Pj4+IElFRUUgZmxvYXQgbnVtYmVyIGZv ciBib3RoIGNhc2VzLCBpdCBzZWVtcyB0aGF0IHlvdSANCj5kb24ndCBhZ3JlZSBvbiANCj4+Pj4+ PiB0aGlzIHZhbHVlLCA6LSkNCj4+Pj4+DQo+Pj4+PiBJJ3ZlIHNlZW4gZGlmZmVyZW5jZXMgaW4g Y2FsY3VsYXRlZCBmbG9hdGluZyBwb2ludCB2YWx1ZXMgZnJvbSANCj4+Pj4+ZGlmZmVyZW50ICBp bXBsZW1lbnRhdGlvbnMsIHNvIEkganVzdCB3YW50IHRvIGVuc3VyZSB0aGF0IA0KPnN1Y2ggY2Fz ZXMgDQo+Pj4+PmFyZSBhdm9pZGVkLg0KPj4+Pj4gSSdtIG9wZW4gdG8gc3BlY2lmaWMgc29sdXRp b25zIGFuZCBjZXJ0YWlubHkgd2lsbCBkZWZmZXIgb24gdGhlICANCj4+Pj4+c3BlY2lmaWNzIGFz c3VtaW5nIHRoZXJlIGlzIG5vIG9wcG9ydHVuaXR5IGZvciANCj4+Pj4+bWlzaW50ZXJwcmV0YXRp b24vaW50ZXJvcCAgaXNzdWVzLiBJIGRvbid0IHRoaW5rIHRoZSANCj5vcmlnaW5hbCBwYXNzZWQg DQo+Pj4+PnRoaXMgdGhyZXNob2xkLCBpLmUuLDoNCj4+Pj4+DQo+Pj4+PiAgICAgICAgICBOID0g Q2VpbGluZyBvZg0KPj4+Pj4NCj4+Pj4+ICAgIE9EVWZsZXgoQ0JSKSBub21pbmFsIGJpdCByYXRl ICogKDEgKyBPRFVmbGV4KENCUikgYml0IHJhdGUNCj4+Pj4+dG9sZXJhbmNlKQ0KPj4+Pj4gICAg DQo+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+LS0tLS0tLS0tLQ0KPj4+Pj4gICAgICAgIE9EVFVrLnRzIG5vbWluYWwgYml0 IHJhdGUgKiAoMSAtIEhPIE9QVWsgYml0IHJhdGUgDQo+dG9sZXJhbmNlKQ0KPj4+Pj4NCj4+Pj4+ PiAuIFRoZXJlZm9yZSwgSSAod2FzKSBhbSBzYXlpbmcgdGhhdCBJIGFtIGdvaW5nIHRvIGFjY2Vw dCB5b3VyIA0KPj4+Pj4+IHN1Z2dlc3Rpb24gdG8gY2FycnkgTiBmb3IgT0RVZmxleChHRlApLiBX ZSBhcmUgDQo+ZGlzY3Vzc2luZyB3aGVyZSB0byANCj4+Pj4+PiBwdXQgTiBmb3IgT0RVZmxleChH RlApLg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4+IFlvdSBzYWlkOg0KPj4+Pj4+PiBiaXRzIGluIHRo ZSBjb250cm9sIHBsYW5lIGFyZSBnZW5lcmFsbHkgY2hlYXAsIElNTyBpdCdzIA0KPmJldHRlciB0 byAgDQo+Pj4+Pj4+aGF2ZSBzaW1wbGVyIGVuY29kaW5nIHRoYW4gdG8gb3B0aW1pemUgZXZlcnkg Yml0IChvciA4IGluIHRoaXMgDQo+Pj4+Pj4+Y2FzZSkuDQo+Pj4+Pj4NCj4+Pj4+PiBbRmF0YWld IE9LLCBJIHdpbGwgYWRkIGEgbmV3IGZpZWxkICh0byBvY2N1cHkgdGhlIHJlc2VydmVkIGJpdHMp IA0KPj4+Pj4+IHRvIGNhcnJ5IE4uDQo+Pj4+Pg0KPj4+Pj4gQXMgeW91IHNlZSBmaXQuDQo+Pj4+ Pg0KPj4+Pj4gSnVzdCB0byBjbGFyaWZ5IG15IHVuZGVyc3RhbmRpbmcsIE9EVWZsZXggYW5kIFZp cnR1YWwgDQo+Y29uY2F0ZW5hdGlvbiANCj4+Pj4+Y2FuICBuZXZlciBiZSBjb21iaW5lZCBmb3Ig dGhlIHNhbWUgc2lnbmFsIHR5cGUvbGV2ZWwsIHJpZ2h0PyANCj4+Pj4+KEFsdGhvdWdoIGFuICBP RFVmbGV4IGNsaWVudCBzaWduYWwgY291bGQgYmUgY2FycmllZCBvdmVyIA0KPmEgdmlydHVhbCAN Cj4+Pj4+Y29uY2F0ZW5hdGVkICBPRFVrKS4gIElzIHRoaXMgY29ycmVjdCBvciBkaWQgSSBtaXNz IHNvbWV0aGluZyBpbiANCj4+Pj4+RzcwOT8NCj4+Pj4+DQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiBM b3UNCj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+ Pj4+Pj4NCj4+Pj4+PiBGYXRhaQ0KPj4+Pj4+DQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0N Cj4+Pj4+PiBTZW50OiBGcmlkYXksIEphbnVhcnkgMTgsIDIwMTMgMTo0MiBBTQ0KPj4+Pj4+IFRv OiBGYXRhaSBaaGFuZw0KPj4+Pj4+IENjOiBDQ0FNUDsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1z aWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FN UF0gV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24g MS8xNS8yMDEzIDEwOjE2IFBNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+Pj4gSGkgTG91LA0K Pj4+Pj4+Pg0KPj4+Pj4+PiBUbyBhdm9pZCBtaXN1bmRlcnN0YW5kaW5nLCBJIHdvdWxkIGxpa2Ug dG8gY2xhcmlmeSBtb3JlIG9uIHRoZSANCj4+Pj4+Pj4gZm9sbG93aW5nIHBvaW50Lg0KPj4+Pj4+ Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gSXQgaXMgYmV0dGVyIHRvIGhhdmUgY29uc2lzdGVudCBm b3JtYXQgYW5kIHRoZSBzYW1lIG1lYW5pbmcgDQo+Pj4+Pj4+Pj4+Pm9mIG9uZQ0KPj4+Pj4+IGZp ZWxkIGZvciBib3RoIE9EVWZsZXgoQ0JSKSBhbmQgR0ZQLiBUaGlzIGlzIHdoeSB3ZSBoYXZlIHNl Y3Rpb24gDQo+Pj4+Pj4gNS4xDQo+Pj4+Pj4gJjUuMiB0byBkZXNjcmliZSB0aGUgY29tcGxleCBz dHVmZi4NCj4+Pj4+Pj4+Pj4gSSBhY3R1YWxseSB3YXNuJ3Qgc3VnZ2VzdGluZyB0aGF0IE4gYmUg Y2FycmllZCBpbiANCj50aGUgYml0IHJhdGUgIA0KPj4+Pj4+Pj4+PmZpZWxkLg0KPj4+Pj4+Pj4+ PiBUaGUgYml0IHJhdGUgZmllbGQgY2FuIGVpdGhlciBiZSBzZXQgYXMgZGVzY3JpYmVkIG9yIHRv IHplcm8gDQo+Pj4+Pj4+Pj4+KGkuZS4sICBpZ25vcmVkKS4gIEF0IHRoZSB0aW1lLCBJIHdhcyB0 aGlua2luZyBhYm91dCANCj5jYXJyeWluZyBOIA0KPj4+Pj4+Pj4+PmluIHRoZSAgcmVzZXJ2ZWQg IGZpZWxkLiBCdXQgcGVyaGFwcyB0aGUgcmlnaHQgcGxhY2UgDQo+aXMgTVQsIGlmIA0KPj4+Pj4+ Pj4+Pm15IHVuZGVyc3RhbmRpbmcgaXMgIHJpZ2h0ICAod291bGQgYWx3YXlzIGJlIDEgDQo+b3Ro ZXJ3aXNlKS4gSSdtIA0KPj4+Pj4+Pj4+Pm9wZW4gdG8gZWl0aGVyLi4uDQo+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gW0ZhdGFpXSBXaHkgbm90IGp1c3QgdXNlICJiaXQgcmF0ZSJmaWVsZCB0byBjYXJy eSANCj4iTiJiZWNhdXNlICJOIg0KPj4+Pj4+Pj4+IGltcGxpZXMgYml0IHJhdGU/ICBJIGFtIE9L IGlmIHlvdSBsaWtlIHRvIHVzZSBhIG5ldyANCj5maWxlZCAobGlrZSANCj4+Pj4+Pj4+PiJUUw0K Pj4+Pj4+Pj4+IE51bWJlciIpIHRvIG9jY3VweSB0aGUgcmVzZXJ2ZWQgZmllbGQgZXZlbiB0aG91 Z2ggDQo+dGhhdCBJIHByZWZlciANCj4+Pj4+Pj4+PnRoZSAgb3JpZ2luYWwgYXBwcm9hY2ggKGll LiwgdXNlICJiaXQgcmF0ZSJmaWVsZCB0byBjYXJyeSAiTiIpLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IEFyZSB5b3UgcHJvcG9zaW5nIGRyb3BwaW5nIGNhcnJ5aW5nIGJpdCByYXRlcyANCj5yZXByZXNl bnRlZCBhcyBhbiANCj4+Pj4+Pj4+SUVFRSAgZmxvYXRpbmcgcG9pbnQgYW5kIGp1c3QgY2Fycnlp bmcgTiBmb3IgT0RVZmxleD8gDQo+VGhpcyBzZWVtcyANCj4+Pj4+Pj4+d29ya2FibGUgIHRvICBt ZSwgYnV0IHdlIHNob3VsZCBlbnN1cmUgdGhhdCB0aGVyZSBhcmUgbm8gDQo+Pj4+Pj4+PnNpZ25p ZmljYW50IG9iamVjdGlvbnMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFtGYXRhaV0gVGhlcmUgYXJlIHR3 byB1c2FnZXMgZm9yICIgQml0X1JhdGUgIiBmaWVsZCBhcyANCj5kZXNjcmliZWQgDQo+Pj4+Pj4+ IGluIHRoZSBsaW5lcyAyODctMzEwLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAoMSkgICAgRm9yIE9EVWZs ZXgoQ0JSKSwgdGhlIEJpdF9SYXRlIGZpZWxkIGluZGljYXRlcyANCj50aGUgbm9taW5hbA0KPj4+ Pj4+PmJpdA0KPj4+Pj4+PiByYXRlIG9mIE9EVWZsZXgoQ0JSKSBleHByZXNzZWQgaW4gYnl0ZXMg cGVyIHNlY29uZCwgDQo+ZW5jb2RlZCBhcyBhICANCj4+Pj4+Pj4zMi1iaXQgIElFRUUgc2luZ2xl IHByZWNpc2lvbiBmbG9hdGluZy1wb2ludCBudW1iZXIuIEZvciB0aGlzIA0KPj4+Pj4+PmNhc2Us IHdlIE1VU1QgIHVzZSAgMzItYml0IElFRUUgZmxvYXRpbmcgcG9pbnQgaW5zdGVhZCBvZiANCj4+ Pj4+Pj4iTiIoUGxlYXNlIHNlZSBtb3JlIGluIHNlY3Rpb24gIDUuMSkuDQo+Pj4+Pj4NCj4+Pj4+ PiBJIGd1ZXNzIHlvdSByZWFsbHkgc3RpbGwgbmVlZCAodG8gYmUgYmFzZWQgb24pIHRoZSBjbGll bnQgc2lnbmFsIA0KPj4+Pj4+IHJhdGUgYXQgdGhlIGVkZ2VzLg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+ Pj4+Pj4+ICgyKSAgICBGb3IgT0RVZmxleChHRlApLCB3ZSBjYW4gY2hhbmdlIHRoZSB0ZXh0ICh0 aGUgDQo+bGluZXMgZnJvbSAzMDUNCj4+Pj4+Pj50bw0KPj4+Pj4+PiAzMTApIGJhc2VkIG9uIHlv dXIgc3VnZ2VzdGlvbiwgaWUuLCB0aGUgQml0X1JhdGUgZmllbGQgDQo+aXMgdXNlZCB0byAgDQo+ Pj4+Pj4+Y2FycnkgICJOInRvIGluZGljYXRlIHRoZSBub21pbmFsIGJpdCByYXRlIG9mIHRoZSAg T0RVZmxleChHRlApLg0KPj4+Pj4+DQo+Pj4+Pj4gYnV0IHlvdSdyZSBzYXlzIGVuY29kZWQgYXMg KE4qTm9taW5hbCBSYXRlKSByaWdodD8gIFdhdCdzIHRoZSANCj4+Pj4+PnZhbHVlIG9mICB0aGlz IHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRo ZXJlZm9yZSwgSSBhbSBwcm9wb3NpbmcgdXNpbmcgb25lIHNpbmdsZSBmaWxlZCAoIkJpdF9SYXRl ICIpIA0KPj4+Pj4+PiBmb3IgdGhlc2UgdHdvIGNhc2VzLCBpbiB0aGlzIHdheSwgd2UgY2FuIGxl YXZlIHRoZSAiUmVzZXJ2ZWQiIA0KPj4+Pj4+PiBiaXRzIGZvciBmdXR1cmUuDQo+Pj4+Pj4NCj4+ Pj4+PiBiaXRzIGluIHRoZSBjb250cm9sIHBsYW5lIGFyZSBnZW5lcmFsbHkgY2hlYXAsIElNTyBp dCdzIA0KPmJldHRlciB0byANCj4+Pj4+PmhhdmUgIHNpbXBsZXIgZW5jb2RpbmcgdGhhbiB0byBv cHRpbWl6ZSBldmVyeSBiaXQgKG9yIDggaW4gdGhpcyANCj4+Pj4+PmNhc2UpLg0KPj4+Pj4+DQo+ Pj4+Pj4gTG91DQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSG9wZSB3ZSBhcmUgbm93IGF0IHRo ZSBzYW1lIHBhZ2UuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+ Pj4+Pg0KPj4+Pj4+PiBGYXRhaQ0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4gQ0NBTVBA aWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+IA0KPj4+IA0KPj4+IA0K Pj4+IA0KPj4+IA0KPg0KPg== From daniele.ceccarelli@ericsson.com Mon Jan 28 08:29:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C7921F87D3 for ; Mon, 28 Jan 2013 08:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 I8Dlh3t9mC4c for ; Mon, 28 Jan 2013 08:29:42 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A742221F87C4 for ; Mon, 28 Jan 2013 08:29:41 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-7f-5106a7743900 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 03.8F.19728.477A6015; Mon, 28 Jan 2013 17:29:40 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 17:29:40 +0100 From: Daniele Ceccarelli To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: Next steps on overlay Thread-Index: Ac36bemQNHMdz+KeTBOfZZLP6sIh3gC+XFww Date: Mon, 28 Jan 2013 16:29:39 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48074083@ESESSMB301.ericsson.se> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48074083ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvrW7JcrZAg42tphZP5txgsbjc1c3u wOTxsn8Oo8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIW3PrIXPAmuOL/0onMDYyLPboYOTkkBEwk vqxcww5hi0lcuLeerYuRi0NI4BCjxMv9J5kgnMWMEpO/TmPtYuTgYBOwknhyyAfEFBHwlZg6 nQnEFBZQkjgxMxdkjIiAssSPrUuZIWwjiaYzb8HGswioSvxpvscKYvMKeEss39DCAmILCYRL 7H34AayeUyBC4sCndrAaRgFZiQm7FzGC2MwC4hK3nsxngjhTQGLJnvPMELaoxMvH/1ghbEWJ nWfbmSHq8yU2PrrHCLFLUOLkzCcsExhFZiEZNQtJ2SwkZRBxPYkbU6ewQdjaEssWvmaGsHUl Zvw7xIIsvoCRfRUje25iZk56udEmRmDcHNzyW3UH451zIocYpTlYlMR5w10vBAgJpCeWpGan phakFsUXleakFh9iZOLglGpgXDp9caQ9R01cvh2/f7oYu36mzdQ5R46cYYqMS2IpUDoeIHqx dIZdYc7ch6uOdBg+/bst3E9HINpJKVxkrcnbmR3f3ql43NrwK6yNZ5la84uZDNcPbTcJE4uS 5ex4HrLPu/2Nsm+QZHKQinzrpqVmq6NWvDi/Mb3r4SerecE/vy1IbticYsmjxFKckWioxVxU nAgAv1t242kCAAA= Subject: Re: [CCAMP] Next steps on overlay X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:29:44 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48074083ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Deborah, all, agree that it's time to sum up. As agreed in Atlanta draft-many-ccamp-gmpls-overlay-model will be updated in the= next days so to reflect the discussions of the last months on the list and= will try to reflect all the topics where there is no consensus and, if ava= ilable, list all the proposed alternatives. Basically: - The overall doc will reflect my latest summary (v2) including the followi= ng comments basically from Lou and Igor. - The terminology part will be based at the time being on VPNs (but open to= be modified if needed) - Use cases: will try to cover the ones in the E-NNI and L1VPN drafts. If m= ore of them are needed please contact me. - Description of the different advertisement models and service models. Bas= ically we are defining a general topology service model so that existing VP= N service models are particular cases of it. - Relationship with MLN/MRN: the overlay interfaces does not necessarily ne= ed to be placed on a link between different technology domains (e.g. IP and= WSON) but could be placed also withing the same NE between two layer of th= e same technology (e.g. an OTN deployment where the ODU3 layer is managed a= s a provided network providing connectivity between ODU2s which form the cl= ient network). In addition, wrt latest discussion on Additional Overlay Protocol Extension= s i think that's meat for the second document on the advertisement, where f= or each of them we need to say which info is needed AND NOT HOW IT ENCODED = OR TRANSPORTED. This final part will be addressed in the third document ded= icated to protocol extensions (this was the agreement in Atlanta and i thin= k there is no reason to move from that). It is definitely too early to move to doc #3 but we could start working on = #2. Most of its content, wrt the Virtual Links advertisement model (former = E-NNI) has already been widely explained by Igor and Lou, which seem to dis= agree on HOW to carry the info but not on WHICH of them are needed. BR Daniele ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: gioved=EC 24 gennaio 2013 21.04 To: ccamp@ietf.org Subject: [CCAMP] Next steps on overlay CCAMP, There's been quite a bit of discussion on the list, we'd like to see progre= ss on this topic. Perhaps we've reached the point where it's time to update= /author drafts to reflect current positions. This can either be done in one= document or in multiple (authors' choice). We also note that multiple viewpoints on how overlays may be deployed/opera= ted have been discussed. We suggest that documenting these use cases, inclu= ding data plane and control plane relationships/boundaries, would be helpfu= l. Thanks, Deborah and Lou CCAMP Chairs --_000_4A1562797D64E44993C5CBF38CF1BE48074083ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Deborah, all,
 
agree that it's time to sum up.
 
As agreed in Atlanta draft-many-ccamp-gmpls-overlay-model will be updated in the next d= ays so to reflect the discussions of the last months on the list = and will try to reflect all the topics where there is no consensus and, if = available, list all the proposed alternatives.
 
Basically:
 
- The overall doc will reflect my= latest summary (v2) including the following comments basically from Lou an= d Igor.
<= span class=3D"405215414-28012013">- The terminology part will be based at the time being on VPNs (bu= t open to be modified if needed)
- Use cases: will try to cover th= e ones in the E-NNI and L1VPN drafts. If more of them are needed please con= tact me.
- Description of the different ad= vertisement models and service models. Basically we are defining a general = topology service model so that existing VPN service models are particular cases of it.
- Relationship with MLN/MRN: the = overlay interfaces does not necessarily need to be placed on a link be= tween different technology domains (e.g. IP and WSON) but could be placed also withing the same NE between two layer of the same= technology (e.g. an OTN deployment where the ODU3 layer is managed as a pr= ovided network providing connectivity between ODU2s which form the client n= etwork).
 
In addition, wrt latest discussio= n on Additional Overlay Protocol Extensions i think that's meat for th= e second document on the advertisement, where for each of them we need to say which info is needed AND NOT HOW IT ENCODED OR= TRANSPORTED. This final part will be addressed in the third document dedic= ated to protocol extensions (this was the agreement in Atlanta and i think = there is no reason to move from that).
 
It is definitely too early to mov= e to doc #3 but we could start working on #2. Most of its content, wrt the = Virtual Links advertisement model (former E-NNI) has already been widely explained by Igor and Lou, which seem to disagree = on HOW to carry the info but not on WHICH of them are needed.=
 
BR
Daniele
 
 
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: gioved=EC 24 gennaio 2013 21.04
To: ccamp@ietf.org
Subject: [CCAMP] Next steps on overlay

CCAMP,
 
There’s been quite a bit of discussion on the list, we’d l= ike to see progress on this topic. Perhaps we’ve reached the point wh= ere it’s time to update/author drafts to reflect current positions. T= his can either be done in one document or in multiple (authors’ choice).
 
We also note that multiple viewpoints on how overlays may be deployed/= operated have been discussed. We suggest that documenting these use cases, = including data plane and control plane relationships/boundaries, would be h= elpful.
 
Thanks,
Deborah and Lou
CCAMP Chairs
 
 
--_000_4A1562797D64E44993C5CBF38CF1BE48074083ESESSMB301ericsso_-- From IBryskin@advaoptical.com Mon Jan 28 08:45:14 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46821F88B9 for ; Mon, 28 Jan 2013 08:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_20=-0.74] 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 MI6e9BnsBGmS for ; Mon, 28 Jan 2013 08:45:13 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1379221F891D for ; Mon, 28 Jan 2013 08:45:12 -0800 (PST) Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0SGj6is028859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 17:45:06 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Mon, 28 Jan 2013 17:45:06 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Mon, 28 Jan 2013 11:45:04 -0500 From: Igor Bryskin To: John E Drake , "BRUNGARD, DEBORAH A" Thread-Topic: The hat trick Thread-Index: Ac39ZaelYtW7hPW6Q/qy/QKuSXA6zA== Date: Mon, 28 Jan 2013 16:45:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.46.146.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-28_03:2013-01-28, 2013-01-28, 1970-01-01 signatures=0 Cc: CCAMP Subject: [CCAMP] The hat trick X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:45:14 -0000 John, You said: I disagree. Airing dirty laundry in public is too entertaining t= o stop. All right then, here is another topic for you.=20 You are very respectable IETFer and seem to be here forever (certainly sinc= e I can remember myself). I wonder what do you (and other CCAMPers) think a= bout these cute little "My hat on/off" statements? That's right, the ones = that IETF ADs and WG Chairs do with a coquettish smile quite often at IETF = meetings and on the mailing lists. The assumption is, of course, that the t= hings must be said by ADs/Chairs and interpreted by the audience differentl= y depending on whether the hat is said to be in "on" or "off" position. Thi= s is a quite safe and reasonable assumption, if one designs a signaling pro= tocol for network elements, for which it is possible to set proper filters,= program processing rules and maintain a separate independent state for eac= h conversation. However, ADs, Chairs and the audience are humans, i.e. they= are not very good at compartmentalizing the information in non-overlapping= memory spaces. When I, for one, hear or read an AD's/Chair's statement, th= e statement always carries the AD/Chair weight.=20 Let's take an example. Consider in a middle of a heated technical discussio= n on a CCAMP WG session, Adrian comes up to the mike and makes his hat-off= comment. What does this exactly mean? Does it mean that Adrian may have a = separate hat-on opinion, that is opposite or perpendicular to what he just = said? I don't think so. The way I see it, Adrian, being an excellent expert= in many areas, has developed an opinion that he genuinely believes may hel= p the discussion. But, being also very professional, Adrian believes that = at this level of discussion (or for whatever other reasons) it is somewhat = inappropriate for an AD to influence the discussion. The end result of the = statement is as follows. I, Igor Bryskin, am sitting in the audience and ju= st heard a statement that might very well influence the discussion and its = outcome. The statement came from Adrian Farrel, who happens to be one of th= e Routing Area ADs (and I don't forget about this for a second) at the prec= ise moment when according to Adrian himself it is inappropriate for an AD t= o influence the discussion. I might remember the statement for quite a whil= e, and I may communicate the statement to other some 37 people. What I will= immediately forget is what Adrian has said about his hat, and this informa= tion will be lost on me and these 37 poor souls. I am sure that the same ha= ppens to most (if not all) of the crowd. I have never read, for example, e= mails like: " Dear Adrian (with your AD hat on)! Thank you very much for your thoughtfu= l comments on our draft...." or "Adrian (with his AD hat off) suggested to use his favorite LSP_ATTRIBUTES = object, but I don't hate this idea and since it was suggested with the hat = off, I think it is Ok to simply ignore the suggestion". Nor I remember a conversation like: "Igor, listen, I am about to make my XYZ draft last call vote. When Lou mad= e this comment on the ASSOCIATION object, could you tell me where his hat w= as?" "Sorry, John, I have to come back to you with that: I have to go throu= gh the meetings minutes as well as through some 1013 emails that Lou has po= sted on the list since then. I am afraid, you will be late with your vote" Furthermore, ADs and Chairs do not talk just on the sessions and mailing li= sts. There are also private emails, telephone calls, face-to-face meetings = even bar conversations. Call me a pessimist, but I doubt that in all these = circumstances ADs/Chairs do not forget to update their hat status (especial= ly in the bar). So, the point is that the "Hat on/off" thing does not reall= y work as intended, which is not a problem per-se. The problem is that inte= ntionally or unintentionally this opens up ways for quite unfair play. I don't know what you, John, know about football (soccer), but imagine a ma= tch between two teams - one in red, one in white - and there is a guy on th= e pitch with a hat: when the hat is on, the guy is the umpire of the game, = when the hat is off, he is a striker for the reds. You can imagine a lot of= funny things happening in such a game. For example, the guy with his umpir= e hat on can pick up a proper situation and moment, stop the game and grant= a penalty against whites. Then, with the hat off, he can take the penalty = and score for the reads. And when it looks like the whites are about to sco= re the equalizer, the guy can put his umpire hat back, blow the whistle and= say: "Time is up, game is over, reds won". Fortunately such a thing cannot= happen in soccer: not only a guy cannot be in the same game an umpire and = a player of one of the teams, an umpire cannot be associated in any way wit= h one team more than with the other (an umpire cannot be even from the same= city or country as one team but not the other). Why is that? Simple, to en= sure fair play, so that a better, more deserving team wins and moves into t= he next round, while the bad team loses and gets kicked out of the competit= ion. That's what makes soccer such a beautiful game, by far the most popula= r in the world: simple well thought through rules and fair play". If you don't like my analogy with soccer, consider a criminal case trial in= the court of law, where the judge is saying something like this: " With my= judge hat off I have to say that I agree completely with the defense. Also= in my previous life I was both defense and district attorney, and my exper= ience of being involved in such or similar cases tells me that in 80% of th= e cases the defendant ends up verdicted as not guilty. Now, with my judge h= at back on, please, proceed ...." You may disagree with any of these analogies, but I hope you see where I am= getting at. With the hat trick It is quite possible to influence the IETF = game (which is creating RFCs) with the end result that it is possible for p= oor architectures and bad solutions to make into useless RFCs, while for go= od ideas to be killed and forgotten. Here is a simple question: When a WG Chair systematically pushes one soluti= on while vigorously fights off an alternative one, does it matter whether t= he Chair is doing this with his hat on or off, considering that at the end = of the day the Chair is the only one (along with co-Chairs) who gets to mak= e a call on rough consensus and hence to decide which solution wins? I say, no it does not matter, and this is unfair to you, John, because whi= le the Chair can take off his hat at any time, you, as a potential (co-)aut= hor of the alternative solution, cannot put the WG Chair hat on and overrul= e the call on the consensus. I suggest we nail down the hats to AD/Chair he= ads and outlaw the hat trick to be used as an excuse. In my opinion, WG cha= ir is, figuratively speaking, 75% soccer umpire and 25% soccer coach, but n= ever a soccer player. Does this make sense? Sorry for the long email. Cheers, Igor=20 From lberger@labn.net Mon Jan 28 08:50:14 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8B321F8871 for ; Mon, 28 Jan 2013 08:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.466 X-Spam-Level: X-Spam-Status: No, score=-101.466 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, 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 zGrSiqKV2q2W for ; Mon, 28 Jan 2013 08:50:13 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id D27E121F87FA for ; Mon, 28 Jan 2013 08:50:12 -0800 (PST) Received: (qmail 5694 invoked by uid 0); 28 Jan 2013 16:49:49 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 28 Jan 2013 16:49:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=a6Z8G8FETLo13CGqrz6J6h5x+gd4ySXzsVMzyYb4f44=; b=SsjeYnWzLm/iQm+7KknqGk2nEjm1L2r+NV4OMZG6tFtgtrdKZg5c1mmGs16cbvKvw34sxgdqIc7c2PSDimUKBe7NuDScmN4KPOps6q4QbzWpSGepvSlC2+SOINzBZX0G; Received: from box313.bluehost.com ([69.89.31.113]:38069 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Tzru1-0001B6-3z; Mon, 28 Jan 2013 09:49:49 -0700 Message-ID: <5106AC38.2010106@labn.net> Date: Mon, 28 Jan 2013 11:50:00 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Daniele Ceccarelli References: <4A1562797D64E44993C5CBF38CF1BE48074083@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48074083@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Next steps on overlay X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:50:14 -0000 Daniele, Much thanks for the summary. I look forward to the revised document. WRT > Most of its content, wrt the Virtual Links advertisement model > (former E-NNI) has already been widely explained by Igor and Lou, I think you give me too much credit. Looking at the archive, the majority of the comments/discussion were from/with others. I hope that their comments are incorporated as well. Lou (pick whichever hat you want!) On 1/28/2013 11:29 AM, Daniele Ceccarelli wrote: > Deborah, all, > > agree that it's time to sum up. > > As agreed in Atlanta draft-many-ccamp-gmpls-overlay-model > will > be updated in the next days so to reflect the discussions of the last > months on the list and will try to reflect all the topics where there is > no consensus and, if available, list all the proposed alternatives. > > Basically: > > - The overall doc will reflect my latest summary (v2) including the > following comments basically from Lou and Igor. > - The terminology part will be based at the time being on VPNs (but open > to be modified if needed) > - Use cases: will try to cover the ones in the E-NNI and L1VPN drafts. > If more of them are needed please contact me. > - Description of the different advertisement models and service models. > Basically we are defining a general topology service model so that > existing VPN service models are particular cases of it. > - Relationship with MLN/MRN: the overlay interfaces does not necessarily > need to be placed on a link between different technology domains (e.g. > IP and WSON) but could be placed also withing the same NE between two > layer of the same technology (e.g. an OTN deployment where the ODU3 > layer is managed as a provided network providing connectivity between > ODU2s which form the client network). > > In addition, wrt latest discussion on Additional Overlay Protocol > Extensions i think that's meat for the second document on the > advertisement, where for each of them we need to say which info is > needed AND NOT HOW IT ENCODED OR TRANSPORTED. This final part will be > addressed in the third document dedicated to protocol extensions (this > was the agreement in Atlanta and i think there is no reason to move from > that). > > It is definitely too early to move to doc #3 but we could start working > on #2. Most of its content, wrt the Virtual Links advertisement model > (former E-NNI) has already been widely explained by Igor and Lou, which > seem to disagree on HOW to carry the info but not on WHICH of them are > needed. > > BR > Daniele > > > ------------------------------------------------------------------------ > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On > Behalf Of *BRUNGARD, DEBORAH A > *Sent:* gioved 24 gennaio 2013 21.04 > *To:* ccamp@ietf.org > *Subject:* [CCAMP] Next steps on overlay > > CCAMP, > > There抯 been quite a bit of discussion on the list, we抎 like to see > progress on this topic. Perhaps we抳e reached the point where it抯 > time to update/author drafts to reflect current positions. This can > either be done in one document or in multiple (authors choice). > > We also note that multiple viewpoints on how overlays may be > deployed/operated have been discussed. We suggest that documenting > these use cases, including data plane and control plane > relationships/boundaries, would be helpful. > > Thanks, > Deborah and Lou > CCAMP Chairs > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From adrian@olddog.co.uk Mon Jan 28 09:54:00 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F61121F899E for ; Mon, 28 Jan 2013 09:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 at4he78RgNeC for ; Mon, 28 Jan 2013 09:54:00 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id DCBA421F8915 for ; Mon, 28 Jan 2013 09:53:59 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0SHruKn000421; Mon, 28 Jan 2013 17:53:56 GMT Received: from 950129200 (089144192153.atnat0001.highway.a1.net [89.144.192.153]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0SHrs8q000364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 17:53:56 GMT From: "Adrian Farrel" To: Date: Mon, 28 Jan 2013 17:53:54 -0000 Message-ID: <011901cdfd80$71ba04f0$552e0ed0$@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: Ac39gG6xz31b8uQ3RSqAvbO/VdOI4w== Content-Language: en-gb Subject: [CCAMP] Please focus your discussions on technical topics X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 17:54:00 -0000 Hi, This mailing list is described at https://www.ietf.org/mailman/listinfo/ccamp as follows: > This email list is the discussion list for the CCAMP working group in the > Routing Area of the IETF. It should be used under the normal rules and > provisions of IETF working group mailing lists with the coordination of > the CCAMP working group co-chairs. > > Any item within the CCAMP charter may be discussed on this list, but > items beyond the charter, spam, and mailshotting are not welcome. Discussions of IETF process may be raised on ietf@ietf.org. Concerns about the behavior of working group chairs should, in the first instance be raised with the chairs themselves. If that does not bring satisfaction, the issue should be brought to the ADs. As a matter of clarification (and not for further discussion on the CCAMP list!): All IETF participants regardless of their role may express technical opinions and, if they feel strongly, may express them forcefully but always politely and courteously. That means that WG chairs (yay, and even ADs) can express technical opinions during discussions. Sometimes the chairs/ADs feel it necessary to point out to the WG that the opinion they are expressing is just one voice in the crowd (i.e., they say they have taken their hat off). Chairs and ADs often have areas of experience where their voice is listened to carefully, but that is because of their experience not because of their IETF role. This is fundamental to the way the IETF operates and needs to be thought about carefully. Please feel free to contact me privately for any further explanations. Thanks, Adrian From jdrake@juniper.net Mon Jan 28 11:40:02 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7631621F86EF for ; Mon, 28 Jan 2013 11:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 MLuyi-eyY2eg for ; Mon, 28 Jan 2013 11:39:56 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 57B5B21F886D for ; Mon, 28 Jan 2013 11:39:53 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUQbUCcgKWsa7f1jHdQjDHAQNlHMHo7n3@postini.com; Mon, 28 Jan 2013 11:39:53 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 28 Jan 2013 11:37:19 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 28 Jan 2013 11:37:19 -0800 Received: from CO9EHSOBE038.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 28 Jan 2013 11:39:38 -0800 Received: from mail207-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.23; Mon, 28 Jan 2013 19:37:18 +0000 Received: from mail207-co9 (localhost [127.0.0.1]) by mail207-co9-R.bigfish.com (Postfix) with ESMTP id 24B366600CD for ; Mon, 28 Jan 2013 19:37:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -14 X-BigFish: PS-14(zz9371I1503M542Id79ah1432I11f6Nzz1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail207-co9 (localhost.localdomain [127.0.0.1]) by mail207-co9 (MessageSwitch) id 1359401836192156_30857; Mon, 28 Jan 2013 19:37:16 +0000 (UTC) Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.251]) by mail207-co9.bigfish.com (Postfix) with ESMTP id 2BCD494004C; Mon, 28 Jan 2013 19:37:16 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 28 Jan 2013 19:37:16 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.86]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0257.004; Mon, 28 Jan 2013 19:37:10 +0000 From: John E Drake To: Igor Bryskin , "BRUNGARD, DEBORAH A" Thread-Topic: The hat trick Thread-Index: Ac39ZaelYtW7hPW6Q/qy/QKuSXA6zAAJ8ofQ Date: Mon, 28 Jan 2013 19:37:09 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E0B710C3A@BL2PRD0510MB349.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ATT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: CCAMP Subject: Re: [CCAMP] The hat trick X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 19:40:02 -0000 Igor, I don't think Lou or Adrian would approve of my replying to your email. Seriously, I think they would be the first to tell you that I have a rather= jaundiced opinion of anything they say, regardless of what hat they are we= aring. If you remember, I pushed back against both Lou and Julien regardin= g their desire to have multiple switching type values for the same switchin= g technology and they eventually agreed. When listening to a WG chair or AD speak, the trick is to imagine them doin= g so wearing a dunce hat. Irrespectively Yours, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, January 28, 2013 8:45 AM > To: John E Drake; BRUNGARD, DEBORAH A > Cc: CCAMP; adrian@olddog.co.uk; Lou Berger (lberger@labn.net) > Subject: The hat trick >=20 > John, >=20 > You said: >=20 > I disagree. Airing dirty laundry in public is too > entertaining to stop. >=20 > All right then, here is another topic for you. >=20 > You are very respectable IETFer and seem to be here forever (certainly > since I can remember myself). I wonder what do you (and other CCAMPers) > think about these cute little "My hat on/off" statements? That's > right, the ones that IETF ADs and WG Chairs do with a coquettish smile > quite often at IETF meetings and on the mailing lists. The assumption > is, of course, that the things must be said by ADs/Chairs and > interpreted by the audience differently depending on whether the hat is > said to be in "on" or "off" position. This is a quite safe and > reasonable assumption, if one designs a signaling protocol for network > elements, for which it is possible to set proper filters, program > processing rules and maintain a separate independent state for each > conversation. However, ADs, Chairs and the audience are humans, i.e. > they are not very good at compartmentalizing the information in non- > overlapping memory spaces. When I, for one, hear or read an > AD's/Chair's statement, the statement always carries the AD/Chair > weight. >=20 > Let's take an example. Consider in a middle of a heated technical > discussion on a CCAMP WG session, Adrian comes up to the mike and > makes his hat-off comment. What does this exactly mean? Does it mean > that Adrian may have a separate hat-on opinion, that is opposite or > perpendicular to what he just said? I don't think so. The way I see it, > Adrian, being an excellent expert in many areas, has developed an > opinion that he genuinely believes may help the discussion. But, being > also very professional, Adrian believes that at this level of > discussion (or for whatever other reasons) it is somewhat inappropriate > for an AD to influence the discussion. The end result of the statement > is as follows. I, Igor Bryskin, am sitting in the audience and just > heard a statement that might very well influence the discussion and its > outcome. The statement came from Adrian Farrel, who happens to be one > of the Routing Area ADs (and I don't forget about this for a second) at > the precise moment when according to Adrian himself it is inappropriate > for an AD to influence the discussion. I might remember the statement > for quite a while, and I may communicate the statement to other some 37 > people. What I will immediately forget is what Adrian has said about > his hat, and this information will be lost on me and these 37 poor > souls. I am sure that the same happens to most (if not all) of the > crowd. I have never read, for example, emails like: >=20 > " Dear Adrian (with your AD hat on)! Thank you very much for your > thoughtful comments on our draft...." or "Adrian (with his AD hat off) > suggested to use his favorite LSP_ATTRIBUTES object, but I don't hate > this idea and since it was suggested with the hat off, I think it is Ok > to simply ignore the suggestion". > Nor I remember a conversation like: > "Igor, listen, I am about to make my XYZ draft last call vote. When Lou > made this comment on the ASSOCIATION object, could you tell me where > his hat was?" "Sorry, John, I have to come back to you with that: I > have to go through the meetings minutes as well as through some 1013 > emails that Lou has posted on the list since then. I am afraid, you > will be late with your vote" >=20 > Furthermore, ADs and Chairs do not talk just on the sessions and > mailing lists. There are also private emails, telephone calls, face-to- > face meetings even bar conversations. Call me a pessimist, but I doubt > that in all these circumstances ADs/Chairs do not forget to update > their hat status (especially in the bar). So, the point is that the > "Hat on/off" thing does not really work as intended, which is not a > problem per-se. The problem is that intentionally or unintentionally > this opens up ways for quite unfair play. >=20 > I don't know what you, John, know about football (soccer), but imagine > a match between two teams - one in red, one in white - and there is a > guy on the pitch with a hat: when the hat is on, the guy is the umpire > of the game, when the hat is off, he is a striker for the reds. You can > imagine a lot of funny things happening in such a game. For example, > the guy with his umpire hat on can pick up a proper situation and > moment, stop the game and grant a penalty against whites. Then, with > the hat off, he can take the penalty and score for the reads. And when > it looks like the whites are about to score the equalizer, the guy can > put his umpire hat back, blow the whistle and say: "Time is up, game is > over, reds won". Fortunately such a thing cannot happen in soccer: not > only a guy cannot be in the same game an umpire and a player of one of > the teams, an umpire cannot be associated in any way with one team more > than with the other (an umpire cannot be even from the same city or > country as one team but not the other). Why is that? Simple, to ensure > fair play, so that a better, more deserving team wins and moves into > the next round, while the bad team loses and gets kicked out of the > competition. That's what makes soccer such a beautiful game, by far the > most popular in the world: simple well thought through rules and fair > play". >=20 > If you don't like my analogy with soccer, consider a criminal case > trial in the court of law, where the judge is saying something like > this: " With my judge hat off I have to say that I agree completely > with the defense. Also in my previous life I was both defense and > district attorney, and my experience of being involved in such or > similar cases tells me that in 80% of the cases the defendant ends up > verdicted as not guilty. Now, with my judge hat back on, please, > proceed ...." >=20 > You may disagree with any of these analogies, but I hope you see where > I am getting at. With the hat trick It is quite possible to influence > the IETF game (which is creating RFCs) with the end result that it is > possible for poor architectures and bad solutions to make into useless > RFCs, while for good ideas to be killed and forgotten. > Here is a simple question: When a WG Chair systematically pushes one > solution while vigorously fights off an alternative one, does it matter > whether the Chair is doing this with his hat on or off, considering > that at the end of the day the Chair is the only one (along with co- > Chairs) who gets to make a call on rough consensus and hence to decide > which solution wins? >=20 > I say, no it does not matter, and this is unfair to you, John, because > while the Chair can take off his hat at any time, you, as a potential > (co-)author of the alternative solution, cannot put the WG Chair hat on > and overrule the call on the consensus. I suggest we nail down the hats > to AD/Chair heads and outlaw the hat trick to be used as an excuse. In > my opinion, WG chair is, figuratively speaking, 75% soccer umpire and > 25% soccer coach, but never a soccer player. >=20 > Does this make sense? Sorry for the long email. >=20 > Cheers, > Igor From db3546@att.com Mon Jan 28 12:03:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB67A21F8A67 for ; Mon, 28 Jan 2013 12:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XLZPEJzoeVZR for ; Mon, 28 Jan 2013 12:03:23 -0800 (PST) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id C562D21F89C0 for ; Mon, 28 Jan 2013 12:03:18 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 889d6015.750a8940.747951.00-528.2038887.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 28 Jan 2013 20:03:20 +0000 (UTC) X-MXL-Hash: 5106d98871b80b6e-6be4b797ae03bd2dfcf8cf42aa4d4145472c6918 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 189d6015.0.747920.00-340.2038722.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 28 Jan 2013 20:03:17 +0000 (UTC) X-MXL-Hash: 5106d9856aa46ac1-bd1d7497ac7ce18a9e0dd62232fe75a35b4b0126 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0SK3B7q020287; Mon, 28 Jan 2013 15:03:13 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0SK36ZB020154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2013 15:03:07 -0500 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint02.pst.cso.att.com (RSA Interceptor); Mon, 28 Jan 2013 15:02:51 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0328.009; Mon, 28 Jan 2013 15:02:51 -0500 From: "BRUNGARD, DEBORAH A" To: John E Drake , Igor Bryskin Thread-Topic: The hat trick Thread-Index: Ac39ZaelYtW7hPW6Q/qy/QKuSXA6zAAJ8ofQAAB/BaA= Date: Mon, 28 Jan 2013 20:02:51 +0000 Message-ID: References: <0182DEA5604B3A44A2EE61F3EE3ED69E0B710C3A@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E0B710C3A@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=OKOQK1mB c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=ed51lL5FJ] X-AnalysisOut: [V4A:10 a=OUXY8nFuAAAA:8 a=AEDFM0qtAAAA:8 a=wU2YTnxGAAAA:8 ] X-AnalysisOut: [a=pmb6BNNbAAAA:8 a=wznNEJTjI4f7zLbX6yEA:9 a=CjuIK1q_8ugA:1] X-AnalysisOut: [0 a=peF9eE_zjQwA:10 a=jqlaW5bC1iAA:10 a=33rK67OTR_gA:10 a=] X-AnalysisOut: [7N0VDwPMIj8A:10 a=VoFH56Qc4gh3qncx:21 a=7oiy2ReN8qkZ4njD:2] X-AnalysisOut: [1] Cc: CCAMP Subject: Re: [CCAMP] The hat trick X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 20:03:38 -0000 In case you missed Adrian's mail, this list is for CCAMP (technical) discus= sion. Refer to RFCs: 1855, 2026, 2418, 3184, and 3934. This thread is closed. -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Monday, January 28, 2013 2:37 PM To: Igor Bryskin; BRUNGARD, DEBORAH A Cc: CCAMP; adrian@olddog.co.uk; Lou Berger (lberger@labn.net) Subject: RE: The hat trick Igor, I don't think Lou or Adrian would approve of my replying to your email. Seriously, I think they would be the first to tell you that I have a rather= jaundiced opinion of anything they say, regardless of what hat they are we= aring. If you remember, I pushed back against both Lou and Julien regardin= g their desire to have multiple switching type values for the same switchin= g technology and they eventually agreed. When listening to a WG chair or AD speak, the trick is to imagine them doin= g so wearing a dunce hat. Irrespectively Yours, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, January 28, 2013 8:45 AM > To: John E Drake; BRUNGARD, DEBORAH A > Cc: CCAMP; adrian@olddog.co.uk; Lou Berger (lberger@labn.net) > Subject: The hat trick >=20 > John, >=20 > You said: >=20 > I disagree. Airing dirty laundry in public is too > entertaining to stop. >=20 > All right then, here is another topic for you. >=20 > You are very respectable IETFer and seem to be here forever (certainly > since I can remember myself). I wonder what do you (and other CCAMPers) > think about these cute little "My hat on/off" statements? That's > right, the ones that IETF ADs and WG Chairs do with a coquettish smile > quite often at IETF meetings and on the mailing lists. The assumption > is, of course, that the things must be said by ADs/Chairs and > interpreted by the audience differently depending on whether the hat is > said to be in "on" or "off" position. This is a quite safe and > reasonable assumption, if one designs a signaling protocol for network > elements, for which it is possible to set proper filters, program > processing rules and maintain a separate independent state for each > conversation. However, ADs, Chairs and the audience are humans, i.e. > they are not very good at compartmentalizing the information in non- > overlapping memory spaces. When I, for one, hear or read an > AD's/Chair's statement, the statement always carries the AD/Chair > weight. >=20 > Let's take an example. Consider in a middle of a heated technical > discussion on a CCAMP WG session, Adrian comes up to the mike and > makes his hat-off comment. What does this exactly mean? Does it mean > that Adrian may have a separate hat-on opinion, that is opposite or > perpendicular to what he just said? I don't think so. The way I see it, > Adrian, being an excellent expert in many areas, has developed an > opinion that he genuinely believes may help the discussion. But, being > also very professional, Adrian believes that at this level of > discussion (or for whatever other reasons) it is somewhat inappropriate > for an AD to influence the discussion. The end result of the statement > is as follows. I, Igor Bryskin, am sitting in the audience and just > heard a statement that might very well influence the discussion and its > outcome. The statement came from Adrian Farrel, who happens to be one > of the Routing Area ADs (and I don't forget about this for a second) at > the precise moment when according to Adrian himself it is inappropriate > for an AD to influence the discussion. I might remember the statement > for quite a while, and I may communicate the statement to other some 37 > people. What I will immediately forget is what Adrian has said about > his hat, and this information will be lost on me and these 37 poor > souls. I am sure that the same happens to most (if not all) of the > crowd. I have never read, for example, emails like: >=20 > " Dear Adrian (with your AD hat on)! Thank you very much for your > thoughtful comments on our draft...." or "Adrian (with his AD hat off) > suggested to use his favorite LSP_ATTRIBUTES object, but I don't hate > this idea and since it was suggested with the hat off, I think it is Ok > to simply ignore the suggestion". > Nor I remember a conversation like: > "Igor, listen, I am about to make my XYZ draft last call vote. When Lou > made this comment on the ASSOCIATION object, could you tell me where > his hat was?" "Sorry, John, I have to come back to you with that: I > have to go through the meetings minutes as well as through some 1013 > emails that Lou has posted on the list since then. I am afraid, you > will be late with your vote" >=20 > Furthermore, ADs and Chairs do not talk just on the sessions and > mailing lists. There are also private emails, telephone calls, face-to- > face meetings even bar conversations. Call me a pessimist, but I doubt > that in all these circumstances ADs/Chairs do not forget to update > their hat status (especially in the bar). So, the point is that the > "Hat on/off" thing does not really work as intended, which is not a > problem per-se. The problem is that intentionally or unintentionally > this opens up ways for quite unfair play. >=20 > I don't know what you, John, know about football (soccer), but imagine > a match between two teams - one in red, one in white - and there is a > guy on the pitch with a hat: when the hat is on, the guy is the umpire > of the game, when the hat is off, he is a striker for the reds. You can > imagine a lot of funny things happening in such a game. For example, > the guy with his umpire hat on can pick up a proper situation and > moment, stop the game and grant a penalty against whites. Then, with > the hat off, he can take the penalty and score for the reads. And when > it looks like the whites are about to score the equalizer, the guy can > put his umpire hat back, blow the whistle and say: "Time is up, game is > over, reds won". Fortunately such a thing cannot happen in soccer: not > only a guy cannot be in the same game an umpire and a player of one of > the teams, an umpire cannot be associated in any way with one team more > than with the other (an umpire cannot be even from the same city or > country as one team but not the other). Why is that? Simple, to ensure > fair play, so that a better, more deserving team wins and moves into > the next round, while the bad team loses and gets kicked out of the > competition. That's what makes soccer such a beautiful game, by far the > most popular in the world: simple well thought through rules and fair > play". >=20 > If you don't like my analogy with soccer, consider a criminal case > trial in the court of law, where the judge is saying something like > this: " With my judge hat off I have to say that I agree completely > with the defense. Also in my previous life I was both defense and > district attorney, and my experience of being involved in such or > similar cases tells me that in 80% of the cases the defendant ends up > verdicted as not guilty. Now, with my judge hat back on, please, > proceed ...." >=20 > You may disagree with any of these analogies, but I hope you see where > I am getting at. With the hat trick It is quite possible to influence > the IETF game (which is creating RFCs) with the end result that it is > possible for poor architectures and bad solutions to make into useless > RFCs, while for good ideas to be killed and forgotten. > Here is a simple question: When a WG Chair systematically pushes one > solution while vigorously fights off an alternative one, does it matter > whether the Chair is doing this with his hat on or off, considering > that at the end of the day the Chair is the only one (along with co- > Chairs) who gets to make a call on rough consensus and hence to decide > which solution wins? >=20 > I say, no it does not matter, and this is unfair to you, John, because > while the Chair can take off his hat at any time, you, as a potential > (co-)author of the alternative solution, cannot put the WG Chair hat on > and overrule the call on the consensus. I suggest we nail down the hats > to AD/Chair heads and outlaw the hat trick to be used as an excuse. In > my opinion, WG chair is, figuratively speaking, 75% soccer umpire and > 25% soccer coach, but never a soccer player. >=20 > Does this make sense? Sorry for the long email. >=20 > Cheers, > Igor From lberger@labn.net Mon Jan 28 12:26:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE50321F8574 for ; Mon, 28 Jan 2013 12:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.179 X-Spam-Level: X-Spam-Status: No, score=-101.179 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 vmFORX8A5kQp for ; Mon, 28 Jan 2013 12:26:13 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 71E4E21F854F for ; Mon, 28 Jan 2013 12:26:13 -0800 (PST) Received: (qmail 15708 invoked by uid 0); 28 Jan 2013 20:25:44 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 28 Jan 2013 20:25:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=gmve3z1MhqyLGuk/jiePIlCBosz4OXCIHZ5kXmzNfN8=; b=ukiux0J9ex29DLEHuTn9uhWHWqmMoNvQep3i58J9keAmLKSIQkyKIYcQieE19p7SuJ1m0xwa0Omkmdwjezn0LZZN8x2UtaM/4Zl5Dw0fokqvd9d0s+fHD5j1iEZGch4+; Received: from box313.bluehost.com ([69.89.31.113]:47836 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TzvGw-0007zr-GM for ccamp@ietf.org; Mon, 28 Jan 2013 13:25:42 -0700 Message-ID: <5106DED0.3090008@labn.net> Date: Mon, 28 Jan 2013 15:25:52 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: CCAMP References: <5105E684.4030607@labn.net> <4A1562797D64E44993C5CBF38CF1BE48073D01@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48073D01@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 20:26:17 -0000 All, We would like to try to close the discussion on the G.709 drafts so that we can move rapidly towards publication request. The discussion of (one of my) LC comments has resulted in several options for the signaling ODU-related traffic parameters, and the point has been raised that realigning routing with signaling should be discussed. Please keep in mind that the objective of any PS is interoperability, and that there may be early implementations that match g709v3-04. The basic question is one of if N, the number of time slots needed to support a ODUflex(GFP) signal, should be carried as a calculated IEEE floating point number or directly. Options 1 and 2 below reflect the former, options 3 and 4 match the latter. It is worth noting that only options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be calculated for ODUflex(CBR) signal types with all options. Please state your support for one the options and, if you wish, the justification for your position: 1) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-04 i.e., redefine [RFC4328] Traffic Parameters c-type when used with OTN-TDM labels. ODUflex(GFP) number of tributary slots (N) is encoded as: ... the Bit_Rate field for ODUflex(GFP) MUST equal to one of the 80 values listed below: 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. 2) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-05 i.e., use a new C-type for OTN-TDM labels. Encoding details unchanged from g709v3-04. (This option addresses the issue of the same c-type needing to be parsed based on label/switching type.) 3) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-06 i.e., use a new C-type for OTN-TDM labels. N is directly carried for ODUflex(GFP) only. 4) Discussed, but not in any draft Use draft-ietf-ccamp-gmpls-signaling-g709v3-04 encoding for all but ODUflex(GFP), and define new ODUflex(GFP) specific Traffic Parameters based on g709v3-06, presumably with unused fields removed. (This also addresses the issue of the same c-type needing to be parsed based on label type, but means there are different types based on signal type.) Option 1 and 2 do not imply any changes to routing, while options 3 and 4 may. Routing implications will be discussed based on the results of this poll, and only if there is consensus to support positions 3 or 4. We hope to make a consensus call by the end of the week, but will continue the discussion as needed. Much thanks, Lou (and Deborah) On 1/28/2013 5:08 AM, Daniele Ceccarelli wrote: > All, > > I think the changes proposed are meaningful and would support them in an individual or early WG draft, but they don't seem to provide significative advantages to risk interworking issues with early implementations. > Moreover the changes don't allow us getting totally rid of of the bit_rate field as it is still needed for ODUflex (CBR). > > My 2c > Daniele > > >> -----Original Message----- >> From: Zafar Ali (zali) [mailto:zali@cisco.com] >> Sent: luned矛 28 gennaio 2013 4.47 >> To: Lou Berger >> Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] WG Last Call comments on >> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >> >> Hi Lou- >> >> Please see in-line. >> >> Thanks >> >> Regards...Zafar >> >> On 1/27/13 9:46 PM, "Lou Berger" wrote: >> >>> Zafar, >>> Is your comment with respect to just routing or both >> signaling and >>> routing? >> >> Both, including consistency between signaling and routing attributes. >> >>> >>> Also, when you say "implementations based on draft versions", >> do these >>> implementations include support for ODUflex? (Which has really been >>> the focus of the discussion.) >> >> Yes, I was referring to ODUFlex. As you know, fixed ODU is >> signaled via level (0 BW) so its not an issue. >> >>> >>> BTW I took Fred's comments as related to just the new >> OTN-specific ISCD >>> definitions (section 4.1.2 of ospf-g709v3-05, in particular). Note >>> that section 4.1.1 already carries N (number of ODUs) not >> IEEE floating >>> point representations of available bandwidth. >> >> What I meant is Unreserved Bandwidth at priority x and Max LSP >> Bandwidth at priority x. >> >>> >>> Much thanks, >>> Lou >>> >>> On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote: >>>> All- >>>> >>>> This impacts existing implementations based on draft versions (and >>>> hence interop with these implementations moving forward). >> IMO this is >>>> a bigger change for us to assume at the last call stage. >> Furthermore >>>> we have been using IEEE floating point format for Unreserved >>>> Bandwidth/ Max LSP BW in IEEE floating point format for other >>>> technologies. Overall, I think this change suffers from the >> "law of diminishing returns". >>>> >>>> Thanks >>>> >>>> Regards 艩 Zafar >>>> >>>> >>>> On 1/27/13 10:28 AM, "Gruman, Fred" >> wrote: >>>> >>>>> Hi Lou, Fatai, Daniele, >>>>> >>>>> I understand the latest change to the way bandwidth is >> signaled for >>>>> ODUflex(GFP), i.e., signaling the number of tributary slots >> N instead >>>>> of the bandwidth rate in bps. I believe that this simplifies the >>>>> signaling and interoperability so I'm in agreement with >> this change. >>>>> >>>>> However, it seems we are now inconsistent between how we >> represent >>>>> bandwidth in routing and signaling for ODUflex(GFP). Routing >>>>> advertises the bandwidth using a floating point representation of >>>>> bandwidth, while signaling is using the number of tributary slots. >>>>> It seems the same benefits would be obtained by >> advertising the max >>>>> LSP bandwidth and unreserved bandwidth for ODUflex(GFP) in >> terms of >>>>> the number of tributary slots. >>>>> >>>>> Fred >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of Lou Berger >>>>> Sent: Wednesday, January 23, 2013 9:08 AM >>>>> To: Fatai Zhang >>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>> >>>>> Fatai, >>>>> >>>>> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>>>>> Hi Lou, >>>>>> >>>>>> For ODUflex(CBR), the formula is from [G.709-2012] and it >> has been >>>>>> discussed before, so please trust that there is no >> opportunity for >>>>>> misinterpretation. (Note that there are two cases, one is >>>>>> ODUflex(CBR) and another one is ODUflex(GFP)). >>>>>> >>>>>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >>>>> >>>>> Thanks for confirming my understanding. This raises the >> question of >>>>> if the new traffic should just apply to ODUFlex? Correct >> me if I'm >>>>> wrong, but I believe the [RFC4328] is sufficient in all >> other cases. >>>>> This may also make it easier for early implementations of >> the draft >>>>> as then they can limit code changes from the (-03) rev to >> only ODUflex LSPs. >>>>> >>>>> Just to be clear, I'm really just *asking* about this. As I said >>>>> before, I'm open on specifics... >>>>> >>>>> Any thoughts/comments? Authors? Implementors? >>>>> >>>>> Thanks, >>>>> Lou >>>>> >>>>> >>>>>> I will issue a new version tomorrow to capture all your comments. >>>>>> >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Fatai >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>> Sent: Wednesday, January 23, 2013 2:11 AM >>>>>> To: Fatai Zhang >>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>> >>>>>> Fatai, >>>>>> >>>>>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>>>>> Hi Lou, >>>>>>> >>>>>>> You said: >>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>> value of this vs just carrying N? >>>>>>> >>>>>>> [Fatai] The original way (in version 04&05) is putting >> (N* Nominal >>>>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we >>>>>>> can generalize to just use one single "Bit_Rate" field to carry >>>>>>> IEEE float number for both cases, it seems that you >> don't agree on >>>>>>> this value, :-) >>>>>> >>>>>> I've seen differences in calculated floating point values from >>>>>> different implementations, so I just want to ensure that >> such cases >>>>>> are avoided. >>>>>> I'm open to specific solutions and certainly will deffer on the >>>>>> specifics assuming there is no opportunity for >>>>>> misinterpretation/interop issues. I don't think the >> original passed >>>>>> this threshold, i.e.,: >>>>>> >>>>>> N = Ceiling of >>>>>> >>>>>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate >>>>>> tolerance) >>>>>> >>>>>> ----------------------------------------------------------- >> ---------- >>>>>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate >> tolerance) >>>>>> >>>>>>> . Therefore, I (was) am saying that I am going to accept your >>>>>>> suggestion to carry N for ODUflex(GFP). We are >> discussing where to >>>>>>> put N for ODUflex(GFP). >>>>>>> >>>>>> >>>>>>> You said: >>>>>>>> bits in the control plane are generally cheap, IMO it's >> better to >>>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>>> case). >>>>>>> >>>>>>> [Fatai] OK, I will add a new field (to occupy the reserved bits) >>>>>>> to carry N. >>>>>> >>>>>> As you see fit. >>>>>> >>>>>> Just to clarify my understanding, ODUflex and Virtual >> concatenation >>>>>> can never be combined for the same signal type/level, right? >>>>>> (Although an ODUflex client signal could be carried over >> a virtual >>>>>> concatenated ODUk). Is this correct or did I miss something in >>>>>> G709? >>>>>> >>>>>> Thanks, >>>>>> Lou >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>>>> Fatai >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>> Sent: Friday, January 18, 2013 1:42 AM >>>>>>> To: Fatai Zhang >>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>>>>> Hi Lou, >>>>>>>> >>>>>>>> To avoid misunderstanding, I would like to clarify more on the >>>>>>>> following point. >>>>>>>> >>>>>>>> >>>>>>>>>>>> It is better to have consistent format and the same meaning >>>>>>>>>>>> of one >>>>>>> field for both ODUflex(CBR) and GFP. This is why we have section >>>>>>> 5.1 >>>>>>> &5.2 to describe the complex stuff. >>>>>>>>>>> I actually wasn't suggesting that N be carried in >> the bit rate >>>>>>>>>>> field. >>>>>>>>>>> The bit rate field can either be set as described or to zero >>>>>>>>>>> (i.e., ignored). At the time, I was thinking about >> carrying N >>>>>>>>>>> in the reserved field. But perhaps the right place >> is MT, if >>>>>>>>>>> my understanding is right (would always be 1 >> otherwise). I'm >>>>>>>>>>> open to either... >>>>>>>>>>> >>>>>>>>>> [Fatai] Why not just use "bit rate"field to carry >> "N"because "N" >>>>>>>>>> implies bit rate? I am OK if you like to use a new >> filed (like >>>>>>>>>> "TS >>>>>>>>>> Number") to occupy the reserved field even though >> that I prefer >>>>>>>>>> the original approach (ie., use "bit rate"field to carry "N"). >>>>>>>>> >>>>>>>>> Are you proposing dropping carrying bit rates >> represented as an >>>>>>>>> IEEE floating point and just carrying N for ODUflex? >> This seems >>>>>>>>> workable to me, but we should ensure that there are no >>>>>>>>> significant objections. >>>>>>>> >>>>>>>> [Fatai] There are two usages for " Bit_Rate " field as >> described >>>>>>>> in the lines 287-310. >>>>>>>> >>>>>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates >> the nominal >>>>>>>> bit >>>>>>>> rate of ODUflex(CBR) expressed in bytes per second, >> encoded as a >>>>>>>> 32-bit IEEE single precision floating-point number. For this >>>>>>>> case, we MUST use 32-bit IEEE floating point instead of >>>>>>>> "N"(Please see more in section 5.1). >>>>>>> >>>>>>> I guess you really still need (to be based on) the client signal >>>>>>> rate at the edges. >>>>>>> >>>>>>>> >>>>>>>> (2) For ODUflex(GFP), we can change the text (the >> lines from 305 >>>>>>>> to >>>>>>>> 310) based on your suggestion, ie., the Bit_Rate field >> is used to >>>>>>>> carry "N"to indicate the nominal bit rate of the ODUflex(GFP). >>>>>>> >>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>> value of this vs just carrying N? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") >>>>>>>> for these two cases, in this way, we can leave the "Reserved" >>>>>>>> bits for future. >>>>>>> >>>>>>> bits in the control plane are generally cheap, IMO it's >> better to >>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>> case). >>>>>>> >>>>>>> Lou >>>>>>> >>>>>>>> >>>>>>>> Hope we are now at the same page. >>>>>>>> >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Fatai >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>>> >> >> > From ke-kumaki@kddi.com Mon Jan 28 15:57:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37E621E8043 for ; Mon, 28 Jan 2013 15:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 TtbmXp-S-tZu for ; Mon, 28 Jan 2013 15:57:44 -0800 (PST) Received: from UTMC1102.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2697421E8039 for ; Mon, 28 Jan 2013 15:57:43 -0800 (PST) Received: from UTMC1136 (unknown [10.5.16.207]) by UTMC1102.kddi.com (Postfix) with SMTP id 362A12B53; Tue, 29 Jan 2013 08:57:42 +0900 (JST) Received: from UTMC1124.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 72F581C03; Tue, 29 Jan 2013 08:57:36 +0900 (JST) Received: from LTMC1006.kddi.com (unknown [10.5.16.217]) by UTMC1124.kddi.com (Postfix) with ESMTP id 64B031BC6; Tue, 29 Jan 2013 08:57:36 +0900 (JST) Received: from LTMC1006.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r0SNva76012747; Tue, 29 Jan 2013 08:57:36 +0900 Received: from LTMC1006.kddi.com.mid_14236193 (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r0SNuf3l012173; Tue, 29 Jan 2013 08:56:41 +0900 Received: from KDDI-1202PC0730 ([10.200.129.120] [10.200.129.120]) by post-zip.kddi.com with ESMTPA; Tue, 29 Jan 2013 08:56:41 +0900 To: db3546@att.com From: Kenji Kumaki References: In-Reply-To: Message-Id: <201301290856.BJG26065.LVBFJNLtL@kddi.com> X-Mailer: Winbiff [Version 2.51 PL4] X-Accept-Language: ja,en,zh Date: Tue, 29 Jan 2013 08:56:41 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-SA-MID: 14236193 X-WAuditID: 1301290857360000614796 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WGdocument X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 23:57:45 -0000 Yes/support (as co-author) Thanks, Kenji $B$N!"(B "[CCAMP] Poll on making draft-ali-ccamp-te-metric-recording- 03 WGdocument" $B$K$*$$$F!"(B ""BRUNGARD, DEBORAH A" "$B$5$s$O=q$-$^$7$?!'(B > > > All, > > This is start a two week poll on making draft-ali-ccamp-te-metric-recording- 03 a ccamp working group document. Please send email to the list indicating " yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. > > The poll ends Thursday, Feb. 7th. > > Note, as stated by some of the authors, there is IPR "still being documented ". > > Thanks, > Deborah and Lou > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From ke-kumaki@kddi.com Mon Jan 28 16:36:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19C721E8049 for ; Mon, 28 Jan 2013 16:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, 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 Hr5lKmU-tB7H for ; Mon, 28 Jan 2013 16:36:35 -0800 (PST) Received: from UTMC1104.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id E6E1C21E8042 for ; Mon, 28 Jan 2013 16:36:34 -0800 (PST) Received: from UTMC1137 (unknown [10.5.16.210]) by UTMC1104.kddi.com (Postfix) with SMTP id 206EC2A18; Tue, 29 Jan 2013 09:36:29 +0900 (JST) Received: from UTMC1124.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 772671C03; Tue, 29 Jan 2013 09:36:26 +0900 (JST) Received: from LTMC1006.kddi.com (unknown [10.5.16.217]) by UTMC1124.kddi.com (Postfix) with ESMTP id 66E6D19D6; Tue, 29 Jan 2013 09:36:26 +0900 (JST) Received: from LTMC1006.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r0T0aQtB018771; Tue, 29 Jan 2013 09:36:26 +0900 Received: from LTMC1006.kddi.com.mid_14239168 (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r0T0ZY0X017828; Tue, 29 Jan 2013 09:35:34 +0900 Received: from KDDI-1202PC0730 ([10.200.129.120] [10.200.129.120]) by post-zip.kddi.com with ESMTPA; Tue, 29 Jan 2013 09:35:34 +0900 To: db3546@att.com From: Kenji Kumaki References: In-Reply-To: Message-Id: <201301290935.ABD21888.NBLJtFLVL@kddi.com> X-Mailer: Winbiff [Version 2.51 PL4] X-Accept-Language: ja,en,zh Date: Tue, 29 Jan 2013 09:35:34 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-SA-MID: 14239168 X-WAuditID: 1301290936260000723297 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WGdocument X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 00:36:36 -0000 yes/support (as co-author) Thanks, Kenji $B$N!"(B "[CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WGdocument" $B$K$*$$$F!"(B ""BRUNGARD, DEBORAH A" "$B$5$s$O=q$-$^$7$?!'(B > > > All, > > This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. Please send email to the list indicating "yes /support" or "no/do not support". If indicating no, please state your technical reservations with the document. > > The poll ends Thursday, January 31st. > > Note, as stated by some of the authors, IPR has been disclosed in compliance with IETF IPR rules. > > Thanks, > Deborah and Lou > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From zhangfatai@huawei.com Mon Jan 28 18:27:11 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D4C21F8443 for ; Mon, 28 Jan 2013 18:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 Ud5A9XH-SXC6 for ; Mon, 28 Jan 2013 18:27:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B23821E8089 for ; Mon, 28 Jan 2013 18:27:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APE80558; Tue, 29 Jan 2013 02:27:00 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 29 Jan 2013 02:26:27 +0000 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 29 Jan 2013 02:26:59 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Tue, 29 Jan 2013 10:26:54 +0800 From: Fatai Zhang To: Lou Berger , CCAMP Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZXCuS8hTs+eckmWtA0MM2hSFphfguWQ Date: Tue, 29 Jan 2013 02:26:53 +0000 Message-ID: References: <5105E684.4030607@labn.net> <4A1562797D64E44993C5CBF38CF1BE48073D01@ESESSMB301.ericsson.se> <5106DED0.3090008@labn.net> In-Reply-To: <5106DED0.3090008@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 02:27:11 -0000 SGkgTG91LA0KDQpJIHdvdWxkIHBpY2sgdXAgb3B0aW9uIDIgKGJldHRlciB0aGFuIG9wdGlvbiAx KSBiZWNhdXNlIG9mIHRoZSBmb2xsb3dpbmcgcmVhc29ucywgZXZlbiB0aG91Z2ggSSBzcGVudCBt dWNoIHRpbWUgdG8gY29udmluY2UgeW91IChidXQgSSBmYWlsZWQpLiANCg0KKDEpIFRoZXJlIHdp bGwgYmUgY29uc2lzdGVudCBiZXR3ZWVuIHNpZ25hbGluZyBkcmFmdCAobmVlZCBjcmFuay1iYWNr KSBhbmQgdGhlIGV4aXN0aW5nIHJvdXRpbmcgZHJhZnQgKHdlIGFsbCBzcGVudCBzbyBtdWNoIHRp bWUgb24gcm91dGluZyBkcmFmdCB0byBnZXQgdGhlIGNvbnNlbnN1cykuDQooMikgVGhlcmUgd2ls bCBiZSBjb25zaXN0ZW50IGZvciAiQml0X1JhdGUiIGZpbGVkIGZvciBib3RoIE9EVWZsZXgoQ0JS KSBhbmQgT0RVZmxleChHRlApIGNhc2VzIChpZSwgaXQgb25seSBuZWVkcyBvbmUgc2luZ2xlICJC aXRfUmF0ZSIgZmllbGQpLiANCigzKSBJIGRvbid0IHRoaW5rIG9wdGlvbiAzJjQgYXJlIGJldHRl ciB0aGFuIG9wdGlvbiAxJjIgZm9yIGludGVyd29ya2luZyB3aXRoIGVhcmx5IGltcGxlbWVudGF0 aW9ucyAoSSB0aGluayBhbGwgdGhlIGF1dGhvcnMgYXJlIGZyb20gdmVuZG9ycywgd2Uga25vdyB0 aGlzIHZlcnkgd2VsbC4gVXN1YWxseS9zb21ldGltZXMsIHRoZXJlIGlzIGFjdHVhbGx5IG5vIGNv bXBhdGliaWxpdHkvaW50ZXJ3b3JraW5nIGlzc3VlIGluIHRoZSByZWFsIHdvcmxkKS4NCg0KRm9y IG9wdGlvbiAzLCBJIGFtIGZpbmUgYmVjYXVzZSBJIGFwcHJlY2lhdGUgdGhlIHdvcmsgdGhhdCBJ IGhhdmUgZG9uZSwgOi0pLCBpZiB3ZSBkb24ndCBjb3VudCB0aGUgYWRkaXRpb25hbCB3b3JrIG9u IHJvdXRpbmcgZHJhZnQuIA0KDQoNCkFueXdheSwgcGxlYXNlIGRvbid0IHRoaW5rIGFib3V0IG9w dGlvbiA0LCBJIGRvbid0IHNlZSBhbnkgc2lnbmlmaWNhbnQgYWR2YW50YWdlcyBieSBkb2luZyB0 aGF0IGJlc2lkZXMgbW9yZSB3b3JrIGFuZCBtb3JlIGRpc2N1c3Npb25zLiANCg0KDQoNCkJlc3Qg UmVnYXJkcw0KDQpGYXRhaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2Nh bXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBMb3UgQmVyZ2VyDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI5LCAyMDEzIDQ6MjYg QU0NClRvOiBDQ0FNUA0KU3ViamVjdDogW0NDQU1QXSBQb2xsIG9uIE9EVUZsZXgtcmVsYXRlZCBl bmNvZGluZyAod2FzOiBXRyBMYXN0IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KDQpBbGwsDQoJV2Ugd291bGQgbGlrZSB0byB0cnkg dG8gY2xvc2UgdGhlIGRpc2N1c3Npb24gb24gdGhlIEcuNzA5DQpkcmFmdHMgc28gdGhhdCB3ZSBj YW4gbW92ZSByYXBpZGx5IHRvd2FyZHMgcHVibGljYXRpb24gcmVxdWVzdC4gIFRoZQ0KZGlzY3Vz c2lvbiBvZiAob25lIG9mIG15KSBMQyBjb21tZW50cyBoYXMgcmVzdWx0ZWQgaW4gc2V2ZXJhbCBv cHRpb25zDQpmb3IgdGhlIHNpZ25hbGluZyBPRFUtcmVsYXRlZCB0cmFmZmljIHBhcmFtZXRlcnMs IGFuZCB0aGUgcG9pbnQgaGFzDQpiZWVuIHJhaXNlZCB0aGF0IHJlYWxpZ25pbmcgcm91dGluZyB3 aXRoIHNpZ25hbGluZyBzaG91bGQgYmUgZGlzY3Vzc2VkLg0KDQpQbGVhc2Uga2VlcCBpbiBtaW5k IHRoYXQgdGhlIG9iamVjdGl2ZSBvZiBhbnkgUFMgaXMgaW50ZXJvcGVyYWJpbGl0eSwNCmFuZCB0 aGF0IHRoZXJlIG1heSBiZSBlYXJseSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBtYXRjaCBnNzA5djMt MDQuDQoNClRoZSBiYXNpYyBxdWVzdGlvbiBpcyBvbmUgb2YgaWYgTiwgdGhlIG51bWJlciBvZiB0 aW1lIHNsb3RzIG5lZWRlZCB0bw0Kc3VwcG9ydCBhIE9EVWZsZXgoR0ZQKSBzaWduYWwsIHNob3Vs ZCBiZSBjYXJyaWVkIGFzIGEgY2FsY3VsYXRlZCBJRUVFDQpmbG9hdGluZyBwb2ludCBudW1iZXIg b3IgZGlyZWN0bHkuICAgT3B0aW9ucyAxIGFuZCAyIGJlbG93IHJlZmxlY3QgdGhlDQpmb3JtZXIs IG9wdGlvbnMgMyBhbmQgNCBtYXRjaCB0aGUgbGF0dGVyLiAgSXQgaXMgd29ydGggbm90aW5nIHRo YXQgb25seQ0Kb3B0aW9ucyAxIGFuZCAyIGFyZSBwcm9wb3NlZCBmb3IgT0RVZmxleChHRlApLCBp LmUuLCBOIG11c3QgYmUNCmNhbGN1bGF0ZWQgZm9yIE9EVWZsZXgoQ0JSKSBzaWduYWwgdHlwZXMg d2l0aCBhbGwgb3B0aW9ucy4NCg0KUGxlYXNlIHN0YXRlIHlvdXIgc3VwcG9ydCBmb3Igb25lIHRo ZSBvcHRpb25zIGFuZCwgaWYgeW91IHdpc2gsIHRoZQ0KanVzdGlmaWNhdGlvbiBmb3IgeW91ciBw b3NpdGlvbjoNCg0KMSkgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3 MDl2My0wNA0KICAgaS5lLiwgcmVkZWZpbmUgW1JGQzQzMjhdIFRyYWZmaWMgUGFyYW1ldGVycyBj LXR5cGUgd2hlbiB1c2VkIHdpdGgNCiAgIE9UTi1URE0gbGFiZWxzLiBPRFVmbGV4KEdGUCkgbnVt YmVyIG9mIHRyaWJ1dGFyeSBzbG90cyAoTikgaXMNCiAgIGVuY29kZWQgYXM6DQoNCiAgIC4uLiB0 aGUgQml0X1JhdGUgZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSBNVVNUDQogICBlcXVhbCB0byBvbmUg b2YgdGhlIDgwIHZhbHVlcyBsaXN0ZWQgYmVsb3c6DQoNCiAgICAgICAxICogT0RVMi50czsgMiAq IE9EVTIudHM7IC4uLjsgOCAqIE9EVTIudHM7DQogICAgICAgOSAqIE9EVTMudHM7IDEwICogT0RV My50cywgLi4uOyAzMiAqIE9EVTMudHM7DQogICAgICAgMzMgKiBPRFU0LnRzOyAzNCAqIE9EVTQu dHM7IC4uLjsgODAgKiBPRFU0LnRzLg0KDQoyKSBGb2xsb3cgZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1zaWduYWxpbmctZzcwOXYzLTA1DQogICBpLmUuLCB1c2UgYSBuZXcgQy10eXBlIGZvciBPVE4t VERNIGxhYmVscy4gIEVuY29kaW5nIGRldGFpbHMNCiAgIHVuY2hhbmdlZCBmcm9tIGc3MDl2My0w NC4NCiAgIChUaGlzIG9wdGlvbiBhZGRyZXNzZXMgdGhlIGlzc3VlIG9mIHRoZSBzYW1lIGMtdHlw ZSBuZWVkaW5nIHRvDQogICAgYmUgcGFyc2VkIGJhc2VkIG9uIGxhYmVsL3N3aXRjaGluZyB0eXBl LikNCg0KMykgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0w Ng0KICAgaS5lLiwgIHVzZSBhIG5ldyBDLXR5cGUgZm9yIE9UTi1URE0gbGFiZWxzLiBOIGlzIGRp cmVjdGx5IGNhcnJpZWQNCiAgIGZvciBPRFVmbGV4KEdGUCkgb25seS4NCg0KNCkgRGlzY3Vzc2Vk LCBidXQgbm90IGluIGFueSBkcmFmdA0KICAgVXNlIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2ln bmFsaW5nLWc3MDl2My0wNCBlbmNvZGluZyBmb3IgYWxsDQogICBidXQgT0RVZmxleChHRlApLCBh bmQgZGVmaW5lIG5ldyBPRFVmbGV4KEdGUCkgc3BlY2lmaWMgVHJhZmZpYw0KICAgUGFyYW1ldGVy cyBiYXNlZCBvbiBnNzA5djMtMDYsIHByZXN1bWFibHkgd2l0aCB1bnVzZWQgZmllbGRzDQogICBy ZW1vdmVkLg0KICAgKFRoaXMgYWxzbyBhZGRyZXNzZXMgdGhlIGlzc3VlIG9mIHRoZSBzYW1lIGMt dHlwZSBuZWVkaW5nIHRvIGJlDQogICAgcGFyc2VkIGJhc2VkIG9uIGxhYmVsIHR5cGUsIGJ1dCBt ZWFucyB0aGVyZSBhcmUgZGlmZmVyZW50IHR5cGVzDQogICAgYmFzZWQgb24gc2lnbmFsIHR5cGUu KQ0KDQpPcHRpb24gMSBhbmQgMiBkbyBub3QgaW1wbHkgYW55IGNoYW5nZXMgdG8gcm91dGluZywg d2hpbGUgb3B0aW9ucyAzIGFuZA0KNCBtYXkuICBSb3V0aW5nIGltcGxpY2F0aW9ucyB3aWxsIGJl IGRpc2N1c3NlZCBiYXNlZCBvbiB0aGUgcmVzdWx0cyBvZg0KdGhpcyBwb2xsLCBhbmQgb25seSBp ZiB0aGVyZSBpcyBjb25zZW5zdXMgdG8gc3VwcG9ydCBwb3NpdGlvbnMgMyBvciA0Lg0KDQpXZSBo b3BlIHRvIG1ha2UgYSBjb25zZW5zdXMgY2FsbCBieSB0aGUgZW5kIG9mIHRoZSB3ZWVrLCBidXQg d2lsbA0KY29udGludWUgdGhlIGRpc2N1c3Npb24gYXMgbmVlZGVkLg0KDQpNdWNoIHRoYW5rcywN CkxvdSAoYW5kIERlYm9yYWgpDQoNCk9uIDEvMjgvMjAxMyA1OjA4IEFNLCBEYW5pZWxlIENlY2Nh cmVsbGkgd3JvdGU6DQo+ICBBbGwsDQo+IA0KPiBJIHRoaW5rIHRoZSBjaGFuZ2VzIHByb3Bvc2Vk IGFyZSBtZWFuaW5nZnVsIGFuZCB3b3VsZCBzdXBwb3J0IHRoZW0gaW4gYW4gaW5kaXZpZHVhbCBv ciBlYXJseSBXRyBkcmFmdCwgYnV0IHRoZXkgZG9uJ3Qgc2VlbSB0byBwcm92aWRlIHNpZ25pZmlj YXRpdmUgYWR2YW50YWdlcyB0byByaXNrIGludGVyd29ya2luZyBpc3N1ZXMgd2l0aCBlYXJseSBp bXBsZW1lbnRhdGlvbnMuDQo+IE1vcmVvdmVyIHRoZSBjaGFuZ2VzIGRvbid0IGFsbG93IHVzIGdl dHRpbmcgdG90YWxseSByaWQgb2Ygb2YgdGhlIGJpdF9yYXRlIGZpZWxkIGFzIGl0IGlzIHN0aWxs IG5lZWRlZCBmb3IgT0RVZmxleCAoQ0JSKS4NCj4gDQo+IE15IDJjDQo+IERhbmllbGUNCj4gDQo+ IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFphZmFyIEFsaSAoemFs aSkgW21haWx0bzp6YWxpQGNpc2NvLmNvbV0gDQo+PiBTZW50OiBsdW5lZMOsIDI4IGdlbm5haW8g MjAxMyA0LjQ3DQo+PiBUbzogTG91IEJlcmdlcg0KPj4gQ2M6IEdydW1hbiwgRnJlZDsgRmF0YWkg Wmhhbmc7IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVA7IA0KPj4gZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW0ND QU1QXSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24gDQo+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxz LXNpZ25hbGluZy1nNzA5djMtMDQNCj4+DQo+PiBIaSBMb3UtIA0KPj4NCj4+IFBsZWFzZSBzZWUg aW4tbGluZS4NCj4+DQo+PiBUaGFua3MNCj4+DQo+PiBSZWdhcmRzLi4uWmFmYXINCj4+DQo+PiBP biAxLzI3LzEzIDk6NDYgUE0sICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6 DQo+Pg0KPj4+IFphZmFyLA0KPj4+IAlJcyB5b3VyIGNvbW1lbnQgd2l0aCByZXNwZWN0IHRvIGp1 c3Qgcm91dGluZyBvciBib3RoIA0KPj4gc2lnbmFsaW5nIGFuZCANCj4+PiByb3V0aW5nPw0KPj4N Cj4+IEJvdGgsIGluY2x1ZGluZyBjb25zaXN0ZW5jeSBiZXR3ZWVuIHNpZ25hbGluZyBhbmQgcm91 dGluZyBhdHRyaWJ1dGVzLg0KPj4NCj4+Pg0KPj4+IEFsc28sIHdoZW4geW91IHNheSAiaW1wbGVt ZW50YXRpb25zIGJhc2VkIG9uIGRyYWZ0IHZlcnNpb25zIiwgDQo+PiBkbyB0aGVzZSANCj4+PiBp bXBsZW1lbnRhdGlvbnMgaW5jbHVkZSBzdXBwb3J0IGZvciBPRFVmbGV4PyAgKFdoaWNoIGhhcyBy ZWFsbHkgYmVlbiANCj4+PiB0aGUgZm9jdXMgb2YgdGhlIGRpc2N1c3Npb24uKQ0KPj4NCj4+IFll cywgSSB3YXMgcmVmZXJyaW5nIHRvIE9EVUZsZXguIEFzIHlvdSBrbm93LCBmaXhlZCBPRFUgaXMg DQo+PiBzaWduYWxlZCB2aWEgbGV2ZWwgKDAgQlcpIHNvIGl0cyBub3QgYW4gaXNzdWUuDQo+Pg0K Pj4+DQo+Pj4gQlRXIEkgdG9vayBGcmVkJ3MgY29tbWVudHMgYXMgcmVsYXRlZCB0byBqdXN0IHRo ZSBuZXcgDQo+PiBPVE4tc3BlY2lmaWMgSVNDRCANCj4+PiBkZWZpbml0aW9ucyAoc2VjdGlvbiA0 LjEuMiBvZiBvc3BmLWc3MDl2My0wNSwgaW4gcGFydGljdWxhcikuICBOb3RlIA0KPj4+IHRoYXQg c2VjdGlvbiA0LjEuMSBhbHJlYWR5IGNhcnJpZXMgTiAobnVtYmVyIG9mIE9EVXMpIG5vdCANCj4+ IElFRUUgZmxvYXRpbmcgDQo+Pj4gcG9pbnQgcmVwcmVzZW50YXRpb25zIG9mIGF2YWlsYWJsZSBi YW5kd2lkdGguDQo+Pg0KPj4gV2hhdCBJIG1lYW50IGlzIFVucmVzZXJ2ZWQgQmFuZHdpZHRoIGF0 IHByaW9yaXR5IHggYW5kIE1heCBMU1AgDQo+PiBCYW5kd2lkdGggYXQgcHJpb3JpdHkgeC4gDQo+ Pg0KPj4+DQo+Pj4gTXVjaCB0aGFua3MsDQo+Pj4gTG91DQo+Pj4NCj4+PiBPbiAxLzI3LzIwMTMg Nzo0NiBQTSwgWmFmYXIgQWxpICh6YWxpKSB3cm90ZToNCj4+Pj4gQWxsLQ0KPj4+Pg0KPj4+PiBU aGlzIGltcGFjdHMgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIGRyYWZ0IHZlcnNp b25zIChhbmQgDQo+Pj4+IGhlbmNlIGludGVyb3Agd2l0aCB0aGVzZSBpbXBsZW1lbnRhdGlvbnMg bW92aW5nIGZvcndhcmQpLiANCj4+IElNTyB0aGlzIGlzIA0KPj4+PiBhIGJpZ2dlciBjaGFuZ2Ug Zm9yIHVzIHRvIGFzc3VtZSBhdCB0aGUgbGFzdCBjYWxsIHN0YWdlLiANCj4+IEZ1cnRoZXJtb3Jl IA0KPj4+PiB3ZSBoYXZlIGJlZW4gdXNpbmcgSUVFRSBmbG9hdGluZyBwb2ludCBmb3JtYXQgZm9y IFVucmVzZXJ2ZWQgDQo+Pj4+IEJhbmR3aWR0aC8gTWF4IExTUCBCVyBpbiBJRUVFIGZsb2F0aW5n IHBvaW50IGZvcm1hdCBmb3Igb3RoZXIgDQo+Pj4+IHRlY2hub2xvZ2llcy4gT3ZlcmFsbCwgSSB0 aGluayB0aGlzIGNoYW5nZSBzdWZmZXJzIGZyb20gdGhlIA0KPj4gImxhdyBvZiBkaW1pbmlzaGlu ZyByZXR1cm5zIi4NCj4+Pj4NCj4+Pj4gVGhhbmtzDQo+Pj4+DQo+Pj4+IFJlZ2FyZHMgxaAgWmFm YXINCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gMS8yNy8xMyAxMDoyOCBBTSwgIkdydW1hbiwgRnJlZCIg DQo+PiA8ZnJlZC5ncnVtYW5AdXMuZnVqaXRzdS5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+Pj4gSGkg TG91LCBGYXRhaSwgRGFuaWVsZSwNCj4+Pj4+DQo+Pj4+PiBJIHVuZGVyc3RhbmQgdGhlIGxhdGVz dCBjaGFuZ2UgdG8gdGhlIHdheSBiYW5kd2lkdGggaXMgDQo+PiBzaWduYWxlZCBmb3IgIA0KPj4+ Pj4gT0RVZmxleChHRlApLCBpLmUuLCBzaWduYWxpbmcgdGhlIG51bWJlciBvZiB0cmlidXRhcnkg c2xvdHMgDQo+PiBOIGluc3RlYWQgDQo+Pj4+PiBvZiAgdGhlIGJhbmR3aWR0aCByYXRlIGluIGJw cy4gIEkgYmVsaWV2ZSB0aGF0IHRoaXMgc2ltcGxpZmllcyB0aGUgDQo+Pj4+PiBzaWduYWxpbmcg IGFuZCBpbnRlcm9wZXJhYmlsaXR5IHNvIEknbSBpbiBhZ3JlZW1lbnQgd2l0aCANCj4+IHRoaXMg Y2hhbmdlLg0KPj4+Pj4NCj4+Pj4+IEhvd2V2ZXIsIGl0IHNlZW1zIHdlIGFyZSBub3cgaW5jb25z aXN0ZW50IGJldHdlZW4gaG93IHdlIA0KPj4gcmVwcmVzZW50ICANCj4+Pj4+IGJhbmR3aWR0aCBp biByb3V0aW5nIGFuZCBzaWduYWxpbmcgZm9yIE9EVWZsZXgoR0ZQKS4gIFJvdXRpbmcgDQo+Pj4+ PiBhZHZlcnRpc2VzICB0aGUgYmFuZHdpZHRoIHVzaW5nIGEgZmxvYXRpbmcgcG9pbnQgcmVwcmVz ZW50YXRpb24gb2YgDQo+Pj4+PiBiYW5kd2lkdGgsIHdoaWxlICBzaWduYWxpbmcgaXMgdXNpbmcg dGhlIG51bWJlciBvZiB0cmlidXRhcnkgc2xvdHMuIA0KPj4+Pj4gSXQgc2VlbXMgdGhlIHNhbWUg IGJlbmVmaXRzIHdvdWxkIGJlIG9idGFpbmVkIGJ5IA0KPj4gYWR2ZXJ0aXNpbmcgdGhlIG1heCAN Cj4+Pj4+IExTUCBiYW5kd2lkdGggYW5kICB1bnJlc2VydmVkIGJhbmR3aWR0aCBmb3IgT0RVZmxl eChHRlApIGluIA0KPj4gdGVybXMgb2YgDQo+Pj4+PiB0aGUgbnVtYmVyIG9mIHRyaWJ1dGFyeSAg c2xvdHMuDQo+Pj4+Pg0KPj4+Pj4gRnJlZA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4+Pj4+IEJlaGFsZiBPZiAg TG91IEJlcmdlcg0KPj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDEzIDk6MDgg QU0NCj4+Pj4+IFRvOiBGYXRhaSBaaGFuZw0KPj4+Pj4gQ2M6IENDQU1QOyBkcmFmdC1pZXRmLWNj YW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6 IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4gZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+Pg0KPj4+Pj4gRmF0YWksDQo+Pj4+ Pg0KPj4+Pj4gT24gMS8yMy8yMDEzIDY6NDkgQU0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4+ IEhpIExvdSwNCj4+Pj4+Pg0KPj4+Pj4+IEZvciBPRFVmbGV4KENCUiksIHRoZSBmb3JtdWxhIGlz IGZyb20gW0cuNzA5LTIwMTJdIGFuZCBpdCANCj4+IGhhcyBiZWVuIA0KPj4+Pj4+IGRpc2N1c3Nl ZCBiZWZvcmUsIHNvIHBsZWFzZSB0cnVzdCB0aGF0IHRoZXJlIGlzIG5vIA0KPj4gb3Bwb3J0dW5p dHkgZm9yIA0KPj4+Pj4+IG1pc2ludGVycHJldGF0aW9uLiAoTm90ZSB0aGF0IHRoZXJlIGFyZSB0 d28gY2FzZXMsIG9uZSBpcw0KPj4+Pj4+IE9EVWZsZXgoQ0JSKSBhbmQgYW5vdGhlciBvbmUgaXMg T0RVZmxleChHRlApKS4NCj4+Pj4+Pg0KPj4+Pj4+IEluIGFkZHRpb24sIE9EVWZsZXggY2Fubm90 IGJlIGNvbmNhdGVuYXRlZCBieSBbRy43MDktMjAxMl0uDQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzIGZv ciBjb25maXJtaW5nIG15IHVuZGVyc3RhbmRpbmcuICBUaGlzIHJhaXNlcyB0aGUgDQo+PiBxdWVz dGlvbiBvZiANCj4+Pj4+IGlmIHRoZSBuZXcgdHJhZmZpYyBzaG91bGQganVzdCBhcHBseSB0byBP RFVGbGV4PyAgQ29ycmVjdCANCj4+IG1lIGlmIEknbSANCj4+Pj4+IHdyb25nLCBidXQgSSBiZWxp ZXZlIHRoZSBbUkZDNDMyOF0gaXMgc3VmZmljaWVudCBpbiBhbGwgDQo+PiBvdGhlciBjYXNlcy4g IA0KPj4+Pj4gVGhpcyBtYXkgYWxzbyBtYWtlIGl0IGVhc2llciBmb3IgZWFybHkgaW1wbGVtZW50 YXRpb25zIG9mIA0KPj4gdGhlIGRyYWZ0IA0KPj4+Pj4gYXMgdGhlbiB0aGV5IGNhbiBsaW1pdCBj b2RlIGNoYW5nZXMgZnJvbSB0aGUgKC0wMykgcmV2IHRvIA0KPj4gb25seSBPRFVmbGV4IExTUHMu DQo+Pj4+Pg0KPj4+Pj4gSnVzdCB0byBiZSBjbGVhciwgSSdtIHJlYWxseSBqdXN0ICphc2tpbmcq IGFib3V0IHRoaXMuICBBcyBJIHNhaWQgDQo+Pj4+PiBiZWZvcmUsIEknbSBvcGVuIG9uIHNwZWNp Zmljcy4uLg0KPj4+Pj4NCj4+Pj4+IEFueSB0aG91Z2h0cy9jb21tZW50cz8gQXV0aG9ycz8gIElt cGxlbWVudG9ycz8NCj4+Pj4+DQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiBMb3UNCj4+Pj4+DQo+Pj4+ Pg0KPj4+Pj4+IEkgd2lsbCBpc3N1ZSBhIG5ldyB2ZXJzaW9uIHRvbW9ycm93IHRvIGNhcHR1cmUg YWxsIHlvdXIgY29tbWVudHMuDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEJlc3QgUmVnYXJkcw0K Pj4+Pj4+DQo+Pj4+Pj4gRmF0YWkNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBs YWJuLm5ldF0NCj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgMjoxMSBB TQ0KPj4+Pj4+IFRvOiBGYXRhaSBaaGFuZw0KPj4+Pj4+IENjOiBDQ0FNUDsgZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+Pj4gU3ViamVj dDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+Pj4gZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+Pj4NCj4+Pj4+PiBGYXRhaSwN Cj4+Pj4+Pg0KPj4+Pj4+IE9uIDEvMjAvMjAxMyA5OjQzIFBNLCBGYXRhaSBaaGFuZyB3cm90ZToN Cj4+Pj4+Pj4gSGkgTG91LA0KPj4+Pj4+Pg0KPj4+Pj4+PiBZb3Ugc2FpZDoNCj4+Pj4+Pj4+IGJ1 dCB5b3UncmUgc2F5cyBlbmNvZGVkIGFzIChOKk5vbWluYWwgUmF0ZSkgcmlnaHQ/IFdhdCdzIHRo ZSANCj4+Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+Pj4+Pj4N Cj4+Pj4+Pj4gW0ZhdGFpXSBUaGUgb3JpZ2luYWwgd2F5IChpbiB2ZXJzaW9uIDA0JjA1KSBpcyBw dXR0aW5nIA0KPj4gKE4qIE5vbWluYWwNCj4+Pj4+Pj4gUmF0ZSkgaW4gIkJpdF9SYXRlIiBmaWVs ZCBmb3IgT0RVZmxleChHRlApLCB0aGUgdmFsdWUgaXMgdGhhdCB3ZSANCj4+Pj4+Pj4gY2FuIGdl bmVyYWxpemUgdG8ganVzdCB1c2Ugb25lIHNpbmdsZSAiQml0X1JhdGUiIGZpZWxkIHRvIGNhcnJ5 IA0KPj4+Pj4+PiBJRUVFIGZsb2F0IG51bWJlciBmb3IgYm90aCBjYXNlcywgaXQgc2VlbXMgdGhh dCB5b3UgDQo+PiBkb24ndCBhZ3JlZSBvbiANCj4+Pj4+Pj4gdGhpcyB2YWx1ZSwgOi0pDQo+Pj4+ Pj4NCj4+Pj4+PiBJJ3ZlIHNlZW4gZGlmZmVyZW5jZXMgaW4gY2FsY3VsYXRlZCBmbG9hdGluZyBw b2ludCB2YWx1ZXMgZnJvbSANCj4+Pj4+PiBkaWZmZXJlbnQgIGltcGxlbWVudGF0aW9ucywgc28g SSBqdXN0IHdhbnQgdG8gZW5zdXJlIHRoYXQgDQo+PiBzdWNoIGNhc2VzIA0KPj4+Pj4+IGFyZSBh dm9pZGVkLg0KPj4+Pj4+IEknbSBvcGVuIHRvIHNwZWNpZmljIHNvbHV0aW9ucyBhbmQgY2VydGFp bmx5IHdpbGwgZGVmZmVyIG9uIHRoZSAgDQo+Pj4+Pj4gc3BlY2lmaWNzIGFzc3VtaW5nIHRoZXJl IGlzIG5vIG9wcG9ydHVuaXR5IGZvciANCj4+Pj4+PiBtaXNpbnRlcnByZXRhdGlvbi9pbnRlcm9w ICBpc3N1ZXMuIEkgZG9uJ3QgdGhpbmsgdGhlIA0KPj4gb3JpZ2luYWwgcGFzc2VkIA0KPj4+Pj4+ IHRoaXMgdGhyZXNob2xkLCBpLmUuLDoNCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgIE4gPSBDZWls aW5nIG9mDQo+Pj4+Pj4NCj4+Pj4+PiAgICBPRFVmbGV4KENCUikgbm9taW5hbCBiaXQgcmF0ZSAq ICgxICsgT0RVZmxleChDQlIpIGJpdCByYXRlDQo+Pj4+Pj4gdG9sZXJhbmNlKQ0KPj4+Pj4+ICAg IA0KPj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+PiAtLS0tLS0tLS0tDQo+Pj4+Pj4gICAgICAgIE9EVFVrLnRzIG5vbWlu YWwgYml0IHJhdGUgKiAoMSAtIEhPIE9QVWsgYml0IHJhdGUgDQo+PiB0b2xlcmFuY2UpDQo+Pj4+ Pj4NCj4+Pj4+Pj4gLiBUaGVyZWZvcmUsIEkgKHdhcykgYW0gc2F5aW5nIHRoYXQgSSBhbSBnb2lu ZyB0byBhY2NlcHQgeW91ciANCj4+Pj4+Pj4gc3VnZ2VzdGlvbiB0byBjYXJyeSBOIGZvciBPRFVm bGV4KEdGUCkuIFdlIGFyZSANCj4+IGRpc2N1c3Npbmcgd2hlcmUgdG8gDQo+Pj4+Pj4+IHB1dCBO IGZvciBPRFVmbGV4KEdGUCkuDQo+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4gWW91IHNhaWQ6DQo+ Pj4+Pj4+PiBiaXRzIGluIHRoZSBjb250cm9sIHBsYW5lIGFyZSBnZW5lcmFsbHkgY2hlYXAsIElN TyBpdCdzIA0KPj4gYmV0dGVyIHRvICANCj4+Pj4+Pj4+IGhhdmUgc2ltcGxlciBlbmNvZGluZyB0 aGFuIHRvIG9wdGltaXplIGV2ZXJ5IGJpdCAob3IgOCBpbiB0aGlzIA0KPj4+Pj4+Pj4gY2FzZSku DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFtGYXRhaV0gT0ssIEkgd2lsbCBhZGQgYSBuZXcgZmllbGQgKHRv IG9jY3VweSB0aGUgcmVzZXJ2ZWQgYml0cykgDQo+Pj4+Pj4+IHRvIGNhcnJ5IE4uDQo+Pj4+Pj4N Cj4+Pj4+PiBBcyB5b3Ugc2VlIGZpdC4NCj4+Pj4+Pg0KPj4+Pj4+IEp1c3QgdG8gY2xhcmlmeSBt eSB1bmRlcnN0YW5kaW5nLCBPRFVmbGV4IGFuZCBWaXJ0dWFsIA0KPj4gY29uY2F0ZW5hdGlvbiAN Cj4+Pj4+PiBjYW4gIG5ldmVyIGJlIGNvbWJpbmVkIGZvciB0aGUgc2FtZSBzaWduYWwgdHlwZS9s ZXZlbCwgcmlnaHQ/IA0KPj4+Pj4+IChBbHRob3VnaCBhbiAgT0RVZmxleCBjbGllbnQgc2lnbmFs IGNvdWxkIGJlIGNhcnJpZWQgb3ZlciANCj4+IGEgdmlydHVhbCANCj4+Pj4+PiBjb25jYXRlbmF0 ZWQgIE9EVWspLiAgSXMgdGhpcyBjb3JyZWN0IG9yIGRpZCBJIG1pc3Mgc29tZXRoaW5nIGluIA0K Pj4+Pj4+IEc3MDk/DQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4gTG91DQo+Pj4+Pj4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4+ DQo+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4+Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0K Pj4+Pj4+PiBTZW50OiBGcmlkYXksIEphbnVhcnkgMTgsIDIwMTMgMTo0MiBBTQ0KPj4+Pj4+PiBU bzogRmF0YWkgWmhhbmcNCj4+Pj4+Pj4gQ2M6IENDQU1QOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxz LXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtD Q0FNUF0gV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAt Z21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+ Pj4+PiBPbiAxLzE1LzIwMTMgMTA6MTYgUE0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4+Pj4g SGkgTG91LA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRvIGF2b2lkIG1pc3VuZGVyc3RhbmRpbmcsIEkg d291bGQgbGlrZSB0byBjbGFyaWZ5IG1vcmUgb24gdGhlIA0KPj4+Pj4+Pj4gZm9sbG93aW5nIHBv aW50Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gSXQgaXMgYmV0dGVyIHRvIGhh dmUgY29uc2lzdGVudCBmb3JtYXQgYW5kIHRoZSBzYW1lIG1lYW5pbmcgDQo+Pj4+Pj4+Pj4+Pj4g b2Ygb25lDQo+Pj4+Pj4+IGZpZWxkIGZvciBib3RoIE9EVWZsZXgoQ0JSKSBhbmQgR0ZQLiBUaGlz IGlzIHdoeSB3ZSBoYXZlIHNlY3Rpb24gDQo+Pj4+Pj4+IDUuMQ0KPj4+Pj4+PiAmNS4yIHRvIGRl c2NyaWJlIHRoZSBjb21wbGV4IHN0dWZmLg0KPj4+Pj4+Pj4+Pj4gSSBhY3R1YWxseSB3YXNuJ3Qg c3VnZ2VzdGluZyB0aGF0IE4gYmUgY2FycmllZCBpbiANCj4+IHRoZSBiaXQgcmF0ZSAgDQo+Pj4+ Pj4+Pj4+PiBmaWVsZC4NCj4+Pj4+Pj4+Pj4+IFRoZSBiaXQgcmF0ZSBmaWVsZCBjYW4gZWl0aGVy IGJlIHNldCBhcyBkZXNjcmliZWQgb3IgdG8gemVybyANCj4+Pj4+Pj4+Pj4+IChpLmUuLCAgaWdu b3JlZCkuICBBdCB0aGUgdGltZSwgSSB3YXMgdGhpbmtpbmcgYWJvdXQgDQo+PiBjYXJyeWluZyBO IA0KPj4+Pj4+Pj4+Pj4gaW4gdGhlICByZXNlcnZlZCAgZmllbGQuIEJ1dCBwZXJoYXBzIHRoZSBy aWdodCBwbGFjZSANCj4+IGlzIE1ULCBpZiANCj4+Pj4+Pj4+Pj4+IG15IHVuZGVyc3RhbmRpbmcg aXMgIHJpZ2h0ICAod291bGQgYWx3YXlzIGJlIDEgDQo+PiBvdGhlcndpc2UpLiBJJ20gDQo+Pj4+ Pj4+Pj4+PiBvcGVuIHRvIGVpdGhlci4uLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gW0ZhdGFp XSBXaHkgbm90IGp1c3QgdXNlICJiaXQgcmF0ZSJmaWVsZCB0byBjYXJyeSANCj4+ICJOImJlY2F1 c2UgIk4iDQo+Pj4+Pj4+Pj4+IGltcGxpZXMgYml0IHJhdGU/ICBJIGFtIE9LIGlmIHlvdSBsaWtl IHRvIHVzZSBhIG5ldyANCj4+IGZpbGVkIChsaWtlIA0KPj4+Pj4+Pj4+PiAiVFMNCj4+Pj4+Pj4+ Pj4gTnVtYmVyIikgdG8gb2NjdXB5IHRoZSByZXNlcnZlZCBmaWVsZCBldmVuIHRob3VnaCANCj4+ IHRoYXQgSSBwcmVmZXIgDQo+Pj4+Pj4+Pj4+IHRoZSAgb3JpZ2luYWwgYXBwcm9hY2ggKGllLiwg dXNlICJiaXQgcmF0ZSJmaWVsZCB0byBjYXJyeSAiTiIpLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g QXJlIHlvdSBwcm9wb3NpbmcgZHJvcHBpbmcgY2FycnlpbmcgYml0IHJhdGVzIA0KPj4gcmVwcmVz ZW50ZWQgYXMgYW4gDQo+Pj4+Pj4+Pj4gSUVFRSAgZmxvYXRpbmcgcG9pbnQgYW5kIGp1c3QgY2Fy cnlpbmcgTiBmb3IgT0RVZmxleD8gDQo+PiBUaGlzIHNlZW1zIA0KPj4+Pj4+Pj4+IHdvcmthYmxl ICB0byAgbWUsIGJ1dCB3ZSBzaG91bGQgZW5zdXJlIHRoYXQgdGhlcmUgYXJlIG5vIA0KPj4+Pj4+ Pj4+IHNpZ25pZmljYW50IG9iamVjdGlvbnMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gW0ZhdGFpXSBU aGVyZSBhcmUgdHdvIHVzYWdlcyBmb3IgIiBCaXRfUmF0ZSAiIGZpZWxkIGFzIA0KPj4gZGVzY3Jp YmVkIA0KPj4+Pj4+Pj4gaW4gdGhlIGxpbmVzIDI4Ny0zMTAuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g KDEpICAgIEZvciBPRFVmbGV4KENCUiksIHRoZSBCaXRfUmF0ZSBmaWVsZCBpbmRpY2F0ZXMgDQo+ PiB0aGUgbm9taW5hbA0KPj4+Pj4+Pj4gYml0DQo+Pj4+Pj4+PiByYXRlIG9mIE9EVWZsZXgoQ0JS KSBleHByZXNzZWQgaW4gYnl0ZXMgcGVyIHNlY29uZCwgDQo+PiBlbmNvZGVkIGFzIGEgIA0KPj4+ Pj4+Pj4gMzItYml0ICBJRUVFIHNpbmdsZSBwcmVjaXNpb24gZmxvYXRpbmctcG9pbnQgbnVtYmVy LiBGb3IgdGhpcyANCj4+Pj4+Pj4+IGNhc2UsIHdlIE1VU1QgIHVzZSAgMzItYml0IElFRUUgZmxv YXRpbmcgcG9pbnQgaW5zdGVhZCBvZiANCj4+Pj4+Pj4+ICJOIihQbGVhc2Ugc2VlIG1vcmUgaW4g c2VjdGlvbiAgNS4xKS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSSBndWVzcyB5b3UgcmVhbGx5IHN0aWxs IG5lZWQgKHRvIGJlIGJhc2VkIG9uKSB0aGUgY2xpZW50IHNpZ25hbCANCj4+Pj4+Pj4gcmF0ZSBh dCB0aGUgZWRnZXMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gKDIpICAgIEZvciBPRFVm bGV4KEdGUCksIHdlIGNhbiBjaGFuZ2UgdGhlIHRleHQgKHRoZSANCj4+IGxpbmVzIGZyb20gMzA1 DQo+Pj4+Pj4+PiB0bw0KPj4+Pj4+Pj4gMzEwKSBiYXNlZCBvbiB5b3VyIHN1Z2dlc3Rpb24sIGll LiwgdGhlIEJpdF9SYXRlIGZpZWxkIA0KPj4gaXMgdXNlZCB0byAgDQo+Pj4+Pj4+PiBjYXJyeSAg Ik4idG8gaW5kaWNhdGUgdGhlIG5vbWluYWwgYml0IHJhdGUgb2YgdGhlICBPRFVmbGV4KEdGUCku DQo+Pj4+Pj4+DQo+Pj4+Pj4+IGJ1dCB5b3UncmUgc2F5cyBlbmNvZGVkIGFzIChOKk5vbWluYWwg UmF0ZSkgcmlnaHQ/ICBXYXQncyB0aGUgDQo+Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3Qg Y2FycnlpbmcgTj8NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGVyZWZv cmUsIEkgYW0gcHJvcG9zaW5nIHVzaW5nIG9uZSBzaW5nbGUgZmlsZWQgKCJCaXRfUmF0ZSAiKSAN Cj4+Pj4+Pj4+IGZvciB0aGVzZSB0d28gY2FzZXMsIGluIHRoaXMgd2F5LCB3ZSBjYW4gbGVhdmUg dGhlICJSZXNlcnZlZCIgDQo+Pj4+Pj4+PiBiaXRzIGZvciBmdXR1cmUuDQo+Pj4+Pj4+DQo+Pj4+ Pj4+IGJpdHMgaW4gdGhlIGNvbnRyb2wgcGxhbmUgYXJlIGdlbmVyYWxseSBjaGVhcCwgSU1PIGl0 J3MgDQo+PiBiZXR0ZXIgdG8gDQo+Pj4+Pj4+IGhhdmUgIHNpbXBsZXIgZW5jb2RpbmcgdGhhbiB0 byBvcHRpbWl6ZSBldmVyeSBiaXQgKG9yIDggaW4gdGhpcyANCj4+Pj4+Pj4gY2FzZSkuDQo+Pj4+ Pj4+DQo+Pj4+Pj4+IExvdQ0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEhvcGUgd2UgYXJl IG5vdyBhdCB0aGUgc2FtZSBwYWdlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBCZXN0 IFJlZ2FyZHMNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBGYXRhaQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+ Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gQ0NBTVAg bWFpbGluZyBsaXN0DQo+Pj4+PiBDQ0FNUEBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+ Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2NhbXANCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+DQo+Pg0KPiANCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWls aW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NjYW1wDQo= From lberger@labn.net Mon Jan 28 18:56:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B3721E8049 for ; Mon, 28 Jan 2013 18:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.339 X-Spam-Level: X-Spam-Status: No, score=-101.339 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 5eUIaxfGsSkF for ; Mon, 28 Jan 2013 18:56:07 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 6537E21E8042 for ; Mon, 28 Jan 2013 18:56:06 -0800 (PST) Received: (qmail 5965 invoked by uid 0); 29 Jan 2013 02:55:43 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 29 Jan 2013 02:55:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=X1QaMZ24JNIfJb04PbUCVC24310GqHZRA/0zd3KfBAo=; b=bDTExFWU0ThWn+UaFEW3/U+InIWH1LWPG38sainHl0oiLBSsKcqwbtF3e806fx2j5RfPattDtnZaEVau0W4pB2l/hx5VSayqODOBRvvG98W86uF0LkSTQfWwVFsT9aJr; Received: from box313.bluehost.com ([69.89.31.113]:43383 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1U01MN-0001vr-FZ; Mon, 28 Jan 2013 19:55:43 -0700 Message-ID: <51073A3B.7010409@labn.net> Date: Mon, 28 Jan 2013 21:55:55 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fatai Zhang References: <5105E684.4030607@labn.net> <4A1562797D64E44993C5CBF38CF1BE48073D01@ESESSMB301.ericsson.se> <5106DED0.3090008@labn.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 02:56:08 -0000 Fatai, Thanks for the input. On 1/28/2013 9:26 PM, Fatai Zhang wrote: > Hi Lou, > > I would pick up option 2 (better than option 1) because of the > following reasons, > even though I spent much time to convince you (but > I failed). I'm not sure what your referring to, but I'm also not sure we really need to discuss it further. As I said on 1/23, I'm open to specifics (that ease interoperability and implementation, including for early adopters). I have yet to state my poll response. I think 2 is a perfectly fine approach, and more so than some of the other options. I'll wait at least a little bit before I state my actual preferred ordering. It'll be interesting to see if others in the WG agree with your current prioritization. Thanks, Lou > (1) There will be consistent between signaling draft (need crank-back) and the existing routing draft (we all spent so much time on routing draft to get the consensus). > (2) There will be consistent for "Bit_Rate" filed for both ODUflex(CBR) and ODUflex(GFP) cases (ie, it only needs one single "Bit_Rate" field). > (3) I don't think option 3&4 are better than option 1&2 for interworking with early implementations (I think all the authors are from vendors, we know this very well. Usually/sometimes, there is actually no compatibility/interworking issue in the real world). > > For option 3, I am fine because I appreciate the work that I have done, :-), if we don't count the additional work on routing draft. > > > Anyway, please don't think about option 4, I don't see any significant advantages by doing that besides more work and more discussions. > > > > Best Regards > > Fatai > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, January 29, 2013 4:26 AM > To: CCAMP > Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) > > All, > We would like to try to close the discussion on the G.709 > drafts so that we can move rapidly towards publication request. The > discussion of (one of my) LC comments has resulted in several options > for the signaling ODU-related traffic parameters, and the point has > been raised that realigning routing with signaling should be discussed. > > Please keep in mind that the objective of any PS is interoperability, > and that there may be early implementations that match g709v3-04. > > The basic question is one of if N, the number of time slots needed to > support a ODUflex(GFP) signal, should be carried as a calculated IEEE > floating point number or directly. Options 1 and 2 below reflect the > former, options 3 and 4 match the latter. It is worth noting that only > options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be > calculated for ODUflex(CBR) signal types with all options. > > Please state your support for one the options and, if you wish, the > justification for your position: > > 1) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-04 > i.e., redefine [RFC4328] Traffic Parameters c-type when used with > OTN-TDM labels. ODUflex(GFP) number of tributary slots (N) is > encoded as: > > ... the Bit_Rate field for ODUflex(GFP) MUST > equal to one of the 80 values listed below: > > 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; > 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; > 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. > > 2) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-05 > i.e., use a new C-type for OTN-TDM labels. Encoding details > unchanged from g709v3-04. > (This option addresses the issue of the same c-type needing to > be parsed based on label/switching type.) > > 3) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-06 > i.e., use a new C-type for OTN-TDM labels. N is directly carried > for ODUflex(GFP) only. > > 4) Discussed, but not in any draft > Use draft-ietf-ccamp-gmpls-signaling-g709v3-04 encoding for all > but ODUflex(GFP), and define new ODUflex(GFP) specific Traffic > Parameters based on g709v3-06, presumably with unused fields > removed. > (This also addresses the issue of the same c-type needing to be > parsed based on label type, but means there are different types > based on signal type.) > > Option 1 and 2 do not imply any changes to routing, while options 3 and > 4 may. Routing implications will be discussed based on the results of > this poll, and only if there is consensus to support positions 3 or 4. > > We hope to make a consensus call by the end of the week, but will > continue the discussion as needed. > > Much thanks, > Lou (and Deborah) > > On 1/28/2013 5:08 AM, Daniele Ceccarelli wrote: >> All, >> >> I think the changes proposed are meaningful and would support them in an individual or early WG draft, but they don't seem to provide significative advantages to risk interworking issues with early implementations. >> Moreover the changes don't allow us getting totally rid of of the bit_rate field as it is still needed for ODUflex (CBR). >> >> My 2c >> Daniele >> >> >>> -----Original Message----- >>> From: Zafar Ali (zali) [mailto:zali@cisco.com] >>> Sent: luned矛 28 gennaio 2013 4.47 >>> To: Lou Berger >>> Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP; >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: Re: [CCAMP] WG Last Call comments on >>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>> >>> Hi Lou- >>> >>> Please see in-line. >>> >>> Thanks >>> >>> Regards...Zafar >>> >>> On 1/27/13 9:46 PM, "Lou Berger" wrote: >>> >>>> Zafar, >>>> Is your comment with respect to just routing or both >>> signaling and >>>> routing? >>> >>> Both, including consistency between signaling and routing attributes. >>> >>>> >>>> Also, when you say "implementations based on draft versions", >>> do these >>>> implementations include support for ODUflex? (Which has really been >>>> the focus of the discussion.) >>> >>> Yes, I was referring to ODUFlex. As you know, fixed ODU is >>> signaled via level (0 BW) so its not an issue. >>> >>>> >>>> BTW I took Fred's comments as related to just the new >>> OTN-specific ISCD >>>> definitions (section 4.1.2 of ospf-g709v3-05, in particular). Note >>>> that section 4.1.1 already carries N (number of ODUs) not >>> IEEE floating >>>> point representations of available bandwidth. >>> >>> What I meant is Unreserved Bandwidth at priority x and Max LSP >>> Bandwidth at priority x. >>> >>>> >>>> Much thanks, >>>> Lou >>>> >>>> On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote: >>>>> All- >>>>> >>>>> This impacts existing implementations based on draft versions (and >>>>> hence interop with these implementations moving forward). >>> IMO this is >>>>> a bigger change for us to assume at the last call stage. >>> Furthermore >>>>> we have been using IEEE floating point format for Unreserved >>>>> Bandwidth/ Max LSP BW in IEEE floating point format for other >>>>> technologies. Overall, I think this change suffers from the >>> "law of diminishing returns". >>>>> >>>>> Thanks >>>>> >>>>> Regards 艩 Zafar >>>>> >>>>> >>>>> On 1/27/13 10:28 AM, "Gruman, Fred" >>> wrote: >>>>> >>>>>> Hi Lou, Fatai, Daniele, >>>>>> >>>>>> I understand the latest change to the way bandwidth is >>> signaled for >>>>>> ODUflex(GFP), i.e., signaling the number of tributary slots >>> N instead >>>>>> of the bandwidth rate in bps. I believe that this simplifies the >>>>>> signaling and interoperability so I'm in agreement with >>> this change. >>>>>> >>>>>> However, it seems we are now inconsistent between how we >>> represent >>>>>> bandwidth in routing and signaling for ODUflex(GFP). Routing >>>>>> advertises the bandwidth using a floating point representation of >>>>>> bandwidth, while signaling is using the number of tributary slots. >>>>>> It seems the same benefits would be obtained by >>> advertising the max >>>>>> LSP bandwidth and unreserved bandwidth for ODUflex(GFP) in >>> terms of >>>>>> the number of tributary slots. >>>>>> >>>>>> Fred >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>> Behalf Of Lou Berger >>>>>> Sent: Wednesday, January 23, 2013 9:08 AM >>>>>> To: Fatai Zhang >>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>> >>>>>> Fatai, >>>>>> >>>>>> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>>>>>> Hi Lou, >>>>>>> >>>>>>> For ODUflex(CBR), the formula is from [G.709-2012] and it >>> has been >>>>>>> discussed before, so please trust that there is no >>> opportunity for >>>>>>> misinterpretation. (Note that there are two cases, one is >>>>>>> ODUflex(CBR) and another one is ODUflex(GFP)). >>>>>>> >>>>>>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >>>>>> >>>>>> Thanks for confirming my understanding. This raises the >>> question of >>>>>> if the new traffic should just apply to ODUFlex? Correct >>> me if I'm >>>>>> wrong, but I believe the [RFC4328] is sufficient in all >>> other cases. >>>>>> This may also make it easier for early implementations of >>> the draft >>>>>> as then they can limit code changes from the (-03) rev to >>> only ODUflex LSPs. >>>>>> >>>>>> Just to be clear, I'm really just *asking* about this. As I said >>>>>> before, I'm open on specifics... >>>>>> >>>>>> Any thoughts/comments? Authors? Implementors? >>>>>> >>>>>> Thanks, >>>>>> Lou >>>>>> >>>>>> >>>>>>> I will issue a new version tomorrow to capture all your comments. >>>>>>> >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>>>> Fatai >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>> Sent: Wednesday, January 23, 2013 2:11 AM >>>>>>> To: Fatai Zhang >>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>> >>>>>>> Fatai, >>>>>>> >>>>>>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>>>>>> Hi Lou, >>>>>>>> >>>>>>>> You said: >>>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>>> value of this vs just carrying N? >>>>>>>> >>>>>>>> [Fatai] The original way (in version 04&05) is putting >>> (N* Nominal >>>>>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we >>>>>>>> can generalize to just use one single "Bit_Rate" field to carry >>>>>>>> IEEE float number for both cases, it seems that you >>> don't agree on >>>>>>>> this value, :-) >>>>>>> >>>>>>> I've seen differences in calculated floating point values from >>>>>>> different implementations, so I just want to ensure that >>> such cases >>>>>>> are avoided. >>>>>>> I'm open to specific solutions and certainly will deffer on the >>>>>>> specifics assuming there is no opportunity for >>>>>>> misinterpretation/interop issues. I don't think the >>> original passed >>>>>>> this threshold, i.e.,: >>>>>>> >>>>>>> N = Ceiling of >>>>>>> >>>>>>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate >>>>>>> tolerance) >>>>>>> >>>>>>> ----------------------------------------------------------- >>> ---------- >>>>>>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate >>> tolerance) >>>>>>> >>>>>>>> . Therefore, I (was) am saying that I am going to accept your >>>>>>>> suggestion to carry N for ODUflex(GFP). We are >>> discussing where to >>>>>>>> put N for ODUflex(GFP). >>>>>>>> >>>>>>> >>>>>>>> You said: >>>>>>>>> bits in the control plane are generally cheap, IMO it's >>> better to >>>>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>>>> case). >>>>>>>> >>>>>>>> [Fatai] OK, I will add a new field (to occupy the reserved bits) >>>>>>>> to carry N. >>>>>>> >>>>>>> As you see fit. >>>>>>> >>>>>>> Just to clarify my understanding, ODUflex and Virtual >>> concatenation >>>>>>> can never be combined for the same signal type/level, right? >>>>>>> (Although an ODUflex client signal could be carried over >>> a virtual >>>>>>> concatenated ODUk). Is this correct or did I miss something in >>>>>>> G709? >>>>>>> >>>>>>> Thanks, >>>>>>> Lou >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Fatai >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>> Sent: Friday, January 18, 2013 1:42 AM >>>>>>>> To: Fatai Zhang >>>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>>>>>> Hi Lou, >>>>>>>>> >>>>>>>>> To avoid misunderstanding, I would like to clarify more on the >>>>>>>>> following point. >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> It is better to have consistent format and the same meaning >>>>>>>>>>>>> of one >>>>>>>> field for both ODUflex(CBR) and GFP. This is why we have section >>>>>>>> 5.1 >>>>>>>> &5.2 to describe the complex stuff. >>>>>>>>>>>> I actually wasn't suggesting that N be carried in >>> the bit rate >>>>>>>>>>>> field. >>>>>>>>>>>> The bit rate field can either be set as described or to zero >>>>>>>>>>>> (i.e., ignored). At the time, I was thinking about >>> carrying N >>>>>>>>>>>> in the reserved field. But perhaps the right place >>> is MT, if >>>>>>>>>>>> my understanding is right (would always be 1 >>> otherwise). I'm >>>>>>>>>>>> open to either... >>>>>>>>>>>> >>>>>>>>>>> [Fatai] Why not just use "bit rate"field to carry >>> "N"because "N" >>>>>>>>>>> implies bit rate? I am OK if you like to use a new >>> filed (like >>>>>>>>>>> "TS >>>>>>>>>>> Number") to occupy the reserved field even though >>> that I prefer >>>>>>>>>>> the original approach (ie., use "bit rate"field to carry "N"). >>>>>>>>>> >>>>>>>>>> Are you proposing dropping carrying bit rates >>> represented as an >>>>>>>>>> IEEE floating point and just carrying N for ODUflex? >>> This seems >>>>>>>>>> workable to me, but we should ensure that there are no >>>>>>>>>> significant objections. >>>>>>>>> >>>>>>>>> [Fatai] There are two usages for " Bit_Rate " field as >>> described >>>>>>>>> in the lines 287-310. >>>>>>>>> >>>>>>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates >>> the nominal >>>>>>>>> bit >>>>>>>>> rate of ODUflex(CBR) expressed in bytes per second, >>> encoded as a >>>>>>>>> 32-bit IEEE single precision floating-point number. For this >>>>>>>>> case, we MUST use 32-bit IEEE floating point instead of >>>>>>>>> "N"(Please see more in section 5.1). >>>>>>>> >>>>>>>> I guess you really still need (to be based on) the client signal >>>>>>>> rate at the edges. >>>>>>>> >>>>>>>>> >>>>>>>>> (2) For ODUflex(GFP), we can change the text (the >>> lines from 305 >>>>>>>>> to >>>>>>>>> 310) based on your suggestion, ie., the Bit_Rate field >>> is used to >>>>>>>>> carry "N"to indicate the nominal bit rate of the ODUflex(GFP). >>>>>>>> >>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>> value of this vs just carrying N? >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") >>>>>>>>> for these two cases, in this way, we can leave the "Reserved" >>>>>>>>> bits for future. >>>>>>>> >>>>>>>> bits in the control plane are generally cheap, IMO it's >>> better to >>>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>>> case). >>>>>>>> >>>>>>>> Lou >>>>>>>> >>>>>>>>> >>>>>>>>> Hope we are now at the same page. >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> >>>>>>>>> Fatai >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From julien.meuric@orange.com Tue Jan 29 01:09:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0830321F86FA for ; Tue, 29 Jan 2013 01:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZGWpUl7lwGr for ; Tue, 29 Jan 2013 01:09:02 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id EE30421F86F0 for ; Tue, 29 Jan 2013 01:09:01 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E0DC116C005 for ; Tue, 29 Jan 2013 10:08:59 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id D8E2316C002 for ; Tue, 29 Jan 2013 10:08:59 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 10:08:59 +0100 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 10:08:59 +0100 Message-ID: <510791AB.1090006@orange.com> Date: Tue, 29 Jan 2013 10:08:59 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: ccamp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Jan 2013 09:08:59.0623 (UTC) FILETIME=[46489770:01CDFE00] Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 09:09:03 -0000 Hi. Support (as co-author). Julien Le 24/01/2013 19:51, BRUNGARD, DEBORAH A a 閏rit : > > Sorry it抯 Feb. 7^th (my mind is too focused on Super Bowl > weekend)- > > > > *From:*ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On > Behalf Of *BRUNGARD, DEBORAH A > > All, > > > > This is start a two week poll on making > draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. > Please send email to the list indicating 搚es/support or 搉o/do not > support. If indicating no, please state your technical reservations > with the document. > > > > The poll ends Thursday, January 31^st . > > > > Note, as stated by some of the authors, IPR has been disclosed in > compliance with IETF IPR rules. > > > > Thanks, > > Deborah and Lou > > > > > > > > _______________________________________________ CCAMP mailing list > CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From julien.meuric@orange.com Tue Jan 29 01:23:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F0221F84CE for ; Tue, 29 Jan 2013 01:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 uKao3NKocURO for ; Tue, 29 Jan 2013 01:23:22 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 94A8321F8487 for ; Tue, 29 Jan 2013 01:23:22 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3FC717E4002 for ; Tue, 29 Jan 2013 10:23:21 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 0638C9C4001 for ; Tue, 29 Jan 2013 10:23:20 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 10:23:20 +0100 Received: from [10.193.71.218] ([10.193.71.218]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 10:23:20 +0100 Message-ID: <51079508.1050907@orange.com> Date: Tue, 29 Jan 2013 10:23:20 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: ccamp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Jan 2013 09:23:20.0702 (UTC) FILETIME=[4786D1E0:01CDFE02] Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 09:23:23 -0000 Hi. I still have doubts on the actual applicability of cost recording in the field, but yes: the latency part deserves support. Julien Le 24/01/2013 19:47, BRUNGARD, DEBORAH A a 閏rit : > All, > This is start a two week poll on making > draft-ali-ccamp-te-metric-recording-03 a ccamp working group document. > Please send email to the list indicating 搚es/support or 搉o/do not > support. If indicating no, please state your technical reservations > with the document. > The poll ends Thursday, Feb^. 7th. > Note, as stated by some of the authors, there is IPR 搒till being > documented. > Thanks, > Deborah and Lou > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From Attila.Takacs@ericsson.com Tue Jan 29 01:36:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37F121F87AB for ; Tue, 29 Jan 2013 01:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QByxNo6npRxd for ; Tue, 29 Jan 2013 01:36:32 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BE2B921F879E for ; Tue, 29 Jan 2013 01:36:31 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-aa-5107981e927b Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6D.3D.19728.E1897015; Tue, 29 Jan 2013 10:36:30 +0100 (CET) Received: from ESESSMB201.ericsson.se ([169.254.1.103]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 10:36:29 +0100 From: Attila Takacs To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-oam-configuration-fwk-09.txt Thread-Index: AQHN+vGo9E+h1w95K0OMxYAcZQsNXZhgEM0Q Date: Tue, 29 Jan 2013 09:36:28 +0000 Message-ID: References: <20130125114642.26387.84014.idtracker@ietfa.amsl.com> In-Reply-To: <20130125114642.26387.84014.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra7cDPZAgwdH5CyezLnBYnG5q5vd gcnjZf8cRo8lS34yBTBFcdmkpOZklqUW6dslcGX0rGhlLGgWrLizdw5jA+NV3i5GTg4JAROJ a5v+sEHYYhIX7q0Hsrk4hAQOMUp8X/uUEcJZwijxoPMdO0gVm4CBxIXmycwgtoiAqsSZmxcZ QWxmAWuJV8daweLCAgESn68cB5rEAVQTKLHnjjpEuZHE3FermEHCLECt2/a4goR5Bbwl5l46 xAgSFhJwlPh3Kg0kzCngJHGr4zMLiM0IdNr3U2uYIBaJS9x6Mp8J4mQBiSV7zjND2KISLx// Y4WwFSU+vtoHdZiOxILdn9ggbG2JZQtfM0OsFZQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlW MbLnJmbmpJcbbWIExsfBLb9VdzDeOSdyiFGag0VJnDfc9UKAkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBsZIvwnPw9ie5VcFh3//cVzsOWu41qnps9j1nxs8q7YT9vp7KnKWp8Q7T40fLpxs +sV3WSPOcRxeFrhyqsDcm7Xnp/pdu5XadGWb4ZwlRlKHFCOkzy3vSP6nKfrDY/aaK0enfdmU LZZ9SWSN2NP238tOtk0ICox+m9R0UPHqtVfXfy3ftuLe0dXLlFiKMxINtZiLihMBzrPv310C AAA= Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-oam-configuration-fwk-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 09:36:32 -0000 Hi all, In preparing the draft for publication we did some wording/grammar updates = to the document based on the editorial comments received from Deborah. Thanks, Attila -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Friday, January 25, 2013 12:47 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-oam-configuration-fwk-09.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : GMPLS RSVP-TE extensions for OAM Configuration Author(s) : Attila Takacs Don Fedyk Jia He Filename : draft-ietf-ccamp-oam-configuration-fwk-09.txt Pages : 18 Date : 2013-01-25 Abstract: OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-oam-configuration-fwk There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-oam-configuration-fwk-0= 9 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Jonathan.Hardwick@metaswitch.com Tue Jan 29 05:24:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D5121F8891 for ; Tue, 29 Jan 2013 05:24:45 -0800 (PST) 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 E1JOJU1Ce9U8 for ; Tue, 29 Jan 2013 05:24:44 -0800 (PST) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id 51DFE21F87D7 for ; Tue, 29 Jan 2013 05:24:44 -0800 (PST) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 29 Jan 2013 13:23:23 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.02.0328.009; Tue, 29 Jan 2013 13:24:16 +0000 From: Jonathan Hardwick To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: Ac36YpzyB19srrPaSouArquCC8tVHQDwVZ/Q Date: Tue, 29 Jan 2013 13:24:15 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBACEA535E2@ENFICSMBX1.datcon.co.uk> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.185] Content-Type: multipart/alternative; boundary="_000_09CE6C3BE5E1EA40B987BF5F25D8DDBACEA535E2ENFICSMBX1datco_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 13:24:45 -0000 --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBACEA535E2ENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes / support. From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: 24 January 2013 18:43 To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = "yes/support" or "no/do not support". If indicating no, please state your t= echnical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBACEA535E2ENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes / support.=

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org= ] On Behalf Of BRUNGARD, DEBORAH A
Sent: 24 January 2013 18:43
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02= a WG document

 

All,

 

This is start a two week poll on making= draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. Pleas= e send email to the list indicating “yes/support” or “no/= do not support”. If indicating no, please state your technical reservat= ions with the document.

 

The poll ends Thursday, January 31st.

 

Note, as stated by some of the authors,= IPR has been disclosed in compliance with IETF IPR rules.

 

Thanks,

Deborah and Lou

 

 

--_000_09CE6C3BE5E1EA40B987BF5F25D8DDBACEA535E2ENFICSMBX1datco_-- From Jonathan.Hardwick@metaswitch.com Tue Jan 29 05:25:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DADE21F8890 for ; Tue, 29 Jan 2013 05:25:44 -0800 (PST) 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 IlfCl-Bq0f-J for ; Tue, 29 Jan 2013 05:25:43 -0800 (PST) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id EB0F821F87D7 for ; Tue, 29 Jan 2013 05:25:42 -0800 (PST) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 29 Jan 2013 13:25:13 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%19]) with mapi id 14.02.0328.009; Tue, 29 Jan 2013 13:25:15 +0000 From: Jonathan Hardwick To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: Ac36Y0THF366bQJXRBinToGRQUxfKQDwNaEA Date: Tue, 29 Jan 2013 13:25:14 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBACEA53601@ENFICSMBX1.datcon.co.uk> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.185] Content-Type: multipart/alternative; boundary="_000_09CE6C3BE5E1EA40B987BF5F25D8DDBACEA53601ENFICSMBX1datco_" MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 13:25:44 -0000 --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBACEA53601ENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes / support. From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: 24 January 2013 18:48 To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG d= ocument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g "yes/support" or "no/do not support". If indicating no, please state your= technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR "still being documente= d". Thanks, Deborah and Lou --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBACEA53601ENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes / support.=

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org= ] On Behalf Of BRUNGARD, DEBORAH A
Sent: 24 January 2013 18:48
To: ccamp@ietf.org
Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-= 03 WG document

 

All,

 

This is start a two week poll on making= draft-ali-ccamp-te-metric-recording-03 a ccamp working group document. Ple= ase send email to the list indicating “yes/support” or “n= o/do not support”. If indicating no, please state your technical reservat= ions with the document.

 

The poll ends Thursday, Feb= . 7th.

 

Note, as stated by some of the authors,= there is IPR “still being documented”.

 

Thanks,

Deborah and Lou

 

 

--_000_09CE6C3BE5E1EA40B987BF5F25D8DDBACEA53601ENFICSMBX1datco_-- From zali@cisco.com Tue Jan 29 08:40:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1832521F890D for ; Tue, 29 Jan 2013 08:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] 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 cZgetMfiRb+w for ; Tue, 29 Jan 2013 08:40:42 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3921F88EF for ; Tue, 29 Jan 2013 08:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20868; q=dns/txt; s=iport; t=1359477640; x=1360687240; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=rzkawtXWYq1n+y6dKsF2KhG+AtZsj1kdc1YeAemgNSo=; b=ZonFNgoZilS8QLjcy8tcSWT9CPonfNjy5OdUcgEfGNUBrVwASlJ1XQGF e9u/8hS4Bm44stwAYJRl/PJyg/fTWB/GE03NT3w87XS8cRzIaaxvnN0kM rChHjg1BRSGQ3RYRM3U4LxeUMYSdJZAINgRYowtZNTKCKXHLIEQHOXKy0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAB77B1GtJXHB/2dsb2JhbABEhka3JHQWc4IeAQEBBAEBASARMwcGEQYBCA4DAwEBAQECAgYZBAMCBCULFAEICAIEARIIE4d2DK47gkCQMQSBI4tgFoJdMmEDpliCd4FnPQ X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="166918861" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jan 2013 16:40:39 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0TGed8r008507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 16:40:39 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 10:40:39 -0600 From: "Zafar Ali (zali)" To: Lou Berger , CCAMP Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZXB3/s+GYEYvka9gmYAFxeuf5hglFOA Date: Tue, 29 Jan 2013 16:40:39 +0000 Message-ID: In-Reply-To: <5106DED0.3090008@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.253.167] Content-Type: text/plain; charset="utf-8" Content-ID: <18ED0F734E99E24D931337348B429C93@cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 16:40:44 -0000 SGkgTG91LCBDLWNhbXBlcnM6IA0KDQpJIHdvdWxkIHBpY2sgT3B0aW9uIDI7IGl0J3MgY2xlYW5l ciBhbmQgIGFkZHJlc3NlcyB0aGUgaXNzdWUgcmVsYXRlZCB0bw0Kb3ZlcmxvYWRpbmcgdGhlIHNh bWUgYy10eXBlLg0KDQpUaGFua3MNCg0KUmVnYXJkc+KAplphZmFyDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206ICJsYmVyZ2VyQGxhYm4ubmV0IiA8bGJlcmdlckBsYWJuLm5l dD4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSAyOCwgMjAxMyAzOjI1IFBNDQpUbzogImNjYW1wQGll dGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbQ0NBTVBdIFBvbGwgb24gT0RVRmxl eC1yZWxhdGVkIGVuY29kaW5nICh3YXM6IFdHIExhc3QgQ2FsbA0KY29tbWVudHMgb24gZHJhZnQt aWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KDQo+QWxsLA0KPglXZSB3b3Vs ZCBsaWtlIHRvIHRyeSB0byBjbG9zZSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgRy43MDkNCj5kcmFm dHMgc28gdGhhdCB3ZSBjYW4gbW92ZSByYXBpZGx5IHRvd2FyZHMgcHVibGljYXRpb24gcmVxdWVz dC4gIFRoZQ0KPmRpc2N1c3Npb24gb2YgKG9uZSBvZiBteSkgTEMgY29tbWVudHMgaGFzIHJlc3Vs dGVkIGluIHNldmVyYWwgb3B0aW9ucw0KPmZvciB0aGUgc2lnbmFsaW5nIE9EVS1yZWxhdGVkIHRy YWZmaWMgcGFyYW1ldGVycywgYW5kIHRoZSBwb2ludCBoYXMNCj5iZWVuIHJhaXNlZCB0aGF0IHJl YWxpZ25pbmcgcm91dGluZyB3aXRoIHNpZ25hbGluZyBzaG91bGQgYmUgZGlzY3Vzc2VkLg0KPg0K PlBsZWFzZSBrZWVwIGluIG1pbmQgdGhhdCB0aGUgb2JqZWN0aXZlIG9mIGFueSBQUyBpcyBpbnRl cm9wZXJhYmlsaXR5LA0KPmFuZCB0aGF0IHRoZXJlIG1heSBiZSBlYXJseSBpbXBsZW1lbnRhdGlv bnMgdGhhdCBtYXRjaCBnNzA5djMtMDQuDQo+DQo+VGhlIGJhc2ljIHF1ZXN0aW9uIGlzIG9uZSBv ZiBpZiBOLCB0aGUgbnVtYmVyIG9mIHRpbWUgc2xvdHMgbmVlZGVkIHRvDQo+c3VwcG9ydCBhIE9E VWZsZXgoR0ZQKSBzaWduYWwsIHNob3VsZCBiZSBjYXJyaWVkIGFzIGEgY2FsY3VsYXRlZCBJRUVF DQo+ZmxvYXRpbmcgcG9pbnQgbnVtYmVyIG9yIGRpcmVjdGx5LiAgIE9wdGlvbnMgMSBhbmQgMiBi ZWxvdyByZWZsZWN0IHRoZQ0KPmZvcm1lciwgb3B0aW9ucyAzIGFuZCA0IG1hdGNoIHRoZSBsYXR0 ZXIuICBJdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBvbmx5DQo+b3B0aW9ucyAxIGFuZCAyIGFyZSBw cm9wb3NlZCBmb3IgT0RVZmxleChHRlApLCBpLmUuLCBOIG11c3QgYmUNCj5jYWxjdWxhdGVkIGZv ciBPRFVmbGV4KENCUikgc2lnbmFsIHR5cGVzIHdpdGggYWxsIG9wdGlvbnMuDQo+DQo+UGxlYXNl IHN0YXRlIHlvdXIgc3VwcG9ydCBmb3Igb25lIHRoZSBvcHRpb25zIGFuZCwgaWYgeW91IHdpc2gs IHRoZQ0KPmp1c3RpZmljYXRpb24gZm9yIHlvdXIgcG9zaXRpb246DQo+DQo+MSkgRm9sbG93IGRy YWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPiAgIGkuZS4sIHJlZGVm aW5lIFtSRkM0MzI4XSBUcmFmZmljIFBhcmFtZXRlcnMgYy10eXBlIHdoZW4gdXNlZCB3aXRoDQo+ ICAgT1ROLVRETSBsYWJlbHMuIE9EVWZsZXgoR0ZQKSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3Rz IChOKSBpcw0KPiAgIGVuY29kZWQgYXM6DQo+DQo+ICAgLi4uIHRoZSBCaXRfUmF0ZSBmaWVsZCBm b3IgT0RVZmxleChHRlApIE1VU1QNCj4gICBlcXVhbCB0byBvbmUgb2YgdGhlIDgwIHZhbHVlcyBs aXN0ZWQgYmVsb3c6DQo+DQo+ICAgICAgIDEgKiBPRFUyLnRzOyAyICogT0RVMi50czsgLi4uOyA4 ICogT0RVMi50czsNCj4gICAgICAgOSAqIE9EVTMudHM7IDEwICogT0RVMy50cywgLi4uOyAzMiAq IE9EVTMudHM7DQo+ICAgICAgIDMzICogT0RVNC50czsgMzQgKiBPRFU0LnRzOyAuLi47IDgwICog T0RVNC50cy4NCj4NCj4yKSBGb2xsb3cgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmct ZzcwOXYzLTA1DQo+ICAgaS5lLiwgdXNlIGEgbmV3IEMtdHlwZSBmb3IgT1ROLVRETSBsYWJlbHMu ICBFbmNvZGluZyBkZXRhaWxzDQo+ICAgdW5jaGFuZ2VkIGZyb20gZzcwOXYzLTA0Lg0KPiAgIChU aGlzIG9wdGlvbiBhZGRyZXNzZXMgdGhlIGlzc3VlIG9mIHRoZSBzYW1lIGMtdHlwZSBuZWVkaW5n IHRvDQo+ICAgIGJlIHBhcnNlZCBiYXNlZCBvbiBsYWJlbC9zd2l0Y2hpbmcgdHlwZS4pDQo+DQo+ MykgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNg0KPiAg IGkuZS4sICB1c2UgYSBuZXcgQy10eXBlIGZvciBPVE4tVERNIGxhYmVscy4gTiBpcyBkaXJlY3Rs eSBjYXJyaWVkDQo+ICAgZm9yIE9EVWZsZXgoR0ZQKSBvbmx5Lg0KPg0KPjQpIERpc2N1c3NlZCwg YnV0IG5vdCBpbiBhbnkgZHJhZnQNCj4gICBVc2UgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWdu YWxpbmctZzcwOXYzLTA0IGVuY29kaW5nIGZvciBhbGwNCj4gICBidXQgT0RVZmxleChHRlApLCBh bmQgZGVmaW5lIG5ldyBPRFVmbGV4KEdGUCkgc3BlY2lmaWMgVHJhZmZpYw0KPiAgIFBhcmFtZXRl cnMgYmFzZWQgb24gZzcwOXYzLTA2LCBwcmVzdW1hYmx5IHdpdGggdW51c2VkIGZpZWxkcw0KPiAg IHJlbW92ZWQuDQo+ICAgKFRoaXMgYWxzbyBhZGRyZXNzZXMgdGhlIGlzc3VlIG9mIHRoZSBzYW1l IGMtdHlwZSBuZWVkaW5nIHRvIGJlDQo+ICAgIHBhcnNlZCBiYXNlZCBvbiBsYWJlbCB0eXBlLCBi dXQgbWVhbnMgdGhlcmUgYXJlIGRpZmZlcmVudCB0eXBlcw0KPiAgICBiYXNlZCBvbiBzaWduYWwg dHlwZS4pDQo+DQo+T3B0aW9uIDEgYW5kIDIgZG8gbm90IGltcGx5IGFueSBjaGFuZ2VzIHRvIHJv dXRpbmcsIHdoaWxlIG9wdGlvbnMgMyBhbmQNCj40IG1heS4gIFJvdXRpbmcgaW1wbGljYXRpb25z IHdpbGwgYmUgZGlzY3Vzc2VkIGJhc2VkIG9uIHRoZSByZXN1bHRzIG9mDQo+dGhpcyBwb2xsLCBh bmQgb25seSBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdG8gc3VwcG9ydCBwb3NpdGlvbnMgMyBvciA0 Lg0KPg0KPldlIGhvcGUgdG8gbWFrZSBhIGNvbnNlbnN1cyBjYWxsIGJ5IHRoZSBlbmQgb2YgdGhl IHdlZWssIGJ1dCB3aWxsDQo+Y29udGludWUgdGhlIGRpc2N1c3Npb24gYXMgbmVlZGVkLg0KPg0K Pk11Y2ggdGhhbmtzLA0KPkxvdSAoYW5kIERlYm9yYWgpDQo+DQo+T24gMS8yOC8yMDEzIDU6MDgg QU0sIERhbmllbGUgQ2VjY2FyZWxsaSB3cm90ZToNCj4+ICBBbGwsDQo+PiANCj4+IEkgdGhpbmsg dGhlIGNoYW5nZXMgcHJvcG9zZWQgYXJlIG1lYW5pbmdmdWwgYW5kIHdvdWxkIHN1cHBvcnQgdGhl bSBpbg0KPj5hbiBpbmRpdmlkdWFsIG9yIGVhcmx5IFdHIGRyYWZ0LCBidXQgdGhleSBkb24ndCBz ZWVtIHRvIHByb3ZpZGUNCj4+c2lnbmlmaWNhdGl2ZSBhZHZhbnRhZ2VzIHRvIHJpc2sgaW50ZXJ3 b3JraW5nIGlzc3VlcyB3aXRoIGVhcmx5DQo+PmltcGxlbWVudGF0aW9ucy4NCj4+IE1vcmVvdmVy IHRoZSBjaGFuZ2VzIGRvbid0IGFsbG93IHVzIGdldHRpbmcgdG90YWxseSByaWQgb2Ygb2YgdGhl DQo+PmJpdF9yYXRlIGZpZWxkIGFzIGl0IGlzIHN0aWxsIG5lZWRlZCBmb3IgT0RVZmxleCAoQ0JS KS4NCj4+IA0KPj4gTXkgMmMNCj4+IERhbmllbGUNCj4+IA0KPj4gDQo+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBaYWZhciBBbGkgKHphbGkpIFttYWlsdG86emFsaUBj aXNjby5jb21dDQo+Pj4gU2VudDogbHVuZWTDrCAyOCBnZW5uYWlvIDIwMTMgNC40Nw0KPj4+IFRv OiBMb3UgQmVyZ2VyDQo+Pj4gQ2M6IEdydW1hbiwgRnJlZDsgRmF0YWkgWmhhbmc7IERhbmllbGUg Q2VjY2FyZWxsaTsgQ0NBTVA7DQo+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmct ZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBD YWxsIGNvbW1lbnRzIG9uDQo+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcw OXYzLTA0DQo+Pj4NCj4+PiBIaSBMb3UtIA0KPj4+DQo+Pj4gUGxlYXNlIHNlZSBpbi1saW5lLg0K Pj4+DQo+Pj4gVGhhbmtzDQo+Pj4NCj4+PiBSZWdhcmRzLi4uWmFmYXINCj4+Pg0KPj4+IE9uIDEv MjcvMTMgOTo0NiBQTSwgIkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4+ Pg0KPj4+PiBaYWZhciwNCj4+Pj4gCUlzIHlvdXIgY29tbWVudCB3aXRoIHJlc3BlY3QgdG8ganVz dCByb3V0aW5nIG9yIGJvdGgNCj4+PiBzaWduYWxpbmcgYW5kIA0KPj4+PiByb3V0aW5nPw0KPj4+ DQo+Pj4gQm90aCwgaW5jbHVkaW5nIGNvbnNpc3RlbmN5IGJldHdlZW4gc2lnbmFsaW5nIGFuZCBy b3V0aW5nIGF0dHJpYnV0ZXMuDQo+Pj4NCj4+Pj4NCj4+Pj4gQWxzbywgd2hlbiB5b3Ugc2F5ICJp bXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZHJhZnQgdmVyc2lvbnMiLA0KPj4+IGRvIHRoZXNlIA0K Pj4+PiBpbXBsZW1lbnRhdGlvbnMgaW5jbHVkZSBzdXBwb3J0IGZvciBPRFVmbGV4PyAgKFdoaWNo IGhhcyByZWFsbHkgYmVlbg0KPj4+PiB0aGUgZm9jdXMgb2YgdGhlIGRpc2N1c3Npb24uKQ0KPj4+ DQo+Pj4gWWVzLCBJIHdhcyByZWZlcnJpbmcgdG8gT0RVRmxleC4gQXMgeW91IGtub3csIGZpeGVk IE9EVSBpcw0KPj4+IHNpZ25hbGVkIHZpYSBsZXZlbCAoMCBCVykgc28gaXRzIG5vdCBhbiBpc3N1 ZS4NCj4+Pg0KPj4+Pg0KPj4+PiBCVFcgSSB0b29rIEZyZWQncyBjb21tZW50cyBhcyByZWxhdGVk IHRvIGp1c3QgdGhlIG5ldw0KPj4+IE9UTi1zcGVjaWZpYyBJU0NEDQo+Pj4+IGRlZmluaXRpb25z IChzZWN0aW9uIDQuMS4yIG9mIG9zcGYtZzcwOXYzLTA1LCBpbiBwYXJ0aWN1bGFyKS4gIE5vdGUN Cj4+Pj4gdGhhdCBzZWN0aW9uIDQuMS4xIGFscmVhZHkgY2FycmllcyBOIChudW1iZXIgb2YgT0RV cykgbm90DQo+Pj4gSUVFRSBmbG9hdGluZyANCj4+Pj4gcG9pbnQgcmVwcmVzZW50YXRpb25zIG9m IGF2YWlsYWJsZSBiYW5kd2lkdGguDQo+Pj4NCj4+PiBXaGF0IEkgbWVhbnQgaXMgVW5yZXNlcnZl ZCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgeCBhbmQgTWF4IExTUA0KPj4+IEJhbmR3aWR0aCBhdCBw cmlvcml0eSB4Lg0KPj4+DQo+Pj4+DQo+Pj4+IE11Y2ggdGhhbmtzLA0KPj4+PiBMb3UNCj4+Pj4N Cj4+Pj4gT24gMS8yNy8yMDEzIDc6NDYgUE0sIFphZmFyIEFsaSAoemFsaSkgd3JvdGU6DQo+Pj4+ PiBBbGwtDQo+Pj4+Pg0KPj4+Pj4gVGhpcyBpbXBhY3RzIGV4aXN0aW5nIGltcGxlbWVudGF0aW9u cyBiYXNlZCBvbiBkcmFmdCB2ZXJzaW9ucyAoYW5kDQo+Pj4+PiBoZW5jZSBpbnRlcm9wIHdpdGgg dGhlc2UgaW1wbGVtZW50YXRpb25zIG1vdmluZyBmb3J3YXJkKS4NCj4+PiBJTU8gdGhpcyBpcyAN Cj4+Pj4+IGEgYmlnZ2VyIGNoYW5nZSBmb3IgdXMgdG8gYXNzdW1lIGF0IHRoZSBsYXN0IGNhbGwg c3RhZ2UuDQo+Pj4gRnVydGhlcm1vcmUgDQo+Pj4+PiB3ZSBoYXZlIGJlZW4gdXNpbmcgSUVFRSBm bG9hdGluZyBwb2ludCBmb3JtYXQgZm9yIFVucmVzZXJ2ZWQNCj4+Pj4+IEJhbmR3aWR0aC8gTWF4 IExTUCBCVyBpbiBJRUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCBmb3Igb3RoZXINCj4+Pj4+IHRl Y2hub2xvZ2llcy4gT3ZlcmFsbCwgSSB0aGluayB0aGlzIGNoYW5nZSBzdWZmZXJzIGZyb20gdGhl DQo+Pj4gImxhdyBvZiBkaW1pbmlzaGluZyByZXR1cm5zIi4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MN Cj4+Pj4+DQo+Pj4+PiBSZWdhcmRzIMWgIFphZmFyDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9uIDEv MjcvMTMgMTA6MjggQU0sICJHcnVtYW4sIEZyZWQiDQo+Pj4gPGZyZWQuZ3J1bWFuQHVzLmZ1aml0 c3UuY29tPiB3cm90ZToNCj4+Pj4+DQo+Pj4+Pj4gSGkgTG91LCBGYXRhaSwgRGFuaWVsZSwNCj4+ Pj4+Pg0KPj4+Pj4+IEkgdW5kZXJzdGFuZCB0aGUgbGF0ZXN0IGNoYW5nZSB0byB0aGUgd2F5IGJh bmR3aWR0aCBpcw0KPj4+IHNpZ25hbGVkIGZvciAgDQo+Pj4+Pj4gT0RVZmxleChHRlApLCBpLmUu LCBzaWduYWxpbmcgdGhlIG51bWJlciBvZiB0cmlidXRhcnkgc2xvdHMNCj4+PiBOIGluc3RlYWQg DQo+Pj4+Pj4gb2YgIHRoZSBiYW5kd2lkdGggcmF0ZSBpbiBicHMuICBJIGJlbGlldmUgdGhhdCB0 aGlzIHNpbXBsaWZpZXMgdGhlDQo+Pj4+Pj4gc2lnbmFsaW5nICBhbmQgaW50ZXJvcGVyYWJpbGl0 eSBzbyBJJ20gaW4gYWdyZWVtZW50IHdpdGgNCj4+PiB0aGlzIGNoYW5nZS4NCj4+Pj4+Pg0KPj4+ Pj4+IEhvd2V2ZXIsIGl0IHNlZW1zIHdlIGFyZSBub3cgaW5jb25zaXN0ZW50IGJldHdlZW4gaG93 IHdlDQo+Pj4gcmVwcmVzZW50ICANCj4+Pj4+PiBiYW5kd2lkdGggaW4gcm91dGluZyBhbmQgc2ln bmFsaW5nIGZvciBPRFVmbGV4KEdGUCkuICBSb3V0aW5nDQo+Pj4+Pj4gYWR2ZXJ0aXNlcyAgdGhl IGJhbmR3aWR0aCB1c2luZyBhIGZsb2F0aW5nIHBvaW50IHJlcHJlc2VudGF0aW9uIG9mDQo+Pj4+ Pj4gYmFuZHdpZHRoLCB3aGlsZSAgc2lnbmFsaW5nIGlzIHVzaW5nIHRoZSBudW1iZXIgb2YgdHJp YnV0YXJ5IHNsb3RzLg0KPj4+Pj4+IEl0IHNlZW1zIHRoZSBzYW1lICBiZW5lZml0cyB3b3VsZCBi ZSBvYnRhaW5lZCBieQ0KPj4+IGFkdmVydGlzaW5nIHRoZSBtYXgNCj4+Pj4+PiBMU1AgYmFuZHdp ZHRoIGFuZCAgdW5yZXNlcnZlZCBiYW5kd2lkdGggZm9yIE9EVWZsZXgoR0ZQKSBpbg0KPj4+IHRl cm1zIG9mIA0KPj4+Pj4+IHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5ICBzbG90cy4NCj4+Pj4+Pg0K Pj4+Pj4+IEZyZWQNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+Pj4+IEJlaGFsZiBPZiAgTG91IEJlcmdl cg0KPj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMywgMjAxMyA5OjA4IEFNDQo+Pj4+ Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4gQ2M6IENDQU1QOyBkcmFmdC1pZXRmLWNjYW1wLWdt cGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+PiBTdWJqZWN0OiBSZTog W0NDQU1QXSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24NCj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1w LWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4+Pj4+Pg0KPj4+Pj4+IEZhdGFpLA0KPj4+Pj4+ DQo+Pj4+Pj4gT24gMS8yMy8yMDEzIDY6NDkgQU0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4+ PiBIaSBMb3UsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZvciBPRFVmbGV4KENCUiksIHRoZSBmb3JtdWxh IGlzIGZyb20gW0cuNzA5LTIwMTJdIGFuZCBpdA0KPj4+IGhhcyBiZWVuIA0KPj4+Pj4+PiBkaXNj dXNzZWQgYmVmb3JlLCBzbyBwbGVhc2UgdHJ1c3QgdGhhdCB0aGVyZSBpcyBubw0KPj4+IG9wcG9y dHVuaXR5IGZvcg0KPj4+Pj4+PiBtaXNpbnRlcnByZXRhdGlvbi4gKE5vdGUgdGhhdCB0aGVyZSBh cmUgdHdvIGNhc2VzLCBvbmUgaXMNCj4+Pj4+Pj4gT0RVZmxleChDQlIpIGFuZCBhbm90aGVyIG9u ZSBpcyBPRFVmbGV4KEdGUCkpLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJbiBhZGR0aW9uLCBPRFVmbGV4 IGNhbm5vdCBiZSBjb25jYXRlbmF0ZWQgYnkgW0cuNzA5LTIwMTJdLg0KPj4+Pj4+DQo+Pj4+Pj4g VGhhbmtzIGZvciBjb25maXJtaW5nIG15IHVuZGVyc3RhbmRpbmcuICBUaGlzIHJhaXNlcyB0aGUN Cj4+PiBxdWVzdGlvbiBvZiANCj4+Pj4+PiBpZiB0aGUgbmV3IHRyYWZmaWMgc2hvdWxkIGp1c3Qg YXBwbHkgdG8gT0RVRmxleD8gIENvcnJlY3QNCj4+PiBtZSBpZiBJJ20gDQo+Pj4+Pj4gd3Jvbmcs IGJ1dCBJIGJlbGlldmUgdGhlIFtSRkM0MzI4XSBpcyBzdWZmaWNpZW50IGluIGFsbA0KPj4+IG90 aGVyIGNhc2VzLiAgDQo+Pj4+Pj4gVGhpcyBtYXkgYWxzbyBtYWtlIGl0IGVhc2llciBmb3IgZWFy bHkgaW1wbGVtZW50YXRpb25zIG9mDQo+Pj4gdGhlIGRyYWZ0IA0KPj4+Pj4+IGFzIHRoZW4gdGhl eSBjYW4gbGltaXQgY29kZSBjaGFuZ2VzIGZyb20gdGhlICgtMDMpIHJldiB0bw0KPj4+IG9ubHkg T0RVZmxleCBMU1BzLg0KPj4+Pj4+DQo+Pj4+Pj4gSnVzdCB0byBiZSBjbGVhciwgSSdtIHJlYWxs eSBqdXN0ICphc2tpbmcqIGFib3V0IHRoaXMuICBBcyBJIHNhaWQNCj4+Pj4+PiBiZWZvcmUsIEkn bSBvcGVuIG9uIHNwZWNpZmljcy4uLg0KPj4+Pj4+DQo+Pj4+Pj4gQW55IHRob3VnaHRzL2NvbW1l bnRzPyBBdXRob3JzPyAgSW1wbGVtZW50b3JzPw0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzLA0KPj4+ Pj4+IExvdQ0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4gSSB3aWxsIGlzc3VlIGEgbmV3IHZlcnNp b24gdG9tb3Jyb3cgdG8gY2FwdHVyZSBhbGwgeW91ciBjb21tZW50cy4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+ DQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+IEZy b206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPj4+Pj4+PiBTZW50OiBX ZWRuZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgMjoxMSBBTQ0KPj4+Pj4+PiBUbzogRmF0YWkgWmhh bmcNCj4+Pj4+Pj4gQ2M6IENDQU1QOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1n NzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFz dCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFs aW5nLWc3MDl2My0wNA0KPj4+Pj4+Pg0KPj4+Pj4+PiBGYXRhaSwNCj4+Pj4+Pj4NCj4+Pj4+Pj4g T24gMS8yMC8yMDEzIDk6NDMgUE0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4+Pj4gSGkgTG91 LA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFlvdSBzYWlkOg0KPj4+Pj4+Pj4+IGJ1dCB5b3UncmUgc2F5 cyBlbmNvZGVkIGFzIChOKk5vbWluYWwgUmF0ZSkgcmlnaHQ/IFdhdCdzIHRoZQ0KPj4+Pj4+Pj4+ IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBb RmF0YWldIFRoZSBvcmlnaW5hbCB3YXkgKGluIHZlcnNpb24gMDQmMDUpIGlzIHB1dHRpbmcNCj4+ PiAoTiogTm9taW5hbA0KPj4+Pj4+Pj4gUmF0ZSkgaW4gIkJpdF9SYXRlIiBmaWVsZCBmb3IgT0RV ZmxleChHRlApLCB0aGUgdmFsdWUgaXMgdGhhdCB3ZQ0KPj4+Pj4+Pj4gY2FuIGdlbmVyYWxpemUg dG8ganVzdCB1c2Ugb25lIHNpbmdsZSAiQml0X1JhdGUiIGZpZWxkIHRvIGNhcnJ5DQo+Pj4+Pj4+ PiBJRUVFIGZsb2F0IG51bWJlciBmb3IgYm90aCBjYXNlcywgaXQgc2VlbXMgdGhhdCB5b3UNCj4+ PiBkb24ndCBhZ3JlZSBvbiANCj4+Pj4+Pj4+IHRoaXMgdmFsdWUsIDotKQ0KPj4+Pj4+Pg0KPj4+ Pj4+PiBJJ3ZlIHNlZW4gZGlmZmVyZW5jZXMgaW4gY2FsY3VsYXRlZCBmbG9hdGluZyBwb2ludCB2 YWx1ZXMgZnJvbQ0KPj4+Pj4+PiBkaWZmZXJlbnQgIGltcGxlbWVudGF0aW9ucywgc28gSSBqdXN0 IHdhbnQgdG8gZW5zdXJlIHRoYXQNCj4+PiBzdWNoIGNhc2VzIA0KPj4+Pj4+PiBhcmUgYXZvaWRl ZC4NCj4+Pj4+Pj4gSSdtIG9wZW4gdG8gc3BlY2lmaWMgc29sdXRpb25zIGFuZCBjZXJ0YWlubHkg d2lsbCBkZWZmZXIgb24gdGhlDQo+Pj4+Pj4+IHNwZWNpZmljcyBhc3N1bWluZyB0aGVyZSBpcyBu byBvcHBvcnR1bml0eSBmb3INCj4+Pj4+Pj4gbWlzaW50ZXJwcmV0YXRpb24vaW50ZXJvcCAgaXNz dWVzLiBJIGRvbid0IHRoaW5rIHRoZQ0KPj4+IG9yaWdpbmFsIHBhc3NlZA0KPj4+Pj4+PiB0aGlz IHRocmVzaG9sZCwgaS5lLiw6DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgIE4gPSBDZWlsaW5n IG9mDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgIE9EVWZsZXgoQ0JSKSBub21pbmFsIGJpdCByYXRlICog KDEgKyBPRFVmbGV4KENCUikgYml0IHJhdGUNCj4+Pj4+Pj4gdG9sZXJhbmNlKQ0KPj4+Pj4+PiAg ICANCj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+PiAtLS0tLS0tLS0tDQo+Pj4+Pj4+ICAgICAgICBPRFRVay50cyBu b21pbmFsIGJpdCByYXRlICogKDEgLSBITyBPUFVrIGJpdCByYXRlDQo+Pj4gdG9sZXJhbmNlKQ0K Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLiBUaGVyZWZvcmUsIEkgKHdhcykgYW0gc2F5aW5nIHRoYXQgSSBh bSBnb2luZyB0byBhY2NlcHQgeW91cg0KPj4+Pj4+Pj4gc3VnZ2VzdGlvbiB0byBjYXJyeSBOIGZv ciBPRFVmbGV4KEdGUCkuIFdlIGFyZQ0KPj4+IGRpc2N1c3Npbmcgd2hlcmUgdG8NCj4+Pj4+Pj4+ IHB1dCBOIGZvciBPRFVmbGV4KEdGUCkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gWW91 IHNhaWQ6DQo+Pj4+Pj4+Pj4gYml0cyBpbiB0aGUgY29udHJvbCBwbGFuZSBhcmUgZ2VuZXJhbGx5 IGNoZWFwLCBJTU8gaXQncw0KPj4+IGJldHRlciB0byAgDQo+Pj4+Pj4+Pj4gaGF2ZSBzaW1wbGVy IGVuY29kaW5nIHRoYW4gdG8gb3B0aW1pemUgZXZlcnkgYml0IChvciA4IGluIHRoaXMNCj4+Pj4+ Pj4+PiBjYXNlKS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBbRmF0YWldIE9LLCBJIHdpbGwgYWRkIGEg bmV3IGZpZWxkICh0byBvY2N1cHkgdGhlIHJlc2VydmVkIGJpdHMpDQo+Pj4+Pj4+PiB0byBjYXJy eSBOLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBBcyB5b3Ugc2VlIGZpdC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g SnVzdCB0byBjbGFyaWZ5IG15IHVuZGVyc3RhbmRpbmcsIE9EVWZsZXggYW5kIFZpcnR1YWwNCj4+ PiBjb25jYXRlbmF0aW9uIA0KPj4+Pj4+PiBjYW4gIG5ldmVyIGJlIGNvbWJpbmVkIGZvciB0aGUg c2FtZSBzaWduYWwgdHlwZS9sZXZlbCwgcmlnaHQ/DQo+Pj4+Pj4+IChBbHRob3VnaCBhbiAgT0RV ZmxleCBjbGllbnQgc2lnbmFsIGNvdWxkIGJlIGNhcnJpZWQgb3Zlcg0KPj4+IGEgdmlydHVhbCAN Cj4+Pj4+Pj4gY29uY2F0ZW5hdGVkICBPRFVrKS4gIElzIHRoaXMgY29ycmVjdCBvciBkaWQgSSBt aXNzIHNvbWV0aGluZyBpbg0KPj4+Pj4+PiBHNzA5Pw0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGFua3Ms DQo+Pj4+Pj4+IExvdQ0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRmF0YWkNCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4gRnJvbTogTG91IEJl cmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+Pj4+Pj4+PiBTZW50OiBGcmlkYXksIEph bnVhcnkgMTgsIDIwMTMgMTo0MiBBTQ0KPj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4+ PiBDYzogQ0NBTVA7IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29s cy5pZXRmLm9yZw0KPj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIGNv bW1lbnRzIG9uDQo+Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5 djMtMDQNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIDEvMTUvMjAx MyAxMDoxNiBQTSwgRmF0YWkgWmhhbmcgd3JvdGU6DQo+Pj4+Pj4+Pj4gSGkgTG91LA0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4gVG8gYXZvaWQgbWlzdW5kZXJzdGFuZGluZywgSSB3b3VsZCBsaWtlIHRv IGNsYXJpZnkgbW9yZSBvbiB0aGUNCj4+Pj4+Pj4+PiBmb2xsb3dpbmcgcG9pbnQuDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBJdCBpcyBiZXR0ZXIgdG8gaGF2ZSBjb25zaXN0 ZW50IGZvcm1hdCBhbmQgdGhlIHNhbWUgbWVhbmluZw0KPj4+Pj4+Pj4+Pj4+PiBvZiBvbmUNCj4+ Pj4+Pj4+IGZpZWxkIGZvciBib3RoIE9EVWZsZXgoQ0JSKSBhbmQgR0ZQLiBUaGlzIGlzIHdoeSB3 ZSBoYXZlIHNlY3Rpb24NCj4+Pj4+Pj4+IDUuMQ0KPj4+Pj4+Pj4gJjUuMiB0byBkZXNjcmliZSB0 aGUgY29tcGxleCBzdHVmZi4NCj4+Pj4+Pj4+Pj4+PiBJIGFjdHVhbGx5IHdhc24ndCBzdWdnZXN0 aW5nIHRoYXQgTiBiZSBjYXJyaWVkIGluDQo+Pj4gdGhlIGJpdCByYXRlICANCj4+Pj4+Pj4+Pj4+ PiBmaWVsZC4NCj4+Pj4+Pj4+Pj4+PiBUaGUgYml0IHJhdGUgZmllbGQgY2FuIGVpdGhlciBiZSBz ZXQgYXMgZGVzY3JpYmVkIG9yIHRvIHplcm8NCj4+Pj4+Pj4+Pj4+PiAoaS5lLiwgIGlnbm9yZWQp LiAgQXQgdGhlIHRpbWUsIEkgd2FzIHRoaW5raW5nIGFib3V0DQo+Pj4gY2FycnlpbmcgTiANCj4+ Pj4+Pj4+Pj4+PiBpbiB0aGUgIHJlc2VydmVkICBmaWVsZC4gQnV0IHBlcmhhcHMgdGhlIHJpZ2h0 IHBsYWNlDQo+Pj4gaXMgTVQsIGlmIA0KPj4+Pj4+Pj4+Pj4+IG15IHVuZGVyc3RhbmRpbmcgaXMg IHJpZ2h0ICAod291bGQgYWx3YXlzIGJlIDENCj4+PiBvdGhlcndpc2UpLiBJJ20NCj4+Pj4+Pj4+ Pj4+PiBvcGVuIHRvIGVpdGhlci4uLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBbRmF0YWld IFdoeSBub3QganVzdCB1c2UgImJpdCByYXRlImZpZWxkIHRvIGNhcnJ5DQo+Pj4gIk4iYmVjYXVz ZSAiTiINCj4+Pj4+Pj4+Pj4+IGltcGxpZXMgYml0IHJhdGU/ICBJIGFtIE9LIGlmIHlvdSBsaWtl IHRvIHVzZSBhIG5ldw0KPj4+IGZpbGVkIChsaWtlIA0KPj4+Pj4+Pj4+Pj4gIlRTDQo+Pj4+Pj4+ Pj4+PiBOdW1iZXIiKSB0byBvY2N1cHkgdGhlIHJlc2VydmVkIGZpZWxkIGV2ZW4gdGhvdWdoDQo+ Pj4gdGhhdCBJIHByZWZlciANCj4+Pj4+Pj4+Pj4+IHRoZSAgb3JpZ2luYWwgYXBwcm9hY2ggKGll LiwgdXNlICJiaXQgcmF0ZSJmaWVsZCB0byBjYXJyeSAiTiIpLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+PiBBcmUgeW91IHByb3Bvc2luZyBkcm9wcGluZyBjYXJyeWluZyBiaXQgcmF0ZXMNCj4+PiBy ZXByZXNlbnRlZCBhcyBhbg0KPj4+Pj4+Pj4+PiBJRUVFICBmbG9hdGluZyBwb2ludCBhbmQganVz dCBjYXJyeWluZyBOIGZvciBPRFVmbGV4Pw0KPj4+IFRoaXMgc2VlbXMgDQo+Pj4+Pj4+Pj4+IHdv cmthYmxlICB0byAgbWUsIGJ1dCB3ZSBzaG91bGQgZW5zdXJlIHRoYXQgdGhlcmUgYXJlIG5vDQo+ Pj4+Pj4+Pj4+IHNpZ25pZmljYW50IG9iamVjdGlvbnMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBb RmF0YWldIFRoZXJlIGFyZSB0d28gdXNhZ2VzIGZvciAiIEJpdF9SYXRlICIgZmllbGQgYXMNCj4+ PiBkZXNjcmliZWQgDQo+Pj4+Pj4+Pj4gaW4gdGhlIGxpbmVzIDI4Ny0zMTAuDQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+PiAoMSkgICAgRm9yIE9EVWZsZXgoQ0JSKSwgdGhlIEJpdF9SYXRlIGZpZWxkIGlu ZGljYXRlcw0KPj4+IHRoZSBub21pbmFsDQo+Pj4+Pj4+Pj4gYml0DQo+Pj4+Pj4+Pj4gcmF0ZSBv ZiBPRFVmbGV4KENCUikgZXhwcmVzc2VkIGluIGJ5dGVzIHBlciBzZWNvbmQsDQo+Pj4gZW5jb2Rl ZCBhcyBhICANCj4+Pj4+Pj4+PiAzMi1iaXQgIElFRUUgc2luZ2xlIHByZWNpc2lvbiBmbG9hdGlu Zy1wb2ludCBudW1iZXIuIEZvciB0aGlzDQo+Pj4+Pj4+Pj4gY2FzZSwgd2UgTVVTVCAgdXNlICAz Mi1iaXQgSUVFRSBmbG9hdGluZyBwb2ludCBpbnN0ZWFkIG9mDQo+Pj4+Pj4+Pj4gIk4iKFBsZWFz ZSBzZWUgbW9yZSBpbiBzZWN0aW9uICA1LjEpLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEkgZ3Vlc3Mg eW91IHJlYWxseSBzdGlsbCBuZWVkICh0byBiZSBiYXNlZCBvbikgdGhlIGNsaWVudCBzaWduYWwN Cj4+Pj4+Pj4+IHJhdGUgYXQgdGhlIGVkZ2VzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+ICgyKSAgICBGb3IgT0RVZmxleChHRlApLCB3ZSBjYW4gY2hhbmdlIHRoZSB0ZXh0ICh0aGUN Cj4+PiBsaW5lcyBmcm9tIDMwNQ0KPj4+Pj4+Pj4+IHRvDQo+Pj4+Pj4+Pj4gMzEwKSBiYXNlZCBv biB5b3VyIHN1Z2dlc3Rpb24sIGllLiwgdGhlIEJpdF9SYXRlIGZpZWxkDQo+Pj4gaXMgdXNlZCB0 byAgDQo+Pj4+Pj4+Pj4gY2FycnkgICJOInRvIGluZGljYXRlIHRoZSBub21pbmFsIGJpdCByYXRl IG9mIHRoZSAgT0RVZmxleChHRlApLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IGJ1dCB5b3UncmUgc2F5 cyBlbmNvZGVkIGFzIChOKk5vbWluYWwgUmF0ZSkgcmlnaHQ/ICBXYXQncyB0aGUNCj4+Pj4+Pj4+ IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gVGhlcmVmb3JlLCBJIGFtIHByb3Bvc2luZyB1c2luZyBvbmUg c2luZ2xlIGZpbGVkICgiQml0X1JhdGUgIikNCj4+Pj4+Pj4+PiBmb3IgdGhlc2UgdHdvIGNhc2Vz LCBpbiB0aGlzIHdheSwgd2UgY2FuIGxlYXZlIHRoZSAiUmVzZXJ2ZWQiDQo+Pj4+Pj4+Pj4gYml0 cyBmb3IgZnV0dXJlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IGJpdHMgaW4gdGhlIGNvbnRyb2wgcGxh bmUgYXJlIGdlbmVyYWxseSBjaGVhcCwgSU1PIGl0J3MNCj4+PiBiZXR0ZXIgdG8gDQo+Pj4+Pj4+ PiBoYXZlICBzaW1wbGVyIGVuY29kaW5nIHRoYW4gdG8gb3B0aW1pemUgZXZlcnkgYml0IChvciA4 IGluIHRoaXMNCj4+Pj4+Pj4+IGNhc2UpLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IExvdQ0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEhvcGUgd2UgYXJlIG5vdyBhdCB0aGUgc2FtZSBwYWdl Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBCZXN0IFJlZ2FyZHMNCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gQ0NBTVAgbWFpbGlu ZyBsaXN0DQo+Pj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4+ PiBDQ0FNUEBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2NhbXANCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+DQo+Pj4N Cj4+IA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Q0NBTVAgbWFpbGluZyBsaXN0DQo+Q0NBTVBAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg== From fred.gruman@us.fujitsu.com Tue Jan 29 09:54:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9E821F888F for ; Tue, 29 Jan 2013 09:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8, 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 0RwX9Xo9Ezwg for ; Tue, 29 Jan 2013 09:54:34 -0800 (PST) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8021F8868 for ; Tue, 29 Jan 2013 09:54:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,561,1355119200"; d="scan'208";a="26969555" Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 29 Jan 2013 11:54:34 -0600 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.98]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.02.0298.004; Tue, 29 Jan 2013 11:54:33 -0600 From: "Gruman, Fred" To: "Zafar Ali (zali)" , Lou Berger , CCAMP Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZXB3/s+GYEYvka9gmYAFxeuf5hglFOAgAACTfA= Date: Tue, 29 Jan 2013 17:54:33 +0000 Message-ID: <5DF87403A81B0C43AF3EB1626511B2923C33126F@RCHEXMBP1.fnc.net.local> References: <5106DED0.3090008@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19598.001 x-tm-as-result: No--56.353900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:54:36 -0000 SGkgTG91LA0KDQpJIGFtIG5vdCBjbGVhciBvbiBvcHRpb24gMiBhcyB3aGVuIEkgbG9vayBpbnRv IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNSwgdGhlIElBTkEgc2Vj dGlvbiBzaG93cyB0aGUgYy10eXBlIGZvciB0aGUgR0VORVJBTElaRV9MQUJFTCBkZWZpbmVkIGlu IFJGQyAzNDczLCBub3QgYSBuZXcgYy10eXBlLg0KDQpPVE4tVERNIEdlbmVyYWxpemVkIExhYmVs IE9iamVjdDogDQoNCiAgICAgICBvIE9UTi1URE0gR2VuZXJhbGl6ZWQgTGFiZWwgT2JqZWN0OiBD bGFzcyA9IDE2LCBDLVR5cGUgPSAyIChzZWUgDQogICAgICAgICBTZWN0aW9uIDUuMSkgDQoNCkkn bSBvcGVuIHRvIGVpdGhlciBjYXJyeWluZyBPRFVmbGV4KEdGUCkgYmFuZHdpZHRoIGFzIGZsb2F0 aW5nLXBvaW50IG9yIGludGVnZXIgTiwgYnV0IHdvdWxkIGxpa2UgdG8gc2VlIGNvbnNpc3RlbmN5 IGJldHdlZW4gcm91dGluZyBhbmQgc2lnbmFsaW5nIGRvY3VtZW50cy4NCg0KDQpSZWdhcmRzLA0K RnJlZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBaYWZh ciBBbGkgKHphbGkpDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI5LCAyMDEzIDEwOjQxIEFNDQpU bzogTG91IEJlcmdlcjsgQ0NBTVANClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFBvbGwgb24gT0RVRmxl eC1yZWxhdGVkIGVuY29kaW5nICh3YXM6IFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbiBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQpDQoNCkhpIExvdSwgQy1jYW1wZXJz OiANCg0KSSB3b3VsZCBwaWNrIE9wdGlvbiAyOyBpdCdzIGNsZWFuZXIgYW5kICBhZGRyZXNzZXMg dGhlIGlzc3VlIHJlbGF0ZWQgdG8NCm92ZXJsb2FkaW5nIHRoZSBzYW1lIGMtdHlwZS4NCg0KVGhh bmtzDQoNClJlZ2FyZHPigKZaYWZhcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiAibGJlcmdlckBsYWJuLm5ldCIgPGxiZXJnZXJAbGFibi5uZXQ+DQpEYXRlOiBNb25kYXks IEphbnVhcnkgMjgsIDIwMTMgMzoyNSBQTQ0KVG86ICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGll dGYub3JnPg0KU3ViamVjdDogW0NDQU1QXSBQb2xsIG9uIE9EVUZsZXgtcmVsYXRlZCBlbmNvZGlu ZyAod2FzOiBXRyBMYXN0IENhbGwNCmNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt c2lnbmFsaW5nLWc3MDl2My0wNCkNCg0KPkFsbCwNCj4JV2Ugd291bGQgbGlrZSB0byB0cnkgdG8g Y2xvc2UgdGhlIGRpc2N1c3Npb24gb24gdGhlIEcuNzA5DQo+ZHJhZnRzIHNvIHRoYXQgd2UgY2Fu IG1vdmUgcmFwaWRseSB0b3dhcmRzIHB1YmxpY2F0aW9uIHJlcXVlc3QuICBUaGUNCj5kaXNjdXNz aW9uIG9mIChvbmUgb2YgbXkpIExDIGNvbW1lbnRzIGhhcyByZXN1bHRlZCBpbiBzZXZlcmFsIG9w dGlvbnMNCj5mb3IgdGhlIHNpZ25hbGluZyBPRFUtcmVsYXRlZCB0cmFmZmljIHBhcmFtZXRlcnMs IGFuZCB0aGUgcG9pbnQgaGFzDQo+YmVlbiByYWlzZWQgdGhhdCByZWFsaWduaW5nIHJvdXRpbmcg d2l0aCBzaWduYWxpbmcgc2hvdWxkIGJlIGRpc2N1c3NlZC4NCj4NCj5QbGVhc2Uga2VlcCBpbiBt aW5kIHRoYXQgdGhlIG9iamVjdGl2ZSBvZiBhbnkgUFMgaXMgaW50ZXJvcGVyYWJpbGl0eSwNCj5h bmQgdGhhdCB0aGVyZSBtYXkgYmUgZWFybHkgaW1wbGVtZW50YXRpb25zIHRoYXQgbWF0Y2ggZzcw OXYzLTA0Lg0KPg0KPlRoZSBiYXNpYyBxdWVzdGlvbiBpcyBvbmUgb2YgaWYgTiwgdGhlIG51bWJl ciBvZiB0aW1lIHNsb3RzIG5lZWRlZCB0bw0KPnN1cHBvcnQgYSBPRFVmbGV4KEdGUCkgc2lnbmFs LCBzaG91bGQgYmUgY2FycmllZCBhcyBhIGNhbGN1bGF0ZWQgSUVFRQ0KPmZsb2F0aW5nIHBvaW50 IG51bWJlciBvciBkaXJlY3RseS4gICBPcHRpb25zIDEgYW5kIDIgYmVsb3cgcmVmbGVjdCB0aGUN Cj5mb3JtZXIsIG9wdGlvbnMgMyBhbmQgNCBtYXRjaCB0aGUgbGF0dGVyLiAgSXQgaXMgd29ydGgg bm90aW5nIHRoYXQgb25seQ0KPm9wdGlvbnMgMSBhbmQgMiBhcmUgcHJvcG9zZWQgZm9yIE9EVWZs ZXgoR0ZQKSwgaS5lLiwgTiBtdXN0IGJlDQo+Y2FsY3VsYXRlZCBmb3IgT0RVZmxleChDQlIpIHNp Z25hbCB0eXBlcyB3aXRoIGFsbCBvcHRpb25zLg0KPg0KPlBsZWFzZSBzdGF0ZSB5b3VyIHN1cHBv cnQgZm9yIG9uZSB0aGUgb3B0aW9ucyBhbmQsIGlmIHlvdSB3aXNoLCB0aGUNCj5qdXN0aWZpY2F0 aW9uIGZvciB5b3VyIHBvc2l0aW9uOg0KPg0KPjEpIEZvbGxvdyBkcmFmdC1pZXRmLWNjYW1wLWdt cGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4gICBpLmUuLCByZWRlZmluZSBbUkZDNDMyOF0gVHJh ZmZpYyBQYXJhbWV0ZXJzIGMtdHlwZSB3aGVuIHVzZWQgd2l0aA0KPiAgIE9UTi1URE0gbGFiZWxz LiBPRFVmbGV4KEdGUCkgbnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cyAoTikgaXMNCj4gICBlbmNv ZGVkIGFzOg0KPg0KPiAgIC4uLiB0aGUgQml0X1JhdGUgZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSBN VVNUDQo+ICAgZXF1YWwgdG8gb25lIG9mIHRoZSA4MCB2YWx1ZXMgbGlzdGVkIGJlbG93Og0KPg0K PiAgICAgICAxICogT0RVMi50czsgMiAqIE9EVTIudHM7IC4uLjsgOCAqIE9EVTIudHM7DQo+ICAg ICAgIDkgKiBPRFUzLnRzOyAxMCAqIE9EVTMudHMsIC4uLjsgMzIgKiBPRFUzLnRzOw0KPiAgICAg ICAzMyAqIE9EVTQudHM7IDM0ICogT0RVNC50czsgLi4uOyA4MCAqIE9EVTQudHMuDQo+DQo+Mikg Rm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNQ0KPiAgIGku ZS4sIHVzZSBhIG5ldyBDLXR5cGUgZm9yIE9UTi1URE0gbGFiZWxzLiAgRW5jb2RpbmcgZGV0YWls cw0KPiAgIHVuY2hhbmdlZCBmcm9tIGc3MDl2My0wNC4NCj4gICAoVGhpcyBvcHRpb24gYWRkcmVz c2VzIHRoZSBpc3N1ZSBvZiB0aGUgc2FtZSBjLXR5cGUgbmVlZGluZyB0bw0KPiAgICBiZSBwYXJz ZWQgYmFzZWQgb24gbGFiZWwvc3dpdGNoaW5nIHR5cGUuKQ0KPg0KPjMpIEZvbGxvdyBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDYNCj4gICBpLmUuLCAgdXNlIGEgbmV3 IEMtdHlwZSBmb3IgT1ROLVRETSBsYWJlbHMuIE4gaXMgZGlyZWN0bHkgY2FycmllZA0KPiAgIGZv ciBPRFVmbGV4KEdGUCkgb25seS4NCj4NCj40KSBEaXNjdXNzZWQsIGJ1dCBub3QgaW4gYW55IGRy YWZ0DQo+ICAgVXNlIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNCBl bmNvZGluZyBmb3IgYWxsDQo+ICAgYnV0IE9EVWZsZXgoR0ZQKSwgYW5kIGRlZmluZSBuZXcgT0RV ZmxleChHRlApIHNwZWNpZmljIFRyYWZmaWMNCj4gICBQYXJhbWV0ZXJzIGJhc2VkIG9uIGc3MDl2 My0wNiwgcHJlc3VtYWJseSB3aXRoIHVudXNlZCBmaWVsZHMNCj4gICByZW1vdmVkLg0KPiAgIChU aGlzIGFsc28gYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiB0aGUgc2FtZSBjLXR5cGUgbmVlZGluZyB0 byBiZQ0KPiAgICBwYXJzZWQgYmFzZWQgb24gbGFiZWwgdHlwZSwgYnV0IG1lYW5zIHRoZXJlIGFy ZSBkaWZmZXJlbnQgdHlwZXMNCj4gICAgYmFzZWQgb24gc2lnbmFsIHR5cGUuKQ0KPg0KPk9wdGlv biAxIGFuZCAyIGRvIG5vdCBpbXBseSBhbnkgY2hhbmdlcyB0byByb3V0aW5nLCB3aGlsZSBvcHRp b25zIDMgYW5kDQo+NCBtYXkuICBSb3V0aW5nIGltcGxpY2F0aW9ucyB3aWxsIGJlIGRpc2N1c3Nl ZCBiYXNlZCBvbiB0aGUgcmVzdWx0cyBvZg0KPnRoaXMgcG9sbCwgYW5kIG9ubHkgaWYgdGhlcmUg aXMgY29uc2Vuc3VzIHRvIHN1cHBvcnQgcG9zaXRpb25zIDMgb3IgNC4NCj4NCj5XZSBob3BlIHRv IG1ha2UgYSBjb25zZW5zdXMgY2FsbCBieSB0aGUgZW5kIG9mIHRoZSB3ZWVrLCBidXQgd2lsbA0K PmNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFzIG5lZWRlZC4NCj4NCj5NdWNoIHRoYW5rcywNCj5M b3UgKGFuZCBEZWJvcmFoKQ0KPg0KPk9uIDEvMjgvMjAxMyA1OjA4IEFNLCBEYW5pZWxlIENlY2Nh cmVsbGkgd3JvdGU6DQo+PiAgQWxsLA0KPj4gDQo+PiBJIHRoaW5rIHRoZSBjaGFuZ2VzIHByb3Bv c2VkIGFyZSBtZWFuaW5nZnVsIGFuZCB3b3VsZCBzdXBwb3J0IHRoZW0gaW4NCj4+YW4gaW5kaXZp ZHVhbCBvciBlYXJseSBXRyBkcmFmdCwgYnV0IHRoZXkgZG9uJ3Qgc2VlbSB0byBwcm92aWRlDQo+ PnNpZ25pZmljYXRpdmUgYWR2YW50YWdlcyB0byByaXNrIGludGVyd29ya2luZyBpc3N1ZXMgd2l0 aCBlYXJseQ0KPj5pbXBsZW1lbnRhdGlvbnMuDQo+PiBNb3Jlb3ZlciB0aGUgY2hhbmdlcyBkb24n dCBhbGxvdyB1cyBnZXR0aW5nIHRvdGFsbHkgcmlkIG9mIG9mIHRoZQ0KPj5iaXRfcmF0ZSBmaWVs ZCBhcyBpdCBpcyBzdGlsbCBuZWVkZWQgZm9yIE9EVWZsZXggKENCUikuDQo+PiANCj4+IE15IDJj DQo+PiBEYW5pZWxlDQo+PiANCj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pj4gRnJvbTogWmFmYXIgQWxpICh6YWxpKSBbbWFpbHRvOnphbGlAY2lzY28uY29tXQ0KPj4+IFNl bnQ6IGx1bmVkw6wgMjggZ2VubmFpbyAyMDEzIDQuNDcNCj4+PiBUbzogTG91IEJlcmdlcg0KPj4+ IENjOiBHcnVtYW4sIEZyZWQ7IEZhdGFpIFpoYW5nOyBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1Q Ow0KPj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRm Lm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0K Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+DQo+Pj4g SGkgTG91LSANCj4+Pg0KPj4+IFBsZWFzZSBzZWUgaW4tbGluZS4NCj4+Pg0KPj4+IFRoYW5rcw0K Pj4+DQo+Pj4gUmVnYXJkcy4uLlphZmFyDQo+Pj4NCj4+PiBPbiAxLzI3LzEzIDk6NDYgUE0sICJM b3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+Pj4NCj4+Pj4gWmFmYXIsDQo+ Pj4+IAlJcyB5b3VyIGNvbW1lbnQgd2l0aCByZXNwZWN0IHRvIGp1c3Qgcm91dGluZyBvciBib3Ro DQo+Pj4gc2lnbmFsaW5nIGFuZCANCj4+Pj4gcm91dGluZz8NCj4+Pg0KPj4+IEJvdGgsIGluY2x1 ZGluZyBjb25zaXN0ZW5jeSBiZXR3ZWVuIHNpZ25hbGluZyBhbmQgcm91dGluZyBhdHRyaWJ1dGVz Lg0KPj4+DQo+Pj4+DQo+Pj4+IEFsc28sIHdoZW4geW91IHNheSAiaW1wbGVtZW50YXRpb25zIGJh c2VkIG9uIGRyYWZ0IHZlcnNpb25zIiwNCj4+PiBkbyB0aGVzZSANCj4+Pj4gaW1wbGVtZW50YXRp b25zIGluY2x1ZGUgc3VwcG9ydCBmb3IgT0RVZmxleD8gIChXaGljaCBoYXMgcmVhbGx5IGJlZW4N Cj4+Pj4gdGhlIGZvY3VzIG9mIHRoZSBkaXNjdXNzaW9uLikNCj4+Pg0KPj4+IFllcywgSSB3YXMg cmVmZXJyaW5nIHRvIE9EVUZsZXguIEFzIHlvdSBrbm93LCBmaXhlZCBPRFUgaXMNCj4+PiBzaWdu YWxlZCB2aWEgbGV2ZWwgKDAgQlcpIHNvIGl0cyBub3QgYW4gaXNzdWUuDQo+Pj4NCj4+Pj4NCj4+ Pj4gQlRXIEkgdG9vayBGcmVkJ3MgY29tbWVudHMgYXMgcmVsYXRlZCB0byBqdXN0IHRoZSBuZXcN Cj4+PiBPVE4tc3BlY2lmaWMgSVNDRA0KPj4+PiBkZWZpbml0aW9ucyAoc2VjdGlvbiA0LjEuMiBv ZiBvc3BmLWc3MDl2My0wNSwgaW4gcGFydGljdWxhcikuICBOb3RlDQo+Pj4+IHRoYXQgc2VjdGlv biA0LjEuMSBhbHJlYWR5IGNhcnJpZXMgTiAobnVtYmVyIG9mIE9EVXMpIG5vdA0KPj4+IElFRUUg ZmxvYXRpbmcgDQo+Pj4+IHBvaW50IHJlcHJlc2VudGF0aW9ucyBvZiBhdmFpbGFibGUgYmFuZHdp ZHRoLg0KPj4+DQo+Pj4gV2hhdCBJIG1lYW50IGlzIFVucmVzZXJ2ZWQgQmFuZHdpZHRoIGF0IHBy aW9yaXR5IHggYW5kIE1heCBMU1ANCj4+PiBCYW5kd2lkdGggYXQgcHJpb3JpdHkgeC4NCj4+Pg0K Pj4+Pg0KPj4+PiBNdWNoIHRoYW5rcywNCj4+Pj4gTG91DQo+Pj4+DQo+Pj4+IE9uIDEvMjcvMjAx MyA3OjQ2IFBNLCBaYWZhciBBbGkgKHphbGkpIHdyb3RlOg0KPj4+Pj4gQWxsLQ0KPj4+Pj4NCj4+ Pj4+IFRoaXMgaW1wYWN0cyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZHJhZnQg dmVyc2lvbnMgKGFuZA0KPj4+Pj4gaGVuY2UgaW50ZXJvcCB3aXRoIHRoZXNlIGltcGxlbWVudGF0 aW9ucyBtb3ZpbmcgZm9yd2FyZCkuDQo+Pj4gSU1PIHRoaXMgaXMgDQo+Pj4+PiBhIGJpZ2dlciBj aGFuZ2UgZm9yIHVzIHRvIGFzc3VtZSBhdCB0aGUgbGFzdCBjYWxsIHN0YWdlLg0KPj4+IEZ1cnRo ZXJtb3JlIA0KPj4+Pj4gd2UgaGF2ZSBiZWVuIHVzaW5nIElFRUUgZmxvYXRpbmcgcG9pbnQgZm9y bWF0IGZvciBVbnJlc2VydmVkDQo+Pj4+PiBCYW5kd2lkdGgvIE1heCBMU1AgQlcgaW4gSUVFRSBm bG9hdGluZyBwb2ludCBmb3JtYXQgZm9yIG90aGVyDQo+Pj4+PiB0ZWNobm9sb2dpZXMuIE92ZXJh bGwsIEkgdGhpbmsgdGhpcyBjaGFuZ2Ugc3VmZmVycyBmcm9tIHRoZQ0KPj4+ICJsYXcgb2YgZGlt aW5pc2hpbmcgcmV0dXJucyIuDQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzDQo+Pj4+Pg0KPj4+Pj4gUmVn YXJkcyDFoCBaYWZhcg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBPbiAxLzI3LzEzIDEwOjI4IEFNLCAi R3J1bWFuLCBGcmVkIg0KPj4+IDxmcmVkLmdydW1hbkB1cy5mdWppdHN1LmNvbT4gd3JvdGU6DQo+ Pj4+Pg0KPj4+Pj4+IEhpIExvdSwgRmF0YWksIERhbmllbGUsDQo+Pj4+Pj4NCj4+Pj4+PiBJIHVu ZGVyc3RhbmQgdGhlIGxhdGVzdCBjaGFuZ2UgdG8gdGhlIHdheSBiYW5kd2lkdGggaXMNCj4+PiBz aWduYWxlZCBmb3IgIA0KPj4+Pj4+IE9EVWZsZXgoR0ZQKSwgaS5lLiwgc2lnbmFsaW5nIHRoZSBu dW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3RzDQo+Pj4gTiBpbnN0ZWFkIA0KPj4+Pj4+IG9mICB0aGUg YmFuZHdpZHRoIHJhdGUgaW4gYnBzLiAgSSBiZWxpZXZlIHRoYXQgdGhpcyBzaW1wbGlmaWVzIHRo ZQ0KPj4+Pj4+IHNpZ25hbGluZyAgYW5kIGludGVyb3BlcmFiaWxpdHkgc28gSSdtIGluIGFncmVl bWVudCB3aXRoDQo+Pj4gdGhpcyBjaGFuZ2UuDQo+Pj4+Pj4NCj4+Pj4+PiBIb3dldmVyLCBpdCBz ZWVtcyB3ZSBhcmUgbm93IGluY29uc2lzdGVudCBiZXR3ZWVuIGhvdyB3ZQ0KPj4+IHJlcHJlc2Vu dCAgDQo+Pj4+Pj4gYmFuZHdpZHRoIGluIHJvdXRpbmcgYW5kIHNpZ25hbGluZyBmb3IgT0RVZmxl eChHRlApLiAgUm91dGluZw0KPj4+Pj4+IGFkdmVydGlzZXMgIHRoZSBiYW5kd2lkdGggdXNpbmcg YSBmbG9hdGluZyBwb2ludCByZXByZXNlbnRhdGlvbiBvZg0KPj4+Pj4+IGJhbmR3aWR0aCwgd2hp bGUgIHNpZ25hbGluZyBpcyB1c2luZyB0aGUgbnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cy4NCj4+ Pj4+PiBJdCBzZWVtcyB0aGUgc2FtZSAgYmVuZWZpdHMgd291bGQgYmUgb2J0YWluZWQgYnkNCj4+ PiBhZHZlcnRpc2luZyB0aGUgbWF4DQo+Pj4+Pj4gTFNQIGJhbmR3aWR0aCBhbmQgIHVucmVzZXJ2 ZWQgYmFuZHdpZHRoIGZvciBPRFVmbGV4KEdGUCkgaW4NCj4+PiB0ZXJtcyBvZiANCj4+Pj4+PiB0 aGUgbnVtYmVyIG9mIHRyaWJ1dGFyeSAgc2xvdHMuDQo+Pj4+Pj4NCj4+Pj4+PiBGcmVkDQo+Pj4+ Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0Bp ZXRmLm9yZ10gT24NCj4+Pj4+PiBCZWhhbGYgT2YgIExvdSBCZXJnZXINCj4+Pj4+PiBTZW50OiBX ZWRuZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgOTowOCBBTQ0KPj4+Pj4+IFRvOiBGYXRhaSBaaGFu Zw0KPj4+Pj4+IENjOiBDQ0FNUDsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcw OXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBD YWxsIGNvbW1lbnRzIG9uDQo+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmct ZzcwOXYzLTA0DQo+Pj4+Pj4NCj4+Pj4+PiBGYXRhaSwNCj4+Pj4+Pg0KPj4+Pj4+IE9uIDEvMjMv MjAxMyA2OjQ5IEFNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+Pj4gSGkgTG91LA0KPj4+Pj4+ Pg0KPj4+Pj4+PiBGb3IgT0RVZmxleChDQlIpLCB0aGUgZm9ybXVsYSBpcyBmcm9tIFtHLjcwOS0y MDEyXSBhbmQgaXQNCj4+PiBoYXMgYmVlbiANCj4+Pj4+Pj4gZGlzY3Vzc2VkIGJlZm9yZSwgc28g cGxlYXNlIHRydXN0IHRoYXQgdGhlcmUgaXMgbm8NCj4+PiBvcHBvcnR1bml0eSBmb3INCj4+Pj4+ Pj4gbWlzaW50ZXJwcmV0YXRpb24uIChOb3RlIHRoYXQgdGhlcmUgYXJlIHR3byBjYXNlcywgb25l IGlzDQo+Pj4+Pj4+IE9EVWZsZXgoQ0JSKSBhbmQgYW5vdGhlciBvbmUgaXMgT0RVZmxleChHRlAp KS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSW4gYWRkdGlvbiwgT0RVZmxleCBjYW5ub3QgYmUgY29uY2F0 ZW5hdGVkIGJ5IFtHLjcwOS0yMDEyXS4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcyBmb3IgY29uZmly bWluZyBteSB1bmRlcnN0YW5kaW5nLiAgVGhpcyByYWlzZXMgdGhlDQo+Pj4gcXVlc3Rpb24gb2Yg DQo+Pj4+Pj4gaWYgdGhlIG5ldyB0cmFmZmljIHNob3VsZCBqdXN0IGFwcGx5IHRvIE9EVUZsZXg/ ICBDb3JyZWN0DQo+Pj4gbWUgaWYgSSdtIA0KPj4+Pj4+IHdyb25nLCBidXQgSSBiZWxpZXZlIHRo ZSBbUkZDNDMyOF0gaXMgc3VmZmljaWVudCBpbiBhbGwNCj4+PiBvdGhlciBjYXNlcy4gIA0KPj4+ Pj4+IFRoaXMgbWF5IGFsc28gbWFrZSBpdCBlYXNpZXIgZm9yIGVhcmx5IGltcGxlbWVudGF0aW9u cyBvZg0KPj4+IHRoZSBkcmFmdCANCj4+Pj4+PiBhcyB0aGVuIHRoZXkgY2FuIGxpbWl0IGNvZGUg Y2hhbmdlcyBmcm9tIHRoZSAoLTAzKSByZXYgdG8NCj4+PiBvbmx5IE9EVWZsZXggTFNQcy4NCj4+ Pj4+Pg0KPj4+Pj4+IEp1c3QgdG8gYmUgY2xlYXIsIEknbSByZWFsbHkganVzdCAqYXNraW5nKiBh Ym91dCB0aGlzLiAgQXMgSSBzYWlkDQo+Pj4+Pj4gYmVmb3JlLCBJJ20gb3BlbiBvbiBzcGVjaWZp Y3MuLi4NCj4+Pj4+Pg0KPj4+Pj4+IEFueSB0aG91Z2h0cy9jb21tZW50cz8gQXV0aG9ycz8gIElt cGxlbWVudG9ycz8NCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcywNCj4+Pj4+PiBMb3UNCj4+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pj4+IEkgd2lsbCBpc3N1ZSBhIG5ldyB2ZXJzaW9uIHRvbW9ycm93IHRvIGNh cHR1cmUgYWxsIHlvdXIgY29tbWVudHMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJlc3Qg UmVnYXJkcw0KPj4+Pj4+Pg0KPj4+Pj4+PiBGYXRhaQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFtt YWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4+Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5 IDIzLCAyMDEzIDI6MTEgQU0NCj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4+IENjOiBD Q0FNUDsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYu b3JnDQo+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBv bg0KPj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4+ Pj4+Pj4NCj4+Pj4+Pj4gRmF0YWksDQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uIDEvMjAvMjAxMyA5OjQz IFBNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiBZb3Ugc2FpZDoNCj4+Pj4+Pj4+PiBidXQgeW91J3JlIHNheXMgZW5jb2RlZCBhcyAoTipO b21pbmFsIFJhdGUpIHJpZ2h0PyBXYXQncyB0aGUNCj4+Pj4+Pj4+PiB2YWx1ZSBvZiAgdGhpcyB2 cyBqdXN0IGNhcnJ5aW5nIE4/DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gW0ZhdGFpXSBUaGUgb3JpZ2lu YWwgd2F5IChpbiB2ZXJzaW9uIDA0JjA1KSBpcyBwdXR0aW5nDQo+Pj4gKE4qIE5vbWluYWwNCj4+ Pj4+Pj4+IFJhdGUpIGluICJCaXRfUmF0ZSIgZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSwgdGhlIHZh bHVlIGlzIHRoYXQgd2UNCj4+Pj4+Pj4+IGNhbiBnZW5lcmFsaXplIHRvIGp1c3QgdXNlIG9uZSBz aW5nbGUgIkJpdF9SYXRlIiBmaWVsZCB0byBjYXJyeQ0KPj4+Pj4+Pj4gSUVFRSBmbG9hdCBudW1i ZXIgZm9yIGJvdGggY2FzZXMsIGl0IHNlZW1zIHRoYXQgeW91DQo+Pj4gZG9uJ3QgYWdyZWUgb24g DQo+Pj4+Pj4+PiB0aGlzIHZhbHVlLCA6LSkNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSSd2ZSBzZWVuIGRp ZmZlcmVuY2VzIGluIGNhbGN1bGF0ZWQgZmxvYXRpbmcgcG9pbnQgdmFsdWVzIGZyb20NCj4+Pj4+ Pj4gZGlmZmVyZW50ICBpbXBsZW1lbnRhdGlvbnMsIHNvIEkganVzdCB3YW50IHRvIGVuc3VyZSB0 aGF0DQo+Pj4gc3VjaCBjYXNlcyANCj4+Pj4+Pj4gYXJlIGF2b2lkZWQuDQo+Pj4+Pj4+IEknbSBv cGVuIHRvIHNwZWNpZmljIHNvbHV0aW9ucyBhbmQgY2VydGFpbmx5IHdpbGwgZGVmZmVyIG9uIHRo ZQ0KPj4+Pj4+PiBzcGVjaWZpY3MgYXNzdW1pbmcgdGhlcmUgaXMgbm8gb3Bwb3J0dW5pdHkgZm9y DQo+Pj4+Pj4+IG1pc2ludGVycHJldGF0aW9uL2ludGVyb3AgIGlzc3Vlcy4gSSBkb24ndCB0aGlu ayB0aGUNCj4+PiBvcmlnaW5hbCBwYXNzZWQNCj4+Pj4+Pj4gdGhpcyB0aHJlc2hvbGQsIGkuZS4s Og0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICBOID0gQ2VpbGluZyBvZg0KPj4+Pj4+Pg0KPj4+ Pj4+PiAgICBPRFVmbGV4KENCUikgbm9taW5hbCBiaXQgcmF0ZSAqICgxICsgT0RVZmxleChDQlIp IGJpdCByYXRlDQo+Pj4+Pj4+IHRvbGVyYW5jZSkNCj4+Pj4+Pj4gICAgDQo+Pj4+Pj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pj4gLS0tLS0tLS0tLQ0KPj4+Pj4+PiAgICAgICAgT0RUVWsudHMgbm9taW5hbCBiaXQgcmF0ZSAq ICgxIC0gSE8gT1BVayBiaXQgcmF0ZQ0KPj4+IHRvbGVyYW5jZSkNCj4+Pj4+Pj4NCj4+Pj4+Pj4+ IC4gVGhlcmVmb3JlLCBJICh3YXMpIGFtIHNheWluZyB0aGF0IEkgYW0gZ29pbmcgdG8gYWNjZXB0 IHlvdXINCj4+Pj4+Pj4+IHN1Z2dlc3Rpb24gdG8gY2FycnkgTiBmb3IgT0RVZmxleChHRlApLiBX ZSBhcmUNCj4+PiBkaXNjdXNzaW5nIHdoZXJlIHRvDQo+Pj4+Pj4+PiBwdXQgTiBmb3IgT0RVZmxl eChHRlApLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+IFlvdSBzYWlkOg0KPj4+Pj4+Pj4+ IGJpdHMgaW4gdGhlIGNvbnRyb2wgcGxhbmUgYXJlIGdlbmVyYWxseSBjaGVhcCwgSU1PIGl0J3MN Cj4+PiBiZXR0ZXIgdG8gIA0KPj4+Pj4+Pj4+IGhhdmUgc2ltcGxlciBlbmNvZGluZyB0aGFuIHRv IG9wdGltaXplIGV2ZXJ5IGJpdCAob3IgOCBpbiB0aGlzDQo+Pj4+Pj4+Pj4gY2FzZSkuDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gW0ZhdGFpXSBPSywgSSB3aWxsIGFkZCBhIG5ldyBmaWVsZCAodG8gb2Nj dXB5IHRoZSByZXNlcnZlZCBiaXRzKQ0KPj4+Pj4+Pj4gdG8gY2FycnkgTi4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gQXMgeW91IHNlZSBmaXQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEp1c3QgdG8gY2xhcmlmeSBt eSB1bmRlcnN0YW5kaW5nLCBPRFVmbGV4IGFuZCBWaXJ0dWFsDQo+Pj4gY29uY2F0ZW5hdGlvbiAN Cj4+Pj4+Pj4gY2FuICBuZXZlciBiZSBjb21iaW5lZCBmb3IgdGhlIHNhbWUgc2lnbmFsIHR5cGUv bGV2ZWwsIHJpZ2h0Pw0KPj4+Pj4+PiAoQWx0aG91Z2ggYW4gIE9EVWZsZXggY2xpZW50IHNpZ25h bCBjb3VsZCBiZSBjYXJyaWVkIG92ZXINCj4+PiBhIHZpcnR1YWwgDQo+Pj4+Pj4+IGNvbmNhdGVu YXRlZCAgT0RVaykuICBJcyB0aGlzIGNvcnJlY3Qgb3IgZGlkIEkgbWlzcyBzb21ldGhpbmcgaW4N Cj4+Pj4+Pj4gRzcwOT8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+PiBMb3UNCj4+ Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEJlc3QgUmVnYXJk cw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVy Z2VyQGxhYm4ubmV0XQ0KPj4+Pj4+Pj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDE4LCAyMDEzIDE6 NDIgQU0NCj4+Pj4+Pj4+IFRvOiBGYXRhaSBaaGFuZw0KPj4+Pj4+Pj4gQ2M6IENDQU1QOyBkcmFm dC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+ Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+ Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBPbiAxLzE1LzIwMTMgMTA6MTYgUE0sIEZhdGFp IFpoYW5nIHdyb3RlOg0KPj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRv IGF2b2lkIG1pc3VuZGVyc3RhbmRpbmcsIEkgd291bGQgbGlrZSB0byBjbGFyaWZ5IG1vcmUgb24g dGhlDQo+Pj4+Pj4+Pj4gZm9sbG93aW5nIHBvaW50Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4gSXQgaXMgYmV0dGVyIHRvIGhhdmUgY29uc2lzdGVudCBmb3JtYXQgYW5kIHRo ZSBzYW1lIG1lYW5pbmcNCj4+Pj4+Pj4+Pj4+Pj4gb2Ygb25lDQo+Pj4+Pj4+PiBmaWVsZCBmb3Ig Ym90aCBPRFVmbGV4KENCUikgYW5kIEdGUC4gVGhpcyBpcyB3aHkgd2UgaGF2ZSBzZWN0aW9uDQo+ Pj4+Pj4+PiA1LjENCj4+Pj4+Pj4+ICY1LjIgdG8gZGVzY3JpYmUgdGhlIGNvbXBsZXggc3R1ZmYu DQo+Pj4+Pj4+Pj4+Pj4gSSBhY3R1YWxseSB3YXNuJ3Qgc3VnZ2VzdGluZyB0aGF0IE4gYmUgY2Fy cmllZCBpbg0KPj4+IHRoZSBiaXQgcmF0ZSAgDQo+Pj4+Pj4+Pj4+Pj4gZmllbGQuDQo+Pj4+Pj4+ Pj4+Pj4gVGhlIGJpdCByYXRlIGZpZWxkIGNhbiBlaXRoZXIgYmUgc2V0IGFzIGRlc2NyaWJlZCBv ciB0byB6ZXJvDQo+Pj4+Pj4+Pj4+Pj4gKGkuZS4sICBpZ25vcmVkKS4gIEF0IHRoZSB0aW1lLCBJ IHdhcyB0aGlua2luZyBhYm91dA0KPj4+IGNhcnJ5aW5nIE4gDQo+Pj4+Pj4+Pj4+Pj4gaW4gdGhl ICByZXNlcnZlZCAgZmllbGQuIEJ1dCBwZXJoYXBzIHRoZSByaWdodCBwbGFjZQ0KPj4+IGlzIE1U LCBpZiANCj4+Pj4+Pj4+Pj4+PiBteSB1bmRlcnN0YW5kaW5nIGlzICByaWdodCAgKHdvdWxkIGFs d2F5cyBiZSAxDQo+Pj4gb3RoZXJ3aXNlKS4gSSdtDQo+Pj4+Pj4+Pj4+Pj4gb3BlbiB0byBlaXRo ZXIuLi4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gW0ZhdGFpXSBXaHkgbm90IGp1c3QgdXNl ICJiaXQgcmF0ZSJmaWVsZCB0byBjYXJyeQ0KPj4+ICJOImJlY2F1c2UgIk4iDQo+Pj4+Pj4+Pj4+ PiBpbXBsaWVzIGJpdCByYXRlPyAgSSBhbSBPSyBpZiB5b3UgbGlrZSB0byB1c2UgYSBuZXcNCj4+ PiBmaWxlZCAobGlrZSANCj4+Pj4+Pj4+Pj4+ICJUUw0KPj4+Pj4+Pj4+Pj4gTnVtYmVyIikgdG8g b2NjdXB5IHRoZSByZXNlcnZlZCBmaWVsZCBldmVuIHRob3VnaA0KPj4+IHRoYXQgSSBwcmVmZXIg DQo+Pj4+Pj4+Pj4+PiB0aGUgIG9yaWdpbmFsIGFwcHJvYWNoIChpZS4sIHVzZSAiYml0IHJhdGUi ZmllbGQgdG8gY2FycnkgIk4iKS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gQXJlIHlvdSBwcm9w b3NpbmcgZHJvcHBpbmcgY2FycnlpbmcgYml0IHJhdGVzDQo+Pj4gcmVwcmVzZW50ZWQgYXMgYW4N Cj4+Pj4+Pj4+Pj4gSUVFRSAgZmxvYXRpbmcgcG9pbnQgYW5kIGp1c3QgY2FycnlpbmcgTiBmb3Ig T0RVZmxleD8NCj4+PiBUaGlzIHNlZW1zIA0KPj4+Pj4+Pj4+PiB3b3JrYWJsZSAgdG8gIG1lLCBi dXQgd2Ugc2hvdWxkIGVuc3VyZSB0aGF0IHRoZXJlIGFyZSBubw0KPj4+Pj4+Pj4+PiBzaWduaWZp Y2FudCBvYmplY3Rpb25zLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gW0ZhdGFpXSBUaGVyZSBhcmUg dHdvIHVzYWdlcyBmb3IgIiBCaXRfUmF0ZSAiIGZpZWxkIGFzDQo+Pj4gZGVzY3JpYmVkIA0KPj4+ Pj4+Pj4+IGluIHRoZSBsaW5lcyAyODctMzEwLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gKDEpICAg IEZvciBPRFVmbGV4KENCUiksIHRoZSBCaXRfUmF0ZSBmaWVsZCBpbmRpY2F0ZXMNCj4+PiB0aGUg bm9taW5hbA0KPj4+Pj4+Pj4+IGJpdA0KPj4+Pj4+Pj4+IHJhdGUgb2YgT0RVZmxleChDQlIpIGV4 cHJlc3NlZCBpbiBieXRlcyBwZXIgc2Vjb25kLA0KPj4+IGVuY29kZWQgYXMgYSAgDQo+Pj4+Pj4+ Pj4gMzItYml0ICBJRUVFIHNpbmdsZSBwcmVjaXNpb24gZmxvYXRpbmctcG9pbnQgbnVtYmVyLiBG b3IgdGhpcw0KPj4+Pj4+Pj4+IGNhc2UsIHdlIE1VU1QgIHVzZSAgMzItYml0IElFRUUgZmxvYXRp bmcgcG9pbnQgaW5zdGVhZCBvZg0KPj4+Pj4+Pj4+ICJOIihQbGVhc2Ugc2VlIG1vcmUgaW4gc2Vj dGlvbiAgNS4xKS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJIGd1ZXNzIHlvdSByZWFsbHkgc3RpbGwg bmVlZCAodG8gYmUgYmFzZWQgb24pIHRoZSBjbGllbnQgc2lnbmFsDQo+Pj4+Pj4+PiByYXRlIGF0 IHRoZSBlZGdlcy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAoMikgICAgRm9yIE9E VWZsZXgoR0ZQKSwgd2UgY2FuIGNoYW5nZSB0aGUgdGV4dCAodGhlDQo+Pj4gbGluZXMgZnJvbSAz MDUNCj4+Pj4+Pj4+PiB0bw0KPj4+Pj4+Pj4+IDMxMCkgYmFzZWQgb24geW91ciBzdWdnZXN0aW9u LCBpZS4sIHRoZSBCaXRfUmF0ZSBmaWVsZA0KPj4+IGlzIHVzZWQgdG8gIA0KPj4+Pj4+Pj4+IGNh cnJ5ICAiTiJ0byBpbmRpY2F0ZSB0aGUgbm9taW5hbCBiaXQgcmF0ZSBvZiB0aGUgIE9EVWZsZXgo R0ZQKS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBidXQgeW91J3JlIHNheXMgZW5jb2RlZCBhcyAoTipO b21pbmFsIFJhdGUpIHJpZ2h0PyAgV2F0J3MgdGhlDQo+Pj4+Pj4+PiB2YWx1ZSBvZiAgdGhpcyB2 cyBqdXN0IGNhcnJ5aW5nIE4/DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+IFRoZXJlZm9yZSwgSSBhbSBwcm9wb3NpbmcgdXNpbmcgb25lIHNpbmdsZSBmaWxlZCAoIkJp dF9SYXRlICIpDQo+Pj4+Pj4+Pj4gZm9yIHRoZXNlIHR3byBjYXNlcywgaW4gdGhpcyB3YXksIHdl IGNhbiBsZWF2ZSB0aGUgIlJlc2VydmVkIg0KPj4+Pj4+Pj4+IGJpdHMgZm9yIGZ1dHVyZS4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBiaXRzIGluIHRoZSBjb250cm9sIHBsYW5lIGFyZSBnZW5lcmFsbHkg Y2hlYXAsIElNTyBpdCdzDQo+Pj4gYmV0dGVyIHRvIA0KPj4+Pj4+Pj4gaGF2ZSAgc2ltcGxlciBl bmNvZGluZyB0aGFuIHRvIG9wdGltaXplIGV2ZXJ5IGJpdCAob3IgOCBpbiB0aGlzDQo+Pj4+Pj4+ PiBjYXNlKS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBMb3UNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+PiBIb3BlIHdlIGFyZSBub3cgYXQgdGhlIHNhbWUgcGFnZS4NCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBGYXRh aQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+Pj4+IEND QU1QQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gQ0NBTVBAaWV0Zi5vcmcN Cj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pg0KPj4+DQo+PiANCj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkNDQU1QIG1haWxpbmcgbGlz dA0KPkNDQU1QQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0K From daniele.ceccarelli@ericsson.com Tue Jan 29 10:31:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A68421F8AB7 for ; Tue, 29 Jan 2013 10:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 lTrOOcMBWFlf for ; Tue, 29 Jan 2013 10:31:50 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BEE1C21F8AA0 for ; Tue, 29 Jan 2013 10:31:49 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-a7-510815945f0b Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B2.1D.32353.49518015; Tue, 29 Jan 2013 19:31:48 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 19:31:48 +0100 From: Daniele Ceccarelli To: "Zafar Ali (zali)" , Lou Berger , CCAMP Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZXHtjks61frnEil2tqgrQxB9Zhgcs6AgAAo+jA= Date: Tue, 29 Jan 2013 18:31:47 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48074CE1@ESESSMB301.ericsson.se> References: <5106DED0.3090008@labn.net> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre4UUY5Ag9ZLOhZP5txgsehofsti 8XrHV3YHZo8pvzeyeixZ8pPJ48OmZrYA5igum5TUnMyy1CJ9uwSujOXfTzMXLNnAWHF8+1rW BsYHqxm7GDk5JARMJFrv/WWGsMUkLtxbz9bFyMUhJHCIUaJ32hkoZzGjxPxVj1m7GDk42ASs JJ4c8gFpEBFIkLi0/C0LSI2wQBOjxIKPV5lAHBGBZkaJXRt/MUJUWUkcm76GDcRmEVCVmLTn PjuIzSvgLfFty0Sw1UICGRK37zUxgdicIPH3l8B6GQVkJSbsXgRmMwuIS9x6Mp8J4lQBiSV7 zkOdLSrx8vE/sOMkBBQllvfLgZjMApoS63fpQ3QqSkzpfgi1VVDi5MwnLBMYRWchGToLoWMW ko5ZSDoWMLKsYmTPTczMSS8338QIjJCDW34b7GDcdF/sEKM0B4uSOG+464UAIYH0xJLU7NTU gtSi+KLSnNTiQ4xMHJxSDYx6bsv7vL1FN6/nfOfRFTBZqXH92tcrnRQ2f2855Ogz6XQhzyYx tj8bnhWK9L7hVc0Ot1IW9zzT94TvW2WsZFjYacX7G13kn9kJphinGf+UPKKscnbyUcbsZ/eL tDeavZh/4reBUs6719ZNqcItf9cpJ+xesYJVoY47Oubc0tuTI1QYIzUaqpVYijMSDbWYi4oT AaQ+Fi1eAgAA Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:31:52 -0000 T3B0aW9uIDIgZm9yIG1lIHRvby4NCg0KTWFpbiByZWFzb24/IEkgZG9uJ3QgaGF2ZSB0byBjaGFu Z2UgdGhlIHJvdXRpbmcgSUQhIDotKSAuLi5vYnZpb3VzbHkgam9raW5nLg0KDQpPdGhlciByZWFz b25zPyBBZ3JlZSB3aXRoIEZhdGFpIGFuZCBaYWZhci4gQW5kIHByZWZlciAyKSB0byAxKSBiZWNh dXNlIGRlZmluZXMgYSBuZXcgQy10eXBlLg0KDQpCUg0KRGFuaWVsZSANCg0KPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNj YW1wLWJvdW5jZXNAaWV0Zi5vcmddIA0KPk9uIEJlaGFsZiBPZiBaYWZhciBBbGkgKHphbGkpDQo+ U2VudDogbWFydGVkw6wgMjkgZ2VubmFpbyAyMDEzIDE3LjQxDQo+VG86IExvdSBCZXJnZXI7IEND QU1QDQo+U3ViamVjdDogUmU6IFtDQ0FNUF0gUG9sbCBvbiBPRFVGbGV4LXJlbGF0ZWQgZW5jb2Rp bmcgKHdhczogV0cgDQo+TGFzdCBDYWxsIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtc2lnbmFsaW5nLWc3MDl2My0wNCkNCj4NCj5IaSBMb3UsIEMtY2FtcGVyczogDQo+DQo+SSB3 b3VsZCBwaWNrIE9wdGlvbiAyOyBpdCdzIGNsZWFuZXIgYW5kICBhZGRyZXNzZXMgdGhlIGlzc3Vl IA0KPnJlbGF0ZWQgdG8gb3ZlcmxvYWRpbmcgdGhlIHNhbWUgYy10eXBlLg0KPg0KPlRoYW5rcw0K Pg0KPlJlZ2FyZHPigKZaYWZhcg0KPg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogImxiZXJnZXJAbGFibi5uZXQiIDxsYmVyZ2VyQGxhYm4ubmV0Pg0KPkRhdGU6IE1vbmRh eSwgSmFudWFyeSAyOCwgMjAxMyAzOjI1IFBNDQo+VG86ICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1w QGlldGYub3JnPg0KPlN1YmplY3Q6IFtDQ0FNUF0gUG9sbCBvbiBPRFVGbGV4LXJlbGF0ZWQgZW5j b2RpbmcgKHdhczogV0cgDQo+TGFzdCBDYWxsIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY2NhbXAt Z21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNCkNCj4NCj4+QWxsLA0KPj4JV2Ugd291bGQgbGlrZSB0 byB0cnkgdG8gY2xvc2UgdGhlIGRpc2N1c3Npb24gb24gdGhlIA0KPkcuNzA5IGRyYWZ0cyBzbyAN Cj4+dGhhdCB3ZSBjYW4gbW92ZSByYXBpZGx5IHRvd2FyZHMgcHVibGljYXRpb24gcmVxdWVzdC4g IFRoZSBkaXNjdXNzaW9uIA0KPj5vZiAob25lIG9mIG15KSBMQyBjb21tZW50cyBoYXMgcmVzdWx0 ZWQgaW4gc2V2ZXJhbCBvcHRpb25zIGZvciB0aGUgDQo+PnNpZ25hbGluZyBPRFUtcmVsYXRlZCB0 cmFmZmljIHBhcmFtZXRlcnMsIGFuZCB0aGUgcG9pbnQgaGFzIA0KPmJlZW4gcmFpc2VkIA0KPj50 aGF0IHJlYWxpZ25pbmcgcm91dGluZyB3aXRoIHNpZ25hbGluZyBzaG91bGQgYmUgZGlzY3Vzc2Vk Lg0KPj4NCj4+UGxlYXNlIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBvYmplY3RpdmUgb2YgYW55IFBT IGlzIGludGVyb3BlcmFiaWxpdHksIA0KPj5hbmQgdGhhdCB0aGVyZSBtYXkgYmUgZWFybHkgaW1w bGVtZW50YXRpb25zIHRoYXQgbWF0Y2ggZzcwOXYzLTA0Lg0KPj4NCj4+VGhlIGJhc2ljIHF1ZXN0 aW9uIGlzIG9uZSBvZiBpZiBOLCB0aGUgbnVtYmVyIG9mIHRpbWUgc2xvdHMgbmVlZGVkIHRvIA0K Pj5zdXBwb3J0IGEgT0RVZmxleChHRlApIHNpZ25hbCwgc2hvdWxkIGJlIGNhcnJpZWQgYXMgYSBj YWxjdWxhdGVkIElFRUUNCj4+ZmxvYXRpbmcgcG9pbnQgbnVtYmVyIG9yIGRpcmVjdGx5LiAgIE9w dGlvbnMgMSBhbmQgMiBiZWxvdyByZWZsZWN0IHRoZQ0KPj5mb3JtZXIsIG9wdGlvbnMgMyBhbmQg NCBtYXRjaCB0aGUgbGF0dGVyLiAgSXQgaXMgd29ydGggbm90aW5nIA0KPnRoYXQgb25seSANCj4+ b3B0aW9ucyAxIGFuZCAyIGFyZSBwcm9wb3NlZCBmb3IgT0RVZmxleChHRlApLCBpLmUuLCBOIG11 c3QgYmUgDQo+PmNhbGN1bGF0ZWQgZm9yIE9EVWZsZXgoQ0JSKSBzaWduYWwgdHlwZXMgd2l0aCBh bGwgb3B0aW9ucy4NCj4+DQo+PlBsZWFzZSBzdGF0ZSB5b3VyIHN1cHBvcnQgZm9yIG9uZSB0aGUg b3B0aW9ucyBhbmQsIGlmIHlvdSB3aXNoLCB0aGUgDQo+Pmp1c3RpZmljYXRpb24gZm9yIHlvdXIg cG9zaXRpb246DQo+Pg0KPj4xKSBGb2xsb3cgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxp bmctZzcwOXYzLTA0DQo+PiAgIGkuZS4sIHJlZGVmaW5lIFtSRkM0MzI4XSBUcmFmZmljIFBhcmFt ZXRlcnMgYy10eXBlIHdoZW4gdXNlZCB3aXRoDQo+PiAgIE9UTi1URE0gbGFiZWxzLiBPRFVmbGV4 KEdGUCkgbnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cyAoTikgaXMNCj4+ICAgZW5jb2RlZCBhczoN Cj4+DQo+PiAgIC4uLiB0aGUgQml0X1JhdGUgZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSBNVVNUDQo+ PiAgIGVxdWFsIHRvIG9uZSBvZiB0aGUgODAgdmFsdWVzIGxpc3RlZCBiZWxvdzoNCj4+DQo+PiAg ICAgICAxICogT0RVMi50czsgMiAqIE9EVTIudHM7IC4uLjsgOCAqIE9EVTIudHM7DQo+PiAgICAg ICA5ICogT0RVMy50czsgMTAgKiBPRFUzLnRzLCAuLi47IDMyICogT0RVMy50czsNCj4+ICAgICAg IDMzICogT0RVNC50czsgMzQgKiBPRFU0LnRzOyAuLi47IDgwICogT0RVNC50cy4NCj4+DQo+PjIp IEZvbGxvdyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDUNCj4+ICAg aS5lLiwgdXNlIGEgbmV3IEMtdHlwZSBmb3IgT1ROLVRETSBsYWJlbHMuICBFbmNvZGluZyBkZXRh aWxzDQo+PiAgIHVuY2hhbmdlZCBmcm9tIGc3MDl2My0wNC4NCj4+ICAgKFRoaXMgb3B0aW9uIGFk ZHJlc3NlcyB0aGUgaXNzdWUgb2YgdGhlIHNhbWUgYy10eXBlIG5lZWRpbmcgdG8NCj4+ICAgIGJl IHBhcnNlZCBiYXNlZCBvbiBsYWJlbC9zd2l0Y2hpbmcgdHlwZS4pDQo+Pg0KPj4zKSBGb2xsb3cg ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA2DQo+PiAgIGkuZS4sICB1 c2UgYSBuZXcgQy10eXBlIGZvciBPVE4tVERNIGxhYmVscy4gTiBpcyBkaXJlY3RseSBjYXJyaWVk DQo+PiAgIGZvciBPRFVmbGV4KEdGUCkgb25seS4NCj4+DQo+PjQpIERpc2N1c3NlZCwgYnV0IG5v dCBpbiBhbnkgZHJhZnQNCj4+ICAgVXNlIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5n LWc3MDl2My0wNCBlbmNvZGluZyBmb3IgYWxsDQo+PiAgIGJ1dCBPRFVmbGV4KEdGUCksIGFuZCBk ZWZpbmUgbmV3IE9EVWZsZXgoR0ZQKSBzcGVjaWZpYyBUcmFmZmljDQo+PiAgIFBhcmFtZXRlcnMg YmFzZWQgb24gZzcwOXYzLTA2LCBwcmVzdW1hYmx5IHdpdGggdW51c2VkIGZpZWxkcw0KPj4gICBy ZW1vdmVkLg0KPj4gICAoVGhpcyBhbHNvIGFkZHJlc3NlcyB0aGUgaXNzdWUgb2YgdGhlIHNhbWUg Yy10eXBlIG5lZWRpbmcgdG8gYmUNCj4+ICAgIHBhcnNlZCBiYXNlZCBvbiBsYWJlbCB0eXBlLCBi dXQgbWVhbnMgdGhlcmUgYXJlIGRpZmZlcmVudCB0eXBlcw0KPj4gICAgYmFzZWQgb24gc2lnbmFs IHR5cGUuKQ0KPj4NCj4+T3B0aW9uIDEgYW5kIDIgZG8gbm90IGltcGx5IGFueSBjaGFuZ2VzIHRv IHJvdXRpbmcsIHdoaWxlIA0KPm9wdGlvbnMgMyBhbmQNCj4+NCBtYXkuICBSb3V0aW5nIGltcGxp Y2F0aW9ucyB3aWxsIGJlIGRpc2N1c3NlZCBiYXNlZCBvbiB0aGUgDQo+cmVzdWx0cyBvZiANCj4+ dGhpcyBwb2xsLCBhbmQgb25seSBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdG8gc3VwcG9ydCBwb3Np dGlvbnMgMyBvciA0Lg0KPj4NCj4+V2UgaG9wZSB0byBtYWtlIGEgY29uc2Vuc3VzIGNhbGwgYnkg dGhlIGVuZCBvZiB0aGUgd2VlaywgYnV0IHdpbGwgDQo+PmNvbnRpbnVlIHRoZSBkaXNjdXNzaW9u IGFzIG5lZWRlZC4NCj4+DQo+Pk11Y2ggdGhhbmtzLA0KPj5Mb3UgKGFuZCBEZWJvcmFoKQ0KPj4N Cj4+T24gMS8yOC8yMDEzIDU6MDggQU0sIERhbmllbGUgQ2VjY2FyZWxsaSB3cm90ZToNCj4+PiAg QWxsLA0KPj4+IA0KPj4+IEkgdGhpbmsgdGhlIGNoYW5nZXMgcHJvcG9zZWQgYXJlIG1lYW5pbmdm dWwgYW5kIHdvdWxkIA0KPnN1cHBvcnQgdGhlbSBpbiANCj4+PmFuIGluZGl2aWR1YWwgb3IgZWFy bHkgV0cgZHJhZnQsIGJ1dCB0aGV5IGRvbid0IHNlZW0gdG8gcHJvdmlkZSANCj4+PnNpZ25pZmlj YXRpdmUgYWR2YW50YWdlcyB0byByaXNrIGludGVyd29ya2luZyBpc3N1ZXMgd2l0aCBlYXJseSAN Cj4+PmltcGxlbWVudGF0aW9ucy4NCj4+PiBNb3Jlb3ZlciB0aGUgY2hhbmdlcyBkb24ndCBhbGxv dyB1cyBnZXR0aW5nIHRvdGFsbHkgcmlkIG9mIG9mIHRoZSANCj4+PmJpdF9yYXRlIGZpZWxkIGFz IGl0IGlzIHN0aWxsIG5lZWRlZCBmb3IgT0RVZmxleCAoQ0JSKS4NCj4+PiANCj4+PiBNeSAyYw0K Pj4+IERhbmllbGUNCj4+PiANCj4+PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4gRnJvbTogWmFmYXIgQWxpICh6YWxpKSBbbWFpbHRvOnphbGlAY2lzY28uY29tXQ0KPj4+ PiBTZW50OiBsdW5lZMOsIDI4IGdlbm5haW8gMjAxMyA0LjQ3DQo+Pj4+IFRvOiBMb3UgQmVyZ2Vy DQo+Pj4+IENjOiBHcnVtYW4sIEZyZWQ7IEZhdGFpIFpoYW5nOyBEYW5pZWxlIENlY2NhcmVsbGk7 IENDQU1QOyANCj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRv b2xzLmlldGYub3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21t ZW50cyBvbg0KPj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQN Cj4+Pj4NCj4+Pj4gSGkgTG91LQ0KPj4+Pg0KPj4+PiBQbGVhc2Ugc2VlIGluLWxpbmUuDQo+Pj4+ DQo+Pj4+IFRoYW5rcw0KPj4+Pg0KPj4+PiBSZWdhcmRzLi4uWmFmYXINCj4+Pj4NCj4+Pj4gT24g MS8yNy8xMyA5OjQ2IFBNLCAiTG91IEJlcmdlciIgPGxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0K Pj4+Pg0KPj4+Pj4gWmFmYXIsDQo+Pj4+PiAJSXMgeW91ciBjb21tZW50IHdpdGggcmVzcGVjdCB0 byBqdXN0IHJvdXRpbmcgb3IgYm90aA0KPj4+PiBzaWduYWxpbmcgYW5kDQo+Pj4+PiByb3V0aW5n Pw0KPj4+Pg0KPj4+PiBCb3RoLCBpbmNsdWRpbmcgY29uc2lzdGVuY3kgYmV0d2VlbiBzaWduYWxp bmcgYW5kIHJvdXRpbmcgDQo+YXR0cmlidXRlcy4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBBbHNvLCB3 aGVuIHlvdSBzYXkgImltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiBkcmFmdCB2ZXJzaW9ucyIsDQo+ Pj4+IGRvIHRoZXNlDQo+Pj4+PiBpbXBsZW1lbnRhdGlvbnMgaW5jbHVkZSBzdXBwb3J0IGZvciBP RFVmbGV4PyAgKFdoaWNoIGhhcyByZWFsbHkgDQo+Pj4+PiBiZWVuIHRoZSBmb2N1cyBvZiB0aGUg ZGlzY3Vzc2lvbi4pDQo+Pj4+DQo+Pj4+IFllcywgSSB3YXMgcmVmZXJyaW5nIHRvIE9EVUZsZXgu IEFzIHlvdSBrbm93LCBmaXhlZCBPRFUgaXMgDQo+c2lnbmFsZWQgDQo+Pj4+IHZpYSBsZXZlbCAo MCBCVykgc28gaXRzIG5vdCBhbiBpc3N1ZS4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBCVFcgSSB0b29r IEZyZWQncyBjb21tZW50cyBhcyByZWxhdGVkIHRvIGp1c3QgdGhlIG5ldw0KPj4+PiBPVE4tc3Bl Y2lmaWMgSVNDRA0KPj4+Pj4gZGVmaW5pdGlvbnMgKHNlY3Rpb24gNC4xLjIgb2Ygb3NwZi1nNzA5 djMtMDUsIGluIA0KPnBhcnRpY3VsYXIpLiAgTm90ZSANCj4+Pj4+IHRoYXQgc2VjdGlvbiA0LjEu MSBhbHJlYWR5IGNhcnJpZXMgTiAobnVtYmVyIG9mIE9EVXMpIG5vdA0KPj4+PiBJRUVFIGZsb2F0 aW5nDQo+Pj4+PiBwb2ludCByZXByZXNlbnRhdGlvbnMgb2YgYXZhaWxhYmxlIGJhbmR3aWR0aC4N Cj4+Pj4NCj4+Pj4gV2hhdCBJIG1lYW50IGlzIFVucmVzZXJ2ZWQgQmFuZHdpZHRoIGF0IHByaW9y aXR5IHggYW5kIE1heCBMU1AgDQo+Pj4+IEJhbmR3aWR0aCBhdCBwcmlvcml0eSB4Lg0KPj4+Pg0K Pj4+Pj4NCj4+Pj4+IE11Y2ggdGhhbmtzLA0KPj4+Pj4gTG91DQo+Pj4+Pg0KPj4+Pj4gT24gMS8y Ny8yMDEzIDc6NDYgUE0sIFphZmFyIEFsaSAoemFsaSkgd3JvdGU6DQo+Pj4+Pj4gQWxsLQ0KPj4+ Pj4+DQo+Pj4+Pj4gVGhpcyBpbXBhY3RzIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBiYXNlZCBv biBkcmFmdCANCj52ZXJzaW9ucyAoYW5kIA0KPj4+Pj4+IGhlbmNlIGludGVyb3Agd2l0aCB0aGVz ZSBpbXBsZW1lbnRhdGlvbnMgbW92aW5nIGZvcndhcmQpLg0KPj4+PiBJTU8gdGhpcyBpcw0KPj4+ Pj4+IGEgYmlnZ2VyIGNoYW5nZSBmb3IgdXMgdG8gYXNzdW1lIGF0IHRoZSBsYXN0IGNhbGwgc3Rh Z2UuDQo+Pj4+IEZ1cnRoZXJtb3JlDQo+Pj4+Pj4gd2UgaGF2ZSBiZWVuIHVzaW5nIElFRUUgZmxv YXRpbmcgcG9pbnQgZm9ybWF0IGZvciBVbnJlc2VydmVkIA0KPj4+Pj4+IEJhbmR3aWR0aC8gTWF4 IExTUCBCVyBpbiBJRUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCBmb3Igb3RoZXIgDQo+Pj4+Pj4g dGVjaG5vbG9naWVzLiBPdmVyYWxsLCBJIHRoaW5rIHRoaXMgY2hhbmdlIHN1ZmZlcnMgZnJvbSB0 aGUNCj4+Pj4gImxhdyBvZiBkaW1pbmlzaGluZyByZXR1cm5zIi4NCj4+Pj4+Pg0KPj4+Pj4+IFRo YW5rcw0KPj4+Pj4+DQo+Pj4+Pj4gUmVnYXJkcyDFoCBaYWZhcg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+ Pj4+PiBPbiAxLzI3LzEzIDEwOjI4IEFNLCAiR3J1bWFuLCBGcmVkIg0KPj4+PiA8ZnJlZC5ncnVt YW5AdXMuZnVqaXRzdS5jb20+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IEhpIExvdSwgRmF0YWks IERhbmllbGUsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgdW5kZXJzdGFuZCB0aGUgbGF0ZXN0IGNoYW5n ZSB0byB0aGUgd2F5IGJhbmR3aWR0aCBpcw0KPj4+PiBzaWduYWxlZCBmb3INCj4+Pj4+Pj4gT0RV ZmxleChHRlApLCBpLmUuLCBzaWduYWxpbmcgdGhlIG51bWJlciBvZiB0cmlidXRhcnkgc2xvdHMN Cj4+Pj4gTiBpbnN0ZWFkDQo+Pj4+Pj4+IG9mICB0aGUgYmFuZHdpZHRoIHJhdGUgaW4gYnBzLiAg SSBiZWxpZXZlIHRoYXQgdGhpcyBzaW1wbGlmaWVzIA0KPj4+Pj4+PiB0aGUgc2lnbmFsaW5nICBh bmQgaW50ZXJvcGVyYWJpbGl0eSBzbyBJJ20gaW4gYWdyZWVtZW50IHdpdGgNCj4+Pj4gdGhpcyBj aGFuZ2UuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhvd2V2ZXIsIGl0IHNlZW1zIHdlIGFyZSBub3cgaW5j b25zaXN0ZW50IGJldHdlZW4gaG93IHdlDQo+Pj4+IHJlcHJlc2VudA0KPj4+Pj4+PiBiYW5kd2lk dGggaW4gcm91dGluZyBhbmQgc2lnbmFsaW5nIGZvciBPRFVmbGV4KEdGUCkuICBSb3V0aW5nIA0K Pj4+Pj4+PiBhZHZlcnRpc2VzICB0aGUgYmFuZHdpZHRoIHVzaW5nIGEgZmxvYXRpbmcgcG9pbnQg cmVwcmVzZW50YXRpb24gDQo+Pj4+Pj4+IG9mIGJhbmR3aWR0aCwgd2hpbGUgIHNpZ25hbGluZyBp cyB1c2luZyB0aGUgbnVtYmVyIG9mIA0KPnRyaWJ1dGFyeSBzbG90cy4NCj4+Pj4+Pj4gSXQgc2Vl bXMgdGhlIHNhbWUgIGJlbmVmaXRzIHdvdWxkIGJlIG9idGFpbmVkIGJ5DQo+Pj4+IGFkdmVydGlz aW5nIHRoZSBtYXgNCj4+Pj4+Pj4gTFNQIGJhbmR3aWR0aCBhbmQgIHVucmVzZXJ2ZWQgYmFuZHdp ZHRoIGZvciBPRFVmbGV4KEdGUCkgaW4NCj4+Pj4gdGVybXMgb2YNCj4+Pj4+Pj4gdGhlIG51bWJl ciBvZiB0cmlidXRhcnkgIHNsb3RzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBGcmVkDQo+Pj4+Pj4+DQo+ Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ Pj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGll dGYub3JnXSBPbiANCj4+Pj4+Pj4gQmVoYWxmIE9mICBMb3UgQmVyZ2VyDQo+Pj4+Pj4+IFNlbnQ6 IFdlZG5lc2RheSwgSmFudWFyeSAyMywgMjAxMyA5OjA4IEFNDQo+Pj4+Pj4+IFRvOiBGYXRhaSBa aGFuZw0KPj4+Pj4+PiBDYzogQ0NBTVA7IA0KPmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFs aW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZw0KPj4+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBX RyBMYXN0IENhbGwgY29tbWVudHMgb24NCj4+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1z aWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZhdGFpLA0KPj4+Pj4+Pg0KPj4+ Pj4+PiBPbiAxLzIzLzIwMTMgNjo0OSBBTSwgRmF0YWkgWmhhbmcgd3JvdGU6DQo+Pj4+Pj4+PiBI aSBMb3UsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRm9yIE9EVWZsZXgoQ0JSKSwgdGhlIGZvcm11bGEg aXMgZnJvbSBbRy43MDktMjAxMl0gYW5kIGl0DQo+Pj4+IGhhcyBiZWVuDQo+Pj4+Pj4+PiBkaXNj dXNzZWQgYmVmb3JlLCBzbyBwbGVhc2UgdHJ1c3QgdGhhdCB0aGVyZSBpcyBubw0KPj4+PiBvcHBv cnR1bml0eSBmb3INCj4+Pj4+Pj4+IG1pc2ludGVycHJldGF0aW9uLiAoTm90ZSB0aGF0IHRoZXJl IGFyZSB0d28gY2FzZXMsIG9uZSBpcw0KPj4+Pj4+Pj4gT0RVZmxleChDQlIpIGFuZCBhbm90aGVy IG9uZSBpcyBPRFVmbGV4KEdGUCkpLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEluIGFkZHRpb24sIE9E VWZsZXggY2Fubm90IGJlIGNvbmNhdGVuYXRlZCBieSBbRy43MDktMjAxMl0uDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IFRoYW5rcyBmb3IgY29uZmlybWluZyBteSB1bmRlcnN0YW5kaW5nLiAgVGhpcyByYWlz ZXMgdGhlDQo+Pj4+IHF1ZXN0aW9uIG9mDQo+Pj4+Pj4+IGlmIHRoZSBuZXcgdHJhZmZpYyBzaG91 bGQganVzdCBhcHBseSB0byBPRFVGbGV4PyAgQ29ycmVjdA0KPj4+PiBtZSBpZiBJJ20NCj4+Pj4+ Pj4gd3JvbmcsIGJ1dCBJIGJlbGlldmUgdGhlIFtSRkM0MzI4XSBpcyBzdWZmaWNpZW50IGluIGFs bA0KPj4+PiBvdGhlciBjYXNlcy4gIA0KPj4+Pj4+PiBUaGlzIG1heSBhbHNvIG1ha2UgaXQgZWFz aWVyIGZvciBlYXJseSBpbXBsZW1lbnRhdGlvbnMgb2YNCj4+Pj4gdGhlIGRyYWZ0DQo+Pj4+Pj4+ IGFzIHRoZW4gdGhleSBjYW4gbGltaXQgY29kZSBjaGFuZ2VzIGZyb20gdGhlICgtMDMpIHJldiB0 bw0KPj4+PiBvbmx5IE9EVWZsZXggTFNQcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSnVzdCB0byBiZSBj bGVhciwgSSdtIHJlYWxseSBqdXN0ICphc2tpbmcqIGFib3V0IHRoaXMuICANCj5BcyBJIHNhaWQg DQo+Pj4+Pj4+IGJlZm9yZSwgSSdtIG9wZW4gb24gc3BlY2lmaWNzLi4uDQo+Pj4+Pj4+DQo+Pj4+ Pj4+IEFueSB0aG91Z2h0cy9jb21tZW50cz8gQXV0aG9ycz8gIEltcGxlbWVudG9ycz8NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+PiBMb3UNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4+IEkgd2lsbCBpc3N1ZSBhIG5ldyB2ZXJzaW9uIHRvbW9ycm93IHRvIGNhcHR1cmUgYWxsIA0K PnlvdXIgY29tbWVudHMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEJlc3QgUmVnYXJk cw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFtt YWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4+Pj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFy eSAyMywgMjAxMyAyOjExIEFNDQo+Pj4+Pj4+PiBUbzogRmF0YWkgWmhhbmcNCj4+Pj4+Pj4+IENj OiBDQ0FNUDsgDQo+Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5 djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3Qg Q2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxp bmctZzcwOXYzLTA0DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRmF0YWksDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4gT24gMS8yMC8yMDEzIDk6NDMgUE0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4+Pj4+IEhp IExvdSwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFlvdSBzYWlkOg0KPj4+Pj4+Pj4+PiBidXQgeW91 J3JlIHNheXMgZW5jb2RlZCBhcyAoTipOb21pbmFsIFJhdGUpIHJpZ2h0PyBXYXQncyB0aGUgDQo+ Pj4+Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IFtGYXRhaV0gVGhlIG9yaWdpbmFsIHdheSAoaW4gdmVyc2lvbiAwNCYwNSkgaXMg cHV0dGluZw0KPj4+PiAoTiogTm9taW5hbA0KPj4+Pj4+Pj4+IFJhdGUpIGluICJCaXRfUmF0ZSIg ZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSwgdGhlIHZhbHVlIGlzIHRoYXQgDQo+Pj4+Pj4+Pj4gd2Ug Y2FuIGdlbmVyYWxpemUgdG8ganVzdCB1c2Ugb25lIHNpbmdsZSAiQml0X1JhdGUiIGZpZWxkIHRv IA0KPj4+Pj4+Pj4+IGNhcnJ5IElFRUUgZmxvYXQgbnVtYmVyIGZvciBib3RoIGNhc2VzLCBpdCBz ZWVtcyB0aGF0IHlvdQ0KPj4+PiBkb24ndCBhZ3JlZSBvbg0KPj4+Pj4+Pj4+IHRoaXMgdmFsdWUs IDotKQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEkndmUgc2VlbiBkaWZmZXJlbmNlcyBpbiBjYWxjdWxh dGVkIGZsb2F0aW5nIHBvaW50IHZhbHVlcyBmcm9tIA0KPj4+Pj4+Pj4gZGlmZmVyZW50ICBpbXBs ZW1lbnRhdGlvbnMsIHNvIEkganVzdCB3YW50IHRvIGVuc3VyZSB0aGF0DQo+Pj4+IHN1Y2ggY2Fz ZXMNCj4+Pj4+Pj4+IGFyZSBhdm9pZGVkLg0KPj4+Pj4+Pj4gSSdtIG9wZW4gdG8gc3BlY2lmaWMg c29sdXRpb25zIGFuZCBjZXJ0YWlubHkgd2lsbCANCj5kZWZmZXIgb24gdGhlIA0KPj4+Pj4+Pj4g c3BlY2lmaWNzIGFzc3VtaW5nIHRoZXJlIGlzIG5vIG9wcG9ydHVuaXR5IGZvciANCj4+Pj4+Pj4+ IG1pc2ludGVycHJldGF0aW9uL2ludGVyb3AgIGlzc3Vlcy4gSSBkb24ndCB0aGluayB0aGUNCj4+ Pj4gb3JpZ2luYWwgcGFzc2VkDQo+Pj4+Pj4+PiB0aGlzIHRocmVzaG9sZCwgaS5lLiw6DQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICAgTiA9IENlaWxpbmcgb2YNCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiAgICBPRFVmbGV4KENCUikgbm9taW5hbCBiaXQgcmF0ZSAqICgxICsgT0RVZmxleChDQlIpIGJp dCByYXRlDQo+Pj4+Pj4+PiB0b2xlcmFuY2UpDQo+Pj4+Pj4+PiAgICANCj4+Pj4+Pj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pj4+IC0tLS0tLS0tLS0NCj4+Pj4+Pj4+ICAgICAgICBPRFRVay50cyBub21pbmFsIGJpdCByYXRl ICogKDEgLSBITyBPUFVrIGJpdCByYXRlDQo+Pj4+IHRvbGVyYW5jZSkNCj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4gLiBUaGVyZWZvcmUsIEkgKHdhcykgYW0gc2F5aW5nIHRoYXQgSSBhbSBnb2luZyB0byBh Y2NlcHQgeW91ciANCj4+Pj4+Pj4+PiBzdWdnZXN0aW9uIHRvIGNhcnJ5IE4gZm9yIE9EVWZsZXgo R0ZQKS4gV2UgYXJlDQo+Pj4+IGRpc2N1c3Npbmcgd2hlcmUgdG8NCj4+Pj4+Pj4+PiBwdXQgTiBm b3IgT0RVZmxleChHRlApLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFlvdSBzYWlk Og0KPj4+Pj4+Pj4+PiBiaXRzIGluIHRoZSBjb250cm9sIHBsYW5lIGFyZSBnZW5lcmFsbHkgY2hl YXAsIElNTyBpdCdzDQo+Pj4+IGJldHRlciB0bw0KPj4+Pj4+Pj4+PiBoYXZlIHNpbXBsZXIgZW5j b2RpbmcgdGhhbiB0byBvcHRpbWl6ZSBldmVyeSBiaXQgKG9yIA0KPjggaW4gdGhpcyANCj4+Pj4+ Pj4+Pj4gY2FzZSkuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBbRmF0YWldIE9LLCBJIHdpbGwgYWRk IGEgbmV3IGZpZWxkICh0byBvY2N1cHkgdGhlIHJlc2VydmVkIA0KPj4+Pj4+Pj4+IGJpdHMpIHRv IGNhcnJ5IE4uDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQXMgeW91IHNlZSBmaXQuDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4gSnVzdCB0byBjbGFyaWZ5IG15IHVuZGVyc3RhbmRpbmcsIE9EVWZsZXggYW5kIFZp cnR1YWwNCj4+Pj4gY29uY2F0ZW5hdGlvbg0KPj4+Pj4+Pj4gY2FuICBuZXZlciBiZSBjb21iaW5l ZCBmb3IgdGhlIHNhbWUgc2lnbmFsIHR5cGUvbGV2ZWwsIHJpZ2h0Pw0KPj4+Pj4+Pj4gKEFsdGhv dWdoIGFuICBPRFVmbGV4IGNsaWVudCBzaWduYWwgY291bGQgYmUgY2FycmllZCBvdmVyDQo+Pj4+ IGEgdmlydHVhbA0KPj4+Pj4+Pj4gY29uY2F0ZW5hdGVkICBPRFVrKS4gIElzIHRoaXMgY29ycmVj dCBvciBkaWQgSSBtaXNzIA0KPnNvbWV0aGluZyBpbiANCj4+Pj4+Pj4+IEc3MDk/DQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4gTG91DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gRmF0YWkNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+Pj4+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5u ZXRdDQo+Pj4+Pj4+Pj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDE4LCAyMDEzIDE6NDIgQU0NCj4+ Pj4+Pj4+PiBUbzogRmF0YWkgWmhhbmcNCj4+Pj4+Pj4+PiBDYzogQ0NBTVA7IA0KPj4+Pj4+Pj4+ IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZw0K Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0K Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIDEvMTUvMjAxMyAxMDox NiBQTSwgRmF0YWkgWmhhbmcgd3JvdGU6DQo+Pj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4gVG8gYXZvaWQgbWlzdW5kZXJzdGFuZGluZywgSSB3b3VsZCBsaWtlIHRvIGNs YXJpZnkgDQo+bW9yZSBvbiB0aGUgDQo+Pj4+Pj4+Pj4+IGZvbGxvd2luZyBwb2ludC4NCj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IEl0IGlzIGJldHRlciB0byBoYXZlIGNv bnNpc3RlbnQgZm9ybWF0IGFuZCB0aGUgc2FtZSANCj4+Pj4+Pj4+Pj4+Pj4+IG1lYW5pbmcgb2Yg b25lDQo+Pj4+Pj4+Pj4gZmllbGQgZm9yIGJvdGggT0RVZmxleChDQlIpIGFuZCBHRlAuIFRoaXMg aXMgd2h5IHdlIGhhdmUgDQo+Pj4+Pj4+Pj4gc2VjdGlvbg0KPj4+Pj4+Pj4+IDUuMQ0KPj4+Pj4+ Pj4+ICY1LjIgdG8gZGVzY3JpYmUgdGhlIGNvbXBsZXggc3R1ZmYuDQo+Pj4+Pj4+Pj4+Pj4+IEkg YWN0dWFsbHkgd2Fzbid0IHN1Z2dlc3RpbmcgdGhhdCBOIGJlIGNhcnJpZWQgaW4NCj4+Pj4gdGhl IGJpdCByYXRlDQo+Pj4+Pj4+Pj4+Pj4+IGZpZWxkLg0KPj4+Pj4+Pj4+Pj4+PiBUaGUgYml0IHJh dGUgZmllbGQgY2FuIGVpdGhlciBiZSBzZXQgYXMgZGVzY3JpYmVkIG9yIHRvIA0KPj4+Pj4+Pj4+ Pj4+PiB6ZXJvIChpLmUuLCAgaWdub3JlZCkuICBBdCB0aGUgdGltZSwgSSB3YXMgdGhpbmtpbmcg YWJvdXQNCj4+Pj4gY2FycnlpbmcgTg0KPj4+Pj4+Pj4+Pj4+PiBpbiB0aGUgIHJlc2VydmVkICBm aWVsZC4gQnV0IHBlcmhhcHMgdGhlIHJpZ2h0IHBsYWNlDQo+Pj4+IGlzIE1ULCBpZg0KPj4+Pj4+ Pj4+Pj4+PiBteSB1bmRlcnN0YW5kaW5nIGlzICByaWdodCAgKHdvdWxkIGFsd2F5cyBiZSAxDQo+ Pj4+IG90aGVyd2lzZSkuIEknbQ0KPj4+Pj4+Pj4+Pj4+PiBvcGVuIHRvIGVpdGhlci4uLg0KPj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFtGYXRhaV0gV2h5IG5vdCBqdXN0IHVzZSAiYml0IHJh dGUiZmllbGQgdG8gY2FycnkNCj4+Pj4gIk4iYmVjYXVzZSAiTiINCj4+Pj4+Pj4+Pj4+PiBpbXBs aWVzIGJpdCByYXRlPyAgSSBhbSBPSyBpZiB5b3UgbGlrZSB0byB1c2UgYSBuZXcNCj4+Pj4gZmls ZWQgKGxpa2UNCj4+Pj4+Pj4+Pj4+PiAiVFMNCj4+Pj4+Pj4+Pj4+PiBOdW1iZXIiKSB0byBvY2N1 cHkgdGhlIHJlc2VydmVkIGZpZWxkIGV2ZW4gdGhvdWdoDQo+Pj4+IHRoYXQgSSBwcmVmZXINCj4+ Pj4+Pj4+Pj4+PiB0aGUgIG9yaWdpbmFsIGFwcHJvYWNoIChpZS4sIHVzZSAiYml0IHJhdGUiZmll bGQgDQo+dG8gY2FycnkgIk4iKS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBBcmUgeW91IHBy b3Bvc2luZyBkcm9wcGluZyBjYXJyeWluZyBiaXQgcmF0ZXMNCj4+Pj4gcmVwcmVzZW50ZWQgYXMg YW4NCj4+Pj4+Pj4+Pj4+IElFRUUgIGZsb2F0aW5nIHBvaW50IGFuZCBqdXN0IGNhcnJ5aW5nIE4g Zm9yIE9EVWZsZXg/DQo+Pj4+IFRoaXMgc2VlbXMNCj4+Pj4+Pj4+Pj4+IHdvcmthYmxlICB0byAg bWUsIGJ1dCB3ZSBzaG91bGQgZW5zdXJlIHRoYXQgdGhlcmUgYXJlIG5vIA0KPj4+Pj4+Pj4+Pj4g c2lnbmlmaWNhbnQgb2JqZWN0aW9ucy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gW0ZhdGFpXSBU aGVyZSBhcmUgdHdvIHVzYWdlcyBmb3IgIiBCaXRfUmF0ZSAiIGZpZWxkIGFzDQo+Pj4+IGRlc2Ny aWJlZA0KPj4+Pj4+Pj4+PiBpbiB0aGUgbGluZXMgMjg3LTMxMC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4gKDEpICAgIEZvciBPRFVmbGV4KENCUiksIHRoZSBCaXRfUmF0ZSBmaWVsZCBpbmRpY2F0 ZXMNCj4+Pj4gdGhlIG5vbWluYWwNCj4+Pj4+Pj4+Pj4gYml0DQo+Pj4+Pj4+Pj4+IHJhdGUgb2Yg T0RVZmxleChDQlIpIGV4cHJlc3NlZCBpbiBieXRlcyBwZXIgc2Vjb25kLA0KPj4+PiBlbmNvZGVk IGFzIGENCj4+Pj4+Pj4+Pj4gMzItYml0ICBJRUVFIHNpbmdsZSBwcmVjaXNpb24gZmxvYXRpbmct cG9pbnQgbnVtYmVyLiANCj5Gb3IgdGhpcyANCj4+Pj4+Pj4+Pj4gY2FzZSwgd2UgTVVTVCAgdXNl ICAzMi1iaXQgSUVFRSBmbG9hdGluZyBwb2ludCBpbnN0ZWFkIG9mIA0KPj4+Pj4+Pj4+PiAiTiIo UGxlYXNlIHNlZSBtb3JlIGluIHNlY3Rpb24gIDUuMSkuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJ IGd1ZXNzIHlvdSByZWFsbHkgc3RpbGwgbmVlZCAodG8gYmUgYmFzZWQgb24pIHRoZSBjbGllbnQg DQo+Pj4+Pj4+Pj4gc2lnbmFsIHJhdGUgYXQgdGhlIGVkZ2VzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+ICgyKSAgICBGb3IgT0RVZmxleChHRlApLCB3ZSBjYW4gY2hhbmdlIHRo ZSB0ZXh0ICh0aGUNCj4+Pj4gbGluZXMgZnJvbSAzMDUNCj4+Pj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+ Pj4gMzEwKSBiYXNlZCBvbiB5b3VyIHN1Z2dlc3Rpb24sIGllLiwgdGhlIEJpdF9SYXRlIGZpZWxk DQo+Pj4+IGlzIHVzZWQgdG8NCj4+Pj4+Pj4+Pj4gY2FycnkgICJOInRvIGluZGljYXRlIHRoZSBu b21pbmFsIGJpdCByYXRlIG9mIHRoZSAgDQo+T0RVZmxleChHRlApLg0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4gYnV0IHlvdSdyZSBzYXlzIGVuY29kZWQgYXMgKE4qTm9taW5hbCBSYXRlKSByaWdodD8g IFdhdCdzIHRoZSANCj4+Pj4+Pj4+PiB2YWx1ZSBvZiAgdGhpcyB2cyBqdXN0IGNhcnJ5aW5nIE4/ DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBUaGVyZWZvcmUs IEkgYW0gcHJvcG9zaW5nIHVzaW5nIG9uZSBzaW5nbGUgZmlsZWQgDQo+KCJCaXRfUmF0ZSAiKSAN Cj4+Pj4+Pj4+Pj4gZm9yIHRoZXNlIHR3byBjYXNlcywgaW4gdGhpcyB3YXksIHdlIGNhbiBsZWF2 ZSB0aGUgIlJlc2VydmVkIg0KPj4+Pj4+Pj4+PiBiaXRzIGZvciBmdXR1cmUuDQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+PiBiaXRzIGluIHRoZSBjb250cm9sIHBsYW5lIGFyZSBnZW5lcmFsbHkgY2hlYXAs IElNTyBpdCdzDQo+Pj4+IGJldHRlciB0bw0KPj4+Pj4+Pj4+IGhhdmUgIHNpbXBsZXIgZW5jb2Rp bmcgdGhhbiB0byBvcHRpbWl6ZSBldmVyeSBiaXQgKG9yIA0KPjggaW4gdGhpcyANCj4+Pj4+Pj4+ PiBjYXNlKS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IExvdQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+IEhvcGUgd2UgYXJlIG5vdyBhdCB0aGUgc2FtZSBwYWdlLg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBCZXN0IFJlZ2FyZHMNCj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4gRmF0YWkNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gQ0NBTVAgbWFp bGluZyBsaXN0DQo+Pj4+Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0 DQo+Pj4+Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4gDQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PkNDQU1QIG1haWxpbmcgbGlzdA0KPj5DQ0FNUEBpZXRmLm9yZw0K Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5DQ0FNUCBtYWlsaW5n IGxpc3QNCj5DQ0FNUEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2NhbXANCj4= From lberger@labn.net Tue Jan 29 10:47:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975D221F888C for ; Tue, 29 Jan 2013 10:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.342 X-Spam-Level: X-Spam-Status: No, score=-101.342 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 73ZKpGTt7tE9 for ; Tue, 29 Jan 2013 10:47:02 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id DB7BF21F86CA for ; Tue, 29 Jan 2013 10:47:01 -0800 (PST) Received: (qmail 11768 invoked by uid 0); 29 Jan 2013 18:46:35 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 29 Jan 2013 18:46:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=6721QCy92HvbmlIt70R1EWqPc5NWHeBa/DIq8e7zHPU=; b=lm+dowoDHXxp0euAiDSFFkm4Gfhzju4OBhkpzKY1/33n6iUVx4rSHh7iQtyf+uJ1TYkApX23GAIETX4+04q9/YNsSzI9H4FEQY+847y8079FMt7hbDiplioXbO3Q6Pea; Received: from box313.bluehost.com ([69.89.31.113]:34707 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1U0GCZ-00020P-4R; Tue, 29 Jan 2013 11:46:35 -0700 Message-ID: <51081917.3080601@labn.net> Date: Tue, 29 Jan 2013 13:46:47 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Gruman, Fred" References: <5106DED0.3090008@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33126F@RCHEXMBP1.fnc.net.local> In-Reply-To: <5DF87403A81B0C43AF3EB1626511B2923C33126F@RCHEXMBP1.fnc.net.local> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:47:03 -0000 Fred, Thanks for the input. On 1/29/2013 12:54 PM, Gruman, Fred wrote: > Hi Lou, > > I am not clear on option 2 as when I look into draft-ietf-ccamp-gmpls-signaling-g709v3-05, the IANA section shows the c-type for the GENERALIZE_LABEL defined in RFC 3473, not a new c-type. > > OTN-TDM Generalized Label Object: > > o OTN-TDM Generalized Label Object: Class = 16, C-Type = 2 (see > Section 5.1) > I didn't notice that inconsistency. Per http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-05#section-5: The traffic parameters for OTN-TDM capable Switching Type are carried in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have the following class and type: - OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA) - OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA) Lou > I'm open to either carrying ODUflex(GFP) bandwidth as floating-point or integer N, but would like to see consistency between routing and signaling documents. > > > Regards, > Fred > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali) > Sent: Tuesday, January 29, 2013 10:41 AM > To: Lou Berger; CCAMP > Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) > > Hi Lou, C-campers: > > I would pick Option 2; it's cleaner and addresses the issue related to > overloading the same c-type. > > Thanks > > Regards鈥afar > > > -----Original Message----- > From: "lberger@labn.net" > Date: Monday, January 28, 2013 3:25 PM > To: "ccamp@ietf.org" > Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call > comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) > >> All, >> We would like to try to close the discussion on the G.709 >> drafts so that we can move rapidly towards publication request. The >> discussion of (one of my) LC comments has resulted in several options >> for the signaling ODU-related traffic parameters, and the point has >> been raised that realigning routing with signaling should be discussed. >> >> Please keep in mind that the objective of any PS is interoperability, >> and that there may be early implementations that match g709v3-04. >> >> The basic question is one of if N, the number of time slots needed to >> support a ODUflex(GFP) signal, should be carried as a calculated IEEE >> floating point number or directly. Options 1 and 2 below reflect the >> former, options 3 and 4 match the latter. It is worth noting that only >> options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be >> calculated for ODUflex(CBR) signal types with all options. >> >> Please state your support for one the options and, if you wish, the >> justification for your position: >> >> 1) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-04 >> i.e., redefine [RFC4328] Traffic Parameters c-type when used with >> OTN-TDM labels. ODUflex(GFP) number of tributary slots (N) is >> encoded as: >> >> ... the Bit_Rate field for ODUflex(GFP) MUST >> equal to one of the 80 values listed below: >> >> 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; >> 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; >> 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. >> >> 2) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-05 >> i.e., use a new C-type for OTN-TDM labels. Encoding details >> unchanged from g709v3-04. >> (This option addresses the issue of the same c-type needing to >> be parsed based on label/switching type.) >> >> 3) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-06 >> i.e., use a new C-type for OTN-TDM labels. N is directly carried >> for ODUflex(GFP) only. >> >> 4) Discussed, but not in any draft >> Use draft-ietf-ccamp-gmpls-signaling-g709v3-04 encoding for all >> but ODUflex(GFP), and define new ODUflex(GFP) specific Traffic >> Parameters based on g709v3-06, presumably with unused fields >> removed. >> (This also addresses the issue of the same c-type needing to be >> parsed based on label type, but means there are different types >> based on signal type.) >> >> Option 1 and 2 do not imply any changes to routing, while options 3 and >> 4 may. Routing implications will be discussed based on the results of >> this poll, and only if there is consensus to support positions 3 or 4. >> >> We hope to make a consensus call by the end of the week, but will >> continue the discussion as needed. >> >> Much thanks, >> Lou (and Deborah) >> >> On 1/28/2013 5:08 AM, Daniele Ceccarelli wrote: >>> All, >>> >>> I think the changes proposed are meaningful and would support them in >>> an individual or early WG draft, but they don't seem to provide >>> significative advantages to risk interworking issues with early >>> implementations. >>> Moreover the changes don't allow us getting totally rid of of the >>> bit_rate field as it is still needed for ODUflex (CBR). >>> >>> My 2c >>> Daniele >>> >>> >>>> -----Original Message----- >>>> From: Zafar Ali (zali) [mailto:zali@cisco.com] >>>> Sent: luned矛 28 gennaio 2013 4.47 >>>> To: Lou Berger >>>> Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP; >>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: Re: [CCAMP] WG Last Call comments on >>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>> >>>> Hi Lou- >>>> >>>> Please see in-line. >>>> >>>> Thanks >>>> >>>> Regards...Zafar >>>> >>>> On 1/27/13 9:46 PM, "Lou Berger" wrote: >>>> >>>>> Zafar, >>>>> Is your comment with respect to just routing or both >>>> signaling and >>>>> routing? >>>> >>>> Both, including consistency between signaling and routing attributes. >>>> >>>>> >>>>> Also, when you say "implementations based on draft versions", >>>> do these >>>>> implementations include support for ODUflex? (Which has really been >>>>> the focus of the discussion.) >>>> >>>> Yes, I was referring to ODUFlex. As you know, fixed ODU is >>>> signaled via level (0 BW) so its not an issue. >>>> >>>>> >>>>> BTW I took Fred's comments as related to just the new >>>> OTN-specific ISCD >>>>> definitions (section 4.1.2 of ospf-g709v3-05, in particular). Note >>>>> that section 4.1.1 already carries N (number of ODUs) not >>>> IEEE floating >>>>> point representations of available bandwidth. >>>> >>>> What I meant is Unreserved Bandwidth at priority x and Max LSP >>>> Bandwidth at priority x. >>>> >>>>> >>>>> Much thanks, >>>>> Lou >>>>> >>>>> On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote: >>>>>> All- >>>>>> >>>>>> This impacts existing implementations based on draft versions (and >>>>>> hence interop with these implementations moving forward). >>>> IMO this is >>>>>> a bigger change for us to assume at the last call stage. >>>> Furthermore >>>>>> we have been using IEEE floating point format for Unreserved >>>>>> Bandwidth/ Max LSP BW in IEEE floating point format for other >>>>>> technologies. Overall, I think this change suffers from the >>>> "law of diminishing returns". >>>>>> >>>>>> Thanks >>>>>> >>>>>> Regards 艩 Zafar >>>>>> >>>>>> >>>>>> On 1/27/13 10:28 AM, "Gruman, Fred" >>>> wrote: >>>>>> >>>>>>> Hi Lou, Fatai, Daniele, >>>>>>> >>>>>>> I understand the latest change to the way bandwidth is >>>> signaled for >>>>>>> ODUflex(GFP), i.e., signaling the number of tributary slots >>>> N instead >>>>>>> of the bandwidth rate in bps. I believe that this simplifies the >>>>>>> signaling and interoperability so I'm in agreement with >>>> this change. >>>>>>> >>>>>>> However, it seems we are now inconsistent between how we >>>> represent >>>>>>> bandwidth in routing and signaling for ODUflex(GFP). Routing >>>>>>> advertises the bandwidth using a floating point representation of >>>>>>> bandwidth, while signaling is using the number of tributary slots. >>>>>>> It seems the same benefits would be obtained by >>>> advertising the max >>>>>>> LSP bandwidth and unreserved bandwidth for ODUflex(GFP) in >>>> terms of >>>>>>> the number of tributary slots. >>>>>>> >>>>>>> Fred >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>>> Behalf Of Lou Berger >>>>>>> Sent: Wednesday, January 23, 2013 9:08 AM >>>>>>> To: Fatai Zhang >>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>> >>>>>>> Fatai, >>>>>>> >>>>>>> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>>>>>>> Hi Lou, >>>>>>>> >>>>>>>> For ODUflex(CBR), the formula is from [G.709-2012] and it >>>> has been >>>>>>>> discussed before, so please trust that there is no >>>> opportunity for >>>>>>>> misinterpretation. (Note that there are two cases, one is >>>>>>>> ODUflex(CBR) and another one is ODUflex(GFP)). >>>>>>>> >>>>>>>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >>>>>>> >>>>>>> Thanks for confirming my understanding. This raises the >>>> question of >>>>>>> if the new traffic should just apply to ODUFlex? Correct >>>> me if I'm >>>>>>> wrong, but I believe the [RFC4328] is sufficient in all >>>> other cases. >>>>>>> This may also make it easier for early implementations of >>>> the draft >>>>>>> as then they can limit code changes from the (-03) rev to >>>> only ODUflex LSPs. >>>>>>> >>>>>>> Just to be clear, I'm really just *asking* about this. As I said >>>>>>> before, I'm open on specifics... >>>>>>> >>>>>>> Any thoughts/comments? Authors? Implementors? >>>>>>> >>>>>>> Thanks, >>>>>>> Lou >>>>>>> >>>>>>> >>>>>>>> I will issue a new version tomorrow to capture all your comments. >>>>>>>> >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Fatai >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>> Sent: Wednesday, January 23, 2013 2:11 AM >>>>>>>> To: Fatai Zhang >>>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>> >>>>>>>> Fatai, >>>>>>>> >>>>>>>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>>>>>>> Hi Lou, >>>>>>>>> >>>>>>>>> You said: >>>>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>>>> value of this vs just carrying N? >>>>>>>>> >>>>>>>>> [Fatai] The original way (in version 04&05) is putting >>>> (N* Nominal >>>>>>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we >>>>>>>>> can generalize to just use one single "Bit_Rate" field to carry >>>>>>>>> IEEE float number for both cases, it seems that you >>>> don't agree on >>>>>>>>> this value, :-) >>>>>>>> >>>>>>>> I've seen differences in calculated floating point values from >>>>>>>> different implementations, so I just want to ensure that >>>> such cases >>>>>>>> are avoided. >>>>>>>> I'm open to specific solutions and certainly will deffer on the >>>>>>>> specifics assuming there is no opportunity for >>>>>>>> misinterpretation/interop issues. I don't think the >>>> original passed >>>>>>>> this threshold, i.e.,: >>>>>>>> >>>>>>>> N = Ceiling of >>>>>>>> >>>>>>>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate >>>>>>>> tolerance) >>>>>>>> >>>>>>>> ----------------------------------------------------------- >>>> ---------- >>>>>>>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate >>>> tolerance) >>>>>>>> >>>>>>>>> . Therefore, I (was) am saying that I am going to accept your >>>>>>>>> suggestion to carry N for ODUflex(GFP). We are >>>> discussing where to >>>>>>>>> put N for ODUflex(GFP). >>>>>>>>> >>>>>>>> >>>>>>>>> You said: >>>>>>>>>> bits in the control plane are generally cheap, IMO it's >>>> better to >>>>>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>>>>> case). >>>>>>>>> >>>>>>>>> [Fatai] OK, I will add a new field (to occupy the reserved bits) >>>>>>>>> to carry N. >>>>>>>> >>>>>>>> As you see fit. >>>>>>>> >>>>>>>> Just to clarify my understanding, ODUflex and Virtual >>>> concatenation >>>>>>>> can never be combined for the same signal type/level, right? >>>>>>>> (Although an ODUflex client signal could be carried over >>>> a virtual >>>>>>>> concatenated ODUk). Is this correct or did I miss something in >>>>>>>> G709? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lou >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> >>>>>>>>> Fatai >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>> Sent: Friday, January 18, 2013 1:42 AM >>>>>>>>> To: Fatai Zhang >>>>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>>>>>>> Hi Lou, >>>>>>>>>> >>>>>>>>>> To avoid misunderstanding, I would like to clarify more on the >>>>>>>>>> following point. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> It is better to have consistent format and the same meaning >>>>>>>>>>>>>> of one >>>>>>>>> field for both ODUflex(CBR) and GFP. This is why we have section >>>>>>>>> 5.1 >>>>>>>>> &5.2 to describe the complex stuff. >>>>>>>>>>>>> I actually wasn't suggesting that N be carried in >>>> the bit rate >>>>>>>>>>>>> field. >>>>>>>>>>>>> The bit rate field can either be set as described or to zero >>>>>>>>>>>>> (i.e., ignored). At the time, I was thinking about >>>> carrying N >>>>>>>>>>>>> in the reserved field. But perhaps the right place >>>> is MT, if >>>>>>>>>>>>> my understanding is right (would always be 1 >>>> otherwise). I'm >>>>>>>>>>>>> open to either... >>>>>>>>>>>>> >>>>>>>>>>>> [Fatai] Why not just use "bit rate"field to carry >>>> "N"because "N" >>>>>>>>>>>> implies bit rate? I am OK if you like to use a new >>>> filed (like >>>>>>>>>>>> "TS >>>>>>>>>>>> Number") to occupy the reserved field even though >>>> that I prefer >>>>>>>>>>>> the original approach (ie., use "bit rate"field to carry "N"). >>>>>>>>>>> >>>>>>>>>>> Are you proposing dropping carrying bit rates >>>> represented as an >>>>>>>>>>> IEEE floating point and just carrying N for ODUflex? >>>> This seems >>>>>>>>>>> workable to me, but we should ensure that there are no >>>>>>>>>>> significant objections. >>>>>>>>>> >>>>>>>>>> [Fatai] There are two usages for " Bit_Rate " field as >>>> described >>>>>>>>>> in the lines 287-310. >>>>>>>>>> >>>>>>>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates >>>> the nominal >>>>>>>>>> bit >>>>>>>>>> rate of ODUflex(CBR) expressed in bytes per second, >>>> encoded as a >>>>>>>>>> 32-bit IEEE single precision floating-point number. For this >>>>>>>>>> case, we MUST use 32-bit IEEE floating point instead of >>>>>>>>>> "N"(Please see more in section 5.1). >>>>>>>>> >>>>>>>>> I guess you really still need (to be based on) the client signal >>>>>>>>> rate at the edges. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> (2) For ODUflex(GFP), we can change the text (the >>>> lines from 305 >>>>>>>>>> to >>>>>>>>>> 310) based on your suggestion, ie., the Bit_Rate field >>>> is used to >>>>>>>>>> carry "N"to indicate the nominal bit rate of the ODUflex(GFP). >>>>>>>>> >>>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>>> value of this vs just carrying N? >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") >>>>>>>>>> for these two cases, in this way, we can leave the "Reserved" >>>>>>>>>> bits for future. >>>>>>>>> >>>>>>>>> bits in the control plane are generally cheap, IMO it's >>>> better to >>>>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>>>> case). >>>>>>>>> >>>>>>>>> Lou >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hope we are now at the same page. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best Regards >>>>>>>>>> >>>>>>>>>> Fatai >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From lberger@labn.net Tue Jan 29 10:53:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B6621F8626 for ; Tue, 29 Jan 2013 10:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.178 X-Spam-Level: X-Spam-Status: No, score=-101.178 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 BQc9Kj8ugTDZ for ; Tue, 29 Jan 2013 10:53:48 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 7DD9E21F84D5 for ; Tue, 29 Jan 2013 10:53:46 -0800 (PST) Received: (qmail 3957 invoked by uid 0); 29 Jan 2013 18:53:23 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 29 Jan 2013 18:53:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=maZyNJdYOo46ZKLIreHMmkKObjVrraalkv4/ecCh6Dw=; b=UIADQ3enoKqiJJ/VfMeuksiwRwGNqsSGpDbjx7FR4AkILtQj5hsDz8NKZSH0k4KeGm+huQfbnUlxVS+oOlTH6bdbkGwVhwldmiOOH+P9BSxU8RfEIBgUe8K8WvGYfzBO; Received: from box313.bluehost.com ([69.89.31.113]:36062 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1U0GJ8-0007k6-Lu; Tue, 29 Jan 2013 11:53:23 -0700 Message-ID: <51081AAF.8030601@labn.net> Date: Tue, 29 Jan 2013 13:53:35 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Daniele Ceccarelli References: <5106DED0.3090008@labn.net> <4A1562797D64E44993C5CBF38CF1BE48074CE1@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48074CE1@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:53:56 -0000 Daniele, Joking aside, I think it may add value to the discussion to highlight your rational for not wanting to change routing. (You are after all the editor of the routing draft.) Is it: - Just avoiding work for the editor (i.e., your joke...)? - Minimizing a change at this late date? - Minimizing impact on an early implementation? - Something completely different? If you don't mind sharing... Thanks, Lou On 1/29/2013 1:31 PM, Daniele Ceccarelli wrote: > Option 2 for me too. > > Main reason? I don't have to change the routing ID! :-) ...obviously joking. > > Other reasons? Agree with Fatai and Zafar. And prefer 2) to 1) because defines a new C-type. > > BR > Daniele > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >> On Behalf Of Zafar Ali (zali) >> Sent: marted矛 29 gennaio 2013 17.41 >> To: Lou Berger; CCAMP >> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG >> Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) >> >> Hi Lou, C-campers: >> >> I would pick Option 2; it's cleaner and addresses the issue >> related to overloading the same c-type. >> >> Thanks >> >> Regards鈥afar >> >> >> -----Original Message----- >> From: "lberger@labn.net" >> Date: Monday, January 28, 2013 3:25 PM >> To: "ccamp@ietf.org" >> Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG >> Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) >> >>> All, >>> We would like to try to close the discussion on the >> G.709 drafts so >>> that we can move rapidly towards publication request. The discussion >>> of (one of my) LC comments has resulted in several options for the >>> signaling ODU-related traffic parameters, and the point has >> been raised >>> that realigning routing with signaling should be discussed. >>> >>> Please keep in mind that the objective of any PS is interoperability, >>> and that there may be early implementations that match g709v3-04. >>> >>> The basic question is one of if N, the number of time slots needed to >>> support a ODUflex(GFP) signal, should be carried as a calculated IEEE >>> floating point number or directly. Options 1 and 2 below reflect the >>> former, options 3 and 4 match the latter. It is worth noting >> that only >>> options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be >>> calculated for ODUflex(CBR) signal types with all options. >>> >>> Please state your support for one the options and, if you wish, the >>> justification for your position: >>> >>> 1) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>> i.e., redefine [RFC4328] Traffic Parameters c-type when used with >>> OTN-TDM labels. ODUflex(GFP) number of tributary slots (N) is >>> encoded as: >>> >>> ... the Bit_Rate field for ODUflex(GFP) MUST >>> equal to one of the 80 values listed below: >>> >>> 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; >>> 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; >>> 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. >>> >>> 2) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-05 >>> i.e., use a new C-type for OTN-TDM labels. Encoding details >>> unchanged from g709v3-04. >>> (This option addresses the issue of the same c-type needing to >>> be parsed based on label/switching type.) >>> >>> 3) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-06 >>> i.e., use a new C-type for OTN-TDM labels. N is directly carried >>> for ODUflex(GFP) only. >>> >>> 4) Discussed, but not in any draft >>> Use draft-ietf-ccamp-gmpls-signaling-g709v3-04 encoding for all >>> but ODUflex(GFP), and define new ODUflex(GFP) specific Traffic >>> Parameters based on g709v3-06, presumably with unused fields >>> removed. >>> (This also addresses the issue of the same c-type needing to be >>> parsed based on label type, but means there are different types >>> based on signal type.) >>> >>> Option 1 and 2 do not imply any changes to routing, while >> options 3 and >>> 4 may. Routing implications will be discussed based on the >> results of >>> this poll, and only if there is consensus to support positions 3 or 4. >>> >>> We hope to make a consensus call by the end of the week, but will >>> continue the discussion as needed. >>> >>> Much thanks, >>> Lou (and Deborah) >>> >>> On 1/28/2013 5:08 AM, Daniele Ceccarelli wrote: >>>> All, >>>> >>>> I think the changes proposed are meaningful and would >> support them in >>>> an individual or early WG draft, but they don't seem to provide >>>> significative advantages to risk interworking issues with early >>>> implementations. >>>> Moreover the changes don't allow us getting totally rid of of the >>>> bit_rate field as it is still needed for ODUflex (CBR). >>>> >>>> My 2c >>>> Daniele >>>> >>>> >>>>> -----Original Message----- >>>>> From: Zafar Ali (zali) [mailto:zali@cisco.com] >>>>> Sent: luned矛 28 gennaio 2013 4.47 >>>>> To: Lou Berger >>>>> Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP; >>>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>> >>>>> Hi Lou- >>>>> >>>>> Please see in-line. >>>>> >>>>> Thanks >>>>> >>>>> Regards...Zafar >>>>> >>>>> On 1/27/13 9:46 PM, "Lou Berger" wrote: >>>>> >>>>>> Zafar, >>>>>> Is your comment with respect to just routing or both >>>>> signaling and >>>>>> routing? >>>>> >>>>> Both, including consistency between signaling and routing >> attributes. >>>>> >>>>>> >>>>>> Also, when you say "implementations based on draft versions", >>>>> do these >>>>>> implementations include support for ODUflex? (Which has really >>>>>> been the focus of the discussion.) >>>>> >>>>> Yes, I was referring to ODUFlex. As you know, fixed ODU is >> signaled >>>>> via level (0 BW) so its not an issue. >>>>> >>>>>> >>>>>> BTW I took Fred's comments as related to just the new >>>>> OTN-specific ISCD >>>>>> definitions (section 4.1.2 of ospf-g709v3-05, in >> particular). Note >>>>>> that section 4.1.1 already carries N (number of ODUs) not >>>>> IEEE floating >>>>>> point representations of available bandwidth. >>>>> >>>>> What I meant is Unreserved Bandwidth at priority x and Max LSP >>>>> Bandwidth at priority x. >>>>> >>>>>> >>>>>> Much thanks, >>>>>> Lou >>>>>> >>>>>> On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote: >>>>>>> All- >>>>>>> >>>>>>> This impacts existing implementations based on draft >> versions (and >>>>>>> hence interop with these implementations moving forward). >>>>> IMO this is >>>>>>> a bigger change for us to assume at the last call stage. >>>>> Furthermore >>>>>>> we have been using IEEE floating point format for Unreserved >>>>>>> Bandwidth/ Max LSP BW in IEEE floating point format for other >>>>>>> technologies. Overall, I think this change suffers from the >>>>> "law of diminishing returns". >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Regards 艩 Zafar >>>>>>> >>>>>>> >>>>>>> On 1/27/13 10:28 AM, "Gruman, Fred" >>>>> wrote: >>>>>>> >>>>>>>> Hi Lou, Fatai, Daniele, >>>>>>>> >>>>>>>> I understand the latest change to the way bandwidth is >>>>> signaled for >>>>>>>> ODUflex(GFP), i.e., signaling the number of tributary slots >>>>> N instead >>>>>>>> of the bandwidth rate in bps. I believe that this simplifies >>>>>>>> the signaling and interoperability so I'm in agreement with >>>>> this change. >>>>>>>> >>>>>>>> However, it seems we are now inconsistent between how we >>>>> represent >>>>>>>> bandwidth in routing and signaling for ODUflex(GFP). Routing >>>>>>>> advertises the bandwidth using a floating point representation >>>>>>>> of bandwidth, while signaling is using the number of >> tributary slots. >>>>>>>> It seems the same benefits would be obtained by >>>>> advertising the max >>>>>>>> LSP bandwidth and unreserved bandwidth for ODUflex(GFP) in >>>>> terms of >>>>>>>> the number of tributary slots. >>>>>>>> >>>>>>>> Fred >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>>>> Behalf Of Lou Berger >>>>>>>> Sent: Wednesday, January 23, 2013 9:08 AM >>>>>>>> To: Fatai Zhang >>>>>>>> Cc: CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>> >>>>>>>> Fatai, >>>>>>>> >>>>>>>> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>>>>>>>> Hi Lou, >>>>>>>>> >>>>>>>>> For ODUflex(CBR), the formula is from [G.709-2012] and it >>>>> has been >>>>>>>>> discussed before, so please trust that there is no >>>>> opportunity for >>>>>>>>> misinterpretation. (Note that there are two cases, one is >>>>>>>>> ODUflex(CBR) and another one is ODUflex(GFP)). >>>>>>>>> >>>>>>>>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >>>>>>>> >>>>>>>> Thanks for confirming my understanding. This raises the >>>>> question of >>>>>>>> if the new traffic should just apply to ODUFlex? Correct >>>>> me if I'm >>>>>>>> wrong, but I believe the [RFC4328] is sufficient in all >>>>> other cases. >>>>>>>> This may also make it easier for early implementations of >>>>> the draft >>>>>>>> as then they can limit code changes from the (-03) rev to >>>>> only ODUflex LSPs. >>>>>>>> >>>>>>>> Just to be clear, I'm really just *asking* about this. >> As I said >>>>>>>> before, I'm open on specifics... >>>>>>>> >>>>>>>> Any thoughts/comments? Authors? Implementors? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lou >>>>>>>> >>>>>>>> >>>>>>>>> I will issue a new version tomorrow to capture all >> your comments. >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> >>>>>>>>> Fatai >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>> Sent: Wednesday, January 23, 2013 2:11 AM >>>>>>>>> To: Fatai Zhang >>>>>>>>> Cc: CCAMP; >>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>>> >>>>>>>>> Fatai, >>>>>>>>> >>>>>>>>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>>>>>>>> Hi Lou, >>>>>>>>>> >>>>>>>>>> You said: >>>>>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>>>>> value of this vs just carrying N? >>>>>>>>>> >>>>>>>>>> [Fatai] The original way (in version 04&05) is putting >>>>> (N* Nominal >>>>>>>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that >>>>>>>>>> we can generalize to just use one single "Bit_Rate" field to >>>>>>>>>> carry IEEE float number for both cases, it seems that you >>>>> don't agree on >>>>>>>>>> this value, :-) >>>>>>>>> >>>>>>>>> I've seen differences in calculated floating point values from >>>>>>>>> different implementations, so I just want to ensure that >>>>> such cases >>>>>>>>> are avoided. >>>>>>>>> I'm open to specific solutions and certainly will >> deffer on the >>>>>>>>> specifics assuming there is no opportunity for >>>>>>>>> misinterpretation/interop issues. I don't think the >>>>> original passed >>>>>>>>> this threshold, i.e.,: >>>>>>>>> >>>>>>>>> N = Ceiling of >>>>>>>>> >>>>>>>>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate >>>>>>>>> tolerance) >>>>>>>>> >>>>>>>>> ----------------------------------------------------------- >>>>> ---------- >>>>>>>>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate >>>>> tolerance) >>>>>>>>> >>>>>>>>>> . Therefore, I (was) am saying that I am going to accept your >>>>>>>>>> suggestion to carry N for ODUflex(GFP). We are >>>>> discussing where to >>>>>>>>>> put N for ODUflex(GFP). >>>>>>>>>> >>>>>>>>> >>>>>>>>>> You said: >>>>>>>>>>> bits in the control plane are generally cheap, IMO it's >>>>> better to >>>>>>>>>>> have simpler encoding than to optimize every bit (or >> 8 in this >>>>>>>>>>> case). >>>>>>>>>> >>>>>>>>>> [Fatai] OK, I will add a new field (to occupy the reserved >>>>>>>>>> bits) to carry N. >>>>>>>>> >>>>>>>>> As you see fit. >>>>>>>>> >>>>>>>>> Just to clarify my understanding, ODUflex and Virtual >>>>> concatenation >>>>>>>>> can never be combined for the same signal type/level, right? >>>>>>>>> (Although an ODUflex client signal could be carried over >>>>> a virtual >>>>>>>>> concatenated ODUk). Is this correct or did I miss >> something in >>>>>>>>> G709? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Lou >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best Regards >>>>>>>>>> >>>>>>>>>> Fatai >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>>> Sent: Friday, January 18, 2013 1:42 AM >>>>>>>>>> To: Fatai Zhang >>>>>>>>>> Cc: CCAMP; >>>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>>>>>>>> Hi Lou, >>>>>>>>>>> >>>>>>>>>>> To avoid misunderstanding, I would like to clarify >> more on the >>>>>>>>>>> following point. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> It is better to have consistent format and the same >>>>>>>>>>>>>>> meaning of one >>>>>>>>>> field for both ODUflex(CBR) and GFP. This is why we have >>>>>>>>>> section >>>>>>>>>> 5.1 >>>>>>>>>> &5.2 to describe the complex stuff. >>>>>>>>>>>>>> I actually wasn't suggesting that N be carried in >>>>> the bit rate >>>>>>>>>>>>>> field. >>>>>>>>>>>>>> The bit rate field can either be set as described or to >>>>>>>>>>>>>> zero (i.e., ignored). At the time, I was thinking about >>>>> carrying N >>>>>>>>>>>>>> in the reserved field. But perhaps the right place >>>>> is MT, if >>>>>>>>>>>>>> my understanding is right (would always be 1 >>>>> otherwise). I'm >>>>>>>>>>>>>> open to either... >>>>>>>>>>>>>> >>>>>>>>>>>>> [Fatai] Why not just use "bit rate"field to carry >>>>> "N"because "N" >>>>>>>>>>>>> implies bit rate? I am OK if you like to use a new >>>>> filed (like >>>>>>>>>>>>> "TS >>>>>>>>>>>>> Number") to occupy the reserved field even though >>>>> that I prefer >>>>>>>>>>>>> the original approach (ie., use "bit rate"field >> to carry "N"). >>>>>>>>>>>> >>>>>>>>>>>> Are you proposing dropping carrying bit rates >>>>> represented as an >>>>>>>>>>>> IEEE floating point and just carrying N for ODUflex? >>>>> This seems >>>>>>>>>>>> workable to me, but we should ensure that there are no >>>>>>>>>>>> significant objections. >>>>>>>>>>> >>>>>>>>>>> [Fatai] There are two usages for " Bit_Rate " field as >>>>> described >>>>>>>>>>> in the lines 287-310. >>>>>>>>>>> >>>>>>>>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates >>>>> the nominal >>>>>>>>>>> bit >>>>>>>>>>> rate of ODUflex(CBR) expressed in bytes per second, >>>>> encoded as a >>>>>>>>>>> 32-bit IEEE single precision floating-point number. >> For this >>>>>>>>>>> case, we MUST use 32-bit IEEE floating point instead of >>>>>>>>>>> "N"(Please see more in section 5.1). >>>>>>>>>> >>>>>>>>>> I guess you really still need (to be based on) the client >>>>>>>>>> signal rate at the edges. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (2) For ODUflex(GFP), we can change the text (the >>>>> lines from 305 >>>>>>>>>>> to >>>>>>>>>>> 310) based on your suggestion, ie., the Bit_Rate field >>>>> is used to >>>>>>>>>>> carry "N"to indicate the nominal bit rate of the >> ODUflex(GFP). >>>>>>>>>> >>>>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>>>> value of this vs just carrying N? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Therefore, I am proposing using one single filed >> ("Bit_Rate ") >>>>>>>>>>> for these two cases, in this way, we can leave the "Reserved" >>>>>>>>>>> bits for future. >>>>>>>>>> >>>>>>>>>> bits in the control plane are generally cheap, IMO it's >>>>> better to >>>>>>>>>> have simpler encoding than to optimize every bit (or >> 8 in this >>>>>>>>>> case). >>>>>>>>>> >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hope we are now at the same page. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best Regards >>>>>>>>>>> >>>>>>>>>>> Fatai >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > From swallow@cisco.com Tue Jan 29 11:08:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDAF21F87D7 for ; Tue, 29 Jan 2013 11:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 pMFdETMgtX02 for ; Tue, 29 Jan 2013 11:08:25 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C2FBA21F87CC for ; Tue, 29 Jan 2013 11:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3288; q=dns/txt; s=iport; t=1359486505; x=1360696105; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aF5ey2LnqBEXYS04XDnZnnFPor5rHylzfp01VR22JA4=; b=Qq4GFp84s/dH7pX7f3N8eHRSQVxe5RRF9/dJDGi7M0IAUAVH59VCND7k i2QeDOkUyVxM0qDdogfDISxvRM1OfjzVHXEn0LJP8URJZvb/BgEczRxb3 12krepw8SX7mFtT5AB0H7i+3ZFhBYkk9xuaCUOhgUhKRTgf1CUS+K9WW1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHAdCFGtJXHB/2dsb2JhbABEgki8GxZzgh8BAQQBAQFrCxACAQgEHh0HJwsUEQEBBA4FCIgJDLEakDMEjQ6DGmEDpliCd4FvNQ X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208,217";a="170052740" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jan 2013 19:08:24 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0TJ8OxS028941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 19:08:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 13:08:24 -0600 From: "George Swallow (swallow)" To: "BRUNGARD, DEBORAH A" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: Ac36Y0THF366bQJXRBinToGRQUxfKQEIwfyA Date: Tue, 29 Jan 2013 19:08:23 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0F723897@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.36.55] Content-Type: multipart/alternative; boundary="_000_2FE467D3673DCE409A84D67EC2F607BB0F723897xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 19:08:26 -0000 --_000_2FE467D3673DCE409A84D67EC2F607BB0F723897xmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes/support (as co-author) George On Jan 24, 2013, at 1:47 PM, "BRUNGARD, DEBORAH A" > wrote: All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g =93yes/support=94 or =93no/do not support=94. If indicating no, please st= ate your technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR =93still being documen= ted=94. Thanks, Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_2FE467D3673DCE409A84D67EC2F607BB0F723897xmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5F0E69969B99D64A9A9D3C569EEF6BF3@cisco.com> Content-Transfer-Encoding: quoted-printable Yes/support (as co-author)

George

On Jan 24, 2013, at 1:47 PM, "BRUNGARD, DEBORAH A" <db3546@att.com>
 wrote:

All,
 
This is start a two week poll on making draft-ali-ccamp-te-metric-reco= rding-03 a ccamp working group document. Please send email to the list indi= cating =93yes/support=94 or =93no/do not support=94. If indicating no, plea= se state your technical reservations with the document.
 
The poll ends Thursday, Feb. 7th.
 
Note, as stated by some of the authors, there is IPR =93still being do= cumented=94.
 
Thanks,
Deborah and Lou
 
 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.or= g/mailman/listinfo/ccamp

--_000_2FE467D3673DCE409A84D67EC2F607BB0F723897xmbrcdx10ciscoc_-- From swallow@cisco.com Tue Jan 29 11:09:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31F821F8820 for ; Tue, 29 Jan 2013 11:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 laYaXzKQSg9N for ; Tue, 29 Jan 2013 11:09:44 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CDBBB21F880B for ; Tue, 29 Jan 2013 11:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8995; q=dns/txt; s=iport; t=1359486583; x=1360696183; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Sk6v553jRI8iYEXb94KNeWX63UgO4ZPsfWx7xqg9F+8=; b=E5RVJcOtPZwsqgie2XfUfstObqyHkPMnjw5tZJj7xly+6KL14JMLEM7d LcfomJOShe45UY6OVim2Gf3E3iNXHBbXDPcn2h3ETOXRyRr20Zsv82iJH 0w29jyCcxCNRkQ7pq5CtznQjgl/wRSqLszKPyBhD5UoGFp+M+Usmdk49N 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAAodCFGtJV2d/2dsb2JhbABEgkiyewGJHhZzgh4BAQEEAQEBawsQAgEIEQQBAQsdBycLFAkIAQEEDgUIiAkMsRqQNY0OgxphA6ZYgneBbzU X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208,217";a="170023208" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jan 2013 19:09:43 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0TJ9hx5020843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 19:09:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 13:09:43 -0600 From: "George Swallow (swallow)" To: "BRUNGARD, DEBORAH A" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: Ac36YpzyB19srrPaSouArquCC8tVHQAAKy+AAQjMYoA= Date: Tue, 29 Jan 2013 19:09:43 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0F7238B5@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.36.55] Content-Type: multipart/alternative; boundary="_000_2FE467D3673DCE409A84D67EC2F607BB0F7238B5xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 19:09:44 -0000 --_000_2FE467D3673DCE409A84D67EC2F607BB0F7238B5xmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes/support (as co-author) George On Jan 24, 2013, at 1:51 PM, "BRUNGARD, DEBORAH A" > wrote: Sorry =96 it=92s Feb. 7th (my mind is too focused on Super Bowl weekend)- From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Thursday, January 24, 2013 1:43 PM To: ccamp@ietf.org Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG d= ocument ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = =93yes/support=94 or =93no/do not support=94. If indicating no, please stat= e your technical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_2FE467D3673DCE409A84D67EC2F607BB0F7238B5xmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <357BEC423E5B4542B994C9F2EE67FA04@cisco.com> Content-Transfer-Encoding: quoted-printable Yes/support (as co-author)

George

On Jan 24, 2013, at 1:51 PM, "BRUNGARD, DEBORAH A" <db3546@att.com>
 wrote:

Sorry =96 it=92s Feb. 7th (my mind is too focused on Super Bowl weekend= )-
 
From:=  = ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, = DEBORAH A
Sent: Thursday, Ja= nuary 24, 2013 1:43 PM
To: c= camp@ietf.org
Subject: [CCAMP] P= oll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document=
 

***Security Advisory: This Message Originated Outside of = AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

All,
 <= o:p>
This is= start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-02 a cca= mp working group document. Please send email to the list indicating =93yes/= support=94 or =93no/do not support=94. If indicating no, please state your technical reservations with the document.=
 <= o:p>
The pol= l ends Thursday, January 31st.
 <= o:p>
Note, a= s stated by some of the authors, IPR has been disclosed in compliance with = IETF IPR rules.
 <= o:p>
Thanks,=
Deborah= and Lou
 <= o:p>
 <= o:p>
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

--_000_2FE467D3673DCE409A84D67EC2F607BB0F7238B5xmbrcdx10ciscoc_-- From fred.gruman@us.fujitsu.com Tue Jan 29 12:05:02 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605EB21F8992 for ; Tue, 29 Jan 2013 12:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8, 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 MsQu-wJqtbZ4 for ; Tue, 29 Jan 2013 12:04:54 -0800 (PST) Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) by ietfa.amsl.com (Postfix) with ESMTP id 983B021F8955 for ; Tue, 29 Jan 2013 12:04:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,561,1355119200"; d="scan'208";a="26977007" Received: from rchexhcp1.fnc.net.local ([168.127.134.75]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 29 Jan 2013 14:04:54 -0600 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.98]) by RCHEXHCP1.fnc.net.local ([168.127.134.75]) with mapi id 14.02.0298.004; Tue, 29 Jan 2013 14:04:54 -0600 From: "Gruman, Fred" To: Lou Berger Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZXB3/s+GYEYvka9gmYAFxeuf5hglFOAgAACTfCAAHTEgP//sBng Date: Tue, 29 Jan 2013 20:04:53 +0000 Message-ID: <5DF87403A81B0C43AF3EB1626511B2923C33153D@RCHEXMBP1.fnc.net.local> References: <5106DED0.3090008@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33126F@RCHEXMBP1.fnc.net.local> <51081917.3080601@labn.net> In-Reply-To: <51081917.3080601@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19598.001 x-tm-as-result: No--61.472100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 20:05:02 -0000 SGkgTG91LA0KDQpKdXN0IHRvIGNvbmZpcm0sIHlvdXIgb3B0aW9uIDIgd2hlcmUgeW91IHN0YXRl ICJ1c2UgYSBuZXcgQy10eXBlIGZvciBPVE4tVERNIGxhYmVscyIsIGl0IHdhcyBub3QgdGhlIGlu dGVudCB0byBoYXZlIGEgbmV3IGMtdHlwZSBmb3IgdGhlIGxhYmVsIGl0c2VsZiwgYnV0IGEgbmV3 IGMtdHlwZSBmb3IgdGhlIHNlbmRlci10c3BlYy9mbG93c3BlYyAodHJhZmZpYyBwYXJhbWV0ZXJz KS4gSWYgc28sIEkgbWlzdW5kZXJzdG9vZCB0aGUgb3B0aW9uIGFuZCBub3cgdW5kZXJzdGFuZCB0 aGUgcHJvcG9zYWxzLg0KDQpUaGFua3MsDQpGcmVkDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDI5LCAyMDEzIDEyOjQ3IFBNDQpUbzogR3J1bWFuLCBGcmVkDQpDYzog WmFmYXIgQWxpICh6YWxpKTsgQ0NBTVANClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFBvbGwgb24gT0RV RmxleC1yZWxhdGVkIGVuY29kaW5nICh3YXM6IFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbiBkcmFm dC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQpDQoNCkZyZWQsDQoJVGhhbmtz IGZvciB0aGUgaW5wdXQuDQoNCk9uIDEvMjkvMjAxMyAxMjo1NCBQTSwgR3J1bWFuLCBGcmVkIHdy b3RlOg0KPiBIaSBMb3UsDQo+IA0KPiBJIGFtIG5vdCBjbGVhciBvbiBvcHRpb24gMiBhcyB3aGVu IEkgbG9vayBpbnRvIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNSwg dGhlIElBTkEgc2VjdGlvbiBzaG93cyB0aGUgYy10eXBlIGZvciB0aGUgR0VORVJBTElaRV9MQUJF TCBkZWZpbmVkIGluIFJGQyAzNDczLCBub3QgYSBuZXcgYy10eXBlLg0KPiANCj4gT1ROLVRETSBH ZW5lcmFsaXplZCBMYWJlbCBPYmplY3Q6IA0KPiANCj4gICAgICAgIG8gT1ROLVRETSBHZW5lcmFs aXplZCBMYWJlbCBPYmplY3Q6IENsYXNzID0gMTYsIEMtVHlwZSA9IDIgKHNlZSANCj4gICAgICAg ICAgU2VjdGlvbiA1LjEpIA0KPg0KDQpJIGRpZG4ndCBub3RpY2UgdGhhdCBpbmNvbnNpc3RlbmN5 LiAgUGVyDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLWdtcGxz LXNpZ25hbGluZy1nNzA5djMtMDUjc2VjdGlvbi01Og0KIFRoZSB0cmFmZmljIHBhcmFtZXRlcnMg Zm9yIE9UTi1URE0gY2FwYWJsZSBTd2l0Y2hpbmcgVHlwZSBhcmUgY2FycmllZA0KIGluIHRoZSBP VE4tVERNIFNFTkRFUl9UU1BFQyBhbmQgRkxPV1NQRUMgb2JqZWN0cy4gVGhlIG9iamVjdHMgaGF2 ZQ0KIHRoZSBmb2xsb3dpbmcgY2xhc3MgYW5kIHR5cGU6DQoNCiAgICAtICBPVE4tVERNIFNFTkRF Ul9UU1BFQyBPYmplY3Q6IENsYXNzID0gMTIsIEMtVHlwZSA9IDcgKFRCQSkNCiAgICAtICBPVE4t VERNIEZMT1dTUEVDIE9iamVjdDogQ2xhc3MgPSA5LCBDLVR5cGUgPSA3IChUQkEpDQoNCkxvdQ0K DQo+IEknbSBvcGVuIHRvIGVpdGhlciBjYXJyeWluZyBPRFVmbGV4KEdGUCkgYmFuZHdpZHRoIGFz IGZsb2F0aW5nLXBvaW50IG9yIGludGVnZXIgTiwgYnV0IHdvdWxkIGxpa2UgdG8gc2VlIGNvbnNp c3RlbmN5IGJldHdlZW4gcm91dGluZyBhbmQgc2lnbmFsaW5nIGRvY3VtZW50cy4NCj4gDQo+IA0K PiBSZWdhcmRzLA0KPiBGcmVkDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFphZmFyIEFsaSAoemFsaSkNCj4gU2VudDogVHVlc2RheSwgSmFudWFy eSAyOSwgMjAxMyAxMDo0MSBBTQ0KPiBUbzogTG91IEJlcmdlcjsgQ0NBTVANCj4gU3ViamVjdDog UmU6IFtDQ0FNUF0gUG9sbCBvbiBPRFVGbGV4LXJlbGF0ZWQgZW5jb2RpbmcgKHdhczogV0cgTGFz dCBDYWxsIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2 My0wNCkNCj4gDQo+IEhpIExvdSwgQy1jYW1wZXJzOiANCj4gDQo+IEkgd291bGQgcGljayBPcHRp b24gMjsgaXQncyBjbGVhbmVyIGFuZCAgYWRkcmVzc2VzIHRoZSBpc3N1ZSByZWxhdGVkIHRvDQo+ IG92ZXJsb2FkaW5nIHRoZSBzYW1lIGMtdHlwZS4NCj4gDQo+IFRoYW5rcw0KPiANCj4gUmVnYXJk c+KAplphZmFyDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog ImxiZXJnZXJAbGFibi5uZXQiIDxsYmVyZ2VyQGxhYm4ubmV0Pg0KPiBEYXRlOiBNb25kYXksIEph bnVhcnkgMjgsIDIwMTMgMzoyNSBQTQ0KPiBUbzogImNjYW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0 Zi5vcmc+DQo+IFN1YmplY3Q6IFtDQ0FNUF0gUG9sbCBvbiBPRFVGbGV4LXJlbGF0ZWQgZW5jb2Rp bmcgKHdhczogV0cgTGFzdCBDYWxsDQo+IGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtc2lnbmFsaW5nLWc3MDl2My0wNCkNCj4gDQo+PiBBbGwsDQo+PiAJV2Ugd291bGQgbGlrZSB0 byB0cnkgdG8gY2xvc2UgdGhlIGRpc2N1c3Npb24gb24gdGhlIEcuNzA5DQo+PiBkcmFmdHMgc28g dGhhdCB3ZSBjYW4gbW92ZSByYXBpZGx5IHRvd2FyZHMgcHVibGljYXRpb24gcmVxdWVzdC4gIFRo ZQ0KPj4gZGlzY3Vzc2lvbiBvZiAob25lIG9mIG15KSBMQyBjb21tZW50cyBoYXMgcmVzdWx0ZWQg aW4gc2V2ZXJhbCBvcHRpb25zDQo+PiBmb3IgdGhlIHNpZ25hbGluZyBPRFUtcmVsYXRlZCB0cmFm ZmljIHBhcmFtZXRlcnMsIGFuZCB0aGUgcG9pbnQgaGFzDQo+PiBiZWVuIHJhaXNlZCB0aGF0IHJl YWxpZ25pbmcgcm91dGluZyB3aXRoIHNpZ25hbGluZyBzaG91bGQgYmUgZGlzY3Vzc2VkLg0KPj4N Cj4+IFBsZWFzZSBrZWVwIGluIG1pbmQgdGhhdCB0aGUgb2JqZWN0aXZlIG9mIGFueSBQUyBpcyBp bnRlcm9wZXJhYmlsaXR5LA0KPj4gYW5kIHRoYXQgdGhlcmUgbWF5IGJlIGVhcmx5IGltcGxlbWVu dGF0aW9ucyB0aGF0IG1hdGNoIGc3MDl2My0wNC4NCj4+DQo+PiBUaGUgYmFzaWMgcXVlc3Rpb24g aXMgb25lIG9mIGlmIE4sIHRoZSBudW1iZXIgb2YgdGltZSBzbG90cyBuZWVkZWQgdG8NCj4+IHN1 cHBvcnQgYSBPRFVmbGV4KEdGUCkgc2lnbmFsLCBzaG91bGQgYmUgY2FycmllZCBhcyBhIGNhbGN1 bGF0ZWQgSUVFRQ0KPj4gZmxvYXRpbmcgcG9pbnQgbnVtYmVyIG9yIGRpcmVjdGx5LiAgIE9wdGlv bnMgMSBhbmQgMiBiZWxvdyByZWZsZWN0IHRoZQ0KPj4gZm9ybWVyLCBvcHRpb25zIDMgYW5kIDQg bWF0Y2ggdGhlIGxhdHRlci4gIEl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IG9ubHkNCj4+IG9wdGlv bnMgMSBhbmQgMiBhcmUgcHJvcG9zZWQgZm9yIE9EVWZsZXgoR0ZQKSwgaS5lLiwgTiBtdXN0IGJl DQo+PiBjYWxjdWxhdGVkIGZvciBPRFVmbGV4KENCUikgc2lnbmFsIHR5cGVzIHdpdGggYWxsIG9w dGlvbnMuDQo+Pg0KPj4gUGxlYXNlIHN0YXRlIHlvdXIgc3VwcG9ydCBmb3Igb25lIHRoZSBvcHRp b25zIGFuZCwgaWYgeW91IHdpc2gsIHRoZQ0KPj4ganVzdGlmaWNhdGlvbiBmb3IgeW91ciBwb3Np dGlvbjoNCj4+DQo+PiAxKSBGb2xsb3cgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmct ZzcwOXYzLTA0DQo+PiAgIGkuZS4sIHJlZGVmaW5lIFtSRkM0MzI4XSBUcmFmZmljIFBhcmFtZXRl cnMgYy10eXBlIHdoZW4gdXNlZCB3aXRoDQo+PiAgIE9UTi1URE0gbGFiZWxzLiBPRFVmbGV4KEdG UCkgbnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cyAoTikgaXMNCj4+ICAgZW5jb2RlZCBhczoNCj4+ DQo+PiAgIC4uLiB0aGUgQml0X1JhdGUgZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSBNVVNUDQo+PiAg IGVxdWFsIHRvIG9uZSBvZiB0aGUgODAgdmFsdWVzIGxpc3RlZCBiZWxvdzoNCj4+DQo+PiAgICAg ICAxICogT0RVMi50czsgMiAqIE9EVTIudHM7IC4uLjsgOCAqIE9EVTIudHM7DQo+PiAgICAgICA5 ICogT0RVMy50czsgMTAgKiBPRFUzLnRzLCAuLi47IDMyICogT0RVMy50czsNCj4+ICAgICAgIDMz ICogT0RVNC50czsgMzQgKiBPRFU0LnRzOyAuLi47IDgwICogT0RVNC50cy4NCj4+DQo+PiAyKSBG b2xsb3cgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA1DQo+PiAgIGku ZS4sIHVzZSBhIG5ldyBDLXR5cGUgZm9yIE9UTi1URE0gbGFiZWxzLiAgRW5jb2RpbmcgZGV0YWls cw0KPj4gICB1bmNoYW5nZWQgZnJvbSBnNzA5djMtMDQuDQo+PiAgIChUaGlzIG9wdGlvbiBhZGRy ZXNzZXMgdGhlIGlzc3VlIG9mIHRoZSBzYW1lIGMtdHlwZSBuZWVkaW5nIHRvDQo+PiAgICBiZSBw YXJzZWQgYmFzZWQgb24gbGFiZWwvc3dpdGNoaW5nIHR5cGUuKQ0KPj4NCj4+IDMpIEZvbGxvdyBk cmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDYNCj4+ICAgaS5lLiwgIHVz ZSBhIG5ldyBDLXR5cGUgZm9yIE9UTi1URE0gbGFiZWxzLiBOIGlzIGRpcmVjdGx5IGNhcnJpZWQN Cj4+ICAgZm9yIE9EVWZsZXgoR0ZQKSBvbmx5Lg0KPj4NCj4+IDQpIERpc2N1c3NlZCwgYnV0IG5v dCBpbiBhbnkgZHJhZnQNCj4+ICAgVXNlIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5n LWc3MDl2My0wNCBlbmNvZGluZyBmb3IgYWxsDQo+PiAgIGJ1dCBPRFVmbGV4KEdGUCksIGFuZCBk ZWZpbmUgbmV3IE9EVWZsZXgoR0ZQKSBzcGVjaWZpYyBUcmFmZmljDQo+PiAgIFBhcmFtZXRlcnMg YmFzZWQgb24gZzcwOXYzLTA2LCBwcmVzdW1hYmx5IHdpdGggdW51c2VkIGZpZWxkcw0KPj4gICBy ZW1vdmVkLg0KPj4gICAoVGhpcyBhbHNvIGFkZHJlc3NlcyB0aGUgaXNzdWUgb2YgdGhlIHNhbWUg Yy10eXBlIG5lZWRpbmcgdG8gYmUNCj4+ICAgIHBhcnNlZCBiYXNlZCBvbiBsYWJlbCB0eXBlLCBi dXQgbWVhbnMgdGhlcmUgYXJlIGRpZmZlcmVudCB0eXBlcw0KPj4gICAgYmFzZWQgb24gc2lnbmFs IHR5cGUuKQ0KPj4NCj4+IE9wdGlvbiAxIGFuZCAyIGRvIG5vdCBpbXBseSBhbnkgY2hhbmdlcyB0 byByb3V0aW5nLCB3aGlsZSBvcHRpb25zIDMgYW5kDQo+PiA0IG1heS4gIFJvdXRpbmcgaW1wbGlj YXRpb25zIHdpbGwgYmUgZGlzY3Vzc2VkIGJhc2VkIG9uIHRoZSByZXN1bHRzIG9mDQo+PiB0aGlz IHBvbGwsIGFuZCBvbmx5IGlmIHRoZXJlIGlzIGNvbnNlbnN1cyB0byBzdXBwb3J0IHBvc2l0aW9u cyAzIG9yIDQuDQo+Pg0KPj4gV2UgaG9wZSB0byBtYWtlIGEgY29uc2Vuc3VzIGNhbGwgYnkgdGhl IGVuZCBvZiB0aGUgd2VlaywgYnV0IHdpbGwNCj4+IGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFz IG5lZWRlZC4NCj4+DQo+PiBNdWNoIHRoYW5rcywNCj4+IExvdSAoYW5kIERlYm9yYWgpDQo+Pg0K Pj4gT24gMS8yOC8yMDEzIDU6MDggQU0sIERhbmllbGUgQ2VjY2FyZWxsaSB3cm90ZToNCj4+PiAg QWxsLA0KPj4+DQo+Pj4gSSB0aGluayB0aGUgY2hhbmdlcyBwcm9wb3NlZCBhcmUgbWVhbmluZ2Z1 bCBhbmQgd291bGQgc3VwcG9ydCB0aGVtIGluDQo+Pj4gYW4gaW5kaXZpZHVhbCBvciBlYXJseSBX RyBkcmFmdCwgYnV0IHRoZXkgZG9uJ3Qgc2VlbSB0byBwcm92aWRlDQo+Pj4gc2lnbmlmaWNhdGl2 ZSBhZHZhbnRhZ2VzIHRvIHJpc2sgaW50ZXJ3b3JraW5nIGlzc3VlcyB3aXRoIGVhcmx5DQo+Pj4g aW1wbGVtZW50YXRpb25zLg0KPj4+IE1vcmVvdmVyIHRoZSBjaGFuZ2VzIGRvbid0IGFsbG93IHVz IGdldHRpbmcgdG90YWxseSByaWQgb2Ygb2YgdGhlDQo+Pj4gYml0X3JhdGUgZmllbGQgYXMgaXQg aXMgc3RpbGwgbmVlZGVkIGZvciBPRFVmbGV4IChDQlIpLg0KPj4+DQo+Pj4gTXkgMmMNCj4+PiBE YW5pZWxlDQo+Pj4NCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBG cm9tOiBaYWZhciBBbGkgKHphbGkpIFttYWlsdG86emFsaUBjaXNjby5jb21dDQo+Pj4+IFNlbnQ6 IGx1bmVkw6wgMjggZ2VubmFpbyAyMDEzIDQuNDcNCj4+Pj4gVG86IExvdSBCZXJnZXINCj4+Pj4g Q2M6IEdydW1hbiwgRnJlZDsgRmF0YWkgWmhhbmc7IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVA7 DQo+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRm Lm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24N Cj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+DQo+ Pj4+IEhpIExvdS0gDQo+Pj4+DQo+Pj4+IFBsZWFzZSBzZWUgaW4tbGluZS4NCj4+Pj4NCj4+Pj4g VGhhbmtzDQo+Pj4+DQo+Pj4+IFJlZ2FyZHMuLi5aYWZhcg0KPj4+Pg0KPj4+PiBPbiAxLzI3LzEz IDk6NDYgUE0sICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+Pj4+DQo+ Pj4+PiBaYWZhciwNCj4+Pj4+IAlJcyB5b3VyIGNvbW1lbnQgd2l0aCByZXNwZWN0IHRvIGp1c3Qg cm91dGluZyBvciBib3RoDQo+Pj4+IHNpZ25hbGluZyBhbmQgDQo+Pj4+PiByb3V0aW5nPw0KPj4+ Pg0KPj4+PiBCb3RoLCBpbmNsdWRpbmcgY29uc2lzdGVuY3kgYmV0d2VlbiBzaWduYWxpbmcgYW5k IHJvdXRpbmcgYXR0cmlidXRlcy4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBBbHNvLCB3aGVuIHlvdSBz YXkgImltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiBkcmFmdCB2ZXJzaW9ucyIsDQo+Pj4+IGRvIHRo ZXNlIA0KPj4+Pj4gaW1wbGVtZW50YXRpb25zIGluY2x1ZGUgc3VwcG9ydCBmb3IgT0RVZmxleD8g IChXaGljaCBoYXMgcmVhbGx5IGJlZW4NCj4+Pj4+IHRoZSBmb2N1cyBvZiB0aGUgZGlzY3Vzc2lv bi4pDQo+Pj4+DQo+Pj4+IFllcywgSSB3YXMgcmVmZXJyaW5nIHRvIE9EVUZsZXguIEFzIHlvdSBr bm93LCBmaXhlZCBPRFUgaXMNCj4+Pj4gc2lnbmFsZWQgdmlhIGxldmVsICgwIEJXKSBzbyBpdHMg bm90IGFuIGlzc3VlLg0KPj4+Pg0KPj4+Pj4NCj4+Pj4+IEJUVyBJIHRvb2sgRnJlZCdzIGNvbW1l bnRzIGFzIHJlbGF0ZWQgdG8ganVzdCB0aGUgbmV3DQo+Pj4+IE9UTi1zcGVjaWZpYyBJU0NEDQo+ Pj4+PiBkZWZpbml0aW9ucyAoc2VjdGlvbiA0LjEuMiBvZiBvc3BmLWc3MDl2My0wNSwgaW4gcGFy dGljdWxhcikuICBOb3RlDQo+Pj4+PiB0aGF0IHNlY3Rpb24gNC4xLjEgYWxyZWFkeSBjYXJyaWVz IE4gKG51bWJlciBvZiBPRFVzKSBub3QNCj4+Pj4gSUVFRSBmbG9hdGluZyANCj4+Pj4+IHBvaW50 IHJlcHJlc2VudGF0aW9ucyBvZiBhdmFpbGFibGUgYmFuZHdpZHRoLg0KPj4+Pg0KPj4+PiBXaGF0 IEkgbWVhbnQgaXMgVW5yZXNlcnZlZCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgeCBhbmQgTWF4IExT UA0KPj4+PiBCYW5kd2lkdGggYXQgcHJpb3JpdHkgeC4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBNdWNo IHRoYW5rcywNCj4+Pj4+IExvdQ0KPj4+Pj4NCj4+Pj4+IE9uIDEvMjcvMjAxMyA3OjQ2IFBNLCBa YWZhciBBbGkgKHphbGkpIHdyb3RlOg0KPj4+Pj4+IEFsbC0NCj4+Pj4+Pg0KPj4+Pj4+IFRoaXMg aW1wYWN0cyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZHJhZnQgdmVyc2lvbnMg KGFuZA0KPj4+Pj4+IGhlbmNlIGludGVyb3Agd2l0aCB0aGVzZSBpbXBsZW1lbnRhdGlvbnMgbW92 aW5nIGZvcndhcmQpLg0KPj4+PiBJTU8gdGhpcyBpcyANCj4+Pj4+PiBhIGJpZ2dlciBjaGFuZ2Ug Zm9yIHVzIHRvIGFzc3VtZSBhdCB0aGUgbGFzdCBjYWxsIHN0YWdlLg0KPj4+PiBGdXJ0aGVybW9y ZSANCj4+Pj4+PiB3ZSBoYXZlIGJlZW4gdXNpbmcgSUVFRSBmbG9hdGluZyBwb2ludCBmb3JtYXQg Zm9yIFVucmVzZXJ2ZWQNCj4+Pj4+PiBCYW5kd2lkdGgvIE1heCBMU1AgQlcgaW4gSUVFRSBmbG9h dGluZyBwb2ludCBmb3JtYXQgZm9yIG90aGVyDQo+Pj4+Pj4gdGVjaG5vbG9naWVzLiBPdmVyYWxs LCBJIHRoaW5rIHRoaXMgY2hhbmdlIHN1ZmZlcnMgZnJvbSB0aGUNCj4+Pj4gImxhdyBvZiBkaW1p bmlzaGluZyByZXR1cm5zIi4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcw0KPj4+Pj4+DQo+Pj4+Pj4g UmVnYXJkcyDFoCBaYWZhcg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBPbiAxLzI3LzEzIDEwOjI4 IEFNLCAiR3J1bWFuLCBGcmVkIg0KPj4+PiA8ZnJlZC5ncnVtYW5AdXMuZnVqaXRzdS5jb20+IHdy b3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IEhpIExvdSwgRmF0YWksIERhbmllbGUsDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IEkgdW5kZXJzdGFuZCB0aGUgbGF0ZXN0IGNoYW5nZSB0byB0aGUgd2F5IGJhbmR3aWR0 aCBpcw0KPj4+PiBzaWduYWxlZCBmb3IgIA0KPj4+Pj4+PiBPRFVmbGV4KEdGUCksIGkuZS4sIHNp Z25hbGluZyB0aGUgbnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cw0KPj4+PiBOIGluc3RlYWQgDQo+ Pj4+Pj4+IG9mICB0aGUgYmFuZHdpZHRoIHJhdGUgaW4gYnBzLiAgSSBiZWxpZXZlIHRoYXQgdGhp cyBzaW1wbGlmaWVzIHRoZQ0KPj4+Pj4+PiBzaWduYWxpbmcgIGFuZCBpbnRlcm9wZXJhYmlsaXR5 IHNvIEknbSBpbiBhZ3JlZW1lbnQgd2l0aA0KPj4+PiB0aGlzIGNoYW5nZS4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gSG93ZXZlciwgaXQgc2VlbXMgd2UgYXJlIG5vdyBpbmNvbnNpc3RlbnQgYmV0d2VlbiBo b3cgd2UNCj4+Pj4gcmVwcmVzZW50ICANCj4+Pj4+Pj4gYmFuZHdpZHRoIGluIHJvdXRpbmcgYW5k IHNpZ25hbGluZyBmb3IgT0RVZmxleChHRlApLiAgUm91dGluZw0KPj4+Pj4+PiBhZHZlcnRpc2Vz ICB0aGUgYmFuZHdpZHRoIHVzaW5nIGEgZmxvYXRpbmcgcG9pbnQgcmVwcmVzZW50YXRpb24gb2YN Cj4+Pj4+Pj4gYmFuZHdpZHRoLCB3aGlsZSAgc2lnbmFsaW5nIGlzIHVzaW5nIHRoZSBudW1iZXIg b2YgdHJpYnV0YXJ5IHNsb3RzLg0KPj4+Pj4+PiBJdCBzZWVtcyB0aGUgc2FtZSAgYmVuZWZpdHMg d291bGQgYmUgb2J0YWluZWQgYnkNCj4+Pj4gYWR2ZXJ0aXNpbmcgdGhlIG1heA0KPj4+Pj4+PiBM U1AgYmFuZHdpZHRoIGFuZCAgdW5yZXNlcnZlZCBiYW5kd2lkdGggZm9yIE9EVWZsZXgoR0ZQKSBp bg0KPj4+PiB0ZXJtcyBvZiANCj4+Pj4+Pj4gdGhlIG51bWJlciBvZiB0cmlidXRhcnkgIHNsb3Rz Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBGcmVkDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+ Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+IEZyb206IGNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+Pj4+PiBC ZWhhbGYgT2YgIExvdSBCZXJnZXINCj4+Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIz LCAyMDEzIDk6MDggQU0NCj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4+IENjOiBDQ0FN UDsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3Jn DQo+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0K Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4+Pj4+ Pj4NCj4+Pj4+Pj4gRmF0YWksDQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uIDEvMjMvMjAxMyA2OjQ5IEFN LCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBGb3IgT0RVZmxleChDQlIpLCB0aGUgZm9ybXVsYSBpcyBmcm9tIFtHLjcwOS0yMDEyXSBhbmQg aXQNCj4+Pj4gaGFzIGJlZW4gDQo+Pj4+Pj4+PiBkaXNjdXNzZWQgYmVmb3JlLCBzbyBwbGVhc2Ug dHJ1c3QgdGhhdCB0aGVyZSBpcyBubw0KPj4+PiBvcHBvcnR1bml0eSBmb3INCj4+Pj4+Pj4+IG1p c2ludGVycHJldGF0aW9uLiAoTm90ZSB0aGF0IHRoZXJlIGFyZSB0d28gY2FzZXMsIG9uZSBpcw0K Pj4+Pj4+Pj4gT0RVZmxleChDQlIpIGFuZCBhbm90aGVyIG9uZSBpcyBPRFVmbGV4KEdGUCkpLg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IEluIGFkZHRpb24sIE9EVWZsZXggY2Fubm90IGJlIGNvbmNhdGVu YXRlZCBieSBbRy43MDktMjAxMl0uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoYW5rcyBmb3IgY29uZmly bWluZyBteSB1bmRlcnN0YW5kaW5nLiAgVGhpcyByYWlzZXMgdGhlDQo+Pj4+IHF1ZXN0aW9uIG9m IA0KPj4+Pj4+PiBpZiB0aGUgbmV3IHRyYWZmaWMgc2hvdWxkIGp1c3QgYXBwbHkgdG8gT0RVRmxl eD8gIENvcnJlY3QNCj4+Pj4gbWUgaWYgSSdtIA0KPj4+Pj4+PiB3cm9uZywgYnV0IEkgYmVsaWV2 ZSB0aGUgW1JGQzQzMjhdIGlzIHN1ZmZpY2llbnQgaW4gYWxsDQo+Pj4+IG90aGVyIGNhc2VzLiAg DQo+Pj4+Pj4+IFRoaXMgbWF5IGFsc28gbWFrZSBpdCBlYXNpZXIgZm9yIGVhcmx5IGltcGxlbWVu dGF0aW9ucyBvZg0KPj4+PiB0aGUgZHJhZnQgDQo+Pj4+Pj4+IGFzIHRoZW4gdGhleSBjYW4gbGlt aXQgY29kZSBjaGFuZ2VzIGZyb20gdGhlICgtMDMpIHJldiB0bw0KPj4+PiBvbmx5IE9EVWZsZXgg TFNQcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSnVzdCB0byBiZSBjbGVhciwgSSdtIHJlYWxseSBqdXN0 ICphc2tpbmcqIGFib3V0IHRoaXMuICBBcyBJIHNhaWQNCj4+Pj4+Pj4gYmVmb3JlLCBJJ20gb3Bl biBvbiBzcGVjaWZpY3MuLi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQW55IHRob3VnaHRzL2NvbW1lbnRz PyBBdXRob3JzPyAgSW1wbGVtZW50b3JzPw0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGFua3MsDQo+Pj4+ Pj4+IExvdQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gSSB3aWxsIGlzc3VlIGEgbmV3IHZl cnNpb24gdG9tb3Jyb3cgdG8gY2FwdHVyZSBhbGwgeW91ciBjb21tZW50cy4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRmF0YWkN Cj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4+Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPj4+ Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDEzIDI6MTEgQU0NCj4+Pj4+Pj4+ IFRvOiBGYXRhaSBaaGFuZw0KPj4+Pj4+Pj4gQ2M6IENDQU1QOyBkcmFmdC1pZXRmLWNjYW1wLWdt cGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+IFN1YmplY3Q6IFJl OiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+Pj4gZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRmF0YWks DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gMS8yMC8yMDEzIDk6NDMgUE0sIEZhdGFpIFpoYW5nIHdy b3RlOg0KPj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFlvdSBzYWlkOg0K Pj4+Pj4+Pj4+PiBidXQgeW91J3JlIHNheXMgZW5jb2RlZCBhcyAoTipOb21pbmFsIFJhdGUpIHJp Z2h0PyBXYXQncyB0aGUNCj4+Pj4+Pj4+Pj4gdmFsdWUgb2YgIHRoaXMgdnMganVzdCBjYXJyeWlu ZyBOPw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gW0ZhdGFpXSBUaGUgb3JpZ2luYWwgd2F5IChpbiB2 ZXJzaW9uIDA0JjA1KSBpcyBwdXR0aW5nDQo+Pj4+IChOKiBOb21pbmFsDQo+Pj4+Pj4+Pj4gUmF0 ZSkgaW4gIkJpdF9SYXRlIiBmaWVsZCBmb3IgT0RVZmxleChHRlApLCB0aGUgdmFsdWUgaXMgdGhh dCB3ZQ0KPj4+Pj4+Pj4+IGNhbiBnZW5lcmFsaXplIHRvIGp1c3QgdXNlIG9uZSBzaW5nbGUgIkJp dF9SYXRlIiBmaWVsZCB0byBjYXJyeQ0KPj4+Pj4+Pj4+IElFRUUgZmxvYXQgbnVtYmVyIGZvciBi b3RoIGNhc2VzLCBpdCBzZWVtcyB0aGF0IHlvdQ0KPj4+PiBkb24ndCBhZ3JlZSBvbiANCj4+Pj4+ Pj4+PiB0aGlzIHZhbHVlLCA6LSkNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJJ3ZlIHNlZW4gZGlmZmVy ZW5jZXMgaW4gY2FsY3VsYXRlZCBmbG9hdGluZyBwb2ludCB2YWx1ZXMgZnJvbQ0KPj4+Pj4+Pj4g ZGlmZmVyZW50ICBpbXBsZW1lbnRhdGlvbnMsIHNvIEkganVzdCB3YW50IHRvIGVuc3VyZSB0aGF0 DQo+Pj4+IHN1Y2ggY2FzZXMgDQo+Pj4+Pj4+PiBhcmUgYXZvaWRlZC4NCj4+Pj4+Pj4+IEknbSBv cGVuIHRvIHNwZWNpZmljIHNvbHV0aW9ucyBhbmQgY2VydGFpbmx5IHdpbGwgZGVmZmVyIG9uIHRo ZQ0KPj4+Pj4+Pj4gc3BlY2lmaWNzIGFzc3VtaW5nIHRoZXJlIGlzIG5vIG9wcG9ydHVuaXR5IGZv cg0KPj4+Pj4+Pj4gbWlzaW50ZXJwcmV0YXRpb24vaW50ZXJvcCAgaXNzdWVzLiBJIGRvbid0IHRo aW5rIHRoZQ0KPj4+PiBvcmlnaW5hbCBwYXNzZWQNCj4+Pj4+Pj4+IHRoaXMgdGhyZXNob2xkLCBp LmUuLDoNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAgICBOID0gQ2VpbGluZyBvZg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+ICAgIE9EVWZsZXgoQ0JSKSBub21pbmFsIGJpdCByYXRlICogKDEgKyBPRFVm bGV4KENCUikgYml0IHJhdGUNCj4+Pj4+Pj4+IHRvbGVyYW5jZSkNCj4+Pj4+Pj4+ICAgIA0KPj4+ Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+Pj4gLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4gICAgICAgIE9EVFVrLnRzIG5vbWlu YWwgYml0IHJhdGUgKiAoMSAtIEhPIE9QVWsgYml0IHJhdGUNCj4+Pj4gdG9sZXJhbmNlKQ0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+PiAuIFRoZXJlZm9yZSwgSSAod2FzKSBhbSBzYXlpbmcgdGhhdCBJIGFt IGdvaW5nIHRvIGFjY2VwdCB5b3VyDQo+Pj4+Pj4+Pj4gc3VnZ2VzdGlvbiB0byBjYXJyeSBOIGZv ciBPRFVmbGV4KEdGUCkuIFdlIGFyZQ0KPj4+PiBkaXNjdXNzaW5nIHdoZXJlIHRvDQo+Pj4+Pj4+ Pj4gcHV0IE4gZm9yIE9EVWZsZXgoR0ZQKS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ PiBZb3Ugc2FpZDoNCj4+Pj4+Pj4+Pj4gYml0cyBpbiB0aGUgY29udHJvbCBwbGFuZSBhcmUgZ2Vu ZXJhbGx5IGNoZWFwLCBJTU8gaXQncw0KPj4+PiBiZXR0ZXIgdG8gIA0KPj4+Pj4+Pj4+PiBoYXZl IHNpbXBsZXIgZW5jb2RpbmcgdGhhbiB0byBvcHRpbWl6ZSBldmVyeSBiaXQgKG9yIDggaW4gdGhp cw0KPj4+Pj4+Pj4+PiBjYXNlKS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFtGYXRhaV0gT0ssIEkg d2lsbCBhZGQgYSBuZXcgZmllbGQgKHRvIG9jY3VweSB0aGUgcmVzZXJ2ZWQgYml0cykNCj4+Pj4+ Pj4+PiB0byBjYXJyeSBOLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEFzIHlvdSBzZWUgZml0Lg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IEp1c3QgdG8gY2xhcmlmeSBteSB1bmRlcnN0YW5kaW5nLCBPRFVmbGV4 IGFuZCBWaXJ0dWFsDQo+Pj4+IGNvbmNhdGVuYXRpb24gDQo+Pj4+Pj4+PiBjYW4gIG5ldmVyIGJl IGNvbWJpbmVkIGZvciB0aGUgc2FtZSBzaWduYWwgdHlwZS9sZXZlbCwgcmlnaHQ/DQo+Pj4+Pj4+ PiAoQWx0aG91Z2ggYW4gIE9EVWZsZXggY2xpZW50IHNpZ25hbCBjb3VsZCBiZSBjYXJyaWVkIG92 ZXINCj4+Pj4gYSB2aXJ0dWFsIA0KPj4+Pj4+Pj4gY29uY2F0ZW5hdGVkICBPRFVrKS4gIElzIHRo aXMgY29ycmVjdCBvciBkaWQgSSBtaXNzIHNvbWV0aGluZyBpbg0KPj4+Pj4+Pj4gRzcwOT8NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+PiBMb3UNCj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBGYXRhaQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBs YWJuLm5ldF0NCj4+Pj4+Pj4+PiBTZW50OiBGcmlkYXksIEphbnVhcnkgMTgsIDIwMTMgMTo0MiBB TQ0KPj4+Pj4+Pj4+IFRvOiBGYXRhaSBaaGFuZw0KPj4+Pj4+Pj4+IENjOiBDQ0FNUDsgZHJhZnQt aWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+Pj4+ Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+Pj4+ Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gT24gMS8xNS8yMDEzIDEwOjE2IFBNLCBG YXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+Pj4+Pj4gSGkgTG91LA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+PiBUbyBhdm9pZCBtaXN1bmRlcnN0YW5kaW5nLCBJIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSBt b3JlIG9uIHRoZQ0KPj4+Pj4+Pj4+PiBmb2xsb3dpbmcgcG9pbnQuDQo+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBJdCBpcyBiZXR0ZXIgdG8gaGF2ZSBjb25zaXN0ZW50IGZv cm1hdCBhbmQgdGhlIHNhbWUgbWVhbmluZw0KPj4+Pj4+Pj4+Pj4+Pj4gb2Ygb25lDQo+Pj4+Pj4+ Pj4gZmllbGQgZm9yIGJvdGggT0RVZmxleChDQlIpIGFuZCBHRlAuIFRoaXMgaXMgd2h5IHdlIGhh dmUgc2VjdGlvbg0KPj4+Pj4+Pj4+IDUuMQ0KPj4+Pj4+Pj4+ICY1LjIgdG8gZGVzY3JpYmUgdGhl IGNvbXBsZXggc3R1ZmYuDQo+Pj4+Pj4+Pj4+Pj4+IEkgYWN0dWFsbHkgd2Fzbid0IHN1Z2dlc3Rp bmcgdGhhdCBOIGJlIGNhcnJpZWQgaW4NCj4+Pj4gdGhlIGJpdCByYXRlICANCj4+Pj4+Pj4+Pj4+ Pj4gZmllbGQuDQo+Pj4+Pj4+Pj4+Pj4+IFRoZSBiaXQgcmF0ZSBmaWVsZCBjYW4gZWl0aGVyIGJl IHNldCBhcyBkZXNjcmliZWQgb3IgdG8gemVybw0KPj4+Pj4+Pj4+Pj4+PiAoaS5lLiwgIGlnbm9y ZWQpLiAgQXQgdGhlIHRpbWUsIEkgd2FzIHRoaW5raW5nIGFib3V0DQo+Pj4+IGNhcnJ5aW5nIE4g DQo+Pj4+Pj4+Pj4+Pj4+IGluIHRoZSAgcmVzZXJ2ZWQgIGZpZWxkLiBCdXQgcGVyaGFwcyB0aGUg cmlnaHQgcGxhY2UNCj4+Pj4gaXMgTVQsIGlmIA0KPj4+Pj4+Pj4+Pj4+PiBteSB1bmRlcnN0YW5k aW5nIGlzICByaWdodCAgKHdvdWxkIGFsd2F5cyBiZSAxDQo+Pj4+IG90aGVyd2lzZSkuIEknbQ0K Pj4+Pj4+Pj4+Pj4+PiBvcGVuIHRvIGVpdGhlci4uLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+IFtGYXRhaV0gV2h5IG5vdCBqdXN0IHVzZSAiYml0IHJhdGUiZmllbGQgdG8gY2FycnkNCj4+ Pj4gIk4iYmVjYXVzZSAiTiINCj4+Pj4+Pj4+Pj4+PiBpbXBsaWVzIGJpdCByYXRlPyAgSSBhbSBP SyBpZiB5b3UgbGlrZSB0byB1c2UgYSBuZXcNCj4+Pj4gZmlsZWQgKGxpa2UgDQo+Pj4+Pj4+Pj4+ Pj4gIlRTDQo+Pj4+Pj4+Pj4+Pj4gTnVtYmVyIikgdG8gb2NjdXB5IHRoZSByZXNlcnZlZCBmaWVs ZCBldmVuIHRob3VnaA0KPj4+PiB0aGF0IEkgcHJlZmVyIA0KPj4+Pj4+Pj4+Pj4+IHRoZSAgb3Jp Z2luYWwgYXBwcm9hY2ggKGllLiwgdXNlICJiaXQgcmF0ZSJmaWVsZCB0byBjYXJyeSAiTiIpLg0K Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEFyZSB5b3UgcHJvcG9zaW5nIGRyb3BwaW5nIGNhcnJ5 aW5nIGJpdCByYXRlcw0KPj4+PiByZXByZXNlbnRlZCBhcyBhbg0KPj4+Pj4+Pj4+Pj4gSUVFRSAg ZmxvYXRpbmcgcG9pbnQgYW5kIGp1c3QgY2FycnlpbmcgTiBmb3IgT0RVZmxleD8NCj4+Pj4gVGhp cyBzZWVtcyANCj4+Pj4+Pj4+Pj4+IHdvcmthYmxlICB0byAgbWUsIGJ1dCB3ZSBzaG91bGQgZW5z dXJlIHRoYXQgdGhlcmUgYXJlIG5vDQo+Pj4+Pj4+Pj4+PiBzaWduaWZpY2FudCBvYmplY3Rpb25z Lg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBbRmF0YWldIFRoZXJlIGFyZSB0d28gdXNhZ2VzIGZv ciAiIEJpdF9SYXRlICIgZmllbGQgYXMNCj4+Pj4gZGVzY3JpYmVkIA0KPj4+Pj4+Pj4+PiBpbiB0 aGUgbGluZXMgMjg3LTMxMC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gKDEpICAgIEZvciBPRFVm bGV4KENCUiksIHRoZSBCaXRfUmF0ZSBmaWVsZCBpbmRpY2F0ZXMNCj4+Pj4gdGhlIG5vbWluYWwN Cj4+Pj4+Pj4+Pj4gYml0DQo+Pj4+Pj4+Pj4+IHJhdGUgb2YgT0RVZmxleChDQlIpIGV4cHJlc3Nl ZCBpbiBieXRlcyBwZXIgc2Vjb25kLA0KPj4+PiBlbmNvZGVkIGFzIGEgIA0KPj4+Pj4+Pj4+PiAz Mi1iaXQgIElFRUUgc2luZ2xlIHByZWNpc2lvbiBmbG9hdGluZy1wb2ludCBudW1iZXIuIEZvciB0 aGlzDQo+Pj4+Pj4+Pj4+IGNhc2UsIHdlIE1VU1QgIHVzZSAgMzItYml0IElFRUUgZmxvYXRpbmcg cG9pbnQgaW5zdGVhZCBvZg0KPj4+Pj4+Pj4+PiAiTiIoUGxlYXNlIHNlZSBtb3JlIGluIHNlY3Rp b24gIDUuMSkuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJIGd1ZXNzIHlvdSByZWFsbHkgc3RpbGwg bmVlZCAodG8gYmUgYmFzZWQgb24pIHRoZSBjbGllbnQgc2lnbmFsDQo+Pj4+Pj4+Pj4gcmF0ZSBh dCB0aGUgZWRnZXMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gKDIpICAgIEZv ciBPRFVmbGV4KEdGUCksIHdlIGNhbiBjaGFuZ2UgdGhlIHRleHQgKHRoZQ0KPj4+PiBsaW5lcyBm cm9tIDMwNQ0KPj4+Pj4+Pj4+PiB0bw0KPj4+Pj4+Pj4+PiAzMTApIGJhc2VkIG9uIHlvdXIgc3Vn Z2VzdGlvbiwgaWUuLCB0aGUgQml0X1JhdGUgZmllbGQNCj4+Pj4gaXMgdXNlZCB0byAgDQo+Pj4+ Pj4+Pj4+IGNhcnJ5ICAiTiJ0byBpbmRpY2F0ZSB0aGUgbm9taW5hbCBiaXQgcmF0ZSBvZiB0aGUg IE9EVWZsZXgoR0ZQKS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IGJ1dCB5b3UncmUgc2F5cyBlbmNv ZGVkIGFzIChOKk5vbWluYWwgUmF0ZSkgcmlnaHQ/ICBXYXQncyB0aGUNCj4+Pj4+Pj4+PiB2YWx1 ZSBvZiAgdGhpcyB2cyBqdXN0IGNhcnJ5aW5nIE4/DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBUaGVyZWZvcmUsIEkgYW0gcHJvcG9zaW5nIHVzaW5nIG9uZSBz aW5nbGUgZmlsZWQgKCJCaXRfUmF0ZSAiKQ0KPj4+Pj4+Pj4+PiBmb3IgdGhlc2UgdHdvIGNhc2Vz LCBpbiB0aGlzIHdheSwgd2UgY2FuIGxlYXZlIHRoZSAiUmVzZXJ2ZWQiDQo+Pj4+Pj4+Pj4+IGJp dHMgZm9yIGZ1dHVyZS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IGJpdHMgaW4gdGhlIGNvbnRyb2wg cGxhbmUgYXJlIGdlbmVyYWxseSBjaGVhcCwgSU1PIGl0J3MNCj4+Pj4gYmV0dGVyIHRvIA0KPj4+ Pj4+Pj4+IGhhdmUgIHNpbXBsZXIgZW5jb2RpbmcgdGhhbiB0byBvcHRpbWl6ZSBldmVyeSBiaXQg KG9yIDggaW4gdGhpcw0KPj4+Pj4+Pj4+IGNhc2UpLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gTG91 DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSG9wZSB3ZSBhcmUgbm93IGF0IHRo ZSBzYW1lIHBhZ2UuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEJlc3QgUmVn YXJkcw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBGYXRhaQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+Pj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gQ0NBTVBAaWV0Zi5vcmcN Cj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pj4+DQo+Pj4+ Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IENDQU1QIG1haWxpbmcg bGlzdA0KPj4gQ0NBTVBAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2NhbXANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+IA0K From fred.gruman@us.fujitsu.com Tue Jan 29 12:09:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E845B21F885C for ; Tue, 29 Jan 2013 12:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8, 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 BRJdsQs3SLWK for ; Tue, 29 Jan 2013 12:09:14 -0800 (PST) Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3E40621F8837 for ; Tue, 29 Jan 2013 12:09:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,561,1355119200"; d="scan'208";a="27100652" Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp02.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 29 Jan 2013 14:09:15 -0600 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.98]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.02.0298.004; Tue, 29 Jan 2013 14:09:13 -0600 From: "Gruman, Fred" To: "Gruman, Fred" , Lou Berger Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZXB3/s+GYEYvka9gmYAFxeuf5hglFOAgAACTfCAAHTEgP//sBnggAABZsA= Date: Tue, 29 Jan 2013 20:09:13 +0000 Message-ID: <5DF87403A81B0C43AF3EB1626511B2923C331576@RCHEXMBP1.fnc.net.local> References: <5106DED0.3090008@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33126F@RCHEXMBP1.fnc.net.local> <51081917.3080601@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33153D@RCHEXMBP1.fnc.net.local> In-Reply-To: <5DF87403A81B0C43AF3EB1626511B2923C33153D@RCHEXMBP1.fnc.net.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19598.001 x-tm-as-result: No--61.862100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 20:09:16 -0000 DQpBcyBhbiBhZGRpdGlvbmFsIGl0ZW0sIGlmIHdlIGFyZSBwbGFubmluZyB0byByZXVzZSBleGlz dGluZyBJQU5BIGNvZGVwb2ludCBmb3IgdGhlIEdFTkVSQUxJWkVEX0xBQkVMLCB3aHkgYXJlIHdl IGxpc3RpbmcgT1ROLVRETSBHZW5lcmFsaXplZCBMYWJlbCBPYmplY3QgaW4gdGhlIElBTkEgc2Vj dGlvbj8gIFRoaXMgYXBwZWFycyB0byBpbXBseSB0aGF0IHdlIGFyZSBhc2tpbmcgZm9yIGEgbmV3 IElBTkEgYXNzaWdubWVudCwgd2hpY2ggaXMgbm90IHRoZSBjYXNlIGZvciB0aGUgbGFiZWwgb2Jq ZWN0LiAgRnVydGhlciB0aGUgcmVmZXJlbmNlIHRvIFNlY3Rpb24gNS4xIGRvZXMgbm90IGhhdmUg YW55dGhpbmcgdG8gZG8gd2l0aCB0aGUgbGFiZWwgYnV0IHRyYWZmaWMgcGFyYW1ldGVycy4NCg0K UmVnYXJkcywNCkZyZWQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNjYW1w LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgR3J1bWFuLCBGcmVkDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI5LCAyMDEzIDI6MDUg UE0NClRvOiBMb3UgQmVyZ2VyDQpDYzogQ0NBTVANClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFBvbGwg b24gT0RVRmxleC1yZWxhdGVkIGVuY29kaW5nICh3YXM6IFdHIExhc3QgQ2FsbCBjb21tZW50cyBv biBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQpDQoNCkhpIExvdSwN Cg0KSnVzdCB0byBjb25maXJtLCB5b3VyIG9wdGlvbiAyIHdoZXJlIHlvdSBzdGF0ZSAidXNlIGEg bmV3IEMtdHlwZSBmb3IgT1ROLVRETSBsYWJlbHMiLCBpdCB3YXMgbm90IHRoZSBpbnRlbnQgdG8g aGF2ZSBhIG5ldyBjLXR5cGUgZm9yIHRoZSBsYWJlbCBpdHNlbGYsIGJ1dCBhIG5ldyBjLXR5cGUg Zm9yIHRoZSBzZW5kZXItdHNwZWMvZmxvd3NwZWMgKHRyYWZmaWMgcGFyYW1ldGVycykuIElmIHNv LCBJIG1pc3VuZGVyc3Rvb2QgdGhlIG9wdGlvbiBhbmQgbm93IHVuZGVyc3RhbmQgdGhlIHByb3Bv c2Fscy4NCg0KVGhhbmtzLA0KRnJlZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0KU2VudDogVHVlc2RheSwg SmFudWFyeSAyOSwgMjAxMyAxMjo0NyBQTQ0KVG86IEdydW1hbiwgRnJlZA0KQ2M6IFphZmFyIEFs aSAoemFsaSk7IENDQU1QDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBQb2xsIG9uIE9EVUZsZXgtcmVs YXRlZCBlbmNvZGluZyAod2FzOiBXRyBMYXN0IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KDQpGcmVkLA0KCVRoYW5rcyBmb3IgdGhl IGlucHV0Lg0KDQpPbiAxLzI5LzIwMTMgMTI6NTQgUE0sIEdydW1hbiwgRnJlZCB3cm90ZToNCj4g SGkgTG91LA0KPiANCj4gSSBhbSBub3QgY2xlYXIgb24gb3B0aW9uIDIgYXMgd2hlbiBJIGxvb2sg aW50byBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDUsIHRoZSBJQU5B IHNlY3Rpb24gc2hvd3MgdGhlIGMtdHlwZSBmb3IgdGhlIEdFTkVSQUxJWkVfTEFCRUwgZGVmaW5l ZCBpbiBSRkMgMzQ3Mywgbm90IGEgbmV3IGMtdHlwZS4NCj4gDQo+IE9UTi1URE0gR2VuZXJhbGl6 ZWQgTGFiZWwgT2JqZWN0OiANCj4gDQo+ICAgICAgICBvIE9UTi1URE0gR2VuZXJhbGl6ZWQgTGFi ZWwgT2JqZWN0OiBDbGFzcyA9IDE2LCBDLVR5cGUgPSAyIChzZWUgDQo+ICAgICAgICAgIFNlY3Rp b24gNS4xKSANCj4NCg0KSSBkaWRuJ3Qgbm90aWNlIHRoYXQgaW5jb25zaXN0ZW5jeS4gIFBlcg0K aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxp bmctZzcwOXYzLTA1I3NlY3Rpb24tNToNCiBUaGUgdHJhZmZpYyBwYXJhbWV0ZXJzIGZvciBPVE4t VERNIGNhcGFibGUgU3dpdGNoaW5nIFR5cGUgYXJlIGNhcnJpZWQNCiBpbiB0aGUgT1ROLVRETSBT RU5ERVJfVFNQRUMgYW5kIEZMT1dTUEVDIG9iamVjdHMuIFRoZSBvYmplY3RzIGhhdmUNCiB0aGUg Zm9sbG93aW5nIGNsYXNzIGFuZCB0eXBlOg0KDQogICAgLSAgT1ROLVRETSBTRU5ERVJfVFNQRUMg T2JqZWN0OiBDbGFzcyA9IDEyLCBDLVR5cGUgPSA3IChUQkEpDQogICAgLSAgT1ROLVRETSBGTE9X U1BFQyBPYmplY3Q6IENsYXNzID0gOSwgQy1UeXBlID0gNyAoVEJBKQ0KDQpMb3UNCg0KPiBJJ20g b3BlbiB0byBlaXRoZXIgY2FycnlpbmcgT0RVZmxleChHRlApIGJhbmR3aWR0aCBhcyBmbG9hdGlu Zy1wb2ludCBvciBpbnRlZ2VyIE4sIGJ1dCB3b3VsZCBsaWtlIHRvIHNlZSBjb25zaXN0ZW5jeSBi ZXR3ZWVuIHJvdXRpbmcgYW5kIHNpZ25hbGluZyBkb2N1bWVudHMuDQo+IA0KPiANCj4gUmVnYXJk cywNCj4gRnJlZA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2Nh bXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBaYWZhciBBbGkgKHphbGkpDQo+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjksIDIw MTMgMTA6NDEgQU0NCj4gVG86IExvdSBCZXJnZXI7IENDQU1QDQo+IFN1YmplY3Q6IFJlOiBbQ0NB TVBdIFBvbGwgb24gT0RVRmxleC1yZWxhdGVkIGVuY29kaW5nICh3YXM6IFdHIExhc3QgQ2FsbCBj b21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQpDQo+ IA0KPiBIaSBMb3UsIEMtY2FtcGVyczogDQo+IA0KPiBJIHdvdWxkIHBpY2sgT3B0aW9uIDI7IGl0 J3MgY2xlYW5lciBhbmQgIGFkZHJlc3NlcyB0aGUgaXNzdWUgcmVsYXRlZCB0bw0KPiBvdmVybG9h ZGluZyB0aGUgc2FtZSBjLXR5cGUuDQo+IA0KPiBUaGFua3MNCj4gDQo+IFJlZ2FyZHPigKZaYWZh cg0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206ICJsYmVyZ2Vy QGxhYm4ubmV0IiA8bGJlcmdlckBsYWJuLm5ldD4NCj4gRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDI4 LCAyMDEzIDM6MjUgUE0NCj4gVG86ICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPg0K PiBTdWJqZWN0OiBbQ0NBTVBdIFBvbGwgb24gT0RVRmxleC1yZWxhdGVkIGVuY29kaW5nICh3YXM6 IFdHIExhc3QgQ2FsbA0KPiBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25h bGluZy1nNzA5djMtMDQpDQo+IA0KPj4gQWxsLA0KPj4gCVdlIHdvdWxkIGxpa2UgdG8gdHJ5IHRv IGNsb3NlIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBHLjcwOQ0KPj4gZHJhZnRzIHNvIHRoYXQgd2Ug Y2FuIG1vdmUgcmFwaWRseSB0b3dhcmRzIHB1YmxpY2F0aW9uIHJlcXVlc3QuICBUaGUNCj4+IGRp c2N1c3Npb24gb2YgKG9uZSBvZiBteSkgTEMgY29tbWVudHMgaGFzIHJlc3VsdGVkIGluIHNldmVy YWwgb3B0aW9ucw0KPj4gZm9yIHRoZSBzaWduYWxpbmcgT0RVLXJlbGF0ZWQgdHJhZmZpYyBwYXJh bWV0ZXJzLCBhbmQgdGhlIHBvaW50IGhhcw0KPj4gYmVlbiByYWlzZWQgdGhhdCByZWFsaWduaW5n IHJvdXRpbmcgd2l0aCBzaWduYWxpbmcgc2hvdWxkIGJlIGRpc2N1c3NlZC4NCj4+DQo+PiBQbGVh c2Uga2VlcCBpbiBtaW5kIHRoYXQgdGhlIG9iamVjdGl2ZSBvZiBhbnkgUFMgaXMgaW50ZXJvcGVy YWJpbGl0eSwNCj4+IGFuZCB0aGF0IHRoZXJlIG1heSBiZSBlYXJseSBpbXBsZW1lbnRhdGlvbnMg dGhhdCBtYXRjaCBnNzA5djMtMDQuDQo+Pg0KPj4gVGhlIGJhc2ljIHF1ZXN0aW9uIGlzIG9uZSBv ZiBpZiBOLCB0aGUgbnVtYmVyIG9mIHRpbWUgc2xvdHMgbmVlZGVkIHRvDQo+PiBzdXBwb3J0IGEg T0RVZmxleChHRlApIHNpZ25hbCwgc2hvdWxkIGJlIGNhcnJpZWQgYXMgYSBjYWxjdWxhdGVkIElF RUUNCj4+IGZsb2F0aW5nIHBvaW50IG51bWJlciBvciBkaXJlY3RseS4gICBPcHRpb25zIDEgYW5k IDIgYmVsb3cgcmVmbGVjdCB0aGUNCj4+IGZvcm1lciwgb3B0aW9ucyAzIGFuZCA0IG1hdGNoIHRo ZSBsYXR0ZXIuICBJdCBpcyB3b3J0aCBub3RpbmcgdGhhdCBvbmx5DQo+PiBvcHRpb25zIDEgYW5k IDIgYXJlIHByb3Bvc2VkIGZvciBPRFVmbGV4KEdGUCksIGkuZS4sIE4gbXVzdCBiZQ0KPj4gY2Fs Y3VsYXRlZCBmb3IgT0RVZmxleChDQlIpIHNpZ25hbCB0eXBlcyB3aXRoIGFsbCBvcHRpb25zLg0K Pj4NCj4+IFBsZWFzZSBzdGF0ZSB5b3VyIHN1cHBvcnQgZm9yIG9uZSB0aGUgb3B0aW9ucyBhbmQs IGlmIHlvdSB3aXNoLCB0aGUNCj4+IGp1c3RpZmljYXRpb24gZm9yIHlvdXIgcG9zaXRpb246DQo+ Pg0KPj4gMSkgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0w NA0KPj4gICBpLmUuLCByZWRlZmluZSBbUkZDNDMyOF0gVHJhZmZpYyBQYXJhbWV0ZXJzIGMtdHlw ZSB3aGVuIHVzZWQgd2l0aA0KPj4gICBPVE4tVERNIGxhYmVscy4gT0RVZmxleChHRlApIG51bWJl ciBvZiB0cmlidXRhcnkgc2xvdHMgKE4pIGlzDQo+PiAgIGVuY29kZWQgYXM6DQo+Pg0KPj4gICAu Li4gdGhlIEJpdF9SYXRlIGZpZWxkIGZvciBPRFVmbGV4KEdGUCkgTVVTVA0KPj4gICBlcXVhbCB0 byBvbmUgb2YgdGhlIDgwIHZhbHVlcyBsaXN0ZWQgYmVsb3c6DQo+Pg0KPj4gICAgICAgMSAqIE9E VTIudHM7IDIgKiBPRFUyLnRzOyAuLi47IDggKiBPRFUyLnRzOw0KPj4gICAgICAgOSAqIE9EVTMu dHM7IDEwICogT0RVMy50cywgLi4uOyAzMiAqIE9EVTMudHM7DQo+PiAgICAgICAzMyAqIE9EVTQu dHM7IDM0ICogT0RVNC50czsgLi4uOyA4MCAqIE9EVTQudHMuDQo+Pg0KPj4gMikgRm9sbG93IGRy YWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNQ0KPj4gICBpLmUuLCB1c2Ug YSBuZXcgQy10eXBlIGZvciBPVE4tVERNIGxhYmVscy4gIEVuY29kaW5nIGRldGFpbHMNCj4+ICAg dW5jaGFuZ2VkIGZyb20gZzcwOXYzLTA0Lg0KPj4gICAoVGhpcyBvcHRpb24gYWRkcmVzc2VzIHRo ZSBpc3N1ZSBvZiB0aGUgc2FtZSBjLXR5cGUgbmVlZGluZyB0bw0KPj4gICAgYmUgcGFyc2VkIGJh c2VkIG9uIGxhYmVsL3N3aXRjaGluZyB0eXBlLikNCj4+DQo+PiAzKSBGb2xsb3cgZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA2DQo+PiAgIGkuZS4sICB1c2UgYSBuZXcg Qy10eXBlIGZvciBPVE4tVERNIGxhYmVscy4gTiBpcyBkaXJlY3RseSBjYXJyaWVkDQo+PiAgIGZv ciBPRFVmbGV4KEdGUCkgb25seS4NCj4+DQo+PiA0KSBEaXNjdXNzZWQsIGJ1dCBub3QgaW4gYW55 IGRyYWZ0DQo+PiAgIFVzZSBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMt MDQgZW5jb2RpbmcgZm9yIGFsbA0KPj4gICBidXQgT0RVZmxleChHRlApLCBhbmQgZGVmaW5lIG5l dyBPRFVmbGV4KEdGUCkgc3BlY2lmaWMgVHJhZmZpYw0KPj4gICBQYXJhbWV0ZXJzIGJhc2VkIG9u IGc3MDl2My0wNiwgcHJlc3VtYWJseSB3aXRoIHVudXNlZCBmaWVsZHMNCj4+ICAgcmVtb3ZlZC4N Cj4+ICAgKFRoaXMgYWxzbyBhZGRyZXNzZXMgdGhlIGlzc3VlIG9mIHRoZSBzYW1lIGMtdHlwZSBu ZWVkaW5nIHRvIGJlDQo+PiAgICBwYXJzZWQgYmFzZWQgb24gbGFiZWwgdHlwZSwgYnV0IG1lYW5z IHRoZXJlIGFyZSBkaWZmZXJlbnQgdHlwZXMNCj4+ICAgIGJhc2VkIG9uIHNpZ25hbCB0eXBlLikN Cj4+DQo+PiBPcHRpb24gMSBhbmQgMiBkbyBub3QgaW1wbHkgYW55IGNoYW5nZXMgdG8gcm91dGlu Zywgd2hpbGUgb3B0aW9ucyAzIGFuZA0KPj4gNCBtYXkuICBSb3V0aW5nIGltcGxpY2F0aW9ucyB3 aWxsIGJlIGRpc2N1c3NlZCBiYXNlZCBvbiB0aGUgcmVzdWx0cyBvZg0KPj4gdGhpcyBwb2xsLCBh bmQgb25seSBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdG8gc3VwcG9ydCBwb3NpdGlvbnMgMyBvciA0 Lg0KPj4NCj4+IFdlIGhvcGUgdG8gbWFrZSBhIGNvbnNlbnN1cyBjYWxsIGJ5IHRoZSBlbmQgb2Yg dGhlIHdlZWssIGJ1dCB3aWxsDQo+PiBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBhcyBuZWVkZWQu DQo+Pg0KPj4gTXVjaCB0aGFua3MsDQo+PiBMb3UgKGFuZCBEZWJvcmFoKQ0KPj4NCj4+IE9uIDEv MjgvMjAxMyA1OjA4IEFNLCBEYW5pZWxlIENlY2NhcmVsbGkgd3JvdGU6DQo+Pj4gIEFsbCwNCj4+ Pg0KPj4+IEkgdGhpbmsgdGhlIGNoYW5nZXMgcHJvcG9zZWQgYXJlIG1lYW5pbmdmdWwgYW5kIHdv dWxkIHN1cHBvcnQgdGhlbSBpbg0KPj4+IGFuIGluZGl2aWR1YWwgb3IgZWFybHkgV0cgZHJhZnQs IGJ1dCB0aGV5IGRvbid0IHNlZW0gdG8gcHJvdmlkZQ0KPj4+IHNpZ25pZmljYXRpdmUgYWR2YW50 YWdlcyB0byByaXNrIGludGVyd29ya2luZyBpc3N1ZXMgd2l0aCBlYXJseQ0KPj4+IGltcGxlbWVu dGF0aW9ucy4NCj4+PiBNb3Jlb3ZlciB0aGUgY2hhbmdlcyBkb24ndCBhbGxvdyB1cyBnZXR0aW5n IHRvdGFsbHkgcmlkIG9mIG9mIHRoZQ0KPj4+IGJpdF9yYXRlIGZpZWxkIGFzIGl0IGlzIHN0aWxs IG5lZWRlZCBmb3IgT0RVZmxleCAoQ0JSKS4NCj4+Pg0KPj4+IE15IDJjDQo+Pj4gRGFuaWVsZQ0K Pj4+DQo+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogWmFm YXIgQWxpICh6YWxpKSBbbWFpbHRvOnphbGlAY2lzY28uY29tXQ0KPj4+PiBTZW50OiBsdW5lZMOs IDI4IGdlbm5haW8gMjAxMyA0LjQ3DQo+Pj4+IFRvOiBMb3UgQmVyZ2VyDQo+Pj4+IENjOiBHcnVt YW4sIEZyZWQ7IEZhdGFpIFpoYW5nOyBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1QOw0KPj4+PiBk cmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+ Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+IGRy YWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pg0KPj4+PiBIaSBM b3UtIA0KPj4+Pg0KPj4+PiBQbGVhc2Ugc2VlIGluLWxpbmUuDQo+Pj4+DQo+Pj4+IFRoYW5rcw0K Pj4+Pg0KPj4+PiBSZWdhcmRzLi4uWmFmYXINCj4+Pj4NCj4+Pj4gT24gMS8yNy8xMyA5OjQ2IFBN LCAiTG91IEJlcmdlciIgPGxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0KPj4+Pg0KPj4+Pj4gWmFm YXIsDQo+Pj4+PiAJSXMgeW91ciBjb21tZW50IHdpdGggcmVzcGVjdCB0byBqdXN0IHJvdXRpbmcg b3IgYm90aA0KPj4+PiBzaWduYWxpbmcgYW5kIA0KPj4+Pj4gcm91dGluZz8NCj4+Pj4NCj4+Pj4g Qm90aCwgaW5jbHVkaW5nIGNvbnNpc3RlbmN5IGJldHdlZW4gc2lnbmFsaW5nIGFuZCByb3V0aW5n IGF0dHJpYnV0ZXMuDQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4gQWxzbywgd2hlbiB5b3Ugc2F5ICJpbXBs ZW1lbnRhdGlvbnMgYmFzZWQgb24gZHJhZnQgdmVyc2lvbnMiLA0KPj4+PiBkbyB0aGVzZSANCj4+ Pj4+IGltcGxlbWVudGF0aW9ucyBpbmNsdWRlIHN1cHBvcnQgZm9yIE9EVWZsZXg/ICAoV2hpY2gg aGFzIHJlYWxseSBiZWVuDQo+Pj4+PiB0aGUgZm9jdXMgb2YgdGhlIGRpc2N1c3Npb24uKQ0KPj4+ Pg0KPj4+PiBZZXMsIEkgd2FzIHJlZmVycmluZyB0byBPRFVGbGV4LiBBcyB5b3Uga25vdywgZml4 ZWQgT0RVIGlzDQo+Pj4+IHNpZ25hbGVkIHZpYSBsZXZlbCAoMCBCVykgc28gaXRzIG5vdCBhbiBp c3N1ZS4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBCVFcgSSB0b29rIEZyZWQncyBjb21tZW50cyBhcyBy ZWxhdGVkIHRvIGp1c3QgdGhlIG5ldw0KPj4+PiBPVE4tc3BlY2lmaWMgSVNDRA0KPj4+Pj4gZGVm aW5pdGlvbnMgKHNlY3Rpb24gNC4xLjIgb2Ygb3NwZi1nNzA5djMtMDUsIGluIHBhcnRpY3VsYXIp LiAgTm90ZQ0KPj4+Pj4gdGhhdCBzZWN0aW9uIDQuMS4xIGFscmVhZHkgY2FycmllcyBOIChudW1i ZXIgb2YgT0RVcykgbm90DQo+Pj4+IElFRUUgZmxvYXRpbmcgDQo+Pj4+PiBwb2ludCByZXByZXNl bnRhdGlvbnMgb2YgYXZhaWxhYmxlIGJhbmR3aWR0aC4NCj4+Pj4NCj4+Pj4gV2hhdCBJIG1lYW50 IGlzIFVucmVzZXJ2ZWQgQmFuZHdpZHRoIGF0IHByaW9yaXR5IHggYW5kIE1heCBMU1ANCj4+Pj4g QmFuZHdpZHRoIGF0IHByaW9yaXR5IHguDQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4gTXVjaCB0aGFua3Ms DQo+Pj4+PiBMb3UNCj4+Pj4+DQo+Pj4+PiBPbiAxLzI3LzIwMTMgNzo0NiBQTSwgWmFmYXIgQWxp ICh6YWxpKSB3cm90ZToNCj4+Pj4+PiBBbGwtDQo+Pj4+Pj4NCj4+Pj4+PiBUaGlzIGltcGFjdHMg ZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIGRyYWZ0IHZlcnNpb25zIChhbmQNCj4+ Pj4+PiBoZW5jZSBpbnRlcm9wIHdpdGggdGhlc2UgaW1wbGVtZW50YXRpb25zIG1vdmluZyBmb3J3 YXJkKS4NCj4+Pj4gSU1PIHRoaXMgaXMgDQo+Pj4+Pj4gYSBiaWdnZXIgY2hhbmdlIGZvciB1cyB0 byBhc3N1bWUgYXQgdGhlIGxhc3QgY2FsbCBzdGFnZS4NCj4+Pj4gRnVydGhlcm1vcmUgDQo+Pj4+ Pj4gd2UgaGF2ZSBiZWVuIHVzaW5nIElFRUUgZmxvYXRpbmcgcG9pbnQgZm9ybWF0IGZvciBVbnJl c2VydmVkDQo+Pj4+Pj4gQmFuZHdpZHRoLyBNYXggTFNQIEJXIGluIElFRUUgZmxvYXRpbmcgcG9p bnQgZm9ybWF0IGZvciBvdGhlcg0KPj4+Pj4+IHRlY2hub2xvZ2llcy4gT3ZlcmFsbCwgSSB0aGlu ayB0aGlzIGNoYW5nZSBzdWZmZXJzIGZyb20gdGhlDQo+Pj4+ICJsYXcgb2YgZGltaW5pc2hpbmcg cmV0dXJucyIuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3MNCj4+Pj4+Pg0KPj4+Pj4+IFJlZ2FyZHMg xaAgWmFmYXINCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24gMS8yNy8xMyAxMDoyOCBBTSwgIkdy dW1hbiwgRnJlZCINCj4+Pj4gPGZyZWQuZ3J1bWFuQHVzLmZ1aml0c3UuY29tPiB3cm90ZToNCj4+ Pj4+Pg0KPj4+Pj4+PiBIaSBMb3UsIEZhdGFpLCBEYW5pZWxlLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBJ IHVuZGVyc3RhbmQgdGhlIGxhdGVzdCBjaGFuZ2UgdG8gdGhlIHdheSBiYW5kd2lkdGggaXMNCj4+ Pj4gc2lnbmFsZWQgZm9yICANCj4+Pj4+Pj4gT0RVZmxleChHRlApLCBpLmUuLCBzaWduYWxpbmcg dGhlIG51bWJlciBvZiB0cmlidXRhcnkgc2xvdHMNCj4+Pj4gTiBpbnN0ZWFkIA0KPj4+Pj4+PiBv ZiAgdGhlIGJhbmR3aWR0aCByYXRlIGluIGJwcy4gIEkgYmVsaWV2ZSB0aGF0IHRoaXMgc2ltcGxp ZmllcyB0aGUNCj4+Pj4+Pj4gc2lnbmFsaW5nICBhbmQgaW50ZXJvcGVyYWJpbGl0eSBzbyBJJ20g aW4gYWdyZWVtZW50IHdpdGgNCj4+Pj4gdGhpcyBjaGFuZ2UuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhv d2V2ZXIsIGl0IHNlZW1zIHdlIGFyZSBub3cgaW5jb25zaXN0ZW50IGJldHdlZW4gaG93IHdlDQo+ Pj4+IHJlcHJlc2VudCAgDQo+Pj4+Pj4+IGJhbmR3aWR0aCBpbiByb3V0aW5nIGFuZCBzaWduYWxp bmcgZm9yIE9EVWZsZXgoR0ZQKS4gIFJvdXRpbmcNCj4+Pj4+Pj4gYWR2ZXJ0aXNlcyAgdGhlIGJh bmR3aWR0aCB1c2luZyBhIGZsb2F0aW5nIHBvaW50IHJlcHJlc2VudGF0aW9uIG9mDQo+Pj4+Pj4+ IGJhbmR3aWR0aCwgd2hpbGUgIHNpZ25hbGluZyBpcyB1c2luZyB0aGUgbnVtYmVyIG9mIHRyaWJ1 dGFyeSBzbG90cy4NCj4+Pj4+Pj4gSXQgc2VlbXMgdGhlIHNhbWUgIGJlbmVmaXRzIHdvdWxkIGJl IG9idGFpbmVkIGJ5DQo+Pj4+IGFkdmVydGlzaW5nIHRoZSBtYXgNCj4+Pj4+Pj4gTFNQIGJhbmR3 aWR0aCBhbmQgIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGZvciBPRFVmbGV4KEdGUCkgaW4NCj4+Pj4g dGVybXMgb2YgDQo+Pj4+Pj4+IHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5ICBzbG90cy4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gRnJlZA0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+Pj4+Pj4gQmVoYWxmIE9m ICBMb3UgQmVyZ2VyDQo+Pj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMywgMjAxMyA5 OjA4IEFNDQo+Pj4+Pj4+IFRvOiBGYXRhaSBaaGFuZw0KPj4+Pj4+PiBDYzogQ0NBTVA7IGRyYWZ0 LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZw0KPj4+Pj4+ PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24NCj4+Pj4+Pj4g ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+Pj4+DQo+Pj4+ Pj4+IEZhdGFpLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiAxLzIzLzIwMTMgNjo0OSBBTSwgRmF0YWkg Wmhhbmcgd3JvdGU6DQo+Pj4+Pj4+PiBIaSBMb3UsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRm9yIE9E VWZsZXgoQ0JSKSwgdGhlIGZvcm11bGEgaXMgZnJvbSBbRy43MDktMjAxMl0gYW5kIGl0DQo+Pj4+ IGhhcyBiZWVuIA0KPj4+Pj4+Pj4gZGlzY3Vzc2VkIGJlZm9yZSwgc28gcGxlYXNlIHRydXN0IHRo YXQgdGhlcmUgaXMgbm8NCj4+Pj4gb3Bwb3J0dW5pdHkgZm9yDQo+Pj4+Pj4+PiBtaXNpbnRlcnBy ZXRhdGlvbi4gKE5vdGUgdGhhdCB0aGVyZSBhcmUgdHdvIGNhc2VzLCBvbmUgaXMNCj4+Pj4+Pj4+ IE9EVWZsZXgoQ0JSKSBhbmQgYW5vdGhlciBvbmUgaXMgT0RVZmxleChHRlApKS4NCj4+Pj4+Pj4+ DQo+Pj4+Pj4+PiBJbiBhZGR0aW9uLCBPRFVmbGV4IGNhbm5vdCBiZSBjb25jYXRlbmF0ZWQgYnkg W0cuNzA5LTIwMTJdLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGFua3MgZm9yIGNvbmZpcm1pbmcgbXkg dW5kZXJzdGFuZGluZy4gIFRoaXMgcmFpc2VzIHRoZQ0KPj4+PiBxdWVzdGlvbiBvZiANCj4+Pj4+ Pj4gaWYgdGhlIG5ldyB0cmFmZmljIHNob3VsZCBqdXN0IGFwcGx5IHRvIE9EVUZsZXg/ICBDb3Jy ZWN0DQo+Pj4+IG1lIGlmIEknbSANCj4+Pj4+Pj4gd3JvbmcsIGJ1dCBJIGJlbGlldmUgdGhlIFtS RkM0MzI4XSBpcyBzdWZmaWNpZW50IGluIGFsbA0KPj4+PiBvdGhlciBjYXNlcy4gIA0KPj4+Pj4+ PiBUaGlzIG1heSBhbHNvIG1ha2UgaXQgZWFzaWVyIGZvciBlYXJseSBpbXBsZW1lbnRhdGlvbnMg b2YNCj4+Pj4gdGhlIGRyYWZ0IA0KPj4+Pj4+PiBhcyB0aGVuIHRoZXkgY2FuIGxpbWl0IGNvZGUg Y2hhbmdlcyBmcm9tIHRoZSAoLTAzKSByZXYgdG8NCj4+Pj4gb25seSBPRFVmbGV4IExTUHMuDQo+ Pj4+Pj4+DQo+Pj4+Pj4+IEp1c3QgdG8gYmUgY2xlYXIsIEknbSByZWFsbHkganVzdCAqYXNraW5n KiBhYm91dCB0aGlzLiAgQXMgSSBzYWlkDQo+Pj4+Pj4+IGJlZm9yZSwgSSdtIG9wZW4gb24gc3Bl Y2lmaWNzLi4uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFueSB0aG91Z2h0cy9jb21tZW50cz8gQXV0aG9y cz8gIEltcGxlbWVudG9ycz8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+PiBMb3UN Cj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+IEkgd2lsbCBpc3N1ZSBhIG5ldyB2ZXJzaW9uIHRv bW9ycm93IHRvIGNhcHR1cmUgYWxsIHlvdXIgY29tbWVudHMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+ PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4+Pj4+Pj4+IFNl bnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMywgMjAxMyAyOjExIEFNDQo+Pj4+Pj4+PiBUbzogRmF0 YWkgWmhhbmcNCj4+Pj4+Pj4+IENjOiBDQ0FNUDsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWdu YWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1Q XSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24NCj4+Pj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEZhdGFpLA0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+IE9uIDEvMjAvMjAxMyA5OjQzIFBNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+ Pj4+Pj4+PiBIaSBMb3UsDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBZb3Ugc2FpZDoNCj4+Pj4+Pj4+ Pj4gYnV0IHlvdSdyZSBzYXlzIGVuY29kZWQgYXMgKE4qTm9taW5hbCBSYXRlKSByaWdodD8gV2F0 J3MgdGhlDQo+Pj4+Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFtGYXRhaV0gVGhlIG9yaWdpbmFsIHdheSAoaW4gdmVyc2lvbiAw NCYwNSkgaXMgcHV0dGluZw0KPj4+PiAoTiogTm9taW5hbA0KPj4+Pj4+Pj4+IFJhdGUpIGluICJC aXRfUmF0ZSIgZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSwgdGhlIHZhbHVlIGlzIHRoYXQgd2UNCj4+ Pj4+Pj4+PiBjYW4gZ2VuZXJhbGl6ZSB0byBqdXN0IHVzZSBvbmUgc2luZ2xlICJCaXRfUmF0ZSIg ZmllbGQgdG8gY2FycnkNCj4+Pj4+Pj4+PiBJRUVFIGZsb2F0IG51bWJlciBmb3IgYm90aCBjYXNl cywgaXQgc2VlbXMgdGhhdCB5b3UNCj4+Pj4gZG9uJ3QgYWdyZWUgb24gDQo+Pj4+Pj4+Pj4gdGhp cyB2YWx1ZSwgOi0pDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSSd2ZSBzZWVuIGRpZmZlcmVuY2VzIGlu IGNhbGN1bGF0ZWQgZmxvYXRpbmcgcG9pbnQgdmFsdWVzIGZyb20NCj4+Pj4+Pj4+IGRpZmZlcmVu dCAgaW1wbGVtZW50YXRpb25zLCBzbyBJIGp1c3Qgd2FudCB0byBlbnN1cmUgdGhhdA0KPj4+PiBz dWNoIGNhc2VzIA0KPj4+Pj4+Pj4gYXJlIGF2b2lkZWQuDQo+Pj4+Pj4+PiBJJ20gb3BlbiB0byBz cGVjaWZpYyBzb2x1dGlvbnMgYW5kIGNlcnRhaW5seSB3aWxsIGRlZmZlciBvbiB0aGUNCj4+Pj4+ Pj4+IHNwZWNpZmljcyBhc3N1bWluZyB0aGVyZSBpcyBubyBvcHBvcnR1bml0eSBmb3INCj4+Pj4+ Pj4+IG1pc2ludGVycHJldGF0aW9uL2ludGVyb3AgIGlzc3Vlcy4gSSBkb24ndCB0aGluayB0aGUN Cj4+Pj4gb3JpZ2luYWwgcGFzc2VkDQo+Pj4+Pj4+PiB0aGlzIHRocmVzaG9sZCwgaS5lLiw6DQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICAgTiA9IENlaWxpbmcgb2YNCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiAgICBPRFVmbGV4KENCUikgbm9taW5hbCBiaXQgcmF0ZSAqICgxICsgT0RVZmxleChDQlIp IGJpdCByYXRlDQo+Pj4+Pj4+PiB0b2xlcmFuY2UpDQo+Pj4+Pj4+PiAgICANCj4+Pj4+Pj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4+IC0tLS0tLS0tLS0NCj4+Pj4+Pj4+ICAgICAgICBPRFRVay50cyBub21pbmFsIGJpdCBy YXRlICogKDEgLSBITyBPUFVrIGJpdCByYXRlDQo+Pj4+IHRvbGVyYW5jZSkNCj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gLiBUaGVyZWZvcmUsIEkgKHdhcykgYW0gc2F5aW5nIHRoYXQgSSBhbSBnb2luZyB0 byBhY2NlcHQgeW91cg0KPj4+Pj4+Pj4+IHN1Z2dlc3Rpb24gdG8gY2FycnkgTiBmb3IgT0RVZmxl eChHRlApLiBXZSBhcmUNCj4+Pj4gZGlzY3Vzc2luZyB3aGVyZSB0bw0KPj4+Pj4+Pj4+IHB1dCBO IGZvciBPRFVmbGV4KEdGUCkuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gWW91IHNh aWQ6DQo+Pj4+Pj4+Pj4+IGJpdHMgaW4gdGhlIGNvbnRyb2wgcGxhbmUgYXJlIGdlbmVyYWxseSBj aGVhcCwgSU1PIGl0J3MNCj4+Pj4gYmV0dGVyIHRvICANCj4+Pj4+Pj4+Pj4gaGF2ZSBzaW1wbGVy IGVuY29kaW5nIHRoYW4gdG8gb3B0aW1pemUgZXZlcnkgYml0IChvciA4IGluIHRoaXMNCj4+Pj4+ Pj4+Pj4gY2FzZSkuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBbRmF0YWldIE9LLCBJIHdpbGwgYWRk IGEgbmV3IGZpZWxkICh0byBvY2N1cHkgdGhlIHJlc2VydmVkIGJpdHMpDQo+Pj4+Pj4+Pj4gdG8g Y2FycnkgTi4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBcyB5b3Ugc2VlIGZpdC4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBKdXN0IHRvIGNsYXJpZnkgbXkgdW5kZXJzdGFuZGluZywgT0RVZmxleCBhbmQgVmly dHVhbA0KPj4+PiBjb25jYXRlbmF0aW9uIA0KPj4+Pj4+Pj4gY2FuICBuZXZlciBiZSBjb21iaW5l ZCBmb3IgdGhlIHNhbWUgc2lnbmFsIHR5cGUvbGV2ZWwsIHJpZ2h0Pw0KPj4+Pj4+Pj4gKEFsdGhv dWdoIGFuICBPRFVmbGV4IGNsaWVudCBzaWduYWwgY291bGQgYmUgY2FycmllZCBvdmVyDQo+Pj4+ IGEgdmlydHVhbCANCj4+Pj4+Pj4+IGNvbmNhdGVuYXRlZCAgT0RVaykuICBJcyB0aGlzIGNvcnJl Y3Qgb3IgZGlkIEkgbWlzcyBzb21ldGhpbmcgaW4NCj4+Pj4+Pj4+IEc3MDk/DQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4gTG91DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4gRmF0YWkNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4+Pj4+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRd DQo+Pj4+Pj4+Pj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDE4LCAyMDEzIDE6NDIgQU0NCj4+Pj4+ Pj4+PiBUbzogRmF0YWkgWmhhbmcNCj4+Pj4+Pj4+PiBDYzogQ0NBTVA7IGRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZw0KPj4+Pj4+Pj4+IFN1Ympl Y3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+Pj4+IGRyYWZ0 LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIDEvMTUvMjAxMyAxMDoxNiBQTSwgRmF0YWkgWmhh bmcgd3JvdGU6DQo+Pj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gVG8g YXZvaWQgbWlzdW5kZXJzdGFuZGluZywgSSB3b3VsZCBsaWtlIHRvIGNsYXJpZnkgbW9yZSBvbiB0 aGUNCj4+Pj4+Pj4+Pj4gZm9sbG93aW5nIHBvaW50Lg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4gSXQgaXMgYmV0dGVyIHRvIGhhdmUgY29uc2lzdGVudCBmb3JtYXQgYW5k IHRoZSBzYW1lIG1lYW5pbmcNCj4+Pj4+Pj4+Pj4+Pj4+IG9mIG9uZQ0KPj4+Pj4+Pj4+IGZpZWxk IGZvciBib3RoIE9EVWZsZXgoQ0JSKSBhbmQgR0ZQLiBUaGlzIGlzIHdoeSB3ZSBoYXZlIHNlY3Rp b24NCj4+Pj4+Pj4+PiA1LjENCj4+Pj4+Pj4+PiAmNS4yIHRvIGRlc2NyaWJlIHRoZSBjb21wbGV4 IHN0dWZmLg0KPj4+Pj4+Pj4+Pj4+PiBJIGFjdHVhbGx5IHdhc24ndCBzdWdnZXN0aW5nIHRoYXQg TiBiZSBjYXJyaWVkIGluDQo+Pj4+IHRoZSBiaXQgcmF0ZSAgDQo+Pj4+Pj4+Pj4+Pj4+IGZpZWxk Lg0KPj4+Pj4+Pj4+Pj4+PiBUaGUgYml0IHJhdGUgZmllbGQgY2FuIGVpdGhlciBiZSBzZXQgYXMg ZGVzY3JpYmVkIG9yIHRvIHplcm8NCj4+Pj4+Pj4+Pj4+Pj4gKGkuZS4sICBpZ25vcmVkKS4gIEF0 IHRoZSB0aW1lLCBJIHdhcyB0aGlua2luZyBhYm91dA0KPj4+PiBjYXJyeWluZyBOIA0KPj4+Pj4+ Pj4+Pj4+PiBpbiB0aGUgIHJlc2VydmVkICBmaWVsZC4gQnV0IHBlcmhhcHMgdGhlIHJpZ2h0IHBs YWNlDQo+Pj4+IGlzIE1ULCBpZiANCj4+Pj4+Pj4+Pj4+Pj4gbXkgdW5kZXJzdGFuZGluZyBpcyAg cmlnaHQgICh3b3VsZCBhbHdheXMgYmUgMQ0KPj4+PiBvdGhlcndpc2UpLiBJJ20NCj4+Pj4+Pj4+ Pj4+Pj4gb3BlbiB0byBlaXRoZXIuLi4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBbRmF0 YWldIFdoeSBub3QganVzdCB1c2UgImJpdCByYXRlImZpZWxkIHRvIGNhcnJ5DQo+Pj4+ICJOImJl Y2F1c2UgIk4iDQo+Pj4+Pj4+Pj4+Pj4gaW1wbGllcyBiaXQgcmF0ZT8gIEkgYW0gT0sgaWYgeW91 IGxpa2UgdG8gdXNlIGEgbmV3DQo+Pj4+IGZpbGVkIChsaWtlIA0KPj4+Pj4+Pj4+Pj4+ICJUUw0K Pj4+Pj4+Pj4+Pj4+IE51bWJlciIpIHRvIG9jY3VweSB0aGUgcmVzZXJ2ZWQgZmllbGQgZXZlbiB0 aG91Z2gNCj4+Pj4gdGhhdCBJIHByZWZlciANCj4+Pj4+Pj4+Pj4+PiB0aGUgIG9yaWdpbmFsIGFw cHJvYWNoIChpZS4sIHVzZSAiYml0IHJhdGUiZmllbGQgdG8gY2FycnkgIk4iKS4NCj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+PiBBcmUgeW91IHByb3Bvc2luZyBkcm9wcGluZyBjYXJyeWluZyBiaXQg cmF0ZXMNCj4+Pj4gcmVwcmVzZW50ZWQgYXMgYW4NCj4+Pj4+Pj4+Pj4+IElFRUUgIGZsb2F0aW5n IHBvaW50IGFuZCBqdXN0IGNhcnJ5aW5nIE4gZm9yIE9EVWZsZXg/DQo+Pj4+IFRoaXMgc2VlbXMg DQo+Pj4+Pj4+Pj4+PiB3b3JrYWJsZSAgdG8gIG1lLCBidXQgd2Ugc2hvdWxkIGVuc3VyZSB0aGF0 IHRoZXJlIGFyZSBubw0KPj4+Pj4+Pj4+Pj4gc2lnbmlmaWNhbnQgb2JqZWN0aW9ucy4NCj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4gW0ZhdGFpXSBUaGVyZSBhcmUgdHdvIHVzYWdlcyBmb3IgIiBCaXRf UmF0ZSAiIGZpZWxkIGFzDQo+Pj4+IGRlc2NyaWJlZCANCj4+Pj4+Pj4+Pj4gaW4gdGhlIGxpbmVz IDI4Ny0zMTAuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICgxKSAgICBGb3IgT0RVZmxleChDQlIp LCB0aGUgQml0X1JhdGUgZmllbGQgaW5kaWNhdGVzDQo+Pj4+IHRoZSBub21pbmFsDQo+Pj4+Pj4+ Pj4+IGJpdA0KPj4+Pj4+Pj4+PiByYXRlIG9mIE9EVWZsZXgoQ0JSKSBleHByZXNzZWQgaW4gYnl0 ZXMgcGVyIHNlY29uZCwNCj4+Pj4gZW5jb2RlZCBhcyBhICANCj4+Pj4+Pj4+Pj4gMzItYml0ICBJ RUVFIHNpbmdsZSBwcmVjaXNpb24gZmxvYXRpbmctcG9pbnQgbnVtYmVyLiBGb3IgdGhpcw0KPj4+ Pj4+Pj4+PiBjYXNlLCB3ZSBNVVNUICB1c2UgIDMyLWJpdCBJRUVFIGZsb2F0aW5nIHBvaW50IGlu c3RlYWQgb2YNCj4+Pj4+Pj4+Pj4gIk4iKFBsZWFzZSBzZWUgbW9yZSBpbiBzZWN0aW9uICA1LjEp Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSSBndWVzcyB5b3UgcmVhbGx5IHN0aWxsIG5lZWQgKHRv IGJlIGJhc2VkIG9uKSB0aGUgY2xpZW50IHNpZ25hbA0KPj4+Pj4+Pj4+IHJhdGUgYXQgdGhlIGVk Z2VzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICgyKSAgICBGb3IgT0RVZmxl eChHRlApLCB3ZSBjYW4gY2hhbmdlIHRoZSB0ZXh0ICh0aGUNCj4+Pj4gbGluZXMgZnJvbSAzMDUN Cj4+Pj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+Pj4gMzEwKSBiYXNlZCBvbiB5b3VyIHN1Z2dlc3Rpb24s IGllLiwgdGhlIEJpdF9SYXRlIGZpZWxkDQo+Pj4+IGlzIHVzZWQgdG8gIA0KPj4+Pj4+Pj4+PiBj YXJyeSAgIk4idG8gaW5kaWNhdGUgdGhlIG5vbWluYWwgYml0IHJhdGUgb2YgdGhlICBPRFVmbGV4 KEdGUCkuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBidXQgeW91J3JlIHNheXMgZW5jb2RlZCBhcyAo TipOb21pbmFsIFJhdGUpIHJpZ2h0PyAgV2F0J3MgdGhlDQo+Pj4+Pj4+Pj4gdmFsdWUgb2YgIHRo aXMgdnMganVzdCBjYXJyeWluZyBOPw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4gVGhlcmVmb3JlLCBJIGFtIHByb3Bvc2luZyB1c2luZyBvbmUgc2luZ2xlIGZp bGVkICgiQml0X1JhdGUgIikNCj4+Pj4+Pj4+Pj4gZm9yIHRoZXNlIHR3byBjYXNlcywgaW4gdGhp cyB3YXksIHdlIGNhbiBsZWF2ZSB0aGUgIlJlc2VydmVkIg0KPj4+Pj4+Pj4+PiBiaXRzIGZvciBm dXR1cmUuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBiaXRzIGluIHRoZSBjb250cm9sIHBsYW5lIGFy ZSBnZW5lcmFsbHkgY2hlYXAsIElNTyBpdCdzDQo+Pj4+IGJldHRlciB0byANCj4+Pj4+Pj4+PiBo YXZlICBzaW1wbGVyIGVuY29kaW5nIHRoYW4gdG8gb3B0aW1pemUgZXZlcnkgYml0IChvciA4IGlu IHRoaXMNCj4+Pj4+Pj4+PiBjYXNlKS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IExvdQ0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEhvcGUgd2UgYXJlIG5vdyBhdCB0aGUgc2FtZSBw YWdlLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBCZXN0IFJlZ2FyZHMNCj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gRmF0YWkNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gQ0NB TVAgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+ Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4NCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+ IENDQU1QQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NjYW1wDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiANCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1Q QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo= From db3546@att.com Tue Jan 29 12:26:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF73A21F8816 for ; Tue, 29 Jan 2013 12:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 c1Yv58SIq9XY for ; Tue, 29 Jan 2013 12:26:53 -0800 (PST) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 8E40921F87DF for ; Tue, 29 Jan 2013 12:26:49 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 98038015.0.1127998.00-262.3093823.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 29 Jan 2013 20:26:49 +0000 (UTC) X-MXL-Hash: 51083089110e8735-dd020cf3a2106cc7666ecf566ff0a20835e4bac5 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0TKQmm8018237 for ; Tue, 29 Jan 2013 15:26:49 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r0TKQf8k018121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Jan 2013 15:26:44 -0500 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Tue, 29 Jan 2013 15:26:22 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0328.009; Tue, 29 Jan 2013 15:26:22 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: CCAMP Scheduling for Friday, March 15th Thread-Index: Ac3flfsG4drpzemoTVGskKzfII/fygex61uw Date: Tue, 29 Jan 2013 20:26:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C825A76EMISOUT7MSGUSR9OIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=eNekegV1 c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=BuKsJBZ0LVMA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=18z4aAOSH] X-AnalysisOut: [C4A:10 a=48vgC7mUAAAA:8 a=plWekj9UDMf6GRcLPa0A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA] X-AnalysisOut: [:8 a=mPCUdzpf4J5ai1j0lt0A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S] X-AnalysisOut: [4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=22axUIIUoUKj1m] X-AnalysisOut: [c2:21] Subject: Re: [CCAMP] CCAMP Scheduling for Friday, March 15th X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 20:26:54 -0000 --_000_F64C10EAA68C8044B33656FA214632C825A76EMISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCAMP, The meeting with ITU-T's SG15 Q6 participants has been scheduled for Friday= and we will be meeting with an extended meeting time on Friday afternoon (= beyond the schedule time of 1:30PM). We will circulate an agenda several we= eks before the meeting. We will also have time allocated for a working group meeting to discuss wor= king group business. The agenda will be based on working group documents an= d published individual drafts. Thanks, Deborah (and Lou) From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Friday, December 21, 2012 11:13 AM To: ccamp@ietf.org Subject: [CCAMP] CCAMP Scheduling for Friday, March 15th CCAMP, Don't forget when scheduling your travel plans - CCAMP will be meeting all = day on Friday (both morning and afternoon until approx. 5PM) due to the mee= ting with ITU-T's SG15 Q6 (Optical experts) on our work. Happy Holidays! Deborah (and Lou) --_000_F64C10EAA68C8044B33656FA214632C825A76EMISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

CCAMP,<= /p>

 <= /p>

The meeting with ITU-T= 217;s SG15 Q6 participants has been scheduled for Friday and we will be mee= ting with an extended meeting time on Friday afternoon (beyond the schedule time of 1:30PM). We will circulate an agenda several weeks be= fore the meeting.

 <= /p>

We will also have time al= located for a working group meeting to discuss working group business. The = agenda will be based on working group documents and published individual drafts.

 <= /p>

Thanks,=

Deborah (and Lou)

 <= /p>

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Friday, December 21, 2012 11:13 AM
To: ccamp@ietf.org
Subject: [CCAMP] CCAMP Scheduling for Friday, March 15th<= /span>

 

CCAMP,

 

Don’t forget when scheduling your= travel plans - CCAMP will be meeting all day on Friday (both morning and a= fternoon until approx. 5PM) due to the meeting with ITU-T’s SG15 Q6 (Optical experts) on our work.

 

Happy Holidays!

Deborah (and Lou)

 

 

--_000_F64C10EAA68C8044B33656FA214632C825A76EMISOUT7MSGUSR9OIT_-- From lberger@labn.net Tue Jan 29 13:42:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9BA21F85D9 for ; Tue, 29 Jan 2013 13:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.173 X-Spam-Level: X-Spam-Status: No, score=-101.173 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 f70fw1xOW47x for ; Tue, 29 Jan 2013 13:42:33 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 52EF721F851F for ; Tue, 29 Jan 2013 13:42:33 -0800 (PST) Received: (qmail 8540 invoked by uid 0); 29 Jan 2013 21:42:03 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 29 Jan 2013 21:42:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hQgx7VyhWvlLkLic5wvFlCOqeSB6oI2kSDlejE4quPQ=; b=Hy58iaCMWPQ8VmLU/46bjHDwreuepattCu9Brd2z+xazGzzbGgEVdbmq77Ou/ZcdpOyocdB0h0XdajWhvMIRVuo6WLTQCkUoeYvo8+vUONz7kZCGyoT9JX5GFvemRTrN; Received: from box313.bluehost.com ([69.89.31.113]:58050 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1U0IwN-0002et-4e; Tue, 29 Jan 2013 14:42:03 -0700 Message-ID: <5108422A.3090704@labn.net> Date: Tue, 29 Jan 2013 16:42:02 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Gruman, Fred" References: <5106DED0.3090008@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33126F@RCHEXMBP1.fnc.net.local> <51081917.3080601@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33153D@RCHEXMBP1.fnc.net.local> In-Reply-To: <5DF87403A81B0C43AF3EB1626511B2923C33153D@RCHEXMBP1.fnc.net.local> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 21:42:34 -0000 Fred, Confirmed. Option 2 had a shortened form of the text of option 1 that fully spelled it out. Sorry for the confusion. Lou On 1/29/2013 3:04 PM, Gruman, Fred wrote: > Hi Lou, > > Just to confirm, your option 2 where you state "use a new C-type for OTN-TDM labels", it was not the intent to have a new c-type for the label itself, but a new c-type for the sender-tspec/flowspec (traffic parameters). If so, I misunderstood the option and now understand the proposals. > > Thanks, > Fred > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, January 29, 2013 12:47 PM > To: Gruman, Fred > Cc: Zafar Ali (zali); CCAMP > Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) > > Fred, > Thanks for the input. > > On 1/29/2013 12:54 PM, Gruman, Fred wrote: >> Hi Lou, >> >> I am not clear on option 2 as when I look into draft-ietf-ccamp-gmpls-signaling-g709v3-05, the IANA section shows the c-type for the GENERALIZE_LABEL defined in RFC 3473, not a new c-type. >> >> OTN-TDM Generalized Label Object: >> >> o OTN-TDM Generalized Label Object: Class = 16, C-Type = 2 (see >> Section 5.1) >> > > I didn't notice that inconsistency. Per > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-05#section-5: > The traffic parameters for OTN-TDM capable Switching Type are carried > in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have > the following class and type: > > - OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA) > - OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA) > > Lou > >> I'm open to either carrying ODUflex(GFP) bandwidth as floating-point or integer N, but would like to see consistency between routing and signaling documents. >> >> >> Regards, >> Fred >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali) >> Sent: Tuesday, January 29, 2013 10:41 AM >> To: Lou Berger; CCAMP >> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) >> >> Hi Lou, C-campers: >> >> I would pick Option 2; it's cleaner and addresses the issue related to >> overloading the same c-type. >> >> Thanks >> >> Regards鈥afar >> >> >> -----Original Message----- >> From: "lberger@labn.net" >> Date: Monday, January 28, 2013 3:25 PM >> To: "ccamp@ietf.org" >> Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call >> comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) >> >>> All, >>> We would like to try to close the discussion on the G.709 >>> drafts so that we can move rapidly towards publication request. The >>> discussion of (one of my) LC comments has resulted in several options >>> for the signaling ODU-related traffic parameters, and the point has >>> been raised that realigning routing with signaling should be discussed. >>> >>> Please keep in mind that the objective of any PS is interoperability, >>> and that there may be early implementations that match g709v3-04. >>> >>> The basic question is one of if N, the number of time slots needed to >>> support a ODUflex(GFP) signal, should be carried as a calculated IEEE >>> floating point number or directly. Options 1 and 2 below reflect the >>> former, options 3 and 4 match the latter. It is worth noting that only >>> options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be >>> calculated for ODUflex(CBR) signal types with all options. >>> >>> Please state your support for one the options and, if you wish, the >>> justification for your position: >>> >>> 1) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>> i.e., redefine [RFC4328] Traffic Parameters c-type when used with >>> OTN-TDM labels. ODUflex(GFP) number of tributary slots (N) is >>> encoded as: >>> >>> ... the Bit_Rate field for ODUflex(GFP) MUST >>> equal to one of the 80 values listed below: >>> >>> 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; >>> 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; >>> 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. >>> >>> 2) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-05 >>> i.e., use a new C-type for OTN-TDM labels. Encoding details >>> unchanged from g709v3-04. >>> (This option addresses the issue of the same c-type needing to >>> be parsed based on label/switching type.) >>> >>> 3) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-06 >>> i.e., use a new C-type for OTN-TDM labels. N is directly carried >>> for ODUflex(GFP) only. >>> >>> 4) Discussed, but not in any draft >>> Use draft-ietf-ccamp-gmpls-signaling-g709v3-04 encoding for all >>> but ODUflex(GFP), and define new ODUflex(GFP) specific Traffic >>> Parameters based on g709v3-06, presumably with unused fields >>> removed. >>> (This also addresses the issue of the same c-type needing to be >>> parsed based on label type, but means there are different types >>> based on signal type.) >>> >>> Option 1 and 2 do not imply any changes to routing, while options 3 and >>> 4 may. Routing implications will be discussed based on the results of >>> this poll, and only if there is consensus to support positions 3 or 4. >>> >>> We hope to make a consensus call by the end of the week, but will >>> continue the discussion as needed. >>> >>> Much thanks, >>> Lou (and Deborah) >>> >>> On 1/28/2013 5:08 AM, Daniele Ceccarelli wrote: >>>> All, >>>> >>>> I think the changes proposed are meaningful and would support them in >>>> an individual or early WG draft, but they don't seem to provide >>>> significative advantages to risk interworking issues with early >>>> implementations. >>>> Moreover the changes don't allow us getting totally rid of of the >>>> bit_rate field as it is still needed for ODUflex (CBR). >>>> >>>> My 2c >>>> Daniele >>>> >>>> >>>>> -----Original Message----- >>>>> From: Zafar Ali (zali) [mailto:zali@cisco.com] >>>>> Sent: luned矛 28 gennaio 2013 4.47 >>>>> To: Lou Berger >>>>> Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP; >>>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>> >>>>> Hi Lou- >>>>> >>>>> Please see in-line. >>>>> >>>>> Thanks >>>>> >>>>> Regards...Zafar >>>>> >>>>> On 1/27/13 9:46 PM, "Lou Berger" wrote: >>>>> >>>>>> Zafar, >>>>>> Is your comment with respect to just routing or both >>>>> signaling and >>>>>> routing? >>>>> >>>>> Both, including consistency between signaling and routing attributes. >>>>> >>>>>> >>>>>> Also, when you say "implementations based on draft versions", >>>>> do these >>>>>> implementations include support for ODUflex? (Which has really been >>>>>> the focus of the discussion.) >>>>> >>>>> Yes, I was referring to ODUFlex. As you know, fixed ODU is >>>>> signaled via level (0 BW) so its not an issue. >>>>> >>>>>> >>>>>> BTW I took Fred's comments as related to just the new >>>>> OTN-specific ISCD >>>>>> definitions (section 4.1.2 of ospf-g709v3-05, in particular). Note >>>>>> that section 4.1.1 already carries N (number of ODUs) not >>>>> IEEE floating >>>>>> point representations of available bandwidth. >>>>> >>>>> What I meant is Unreserved Bandwidth at priority x and Max LSP >>>>> Bandwidth at priority x. >>>>> >>>>>> >>>>>> Much thanks, >>>>>> Lou >>>>>> >>>>>> On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote: >>>>>>> All- >>>>>>> >>>>>>> This impacts existing implementations based on draft versions (and >>>>>>> hence interop with these implementations moving forward). >>>>> IMO this is >>>>>>> a bigger change for us to assume at the last call stage. >>>>> Furthermore >>>>>>> we have been using IEEE floating point format for Unreserved >>>>>>> Bandwidth/ Max LSP BW in IEEE floating point format for other >>>>>>> technologies. Overall, I think this change suffers from the >>>>> "law of diminishing returns". >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Regards 艩 Zafar >>>>>>> >>>>>>> >>>>>>> On 1/27/13 10:28 AM, "Gruman, Fred" >>>>> wrote: >>>>>>> >>>>>>>> Hi Lou, Fatai, Daniele, >>>>>>>> >>>>>>>> I understand the latest change to the way bandwidth is >>>>> signaled for >>>>>>>> ODUflex(GFP), i.e., signaling the number of tributary slots >>>>> N instead >>>>>>>> of the bandwidth rate in bps. I believe that this simplifies the >>>>>>>> signaling and interoperability so I'm in agreement with >>>>> this change. >>>>>>>> >>>>>>>> However, it seems we are now inconsistent between how we >>>>> represent >>>>>>>> bandwidth in routing and signaling for ODUflex(GFP). Routing >>>>>>>> advertises the bandwidth using a floating point representation of >>>>>>>> bandwidth, while signaling is using the number of tributary slots. >>>>>>>> It seems the same benefits would be obtained by >>>>> advertising the max >>>>>>>> LSP bandwidth and unreserved bandwidth for ODUflex(GFP) in >>>>> terms of >>>>>>>> the number of tributary slots. >>>>>>>> >>>>>>>> Fred >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>>>> Behalf Of Lou Berger >>>>>>>> Sent: Wednesday, January 23, 2013 9:08 AM >>>>>>>> To: Fatai Zhang >>>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>> >>>>>>>> Fatai, >>>>>>>> >>>>>>>> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>>>>>>>> Hi Lou, >>>>>>>>> >>>>>>>>> For ODUflex(CBR), the formula is from [G.709-2012] and it >>>>> has been >>>>>>>>> discussed before, so please trust that there is no >>>>> opportunity for >>>>>>>>> misinterpretation. (Note that there are two cases, one is >>>>>>>>> ODUflex(CBR) and another one is ODUflex(GFP)). >>>>>>>>> >>>>>>>>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >>>>>>>> >>>>>>>> Thanks for confirming my understanding. This raises the >>>>> question of >>>>>>>> if the new traffic should just apply to ODUFlex? Correct >>>>> me if I'm >>>>>>>> wrong, but I believe the [RFC4328] is sufficient in all >>>>> other cases. >>>>>>>> This may also make it easier for early implementations of >>>>> the draft >>>>>>>> as then they can limit code changes from the (-03) rev to >>>>> only ODUflex LSPs. >>>>>>>> >>>>>>>> Just to be clear, I'm really just *asking* about this. As I said >>>>>>>> before, I'm open on specifics... >>>>>>>> >>>>>>>> Any thoughts/comments? Authors? Implementors? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lou >>>>>>>> >>>>>>>> >>>>>>>>> I will issue a new version tomorrow to capture all your comments. >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> >>>>>>>>> Fatai >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>> Sent: Wednesday, January 23, 2013 2:11 AM >>>>>>>>> To: Fatai Zhang >>>>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>>> >>>>>>>>> Fatai, >>>>>>>>> >>>>>>>>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>>>>>>>> Hi Lou, >>>>>>>>>> >>>>>>>>>> You said: >>>>>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>>>>> value of this vs just carrying N? >>>>>>>>>> >>>>>>>>>> [Fatai] The original way (in version 04&05) is putting >>>>> (N* Nominal >>>>>>>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we >>>>>>>>>> can generalize to just use one single "Bit_Rate" field to carry >>>>>>>>>> IEEE float number for both cases, it seems that you >>>>> don't agree on >>>>>>>>>> this value, :-) >>>>>>>>> >>>>>>>>> I've seen differences in calculated floating point values from >>>>>>>>> different implementations, so I just want to ensure that >>>>> such cases >>>>>>>>> are avoided. >>>>>>>>> I'm open to specific solutions and certainly will deffer on the >>>>>>>>> specifics assuming there is no opportunity for >>>>>>>>> misinterpretation/interop issues. I don't think the >>>>> original passed >>>>>>>>> this threshold, i.e.,: >>>>>>>>> >>>>>>>>> N = Ceiling of >>>>>>>>> >>>>>>>>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate >>>>>>>>> tolerance) >>>>>>>>> >>>>>>>>> ----------------------------------------------------------- >>>>> ---------- >>>>>>>>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate >>>>> tolerance) >>>>>>>>> >>>>>>>>>> . Therefore, I (was) am saying that I am going to accept your >>>>>>>>>> suggestion to carry N for ODUflex(GFP). We are >>>>> discussing where to >>>>>>>>>> put N for ODUflex(GFP). >>>>>>>>>> >>>>>>>>> >>>>>>>>>> You said: >>>>>>>>>>> bits in the control plane are generally cheap, IMO it's >>>>> better to >>>>>>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>>>>>> case). >>>>>>>>>> >>>>>>>>>> [Fatai] OK, I will add a new field (to occupy the reserved bits) >>>>>>>>>> to carry N. >>>>>>>>> >>>>>>>>> As you see fit. >>>>>>>>> >>>>>>>>> Just to clarify my understanding, ODUflex and Virtual >>>>> concatenation >>>>>>>>> can never be combined for the same signal type/level, right? >>>>>>>>> (Although an ODUflex client signal could be carried over >>>>> a virtual >>>>>>>>> concatenated ODUk). Is this correct or did I miss something in >>>>>>>>> G709? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Lou >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best Regards >>>>>>>>>> >>>>>>>>>> Fatai >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>>> Sent: Friday, January 18, 2013 1:42 AM >>>>>>>>>> To: Fatai Zhang >>>>>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>>>>>>>> Hi Lou, >>>>>>>>>>> >>>>>>>>>>> To avoid misunderstanding, I would like to clarify more on the >>>>>>>>>>> following point. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> It is better to have consistent format and the same meaning >>>>>>>>>>>>>>> of one >>>>>>>>>> field for both ODUflex(CBR) and GFP. This is why we have section >>>>>>>>>> 5.1 >>>>>>>>>> &5.2 to describe the complex stuff. >>>>>>>>>>>>>> I actually wasn't suggesting that N be carried in >>>>> the bit rate >>>>>>>>>>>>>> field. >>>>>>>>>>>>>> The bit rate field can either be set as described or to zero >>>>>>>>>>>>>> (i.e., ignored). At the time, I was thinking about >>>>> carrying N >>>>>>>>>>>>>> in the reserved field. But perhaps the right place >>>>> is MT, if >>>>>>>>>>>>>> my understanding is right (would always be 1 >>>>> otherwise). I'm >>>>>>>>>>>>>> open to either... >>>>>>>>>>>>>> >>>>>>>>>>>>> [Fatai] Why not just use "bit rate"field to carry >>>>> "N"because "N" >>>>>>>>>>>>> implies bit rate? I am OK if you like to use a new >>>>> filed (like >>>>>>>>>>>>> "TS >>>>>>>>>>>>> Number") to occupy the reserved field even though >>>>> that I prefer >>>>>>>>>>>>> the original approach (ie., use "bit rate"field to carry "N"). >>>>>>>>>>>> >>>>>>>>>>>> Are you proposing dropping carrying bit rates >>>>> represented as an >>>>>>>>>>>> IEEE floating point and just carrying N for ODUflex? >>>>> This seems >>>>>>>>>>>> workable to me, but we should ensure that there are no >>>>>>>>>>>> significant objections. >>>>>>>>>>> >>>>>>>>>>> [Fatai] There are two usages for " Bit_Rate " field as >>>>> described >>>>>>>>>>> in the lines 287-310. >>>>>>>>>>> >>>>>>>>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates >>>>> the nominal >>>>>>>>>>> bit >>>>>>>>>>> rate of ODUflex(CBR) expressed in bytes per second, >>>>> encoded as a >>>>>>>>>>> 32-bit IEEE single precision floating-point number. For this >>>>>>>>>>> case, we MUST use 32-bit IEEE floating point instead of >>>>>>>>>>> "N"(Please see more in section 5.1). >>>>>>>>>> >>>>>>>>>> I guess you really still need (to be based on) the client signal >>>>>>>>>> rate at the edges. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (2) For ODUflex(GFP), we can change the text (the >>>>> lines from 305 >>>>>>>>>>> to >>>>>>>>>>> 310) based on your suggestion, ie., the Bit_Rate field >>>>> is used to >>>>>>>>>>> carry "N"to indicate the nominal bit rate of the ODUflex(GFP). >>>>>>>>>> >>>>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>>>> value of this vs just carrying N? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") >>>>>>>>>>> for these two cases, in this way, we can leave the "Reserved" >>>>>>>>>>> bits for future. >>>>>>>>>> >>>>>>>>>> bits in the control plane are generally cheap, IMO it's >>>>> better to >>>>>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>>>>> case). >>>>>>>>>> >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hope we are now at the same page. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best Regards >>>>>>>>>>> >>>>>>>>>>> Fatai >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> From lberger@labn.net Tue Jan 29 13:47:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F7D21F883C for ; Tue, 29 Jan 2013 13:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.167 X-Spam-Level: X-Spam-Status: No, score=-101.167 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 UTCBT1Py78ai for ; Tue, 29 Jan 2013 13:47:57 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 9B62021F8550 for ; Tue, 29 Jan 2013 13:47:57 -0800 (PST) Received: (qmail 23067 invoked by uid 0); 29 Jan 2013 21:47:31 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 29 Jan 2013 21:47:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=eYm3Qr4ApI+jLxYu/tPNb5QJ8YTlcQY0iCb/YKHhOUc=; b=BCtNwqae1Xq+KF42GGTuV88I+T+Lag/7s+VpnHdrIjwu3JebaXSTbIVS8RcCH/0lsbeiewrsZmURyb6VsA0lRYBT2ktPVONtor0+Fa47KPqtdlDleT+VlsqG00gnHSjD; Received: from box313.bluehost.com ([69.89.31.113]:58789 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1U0J1c-0008Aj-VM; Tue, 29 Jan 2013 14:47:29 -0700 Message-ID: <51084370.4020600@labn.net> Date: Tue, 29 Jan 2013 16:47:28 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" References: <5DF87403A81B0C43AF3EB1626511B2923C331576@RCHEXMBP1.fnc.net.local> In-Reply-To: <5DF87403A81B0C43AF3EB1626511B2923C331576@RCHEXMBP1.fnc.net.local> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <5DF87403A81B0C43AF3EB1626511B2923C331576@RCHEXMBP1.fnc.net.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: [CCAMP] Fwd: RE: Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 21:47:59 -0000 Authors, Please respond to Fred anytime you're ready, but please do update the subject line as appropriate (as the comment has little to do with the poll). Also ensure the next rev of the draft includes any necessary update. Thanks, Lou -------- Original Message -------- Subject: RE: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Date: Tue, 29 Jan 2013 20:09:13 +0000 From: Gruman, Fred To: Gruman, Fred , Lou Berger CC: CCAMP As an additional item, if we are planning to reuse existing IANA codepoint for the GENERALIZED_LABEL, why are we listing OTN-TDM Generalized Label Object in the IANA section? This appears to imply that we are asking for a new IANA assignment, which is not the case for the label object. Further the reference to Section 5.1 does not have anything to do with the label but traffic parameters. Regards, Fred -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Gruman, Fred Sent: Tuesday, January 29, 2013 2:05 PM To: Lou Berger Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Hi Lou, Just to confirm, your option 2 where you state "use a new C-type for OTN-TDM labels", it was not the intent to have a new c-type for the label itself, but a new c-type for the sender-tspec/flowspec (traffic parameters). If so, I misunderstood the option and now understand the proposals. Thanks, Fred -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Tuesday, January 29, 2013 12:47 PM To: Gruman, Fred Cc: Zafar Ali (zali); CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Fred, Thanks for the input. On 1/29/2013 12:54 PM, Gruman, Fred wrote: > Hi Lou, > > I am not clear on option 2 as when I look into draft-ietf-ccamp-gmpls-signaling-g709v3-05, the IANA section shows the c-type for the GENERALIZE_LABEL defined in RFC 3473, not a new c-type. > > OTN-TDM Generalized Label Object: > > o OTN-TDM Generalized Label Object: Class = 16, C-Type = 2 (see > Section 5.1) > I didn't notice that inconsistency. Per http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-05#section-5: The traffic parameters for OTN-TDM capable Switching Type are carried in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have the following class and type: - OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA) - OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA) Lou > I'm open to either carrying ODUflex(GFP) bandwidth as floating-point or integer N, but would like to see consistency between routing and signaling documents. > > > Regards, > Fred > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali) > Sent: Tuesday, January 29, 2013 10:41 AM > To: Lou Berger; CCAMP > Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) > > Hi Lou, C-campers: > > I would pick Option 2; it's cleaner and addresses the issue related to > overloading the same c-type. > > Thanks > > Regards鈥afar > > > -----Original Message----- > From: "lberger@labn.net" > Date: Monday, January 28, 2013 3:25 PM > To: "ccamp@ietf.org" > Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call > comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) > >> All, >> We would like to try to close the discussion on the G.709 >> drafts so that we can move rapidly towards publication request. The >> discussion of (one of my) LC comments has resulted in several options >> for the signaling ODU-related traffic parameters, and the point has >> been raised that realigning routing with signaling should be discussed. >> >> Please keep in mind that the objective of any PS is interoperability, >> and that there may be early implementations that match g709v3-04. >> >> The basic question is one of if N, the number of time slots needed to >> support a ODUflex(GFP) signal, should be carried as a calculated IEEE >> floating point number or directly. Options 1 and 2 below reflect the >> former, options 3 and 4 match the latter. It is worth noting that only >> options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be >> calculated for ODUflex(CBR) signal types with all options. >> >> Please state your support for one the options and, if you wish, the >> justification for your position: >> >> 1) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-04 >> i.e., redefine [RFC4328] Traffic Parameters c-type when used with >> OTN-TDM labels. ODUflex(GFP) number of tributary slots (N) is >> encoded as: >> >> ... the Bit_Rate field for ODUflex(GFP) MUST >> equal to one of the 80 values listed below: >> >> 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; >> 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; >> 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. >> >> 2) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-05 >> i.e., use a new C-type for OTN-TDM labels. Encoding details >> unchanged from g709v3-04. >> (This option addresses the issue of the same c-type needing to >> be parsed based on label/switching type.) >> >> 3) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-06 >> i.e., use a new C-type for OTN-TDM labels. N is directly carried >> for ODUflex(GFP) only. >> >> 4) Discussed, but not in any draft >> Use draft-ietf-ccamp-gmpls-signaling-g709v3-04 encoding for all >> but ODUflex(GFP), and define new ODUflex(GFP) specific Traffic >> Parameters based on g709v3-06, presumably with unused fields >> removed. >> (This also addresses the issue of the same c-type needing to be >> parsed based on label type, but means there are different types >> based on signal type.) >> >> Option 1 and 2 do not imply any changes to routing, while options 3 and >> 4 may. Routing implications will be discussed based on the results of >> this poll, and only if there is consensus to support positions 3 or 4. >> >> We hope to make a consensus call by the end of the week, but will >> continue the discussion as needed. >> >> Much thanks, >> Lou (and Deborah) >> >> On 1/28/2013 5:08 AM, Daniele Ceccarelli wrote: >>> All, >>> >>> I think the changes proposed are meaningful and would support them in >>> an individual or early WG draft, but they don't seem to provide >>> significative advantages to risk interworking issues with early >>> implementations. >>> Moreover the changes don't allow us getting totally rid of of the >>> bit_rate field as it is still needed for ODUflex (CBR). >>> >>> My 2c >>> Daniele >>> >>> >>>> -----Original Message----- >>>> From: Zafar Ali (zali) [mailto:zali@cisco.com] >>>> Sent: luned矛 28 gennaio 2013 4.47 >>>> To: Lou Berger >>>> Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP; >>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>> Subject: Re: [CCAMP] WG Last Call comments on >>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>> >>>> Hi Lou- >>>> >>>> Please see in-line. >>>> >>>> Thanks >>>> >>>> Regards...Zafar >>>> >>>> On 1/27/13 9:46 PM, "Lou Berger" wrote: >>>> >>>>> Zafar, >>>>> Is your comment with respect to just routing or both >>>> signaling and >>>>> routing? >>>> >>>> Both, including consistency between signaling and routing attributes. >>>> >>>>> >>>>> Also, when you say "implementations based on draft versions", >>>> do these >>>>> implementations include support for ODUflex? (Which has really been >>>>> the focus of the discussion.) >>>> >>>> Yes, I was referring to ODUFlex. As you know, fixed ODU is >>>> signaled via level (0 BW) so its not an issue. >>>> >>>>> >>>>> BTW I took Fred's comments as related to just the new >>>> OTN-specific ISCD >>>>> definitions (section 4.1.2 of ospf-g709v3-05, in particular). Note >>>>> that section 4.1.1 already carries N (number of ODUs) not >>>> IEEE floating >>>>> point representations of available bandwidth. >>>> >>>> What I meant is Unreserved Bandwidth at priority x and Max LSP >>>> Bandwidth at priority x. >>>> >>>>> >>>>> Much thanks, >>>>> Lou >>>>> >>>>> On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote: >>>>>> All- >>>>>> >>>>>> This impacts existing implementations based on draft versions (and >>>>>> hence interop with these implementations moving forward). >>>> IMO this is >>>>>> a bigger change for us to assume at the last call stage. >>>> Furthermore >>>>>> we have been using IEEE floating point format for Unreserved >>>>>> Bandwidth/ Max LSP BW in IEEE floating point format for other >>>>>> technologies. Overall, I think this change suffers from the >>>> "law of diminishing returns". >>>>>> >>>>>> Thanks >>>>>> >>>>>> Regards 艩 Zafar >>>>>> >>>>>> >>>>>> On 1/27/13 10:28 AM, "Gruman, Fred" >>>> wrote: >>>>>> >>>>>>> Hi Lou, Fatai, Daniele, >>>>>>> >>>>>>> I understand the latest change to the way bandwidth is >>>> signaled for >>>>>>> ODUflex(GFP), i.e., signaling the number of tributary slots >>>> N instead >>>>>>> of the bandwidth rate in bps. I believe that this simplifies the >>>>>>> signaling and interoperability so I'm in agreement with >>>> this change. >>>>>>> >>>>>>> However, it seems we are now inconsistent between how we >>>> represent >>>>>>> bandwidth in routing and signaling for ODUflex(GFP). Routing >>>>>>> advertises the bandwidth using a floating point representation of >>>>>>> bandwidth, while signaling is using the number of tributary slots. >>>>>>> It seems the same benefits would be obtained by >>>> advertising the max >>>>>>> LSP bandwidth and unreserved bandwidth for ODUflex(GFP) in >>>> terms of >>>>>>> the number of tributary slots. >>>>>>> >>>>>>> Fred >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>>> Behalf Of Lou Berger >>>>>>> Sent: Wednesday, January 23, 2013 9:08 AM >>>>>>> To: Fatai Zhang >>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>> >>>>>>> Fatai, >>>>>>> >>>>>>> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>>>>>>> Hi Lou, >>>>>>>> >>>>>>>> For ODUflex(CBR), the formula is from [G.709-2012] and it >>>> has been >>>>>>>> discussed before, so please trust that there is no >>>> opportunity for >>>>>>>> misinterpretation. (Note that there are two cases, one is >>>>>>>> ODUflex(CBR) and another one is ODUflex(GFP)). >>>>>>>> >>>>>>>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >>>>>>> >>>>>>> Thanks for confirming my understanding. This raises the >>>> question of >>>>>>> if the new traffic should just apply to ODUFlex? Correct >>>> me if I'm >>>>>>> wrong, but I believe the [RFC4328] is sufficient in all >>>> other cases. >>>>>>> This may also make it easier for early implementations of >>>> the draft >>>>>>> as then they can limit code changes from the (-03) rev to >>>> only ODUflex LSPs. >>>>>>> >>>>>>> Just to be clear, I'm really just *asking* about this. As I said >>>>>>> before, I'm open on specifics... >>>>>>> >>>>>>> Any thoughts/comments? Authors? Implementors? >>>>>>> >>>>>>> Thanks, >>>>>>> Lou >>>>>>> >>>>>>> >>>>>>>> I will issue a new version tomorrow to capture all your comments. >>>>>>>> >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Fatai >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>> Sent: Wednesday, January 23, 2013 2:11 AM >>>>>>>> To: Fatai Zhang >>>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>> >>>>>>>> Fatai, >>>>>>>> >>>>>>>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>>>>>>> Hi Lou, >>>>>>>>> >>>>>>>>> You said: >>>>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>>>> value of this vs just carrying N? >>>>>>>>> >>>>>>>>> [Fatai] The original way (in version 04&05) is putting >>>> (N* Nominal >>>>>>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we >>>>>>>>> can generalize to just use one single "Bit_Rate" field to carry >>>>>>>>> IEEE float number for both cases, it seems that you >>>> don't agree on >>>>>>>>> this value, :-) >>>>>>>> >>>>>>>> I've seen differences in calculated floating point values from >>>>>>>> different implementations, so I just want to ensure that >>>> such cases >>>>>>>> are avoided. >>>>>>>> I'm open to specific solutions and certainly will deffer on the >>>>>>>> specifics assuming there is no opportunity for >>>>>>>> misinterpretation/interop issues. I don't think the >>>> original passed >>>>>>>> this threshold, i.e.,: >>>>>>>> >>>>>>>> N = Ceiling of >>>>>>>> >>>>>>>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate >>>>>>>> tolerance) >>>>>>>> >>>>>>>> ----------------------------------------------------------- >>>> ---------- >>>>>>>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate >>>> tolerance) >>>>>>>> >>>>>>>>> . Therefore, I (was) am saying that I am going to accept your >>>>>>>>> suggestion to carry N for ODUflex(GFP). We are >>>> discussing where to >>>>>>>>> put N for ODUflex(GFP). >>>>>>>>> >>>>>>>> >>>>>>>>> You said: >>>>>>>>>> bits in the control plane are generally cheap, IMO it's >>>> better to >>>>>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>>>>> case). >>>>>>>>> >>>>>>>>> [Fatai] OK, I will add a new field (to occupy the reserved bits) >>>>>>>>> to carry N. >>>>>>>> >>>>>>>> As you see fit. >>>>>>>> >>>>>>>> Just to clarify my understanding, ODUflex and Virtual >>>> concatenation >>>>>>>> can never be combined for the same signal type/level, right? >>>>>>>> (Although an ODUflex client signal could be carried over >>>> a virtual >>>>>>>> concatenated ODUk). Is this correct or did I miss something in >>>>>>>> G709? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lou >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> >>>>>>>>> Fatai >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>> Sent: Friday, January 18, 2013 1:42 AM >>>>>>>>> To: Fatai Zhang >>>>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>>>>>>> Hi Lou, >>>>>>>>>> >>>>>>>>>> To avoid misunderstanding, I would like to clarify more on the >>>>>>>>>> following point. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> It is better to have consistent format and the same meaning >>>>>>>>>>>>>> of one >>>>>>>>> field for both ODUflex(CBR) and GFP. This is why we have section >>>>>>>>> 5.1 >>>>>>>>> &5.2 to describe the complex stuff. >>>>>>>>>>>>> I actually wasn't suggesting that N be carried in >>>> the bit rate >>>>>>>>>>>>> field. >>>>>>>>>>>>> The bit rate field can either be set as described or to zero >>>>>>>>>>>>> (i.e., ignored). At the time, I was thinking about >>>> carrying N >>>>>>>>>>>>> in the reserved field. But perhaps the right place >>>> is MT, if >>>>>>>>>>>>> my understanding is right (would always be 1 >>>> otherwise). I'm >>>>>>>>>>>>> open to either... >>>>>>>>>>>>> >>>>>>>>>>>> [Fatai] Why not just use "bit rate"field to carry >>>> "N"because "N" >>>>>>>>>>>> implies bit rate? I am OK if you like to use a new >>>> filed (like >>>>>>>>>>>> "TS >>>>>>>>>>>> Number") to occupy the reserved field even though >>>> that I prefer >>>>>>>>>>>> the original approach (ie., use "bit rate"field to carry "N"). >>>>>>>>>>> >>>>>>>>>>> Are you proposing dropping carrying bit rates >>>> represented as an >>>>>>>>>>> IEEE floating point and just carrying N for ODUflex? >>>> This seems >>>>>>>>>>> workable to me, but we should ensure that there are no >>>>>>>>>>> significant objections. >>>>>>>>>> >>>>>>>>>> [Fatai] There are two usages for " Bit_Rate " field as >>>> described >>>>>>>>>> in the lines 287-310. >>>>>>>>>> >>>>>>>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates >>>> the nominal >>>>>>>>>> bit >>>>>>>>>> rate of ODUflex(CBR) expressed in bytes per second, >>>> encoded as a >>>>>>>>>> 32-bit IEEE single precision floating-point number. For this >>>>>>>>>> case, we MUST use 32-bit IEEE floating point instead of >>>>>>>>>> "N"(Please see more in section 5.1). >>>>>>>>> >>>>>>>>> I guess you really still need (to be based on) the client signal >>>>>>>>> rate at the edges. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> (2) For ODUflex(GFP), we can change the text (the >>>> lines from 305 >>>>>>>>>> to >>>>>>>>>> 310) based on your suggestion, ie., the Bit_Rate field >>>> is used to >>>>>>>>>> carry "N"to indicate the nominal bit rate of the ODUflex(GFP). >>>>>>>>> >>>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>>> value of this vs just carrying N? >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") >>>>>>>>>> for these two cases, in this way, we can leave the "Reserved" >>>>>>>>>> bits for future. >>>>>>>>> >>>>>>>>> bits in the control plane are generally cheap, IMO it's >>>> better to >>>>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>>>> case). >>>>>>>>> >>>>>>>>> Lou >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hope we are now at the same page. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best Regards >>>>>>>>>> >>>>>>>>>> Fatai >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From ta-miyasaka@kddi.com Tue Jan 29 16:52:46 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42CA21F8717 for ; Tue, 29 Jan 2013 16:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 duIHwHkPFs+k for ; Tue, 29 Jan 2013 16:52:45 -0800 (PST) Received: from UTMC1101.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDF921F870E for ; Tue, 29 Jan 2013 16:52:44 -0800 (PST) Received: from UTMC1135 (unknown [10.5.16.204]) by UTMC1101.kddi.com (Postfix) with SMTP id 8557212EA; Wed, 30 Jan 2013 09:52:36 +0900 (JST) Received: from UTMC1122.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id D67F21A27; Wed, 30 Jan 2013 09:52:30 +0900 (JST) Received: from LTMC1005.kddi.com (unknown [10.5.16.216]) by UTMC1122.kddi.com (Postfix) with ESMTP id C671F1A1C; Wed, 30 Jan 2013 09:52:30 +0900 (JST) Received: from LTMC1005.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id r0U0qUTD001117; Wed, 30 Jan 2013 09:52:30 +0900 Received: from LTMC1005.kddi.com.mid_14511660 (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id r0U0gRic025133; Wed, 30 Jan 2013 09:42:28 +0900 Received: from KDDI-0705PC0198 ([10.200.129.56] [10.200.129.56]) by post-zip.kddi.com with ESMTPA; Wed, 30 Jan 2013 09:42:27 +0900 To: db3546@att.com From: Takuya Miyasaka References: <2FE467D3673DCE409A84D67EC2F607BB0F723897@xmb-rcd-x10.cisco.com> In-Reply-To: <2FE467D3673DCE409A84D67EC2F607BB0F723897@xmb-rcd-x10.cisco.com> Message-Id: <201301300942.CJI43212.BTZBLUBtNBJ@kddi.com> X-Mailer: Winbiff [Version 2.51 PL4] X-Accept-Language: ja,en,zh Date: Wed, 30 Jan 2013 09:42:27 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-SA-MID: 14511660 X-WAuditID: 1301300952310000514989 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 00:52:46 -0000 Yes/support Takuya Miyasaka > On Jan 24, 2013, at 1:47 PM, "BRUNGARD, DEBORAH A" > > wrote: > > All, > > This is start a two week poll on making draft-ali-ccamp-te-metric-recording- 03 a ccamp working group document. Please send email to the list indicating Yes/support$B!&(Bor No/do not support$B!&(B If indicating no, please state your technical reservations with the document. > > The poll ends Thursday, Feb. 7th. > > Note, as stated by some of the authors, there is IPR $BET(Btill being documented $B!&(B > > Thanks, > Deborah and Lou > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From ta-miyasaka@kddi.com Tue Jan 29 16:55:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CFE21F8727 for ; Tue, 29 Jan 2013 16:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zT3HG9KmC005 for ; Tue, 29 Jan 2013 16:55:00 -0800 (PST) Received: from UTMC1102.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 636C621F870E for ; Tue, 29 Jan 2013 16:55:00 -0800 (PST) Received: from UTMC1131 (unknown [10.5.16.192]) by UTMC1102.kddi.com (Postfix) with SMTP id 926A92CC4; Wed, 30 Jan 2013 09:54:59 +0900 (JST) Received: from UTMC1123.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id E49501C36; Wed, 30 Jan 2013 09:54:52 +0900 (JST) Received: from LTMC1006.kddi.com (unknown [10.5.16.217]) by UTMC1123.kddi.com (Postfix) with ESMTP id D0AB619C0; Wed, 30 Jan 2013 09:54:52 +0900 (JST) Received: from LTMC1006.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r0U0sqIm002161; Wed, 30 Jan 2013 09:54:52 +0900 Received: from LTMC1006.kddi.com.mid_14300112 (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r0U0il5l019231; Wed, 30 Jan 2013 09:44:47 +0900 Received: from KDDI-0705PC0198 ([10.200.129.56] [10.200.129.56]) by post-zip.kddi.com with ESMTPA; Wed, 30 Jan 2013 09:44:47 +0900 To: db3546@att.com From: Takuya Miyasaka References: <201301300934.BHD34843.NVLFJLBLt@kddi.com> In-Reply-To: <201301300934.BHD34843.NVLFJLBLt@kddi.com> Message-Id: <201301300944.AFD51016.BtLBBUTNBZJ@kddi.com> X-Mailer: Winbiff [Version 2.51 PL4] X-Accept-Language: ja,en,zh Date: Wed, 30 Jan 2013 09:44:47 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SA-MID: 14300112 X-WAuditID: 1301300954530000102851 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WGdocument X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 00:55:02 -0000 yes/support Takuya Miyasaka > > All, > > This is start a two week poll on making draft-ali-ccamp-xro-lsp- > subobject-02 a ccamp working group document. Please send email > to the list indicating "yes/support" or "no/do not support". If > indicating no, please state your technical reservations with the > document. > > The poll ends Thursday, January 31st. > > Note, as stated by some of the authors, IPR has been disclosed > in compliance with IETF IPR rules. > > Thanks, > Deborah and Lou > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > ------- End of Forwarded Message > > > > All, > > This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. Please send email to the list indicating "yes /support" or "no/do not support". If indicating no, please state your technical reservations with the document. > > The poll ends Thursday, January 31st. > > Note, as stated by some of the authors, IPR has been disclosed in compliance with IETF IPR rules. > > Thanks, > Deborah and Lou > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From zhangfatai@huawei.com Tue Jan 29 18:56:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A692421F883C for ; Tue, 29 Jan 2013 18:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.439 X-Spam-Level: X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 ayNRGPLB-kl9 for ; Tue, 29 Jan 2013 18:56:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5307321F8816 for ; Tue, 29 Jan 2013 18:56:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APF71557; Wed, 30 Jan 2013 02:56:22 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 30 Jan 2013 02:55:45 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 30 Jan 2013 10:56:20 +0800 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Wed, 30 Jan 2013 10:56:15 +0800 From: Fatai Zhang To: "Gruman, Fred" , Lou Berger Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-06 Thread-Index: AQHN/pVeX0YZHv1Mk0KMGHme+zpZ5w== Date: Wed, 30 Jan 2013 02:56:14 +0000 Message-ID: References: <5106DED0.3090008@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33126F@RCHEXMBP1.fnc.net.local> <51081917.3080601@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33153D@RCHEXMBP1.fnc.net.local> <5DF87403A81B0C43AF3EB1626511B2923C331576@RCHEXMBP1.fnc.net.local> In-Reply-To: <5DF87403A81B0C43AF3EB1626511B2923C331576@RCHEXMBP1.fnc.net.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-06 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 02:56:27 -0000 SGkgRnJlZCwNCg0KWW91IGFyZSByaWdodCwgdGhpcyBpcyBhIGxlZ2FjeSBlcnJvci4gDQoNCkkg d2lsbCByZW1vdmUgT1ROLVRETSBHZW5lcmFsaXplZCBMYWJlbCBPYmplY3QgZnJvbSBJQU5BIHNl Y3Rpb24uDQoNCg0KDQpCZXN0IFJlZ2FyZHMNCg0KRmF0YWkNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcnVtYW4sIEZyZWQNClNlbnQ6IFdlZG5lc2Rh eSwgSmFudWFyeSAzMCwgMjAxMyA0OjA5IEFNDQpUbzogR3J1bWFuLCBGcmVkOyBMb3UgQmVyZ2Vy DQpDYzogQ0NBTVANClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFBvbGwgb24gT0RVRmxleC1yZWxhdGVk IGVuY29kaW5nICh3YXM6IFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1w LWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQpDQoNCg0KQXMgYW4gYWRkaXRpb25hbCBpdGVtLCBp ZiB3ZSBhcmUgcGxhbm5pbmcgdG8gcmV1c2UgZXhpc3RpbmcgSUFOQSBjb2RlcG9pbnQgZm9yIHRo ZSBHRU5FUkFMSVpFRF9MQUJFTCwgd2h5IGFyZSB3ZSBsaXN0aW5nIE9UTi1URE0gR2VuZXJhbGl6 ZWQgTGFiZWwgT2JqZWN0IGluIHRoZSBJQU5BIHNlY3Rpb24/ICBUaGlzIGFwcGVhcnMgdG8gaW1w bHkgdGhhdCB3ZSBhcmUgYXNraW5nIGZvciBhIG5ldyBJQU5BIGFzc2lnbm1lbnQsIHdoaWNoIGlz IG5vdCB0aGUgY2FzZSBmb3IgdGhlIGxhYmVsIG9iamVjdC4gIEZ1cnRoZXIgdGhlIHJlZmVyZW5j ZSB0byBTZWN0aW9uIDUuMSBkb2VzIG5vdCBoYXZlIGFueXRoaW5nIHRvIGRvIHdpdGggdGhlIGxh YmVsIGJ1dCB0cmFmZmljIHBhcmFtZXRlcnMuDQoNClJlZ2FyZHMsDQpGcmVkDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdydW1hbiwgRnJlZA0KU2VudDog VHVlc2RheSwgSmFudWFyeSAyOSwgMjAxMyAyOjA1IFBNDQpUbzogTG91IEJlcmdlcg0KQ2M6IEND QU1QDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBQb2xsIG9uIE9EVUZsZXgtcmVsYXRlZCBlbmNvZGlu ZyAod2FzOiBXRyBMYXN0IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1z aWduYWxpbmctZzcwOXYzLTA0KQ0KDQpIaSBMb3UsDQoNCkp1c3QgdG8gY29uZmlybSwgeW91ciBv cHRpb24gMiB3aGVyZSB5b3Ugc3RhdGUgInVzZSBhIG5ldyBDLXR5cGUgZm9yIE9UTi1URE0gbGFi ZWxzIiwgaXQgd2FzIG5vdCB0aGUgaW50ZW50IHRvIGhhdmUgYSBuZXcgYy10eXBlIGZvciB0aGUg bGFiZWwgaXRzZWxmLCBidXQgYSBuZXcgYy10eXBlIGZvciB0aGUgc2VuZGVyLXRzcGVjL2Zsb3dz cGVjICh0cmFmZmljIHBhcmFtZXRlcnMpLiBJZiBzbywgSSBtaXN1bmRlcnN0b29kIHRoZSBvcHRp b24gYW5kIG5vdyB1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbHMuDQoNClRoYW5rcywNCkZyZWQNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVy Z2VyQGxhYm4ubmV0XSANClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjksIDIwMTMgMTI6NDcgUE0N ClRvOiBHcnVtYW4sIEZyZWQNCkNjOiBaYWZhciBBbGkgKHphbGkpOyBDQ0FNUA0KU3ViamVjdDog UmU6IFtDQ0FNUF0gUG9sbCBvbiBPRFVGbGV4LXJlbGF0ZWQgZW5jb2RpbmcgKHdhczogV0cgTGFz dCBDYWxsIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2 My0wNCkNCg0KRnJlZCwNCglUaGFua3MgZm9yIHRoZSBpbnB1dC4NCg0KT24gMS8yOS8yMDEzIDEy OjU0IFBNLCBHcnVtYW4sIEZyZWQgd3JvdGU6DQo+IEhpIExvdSwNCj4gDQo+IEkgYW0gbm90IGNs ZWFyIG9uIG9wdGlvbiAyIGFzIHdoZW4gSSBsb29rIGludG8gZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1zaWduYWxpbmctZzcwOXYzLTA1LCB0aGUgSUFOQSBzZWN0aW9uIHNob3dzIHRoZSBjLXR5cGUg Zm9yIHRoZSBHRU5FUkFMSVpFX0xBQkVMIGRlZmluZWQgaW4gUkZDIDM0NzMsIG5vdCBhIG5ldyBj LXR5cGUuDQo+IA0KPiBPVE4tVERNIEdlbmVyYWxpemVkIExhYmVsIE9iamVjdDogDQo+IA0KPiAg ICAgICAgbyBPVE4tVERNIEdlbmVyYWxpemVkIExhYmVsIE9iamVjdDogQ2xhc3MgPSAxNiwgQy1U eXBlID0gMiAoc2VlIA0KPiAgICAgICAgICBTZWN0aW9uIDUuMSkgDQo+DQoNCkkgZGlkbid0IG5v dGljZSB0aGF0IGluY29uc2lzdGVuY3kuICBQZXINCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNSNzZWN0aW9uLTU6DQog VGhlIHRyYWZmaWMgcGFyYW1ldGVycyBmb3IgT1ROLVRETSBjYXBhYmxlIFN3aXRjaGluZyBUeXBl IGFyZSBjYXJyaWVkDQogaW4gdGhlIE9UTi1URE0gU0VOREVSX1RTUEVDIGFuZCBGTE9XU1BFQyBv YmplY3RzLiBUaGUgb2JqZWN0cyBoYXZlDQogdGhlIGZvbGxvd2luZyBjbGFzcyBhbmQgdHlwZToN Cg0KICAgIC0gIE9UTi1URE0gU0VOREVSX1RTUEVDIE9iamVjdDogQ2xhc3MgPSAxMiwgQy1UeXBl ID0gNyAoVEJBKQ0KICAgIC0gIE9UTi1URE0gRkxPV1NQRUMgT2JqZWN0OiBDbGFzcyA9IDksIEMt VHlwZSA9IDcgKFRCQSkNCg0KTG91DQoNCj4gSSdtIG9wZW4gdG8gZWl0aGVyIGNhcnJ5aW5nIE9E VWZsZXgoR0ZQKSBiYW5kd2lkdGggYXMgZmxvYXRpbmctcG9pbnQgb3IgaW50ZWdlciBOLCBidXQg d291bGQgbGlrZSB0byBzZWUgY29uc2lzdGVuY3kgYmV0d2VlbiByb3V0aW5nIGFuZCBzaWduYWxp bmcgZG9jdW1lbnRzLg0KPiANCj4gDQo+IFJlZ2FyZHMsDQo+IEZyZWQNCj4gDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWmFmYXIgQWxpICh6YWxpKQ0K PiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI5LCAyMDEzIDEwOjQxIEFNDQo+IFRvOiBMb3UgQmVy Z2VyOyBDQ0FNUA0KPiBTdWJqZWN0OiBSZTogW0NDQU1QXSBQb2xsIG9uIE9EVUZsZXgtcmVsYXRl ZCBlbmNvZGluZyAod2FzOiBXRyBMYXN0IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2Ft cC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KPiANCj4gSGkgTG91LCBDLWNhbXBlcnM6IA0K PiANCj4gSSB3b3VsZCBwaWNrIE9wdGlvbiAyOyBpdCdzIGNsZWFuZXIgYW5kICBhZGRyZXNzZXMg dGhlIGlzc3VlIHJlbGF0ZWQgdG8NCj4gb3ZlcmxvYWRpbmcgdGhlIHNhbWUgYy10eXBlLg0KPiAN Cj4gVGhhbmtzDQo+IA0KPiBSZWdhcmRz4oCmWmFmYXINCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiAibGJlcmdlckBsYWJuLm5ldCIgPGxiZXJnZXJAbGFibi5u ZXQ+DQo+IERhdGU6IE1vbmRheSwgSmFudWFyeSAyOCwgMjAxMyAzOjI1IFBNDQo+IFRvOiAiY2Nh bXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4NCj4gU3ViamVjdDogW0NDQU1QXSBQb2xsIG9u IE9EVUZsZXgtcmVsYXRlZCBlbmNvZGluZyAod2FzOiBXRyBMYXN0IENhbGwNCj4gY29tbWVudHMg b24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KPiANCj4+IEFs bCwNCj4+IAlXZSB3b3VsZCBsaWtlIHRvIHRyeSB0byBjbG9zZSB0aGUgZGlzY3Vzc2lvbiBvbiB0 aGUgRy43MDkNCj4+IGRyYWZ0cyBzbyB0aGF0IHdlIGNhbiBtb3ZlIHJhcGlkbHkgdG93YXJkcyBw dWJsaWNhdGlvbiByZXF1ZXN0LiAgVGhlDQo+PiBkaXNjdXNzaW9uIG9mIChvbmUgb2YgbXkpIExD IGNvbW1lbnRzIGhhcyByZXN1bHRlZCBpbiBzZXZlcmFsIG9wdGlvbnMNCj4+IGZvciB0aGUgc2ln bmFsaW5nIE9EVS1yZWxhdGVkIHRyYWZmaWMgcGFyYW1ldGVycywgYW5kIHRoZSBwb2ludCBoYXMN Cj4+IGJlZW4gcmFpc2VkIHRoYXQgcmVhbGlnbmluZyByb3V0aW5nIHdpdGggc2lnbmFsaW5nIHNo b3VsZCBiZSBkaXNjdXNzZWQuDQo+Pg0KPj4gUGxlYXNlIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBv YmplY3RpdmUgb2YgYW55IFBTIGlzIGludGVyb3BlcmFiaWxpdHksDQo+PiBhbmQgdGhhdCB0aGVy ZSBtYXkgYmUgZWFybHkgaW1wbGVtZW50YXRpb25zIHRoYXQgbWF0Y2ggZzcwOXYzLTA0Lg0KPj4N Cj4+IFRoZSBiYXNpYyBxdWVzdGlvbiBpcyBvbmUgb2YgaWYgTiwgdGhlIG51bWJlciBvZiB0aW1l IHNsb3RzIG5lZWRlZCB0bw0KPj4gc3VwcG9ydCBhIE9EVWZsZXgoR0ZQKSBzaWduYWwsIHNob3Vs ZCBiZSBjYXJyaWVkIGFzIGEgY2FsY3VsYXRlZCBJRUVFDQo+PiBmbG9hdGluZyBwb2ludCBudW1i ZXIgb3IgZGlyZWN0bHkuICAgT3B0aW9ucyAxIGFuZCAyIGJlbG93IHJlZmxlY3QgdGhlDQo+PiBm b3JtZXIsIG9wdGlvbnMgMyBhbmQgNCBtYXRjaCB0aGUgbGF0dGVyLiAgSXQgaXMgd29ydGggbm90 aW5nIHRoYXQgb25seQ0KPj4gb3B0aW9ucyAxIGFuZCAyIGFyZSBwcm9wb3NlZCBmb3IgT0RVZmxl eChHRlApLCBpLmUuLCBOIG11c3QgYmUNCj4+IGNhbGN1bGF0ZWQgZm9yIE9EVWZsZXgoQ0JSKSBz aWduYWwgdHlwZXMgd2l0aCBhbGwgb3B0aW9ucy4NCj4+DQo+PiBQbGVhc2Ugc3RhdGUgeW91ciBz dXBwb3J0IGZvciBvbmUgdGhlIG9wdGlvbnMgYW5kLCBpZiB5b3Ugd2lzaCwgdGhlDQo+PiBqdXN0 aWZpY2F0aW9uIGZvciB5b3VyIHBvc2l0aW9uOg0KPj4NCj4+IDEpIEZvbGxvdyBkcmFmdC1pZXRm LWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4+ICAgaS5lLiwgcmVkZWZpbmUgW1JG QzQzMjhdIFRyYWZmaWMgUGFyYW1ldGVycyBjLXR5cGUgd2hlbiB1c2VkIHdpdGgNCj4+ICAgT1RO LVRETSBsYWJlbHMuIE9EVWZsZXgoR0ZQKSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3RzIChOKSBp cw0KPj4gICBlbmNvZGVkIGFzOg0KPj4NCj4+ICAgLi4uIHRoZSBCaXRfUmF0ZSBmaWVsZCBmb3Ig T0RVZmxleChHRlApIE1VU1QNCj4+ICAgZXF1YWwgdG8gb25lIG9mIHRoZSA4MCB2YWx1ZXMgbGlz dGVkIGJlbG93Og0KPj4NCj4+ICAgICAgIDEgKiBPRFUyLnRzOyAyICogT0RVMi50czsgLi4uOyA4 ICogT0RVMi50czsNCj4+ICAgICAgIDkgKiBPRFUzLnRzOyAxMCAqIE9EVTMudHMsIC4uLjsgMzIg KiBPRFUzLnRzOw0KPj4gICAgICAgMzMgKiBPRFU0LnRzOyAzNCAqIE9EVTQudHM7IC4uLjsgODAg KiBPRFU0LnRzLg0KPj4NCj4+IDIpIEZvbGxvdyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25h bGluZy1nNzA5djMtMDUNCj4+ICAgaS5lLiwgdXNlIGEgbmV3IEMtdHlwZSBmb3IgT1ROLVRETSBs YWJlbHMuICBFbmNvZGluZyBkZXRhaWxzDQo+PiAgIHVuY2hhbmdlZCBmcm9tIGc3MDl2My0wNC4N Cj4+ICAgKFRoaXMgb3B0aW9uIGFkZHJlc3NlcyB0aGUgaXNzdWUgb2YgdGhlIHNhbWUgYy10eXBl IG5lZWRpbmcgdG8NCj4+ICAgIGJlIHBhcnNlZCBiYXNlZCBvbiBsYWJlbC9zd2l0Y2hpbmcgdHlw ZS4pDQo+Pg0KPj4gMykgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3 MDl2My0wNg0KPj4gICBpLmUuLCAgdXNlIGEgbmV3IEMtdHlwZSBmb3IgT1ROLVRETSBsYWJlbHMu IE4gaXMgZGlyZWN0bHkgY2FycmllZA0KPj4gICBmb3IgT0RVZmxleChHRlApIG9ubHkuDQo+Pg0K Pj4gNCkgRGlzY3Vzc2VkLCBidXQgbm90IGluIGFueSBkcmFmdA0KPj4gICBVc2UgZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0IGVuY29kaW5nIGZvciBhbGwNCj4+ICAg YnV0IE9EVWZsZXgoR0ZQKSwgYW5kIGRlZmluZSBuZXcgT0RVZmxleChHRlApIHNwZWNpZmljIFRy YWZmaWMNCj4+ICAgUGFyYW1ldGVycyBiYXNlZCBvbiBnNzA5djMtMDYsIHByZXN1bWFibHkgd2l0 aCB1bnVzZWQgZmllbGRzDQo+PiAgIHJlbW92ZWQuDQo+PiAgIChUaGlzIGFsc28gYWRkcmVzc2Vz IHRoZSBpc3N1ZSBvZiB0aGUgc2FtZSBjLXR5cGUgbmVlZGluZyB0byBiZQ0KPj4gICAgcGFyc2Vk IGJhc2VkIG9uIGxhYmVsIHR5cGUsIGJ1dCBtZWFucyB0aGVyZSBhcmUgZGlmZmVyZW50IHR5cGVz DQo+PiAgICBiYXNlZCBvbiBzaWduYWwgdHlwZS4pDQo+Pg0KPj4gT3B0aW9uIDEgYW5kIDIgZG8g bm90IGltcGx5IGFueSBjaGFuZ2VzIHRvIHJvdXRpbmcsIHdoaWxlIG9wdGlvbnMgMyBhbmQNCj4+ IDQgbWF5LiAgUm91dGluZyBpbXBsaWNhdGlvbnMgd2lsbCBiZSBkaXNjdXNzZWQgYmFzZWQgb24g dGhlIHJlc3VsdHMgb2YNCj4+IHRoaXMgcG9sbCwgYW5kIG9ubHkgaWYgdGhlcmUgaXMgY29uc2Vu c3VzIHRvIHN1cHBvcnQgcG9zaXRpb25zIDMgb3IgNC4NCj4+DQo+PiBXZSBob3BlIHRvIG1ha2Ug YSBjb25zZW5zdXMgY2FsbCBieSB0aGUgZW5kIG9mIHRoZSB3ZWVrLCBidXQgd2lsbA0KPj4gY29u dGludWUgdGhlIGRpc2N1c3Npb24gYXMgbmVlZGVkLg0KPj4NCj4+IE11Y2ggdGhhbmtzLA0KPj4g TG91IChhbmQgRGVib3JhaCkNCj4+DQo+PiBPbiAxLzI4LzIwMTMgNTowOCBBTSwgRGFuaWVsZSBD ZWNjYXJlbGxpIHdyb3RlOg0KPj4+ICBBbGwsDQo+Pj4NCj4+PiBJIHRoaW5rIHRoZSBjaGFuZ2Vz IHByb3Bvc2VkIGFyZSBtZWFuaW5nZnVsIGFuZCB3b3VsZCBzdXBwb3J0IHRoZW0gaW4NCj4+PiBh biBpbmRpdmlkdWFsIG9yIGVhcmx5IFdHIGRyYWZ0LCBidXQgdGhleSBkb24ndCBzZWVtIHRvIHBy b3ZpZGUNCj4+PiBzaWduaWZpY2F0aXZlIGFkdmFudGFnZXMgdG8gcmlzayBpbnRlcndvcmtpbmcg aXNzdWVzIHdpdGggZWFybHkNCj4+PiBpbXBsZW1lbnRhdGlvbnMuDQo+Pj4gTW9yZW92ZXIgdGhl IGNoYW5nZXMgZG9uJ3QgYWxsb3cgdXMgZ2V0dGluZyB0b3RhbGx5IHJpZCBvZiBvZiB0aGUNCj4+ PiBiaXRfcmF0ZSBmaWVsZCBhcyBpdCBpcyBzdGlsbCBuZWVkZWQgZm9yIE9EVWZsZXggKENCUiku DQo+Pj4NCj4+PiBNeSAyYw0KPj4+IERhbmllbGUNCj4+Pg0KPj4+DQo+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxp QGNpc2NvLmNvbV0NCj4+Pj4gU2VudDogbHVuZWTDrCAyOCBnZW5uYWlvIDIwMTMgNC40Nw0KPj4+ PiBUbzogTG91IEJlcmdlcg0KPj4+PiBDYzogR3J1bWFuLCBGcmVkOyBGYXRhaSBaaGFuZzsgRGFu aWVsZSBDZWNjYXJlbGxpOyBDQ0FNUDsNCj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWdu YWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdH IExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25h bGluZy1nNzA5djMtMDQNCj4+Pj4NCj4+Pj4gSGkgTG91LSANCj4+Pj4NCj4+Pj4gUGxlYXNlIHNl ZSBpbi1saW5lLg0KPj4+Pg0KPj4+PiBUaGFua3MNCj4+Pj4NCj4+Pj4gUmVnYXJkcy4uLlphZmFy DQo+Pj4+DQo+Pj4+IE9uIDEvMjcvMTMgOTo0NiBQTSwgIkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxh Ym4ubmV0PiB3cm90ZToNCj4+Pj4NCj4+Pj4+IFphZmFyLA0KPj4+Pj4gCUlzIHlvdXIgY29tbWVu dCB3aXRoIHJlc3BlY3QgdG8ganVzdCByb3V0aW5nIG9yIGJvdGgNCj4+Pj4gc2lnbmFsaW5nIGFu ZCANCj4+Pj4+IHJvdXRpbmc/DQo+Pj4+DQo+Pj4+IEJvdGgsIGluY2x1ZGluZyBjb25zaXN0ZW5j eSBiZXR3ZWVuIHNpZ25hbGluZyBhbmQgcm91dGluZyBhdHRyaWJ1dGVzLg0KPj4+Pg0KPj4+Pj4N Cj4+Pj4+IEFsc28sIHdoZW4geW91IHNheSAiaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIGRyYWZ0 IHZlcnNpb25zIiwNCj4+Pj4gZG8gdGhlc2UgDQo+Pj4+PiBpbXBsZW1lbnRhdGlvbnMgaW5jbHVk ZSBzdXBwb3J0IGZvciBPRFVmbGV4PyAgKFdoaWNoIGhhcyByZWFsbHkgYmVlbg0KPj4+Pj4gdGhl IGZvY3VzIG9mIHRoZSBkaXNjdXNzaW9uLikNCj4+Pj4NCj4+Pj4gWWVzLCBJIHdhcyByZWZlcnJp bmcgdG8gT0RVRmxleC4gQXMgeW91IGtub3csIGZpeGVkIE9EVSBpcw0KPj4+PiBzaWduYWxlZCB2 aWEgbGV2ZWwgKDAgQlcpIHNvIGl0cyBub3QgYW4gaXNzdWUuDQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4g QlRXIEkgdG9vayBGcmVkJ3MgY29tbWVudHMgYXMgcmVsYXRlZCB0byBqdXN0IHRoZSBuZXcNCj4+ Pj4gT1ROLXNwZWNpZmljIElTQ0QNCj4+Pj4+IGRlZmluaXRpb25zIChzZWN0aW9uIDQuMS4yIG9m IG9zcGYtZzcwOXYzLTA1LCBpbiBwYXJ0aWN1bGFyKS4gIE5vdGUNCj4+Pj4+IHRoYXQgc2VjdGlv biA0LjEuMSBhbHJlYWR5IGNhcnJpZXMgTiAobnVtYmVyIG9mIE9EVXMpIG5vdA0KPj4+PiBJRUVF IGZsb2F0aW5nIA0KPj4+Pj4gcG9pbnQgcmVwcmVzZW50YXRpb25zIG9mIGF2YWlsYWJsZSBiYW5k d2lkdGguDQo+Pj4+DQo+Pj4+IFdoYXQgSSBtZWFudCBpcyBVbnJlc2VydmVkIEJhbmR3aWR0aCBh dCBwcmlvcml0eSB4IGFuZCBNYXggTFNQDQo+Pj4+IEJhbmR3aWR0aCBhdCBwcmlvcml0eSB4Lg0K Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE11Y2ggdGhhbmtzLA0KPj4+Pj4gTG91DQo+Pj4+Pg0KPj4+Pj4g T24gMS8yNy8yMDEzIDc6NDYgUE0sIFphZmFyIEFsaSAoemFsaSkgd3JvdGU6DQo+Pj4+Pj4gQWxs LQ0KPj4+Pj4+DQo+Pj4+Pj4gVGhpcyBpbXBhY3RzIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBi YXNlZCBvbiBkcmFmdCB2ZXJzaW9ucyAoYW5kDQo+Pj4+Pj4gaGVuY2UgaW50ZXJvcCB3aXRoIHRo ZXNlIGltcGxlbWVudGF0aW9ucyBtb3ZpbmcgZm9yd2FyZCkuDQo+Pj4+IElNTyB0aGlzIGlzIA0K Pj4+Pj4+IGEgYmlnZ2VyIGNoYW5nZSBmb3IgdXMgdG8gYXNzdW1lIGF0IHRoZSBsYXN0IGNhbGwg c3RhZ2UuDQo+Pj4+IEZ1cnRoZXJtb3JlIA0KPj4+Pj4+IHdlIGhhdmUgYmVlbiB1c2luZyBJRUVF IGZsb2F0aW5nIHBvaW50IGZvcm1hdCBmb3IgVW5yZXNlcnZlZA0KPj4+Pj4+IEJhbmR3aWR0aC8g TWF4IExTUCBCVyBpbiBJRUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCBmb3Igb3RoZXINCj4+Pj4+ PiB0ZWNobm9sb2dpZXMuIE92ZXJhbGwsIEkgdGhpbmsgdGhpcyBjaGFuZ2Ugc3VmZmVycyBmcm9t IHRoZQ0KPj4+PiAibGF3IG9mIGRpbWluaXNoaW5nIHJldHVybnMiLg0KPj4+Pj4+DQo+Pj4+Pj4g VGhhbmtzDQo+Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRzIMWgIFphZmFyDQo+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+Pj4+IE9uIDEvMjcvMTMgMTA6MjggQU0sICJHcnVtYW4sIEZyZWQiDQo+Pj4+IDxmcmVkLmdy dW1hbkB1cy5mdWppdHN1LmNvbT4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+Pj4gSGkgTG91LCBGYXRh aSwgRGFuaWVsZSwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSSB1bmRlcnN0YW5kIHRoZSBsYXRlc3QgY2hh bmdlIHRvIHRoZSB3YXkgYmFuZHdpZHRoIGlzDQo+Pj4+IHNpZ25hbGVkIGZvciAgDQo+Pj4+Pj4+ IE9EVWZsZXgoR0ZQKSwgaS5lLiwgc2lnbmFsaW5nIHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNs b3RzDQo+Pj4+IE4gaW5zdGVhZCANCj4+Pj4+Pj4gb2YgIHRoZSBiYW5kd2lkdGggcmF0ZSBpbiBi cHMuICBJIGJlbGlldmUgdGhhdCB0aGlzIHNpbXBsaWZpZXMgdGhlDQo+Pj4+Pj4+IHNpZ25hbGlu ZyAgYW5kIGludGVyb3BlcmFiaWxpdHkgc28gSSdtIGluIGFncmVlbWVudCB3aXRoDQo+Pj4+IHRo aXMgY2hhbmdlLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBIb3dldmVyLCBpdCBzZWVtcyB3ZSBhcmUgbm93 IGluY29uc2lzdGVudCBiZXR3ZWVuIGhvdyB3ZQ0KPj4+PiByZXByZXNlbnQgIA0KPj4+Pj4+PiBi YW5kd2lkdGggaW4gcm91dGluZyBhbmQgc2lnbmFsaW5nIGZvciBPRFVmbGV4KEdGUCkuICBSb3V0 aW5nDQo+Pj4+Pj4+IGFkdmVydGlzZXMgIHRoZSBiYW5kd2lkdGggdXNpbmcgYSBmbG9hdGluZyBw b2ludCByZXByZXNlbnRhdGlvbiBvZg0KPj4+Pj4+PiBiYW5kd2lkdGgsIHdoaWxlICBzaWduYWxp bmcgaXMgdXNpbmcgdGhlIG51bWJlciBvZiB0cmlidXRhcnkgc2xvdHMuDQo+Pj4+Pj4+IEl0IHNl ZW1zIHRoZSBzYW1lICBiZW5lZml0cyB3b3VsZCBiZSBvYnRhaW5lZCBieQ0KPj4+PiBhZHZlcnRp c2luZyB0aGUgbWF4DQo+Pj4+Pj4+IExTUCBiYW5kd2lkdGggYW5kICB1bnJlc2VydmVkIGJhbmR3 aWR0aCBmb3IgT0RVZmxleChHRlApIGluDQo+Pj4+IHRlcm1zIG9mIA0KPj4+Pj4+PiB0aGUgbnVt YmVyIG9mIHRyaWJ1dGFyeSAgc2xvdHMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZyZWQNCj4+Pj4+Pj4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4+Pj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNA aWV0Zi5vcmddIE9uDQo+Pj4+Pj4+IEJlaGFsZiBPZiAgTG91IEJlcmdlcg0KPj4+Pj4+PiBTZW50 OiBXZWRuZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgOTowOCBBTQ0KPj4+Pj4+PiBUbzogRmF0YWkg WmhhbmcNCj4+Pj4+Pj4gQ2M6IENDQU1QOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGlu Zy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cg TGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2ln bmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4+Pg0KPj4+Pj4+PiBGYXRhaSwNCj4+Pj4+Pj4NCj4+Pj4+ Pj4gT24gMS8yMy8yMDEzIDY6NDkgQU0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4+Pj4gSGkg TG91LA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEZvciBPRFVmbGV4KENCUiksIHRoZSBmb3JtdWxhIGlz IGZyb20gW0cuNzA5LTIwMTJdIGFuZCBpdA0KPj4+PiBoYXMgYmVlbiANCj4+Pj4+Pj4+IGRpc2N1 c3NlZCBiZWZvcmUsIHNvIHBsZWFzZSB0cnVzdCB0aGF0IHRoZXJlIGlzIG5vDQo+Pj4+IG9wcG9y dHVuaXR5IGZvcg0KPj4+Pj4+Pj4gbWlzaW50ZXJwcmV0YXRpb24uIChOb3RlIHRoYXQgdGhlcmUg YXJlIHR3byBjYXNlcywgb25lIGlzDQo+Pj4+Pj4+PiBPRFVmbGV4KENCUikgYW5kIGFub3RoZXIg b25lIGlzIE9EVWZsZXgoR0ZQKSkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSW4gYWRkdGlvbiwgT0RV ZmxleCBjYW5ub3QgYmUgY29uY2F0ZW5hdGVkIGJ5IFtHLjcwOS0yMDEyXS4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gVGhhbmtzIGZvciBjb25maXJtaW5nIG15IHVuZGVyc3RhbmRpbmcuICBUaGlzIHJhaXNl cyB0aGUNCj4+Pj4gcXVlc3Rpb24gb2YgDQo+Pj4+Pj4+IGlmIHRoZSBuZXcgdHJhZmZpYyBzaG91 bGQganVzdCBhcHBseSB0byBPRFVGbGV4PyAgQ29ycmVjdA0KPj4+PiBtZSBpZiBJJ20gDQo+Pj4+ Pj4+IHdyb25nLCBidXQgSSBiZWxpZXZlIHRoZSBbUkZDNDMyOF0gaXMgc3VmZmljaWVudCBpbiBh bGwNCj4+Pj4gb3RoZXIgY2FzZXMuICANCj4+Pj4+Pj4gVGhpcyBtYXkgYWxzbyBtYWtlIGl0IGVh c2llciBmb3IgZWFybHkgaW1wbGVtZW50YXRpb25zIG9mDQo+Pj4+IHRoZSBkcmFmdCANCj4+Pj4+ Pj4gYXMgdGhlbiB0aGV5IGNhbiBsaW1pdCBjb2RlIGNoYW5nZXMgZnJvbSB0aGUgKC0wMykgcmV2 IHRvDQo+Pj4+IG9ubHkgT0RVZmxleCBMU1BzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBKdXN0IHRvIGJl IGNsZWFyLCBJJ20gcmVhbGx5IGp1c3QgKmFza2luZyogYWJvdXQgdGhpcy4gIEFzIEkgc2FpZA0K Pj4+Pj4+PiBiZWZvcmUsIEknbSBvcGVuIG9uIHNwZWNpZmljcy4uLg0KPj4+Pj4+Pg0KPj4+Pj4+ PiBBbnkgdGhvdWdodHMvY29tbWVudHM/IEF1dGhvcnM/ICBJbXBsZW1lbnRvcnM/DQo+Pj4+Pj4+ DQo+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4gTG91DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ PiBJIHdpbGwgaXNzdWUgYSBuZXcgdmVyc2lvbiB0b21vcnJvdyB0byBjYXB0dXJlIGFsbCB5b3Vy IGNvbW1lbnRzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBCZXN0IFJlZ2FyZHMNCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBGYXRhaQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRv OmxiZXJnZXJAbGFibi5uZXRdDQo+Pj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjMs IDIwMTMgMjoxMSBBTQ0KPj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4+PiBDYzogQ0NB TVA7IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9y Zw0KPj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9u DQo+Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBGYXRhaSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBPbiAxLzIwLzIwMTMg OTo0MyBQTSwgRmF0YWkgWmhhbmcgd3JvdGU6DQo+Pj4+Pj4+Pj4gSGkgTG91LA0KPj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4gWW91IHNhaWQ6DQo+Pj4+Pj4+Pj4+IGJ1dCB5b3UncmUgc2F5cyBlbmNvZGVk IGFzIChOKk5vbWluYWwgUmF0ZSkgcmlnaHQ/IFdhdCdzIHRoZQ0KPj4+Pj4+Pj4+PiB2YWx1ZSBv ZiAgdGhpcyB2cyBqdXN0IGNhcnJ5aW5nIE4/DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBbRmF0YWld IFRoZSBvcmlnaW5hbCB3YXkgKGluIHZlcnNpb24gMDQmMDUpIGlzIHB1dHRpbmcNCj4+Pj4gKE4q IE5vbWluYWwNCj4+Pj4+Pj4+PiBSYXRlKSBpbiAiQml0X1JhdGUiIGZpZWxkIGZvciBPRFVmbGV4 KEdGUCksIHRoZSB2YWx1ZSBpcyB0aGF0IHdlDQo+Pj4+Pj4+Pj4gY2FuIGdlbmVyYWxpemUgdG8g anVzdCB1c2Ugb25lIHNpbmdsZSAiQml0X1JhdGUiIGZpZWxkIHRvIGNhcnJ5DQo+Pj4+Pj4+Pj4g SUVFRSBmbG9hdCBudW1iZXIgZm9yIGJvdGggY2FzZXMsIGl0IHNlZW1zIHRoYXQgeW91DQo+Pj4+ IGRvbid0IGFncmVlIG9uIA0KPj4+Pj4+Pj4+IHRoaXMgdmFsdWUsIDotKQ0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IEkndmUgc2VlbiBkaWZmZXJlbmNlcyBpbiBjYWxjdWxhdGVkIGZsb2F0aW5nIHBvaW50 IHZhbHVlcyBmcm9tDQo+Pj4+Pj4+PiBkaWZmZXJlbnQgIGltcGxlbWVudGF0aW9ucywgc28gSSBq dXN0IHdhbnQgdG8gZW5zdXJlIHRoYXQNCj4+Pj4gc3VjaCBjYXNlcyANCj4+Pj4+Pj4+IGFyZSBh dm9pZGVkLg0KPj4+Pj4+Pj4gSSdtIG9wZW4gdG8gc3BlY2lmaWMgc29sdXRpb25zIGFuZCBjZXJ0 YWlubHkgd2lsbCBkZWZmZXIgb24gdGhlDQo+Pj4+Pj4+PiBzcGVjaWZpY3MgYXNzdW1pbmcgdGhl cmUgaXMgbm8gb3Bwb3J0dW5pdHkgZm9yDQo+Pj4+Pj4+PiBtaXNpbnRlcnByZXRhdGlvbi9pbnRl cm9wICBpc3N1ZXMuIEkgZG9uJ3QgdGhpbmsgdGhlDQo+Pj4+IG9yaWdpbmFsIHBhc3NlZA0KPj4+ Pj4+Pj4gdGhpcyB0aHJlc2hvbGQsIGkuZS4sOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAg IE4gPSBDZWlsaW5nIG9mDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgT0RVZmxleChDQlIpIG5vbWlu YWwgYml0IHJhdGUgKiAoMSArIE9EVWZsZXgoQ0JSKSBiaXQgcmF0ZQ0KPj4+Pj4+Pj4gdG9sZXJh bmNlKQ0KPj4+Pj4+Pj4gICAgDQo+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiAtLS0tLS0tLS0tDQo+Pj4+Pj4+ PiAgICAgICAgT0RUVWsudHMgbm9taW5hbCBiaXQgcmF0ZSAqICgxIC0gSE8gT1BVayBiaXQgcmF0 ZQ0KPj4+PiB0b2xlcmFuY2UpDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC4gVGhlcmVmb3JlLCBJICh3 YXMpIGFtIHNheWluZyB0aGF0IEkgYW0gZ29pbmcgdG8gYWNjZXB0IHlvdXINCj4+Pj4+Pj4+PiBz dWdnZXN0aW9uIHRvIGNhcnJ5IE4gZm9yIE9EVWZsZXgoR0ZQKS4gV2UgYXJlDQo+Pj4+IGRpc2N1 c3Npbmcgd2hlcmUgdG8NCj4+Pj4+Pj4+PiBwdXQgTiBmb3IgT0RVZmxleChHRlApLg0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFlvdSBzYWlkOg0KPj4+Pj4+Pj4+PiBiaXRzIGluIHRo ZSBjb250cm9sIHBsYW5lIGFyZSBnZW5lcmFsbHkgY2hlYXAsIElNTyBpdCdzDQo+Pj4+IGJldHRl ciB0byAgDQo+Pj4+Pj4+Pj4+IGhhdmUgc2ltcGxlciBlbmNvZGluZyB0aGFuIHRvIG9wdGltaXpl IGV2ZXJ5IGJpdCAob3IgOCBpbiB0aGlzDQo+Pj4+Pj4+Pj4+IGNhc2UpLg0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gW0ZhdGFpXSBPSywgSSB3aWxsIGFkZCBhIG5ldyBmaWVsZCAodG8gb2NjdXB5IHRo ZSByZXNlcnZlZCBiaXRzKQ0KPj4+Pj4+Pj4+IHRvIGNhcnJ5IE4uDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4gQXMgeW91IHNlZSBmaXQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSnVzdCB0byBjbGFyaWZ5IG15 IHVuZGVyc3RhbmRpbmcsIE9EVWZsZXggYW5kIFZpcnR1YWwNCj4+Pj4gY29uY2F0ZW5hdGlvbiAN Cj4+Pj4+Pj4+IGNhbiAgbmV2ZXIgYmUgY29tYmluZWQgZm9yIHRoZSBzYW1lIHNpZ25hbCB0eXBl L2xldmVsLCByaWdodD8NCj4+Pj4+Pj4+IChBbHRob3VnaCBhbiAgT0RVZmxleCBjbGllbnQgc2ln bmFsIGNvdWxkIGJlIGNhcnJpZWQgb3Zlcg0KPj4+PiBhIHZpcnR1YWwgDQo+Pj4+Pj4+PiBjb25j YXRlbmF0ZWQgIE9EVWspLiAgSXMgdGhpcyBjb3JyZWN0IG9yIGRpZCBJIG1pc3Mgc29tZXRoaW5n IGluDQo+Pj4+Pj4+PiBHNzA5Pw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+ IExvdQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ PiBCZXN0IFJlZ2FyZHMNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+IEZyb206IExvdSBC ZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPj4+Pj4+Pj4+IFNlbnQ6IEZyaWRheSwg SmFudWFyeSAxOCwgMjAxMyAxOjQyIEFNDQo+Pj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+ Pj4+Pj4gQ2M6IENDQU1QOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djNA dG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0IENh bGwgY29tbWVudHMgb24NCj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGlu Zy1nNzA5djMtMDQNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBP biAxLzE1LzIwMTMgMTA6MTYgUE0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4+Pj4+PiBIaSBM b3UsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRvIGF2b2lkIG1pc3VuZGVyc3RhbmRpbmcsIEkg d291bGQgbGlrZSB0byBjbGFyaWZ5IG1vcmUgb24gdGhlDQo+Pj4+Pj4+Pj4+IGZvbGxvd2luZyBw b2ludC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IEl0IGlzIGJldHRl ciB0byBoYXZlIGNvbnNpc3RlbnQgZm9ybWF0IGFuZCB0aGUgc2FtZSBtZWFuaW5nDQo+Pj4+Pj4+ Pj4+Pj4+PiBvZiBvbmUNCj4+Pj4+Pj4+PiBmaWVsZCBmb3IgYm90aCBPRFVmbGV4KENCUikgYW5k IEdGUC4gVGhpcyBpcyB3aHkgd2UgaGF2ZSBzZWN0aW9uDQo+Pj4+Pj4+Pj4gNS4xDQo+Pj4+Pj4+ Pj4gJjUuMiB0byBkZXNjcmliZSB0aGUgY29tcGxleCBzdHVmZi4NCj4+Pj4+Pj4+Pj4+Pj4gSSBh Y3R1YWxseSB3YXNuJ3Qgc3VnZ2VzdGluZyB0aGF0IE4gYmUgY2FycmllZCBpbg0KPj4+PiB0aGUg Yml0IHJhdGUgIA0KPj4+Pj4+Pj4+Pj4+PiBmaWVsZC4NCj4+Pj4+Pj4+Pj4+Pj4gVGhlIGJpdCBy YXRlIGZpZWxkIGNhbiBlaXRoZXIgYmUgc2V0IGFzIGRlc2NyaWJlZCBvciB0byB6ZXJvDQo+Pj4+ Pj4+Pj4+Pj4+IChpLmUuLCAgaWdub3JlZCkuICBBdCB0aGUgdGltZSwgSSB3YXMgdGhpbmtpbmcg YWJvdXQNCj4+Pj4gY2FycnlpbmcgTiANCj4+Pj4+Pj4+Pj4+Pj4gaW4gdGhlICByZXNlcnZlZCAg ZmllbGQuIEJ1dCBwZXJoYXBzIHRoZSByaWdodCBwbGFjZQ0KPj4+PiBpcyBNVCwgaWYgDQo+Pj4+ Pj4+Pj4+Pj4+IG15IHVuZGVyc3RhbmRpbmcgaXMgIHJpZ2h0ICAod291bGQgYWx3YXlzIGJlIDEN Cj4+Pj4gb3RoZXJ3aXNlKS4gSSdtDQo+Pj4+Pj4+Pj4+Pj4+IG9wZW4gdG8gZWl0aGVyLi4uDQo+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gW0ZhdGFpXSBXaHkgbm90IGp1c3QgdXNlICJiaXQg cmF0ZSJmaWVsZCB0byBjYXJyeQ0KPj4+PiAiTiJiZWNhdXNlICJOIg0KPj4+Pj4+Pj4+Pj4+IGlt cGxpZXMgYml0IHJhdGU/ICBJIGFtIE9LIGlmIHlvdSBsaWtlIHRvIHVzZSBhIG5ldw0KPj4+PiBm aWxlZCAobGlrZSANCj4+Pj4+Pj4+Pj4+PiAiVFMNCj4+Pj4+Pj4+Pj4+PiBOdW1iZXIiKSB0byBv Y2N1cHkgdGhlIHJlc2VydmVkIGZpZWxkIGV2ZW4gdGhvdWdoDQo+Pj4+IHRoYXQgSSBwcmVmZXIg DQo+Pj4+Pj4+Pj4+Pj4gdGhlICBvcmlnaW5hbCBhcHByb2FjaCAoaWUuLCB1c2UgImJpdCByYXRl ImZpZWxkIHRvIGNhcnJ5ICJOIikuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gQXJlIHlvdSBw cm9wb3NpbmcgZHJvcHBpbmcgY2FycnlpbmcgYml0IHJhdGVzDQo+Pj4+IHJlcHJlc2VudGVkIGFz IGFuDQo+Pj4+Pj4+Pj4+PiBJRUVFICBmbG9hdGluZyBwb2ludCBhbmQganVzdCBjYXJyeWluZyBO IGZvciBPRFVmbGV4Pw0KPj4+PiBUaGlzIHNlZW1zIA0KPj4+Pj4+Pj4+Pj4gd29ya2FibGUgIHRv ICBtZSwgYnV0IHdlIHNob3VsZCBlbnN1cmUgdGhhdCB0aGVyZSBhcmUgbm8NCj4+Pj4+Pj4+Pj4+ IHNpZ25pZmljYW50IG9iamVjdGlvbnMuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFtGYXRhaV0g VGhlcmUgYXJlIHR3byB1c2FnZXMgZm9yICIgQml0X1JhdGUgIiBmaWVsZCBhcw0KPj4+PiBkZXNj cmliZWQgDQo+Pj4+Pj4+Pj4+IGluIHRoZSBsaW5lcyAyODctMzEwLg0KPj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+PiAoMSkgICAgRm9yIE9EVWZsZXgoQ0JSKSwgdGhlIEJpdF9SYXRlIGZpZWxkIGluZGlj YXRlcw0KPj4+PiB0aGUgbm9taW5hbA0KPj4+Pj4+Pj4+PiBiaXQNCj4+Pj4+Pj4+Pj4gcmF0ZSBv ZiBPRFVmbGV4KENCUikgZXhwcmVzc2VkIGluIGJ5dGVzIHBlciBzZWNvbmQsDQo+Pj4+IGVuY29k ZWQgYXMgYSAgDQo+Pj4+Pj4+Pj4+IDMyLWJpdCAgSUVFRSBzaW5nbGUgcHJlY2lzaW9uIGZsb2F0 aW5nLXBvaW50IG51bWJlci4gRm9yIHRoaXMNCj4+Pj4+Pj4+Pj4gY2FzZSwgd2UgTVVTVCAgdXNl ICAzMi1iaXQgSUVFRSBmbG9hdGluZyBwb2ludCBpbnN0ZWFkIG9mDQo+Pj4+Pj4+Pj4+ICJOIihQ bGVhc2Ugc2VlIG1vcmUgaW4gc2VjdGlvbiAgNS4xKS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEkg Z3Vlc3MgeW91IHJlYWxseSBzdGlsbCBuZWVkICh0byBiZSBiYXNlZCBvbikgdGhlIGNsaWVudCBz aWduYWwNCj4+Pj4+Pj4+PiByYXRlIGF0IHRoZSBlZGdlcy4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+PiAoMikgICAgRm9yIE9EVWZsZXgoR0ZQKSwgd2UgY2FuIGNoYW5nZSB0aGUg dGV4dCAodGhlDQo+Pj4+IGxpbmVzIGZyb20gMzA1DQo+Pj4+Pj4+Pj4+IHRvDQo+Pj4+Pj4+Pj4+ IDMxMCkgYmFzZWQgb24geW91ciBzdWdnZXN0aW9uLCBpZS4sIHRoZSBCaXRfUmF0ZSBmaWVsZA0K Pj4+PiBpcyB1c2VkIHRvICANCj4+Pj4+Pj4+Pj4gY2FycnkgICJOInRvIGluZGljYXRlIHRoZSBu b21pbmFsIGJpdCByYXRlIG9mIHRoZSAgT0RVZmxleChHRlApLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gYnV0IHlvdSdyZSBzYXlzIGVuY29kZWQgYXMgKE4qTm9taW5hbCBSYXRlKSByaWdodD8gIFdh dCdzIHRoZQ0KPj4+Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRoZXJlZm9yZSwgSSBh bSBwcm9wb3NpbmcgdXNpbmcgb25lIHNpbmdsZSBmaWxlZCAoIkJpdF9SYXRlICIpDQo+Pj4+Pj4+ Pj4+IGZvciB0aGVzZSB0d28gY2FzZXMsIGluIHRoaXMgd2F5LCB3ZSBjYW4gbGVhdmUgdGhlICJS ZXNlcnZlZCINCj4+Pj4+Pj4+Pj4gYml0cyBmb3IgZnV0dXJlLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gYml0cyBpbiB0aGUgY29udHJvbCBwbGFuZSBhcmUgZ2VuZXJhbGx5IGNoZWFwLCBJTU8gaXQn cw0KPj4+PiBiZXR0ZXIgdG8gDQo+Pj4+Pj4+Pj4gaGF2ZSAgc2ltcGxlciBlbmNvZGluZyB0aGFu IHRvIG9wdGltaXplIGV2ZXJ5IGJpdCAob3IgOCBpbiB0aGlzDQo+Pj4+Pj4+Pj4gY2FzZSkuDQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBMb3UNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBIb3BlIHdlIGFyZSBub3cgYXQgdGhlIHNhbWUgcGFnZS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEZhdGFp DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0K Pj4+Pj4+PiBDQ0FNUEBpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBD Q0FNUEBpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NjYW1wDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pg0K Pj4+Pg0KPj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+PiBDQ0FNUEBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0 DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2NhbXANCj4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== From kpithewan@infinera.com Tue Jan 29 22:46:39 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4009621F8A98 for ; Tue, 29 Jan 2013 22:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6] 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 6amiToNZltwa for ; Tue, 29 Jan 2013 22:46:37 -0800 (PST) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id C931921F8A89 for ; Tue, 29 Jan 2013 22:46:37 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0328.009; Tue, 29 Jan 2013 22:46:36 -0800 From: Khuzema Pithewan To: Lou Berger , "Gruman, Fred" Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZW/sDJ1cyws+0yoEFNCa9OlrphhCa6AgAAUpoCAAA6YgIAAFdKAgAAbJACAABHfQA== Date: Wed, 30 Jan 2013 06:46:35 +0000 Message-ID: References: <5106DED0.3090008@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33126F@RCHEXMBP1.fnc.net.local> <51081917.3080601@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33153D@RCHEXMBP1.fnc.net.local> <5108422A.3090704@labn.net> In-Reply-To: <5108422A.3090704@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 06:46:39 -0000 SSB3b3VsZCBwcmVmZXIgb3B0aW9uIzEvMi4NCg0KVGhhbmtzDQpLaHV6ZW1hDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvdSBCZXJnZXINClNlbnQ6IFdl ZG5lc2RheSwgSmFudWFyeSAzMCwgMjAxMyAzOjEyIEFNDQpUbzogR3J1bWFuLCBGcmVkDQpDYzog Q0NBTVANClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFBvbGwgb24gT0RVRmxleC1yZWxhdGVkIGVuY29k aW5nICh3YXM6IFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxz LXNpZ25hbGluZy1nNzA5djMtMDQpDQoNCkZyZWQsDQoNCkNvbmZpcm1lZC4gIE9wdGlvbiAyIGhh ZCBhIHNob3J0ZW5lZCBmb3JtIG9mIHRoZSB0ZXh0IG9mIG9wdGlvbiAxIHRoYXQgZnVsbHkgc3Bl bGxlZCBpdCBvdXQuICBTb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4NCg0KTG91DQoNCk9uIDEvMjkv MjAxMyAzOjA0IFBNLCBHcnVtYW4sIEZyZWQgd3JvdGU6DQo+IEhpIExvdSwNCj4gDQo+IEp1c3Qg dG8gY29uZmlybSwgeW91ciBvcHRpb24gMiB3aGVyZSB5b3Ugc3RhdGUgInVzZSBhIG5ldyBDLXR5 cGUgZm9yIE9UTi1URE0gbGFiZWxzIiwgaXQgd2FzIG5vdCB0aGUgaW50ZW50IHRvIGhhdmUgYSBu ZXcgYy10eXBlIGZvciB0aGUgbGFiZWwgaXRzZWxmLCBidXQgYSBuZXcgYy10eXBlIGZvciB0aGUg c2VuZGVyLXRzcGVjL2Zsb3dzcGVjICh0cmFmZmljIHBhcmFtZXRlcnMpLiBJZiBzbywgSSBtaXN1 bmRlcnN0b29kIHRoZSBvcHRpb24gYW5kIG5vdyB1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbHMuDQo+ IA0KPiBUaGFua3MsDQo+IEZyZWQNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPiBTZW50OiBUdWVz ZGF5LCBKYW51YXJ5IDI5LCAyMDEzIDEyOjQ3IFBNDQo+IFRvOiBHcnVtYW4sIEZyZWQNCj4gQ2M6 IFphZmFyIEFsaSAoemFsaSk7IENDQU1QDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFBvbGwgb24g T0RVRmxleC1yZWxhdGVkIGVuY29kaW5nICh3YXM6IFdHIExhc3QgDQo+IENhbGwgY29tbWVudHMg b24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KPiANCj4gRnJl ZCwNCj4gCVRoYW5rcyBmb3IgdGhlIGlucHV0Lg0KPiANCj4gT24gMS8yOS8yMDEzIDEyOjU0IFBN LCBHcnVtYW4sIEZyZWQgd3JvdGU6DQo+PiBIaSBMb3UsDQo+Pg0KPj4gSSBhbSBub3QgY2xlYXIg b24gb3B0aW9uIDIgYXMgd2hlbiBJIGxvb2sgaW50byBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNp Z25hbGluZy1nNzA5djMtMDUsIHRoZSBJQU5BIHNlY3Rpb24gc2hvd3MgdGhlIGMtdHlwZSBmb3Ig dGhlIEdFTkVSQUxJWkVfTEFCRUwgZGVmaW5lZCBpbiBSRkMgMzQ3Mywgbm90IGEgbmV3IGMtdHlw ZS4NCj4+DQo+PiBPVE4tVERNIEdlbmVyYWxpemVkIExhYmVsIE9iamVjdDogDQo+Pg0KPj4gICAg ICAgIG8gT1ROLVRETSBHZW5lcmFsaXplZCBMYWJlbCBPYmplY3Q6IENsYXNzID0gMTYsIEMtVHlw ZSA9IDIgKHNlZSANCj4+ICAgICAgICAgIFNlY3Rpb24gNS4xKQ0KPj4NCj4gDQo+IEkgZGlkbid0 IG5vdGljZSB0aGF0IGluY29uc2lzdGVuY3kuICBQZXINCj4gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA1I3NlY3Rpb24t NToNCj4gIFRoZSB0cmFmZmljIHBhcmFtZXRlcnMgZm9yIE9UTi1URE0gY2FwYWJsZSBTd2l0Y2hp bmcgVHlwZSBhcmUgY2FycmllZCAgDQo+IGluIHRoZSBPVE4tVERNIFNFTkRFUl9UU1BFQyBhbmQg RkxPV1NQRUMgb2JqZWN0cy4gVGhlIG9iamVjdHMgaGF2ZSAgDQo+IHRoZSBmb2xsb3dpbmcgY2xh c3MgYW5kIHR5cGU6DQo+IA0KPiAgICAgLSAgT1ROLVRETSBTRU5ERVJfVFNQRUMgT2JqZWN0OiBD bGFzcyA9IDEyLCBDLVR5cGUgPSA3IChUQkEpDQo+ICAgICAtICBPVE4tVERNIEZMT1dTUEVDIE9i amVjdDogQ2xhc3MgPSA5LCBDLVR5cGUgPSA3IChUQkEpDQo+IA0KPiBMb3UNCj4gDQo+PiBJJ20g b3BlbiB0byBlaXRoZXIgY2FycnlpbmcgT0RVZmxleChHRlApIGJhbmR3aWR0aCBhcyBmbG9hdGlu Zy1wb2ludCBvciBpbnRlZ2VyIE4sIGJ1dCB3b3VsZCBsaWtlIHRvIHNlZSBjb25zaXN0ZW5jeSBi ZXR3ZWVuIHJvdXRpbmcgYW5kIHNpZ25hbGluZyBkb2N1bWVudHMuDQo+Pg0KPj4NCj4+IFJlZ2Fy ZHMsDQo+PiBGcmVkDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBP biANCj4+IEJlaGFsZiBPZiBaYWZhciBBbGkgKHphbGkpDQo+PiBTZW50OiBUdWVzZGF5LCBKYW51 YXJ5IDI5LCAyMDEzIDEwOjQxIEFNDQo+PiBUbzogTG91IEJlcmdlcjsgQ0NBTVANCj4+IFN1Ympl Y3Q6IFJlOiBbQ0NBTVBdIFBvbGwgb24gT0RVRmxleC1yZWxhdGVkIGVuY29kaW5nICh3YXM6IFdH IExhc3QgDQo+PiBDYWxsIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFs aW5nLWc3MDl2My0wNCkNCj4+DQo+PiBIaSBMb3UsIEMtY2FtcGVyczogDQo+Pg0KPj4gSSB3b3Vs ZCBwaWNrIE9wdGlvbiAyOyBpdCdzIGNsZWFuZXIgYW5kICBhZGRyZXNzZXMgdGhlIGlzc3VlIHJl bGF0ZWQgDQo+PiB0byBvdmVybG9hZGluZyB0aGUgc2FtZSBjLXR5cGUuDQo+Pg0KPj4gVGhhbmtz DQo+Pg0KPj4gUmVnYXJkc+KAplphZmFyDQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiBGcm9tOiAibGJlcmdlckBsYWJuLm5ldCIgPGxiZXJnZXJAbGFibi5uZXQ+DQo+ PiBEYXRlOiBNb25kYXksIEphbnVhcnkgMjgsIDIwMTMgMzoyNSBQTQ0KPj4gVG86ICJjY2FtcEBp ZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPg0KPj4gU3ViamVjdDogW0NDQU1QXSBQb2xsIG9uIE9E VUZsZXgtcmVsYXRlZCBlbmNvZGluZyAod2FzOiBXRyBMYXN0IENhbGwgDQo+PiBjb21tZW50cyBv biBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQpDQo+Pg0KPj4+IEFs bCwNCj4+PiAJV2Ugd291bGQgbGlrZSB0byB0cnkgdG8gY2xvc2UgdGhlIGRpc2N1c3Npb24gb24g dGhlIEcuNzA5IGRyYWZ0cyBzbyANCj4+PiB0aGF0IHdlIGNhbiBtb3ZlIHJhcGlkbHkgdG93YXJk cyBwdWJsaWNhdGlvbiByZXF1ZXN0LiAgVGhlIA0KPj4+IGRpc2N1c3Npb24gb2YgKG9uZSBvZiBt eSkgTEMgY29tbWVudHMgaGFzIHJlc3VsdGVkIGluIHNldmVyYWwgDQo+Pj4gb3B0aW9ucyBmb3Ig dGhlIHNpZ25hbGluZyBPRFUtcmVsYXRlZCB0cmFmZmljIHBhcmFtZXRlcnMsIGFuZCB0aGUgDQo+ Pj4gcG9pbnQgaGFzIGJlZW4gcmFpc2VkIHRoYXQgcmVhbGlnbmluZyByb3V0aW5nIHdpdGggc2ln bmFsaW5nIHNob3VsZCBiZSBkaXNjdXNzZWQuDQo+Pj4NCj4+PiBQbGVhc2Uga2VlcCBpbiBtaW5k IHRoYXQgdGhlIG9iamVjdGl2ZSBvZiBhbnkgUFMgaXMgDQo+Pj4gaW50ZXJvcGVyYWJpbGl0eSwg YW5kIHRoYXQgdGhlcmUgbWF5IGJlIGVhcmx5IGltcGxlbWVudGF0aW9ucyB0aGF0IG1hdGNoIGc3 MDl2My0wNC4NCj4+Pg0KPj4+IFRoZSBiYXNpYyBxdWVzdGlvbiBpcyBvbmUgb2YgaWYgTiwgdGhl IG51bWJlciBvZiB0aW1lIHNsb3RzIG5lZWRlZCANCj4+PiB0byBzdXBwb3J0IGEgT0RVZmxleChH RlApIHNpZ25hbCwgc2hvdWxkIGJlIGNhcnJpZWQgYXMgYSBjYWxjdWxhdGVkIElFRUUNCj4+PiBm bG9hdGluZyBwb2ludCBudW1iZXIgb3IgZGlyZWN0bHkuICAgT3B0aW9ucyAxIGFuZCAyIGJlbG93 IHJlZmxlY3QgdGhlDQo+Pj4gZm9ybWVyLCBvcHRpb25zIDMgYW5kIDQgbWF0Y2ggdGhlIGxhdHRl ci4gIEl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IA0KPj4+IG9ubHkgb3B0aW9ucyAxIGFuZCAyIGFy ZSBwcm9wb3NlZCBmb3IgT0RVZmxleChHRlApLCBpLmUuLCBOIG11c3QgYmUgDQo+Pj4gY2FsY3Vs YXRlZCBmb3IgT0RVZmxleChDQlIpIHNpZ25hbCB0eXBlcyB3aXRoIGFsbCBvcHRpb25zLg0KPj4+ DQo+Pj4gUGxlYXNlIHN0YXRlIHlvdXIgc3VwcG9ydCBmb3Igb25lIHRoZSBvcHRpb25zIGFuZCwg aWYgeW91IHdpc2gsIHRoZSANCj4+PiBqdXN0aWZpY2F0aW9uIGZvciB5b3VyIHBvc2l0aW9uOg0K Pj4+DQo+Pj4gMSkgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2 My0wNA0KPj4+ICAgaS5lLiwgcmVkZWZpbmUgW1JGQzQzMjhdIFRyYWZmaWMgUGFyYW1ldGVycyBj LXR5cGUgd2hlbiB1c2VkIHdpdGgNCj4+PiAgIE9UTi1URE0gbGFiZWxzLiBPRFVmbGV4KEdGUCkg bnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cyAoTikgaXMNCj4+PiAgIGVuY29kZWQgYXM6DQo+Pj4N Cj4+PiAgIC4uLiB0aGUgQml0X1JhdGUgZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSBNVVNUDQo+Pj4g ICBlcXVhbCB0byBvbmUgb2YgdGhlIDgwIHZhbHVlcyBsaXN0ZWQgYmVsb3c6DQo+Pj4NCj4+PiAg ICAgICAxICogT0RVMi50czsgMiAqIE9EVTIudHM7IC4uLjsgOCAqIE9EVTIudHM7DQo+Pj4gICAg ICAgOSAqIE9EVTMudHM7IDEwICogT0RVMy50cywgLi4uOyAzMiAqIE9EVTMudHM7DQo+Pj4gICAg ICAgMzMgKiBPRFU0LnRzOyAzNCAqIE9EVTQudHM7IC4uLjsgODAgKiBPRFU0LnRzLg0KPj4+DQo+ Pj4gMikgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNQ0K Pj4+ICAgaS5lLiwgdXNlIGEgbmV3IEMtdHlwZSBmb3IgT1ROLVRETSBsYWJlbHMuICBFbmNvZGlu ZyBkZXRhaWxzDQo+Pj4gICB1bmNoYW5nZWQgZnJvbSBnNzA5djMtMDQuDQo+Pj4gICAoVGhpcyBv cHRpb24gYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiB0aGUgc2FtZSBjLXR5cGUgbmVlZGluZyB0bw0K Pj4+ICAgIGJlIHBhcnNlZCBiYXNlZCBvbiBsYWJlbC9zd2l0Y2hpbmcgdHlwZS4pDQo+Pj4NCj4+ PiAzKSBGb2xsb3cgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA2DQo+ Pj4gICBpLmUuLCAgdXNlIGEgbmV3IEMtdHlwZSBmb3IgT1ROLVRETSBsYWJlbHMuIE4gaXMgZGly ZWN0bHkgY2FycmllZA0KPj4+ICAgZm9yIE9EVWZsZXgoR0ZQKSBvbmx5Lg0KPj4+DQo+Pj4gNCkg RGlzY3Vzc2VkLCBidXQgbm90IGluIGFueSBkcmFmdA0KPj4+ICAgVXNlIGRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNCBlbmNvZGluZyBmb3IgYWxsDQo+Pj4gICBidXQg T0RVZmxleChHRlApLCBhbmQgZGVmaW5lIG5ldyBPRFVmbGV4KEdGUCkgc3BlY2lmaWMgVHJhZmZp Yw0KPj4+ICAgUGFyYW1ldGVycyBiYXNlZCBvbiBnNzA5djMtMDYsIHByZXN1bWFibHkgd2l0aCB1 bnVzZWQgZmllbGRzDQo+Pj4gICByZW1vdmVkLg0KPj4+ICAgKFRoaXMgYWxzbyBhZGRyZXNzZXMg dGhlIGlzc3VlIG9mIHRoZSBzYW1lIGMtdHlwZSBuZWVkaW5nIHRvIGJlDQo+Pj4gICAgcGFyc2Vk IGJhc2VkIG9uIGxhYmVsIHR5cGUsIGJ1dCBtZWFucyB0aGVyZSBhcmUgZGlmZmVyZW50IHR5cGVz DQo+Pj4gICAgYmFzZWQgb24gc2lnbmFsIHR5cGUuKQ0KPj4+DQo+Pj4gT3B0aW9uIDEgYW5kIDIg ZG8gbm90IGltcGx5IGFueSBjaGFuZ2VzIHRvIHJvdXRpbmcsIHdoaWxlIG9wdGlvbnMgMyANCj4+ PiBhbmQNCj4+PiA0IG1heS4gIFJvdXRpbmcgaW1wbGljYXRpb25zIHdpbGwgYmUgZGlzY3Vzc2Vk IGJhc2VkIG9uIHRoZSByZXN1bHRzIA0KPj4+IG9mIHRoaXMgcG9sbCwgYW5kIG9ubHkgaWYgdGhl cmUgaXMgY29uc2Vuc3VzIHRvIHN1cHBvcnQgcG9zaXRpb25zIDMgb3IgNC4NCj4+Pg0KPj4+IFdl IGhvcGUgdG8gbWFrZSBhIGNvbnNlbnN1cyBjYWxsIGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWssIGJ1 dCB3aWxsIA0KPj4+IGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFzIG5lZWRlZC4NCj4+Pg0KPj4+ IE11Y2ggdGhhbmtzLA0KPj4+IExvdSAoYW5kIERlYm9yYWgpDQo+Pj4NCj4+PiBPbiAxLzI4LzIw MTMgNTowOCBBTSwgRGFuaWVsZSBDZWNjYXJlbGxpIHdyb3RlOg0KPj4+PiAgQWxsLA0KPj4+Pg0K Pj4+PiBJIHRoaW5rIHRoZSBjaGFuZ2VzIHByb3Bvc2VkIGFyZSBtZWFuaW5nZnVsIGFuZCB3b3Vs ZCBzdXBwb3J0IHRoZW0gDQo+Pj4+IGluIGFuIGluZGl2aWR1YWwgb3IgZWFybHkgV0cgZHJhZnQs IGJ1dCB0aGV5IGRvbid0IHNlZW0gdG8gcHJvdmlkZSANCj4+Pj4gc2lnbmlmaWNhdGl2ZSBhZHZh bnRhZ2VzIHRvIHJpc2sgaW50ZXJ3b3JraW5nIGlzc3VlcyB3aXRoIGVhcmx5IA0KPj4+PiBpbXBs ZW1lbnRhdGlvbnMuDQo+Pj4+IE1vcmVvdmVyIHRoZSBjaGFuZ2VzIGRvbid0IGFsbG93IHVzIGdl dHRpbmcgdG90YWxseSByaWQgb2Ygb2YgdGhlIA0KPj4+PiBiaXRfcmF0ZSBmaWVsZCBhcyBpdCBp cyBzdGlsbCBuZWVkZWQgZm9yIE9EVWZsZXggKENCUikuDQo+Pj4+DQo+Pj4+IE15IDJjDQo+Pj4+ IERhbmllbGUNCj4+Pj4NCj4+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pj4+PiBGcm9tOiBaYWZhciBBbGkgKHphbGkpIFttYWlsdG86emFsaUBjaXNjby5jb21dDQo+Pj4+ PiBTZW50OiBsdW5lZMOsIDI4IGdlbm5haW8gMjAxMyA0LjQ3DQo+Pj4+PiBUbzogTG91IEJlcmdl cg0KPj4+Pj4gQ2M6IEdydW1hbiwgRnJlZDsgRmF0YWkgWmhhbmc7IERhbmllbGUgQ2VjY2FyZWxs aTsgQ0NBTVA7IA0KPj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYz QHRvb2xzLmlldGYub3JnDQo+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0IENhbGwg Y29tbWVudHMgb24NCj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2 My0wNA0KPj4+Pj4NCj4+Pj4+IEhpIExvdS0NCj4+Pj4+DQo+Pj4+PiBQbGVhc2Ugc2VlIGluLWxp bmUuDQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcy4uLlphZmFyDQo+ Pj4+Pg0KPj4+Pj4gT24gMS8yNy8xMyA5OjQ2IFBNLCAiTG91IEJlcmdlciIgPGxiZXJnZXJAbGFi bi5uZXQ+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiBaYWZhciwNCj4+Pj4+PiAJSXMgeW91ciBjb21t ZW50IHdpdGggcmVzcGVjdCB0byBqdXN0IHJvdXRpbmcgb3IgYm90aA0KPj4+Pj4gc2lnbmFsaW5n IGFuZA0KPj4+Pj4+IHJvdXRpbmc/DQo+Pj4+Pg0KPj4+Pj4gQm90aCwgaW5jbHVkaW5nIGNvbnNp c3RlbmN5IGJldHdlZW4gc2lnbmFsaW5nIGFuZCByb3V0aW5nIGF0dHJpYnV0ZXMuDQo+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pj4gQWxzbywgd2hlbiB5b3Ugc2F5ICJpbXBsZW1lbnRhdGlvbnMgYmFzZWQg b24gZHJhZnQgdmVyc2lvbnMiLA0KPj4+Pj4gZG8gdGhlc2UNCj4+Pj4+PiBpbXBsZW1lbnRhdGlv bnMgaW5jbHVkZSBzdXBwb3J0IGZvciBPRFVmbGV4PyAgKFdoaWNoIGhhcyByZWFsbHkgDQo+Pj4+ Pj4gYmVlbiB0aGUgZm9jdXMgb2YgdGhlIGRpc2N1c3Npb24uKQ0KPj4+Pj4NCj4+Pj4+IFllcywg SSB3YXMgcmVmZXJyaW5nIHRvIE9EVUZsZXguIEFzIHlvdSBrbm93LCBmaXhlZCBPRFUgaXMgDQo+ Pj4+PiBzaWduYWxlZCB2aWEgbGV2ZWwgKDAgQlcpIHNvIGl0cyBub3QgYW4gaXNzdWUuDQo+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4gQlRXIEkgdG9vayBGcmVkJ3MgY29tbWVudHMgYXMgcmVsYXRlZCB0 byBqdXN0IHRoZSBuZXcNCj4+Pj4+IE9UTi1zcGVjaWZpYyBJU0NEDQo+Pj4+Pj4gZGVmaW5pdGlv bnMgKHNlY3Rpb24gNC4xLjIgb2Ygb3NwZi1nNzA5djMtMDUsIGluIHBhcnRpY3VsYXIpLiAgDQo+ Pj4+Pj4gTm90ZSB0aGF0IHNlY3Rpb24gNC4xLjEgYWxyZWFkeSBjYXJyaWVzIE4gKG51bWJlciBv ZiBPRFVzKSBub3QNCj4+Pj4+IElFRUUgZmxvYXRpbmcNCj4+Pj4+PiBwb2ludCByZXByZXNlbnRh dGlvbnMgb2YgYXZhaWxhYmxlIGJhbmR3aWR0aC4NCj4+Pj4+DQo+Pj4+PiBXaGF0IEkgbWVhbnQg aXMgVW5yZXNlcnZlZCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgeCBhbmQgTWF4IExTUCANCj4+Pj4+ IEJhbmR3aWR0aCBhdCBwcmlvcml0eSB4Lg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IE11Y2ggdGhh bmtzLA0KPj4+Pj4+IExvdQ0KPj4+Pj4+DQo+Pj4+Pj4gT24gMS8yNy8yMDEzIDc6NDYgUE0sIFph ZmFyIEFsaSAoemFsaSkgd3JvdGU6DQo+Pj4+Pj4+IEFsbC0NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhp cyBpbXBhY3RzIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiBkcmFmdCB2ZXJzaW9u cyANCj4+Pj4+Pj4gKGFuZCBoZW5jZSBpbnRlcm9wIHdpdGggdGhlc2UgaW1wbGVtZW50YXRpb25z IG1vdmluZyBmb3J3YXJkKS4NCj4+Pj4+IElNTyB0aGlzIGlzDQo+Pj4+Pj4+IGEgYmlnZ2VyIGNo YW5nZSBmb3IgdXMgdG8gYXNzdW1lIGF0IHRoZSBsYXN0IGNhbGwgc3RhZ2UuDQo+Pj4+PiBGdXJ0 aGVybW9yZQ0KPj4+Pj4+PiB3ZSBoYXZlIGJlZW4gdXNpbmcgSUVFRSBmbG9hdGluZyBwb2ludCBm b3JtYXQgZm9yIFVucmVzZXJ2ZWQgDQo+Pj4+Pj4+IEJhbmR3aWR0aC8gTWF4IExTUCBCVyBpbiBJ RUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCBmb3Igb3RoZXIgDQo+Pj4+Pj4+IHRlY2hub2xvZ2ll cy4gT3ZlcmFsbCwgSSB0aGluayB0aGlzIGNoYW5nZSBzdWZmZXJzIGZyb20gdGhlDQo+Pj4+PiAi bGF3IG9mIGRpbWluaXNoaW5nIHJldHVybnMiLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGFua3MNCj4+ Pj4+Pj4NCj4+Pj4+Pj4gUmVnYXJkcyDFoCBaYWZhcg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+ PiBPbiAxLzI3LzEzIDEwOjI4IEFNLCAiR3J1bWFuLCBGcmVkIg0KPj4+Pj4gPGZyZWQuZ3J1bWFu QHVzLmZ1aml0c3UuY29tPiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4+IEhpIExvdSwgRmF0YWks IERhbmllbGUsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSSB1bmRlcnN0YW5kIHRoZSBsYXRlc3QgY2hh bmdlIHRvIHRoZSB3YXkgYmFuZHdpZHRoIGlzDQo+Pj4+PiBzaWduYWxlZCBmb3INCj4+Pj4+Pj4+ IE9EVWZsZXgoR0ZQKSwgaS5lLiwgc2lnbmFsaW5nIHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNs b3RzDQo+Pj4+PiBOIGluc3RlYWQNCj4+Pj4+Pj4+IG9mICB0aGUgYmFuZHdpZHRoIHJhdGUgaW4g YnBzLiAgSSBiZWxpZXZlIHRoYXQgdGhpcyBzaW1wbGlmaWVzIA0KPj4+Pj4+Pj4gdGhlIHNpZ25h bGluZyAgYW5kIGludGVyb3BlcmFiaWxpdHkgc28gSSdtIGluIGFncmVlbWVudCB3aXRoDQo+Pj4+ PiB0aGlzIGNoYW5nZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBIb3dldmVyLCBpdCBzZWVtcyB3ZSBh cmUgbm93IGluY29uc2lzdGVudCBiZXR3ZWVuIGhvdyB3ZQ0KPj4+Pj4gcmVwcmVzZW50DQo+Pj4+ Pj4+PiBiYW5kd2lkdGggaW4gcm91dGluZyBhbmQgc2lnbmFsaW5nIGZvciBPRFVmbGV4KEdGUCku ICBSb3V0aW5nIA0KPj4+Pj4+Pj4gYWR2ZXJ0aXNlcyAgdGhlIGJhbmR3aWR0aCB1c2luZyBhIGZs b2F0aW5nIHBvaW50IHJlcHJlc2VudGF0aW9uIA0KPj4+Pj4+Pj4gb2YgYmFuZHdpZHRoLCB3aGls ZSAgc2lnbmFsaW5nIGlzIHVzaW5nIHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3RzLg0KPj4+ Pj4+Pj4gSXQgc2VlbXMgdGhlIHNhbWUgIGJlbmVmaXRzIHdvdWxkIGJlIG9idGFpbmVkIGJ5DQo+ Pj4+PiBhZHZlcnRpc2luZyB0aGUgbWF4DQo+Pj4+Pj4+PiBMU1AgYmFuZHdpZHRoIGFuZCAgdW5y ZXNlcnZlZCBiYW5kd2lkdGggZm9yIE9EVWZsZXgoR0ZQKSBpbg0KPj4+Pj4gdGVybXMgb2YNCj4+ Pj4+Pj4+IHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5ICBzbG90cy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBGcmVkDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4+Pj4+Pj4gQmVoYWxmIE9mICBM b3UgQmVyZ2VyDQo+Pj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgOTow OCBBTQ0KPj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4+PiBDYzogQ0NBTVA7IA0KPj4+ Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYu b3JnDQo+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0IENhbGwgY29tbWVudHMg b24NCj4+Pj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IEZhdGFpLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIDEvMjMvMjAx MyA2OjQ5IEFNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+Pj4+PiBIaSBMb3UsDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBGb3IgT0RVZmxleChDQlIpLCB0aGUgZm9ybXVsYSBpcyBmcm9tIFtHLjcw OS0yMDEyXSBhbmQgaXQNCj4+Pj4+IGhhcyBiZWVuDQo+Pj4+Pj4+Pj4gZGlzY3Vzc2VkIGJlZm9y ZSwgc28gcGxlYXNlIHRydXN0IHRoYXQgdGhlcmUgaXMgbm8NCj4+Pj4+IG9wcG9ydHVuaXR5IGZv cg0KPj4+Pj4+Pj4+IG1pc2ludGVycHJldGF0aW9uLiAoTm90ZSB0aGF0IHRoZXJlIGFyZSB0d28g Y2FzZXMsIG9uZSBpcw0KPj4+Pj4+Pj4+IE9EVWZsZXgoQ0JSKSBhbmQgYW5vdGhlciBvbmUgaXMg T0RVZmxleChHRlApKS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEluIGFkZHRpb24sIE9EVWZsZXgg Y2Fubm90IGJlIGNvbmNhdGVuYXRlZCBieSBbRy43MDktMjAxMl0uDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4gVGhhbmtzIGZvciBjb25maXJtaW5nIG15IHVuZGVyc3RhbmRpbmcuICBUaGlzIHJhaXNlcyB0 aGUNCj4+Pj4+IHF1ZXN0aW9uIG9mDQo+Pj4+Pj4+PiBpZiB0aGUgbmV3IHRyYWZmaWMgc2hvdWxk IGp1c3QgYXBwbHkgdG8gT0RVRmxleD8gIENvcnJlY3QNCj4+Pj4+IG1lIGlmIEknbQ0KPj4+Pj4+ Pj4gd3JvbmcsIGJ1dCBJIGJlbGlldmUgdGhlIFtSRkM0MzI4XSBpcyBzdWZmaWNpZW50IGluIGFs bA0KPj4+Pj4gb3RoZXIgY2FzZXMuICANCj4+Pj4+Pj4+IFRoaXMgbWF5IGFsc28gbWFrZSBpdCBl YXNpZXIgZm9yIGVhcmx5IGltcGxlbWVudGF0aW9ucyBvZg0KPj4+Pj4gdGhlIGRyYWZ0DQo+Pj4+ Pj4+PiBhcyB0aGVuIHRoZXkgY2FuIGxpbWl0IGNvZGUgY2hhbmdlcyBmcm9tIHRoZSAoLTAzKSBy ZXYgdG8NCj4+Pj4+IG9ubHkgT0RVZmxleCBMU1BzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEp1c3Qg dG8gYmUgY2xlYXIsIEknbSByZWFsbHkganVzdCAqYXNraW5nKiBhYm91dCB0aGlzLiAgQXMgSSAN Cj4+Pj4+Pj4+IHNhaWQgYmVmb3JlLCBJJ20gb3BlbiBvbiBzcGVjaWZpY3MuLi4NCj4+Pj4+Pj4+ DQo+Pj4+Pj4+PiBBbnkgdGhvdWdodHMvY29tbWVudHM/IEF1dGhvcnM/ICBJbXBsZW1lbnRvcnM/ DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4gTG91DQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+PiBJIHdpbGwgaXNzdWUgYSBuZXcgdmVyc2lvbiB0b21vcnJvdyB0byBj YXB0dXJlIGFsbCB5b3VyIGNvbW1lbnRzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ PiBCZXN0IFJlZ2FyZHMNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4g RnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+Pj4+Pj4+Pj4gU2Vu dDogV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDEzIDI6MTEgQU0NCj4+Pj4+Pj4+PiBUbzogRmF0 YWkgWmhhbmcNCj4+Pj4+Pj4+PiBDYzogQ0NBTVA7IA0KPj4+Pj4+Pj4+IGRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZw0KPj4+Pj4+Pj4+IFN1Ympl Y3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+Pj4+IGRyYWZ0 LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gRmF0YWksDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBPbiAxLzIwLzIwMTMgOTo0MyBQTSwgRmF0 YWkgWmhhbmcgd3JvdGU6DQo+Pj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4gWW91IHNhaWQ6DQo+Pj4+Pj4+Pj4+PiBidXQgeW91J3JlIHNheXMgZW5jb2RlZCBhcyAoTipO b21pbmFsIFJhdGUpIHJpZ2h0PyBXYXQncyB0aGUgDQo+Pj4+Pj4+Pj4+PiB2YWx1ZSBvZiAgdGhp cyB2cyBqdXN0IGNhcnJ5aW5nIE4/DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFtGYXRhaV0gVGhl IG9yaWdpbmFsIHdheSAoaW4gdmVyc2lvbiAwNCYwNSkgaXMgcHV0dGluZw0KPj4+Pj4gKE4qIE5v bWluYWwNCj4+Pj4+Pj4+Pj4gUmF0ZSkgaW4gIkJpdF9SYXRlIiBmaWVsZCBmb3IgT0RVZmxleChH RlApLCB0aGUgdmFsdWUgaXMgdGhhdCANCj4+Pj4+Pj4+Pj4gd2UgY2FuIGdlbmVyYWxpemUgdG8g anVzdCB1c2Ugb25lIHNpbmdsZSAiQml0X1JhdGUiIGZpZWxkIHRvIA0KPj4+Pj4+Pj4+PiBjYXJy eSBJRUVFIGZsb2F0IG51bWJlciBmb3IgYm90aCBjYXNlcywgaXQgc2VlbXMgdGhhdCB5b3UNCj4+ Pj4+IGRvbid0IGFncmVlIG9uDQo+Pj4+Pj4+Pj4+IHRoaXMgdmFsdWUsIDotKQ0KPj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4gSSd2ZSBzZWVuIGRpZmZlcmVuY2VzIGluIGNhbGN1bGF0ZWQgZmxvYXRpbmcg cG9pbnQgdmFsdWVzIGZyb20gDQo+Pj4+Pj4+Pj4gZGlmZmVyZW50ICBpbXBsZW1lbnRhdGlvbnMs IHNvIEkganVzdCB3YW50IHRvIGVuc3VyZSB0aGF0DQo+Pj4+PiBzdWNoIGNhc2VzDQo+Pj4+Pj4+ Pj4gYXJlIGF2b2lkZWQuDQo+Pj4+Pj4+Pj4gSSdtIG9wZW4gdG8gc3BlY2lmaWMgc29sdXRpb25z IGFuZCBjZXJ0YWlubHkgd2lsbCBkZWZmZXIgb24gDQo+Pj4+Pj4+Pj4gdGhlIHNwZWNpZmljcyBh c3N1bWluZyB0aGVyZSBpcyBubyBvcHBvcnR1bml0eSBmb3IgDQo+Pj4+Pj4+Pj4gbWlzaW50ZXJw cmV0YXRpb24vaW50ZXJvcCAgaXNzdWVzLiBJIGRvbid0IHRoaW5rIHRoZQ0KPj4+Pj4gb3JpZ2lu YWwgcGFzc2VkDQo+Pj4+Pj4+Pj4gdGhpcyB0aHJlc2hvbGQsIGkuZS4sOg0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gICAgICAgICAgTiA9IENlaWxpbmcgb2YNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAg IE9EVWZsZXgoQ0JSKSBub21pbmFsIGJpdCByYXRlICogKDEgKyBPRFVmbGV4KENCUikgYml0IHJh dGUNCj4+Pj4+Pj4+PiB0b2xlcmFuY2UpDQo+Pj4+Pj4+Pj4gICAgDQo+Pj4+Pj4+Pj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ Pj4+IC0tLS0tLS0tLS0NCj4+Pj4+Pj4+PiAgICAgICAgT0RUVWsudHMgbm9taW5hbCBiaXQgcmF0 ZSAqICgxIC0gSE8gT1BVayBiaXQgcmF0ZQ0KPj4+Pj4gdG9sZXJhbmNlKQ0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+IC4gVGhlcmVmb3JlLCBJICh3YXMpIGFtIHNheWluZyB0aGF0IEkgYW0gZ29pbmcg dG8gYWNjZXB0IHlvdXIgDQo+Pj4+Pj4+Pj4+IHN1Z2dlc3Rpb24gdG8gY2FycnkgTiBmb3IgT0RV ZmxleChHRlApLiBXZSBhcmUNCj4+Pj4+IGRpc2N1c3Npbmcgd2hlcmUgdG8NCj4+Pj4+Pj4+Pj4g cHV0IE4gZm9yIE9EVWZsZXgoR0ZQKS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBZb3Ugc2FpZDoNCj4+Pj4+Pj4+Pj4+IGJpdHMgaW4gdGhlIGNvbnRyb2wgcGxhbmUgYXJlIGdl bmVyYWxseSBjaGVhcCwgSU1PIGl0J3MNCj4+Pj4+IGJldHRlciB0bw0KPj4+Pj4+Pj4+Pj4gaGF2 ZSBzaW1wbGVyIGVuY29kaW5nIHRoYW4gdG8gb3B0aW1pemUgZXZlcnkgYml0IChvciA4IGluIA0K Pj4+Pj4+Pj4+Pj4gdGhpcyBjYXNlKS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gW0ZhdGFpXSBP SywgSSB3aWxsIGFkZCBhIG5ldyBmaWVsZCAodG8gb2NjdXB5IHRoZSByZXNlcnZlZCANCj4+Pj4+ Pj4+Pj4gYml0cykgdG8gY2FycnkgTi4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEFzIHlvdSBzZWUg Zml0Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSnVzdCB0byBjbGFyaWZ5IG15IHVuZGVyc3RhbmRp bmcsIE9EVWZsZXggYW5kIFZpcnR1YWwNCj4+Pj4+IGNvbmNhdGVuYXRpb24NCj4+Pj4+Pj4+PiBj YW4gIG5ldmVyIGJlIGNvbWJpbmVkIGZvciB0aGUgc2FtZSBzaWduYWwgdHlwZS9sZXZlbCwgcmln aHQ/DQo+Pj4+Pj4+Pj4gKEFsdGhvdWdoIGFuICBPRFVmbGV4IGNsaWVudCBzaWduYWwgY291bGQg YmUgY2FycmllZCBvdmVyDQo+Pj4+PiBhIHZpcnR1YWwNCj4+Pj4+Pj4+PiBjb25jYXRlbmF0ZWQg IE9EVWspLiAgSXMgdGhpcyBjb3JyZWN0IG9yIGRpZCBJIG1pc3Mgc29tZXRoaW5nIA0KPj4+Pj4+ Pj4+IGluIEc3MDk/DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4gTG91 DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4+IEZyb206 IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPj4+Pj4+Pj4+PiBTZW50OiBG cmlkYXksIEphbnVhcnkgMTgsIDIwMTMgMTo0MiBBTQ0KPj4+Pj4+Pj4+PiBUbzogRmF0YWkgWmhh bmcNCj4+Pj4+Pj4+Pj4gQ2M6IENDQU1QOyANCj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+Pj4+Pj4+IFN1YmplY3Q6 IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+Pj4+PiBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gT24gMS8xNS8yMDEzIDEwOjE2IFBNLCBGYXRhaSBa aGFuZyB3cm90ZToNCj4+Pj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ PiBUbyBhdm9pZCBtaXN1bmRlcnN0YW5kaW5nLCBJIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSBtb3Jl IG9uIA0KPj4+Pj4+Pj4+Pj4gdGhlIGZvbGxvd2luZyBwb2ludC4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IEl0IGlzIGJldHRlciB0byBoYXZlIGNvbnNpc3RlbnQg Zm9ybWF0IGFuZCB0aGUgc2FtZSANCj4+Pj4+Pj4+Pj4+Pj4+PiBtZWFuaW5nIG9mIG9uZQ0KPj4+ Pj4+Pj4+PiBmaWVsZCBmb3IgYm90aCBPRFVmbGV4KENCUikgYW5kIEdGUC4gVGhpcyBpcyB3aHkg d2UgaGF2ZSANCj4+Pj4+Pj4+Pj4gc2VjdGlvbg0KPj4+Pj4+Pj4+PiA1LjENCj4+Pj4+Pj4+Pj4g JjUuMiB0byBkZXNjcmliZSB0aGUgY29tcGxleCBzdHVmZi4NCj4+Pj4+Pj4+Pj4+Pj4+IEkgYWN0 dWFsbHkgd2Fzbid0IHN1Z2dlc3RpbmcgdGhhdCBOIGJlIGNhcnJpZWQgaW4NCj4+Pj4+IHRoZSBi aXQgcmF0ZQ0KPj4+Pj4+Pj4+Pj4+Pj4gZmllbGQuDQo+Pj4+Pj4+Pj4+Pj4+PiBUaGUgYml0IHJh dGUgZmllbGQgY2FuIGVpdGhlciBiZSBzZXQgYXMgZGVzY3JpYmVkIG9yIHRvIA0KPj4+Pj4+Pj4+ Pj4+Pj4gemVybyAoaS5lLiwgIGlnbm9yZWQpLiAgQXQgdGhlIHRpbWUsIEkgd2FzIHRoaW5raW5n IGFib3V0DQo+Pj4+PiBjYXJyeWluZyBODQo+Pj4+Pj4+Pj4+Pj4+PiBpbiB0aGUgIHJlc2VydmVk ICBmaWVsZC4gQnV0IHBlcmhhcHMgdGhlIHJpZ2h0IHBsYWNlDQo+Pj4+PiBpcyBNVCwgaWYNCj4+ Pj4+Pj4+Pj4+Pj4+IG15IHVuZGVyc3RhbmRpbmcgaXMgIHJpZ2h0ICAod291bGQgYWx3YXlzIGJl IDENCj4+Pj4+IG90aGVyd2lzZSkuIEknbQ0KPj4+Pj4+Pj4+Pj4+Pj4gb3BlbiB0byBlaXRoZXIu Li4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IFtGYXRhaV0gV2h5IG5vdCBqdXN0IHVz ZSAiYml0IHJhdGUiZmllbGQgdG8gY2FycnkNCj4+Pj4+ICJOImJlY2F1c2UgIk4iDQo+Pj4+Pj4+ Pj4+Pj4+IGltcGxpZXMgYml0IHJhdGU/ICBJIGFtIE9LIGlmIHlvdSBsaWtlIHRvIHVzZSBhIG5l dw0KPj4+Pj4gZmlsZWQgKGxpa2UNCj4+Pj4+Pj4+Pj4+Pj4gIlRTDQo+Pj4+Pj4+Pj4+Pj4+IE51 bWJlciIpIHRvIG9jY3VweSB0aGUgcmVzZXJ2ZWQgZmllbGQgZXZlbiB0aG91Z2gNCj4+Pj4+IHRo YXQgSSBwcmVmZXINCj4+Pj4+Pj4+Pj4+Pj4gdGhlICBvcmlnaW5hbCBhcHByb2FjaCAoaWUuLCB1 c2UgImJpdCByYXRlImZpZWxkIHRvIGNhcnJ5ICJOIikuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+PiBBcmUgeW91IHByb3Bvc2luZyBkcm9wcGluZyBjYXJyeWluZyBiaXQgcmF0ZXMNCj4+Pj4+ IHJlcHJlc2VudGVkIGFzIGFuDQo+Pj4+Pj4+Pj4+Pj4gSUVFRSAgZmxvYXRpbmcgcG9pbnQgYW5k IGp1c3QgY2FycnlpbmcgTiBmb3IgT0RVZmxleD8NCj4+Pj4+IFRoaXMgc2VlbXMNCj4+Pj4+Pj4+ Pj4+PiB3b3JrYWJsZSAgdG8gIG1lLCBidXQgd2Ugc2hvdWxkIGVuc3VyZSB0aGF0IHRoZXJlIGFy ZSBubyANCj4+Pj4+Pj4+Pj4+PiBzaWduaWZpY2FudCBvYmplY3Rpb25zLg0KPj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+IFtGYXRhaV0gVGhlcmUgYXJlIHR3byB1c2FnZXMgZm9yICIgQml0X1JhdGUg IiBmaWVsZCBhcw0KPj4+Pj4gZGVzY3JpYmVkDQo+Pj4+Pj4+Pj4+PiBpbiB0aGUgbGluZXMgMjg3 LTMxMC4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAoMSkgICAgRm9yIE9EVWZsZXgoQ0JSKSwg dGhlIEJpdF9SYXRlIGZpZWxkIGluZGljYXRlcw0KPj4+Pj4gdGhlIG5vbWluYWwNCj4+Pj4+Pj4+ Pj4+IGJpdA0KPj4+Pj4+Pj4+Pj4gcmF0ZSBvZiBPRFVmbGV4KENCUikgZXhwcmVzc2VkIGluIGJ5 dGVzIHBlciBzZWNvbmQsDQo+Pj4+PiBlbmNvZGVkIGFzIGENCj4+Pj4+Pj4+Pj4+IDMyLWJpdCAg SUVFRSBzaW5nbGUgcHJlY2lzaW9uIGZsb2F0aW5nLXBvaW50IG51bWJlci4gRm9yIA0KPj4+Pj4+ Pj4+Pj4gdGhpcyBjYXNlLCB3ZSBNVVNUICB1c2UgIDMyLWJpdCBJRUVFIGZsb2F0aW5nIHBvaW50 IGluc3RlYWQgDQo+Pj4+Pj4+Pj4+PiBvZiAiTiIoUGxlYXNlIHNlZSBtb3JlIGluIHNlY3Rpb24g IDUuMSkuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEkgZ3Vlc3MgeW91IHJlYWxseSBzdGlsbCBu ZWVkICh0byBiZSBiYXNlZCBvbikgdGhlIGNsaWVudCANCj4+Pj4+Pj4+Pj4gc2lnbmFsIHJhdGUg YXQgdGhlIGVkZ2VzLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ICgyKSAg ICBGb3IgT0RVZmxleChHRlApLCB3ZSBjYW4gY2hhbmdlIHRoZSB0ZXh0ICh0aGUNCj4+Pj4+IGxp bmVzIGZyb20gMzA1DQo+Pj4+Pj4+Pj4+PiB0bw0KPj4+Pj4+Pj4+Pj4gMzEwKSBiYXNlZCBvbiB5 b3VyIHN1Z2dlc3Rpb24sIGllLiwgdGhlIEJpdF9SYXRlIGZpZWxkDQo+Pj4+PiBpcyB1c2VkIHRv DQo+Pj4+Pj4+Pj4+PiBjYXJyeSAgIk4idG8gaW5kaWNhdGUgdGhlIG5vbWluYWwgYml0IHJhdGUg b2YgdGhlICBPRFVmbGV4KEdGUCkuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IGJ1dCB5b3UncmUg c2F5cyBlbmNvZGVkIGFzIChOKk5vbWluYWwgUmF0ZSkgcmlnaHQ/ICBXYXQncyB0aGUgDQo+Pj4+ Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBUaGVyZWZvcmUsIEkgYW0gcHJvcG9z aW5nIHVzaW5nIG9uZSBzaW5nbGUgZmlsZWQgKCJCaXRfUmF0ZSANCj4+Pj4+Pj4+Pj4+ICIpIGZv ciB0aGVzZSB0d28gY2FzZXMsIGluIHRoaXMgd2F5LCB3ZSBjYW4gbGVhdmUgdGhlICJSZXNlcnZl ZCINCj4+Pj4+Pj4+Pj4+IGJpdHMgZm9yIGZ1dHVyZS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g Yml0cyBpbiB0aGUgY29udHJvbCBwbGFuZSBhcmUgZ2VuZXJhbGx5IGNoZWFwLCBJTU8gaXQncw0K Pj4+Pj4gYmV0dGVyIHRvDQo+Pj4+Pj4+Pj4+IGhhdmUgIHNpbXBsZXIgZW5jb2RpbmcgdGhhbiB0 byBvcHRpbWl6ZSBldmVyeSBiaXQgKG9yIDggaW4gDQo+Pj4+Pj4+Pj4+IHRoaXMgY2FzZSkuDQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IExvdQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+IEhvcGUgd2UgYXJlIG5vdyBhdCB0aGUgc2FtZSBwYWdlLg0KPj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBCZXN0IFJlZ2FyZHMNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+PiBGYXRhaQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4g Q0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBDQ0FNUEBpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+IENDQU1Q IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pg0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gQ0NBTVAgbWFpbGlu ZyBsaXN0DQo+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NjYW1wDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4gQ0NBTVBAaWV0Zi5v cmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFp bGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcA0K From daniele.ceccarelli@ericsson.com Wed Jan 30 00:36:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0D321F8775 for ; Wed, 30 Jan 2013 00:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 LZWc+dk1L4Ao for ; Wed, 30 Jan 2013 00:36:26 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDE121F85A2 for ; Wed, 30 Jan 2013 00:36:24 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-fe-5108db88e742 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E5.56.10459.88BD8015; Wed, 30 Jan 2013 09:36:24 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 09:36:23 +0100 From: Daniele Ceccarelli To: Lou Berger Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZXHtjks61frnEil2tqgrQxB9Zhgcs6AgAAo+jD///wqgIAA9BgQ Date: Wed, 30 Jan 2013 08:36:22 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4807506B@ESESSMB301.ericsson.se> References: <5106DED0.3090008@labn.net> <4A1562797D64E44993C5CBF38CF1BE48074CE1@ESESSMB301.ericsson.se> <51081AAF.8030601@labn.net> In-Reply-To: <51081AAF.8030601@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvrW7HbY5Agy13BSyezLnBYtHR/JbF gcljyZKfTB4fNjWzBTBFcdmkpOZklqUW6dslcGW8nNHPUvDhJGPF4w8/2RsYbxxh7GLk5JAQ MJHY0vuWBcIWk7hwbz1bFyMXh5DAIUaJnqvboJzFjBJzD25g72Lk4GATsJJ4csgHpEFEQFHi 68dFTCA2s4CUxN1bXYwg9cICTYwSCz5eZQJxRASaGSV2bfzFCNHhJvFkMsgKTg4WAVWJm/em g3XzCnhLtP8/CBYXEjjBKLHlnTrIMk4BDYkl38VAwowCshITdi9ihFgmLnHryXwmiKsFJJbs Oc8MYYtKvHz8jxXCVpTYebadGWQMs4CmxPpd+hCtihJTuh+yQ2wVlDg58wnLBEaxWUimzkLo mIWkYxaSjgWMLKsY2XMTM3PSyw03MQKj5OCW37o7GE+dEznEKM3BoiTOG+Z6IUBIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDYwrnQuGpMx687g88f/nTdaY1jqWbPhcfuem/8Z7bslUTVmpW ZG8MnFXI5LXfYt3N0MefPDkU1DkDvyTLHinU1d/anhj5Yq/3ff4d2aZ+RqoHU/4F/5YV9HNO z2/jrLN+NtH12t2gTnOOo4/1jnmoh8hOOhb1mfd5qUFjvoPztvuaSX66eQLPlFiKMxINtZiL ihMBFUUE8GACAAA= Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 08:36:27 -0000 TG91LCANCg0KaXQgd2FzIHJlYWxseSBqdXN0IGEgam9rZSwgbm8gaGlkZGVuIG1lYW5pbmdzLiAN CklmIHdlIGZpbmQgYSByZWFzb25hYmxlIHNvbHV0aW9uIGZvciBzaWduYWxpbmcgdGhhdCBpbXBs aWVzIG1vZGlmaWNhdGlvbnMgdG8gdGhlIHJvdXRpbmcgd2Ugd2lsbCBtb2RpZnkgdGhlIHJvdXRp bmcgdG9vIChoZXJlIEkgYWdyZWUgd2l0aCBGcmVkIHRoYXQgYWxpZ25tZW50IGJldHdlZW4gc2ln bmFsaW5nIGFuZCByb3V0aW5nIGlzIGEgU0hPVUxELCBpZiBub3QgYSBNVVNUKS4NCg0KSW5kZXBu ZGVudGx5IGZyb20gY2hhbmdlcyB0byB0aGUgcm91dGluZyBpIHN0aWxsIGJlbGlldmUgdGhhdCBv cHRpb24gMiBpcyB0aGUgbW9zdCByZWFzb25hYmxlLiBUaGUgZmFjdCB0aGF0IGl0IGlzIG9uZSBv ZiB0aGUgb3B0aW9ucyB0aGF0IGRvZXMgbm90IGltcGx5IGNoYW5nZXMgdG8gdGhlIHJvdXRpbmcg aXMganVzdCBhIGNvaW5jaWRlbmNlLg0KDQpUaGFua3MsDQpEYW5pZWxlDQoNCj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4u bmV0XSANCj5TZW50OiBtYXJ0ZWTDrCAyOSBnZW5uYWlvIDIwMTMgMTkuNTQNCj5UbzogRGFuaWVs ZSBDZWNjYXJlbGxpDQo+Q2M6IENDQU1QDQo+U3ViamVjdDogUmU6IFtDQ0FNUF0gUG9sbCBvbiBP RFVGbGV4LXJlbGF0ZWQgZW5jb2RpbmcgKHdhczogV0cgDQo+TGFzdCBDYWxsIGNvbW1lbnRzIG9u IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNCkNCj4NCj5EYW5pZWxl LA0KPglKb2tpbmcgYXNpZGUsIEkgdGhpbmsgaXQgbWF5IGFkZCB2YWx1ZSB0byB0aGUgDQo+ZGlz Y3Vzc2lvbiB0byBoaWdobGlnaHQgeW91ciByYXRpb25hbCBmb3Igbm90IHdhbnRpbmcgdG8gDQo+ Y2hhbmdlIHJvdXRpbmcuICAoWW91IGFyZSBhZnRlciBhbGwgdGhlIGVkaXRvciBvZiB0aGUgcm91 dGluZyBkcmFmdC4pDQo+DQo+SXMgaXQ6DQo+LSBKdXN0IGF2b2lkaW5nIHdvcmsgZm9yIHRoZSBl ZGl0b3IgKGkuZS4sIHlvdXIgam9rZS4uLik/DQo+LSBNaW5pbWl6aW5nIGEgY2hhbmdlIGF0IHRo aXMgbGF0ZSBkYXRlPw0KPi0gTWluaW1pemluZyBpbXBhY3Qgb24gYW4gZWFybHkgaW1wbGVtZW50 YXRpb24/DQo+LSBTb21ldGhpbmcgY29tcGxldGVseSBkaWZmZXJlbnQ/DQo+DQo+SWYgeW91IGRv bid0IG1pbmQgc2hhcmluZy4uLg0KPg0KPlRoYW5rcywNCj5Mb3UNCj4NCj5PbiAxLzI5LzIwMTMg MTozMSBQTSwgRGFuaWVsZSBDZWNjYXJlbGxpIHdyb3RlOg0KPj4gT3B0aW9uIDIgZm9yIG1lIHRv by4NCj4+IA0KPj4gTWFpbiByZWFzb24/IEkgZG9uJ3QgaGF2ZSB0byBjaGFuZ2UgdGhlIHJvdXRp bmcgSUQhIDotKSANCj4uLi5vYnZpb3VzbHkgam9raW5nLg0KPj4gDQo+PiBPdGhlciByZWFzb25z PyBBZ3JlZSB3aXRoIEZhdGFpIGFuZCBaYWZhci4gQW5kIHByZWZlciAyKSB0byANCj4xKSBiZWNh dXNlIGRlZmluZXMgYSBuZXcgQy10eXBlLg0KPj4gDQo+PiBCUg0KPj4gRGFuaWVsZQ0KPj4gDQo+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+Pj4gQmVoYWxmIE9m IFphZmFyIEFsaSAoemFsaSkNCj4+PiBTZW50OiBtYXJ0ZWTDrCAyOSBnZW5uYWlvIDIwMTMgMTcu NDENCj4+PiBUbzogTG91IEJlcmdlcjsgQ0NBTVANCj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBQ b2xsIG9uIE9EVUZsZXgtcmVsYXRlZCBlbmNvZGluZyAod2FzOiBXRyBMYXN0IA0KPj4+IENhbGwg Y29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0KQ0K Pj4+DQo+Pj4gSGkgTG91LCBDLWNhbXBlcnM6IA0KPj4+DQo+Pj4gSSB3b3VsZCBwaWNrIE9wdGlv biAyOyBpdCdzIGNsZWFuZXIgYW5kICBhZGRyZXNzZXMgdGhlIA0KPmlzc3VlIHJlbGF0ZWQgDQo+ Pj4gdG8gb3ZlcmxvYWRpbmcgdGhlIHNhbWUgYy10eXBlLg0KPj4+DQo+Pj4gVGhhbmtzDQo+Pj4N Cj4+PiBSZWdhcmRz4oCmWmFmYXINCj4+Pg0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+PiBGcm9tOiAibGJlcmdlckBsYWJuLm5ldCIgPGxiZXJnZXJAbGFibi5uZXQ+DQo+ Pj4gRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDEzIDM6MjUgUE0NCj4+PiBUbzogImNjYW1w QGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+DQo+Pj4gU3ViamVjdDogW0NDQU1QXSBQb2xsIG9u IE9EVUZsZXgtcmVsYXRlZCBlbmNvZGluZyAod2FzOiBXRyANCj5MYXN0IENhbGwgDQo+Pj4gY29t bWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KPj4+ DQo+Pj4+IEFsbCwNCj4+Pj4gCVdlIHdvdWxkIGxpa2UgdG8gdHJ5IHRvIGNsb3NlIHRoZSBkaXNj dXNzaW9uIG9uIHRoZQ0KPj4+IEcuNzA5IGRyYWZ0cyBzbw0KPj4+PiB0aGF0IHdlIGNhbiBtb3Zl IHJhcGlkbHkgdG93YXJkcyBwdWJsaWNhdGlvbiByZXF1ZXN0LiAgVGhlIA0KPj4+PiBkaXNjdXNz aW9uIG9mIChvbmUgb2YgbXkpIExDIGNvbW1lbnRzIGhhcyByZXN1bHRlZCBpbiBzZXZlcmFsIA0K Pj4+PiBvcHRpb25zIGZvciB0aGUgc2lnbmFsaW5nIE9EVS1yZWxhdGVkIHRyYWZmaWMgcGFyYW1l dGVycywgYW5kIHRoZSANCj4+Pj4gcG9pbnQgaGFzDQo+Pj4gYmVlbiByYWlzZWQNCj4+Pj4gdGhh dCByZWFsaWduaW5nIHJvdXRpbmcgd2l0aCBzaWduYWxpbmcgc2hvdWxkIGJlIGRpc2N1c3NlZC4N Cj4+Pj4NCj4+Pj4gUGxlYXNlIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBvYmplY3RpdmUgb2YgYW55 IFBTIGlzIA0KPj4+PiBpbnRlcm9wZXJhYmlsaXR5LCBhbmQgdGhhdCB0aGVyZSBtYXkgYmUgZWFy bHkgDQo+aW1wbGVtZW50YXRpb25zIHRoYXQgbWF0Y2ggZzcwOXYzLTA0Lg0KPj4+Pg0KPj4+PiBU aGUgYmFzaWMgcXVlc3Rpb24gaXMgb25lIG9mIGlmIE4sIHRoZSBudW1iZXIgb2YgdGltZSBzbG90 cyBuZWVkZWQgDQo+Pj4+IHRvIHN1cHBvcnQgYSBPRFVmbGV4KEdGUCkgc2lnbmFsLCBzaG91bGQg YmUgY2FycmllZCBhcyBhIA0KPmNhbGN1bGF0ZWQgSUVFRQ0KPj4+PiBmbG9hdGluZyBwb2ludCBu dW1iZXIgb3IgZGlyZWN0bHkuICAgT3B0aW9ucyAxIGFuZCAyIGJlbG93IA0KPnJlZmxlY3QgdGhl DQo+Pj4+IGZvcm1lciwgb3B0aW9ucyAzIGFuZCA0IG1hdGNoIHRoZSBsYXR0ZXIuICBJdCBpcyB3 b3J0aCBub3RpbmcNCj4+PiB0aGF0IG9ubHkNCj4+Pj4gb3B0aW9ucyAxIGFuZCAyIGFyZSBwcm9w b3NlZCBmb3IgT0RVZmxleChHRlApLCBpLmUuLCBOIG11c3QgYmUgDQo+Pj4+IGNhbGN1bGF0ZWQg Zm9yIE9EVWZsZXgoQ0JSKSBzaWduYWwgdHlwZXMgd2l0aCBhbGwgb3B0aW9ucy4NCj4+Pj4NCj4+ Pj4gUGxlYXNlIHN0YXRlIHlvdXIgc3VwcG9ydCBmb3Igb25lIHRoZSBvcHRpb25zIGFuZCwgaWYg eW91IA0KPndpc2gsIHRoZSANCj4+Pj4ganVzdGlmaWNhdGlvbiBmb3IgeW91ciBwb3NpdGlvbjoN Cj4+Pj4NCj4+Pj4gMSkgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3 MDl2My0wNA0KPj4+PiAgIGkuZS4sIHJlZGVmaW5lIFtSRkM0MzI4XSBUcmFmZmljIFBhcmFtZXRl cnMgYy10eXBlIHdoZW4gdXNlZCB3aXRoDQo+Pj4+ICAgT1ROLVRETSBsYWJlbHMuIE9EVWZsZXgo R0ZQKSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3RzIChOKSBpcw0KPj4+PiAgIGVuY29kZWQgYXM6 DQo+Pj4+DQo+Pj4+ICAgLi4uIHRoZSBCaXRfUmF0ZSBmaWVsZCBmb3IgT0RVZmxleChHRlApIE1V U1QNCj4+Pj4gICBlcXVhbCB0byBvbmUgb2YgdGhlIDgwIHZhbHVlcyBsaXN0ZWQgYmVsb3c6DQo+ Pj4+DQo+Pj4+ICAgICAgIDEgKiBPRFUyLnRzOyAyICogT0RVMi50czsgLi4uOyA4ICogT0RVMi50 czsNCj4+Pj4gICAgICAgOSAqIE9EVTMudHM7IDEwICogT0RVMy50cywgLi4uOyAzMiAqIE9EVTMu dHM7DQo+Pj4+ICAgICAgIDMzICogT0RVNC50czsgMzQgKiBPRFU0LnRzOyAuLi47IDgwICogT0RV NC50cy4NCj4+Pj4NCj4+Pj4gMikgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFs aW5nLWc3MDl2My0wNQ0KPj4+PiAgIGkuZS4sIHVzZSBhIG5ldyBDLXR5cGUgZm9yIE9UTi1URE0g bGFiZWxzLiAgRW5jb2RpbmcgZGV0YWlscw0KPj4+PiAgIHVuY2hhbmdlZCBmcm9tIGc3MDl2My0w NC4NCj4+Pj4gICAoVGhpcyBvcHRpb24gYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiB0aGUgc2FtZSBj LXR5cGUgbmVlZGluZyB0bw0KPj4+PiAgICBiZSBwYXJzZWQgYmFzZWQgb24gbGFiZWwvc3dpdGNo aW5nIHR5cGUuKQ0KPj4+Pg0KPj4+PiAzKSBGb2xsb3cgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1z aWduYWxpbmctZzcwOXYzLTA2DQo+Pj4+ICAgaS5lLiwgIHVzZSBhIG5ldyBDLXR5cGUgZm9yIE9U Ti1URE0gbGFiZWxzLiBOIGlzIGRpcmVjdGx5IGNhcnJpZWQNCj4+Pj4gICBmb3IgT0RVZmxleChH RlApIG9ubHkuDQo+Pj4+DQo+Pj4+IDQpIERpc2N1c3NlZCwgYnV0IG5vdCBpbiBhbnkgZHJhZnQN Cj4+Pj4gICBVc2UgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0IGVu Y29kaW5nIGZvciBhbGwNCj4+Pj4gICBidXQgT0RVZmxleChHRlApLCBhbmQgZGVmaW5lIG5ldyBP RFVmbGV4KEdGUCkgc3BlY2lmaWMgVHJhZmZpYw0KPj4+PiAgIFBhcmFtZXRlcnMgYmFzZWQgb24g ZzcwOXYzLTA2LCBwcmVzdW1hYmx5IHdpdGggdW51c2VkIGZpZWxkcw0KPj4+PiAgIHJlbW92ZWQu DQo+Pj4+ICAgKFRoaXMgYWxzbyBhZGRyZXNzZXMgdGhlIGlzc3VlIG9mIHRoZSBzYW1lIGMtdHlw ZSBuZWVkaW5nIHRvIGJlDQo+Pj4+ICAgIHBhcnNlZCBiYXNlZCBvbiBsYWJlbCB0eXBlLCBidXQg bWVhbnMgdGhlcmUgYXJlIGRpZmZlcmVudCB0eXBlcw0KPj4+PiAgICBiYXNlZCBvbiBzaWduYWwg dHlwZS4pDQo+Pj4+DQo+Pj4+IE9wdGlvbiAxIGFuZCAyIGRvIG5vdCBpbXBseSBhbnkgY2hhbmdl cyB0byByb3V0aW5nLCB3aGlsZQ0KPj4+IG9wdGlvbnMgMyBhbmQNCj4+Pj4gNCBtYXkuICBSb3V0 aW5nIGltcGxpY2F0aW9ucyB3aWxsIGJlIGRpc2N1c3NlZCBiYXNlZCBvbiB0aGUNCj4+PiByZXN1 bHRzIG9mDQo+Pj4+IHRoaXMgcG9sbCwgYW5kIG9ubHkgaWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRv IHN1cHBvcnQgDQo+cG9zaXRpb25zIDMgb3IgNC4NCj4+Pj4NCj4+Pj4gV2UgaG9wZSB0byBtYWtl IGEgY29uc2Vuc3VzIGNhbGwgYnkgdGhlIGVuZCBvZiB0aGUgd2VlaywgYnV0IHdpbGwgDQo+Pj4+ IGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFzIG5lZWRlZC4NCj4+Pj4NCj4+Pj4gTXVjaCB0aGFu a3MsDQo+Pj4+IExvdSAoYW5kIERlYm9yYWgpDQo+Pj4+DQo+Pj4+IE9uIDEvMjgvMjAxMyA1OjA4 IEFNLCBEYW5pZWxlIENlY2NhcmVsbGkgd3JvdGU6DQo+Pj4+PiAgQWxsLA0KPj4+Pj4NCj4+Pj4+ IEkgdGhpbmsgdGhlIGNoYW5nZXMgcHJvcG9zZWQgYXJlIG1lYW5pbmdmdWwgYW5kIHdvdWxkDQo+ Pj4gc3VwcG9ydCB0aGVtIGluDQo+Pj4+PiBhbiBpbmRpdmlkdWFsIG9yIGVhcmx5IFdHIGRyYWZ0 LCBidXQgdGhleSBkb24ndCBzZWVtIHRvIHByb3ZpZGUgDQo+Pj4+PiBzaWduaWZpY2F0aXZlIGFk dmFudGFnZXMgdG8gcmlzayBpbnRlcndvcmtpbmcgaXNzdWVzIHdpdGggZWFybHkgDQo+Pj4+PiBp bXBsZW1lbnRhdGlvbnMuDQo+Pj4+PiBNb3Jlb3ZlciB0aGUgY2hhbmdlcyBkb24ndCBhbGxvdyB1 cyBnZXR0aW5nIHRvdGFsbHkgcmlkIG9mIG9mIHRoZSANCj4+Pj4+IGJpdF9yYXRlIGZpZWxkIGFz IGl0IGlzIHN0aWxsIG5lZWRlZCBmb3IgT0RVZmxleCAoQ0JSKS4NCj4+Pj4+DQo+Pj4+PiBNeSAy Yw0KPj4+Pj4gRGFuaWVsZQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBaYWZhciBBbGkgKHphbGkpIFttYWlsdG86emFsaUBjaXNj by5jb21dDQo+Pj4+Pj4gU2VudDogbHVuZWTDrCAyOCBnZW5uYWlvIDIwMTMgNC40Nw0KPj4+Pj4+ IFRvOiBMb3UgQmVyZ2VyDQo+Pj4+Pj4gQ2M6IEdydW1hbiwgRnJlZDsgRmF0YWkgWmhhbmc7IERh bmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVA7IA0KPj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt c2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NB TVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4+DQo+Pj4+Pj4gSGkgTG91LQ0KPj4+Pj4+DQo+ Pj4+Pj4gUGxlYXNlIHNlZSBpbi1saW5lLg0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzDQo+Pj4+Pj4N Cj4+Pj4+PiBSZWdhcmRzLi4uWmFmYXINCj4+Pj4+Pg0KPj4+Pj4+IE9uIDEvMjcvMTMgOTo0NiBQ TSwgIkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+ PiBaYWZhciwNCj4+Pj4+Pj4gCUlzIHlvdXIgY29tbWVudCB3aXRoIHJlc3BlY3QgdG8ganVzdCBy b3V0aW5nIG9yIGJvdGgNCj4+Pj4+PiBzaWduYWxpbmcgYW5kDQo+Pj4+Pj4+IHJvdXRpbmc/DQo+ Pj4+Pj4NCj4+Pj4+PiBCb3RoLCBpbmNsdWRpbmcgY29uc2lzdGVuY3kgYmV0d2VlbiBzaWduYWxp bmcgYW5kIHJvdXRpbmcNCj4+PiBhdHRyaWJ1dGVzLg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ IEFsc28sIHdoZW4geW91IHNheSAiaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIGRyYWZ0IHZlcnNp b25zIiwNCj4+Pj4+PiBkbyB0aGVzZQ0KPj4+Pj4+PiBpbXBsZW1lbnRhdGlvbnMgaW5jbHVkZSBz dXBwb3J0IGZvciBPRFVmbGV4PyAgKFdoaWNoIGhhcyByZWFsbHkgDQo+Pj4+Pj4+IGJlZW4gdGhl IGZvY3VzIG9mIHRoZSBkaXNjdXNzaW9uLikNCj4+Pj4+Pg0KPj4+Pj4+IFllcywgSSB3YXMgcmVm ZXJyaW5nIHRvIE9EVUZsZXguIEFzIHlvdSBrbm93LCBmaXhlZCBPRFUgaXMNCj4+PiBzaWduYWxl ZA0KPj4+Pj4+IHZpYSBsZXZlbCAoMCBCVykgc28gaXRzIG5vdCBhbiBpc3N1ZS4NCj4+Pj4+Pg0K Pj4+Pj4+Pg0KPj4+Pj4+PiBCVFcgSSB0b29rIEZyZWQncyBjb21tZW50cyBhcyByZWxhdGVkIHRv IGp1c3QgdGhlIG5ldw0KPj4+Pj4+IE9UTi1zcGVjaWZpYyBJU0NEDQo+Pj4+Pj4+IGRlZmluaXRp b25zIChzZWN0aW9uIDQuMS4yIG9mIG9zcGYtZzcwOXYzLTA1LCBpbg0KPj4+IHBhcnRpY3VsYXIp LiAgTm90ZQ0KPj4+Pj4+PiB0aGF0IHNlY3Rpb24gNC4xLjEgYWxyZWFkeSBjYXJyaWVzIE4gKG51 bWJlciBvZiBPRFVzKSBub3QNCj4+Pj4+PiBJRUVFIGZsb2F0aW5nDQo+Pj4+Pj4+IHBvaW50IHJl cHJlc2VudGF0aW9ucyBvZiBhdmFpbGFibGUgYmFuZHdpZHRoLg0KPj4+Pj4+DQo+Pj4+Pj4gV2hh dCBJIG1lYW50IGlzIFVucmVzZXJ2ZWQgQmFuZHdpZHRoIGF0IHByaW9yaXR5IHggYW5kIE1heCBM U1AgDQo+Pj4+Pj4gQmFuZHdpZHRoIGF0IHByaW9yaXR5IHguDQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gTXVjaCB0aGFua3MsDQo+Pj4+Pj4+IExvdQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiAxLzI3 LzIwMTMgNzo0NiBQTSwgWmFmYXIgQWxpICh6YWxpKSB3cm90ZToNCj4+Pj4+Pj4+IEFsbC0NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGlzIGltcGFjdHMgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGJh c2VkIG9uIGRyYWZ0DQo+Pj4gdmVyc2lvbnMgKGFuZA0KPj4+Pj4+Pj4gaGVuY2UgaW50ZXJvcCB3 aXRoIHRoZXNlIGltcGxlbWVudGF0aW9ucyBtb3ZpbmcgZm9yd2FyZCkuDQo+Pj4+Pj4gSU1PIHRo aXMgaXMNCj4+Pj4+Pj4+IGEgYmlnZ2VyIGNoYW5nZSBmb3IgdXMgdG8gYXNzdW1lIGF0IHRoZSBs YXN0IGNhbGwgc3RhZ2UuDQo+Pj4+Pj4gRnVydGhlcm1vcmUNCj4+Pj4+Pj4+IHdlIGhhdmUgYmVl biB1c2luZyBJRUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCBmb3IgVW5yZXNlcnZlZCANCj4+Pj4+ Pj4+IEJhbmR3aWR0aC8gTWF4IExTUCBCVyBpbiBJRUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCBm b3Igb3RoZXIgDQo+Pj4+Pj4+PiB0ZWNobm9sb2dpZXMuIE92ZXJhbGwsIEkgdGhpbmsgdGhpcyBj aGFuZ2Ugc3VmZmVycyBmcm9tIHRoZQ0KPj4+Pj4+ICJsYXcgb2YgZGltaW5pc2hpbmcgcmV0dXJu cyIuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhhbmtzDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gUmVnYXJk cyDFoCBaYWZhcg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBPbiAxLzI3LzEzIDEwOjI4 IEFNLCAiR3J1bWFuLCBGcmVkIg0KPj4+Pj4+IDxmcmVkLmdydW1hbkB1cy5mdWppdHN1LmNvbT4g d3JvdGU6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEhpIExvdSwgRmF0YWksIERhbmllbGUsDQo+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+PiBJIHVuZGVyc3RhbmQgdGhlIGxhdGVzdCBjaGFuZ2UgdG8gdGhlIHdh eSBiYW5kd2lkdGggaXMNCj4+Pj4+PiBzaWduYWxlZCBmb3INCj4+Pj4+Pj4+PiBPRFVmbGV4KEdG UCksIGkuZS4sIHNpZ25hbGluZyB0aGUgbnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cw0KPj4+Pj4+ IE4gaW5zdGVhZA0KPj4+Pj4+Pj4+IG9mICB0aGUgYmFuZHdpZHRoIHJhdGUgaW4gYnBzLiAgSSBi ZWxpZXZlIHRoYXQgdGhpcyANCj5zaW1wbGlmaWVzIA0KPj4+Pj4+Pj4+IHRoZSBzaWduYWxpbmcg IGFuZCBpbnRlcm9wZXJhYmlsaXR5IHNvIEknbSBpbiBhZ3JlZW1lbnQgd2l0aA0KPj4+Pj4+IHRo aXMgY2hhbmdlLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSG93ZXZlciwgaXQgc2VlbXMgd2UgYXJl IG5vdyBpbmNvbnNpc3RlbnQgYmV0d2VlbiBob3cgd2UNCj4+Pj4+PiByZXByZXNlbnQNCj4+Pj4+ Pj4+PiBiYW5kd2lkdGggaW4gcm91dGluZyBhbmQgc2lnbmFsaW5nIGZvciBPRFVmbGV4KEdGUCku ICBSb3V0aW5nIA0KPj4+Pj4+Pj4+IGFkdmVydGlzZXMgIHRoZSBiYW5kd2lkdGggdXNpbmcgYSBm bG9hdGluZyBwb2ludCANCj5yZXByZXNlbnRhdGlvbiANCj4+Pj4+Pj4+PiBvZiBiYW5kd2lkdGgs IHdoaWxlICBzaWduYWxpbmcgaXMgdXNpbmcgdGhlIG51bWJlciBvZg0KPj4+IHRyaWJ1dGFyeSBz bG90cy4NCj4+Pj4+Pj4+PiBJdCBzZWVtcyB0aGUgc2FtZSAgYmVuZWZpdHMgd291bGQgYmUgb2J0 YWluZWQgYnkNCj4+Pj4+PiBhZHZlcnRpc2luZyB0aGUgbWF4DQo+Pj4+Pj4+Pj4gTFNQIGJhbmR3 aWR0aCBhbmQgIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGZvciBPRFVmbGV4KEdGUCkgaW4NCj4+Pj4+ PiB0ZXJtcyBvZg0KPj4+Pj4+Pj4+IHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5ICBzbG90cy4NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEZyZWQNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+IEZyb206IGNj YW1wLWJvdW5jZXNAaWV0Zi5vcmcgDQo+W21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBP biANCj4+Pj4+Pj4+PiBCZWhhbGYgT2YgIExvdSBCZXJnZXINCj4+Pj4+Pj4+PiBTZW50OiBXZWRu ZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgOTowOCBBTQ0KPj4+Pj4+Pj4+IFRvOiBGYXRhaSBaaGFu Zw0KPj4+Pj4+Pj4+IENjOiBDQ0FNUDsNCj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25h bGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1Q XSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24NCj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdt cGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEZhdGFpLA0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4gT24gMS8yMy8yMDEzIDY6NDkgQU0sIEZhdGFpIFpoYW5nIHdyb3Rl Og0KPj4+Pj4+Pj4+PiBIaSBMb3UsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEZvciBPRFVmbGV4 KENCUiksIHRoZSBmb3JtdWxhIGlzIGZyb20gW0cuNzA5LTIwMTJdIGFuZCBpdA0KPj4+Pj4+IGhh cyBiZWVuDQo+Pj4+Pj4+Pj4+IGRpc2N1c3NlZCBiZWZvcmUsIHNvIHBsZWFzZSB0cnVzdCB0aGF0 IHRoZXJlIGlzIG5vDQo+Pj4+Pj4gb3Bwb3J0dW5pdHkgZm9yDQo+Pj4+Pj4+Pj4+IG1pc2ludGVy cHJldGF0aW9uLiAoTm90ZSB0aGF0IHRoZXJlIGFyZSB0d28gY2FzZXMsIG9uZSBpcw0KPj4+Pj4+ Pj4+PiBPRFVmbGV4KENCUikgYW5kIGFub3RoZXIgb25lIGlzIE9EVWZsZXgoR0ZQKSkuDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEluIGFkZHRpb24sIE9EVWZsZXggY2Fubm90IGJlIGNvbmNhdGVu YXRlZCBieSBbRy43MDktMjAxMl0uDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaGFua3MgZm9yIGNv bmZpcm1pbmcgbXkgdW5kZXJzdGFuZGluZy4gIFRoaXMgcmFpc2VzIHRoZQ0KPj4+Pj4+IHF1ZXN0 aW9uIG9mDQo+Pj4+Pj4+Pj4gaWYgdGhlIG5ldyB0cmFmZmljIHNob3VsZCBqdXN0IGFwcGx5IHRv IE9EVUZsZXg/ICBDb3JyZWN0DQo+Pj4+Pj4gbWUgaWYgSSdtDQo+Pj4+Pj4+Pj4gd3JvbmcsIGJ1 dCBJIGJlbGlldmUgdGhlIFtSRkM0MzI4XSBpcyBzdWZmaWNpZW50IGluIGFsbA0KPj4+Pj4+IG90 aGVyIGNhc2VzLiAgDQo+Pj4+Pj4+Pj4gVGhpcyBtYXkgYWxzbyBtYWtlIGl0IGVhc2llciBmb3Ig ZWFybHkgaW1wbGVtZW50YXRpb25zIG9mDQo+Pj4+Pj4gdGhlIGRyYWZ0DQo+Pj4+Pj4+Pj4gYXMg dGhlbiB0aGV5IGNhbiBsaW1pdCBjb2RlIGNoYW5nZXMgZnJvbSB0aGUgKC0wMykgcmV2IHRvDQo+ Pj4+Pj4gb25seSBPRFVmbGV4IExTUHMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBKdXN0IHRvIGJl IGNsZWFyLCBJJ20gcmVhbGx5IGp1c3QgKmFza2luZyogYWJvdXQgdGhpcy4gIA0KPj4+IEFzIEkg c2FpZA0KPj4+Pj4+Pj4+IGJlZm9yZSwgSSdtIG9wZW4gb24gc3BlY2lmaWNzLi4uDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBBbnkgdGhvdWdodHMvY29tbWVudHM/IEF1dGhvcnM/ICBJbXBsZW1lbnRv cnM/DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4gTG91DQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBJIHdpbGwgaXNzdWUgYSBuZXcgdmVyc2lvbiB0b21v cnJvdyB0byBjYXB0dXJlIGFsbA0KPj4+IHlvdXIgY29tbWVudHMuDQo+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBG YXRhaQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBs YWJuLm5ldF0NCj4+Pj4+Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDEzIDI6 MTEgQU0NCj4+Pj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4+Pj4+IENjOiBDQ0FNUDsN Cj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xz LmlldGYub3JnDQo+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBj b21tZW50cyBvbg0KPj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1n NzA5djMtMDQNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gRmF0YWksDQo+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+IE9uIDEvMjAvMjAxMyA5OjQzIFBNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+Pj4+ Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBZb3Ugc2FpZDoNCj4+Pj4+Pj4+ Pj4+PiBidXQgeW91J3JlIHNheXMgZW5jb2RlZCBhcyAoTipOb21pbmFsIFJhdGUpIHJpZ2h0PyAN Cj5XYXQncyB0aGUgDQo+Pj4+Pj4+Pj4+Pj4gdmFsdWUgb2YgIHRoaXMgdnMganVzdCBjYXJyeWlu ZyBOPw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFtGYXRhaV0gVGhlIG9yaWdpbmFsIHdheSAo aW4gdmVyc2lvbiAwNCYwNSkgaXMgcHV0dGluZw0KPj4+Pj4+IChOKiBOb21pbmFsDQo+Pj4+Pj4+ Pj4+PiBSYXRlKSBpbiAiQml0X1JhdGUiIGZpZWxkIGZvciBPRFVmbGV4KEdGUCksIHRoZSANCj52 YWx1ZSBpcyB0aGF0IA0KPj4+Pj4+Pj4+Pj4gd2UgY2FuIGdlbmVyYWxpemUgdG8ganVzdCB1c2Ug b25lIHNpbmdsZSAiQml0X1JhdGUiIA0KPmZpZWxkIHRvIA0KPj4+Pj4+Pj4+Pj4gY2FycnkgSUVF RSBmbG9hdCBudW1iZXIgZm9yIGJvdGggY2FzZXMsIGl0IHNlZW1zIHRoYXQgeW91DQo+Pj4+Pj4g ZG9uJ3QgYWdyZWUgb24NCj4+Pj4+Pj4+Pj4+IHRoaXMgdmFsdWUsIDotKQ0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+PiBJJ3ZlIHNlZW4gZGlmZmVyZW5jZXMgaW4gY2FsY3VsYXRlZCBmbG9hdGluZyBw b2ludCANCj52YWx1ZXMgZnJvbSANCj4+Pj4+Pj4+Pj4gZGlmZmVyZW50ICBpbXBsZW1lbnRhdGlv bnMsIHNvIEkganVzdCB3YW50IHRvIGVuc3VyZSB0aGF0DQo+Pj4+Pj4gc3VjaCBjYXNlcw0KPj4+ Pj4+Pj4+PiBhcmUgYXZvaWRlZC4NCj4+Pj4+Pj4+Pj4gSSdtIG9wZW4gdG8gc3BlY2lmaWMgc29s dXRpb25zIGFuZCBjZXJ0YWlubHkgd2lsbA0KPj4+IGRlZmZlciBvbiB0aGUNCj4+Pj4+Pj4+Pj4g c3BlY2lmaWNzIGFzc3VtaW5nIHRoZXJlIGlzIG5vIG9wcG9ydHVuaXR5IGZvciANCj4+Pj4+Pj4+ Pj4gbWlzaW50ZXJwcmV0YXRpb24vaW50ZXJvcCAgaXNzdWVzLiBJIGRvbid0IHRoaW5rIHRoZQ0K Pj4+Pj4+IG9yaWdpbmFsIHBhc3NlZA0KPj4+Pj4+Pj4+PiB0aGlzIHRocmVzaG9sZCwgaS5lLiw6 DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICAgICAgICAgIE4gPSBDZWlsaW5nIG9mDQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+ICAgIE9EVWZsZXgoQ0JSKSBub21pbmFsIGJpdCByYXRlICogKDEgKyBP RFVmbGV4KENCUikgYml0IHJhdGUNCj4+Pj4+Pj4+Pj4gdG9sZXJhbmNlKQ0KPj4+Pj4+Pj4+PiAg ICANCj4+Pj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+PiAtLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4+ICAgICAgICBP RFRVay50cyBub21pbmFsIGJpdCByYXRlICogKDEgLSBITyBPUFVrIGJpdCByYXRlDQo+Pj4+Pj4g dG9sZXJhbmNlKQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gLiBUaGVyZWZvcmUsIEkgKHdhcykg YW0gc2F5aW5nIHRoYXQgSSBhbSBnb2luZyB0byANCj5hY2NlcHQgeW91ciANCj4+Pj4+Pj4+Pj4+ IHN1Z2dlc3Rpb24gdG8gY2FycnkgTiBmb3IgT0RVZmxleChHRlApLiBXZSBhcmUNCj4+Pj4+PiBk aXNjdXNzaW5nIHdoZXJlIHRvDQo+Pj4+Pj4+Pj4+PiBwdXQgTiBmb3IgT0RVZmxleChHRlApLg0K Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFlvdSBzYWlkOg0KPj4+Pj4+Pj4+ Pj4+IGJpdHMgaW4gdGhlIGNvbnRyb2wgcGxhbmUgYXJlIGdlbmVyYWxseSBjaGVhcCwgSU1PIGl0 J3MNCj4+Pj4+PiBiZXR0ZXIgdG8NCj4+Pj4+Pj4+Pj4+PiBoYXZlIHNpbXBsZXIgZW5jb2Rpbmcg dGhhbiB0byBvcHRpbWl6ZSBldmVyeSBiaXQgKG9yDQo+Pj4gOCBpbiB0aGlzDQo+Pj4+Pj4+Pj4+ Pj4gY2FzZSkuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gW0ZhdGFpXSBPSywgSSB3aWxsIGFk ZCBhIG5ldyBmaWVsZCAodG8gb2NjdXB5IHRoZSByZXNlcnZlZA0KPj4+Pj4+Pj4+Pj4gYml0cykg dG8gY2FycnkgTi4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gQXMgeW91IHNlZSBmaXQuDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEp1c3QgdG8gY2xhcmlmeSBteSB1bmRlcnN0YW5kaW5nLCBPRFVm bGV4IGFuZCBWaXJ0dWFsDQo+Pj4+Pj4gY29uY2F0ZW5hdGlvbg0KPj4+Pj4+Pj4+PiBjYW4gIG5l dmVyIGJlIGNvbWJpbmVkIGZvciB0aGUgc2FtZSBzaWduYWwgdHlwZS9sZXZlbCwgcmlnaHQ/DQo+ Pj4+Pj4+Pj4+IChBbHRob3VnaCBhbiAgT0RVZmxleCBjbGllbnQgc2lnbmFsIGNvdWxkIGJlIGNh cnJpZWQgb3Zlcg0KPj4+Pj4+IGEgdmlydHVhbA0KPj4+Pj4+Pj4+PiBjb25jYXRlbmF0ZWQgIE9E VWspLiAgSXMgdGhpcyBjb3JyZWN0IG9yIGRpZCBJIG1pc3MNCj4+PiBzb21ldGhpbmcgaW4NCj4+ Pj4+Pj4+Pj4gRzcwOT8NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+ PiBMb3UNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEZhdGFp DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4+Pj4+Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPj4+ Pj4+Pj4+Pj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDE4LCAyMDEzIDE6NDIgQU0NCj4+Pj4+Pj4+ Pj4+IFRvOiBGYXRhaSBaaGFuZw0KPj4+Pj4+Pj4+Pj4gQ2M6IENDQU1QOw0KPj4+Pj4+Pj4+Pj4g ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+ Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24N Cj4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0K Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gT24gMS8x NS8yMDEzIDEwOjE2IFBNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+Pj4+Pj4+PiBIaSBMb3Us DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBUbyBhdm9pZCBtaXN1bmRlcnN0YW5kaW5nLCBJ IHdvdWxkIGxpa2UgdG8gY2xhcmlmeQ0KPj4+IG1vcmUgb24gdGhlDQo+Pj4+Pj4+Pj4+Pj4gZm9s bG93aW5nIHBvaW50Lg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4gSXQgaXMgYmV0dGVyIHRvIGhhdmUgY29uc2lzdGVudCBmb3JtYXQgYW5kIHRoZSBzYW1lIA0K Pj4+Pj4+Pj4+Pj4+Pj4+PiBtZWFuaW5nIG9mIG9uZQ0KPj4+Pj4+Pj4+Pj4gZmllbGQgZm9yIGJv dGggT0RVZmxleChDQlIpIGFuZCBHRlAuIFRoaXMgaXMgd2h5IHdlIGhhdmUgDQo+Pj4+Pj4+Pj4+ PiBzZWN0aW9uDQo+Pj4+Pj4+Pj4+PiA1LjENCj4+Pj4+Pj4+Pj4+ICY1LjIgdG8gZGVzY3JpYmUg dGhlIGNvbXBsZXggc3R1ZmYuDQo+Pj4+Pj4+Pj4+Pj4+Pj4gSSBhY3R1YWxseSB3YXNuJ3Qgc3Vn Z2VzdGluZyB0aGF0IE4gYmUgY2FycmllZCBpbg0KPj4+Pj4+IHRoZSBiaXQgcmF0ZQ0KPj4+Pj4+ Pj4+Pj4+Pj4+IGZpZWxkLg0KPj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBiaXQgcmF0ZSBmaWVsZCBjYW4g ZWl0aGVyIGJlIHNldCBhcyBkZXNjcmliZWQgb3IgdG8gDQo+Pj4+Pj4+Pj4+Pj4+Pj4gemVybyAo aS5lLiwgIGlnbm9yZWQpLiAgQXQgdGhlIHRpbWUsIEkgd2FzIA0KPnRoaW5raW5nIGFib3V0DQo+ Pj4+Pj4gY2FycnlpbmcgTg0KPj4+Pj4+Pj4+Pj4+Pj4+IGluIHRoZSAgcmVzZXJ2ZWQgIGZpZWxk LiBCdXQgcGVyaGFwcyB0aGUgcmlnaHQgcGxhY2UNCj4+Pj4+PiBpcyBNVCwgaWYNCj4+Pj4+Pj4+ Pj4+Pj4+PiBteSB1bmRlcnN0YW5kaW5nIGlzICByaWdodCAgKHdvdWxkIGFsd2F5cyBiZSAxDQo+ Pj4+Pj4gb3RoZXJ3aXNlKS4gSSdtDQo+Pj4+Pj4+Pj4+Pj4+Pj4gb3BlbiB0byBlaXRoZXIuLi4N Cj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gW0ZhdGFpXSBXaHkgbm90IGp1c3QgdXNl ICJiaXQgcmF0ZSJmaWVsZCB0byBjYXJyeQ0KPj4+Pj4+ICJOImJlY2F1c2UgIk4iDQo+Pj4+Pj4+ Pj4+Pj4+PiBpbXBsaWVzIGJpdCByYXRlPyAgSSBhbSBPSyBpZiB5b3UgbGlrZSB0byB1c2UgYSBu ZXcNCj4+Pj4+PiBmaWxlZCAobGlrZQ0KPj4+Pj4+Pj4+Pj4+Pj4gIlRTDQo+Pj4+Pj4+Pj4+Pj4+ PiBOdW1iZXIiKSB0byBvY2N1cHkgdGhlIHJlc2VydmVkIGZpZWxkIGV2ZW4gdGhvdWdoDQo+Pj4+ Pj4gdGhhdCBJIHByZWZlcg0KPj4+Pj4+Pj4+Pj4+Pj4gdGhlICBvcmlnaW5hbCBhcHByb2FjaCAo aWUuLCB1c2UgImJpdCByYXRlImZpZWxkDQo+Pj4gdG8gY2FycnkgIk4iKS4NCj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4gQXJlIHlvdSBwcm9wb3NpbmcgZHJvcHBpbmcgY2FycnlpbmcgYml0 IHJhdGVzDQo+Pj4+Pj4gcmVwcmVzZW50ZWQgYXMgYW4NCj4+Pj4+Pj4+Pj4+Pj4gSUVFRSAgZmxv YXRpbmcgcG9pbnQgYW5kIGp1c3QgY2FycnlpbmcgTiBmb3IgT0RVZmxleD8NCj4+Pj4+PiBUaGlz IHNlZW1zDQo+Pj4+Pj4+Pj4+Pj4+IHdvcmthYmxlICB0byAgbWUsIGJ1dCB3ZSBzaG91bGQgZW5z dXJlIHRoYXQgdGhlcmUgYXJlIG5vIA0KPj4+Pj4+Pj4+Pj4+PiBzaWduaWZpY2FudCBvYmplY3Rp b25zLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gW0ZhdGFpXSBUaGVyZSBhcmUgdHdvIHVz YWdlcyBmb3IgIiBCaXRfUmF0ZSAiIGZpZWxkIGFzDQo+Pj4+Pj4gZGVzY3JpYmVkDQo+Pj4+Pj4+ Pj4+Pj4gaW4gdGhlIGxpbmVzIDI4Ny0zMTAuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAo MSkgICAgRm9yIE9EVWZsZXgoQ0JSKSwgdGhlIEJpdF9SYXRlIGZpZWxkIGluZGljYXRlcw0KPj4+ Pj4+IHRoZSBub21pbmFsDQo+Pj4+Pj4+Pj4+Pj4gYml0DQo+Pj4+Pj4+Pj4+Pj4gcmF0ZSBvZiBP RFVmbGV4KENCUikgZXhwcmVzc2VkIGluIGJ5dGVzIHBlciBzZWNvbmQsDQo+Pj4+Pj4gZW5jb2Rl ZCBhcyBhDQo+Pj4+Pj4+Pj4+Pj4gMzItYml0ICBJRUVFIHNpbmdsZSBwcmVjaXNpb24gZmxvYXRp bmctcG9pbnQgbnVtYmVyLiANCj4+PiBGb3IgdGhpcw0KPj4+Pj4+Pj4+Pj4+IGNhc2UsIHdlIE1V U1QgIHVzZSAgMzItYml0IElFRUUgZmxvYXRpbmcgcG9pbnQgaW5zdGVhZCBvZiANCj4+Pj4+Pj4+ Pj4+PiAiTiIoUGxlYXNlIHNlZSBtb3JlIGluIHNlY3Rpb24gIDUuMSkuDQo+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4gSSBndWVzcyB5b3UgcmVhbGx5IHN0aWxsIG5lZWQgKHRvIGJlIGJhc2VkIG9u KSB0aGUgY2xpZW50IA0KPj4+Pj4+Pj4+Pj4gc2lnbmFsIHJhdGUgYXQgdGhlIGVkZ2VzLg0KPj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICgyKSAgICBGb3IgT0RVZmxleChH RlApLCB3ZSBjYW4gY2hhbmdlIHRoZSB0ZXh0ICh0aGUNCj4+Pj4+PiBsaW5lcyBmcm9tIDMwNQ0K Pj4+Pj4+Pj4+Pj4+IHRvDQo+Pj4+Pj4+Pj4+Pj4gMzEwKSBiYXNlZCBvbiB5b3VyIHN1Z2dlc3Rp b24sIGllLiwgdGhlIEJpdF9SYXRlIGZpZWxkDQo+Pj4+Pj4gaXMgdXNlZCB0bw0KPj4+Pj4+Pj4+ Pj4+IGNhcnJ5ICAiTiJ0byBpbmRpY2F0ZSB0aGUgbm9taW5hbCBiaXQgcmF0ZSBvZiB0aGUNCj4+ PiBPRFVmbGV4KEdGUCkuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gYnV0IHlvdSdyZSBzYXlz IGVuY29kZWQgYXMgKE4qTm9taW5hbCBSYXRlKSByaWdodD8gIA0KPldhdCdzIHRoZSANCj4+Pj4+ Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gVGhlcmVmb3JlLCBJIGFtIHBy b3Bvc2luZyB1c2luZyBvbmUgc2luZ2xlIGZpbGVkDQo+Pj4gKCJCaXRfUmF0ZSAiKQ0KPj4+Pj4+ Pj4+Pj4+IGZvciB0aGVzZSB0d28gY2FzZXMsIGluIHRoaXMgd2F5LCB3ZSBjYW4gbGVhdmUgdGhl IA0KPiJSZXNlcnZlZCINCj4+Pj4+Pj4+Pj4+PiBiaXRzIGZvciBmdXR1cmUuDQo+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4gYml0cyBpbiB0aGUgY29udHJvbCBwbGFuZSBhcmUgZ2VuZXJhbGx5IGNo ZWFwLCBJTU8gaXQncw0KPj4+Pj4+IGJldHRlciB0bw0KPj4+Pj4+Pj4+Pj4gaGF2ZSAgc2ltcGxl ciBlbmNvZGluZyB0aGFuIHRvIG9wdGltaXplIGV2ZXJ5IGJpdCAob3INCj4+PiA4IGluIHRoaXMN Cj4+Pj4+Pj4+Pj4+IGNhc2UpLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IExvdQ0KPj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEhvcGUgd2UgYXJlIG5vdyBhdCB0aGUg c2FtZSBwYWdlLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBCZXN0 IFJlZ2FyZHMNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4gQ0NBTVAgbWFpbGluZyBs aXN0DQo+Pj4+Pj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+PiBDQ0FNUCBtYWlsaW5nIGxp c3QNCj4+Pj4+Pj4+PiBDQ0FNUEBpZXRmLm9yZw0KPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+DQo+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IENDQU1QIG1haWxp bmcgbGlzdA0KPj4+PiBDQ0FNUEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+IENDQU1Q QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cA0KPj4+DQo+PiANCj4= From zhangfatai@huawei.com Wed Jan 30 00:59:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25C721F88B5 for ; Wed, 30 Jan 2013 00:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 oGGA1oRLUMzP for ; Wed, 30 Jan 2013 00:59:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 08C5021F88CB for ; Wed, 30 Jan 2013 00:59:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APF97351; Wed, 30 Jan 2013 08:59:17 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 30 Jan 2013 08:58:40 +0000 Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 30 Jan 2013 08:59:13 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.01.0323.007; Wed, 30 Jan 2013 16:58:07 +0800 From: Fatai Zhang To: Daniele Ceccarelli , Lou Berger Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZXCuS8hTs+eckmWtA0MM2hSFphf/XWAgAAfDYCAAAYXgIAA5eIAgACK3mA= Date: Wed, 30 Jan 2013 08:58:05 +0000 Message-ID: References: <5106DED0.3090008@labn.net> <4A1562797D64E44993C5CBF38CF1BE48074CE1@ESESSMB301.ericsson.se> <51081AAF.8030601@labn.net> <4A1562797D64E44993C5CBF38CF1BE4807506B@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4807506B@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 08:59:25 -0000 SGkgRGFuaWVsZSBhbmQgTG91LA0KDQpUbyBhdm9pZCB3b3JrIGJhY2sgYW5kIGZvcnRoLCBJIHdv dWxkIHBvaW50IG91dCB0aGF0IHdlIGNhbiBzdGlsbCBnZXQgdGhlIGNvaW5jaWRlbmNlIGJldHdl ZW4gc2lnbmFsaW5nIGFuZCByb3V0aW5nIGlmIHdlIGFkb3B0IG9wdGlvbiAzIGFuZCBjaGFuZ2Ug cm91dGluZyBkcmFmdC4NCg0KDQoNCg0KDQpCZXN0IFJlZ2FyZHMNCg0KRmF0YWkNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWxlIENlY2NhcmVs bGkNClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAzMCwgMjAxMyA0OjM2IFBNDQpUbzogTG91IEJl cmdlcg0KQ2M6IENDQU1QDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBQb2xsIG9uIE9EVUZsZXgtcmVs YXRlZCBlbmNvZGluZyAod2FzOiBXRyBMYXN0IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KDQpMb3UsIA0KDQppdCB3YXMgcmVhbGx5 IGp1c3QgYSBqb2tlLCBubyBoaWRkZW4gbWVhbmluZ3MuIA0KSWYgd2UgZmluZCBhIHJlYXNvbmFi bGUgc29sdXRpb24gZm9yIHNpZ25hbGluZyB0aGF0IGltcGxpZXMgbW9kaWZpY2F0aW9ucyB0byB0 aGUgcm91dGluZyB3ZSB3aWxsIG1vZGlmeSB0aGUgcm91dGluZyB0b28gKGhlcmUgSSBhZ3JlZSB3 aXRoIEZyZWQgdGhhdCBhbGlnbm1lbnQgYmV0d2VlbiBzaWduYWxpbmcgYW5kIHJvdXRpbmcgaXMg YSBTSE9VTEQsIGlmIG5vdCBhIE1VU1QpLg0KDQpJbmRlcG5kZW50bHkgZnJvbSBjaGFuZ2VzIHRv IHRoZSByb3V0aW5nIGkgc3RpbGwgYmVsaWV2ZSB0aGF0IG9wdGlvbiAyIGlzIHRoZSBtb3N0IHJl YXNvbmFibGUuIFRoZSBmYWN0IHRoYXQgaXQgaXMgb25lIG9mIHRoZSBvcHRpb25zIHRoYXQgZG9l cyBub3QgaW1wbHkgY2hhbmdlcyB0byB0aGUgcm91dGluZyBpcyBqdXN0IGEgY29pbmNpZGVuY2Uu DQoNClRoYW5rcywNCkRhbmllbGUNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJv bTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0KPlNlbnQ6IG1hcnRlZMOs IDI5IGdlbm5haW8gMjAxMyAxOS41NA0KPlRvOiBEYW5pZWxlIENlY2NhcmVsbGkNCj5DYzogQ0NB TVANCj5TdWJqZWN0OiBSZTogW0NDQU1QXSBQb2xsIG9uIE9EVUZsZXgtcmVsYXRlZCBlbmNvZGlu ZyAod2FzOiBXRyANCj5MYXN0IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KPg0KPkRhbmllbGUsDQo+CUpva2luZyBhc2lkZSwgSSB0 aGluayBpdCBtYXkgYWRkIHZhbHVlIHRvIHRoZSANCj5kaXNjdXNzaW9uIHRvIGhpZ2hsaWdodCB5 b3VyIHJhdGlvbmFsIGZvciBub3Qgd2FudGluZyB0byANCj5jaGFuZ2Ugcm91dGluZy4gIChZb3Ug YXJlIGFmdGVyIGFsbCB0aGUgZWRpdG9yIG9mIHRoZSByb3V0aW5nIGRyYWZ0LikNCj4NCj5JcyBp dDoNCj4tIEp1c3QgYXZvaWRpbmcgd29yayBmb3IgdGhlIGVkaXRvciAoaS5lLiwgeW91ciBqb2tl Li4uKT8NCj4tIE1pbmltaXppbmcgYSBjaGFuZ2UgYXQgdGhpcyBsYXRlIGRhdGU/DQo+LSBNaW5p bWl6aW5nIGltcGFjdCBvbiBhbiBlYXJseSBpbXBsZW1lbnRhdGlvbj8NCj4tIFNvbWV0aGluZyBj b21wbGV0ZWx5IGRpZmZlcmVudD8NCj4NCj5JZiB5b3UgZG9uJ3QgbWluZCBzaGFyaW5nLi4uDQo+ DQo+VGhhbmtzLA0KPkxvdQ0KPg0KPk9uIDEvMjkvMjAxMyAxOjMxIFBNLCBEYW5pZWxlIENlY2Nh cmVsbGkgd3JvdGU6DQo+PiBPcHRpb24gMiBmb3IgbWUgdG9vLg0KPj4gDQo+PiBNYWluIHJlYXNv bj8gSSBkb24ndCBoYXZlIHRvIGNoYW5nZSB0aGUgcm91dGluZyBJRCEgOi0pIA0KPi4uLm9idmlv dXNseSBqb2tpbmcuDQo+PiANCj4+IE90aGVyIHJlYXNvbnM/IEFncmVlIHdpdGggRmF0YWkgYW5k IFphZmFyLiBBbmQgcHJlZmVyIDIpIHRvIA0KPjEpIGJlY2F1c2UgZGVmaW5lcyBhIG5ldyBDLXR5 cGUuDQo+PiANCj4+IEJSDQo+PiBEYW5pZWxlDQo+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1i b3VuY2VzQGlldGYub3JnXSBPbiANCj4+PiBCZWhhbGYgT2YgWmFmYXIgQWxpICh6YWxpKQ0KPj4+ IFNlbnQ6IG1hcnRlZMOsIDI5IGdlbm5haW8gMjAxMyAxNy40MQ0KPj4+IFRvOiBMb3UgQmVyZ2Vy OyBDQ0FNUA0KPj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFBvbGwgb24gT0RVRmxleC1yZWxhdGVk IGVuY29kaW5nICh3YXM6IFdHIExhc3QgDQo+Pj4gQ2FsbCBjb21tZW50cyBvbiBkcmFmdC1pZXRm LWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQpDQo+Pj4NCj4+PiBIaSBMb3UsIEMtY2Ft cGVyczogDQo+Pj4NCj4+PiBJIHdvdWxkIHBpY2sgT3B0aW9uIDI7IGl0J3MgY2xlYW5lciBhbmQg IGFkZHJlc3NlcyB0aGUgDQo+aXNzdWUgcmVsYXRlZCANCj4+PiB0byBvdmVybG9hZGluZyB0aGUg c2FtZSBjLXR5cGUuDQo+Pj4NCj4+PiBUaGFua3MNCj4+Pg0KPj4+IFJlZ2FyZHPigKZaYWZhcg0K Pj4+DQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206ICJsYmVy Z2VyQGxhYm4ubmV0IiA8bGJlcmdlckBsYWJuLm5ldD4NCj4+PiBEYXRlOiBNb25kYXksIEphbnVh cnkgMjgsIDIwMTMgMzoyNSBQTQ0KPj4+IFRvOiAiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRm Lm9yZz4NCj4+PiBTdWJqZWN0OiBbQ0NBTVBdIFBvbGwgb24gT0RVRmxleC1yZWxhdGVkIGVuY29k aW5nICh3YXM6IFdHIA0KPkxhc3QgQ2FsbCANCj4+PiBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWNj YW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQpDQo+Pj4NCj4+Pj4gQWxsLA0KPj4+PiAJV2Ug d291bGQgbGlrZSB0byB0cnkgdG8gY2xvc2UgdGhlIGRpc2N1c3Npb24gb24gdGhlDQo+Pj4gRy43 MDkgZHJhZnRzIHNvDQo+Pj4+IHRoYXQgd2UgY2FuIG1vdmUgcmFwaWRseSB0b3dhcmRzIHB1Ymxp Y2F0aW9uIHJlcXVlc3QuICBUaGUgDQo+Pj4+IGRpc2N1c3Npb24gb2YgKG9uZSBvZiBteSkgTEMg Y29tbWVudHMgaGFzIHJlc3VsdGVkIGluIHNldmVyYWwgDQo+Pj4+IG9wdGlvbnMgZm9yIHRoZSBz aWduYWxpbmcgT0RVLXJlbGF0ZWQgdHJhZmZpYyBwYXJhbWV0ZXJzLCBhbmQgdGhlIA0KPj4+PiBw b2ludCBoYXMNCj4+PiBiZWVuIHJhaXNlZA0KPj4+PiB0aGF0IHJlYWxpZ25pbmcgcm91dGluZyB3 aXRoIHNpZ25hbGluZyBzaG91bGQgYmUgZGlzY3Vzc2VkLg0KPj4+Pg0KPj4+PiBQbGVhc2Uga2Vl cCBpbiBtaW5kIHRoYXQgdGhlIG9iamVjdGl2ZSBvZiBhbnkgUFMgaXMgDQo+Pj4+IGludGVyb3Bl cmFiaWxpdHksIGFuZCB0aGF0IHRoZXJlIG1heSBiZSBlYXJseSANCj5pbXBsZW1lbnRhdGlvbnMg dGhhdCBtYXRjaCBnNzA5djMtMDQuDQo+Pj4+DQo+Pj4+IFRoZSBiYXNpYyBxdWVzdGlvbiBpcyBv bmUgb2YgaWYgTiwgdGhlIG51bWJlciBvZiB0aW1lIHNsb3RzIG5lZWRlZCANCj4+Pj4gdG8gc3Vw cG9ydCBhIE9EVWZsZXgoR0ZQKSBzaWduYWwsIHNob3VsZCBiZSBjYXJyaWVkIGFzIGEgDQo+Y2Fs Y3VsYXRlZCBJRUVFDQo+Pj4+IGZsb2F0aW5nIHBvaW50IG51bWJlciBvciBkaXJlY3RseS4gICBP cHRpb25zIDEgYW5kIDIgYmVsb3cgDQo+cmVmbGVjdCB0aGUNCj4+Pj4gZm9ybWVyLCBvcHRpb25z IDMgYW5kIDQgbWF0Y2ggdGhlIGxhdHRlci4gIEl0IGlzIHdvcnRoIG5vdGluZw0KPj4+IHRoYXQg b25seQ0KPj4+PiBvcHRpb25zIDEgYW5kIDIgYXJlIHByb3Bvc2VkIGZvciBPRFVmbGV4KEdGUCks IGkuZS4sIE4gbXVzdCBiZSANCj4+Pj4gY2FsY3VsYXRlZCBmb3IgT0RVZmxleChDQlIpIHNpZ25h bCB0eXBlcyB3aXRoIGFsbCBvcHRpb25zLg0KPj4+Pg0KPj4+PiBQbGVhc2Ugc3RhdGUgeW91ciBz dXBwb3J0IGZvciBvbmUgdGhlIG9wdGlvbnMgYW5kLCBpZiB5b3UgDQo+d2lzaCwgdGhlIA0KPj4+ PiBqdXN0aWZpY2F0aW9uIGZvciB5b3VyIHBvc2l0aW9uOg0KPj4+Pg0KPj4+PiAxKSBGb2xsb3cg ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+ICAgaS5lLiwg cmVkZWZpbmUgW1JGQzQzMjhdIFRyYWZmaWMgUGFyYW1ldGVycyBjLXR5cGUgd2hlbiB1c2VkIHdp dGgNCj4+Pj4gICBPVE4tVERNIGxhYmVscy4gT0RVZmxleChHRlApIG51bWJlciBvZiB0cmlidXRh cnkgc2xvdHMgKE4pIGlzDQo+Pj4+ICAgZW5jb2RlZCBhczoNCj4+Pj4NCj4+Pj4gICAuLi4gdGhl IEJpdF9SYXRlIGZpZWxkIGZvciBPRFVmbGV4KEdGUCkgTVVTVA0KPj4+PiAgIGVxdWFsIHRvIG9u ZSBvZiB0aGUgODAgdmFsdWVzIGxpc3RlZCBiZWxvdzoNCj4+Pj4NCj4+Pj4gICAgICAgMSAqIE9E VTIudHM7IDIgKiBPRFUyLnRzOyAuLi47IDggKiBPRFUyLnRzOw0KPj4+PiAgICAgICA5ICogT0RV My50czsgMTAgKiBPRFUzLnRzLCAuLi47IDMyICogT0RVMy50czsNCj4+Pj4gICAgICAgMzMgKiBP RFU0LnRzOyAzNCAqIE9EVTQudHM7IC4uLjsgODAgKiBPRFU0LnRzLg0KPj4+Pg0KPj4+PiAyKSBG b2xsb3cgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA1DQo+Pj4+ICAg aS5lLiwgdXNlIGEgbmV3IEMtdHlwZSBmb3IgT1ROLVRETSBsYWJlbHMuICBFbmNvZGluZyBkZXRh aWxzDQo+Pj4+ICAgdW5jaGFuZ2VkIGZyb20gZzcwOXYzLTA0Lg0KPj4+PiAgIChUaGlzIG9wdGlv biBhZGRyZXNzZXMgdGhlIGlzc3VlIG9mIHRoZSBzYW1lIGMtdHlwZSBuZWVkaW5nIHRvDQo+Pj4+ ICAgIGJlIHBhcnNlZCBiYXNlZCBvbiBsYWJlbC9zd2l0Y2hpbmcgdHlwZS4pDQo+Pj4+DQo+Pj4+ IDMpIEZvbGxvdyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDYNCj4+ Pj4gICBpLmUuLCAgdXNlIGEgbmV3IEMtdHlwZSBmb3IgT1ROLVRETSBsYWJlbHMuIE4gaXMgZGly ZWN0bHkgY2FycmllZA0KPj4+PiAgIGZvciBPRFVmbGV4KEdGUCkgb25seS4NCj4+Pj4NCj4+Pj4g NCkgRGlzY3Vzc2VkLCBidXQgbm90IGluIGFueSBkcmFmdA0KPj4+PiAgIFVzZSBkcmFmdC1pZXRm LWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQgZW5jb2RpbmcgZm9yIGFsbA0KPj4+PiAg IGJ1dCBPRFVmbGV4KEdGUCksIGFuZCBkZWZpbmUgbmV3IE9EVWZsZXgoR0ZQKSBzcGVjaWZpYyBU cmFmZmljDQo+Pj4+ICAgUGFyYW1ldGVycyBiYXNlZCBvbiBnNzA5djMtMDYsIHByZXN1bWFibHkg d2l0aCB1bnVzZWQgZmllbGRzDQo+Pj4+ICAgcmVtb3ZlZC4NCj4+Pj4gICAoVGhpcyBhbHNvIGFk ZHJlc3NlcyB0aGUgaXNzdWUgb2YgdGhlIHNhbWUgYy10eXBlIG5lZWRpbmcgdG8gYmUNCj4+Pj4g ICAgcGFyc2VkIGJhc2VkIG9uIGxhYmVsIHR5cGUsIGJ1dCBtZWFucyB0aGVyZSBhcmUgZGlmZmVy ZW50IHR5cGVzDQo+Pj4+ICAgIGJhc2VkIG9uIHNpZ25hbCB0eXBlLikNCj4+Pj4NCj4+Pj4gT3B0 aW9uIDEgYW5kIDIgZG8gbm90IGltcGx5IGFueSBjaGFuZ2VzIHRvIHJvdXRpbmcsIHdoaWxlDQo+ Pj4gb3B0aW9ucyAzIGFuZA0KPj4+PiA0IG1heS4gIFJvdXRpbmcgaW1wbGljYXRpb25zIHdpbGwg YmUgZGlzY3Vzc2VkIGJhc2VkIG9uIHRoZQ0KPj4+IHJlc3VsdHMgb2YNCj4+Pj4gdGhpcyBwb2xs LCBhbmQgb25seSBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdG8gc3VwcG9ydCANCj5wb3NpdGlvbnMg MyBvciA0Lg0KPj4+Pg0KPj4+PiBXZSBob3BlIHRvIG1ha2UgYSBjb25zZW5zdXMgY2FsbCBieSB0 aGUgZW5kIG9mIHRoZSB3ZWVrLCBidXQgd2lsbCANCj4+Pj4gY29udGludWUgdGhlIGRpc2N1c3Np b24gYXMgbmVlZGVkLg0KPj4+Pg0KPj4+PiBNdWNoIHRoYW5rcywNCj4+Pj4gTG91IChhbmQgRGVi b3JhaCkNCj4+Pj4NCj4+Pj4gT24gMS8yOC8yMDEzIDU6MDggQU0sIERhbmllbGUgQ2VjY2FyZWxs aSB3cm90ZToNCj4+Pj4+ICBBbGwsDQo+Pj4+Pg0KPj4+Pj4gSSB0aGluayB0aGUgY2hhbmdlcyBw cm9wb3NlZCBhcmUgbWVhbmluZ2Z1bCBhbmQgd291bGQNCj4+PiBzdXBwb3J0IHRoZW0gaW4NCj4+ Pj4+IGFuIGluZGl2aWR1YWwgb3IgZWFybHkgV0cgZHJhZnQsIGJ1dCB0aGV5IGRvbid0IHNlZW0g dG8gcHJvdmlkZSANCj4+Pj4+IHNpZ25pZmljYXRpdmUgYWR2YW50YWdlcyB0byByaXNrIGludGVy d29ya2luZyBpc3N1ZXMgd2l0aCBlYXJseSANCj4+Pj4+IGltcGxlbWVudGF0aW9ucy4NCj4+Pj4+ IE1vcmVvdmVyIHRoZSBjaGFuZ2VzIGRvbid0IGFsbG93IHVzIGdldHRpbmcgdG90YWxseSByaWQg b2Ygb2YgdGhlIA0KPj4+Pj4gYml0X3JhdGUgZmllbGQgYXMgaXQgaXMgc3RpbGwgbmVlZGVkIGZv ciBPRFVmbGV4IChDQlIpLg0KPj4+Pj4NCj4+Pj4+IE15IDJjDQo+Pj4+PiBEYW5pZWxlDQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206 IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxpQGNpc2NvLmNvbV0NCj4+Pj4+PiBTZW50OiBs dW5lZMOsIDI4IGdlbm5haW8gMjAxMyA0LjQ3DQo+Pj4+Pj4gVG86IExvdSBCZXJnZXINCj4+Pj4+ PiBDYzogR3J1bWFuLCBGcmVkOyBGYXRhaSBaaGFuZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FN UDsgDQo+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xz LmlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIGNvbW1l bnRzIG9uDQo+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0 DQo+Pj4+Pj4NCj4+Pj4+PiBIaSBMb3UtDQo+Pj4+Pj4NCj4+Pj4+PiBQbGVhc2Ugc2VlIGluLWxp bmUuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3MNCj4+Pj4+Pg0KPj4+Pj4+IFJlZ2FyZHMuLi5aYWZh cg0KPj4+Pj4+DQo+Pj4+Pj4gT24gMS8yNy8xMyA5OjQ2IFBNLCAiTG91IEJlcmdlciIgPGxiZXJn ZXJAbGFibi5uZXQ+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IFphZmFyLA0KPj4+Pj4+PiAJSXMg eW91ciBjb21tZW50IHdpdGggcmVzcGVjdCB0byBqdXN0IHJvdXRpbmcgb3IgYm90aA0KPj4+Pj4+ IHNpZ25hbGluZyBhbmQNCj4+Pj4+Pj4gcm91dGluZz8NCj4+Pj4+Pg0KPj4+Pj4+IEJvdGgsIGlu Y2x1ZGluZyBjb25zaXN0ZW5jeSBiZXR3ZWVuIHNpZ25hbGluZyBhbmQgcm91dGluZw0KPj4+IGF0 dHJpYnV0ZXMuDQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQWxzbywgd2hlbiB5b3Ugc2F5ICJp bXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZHJhZnQgdmVyc2lvbnMiLA0KPj4+Pj4+IGRvIHRoZXNl DQo+Pj4+Pj4+IGltcGxlbWVudGF0aW9ucyBpbmNsdWRlIHN1cHBvcnQgZm9yIE9EVWZsZXg/ICAo V2hpY2ggaGFzIHJlYWxseSANCj4+Pj4+Pj4gYmVlbiB0aGUgZm9jdXMgb2YgdGhlIGRpc2N1c3Np b24uKQ0KPj4+Pj4+DQo+Pj4+Pj4gWWVzLCBJIHdhcyByZWZlcnJpbmcgdG8gT0RVRmxleC4gQXMg eW91IGtub3csIGZpeGVkIE9EVSBpcw0KPj4+IHNpZ25hbGVkDQo+Pj4+Pj4gdmlhIGxldmVsICgw IEJXKSBzbyBpdHMgbm90IGFuIGlzc3VlLg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJUVyBJ IHRvb2sgRnJlZCdzIGNvbW1lbnRzIGFzIHJlbGF0ZWQgdG8ganVzdCB0aGUgbmV3DQo+Pj4+Pj4g T1ROLXNwZWNpZmljIElTQ0QNCj4+Pj4+Pj4gZGVmaW5pdGlvbnMgKHNlY3Rpb24gNC4xLjIgb2Yg b3NwZi1nNzA5djMtMDUsIGluDQo+Pj4gcGFydGljdWxhcikuICBOb3RlDQo+Pj4+Pj4+IHRoYXQg c2VjdGlvbiA0LjEuMSBhbHJlYWR5IGNhcnJpZXMgTiAobnVtYmVyIG9mIE9EVXMpIG5vdA0KPj4+ Pj4+IElFRUUgZmxvYXRpbmcNCj4+Pj4+Pj4gcG9pbnQgcmVwcmVzZW50YXRpb25zIG9mIGF2YWls YWJsZSBiYW5kd2lkdGguDQo+Pj4+Pj4NCj4+Pj4+PiBXaGF0IEkgbWVhbnQgaXMgVW5yZXNlcnZl ZCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgeCBhbmQgTWF4IExTUCANCj4+Pj4+PiBCYW5kd2lkdGgg YXQgcHJpb3JpdHkgeC4NCj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBNdWNoIHRoYW5rcywNCj4+ Pj4+Pj4gTG91DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uIDEvMjcvMjAxMyA3OjQ2IFBNLCBaYWZhciBB bGkgKHphbGkpIHdyb3RlOg0KPj4+Pj4+Pj4gQWxsLQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoaXMg aW1wYWN0cyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZHJhZnQNCj4+PiB2ZXJz aW9ucyAoYW5kDQo+Pj4+Pj4+PiBoZW5jZSBpbnRlcm9wIHdpdGggdGhlc2UgaW1wbGVtZW50YXRp b25zIG1vdmluZyBmb3J3YXJkKS4NCj4+Pj4+PiBJTU8gdGhpcyBpcw0KPj4+Pj4+Pj4gYSBiaWdn ZXIgY2hhbmdlIGZvciB1cyB0byBhc3N1bWUgYXQgdGhlIGxhc3QgY2FsbCBzdGFnZS4NCj4+Pj4+ PiBGdXJ0aGVybW9yZQ0KPj4+Pj4+Pj4gd2UgaGF2ZSBiZWVuIHVzaW5nIElFRUUgZmxvYXRpbmcg cG9pbnQgZm9ybWF0IGZvciBVbnJlc2VydmVkIA0KPj4+Pj4+Pj4gQmFuZHdpZHRoLyBNYXggTFNQ IEJXIGluIElFRUUgZmxvYXRpbmcgcG9pbnQgZm9ybWF0IGZvciBvdGhlciANCj4+Pj4+Pj4+IHRl Y2hub2xvZ2llcy4gT3ZlcmFsbCwgSSB0aGluayB0aGlzIGNoYW5nZSBzdWZmZXJzIGZyb20gdGhl DQo+Pj4+Pj4gImxhdyBvZiBkaW1pbmlzaGluZyByZXR1cm5zIi4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBUaGFua3MNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBSZWdhcmRzIMWgIFphZmFyDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIDEvMjcvMTMgMTA6MjggQU0sICJHcnVtYW4sIEZyZWQiDQo+ Pj4+Pj4gPGZyZWQuZ3J1bWFuQHVzLmZ1aml0c3UuY29tPiB3cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4gSGkgTG91LCBGYXRhaSwgRGFuaWVsZSwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEkgdW5k ZXJzdGFuZCB0aGUgbGF0ZXN0IGNoYW5nZSB0byB0aGUgd2F5IGJhbmR3aWR0aCBpcw0KPj4+Pj4+ IHNpZ25hbGVkIGZvcg0KPj4+Pj4+Pj4+IE9EVWZsZXgoR0ZQKSwgaS5lLiwgc2lnbmFsaW5nIHRo ZSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3RzDQo+Pj4+Pj4gTiBpbnN0ZWFkDQo+Pj4+Pj4+Pj4g b2YgIHRoZSBiYW5kd2lkdGggcmF0ZSBpbiBicHMuICBJIGJlbGlldmUgdGhhdCB0aGlzIA0KPnNp bXBsaWZpZXMgDQo+Pj4+Pj4+Pj4gdGhlIHNpZ25hbGluZyAgYW5kIGludGVyb3BlcmFiaWxpdHkg c28gSSdtIGluIGFncmVlbWVudCB3aXRoDQo+Pj4+Pj4gdGhpcyBjaGFuZ2UuDQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+PiBIb3dldmVyLCBpdCBzZWVtcyB3ZSBhcmUgbm93IGluY29uc2lzdGVudCBiZXR3 ZWVuIGhvdyB3ZQ0KPj4+Pj4+IHJlcHJlc2VudA0KPj4+Pj4+Pj4+IGJhbmR3aWR0aCBpbiByb3V0 aW5nIGFuZCBzaWduYWxpbmcgZm9yIE9EVWZsZXgoR0ZQKS4gIFJvdXRpbmcgDQo+Pj4+Pj4+Pj4g YWR2ZXJ0aXNlcyAgdGhlIGJhbmR3aWR0aCB1c2luZyBhIGZsb2F0aW5nIHBvaW50IA0KPnJlcHJl c2VudGF0aW9uIA0KPj4+Pj4+Pj4+IG9mIGJhbmR3aWR0aCwgd2hpbGUgIHNpZ25hbGluZyBpcyB1 c2luZyB0aGUgbnVtYmVyIG9mDQo+Pj4gdHJpYnV0YXJ5IHNsb3RzLg0KPj4+Pj4+Pj4+IEl0IHNl ZW1zIHRoZSBzYW1lICBiZW5lZml0cyB3b3VsZCBiZSBvYnRhaW5lZCBieQ0KPj4+Pj4+IGFkdmVy dGlzaW5nIHRoZSBtYXgNCj4+Pj4+Pj4+PiBMU1AgYmFuZHdpZHRoIGFuZCAgdW5yZXNlcnZlZCBi YW5kd2lkdGggZm9yIE9EVWZsZXgoR0ZQKSBpbg0KPj4+Pj4+IHRlcm1zIG9mDQo+Pj4+Pj4+Pj4g dGhlIG51bWJlciBvZiB0cmlidXRhcnkgIHNsb3RzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gRnJl ZA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyAN Cj5bbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4+Pj4+Pj4+IEJlaGFsZiBP ZiAgTG91IEJlcmdlcg0KPj4+Pj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMywgMjAx MyA5OjA4IEFNDQo+Pj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4+Pj4gQ2M6IENDQU1Q Ow0KPj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRm Lm9yZw0KPj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50 cyBvbg0KPj4+Pj4+Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0w NA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gRmF0YWksDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBPbiAx LzIzLzIwMTMgNjo0OSBBTSwgRmF0YWkgWmhhbmcgd3JvdGU6DQo+Pj4+Pj4+Pj4+IEhpIExvdSwN Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gRm9yIE9EVWZsZXgoQ0JSKSwgdGhlIGZvcm11bGEgaXMg ZnJvbSBbRy43MDktMjAxMl0gYW5kIGl0DQo+Pj4+Pj4gaGFzIGJlZW4NCj4+Pj4+Pj4+Pj4gZGlz Y3Vzc2VkIGJlZm9yZSwgc28gcGxlYXNlIHRydXN0IHRoYXQgdGhlcmUgaXMgbm8NCj4+Pj4+PiBv cHBvcnR1bml0eSBmb3INCj4+Pj4+Pj4+Pj4gbWlzaW50ZXJwcmV0YXRpb24uIChOb3RlIHRoYXQg dGhlcmUgYXJlIHR3byBjYXNlcywgb25lIGlzDQo+Pj4+Pj4+Pj4+IE9EVWZsZXgoQ0JSKSBhbmQg YW5vdGhlciBvbmUgaXMgT0RVZmxleChHRlApKS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSW4g YWRkdGlvbiwgT0RVZmxleCBjYW5ub3QgYmUgY29uY2F0ZW5hdGVkIGJ5IFtHLjcwOS0yMDEyXS4N Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoYW5rcyBmb3IgY29uZmlybWluZyBteSB1bmRlcnN0YW5k aW5nLiAgVGhpcyByYWlzZXMgdGhlDQo+Pj4+Pj4gcXVlc3Rpb24gb2YNCj4+Pj4+Pj4+PiBpZiB0 aGUgbmV3IHRyYWZmaWMgc2hvdWxkIGp1c3QgYXBwbHkgdG8gT0RVRmxleD8gIENvcnJlY3QNCj4+ Pj4+PiBtZSBpZiBJJ20NCj4+Pj4+Pj4+PiB3cm9uZywgYnV0IEkgYmVsaWV2ZSB0aGUgW1JGQzQz MjhdIGlzIHN1ZmZpY2llbnQgaW4gYWxsDQo+Pj4+Pj4gb3RoZXIgY2FzZXMuICANCj4+Pj4+Pj4+ PiBUaGlzIG1heSBhbHNvIG1ha2UgaXQgZWFzaWVyIGZvciBlYXJseSBpbXBsZW1lbnRhdGlvbnMg b2YNCj4+Pj4+PiB0aGUgZHJhZnQNCj4+Pj4+Pj4+PiBhcyB0aGVuIHRoZXkgY2FuIGxpbWl0IGNv ZGUgY2hhbmdlcyBmcm9tIHRoZSAoLTAzKSByZXYgdG8NCj4+Pj4+PiBvbmx5IE9EVWZsZXggTFNQ cy4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEp1c3QgdG8gYmUgY2xlYXIsIEknbSByZWFsbHkganVz dCAqYXNraW5nKiBhYm91dCB0aGlzLiAgDQo+Pj4gQXMgSSBzYWlkDQo+Pj4+Pj4+Pj4gYmVmb3Jl LCBJJ20gb3BlbiBvbiBzcGVjaWZpY3MuLi4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEFueSB0aG91 Z2h0cy9jb21tZW50cz8gQXV0aG9ycz8gIEltcGxlbWVudG9ycz8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+PiBMb3UNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IEkgd2lsbCBpc3N1ZSBhIG5ldyB2ZXJzaW9uIHRvbW9ycm93IHRvIGNhcHR1cmUgYWxsDQo+ Pj4geW91ciBjb21tZW50cy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gQmVz dCBSZWdhcmRzDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4+ IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPj4+Pj4+Pj4+PiBT ZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgMjoxMSBBTQ0KPj4+Pj4+Pj4+PiBUbzog RmF0YWkgWmhhbmcNCj4+Pj4+Pj4+Pj4gQ2M6IENDQU1QOw0KPj4+Pj4+Pj4+PiBkcmFmdC1pZXRm LWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4g U3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+Pj4+Pj4+ IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+PiBGYXRhaSwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gT24gMS8yMC8yMDEzIDk6 NDMgUE0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4gSGkgTG91LA0KPj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+IFlvdSBzYWlkOg0KPj4+Pj4+Pj4+Pj4+IGJ1dCB5b3UncmUgc2F5cyBl bmNvZGVkIGFzIChOKk5vbWluYWwgUmF0ZSkgcmlnaHQ/IA0KPldhdCdzIHRoZSANCj4+Pj4+Pj4+ Pj4+PiB2YWx1ZSBvZiAgdGhpcyB2cyBqdXN0IGNhcnJ5aW5nIE4/DQo+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4gW0ZhdGFpXSBUaGUgb3JpZ2luYWwgd2F5IChpbiB2ZXJzaW9uIDA0JjA1KSBpcyBw dXR0aW5nDQo+Pj4+Pj4gKE4qIE5vbWluYWwNCj4+Pj4+Pj4+Pj4+IFJhdGUpIGluICJCaXRfUmF0 ZSIgZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSwgdGhlIA0KPnZhbHVlIGlzIHRoYXQgDQo+Pj4+Pj4+ Pj4+PiB3ZSBjYW4gZ2VuZXJhbGl6ZSB0byBqdXN0IHVzZSBvbmUgc2luZ2xlICJCaXRfUmF0ZSIg DQo+ZmllbGQgdG8gDQo+Pj4+Pj4+Pj4+PiBjYXJyeSBJRUVFIGZsb2F0IG51bWJlciBmb3IgYm90 aCBjYXNlcywgaXQgc2VlbXMgdGhhdCB5b3UNCj4+Pj4+PiBkb24ndCBhZ3JlZSBvbg0KPj4+Pj4+ Pj4+Pj4gdGhpcyB2YWx1ZSwgOi0pDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEkndmUgc2VlbiBk aWZmZXJlbmNlcyBpbiBjYWxjdWxhdGVkIGZsb2F0aW5nIHBvaW50IA0KPnZhbHVlcyBmcm9tIA0K Pj4+Pj4+Pj4+PiBkaWZmZXJlbnQgIGltcGxlbWVudGF0aW9ucywgc28gSSBqdXN0IHdhbnQgdG8g ZW5zdXJlIHRoYXQNCj4+Pj4+PiBzdWNoIGNhc2VzDQo+Pj4+Pj4+Pj4+IGFyZSBhdm9pZGVkLg0K Pj4+Pj4+Pj4+PiBJJ20gb3BlbiB0byBzcGVjaWZpYyBzb2x1dGlvbnMgYW5kIGNlcnRhaW5seSB3 aWxsDQo+Pj4gZGVmZmVyIG9uIHRoZQ0KPj4+Pj4+Pj4+PiBzcGVjaWZpY3MgYXNzdW1pbmcgdGhl cmUgaXMgbm8gb3Bwb3J0dW5pdHkgZm9yIA0KPj4+Pj4+Pj4+PiBtaXNpbnRlcnByZXRhdGlvbi9p bnRlcm9wICBpc3N1ZXMuIEkgZG9uJ3QgdGhpbmsgdGhlDQo+Pj4+Pj4gb3JpZ2luYWwgcGFzc2Vk DQo+Pj4+Pj4+Pj4+IHRoaXMgdGhyZXNob2xkLCBpLmUuLDoNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4gICAgICAgICAgTiA9IENlaWxpbmcgb2YNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gICAgT0RV ZmxleChDQlIpIG5vbWluYWwgYml0IHJhdGUgKiAoMSArIE9EVWZsZXgoQ0JSKSBiaXQgcmF0ZQ0K Pj4+Pj4+Pj4+PiB0b2xlcmFuY2UpDQo+Pj4+Pj4+Pj4+ICAgIA0KPj4+Pj4+Pj4+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+ Pj4+IC0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4gICAgICAgIE9EVFVrLnRzIG5vbWluYWwgYml0IHJh dGUgKiAoMSAtIEhPIE9QVWsgYml0IHJhdGUNCj4+Pj4+PiB0b2xlcmFuY2UpDQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+PiAuIFRoZXJlZm9yZSwgSSAod2FzKSBhbSBzYXlpbmcgdGhhdCBJIGFtIGdv aW5nIHRvIA0KPmFjY2VwdCB5b3VyIA0KPj4+Pj4+Pj4+Pj4gc3VnZ2VzdGlvbiB0byBjYXJyeSBO IGZvciBPRFVmbGV4KEdGUCkuIFdlIGFyZQ0KPj4+Pj4+IGRpc2N1c3Npbmcgd2hlcmUgdG8NCj4+ Pj4+Pj4+Pj4+IHB1dCBOIGZvciBPRFVmbGV4KEdGUCkuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4gWW91IHNhaWQ6DQo+Pj4+Pj4+Pj4+Pj4gYml0cyBpbiB0aGUgY29udHJv bCBwbGFuZSBhcmUgZ2VuZXJhbGx5IGNoZWFwLCBJTU8gaXQncw0KPj4+Pj4+IGJldHRlciB0bw0K Pj4+Pj4+Pj4+Pj4+IGhhdmUgc2ltcGxlciBlbmNvZGluZyB0aGFuIHRvIG9wdGltaXplIGV2ZXJ5 IGJpdCAob3INCj4+PiA4IGluIHRoaXMNCj4+Pj4+Pj4+Pj4+PiBjYXNlKS4NCj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+PiBbRmF0YWldIE9LLCBJIHdpbGwgYWRkIGEgbmV3IGZpZWxkICh0byBvY2N1 cHkgdGhlIHJlc2VydmVkDQo+Pj4+Pj4+Pj4+PiBiaXRzKSB0byBjYXJyeSBOLg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+PiBBcyB5b3Ugc2VlIGZpdC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSnVz dCB0byBjbGFyaWZ5IG15IHVuZGVyc3RhbmRpbmcsIE9EVWZsZXggYW5kIFZpcnR1YWwNCj4+Pj4+ PiBjb25jYXRlbmF0aW9uDQo+Pj4+Pj4+Pj4+IGNhbiAgbmV2ZXIgYmUgY29tYmluZWQgZm9yIHRo ZSBzYW1lIHNpZ25hbCB0eXBlL2xldmVsLCByaWdodD8NCj4+Pj4+Pj4+Pj4gKEFsdGhvdWdoIGFu ICBPRFVmbGV4IGNsaWVudCBzaWduYWwgY291bGQgYmUgY2FycmllZCBvdmVyDQo+Pj4+Pj4gYSB2 aXJ0dWFsDQo+Pj4+Pj4+Pj4+IGNvbmNhdGVuYXRlZCAgT0RVaykuICBJcyB0aGlzIGNvcnJlY3Qg b3IgZGlkIEkgbWlzcw0KPj4+IHNvbWV0aGluZyBpbg0KPj4+Pj4+Pj4+PiBHNzA5Pw0KPj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4+IExvdQ0KPj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gQmVzdCBSZWdh cmRzDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gRmF0YWkNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4gRnJvbTogTG91IEJl cmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+Pj4+Pj4+Pj4+PiBTZW50OiBGcmlkYXks IEphbnVhcnkgMTgsIDIwMTMgMTo0MiBBTQ0KPj4+Pj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+ Pj4+Pj4+Pj4+PiBDYzogQ0NBTVA7DQo+Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxz LXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJl OiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBPbiAxLzE1LzIwMTMgMTA6MTYgUE0sIEZhdGFp IFpoYW5nIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+IFRvIGF2b2lkIG1pc3VuZGVyc3RhbmRpbmcsIEkgd291bGQgbGlrZSB0byBjbGFyaWZ5 DQo+Pj4gbW9yZSBvbiB0aGUNCj4+Pj4+Pj4+Pj4+PiBmb2xsb3dpbmcgcG9pbnQuDQo+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+PiBJdCBpcyBiZXR0ZXIgdG8gaGF2 ZSBjb25zaXN0ZW50IGZvcm1hdCBhbmQgdGhlIHNhbWUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IG1lYW5p bmcgb2Ygb25lDQo+Pj4+Pj4+Pj4+PiBmaWVsZCBmb3IgYm90aCBPRFVmbGV4KENCUikgYW5kIEdG UC4gVGhpcyBpcyB3aHkgd2UgaGF2ZSANCj4+Pj4+Pj4+Pj4+IHNlY3Rpb24NCj4+Pj4+Pj4+Pj4+ IDUuMQ0KPj4+Pj4+Pj4+Pj4gJjUuMiB0byBkZXNjcmliZSB0aGUgY29tcGxleCBzdHVmZi4NCj4+ Pj4+Pj4+Pj4+Pj4+PiBJIGFjdHVhbGx5IHdhc24ndCBzdWdnZXN0aW5nIHRoYXQgTiBiZSBjYXJy aWVkIGluDQo+Pj4+Pj4gdGhlIGJpdCByYXRlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gZmllbGQuDQo+Pj4+ Pj4+Pj4+Pj4+Pj4gVGhlIGJpdCByYXRlIGZpZWxkIGNhbiBlaXRoZXIgYmUgc2V0IGFzIGRlc2Ny aWJlZCBvciB0byANCj4+Pj4+Pj4+Pj4+Pj4+PiB6ZXJvIChpLmUuLCAgaWdub3JlZCkuICBBdCB0 aGUgdGltZSwgSSB3YXMgDQo+dGhpbmtpbmcgYWJvdXQNCj4+Pj4+PiBjYXJyeWluZyBODQo+Pj4+ Pj4+Pj4+Pj4+Pj4gaW4gdGhlICByZXNlcnZlZCAgZmllbGQuIEJ1dCBwZXJoYXBzIHRoZSByaWdo dCBwbGFjZQ0KPj4+Pj4+IGlzIE1ULCBpZg0KPj4+Pj4+Pj4+Pj4+Pj4+IG15IHVuZGVyc3RhbmRp bmcgaXMgIHJpZ2h0ICAod291bGQgYWx3YXlzIGJlIDENCj4+Pj4+PiBvdGhlcndpc2UpLiBJJ20N Cj4+Pj4+Pj4+Pj4+Pj4+PiBvcGVuIHRvIGVpdGhlci4uLg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+PiBbRmF0YWldIFdoeSBub3QganVzdCB1c2UgImJpdCByYXRlImZpZWxkIHRvIGNh cnJ5DQo+Pj4+Pj4gIk4iYmVjYXVzZSAiTiINCj4+Pj4+Pj4+Pj4+Pj4+IGltcGxpZXMgYml0IHJh dGU/ICBJIGFtIE9LIGlmIHlvdSBsaWtlIHRvIHVzZSBhIG5ldw0KPj4+Pj4+IGZpbGVkIChsaWtl DQo+Pj4+Pj4+Pj4+Pj4+PiAiVFMNCj4+Pj4+Pj4+Pj4+Pj4+IE51bWJlciIpIHRvIG9jY3VweSB0 aGUgcmVzZXJ2ZWQgZmllbGQgZXZlbiB0aG91Z2gNCj4+Pj4+PiB0aGF0IEkgcHJlZmVyDQo+Pj4+ Pj4+Pj4+Pj4+PiB0aGUgIG9yaWdpbmFsIGFwcHJvYWNoIChpZS4sIHVzZSAiYml0IHJhdGUiZmll bGQNCj4+PiB0byBjYXJyeSAiTiIpLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBBcmUg eW91IHByb3Bvc2luZyBkcm9wcGluZyBjYXJyeWluZyBiaXQgcmF0ZXMNCj4+Pj4+PiByZXByZXNl bnRlZCBhcyBhbg0KPj4+Pj4+Pj4+Pj4+PiBJRUVFICBmbG9hdGluZyBwb2ludCBhbmQganVzdCBj YXJyeWluZyBOIGZvciBPRFVmbGV4Pw0KPj4+Pj4+IFRoaXMgc2VlbXMNCj4+Pj4+Pj4+Pj4+Pj4g d29ya2FibGUgIHRvICBtZSwgYnV0IHdlIHNob3VsZCBlbnN1cmUgdGhhdCB0aGVyZSBhcmUgbm8g DQo+Pj4+Pj4+Pj4+Pj4+IHNpZ25pZmljYW50IG9iamVjdGlvbnMuDQo+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+PiBbRmF0YWldIFRoZXJlIGFyZSB0d28gdXNhZ2VzIGZvciAiIEJpdF9SYXRlICIg ZmllbGQgYXMNCj4+Pj4+PiBkZXNjcmliZWQNCj4+Pj4+Pj4+Pj4+PiBpbiB0aGUgbGluZXMgMjg3 LTMxMC4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICgxKSAgICBGb3IgT0RVZmxleChDQlIp LCB0aGUgQml0X1JhdGUgZmllbGQgaW5kaWNhdGVzDQo+Pj4+Pj4gdGhlIG5vbWluYWwNCj4+Pj4+ Pj4+Pj4+PiBiaXQNCj4+Pj4+Pj4+Pj4+PiByYXRlIG9mIE9EVWZsZXgoQ0JSKSBleHByZXNzZWQg aW4gYnl0ZXMgcGVyIHNlY29uZCwNCj4+Pj4+PiBlbmNvZGVkIGFzIGENCj4+Pj4+Pj4+Pj4+PiAz Mi1iaXQgIElFRUUgc2luZ2xlIHByZWNpc2lvbiBmbG9hdGluZy1wb2ludCBudW1iZXIuIA0KPj4+ IEZvciB0aGlzDQo+Pj4+Pj4+Pj4+Pj4gY2FzZSwgd2UgTVVTVCAgdXNlICAzMi1iaXQgSUVFRSBm bG9hdGluZyBwb2ludCBpbnN0ZWFkIG9mIA0KPj4+Pj4+Pj4+Pj4+ICJOIihQbGVhc2Ugc2VlIG1v cmUgaW4gc2VjdGlvbiAgNS4xKS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBJIGd1ZXNzIHlv dSByZWFsbHkgc3RpbGwgbmVlZCAodG8gYmUgYmFzZWQgb24pIHRoZSBjbGllbnQgDQo+Pj4+Pj4+ Pj4+PiBzaWduYWwgcmF0ZSBhdCB0aGUgZWRnZXMuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4gKDIpICAgIEZvciBPRFVmbGV4KEdGUCksIHdlIGNhbiBjaGFuZ2UgdGhl IHRleHQgKHRoZQ0KPj4+Pj4+IGxpbmVzIGZyb20gMzA1DQo+Pj4+Pj4+Pj4+Pj4gdG8NCj4+Pj4+ Pj4+Pj4+PiAzMTApIGJhc2VkIG9uIHlvdXIgc3VnZ2VzdGlvbiwgaWUuLCB0aGUgQml0X1JhdGUg ZmllbGQNCj4+Pj4+PiBpcyB1c2VkIHRvDQo+Pj4+Pj4+Pj4+Pj4gY2FycnkgICJOInRvIGluZGlj YXRlIHRoZSBub21pbmFsIGJpdCByYXRlIG9mIHRoZQ0KPj4+IE9EVWZsZXgoR0ZQKS4NCj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBidXQgeW91J3JlIHNheXMgZW5jb2RlZCBhcyAoTipOb21pbmFs IFJhdGUpIHJpZ2h0PyAgDQo+V2F0J3MgdGhlIA0KPj4+Pj4+Pj4+Pj4gdmFsdWUgb2YgIHRoaXMg dnMganVzdCBjYXJyeWluZyBOPw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+PiBUaGVyZWZvcmUsIEkgYW0gcHJvcG9zaW5nIHVzaW5nIG9uZSBzaW5n bGUgZmlsZWQNCj4+PiAoIkJpdF9SYXRlICIpDQo+Pj4+Pj4+Pj4+Pj4gZm9yIHRoZXNlIHR3byBj YXNlcywgaW4gdGhpcyB3YXksIHdlIGNhbiBsZWF2ZSB0aGUgDQo+IlJlc2VydmVkIg0KPj4+Pj4+ Pj4+Pj4+IGJpdHMgZm9yIGZ1dHVyZS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBiaXRzIGlu IHRoZSBjb250cm9sIHBsYW5lIGFyZSBnZW5lcmFsbHkgY2hlYXAsIElNTyBpdCdzDQo+Pj4+Pj4g YmV0dGVyIHRvDQo+Pj4+Pj4+Pj4+PiBoYXZlICBzaW1wbGVyIGVuY29kaW5nIHRoYW4gdG8gb3B0 aW1pemUgZXZlcnkgYml0IChvcg0KPj4+IDggaW4gdGhpcw0KPj4+Pj4+Pj4+Pj4gY2FzZSkuDQo+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gTG91DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4gSG9wZSB3ZSBhcmUgbm93IGF0IHRoZSBzYW1lIHBhZ2UuDQo+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4gRmF0YWkNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4+Pj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+PiBDQ0FNUEBp ZXRmLm9yZw0KPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2NhbXANCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IENDQU1QQGll dGYub3JnDQo+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j Y2FtcA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+IENDQU1QQGll dGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAN Cj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4NCj4+IA0KPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcg bGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2NhbXANCg== From ogondio@tid.es Wed Jan 30 01:12:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3DF21F85E8 for ; Wed, 30 Jan 2013 01:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.439 X-Spam-Level: X-Spam-Status: No, score=-4.439 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 Vd5e+e4UyzpF for ; Wed, 30 Jan 2013 01:12:57 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E94221F86B6 for ; Wed, 30 Jan 2013 01:12:56 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MHF00I79LLJGD@tid.hi.inet> for ccamp@ietf.org; Wed, 30 Jan 2013 10:12:55 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id A2.28.03184.614E8015; Wed, 30 Jan 2013 10:12:54 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MHF00I75LLIGD@tid.hi.inet> for ccamp@ietf.org; Wed, 30 Jan 2013 10:12:54 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0328.009; Wed, 30 Jan 2013 10:12:54 +0100 Date: Wed, 30 Jan 2013 09:12:54 +0000 From: =?Windows-1252?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: X-Originating-IP: [10.95.64.115] To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Message-id: <7CFF94B047D8864CB6268315034E35DE1B22627E@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_iBkVNzTRaeiEF7TOodMtkw)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-index: AQHN/sn8db5FsFwnT0ONC+D08Y8XnA== user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4068-b7fc06d000000c70-c0-5108e416a354 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsXCFe/ApSv2hCPQoP2wtcWTOTdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseL7VpaC14oVp9dqNDDukO1i5OCQEDCR2PtMp4uRE8gUk7hw bz1bFyMXh5DABkaJxkn7WCCcH4wSD/uuQTkzGSWW9N5kB2lhEVCVWNn6nwnEZhNwkmjoOc8I YgsLREjc/LKEGcTmFIiSuP7+EBPECgWJP+ces4BsFhHwlZg6HSzMK+AtcWHLUhYIW1Dix+R7 YDazQK7E8T1v2SBscYk5vyaygtiMArISK8+fBlslIhAp8X3/byhbT+LTg04wWxTIbjt2hh1i rYDEkj3nmSFsUYmXj/+xTmAUnYVk3Swk62YhWQdhG0i8PzefGcLWlli28DWUrS+x8ctZRgjb TOJZ+w8mZDULGDlWMYoVJxVlpmeU5CZm5qQbGOplZOpl5qWWbGKExFzGDsblO1UOMQpwMCrx 8H64xhooxJpYVlyZe4hRkoNJSZT35UOOQCG+pPyUyozE4oz4otKc1OJDjBIczEoivApqQDne lMTKqtSifJiUDAeHkgTvs0dAKcGi1PTUirTMHGBigUkzcXCCtPMAtW8CqeEtLkjMLc5Mh8if YlTlaDnQ/ZxRiCUvPy9VSpxX6zFQkQBIUUZpHtycV4ziQAcL8zqAjOABpka4Ca+AhjMBDTdq YwcZXpKIkJJqYJS/kn/vRP2a7B6mAhFv0/n1b3K329qyTpjwV8o61d5frLeSyVxWaeViq53z 2teXyKS29y7XluKU+fhg0fVzHlc1cs/nhky3/CR96U3cjYL3zfNuZqR5HzdPP7opYrNX5LJV 8wRCOy5avClOv9nCnljfz3drzynNm1qSZb6Gkid91ux88U7ljRJLcUaioRZzUXEiANPmkJdK AwAA Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:12:59 -0000 --Boundary_(ID_iBkVNzTRaeiEF7TOodMtkw) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Yes/support, Best Regards, =D3scar De: , DEBORAH A BRUNGARD > Fecha: jueves, 24 de enero de 2013 19:42 Para: CCAMP > Asunto: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG do= cument All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = =93yes/support=94 or =93no/do not support=94. If indicating no, please stat= e your technical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_iBkVNzTRaeiEF7TOodMtkw) Content-id: <87CB9A20DEE3DC4E9D1F5716B7098598@hi.inet> Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable
Yes/support,

Best R= egards,

=D3sca= r

De: <BRUNGARD>, DEBORAH A BRU= NGARD <db3546@att.com>
Fecha: jueves, 24 de enero de 2013 = 19:42
Para: CCAMP <ccamp@ietf.org>
Asunto: [CCAMP] Poll on making draf= t-ali-ccamp-xro-lsp-subobject-02 a WG document

All,
 
This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobj= ect-02 a ccamp working group document. Please send email to the list indica= ting =93yes/support=94 or =93no/do not support=94. If indicating no, please= state your technical reservations with the document.
 
The poll ends Thursday, January 31st.
 
Note, as stated by some of the authors, IPR has been disclosed in comp= liance with IETF IPR rules.
 
Thanks,
Deborah and Lou
 
 


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_iBkVNzTRaeiEF7TOodMtkw)-- From ogondio@tid.es Wed Jan 30 01:14:48 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0487F21F86B6 for ; Wed, 30 Jan 2013 01:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 v1jYXyGuboMg for ; Wed, 30 Jan 2013 01:14:47 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2D6F21F8467 for ; Wed, 30 Jan 2013 01:14:46 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MHF00IIMLOLGD@tid.hi.inet> for ccamp@ietf.org; Wed, 30 Jan 2013 10:14:45 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 6C.28.03184.584E8015; Wed, 30 Jan 2013 10:14:45 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MHF00IIILOLGD@tid.hi.inet> for ccamp@ietf.org; Wed, 30 Jan 2013 10:14:45 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Wed, 30 Jan 2013 10:14:45 +0100 Date: Wed, 30 Jan 2013 09:14:45 +0000 From: =?Windows-1252?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: X-Originating-IP: [10.95.64.115] To: "BRUNGARD, DEBORAH A" , "ccamp@ietf.org" Message-id: <7CFF94B047D8864CB6268315034E35DE1B22628F@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cuJvwoyicuGVNnJ0WUB3Uw)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-index: AQHN/so+1B9dGlt1okapfSbqVo230w== user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4068-b7fc06d000000c70-05-5108e485b4ab X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsXCFe/Apdv6hCPQ4NI/OYsnc26wODB6LFny kymAMYrLJiU1J7MstUjfLoErY+XMRsaCm4oVJ1++YGlgXC3bxcjJISFgIvGwp4cRwhaTuHBv PRuILSSwgVFi7Ry3LkYuIPsHo8S1bS2sEM5MRokT66+yg1SxCKhKPN/WCWazCThJNPScB5sk LBAh0XriAnMXIwcHp0CUxPKfehALFCT+nHvMAhIWEfCVmDqdCSTMK+AtceDxHTYIW1Dix+R7 LCA2s0CuRPPkP8wQtrjEnF8TWUFsRgFZiZXnT4NtEhGIlNg1/SWUrSfR+Ps7WL0okN127Aw7 xFoBiSV7zjND2KISLx//Y53AKDoLybpZSNbNQrIOwjaQeH9uPlRcW2LZwtdQtr7Exi9nGSFs M4nN/2cyIqtZwMixilGsOKkoMz2jJDcxMyfdwFAvI1MvMy+1ZBMjJOYydjAu36lyiFGAg1GJ h/fDNdZAIdbEsuLK3EOMkhxMSqK8Lx9yBArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4VVQA8rx piRWVqUW5cOkZDg4lCR4Yx4DpQSLUtNTK9Iyc4CJBSbNxMEJ0s4D1K4BUsNbXJCYW5yZDpE/ xajK0XKg+zmjEEtefl6qlDhvGkiRAEhRRmke3JxXjOJABwvzGoFkeYCpEW7CK6DhTEDDjdrY QYaXJCKkpBoYOzleVqS8XxiSPLnV4nLSjF3Sx1eop/N7HX3glMlUwrXLa5LI5+611xpYn61x 9W+pyVgdkfbusSq/9eTww88OKNy/5aRfL2vxQkF55hyGJywOjfbW+zqc2UPeW7m4Ltmo73/x pazFpo1rvqr6FXT27TXyO+Veu2ri303v6s1eT+yVybq9/v9VJZbijERDLeai4kQAxT5PRUoD AAA= Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:14:49 -0000 --Boundary_(ID_cuJvwoyicuGVNnJ0WUB3Uw) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Yes/support, Best Regards, =D3scar De: , DEBORAH A BRUNGARD > Fecha: jueves, 24 de enero de 2013 19:47 Para: CCAMP > Asunto: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG do= cument All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g =93yes/support=94 or =93no/do not support=94. If indicating no, please st= ate your technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR =93still being documen= ted=94. Thanks, Deborah and Lou ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_cuJvwoyicuGVNnJ0WUB3Uw) Content-id: <6B3613A6E76AD840AFED57F98F478042@hi.inet> Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable
Yes/support,

Best R= egards,

=D3sca= r

De: <BRUNGARD>, DEBORAH A BRU= NGARD <db3546@att.com>
Fecha: jueves, 24 de enero de 2013 = 19:47
Para: CCAMP <ccamp@ietf.org>
Asunto: [CCAMP] Poll on making draf= t-ali-ccamp-te-metric-recording-03 WG document

All,
 
This is start a two week poll on making draft-ali-ccamp-te-metric-reco= rding-03 a ccamp working group document. Please send email to the list indi= cating =93yes/support=94 or =93no/do not support=94. If indicating no, plea= se state your technical reservations with the document.
 
The poll ends Thursday, Feb. 7th.
 
Note, as stated by some of the authors, there is IPR =93still being do= cumented=94.
 
Thanks,
Deborah and Lou
 
 


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_cuJvwoyicuGVNnJ0WUB3Uw)-- From shtsuchi@cisco.com Wed Jan 30 01:19:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A6721F86EF for ; Wed, 30 Jan 2013 01:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 22Lv2Nmw9Bia for ; Wed, 30 Jan 2013 01:19:53 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9D86521F86B6 for ; Wed, 30 Jan 2013 01:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=703; q=dns/txt; s=iport; t=1359537593; x=1360747193; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2PYHsOl7NcEtPH/Oi0CqL2332Bq7eNNA4RWJZDY50pA=; b=aLDUd1nCoBwLT6M+BHMgpu3/l5/udAGzQjkHR28moKS+OGz80nlZlHfa kL+240YYNwbuBCl8J6IR5NB257kO9848QSrva4ODynvuZdA/IarD0m07A RghrEsMQZznNH01xiefF8gfMCtKasvZUUyDji0GdP/SskGmjjcvCk9E5s o=; X-IronPort-AV: E=Sophos;i="4.84,566,1355097600"; d="scan'208";a="24559453" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 30 Jan 2013 09:19:48 +0000 Received: from [10.141.32.249] (dhcp-10-141-32-249.cisco.com [10.141.32.249]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0U9JlRX008348; Wed, 30 Jan 2013 09:19:47 GMT Message-ID: <5108E5B2.5000807@cisco.com> Date: Wed, 30 Jan 2013 18:19:46 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: db3546@att.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:19:54 -0000 yes/support Regards, -Shishio (2013/01/25 3:47), BRUNGARD, DEBORAH A wrote: > All, > This is start a two week poll on making draft-ali-ccamp-te-metric-recording-03 a ccamp working group document. Please send email to the list indicating $B!H(Byes/support$B!I(B or $B!H(Bno/do not support$B!I(B. If indicating no, please state your technical reservations with the document. > The poll ends Thursday, Feb^. 7th. > Note, as stated by some of the authors, there is IPR $B!H(Bstill being documented$B!I(B. > Thanks, > Deborah and Lou > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From shtsuchi@cisco.com Wed Jan 30 01:20:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DC821F86EF for ; Wed, 30 Jan 2013 01:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 hw7K1-xHrFVl for ; Wed, 30 Jan 2013 01:20:42 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9452821F86B6 for ; Wed, 30 Jan 2013 01:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=714; q=dns/txt; s=iport; t=1359537641; x=1360747241; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wM+84em2UuC/BAIqivbRtYogewxRrrPDzuBUBwKm87M=; b=akK6jaYlWGvGsumkNFVurR6tqDSMGafRbN4wgfAYplpT+hwg6Jr/cX5G +SVYHBupP2tbzWxC5baPsMEycZ3jvNkTdjq41M3WOXuvUecUGpnw4Xmk6 GE7dYVqMxJ/NLol3m0bCqr2gnr7oFz2+1UvEK3C/TTp5kHwHcf6evrogj E=; X-IronPort-AV: E=Sophos;i="4.84,566,1355097600"; d="scan'208";a="24559507" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 30 Jan 2013 09:20:38 +0000 Received: from [10.141.32.249] (dhcp-10-141-32-249.cisco.com [10.141.32.249]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0U9KbIl003620; Wed, 30 Jan 2013 09:20:37 GMT Message-ID: <5108E5E4.30107@cisco.com> Date: Wed, 30 Jan 2013 18:20:36 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: db3546@att.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:20:43 -0000 yes,support. Regards, -Shishio (2013/01/25 3:42), BRUNGARD, DEBORAH A wrote: > All, > This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. Please send email to the list indicating $B!H(Byes/support$B!I(B or $B!H(Bno/do not support$B!I(B. If indicating no, please state your technical reservations with the document. > The poll ends Thursday, January 31^st . > Note, as stated by some of the authors, IPR has been disclosed in compliance with IETF IPR rules. > Thanks, > Deborah and Lou > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From sergio.belotti@alcatel-lucent.com Wed Jan 30 02:17:49 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1BC21F858C for ; Wed, 30 Jan 2013 02:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.049 X-Spam-Level: X-Spam-Status: No, score=-9.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] 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 v+qkaDNm19WB for ; Wed, 30 Jan 2013 02:17:48 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA3F21F8457 for ; Wed, 30 Jan 2013 02:17:36 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0UAHOXx001341 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Jan 2013 11:17:28 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 30 Jan 2013 11:17:27 +0100 From: "BELOTTI, SERGIO (SERGIO)" To: Fatai Zhang , Lou Berger Date: Wed, 30 Jan 2013 11:17:25 +0100 Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZXCuS8hTs+eckmWtA0MM2hSFphfguWQgAInNUA= Message-ID: References: <5105E684.4030607@labn.net> <4A1562797D64E44993C5CBF38CF1BE48073D01@ESESSMB301.ericsson.se> <5106DED0.3090008@labn.net> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: CCAMP Subject: [CCAMP] R: Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 10:17:50 -0000 SGkgYWxsLA0KDQpPcHRpb24gMiBpcyBteSBwcmVmZXJlbmNlIHRvby4gSSBzaGFyZSBjb21wbGV0 ZWx5IG1vdGl2YXRpb25zIHByb3ZpZGVkIGJ5IEZhdGFpLg0KDQpUaGFua3MuDQoNCkJlc3QgUmVn YXJkcw0KU2VyZ2lvDQoNCkJlbG90dGkgU2VyZ2lvIC0gU3lzdGVtIEFyY2hpdGVjdA0KQUxDQVRF TC1MVUNFTlQgIE9wdGljcyBEaXZpc2lvbg0KLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0N CkRhOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9y Z10gUGVyIGNvbnRvIGRpIEZhdGFpIFpoYW5nDQpJbnZpYXRvOiBtYXJ0ZWTDrCAyOSBnZW5uYWlv IDIwMTMgMy4yNw0KQTogTG91IEJlcmdlcjsgQ0NBTVANCk9nZ2V0dG86IFJlOiBbQ0NBTVBdIFBv bGwgb24gT0RVRmxleC1yZWxhdGVkIGVuY29kaW5nICh3YXM6IFdHIExhc3QgQ2FsbCBjb21tZW50 cyBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQpDQoNCkhpIExv dSwNCg0KSSB3b3VsZCBwaWNrIHVwIG9wdGlvbiAyIChiZXR0ZXIgdGhhbiBvcHRpb24gMSkgYmVj YXVzZSBvZiB0aGUgZm9sbG93aW5nIHJlYXNvbnMsIGV2ZW4gdGhvdWdoIEkgc3BlbnQgbXVjaCB0 aW1lIHRvIGNvbnZpbmNlIHlvdSAoYnV0IEkgZmFpbGVkKS4NCg0KKDEpIFRoZXJlIHdpbGwgYmUg Y29uc2lzdGVudCBiZXR3ZWVuIHNpZ25hbGluZyBkcmFmdCAobmVlZCBjcmFuay1iYWNrKSBhbmQg dGhlIGV4aXN0aW5nIHJvdXRpbmcgZHJhZnQgKHdlIGFsbCBzcGVudCBzbyBtdWNoIHRpbWUgb24g cm91dGluZyBkcmFmdCB0byBnZXQgdGhlIGNvbnNlbnN1cykuDQooMikgVGhlcmUgd2lsbCBiZSBj b25zaXN0ZW50IGZvciAiQml0X1JhdGUiIGZpbGVkIGZvciBib3RoIE9EVWZsZXgoQ0JSKSBhbmQg T0RVZmxleChHRlApIGNhc2VzIChpZSwgaXQgb25seSBuZWVkcyBvbmUgc2luZ2xlICJCaXRfUmF0 ZSIgZmllbGQpLg0KKDMpIEkgZG9uJ3QgdGhpbmsgb3B0aW9uIDMmNCBhcmUgYmV0dGVyIHRoYW4g b3B0aW9uIDEmMiBmb3IgaW50ZXJ3b3JraW5nIHdpdGggZWFybHkgaW1wbGVtZW50YXRpb25zIChJ IHRoaW5rIGFsbCB0aGUgYXV0aG9ycyBhcmUgZnJvbSB2ZW5kb3JzLCB3ZSBrbm93IHRoaXMgdmVy eSB3ZWxsLiBVc3VhbGx5L3NvbWV0aW1lcywgdGhlcmUgaXMgYWN0dWFsbHkgbm8gY29tcGF0aWJp bGl0eS9pbnRlcndvcmtpbmcgaXNzdWUgaW4gdGhlIHJlYWwgd29ybGQpLg0KDQpGb3Igb3B0aW9u IDMsIEkgYW0gZmluZSBiZWNhdXNlIEkgYXBwcmVjaWF0ZSB0aGUgd29yayB0aGF0IEkgaGF2ZSBk b25lLCA6LSksIGlmIHdlIGRvbid0IGNvdW50IHRoZSBhZGRpdGlvbmFsIHdvcmsgb24gcm91dGlu ZyBkcmFmdC4NCg0KDQpBbnl3YXksIHBsZWFzZSBkb24ndCB0aGluayBhYm91dCBvcHRpb24gNCwg SSBkb24ndCBzZWUgYW55IHNpZ25pZmljYW50IGFkdmFudGFnZXMgYnkgZG9pbmcgdGhhdCBiZXNp ZGVzIG1vcmUgd29yayBhbmQgbW9yZSBkaXNjdXNzaW9ucy4NCg0KDQoNCkJlc3QgUmVnYXJkcw0K DQpGYXRhaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBM b3UgQmVyZ2VyDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI5LCAyMDEzIDQ6MjYgQU0NClRvOiBD Q0FNUA0KU3ViamVjdDogW0NDQU1QXSBQb2xsIG9uIE9EVUZsZXgtcmVsYXRlZCBlbmNvZGluZyAo d2FzOiBXRyBMYXN0IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWdu YWxpbmctZzcwOXYzLTA0KQ0KDQpBbGwsDQogICAgICAgIFdlIHdvdWxkIGxpa2UgdG8gdHJ5IHRv IGNsb3NlIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBHLjcwOQ0KZHJhZnRzIHNvIHRoYXQgd2UgY2Fu IG1vdmUgcmFwaWRseSB0b3dhcmRzIHB1YmxpY2F0aW9uIHJlcXVlc3QuICBUaGUNCmRpc2N1c3Np b24gb2YgKG9uZSBvZiBteSkgTEMgY29tbWVudHMgaGFzIHJlc3VsdGVkIGluIHNldmVyYWwgb3B0 aW9ucw0KZm9yIHRoZSBzaWduYWxpbmcgT0RVLXJlbGF0ZWQgdHJhZmZpYyBwYXJhbWV0ZXJzLCBh bmQgdGhlIHBvaW50IGhhcw0KYmVlbiByYWlzZWQgdGhhdCByZWFsaWduaW5nIHJvdXRpbmcgd2l0 aCBzaWduYWxpbmcgc2hvdWxkIGJlIGRpc2N1c3NlZC4NCg0KUGxlYXNlIGtlZXAgaW4gbWluZCB0 aGF0IHRoZSBvYmplY3RpdmUgb2YgYW55IFBTIGlzIGludGVyb3BlcmFiaWxpdHksDQphbmQgdGhh dCB0aGVyZSBtYXkgYmUgZWFybHkgaW1wbGVtZW50YXRpb25zIHRoYXQgbWF0Y2ggZzcwOXYzLTA0 Lg0KDQpUaGUgYmFzaWMgcXVlc3Rpb24gaXMgb25lIG9mIGlmIE4sIHRoZSBudW1iZXIgb2YgdGlt ZSBzbG90cyBuZWVkZWQgdG8NCnN1cHBvcnQgYSBPRFVmbGV4KEdGUCkgc2lnbmFsLCBzaG91bGQg YmUgY2FycmllZCBhcyBhIGNhbGN1bGF0ZWQgSUVFRQ0KZmxvYXRpbmcgcG9pbnQgbnVtYmVyIG9y IGRpcmVjdGx5LiAgIE9wdGlvbnMgMSBhbmQgMiBiZWxvdyByZWZsZWN0IHRoZQ0KZm9ybWVyLCBv cHRpb25zIDMgYW5kIDQgbWF0Y2ggdGhlIGxhdHRlci4gIEl0IGlzIHdvcnRoIG5vdGluZyB0aGF0 IG9ubHkNCm9wdGlvbnMgMSBhbmQgMiBhcmUgcHJvcG9zZWQgZm9yIE9EVWZsZXgoR0ZQKSwgaS5l LiwgTiBtdXN0IGJlDQpjYWxjdWxhdGVkIGZvciBPRFVmbGV4KENCUikgc2lnbmFsIHR5cGVzIHdp dGggYWxsIG9wdGlvbnMuDQoNClBsZWFzZSBzdGF0ZSB5b3VyIHN1cHBvcnQgZm9yIG9uZSB0aGUg b3B0aW9ucyBhbmQsIGlmIHlvdSB3aXNoLCB0aGUNCmp1c3RpZmljYXRpb24gZm9yIHlvdXIgcG9z aXRpb246DQoNCjEpIEZvbGxvdyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5 djMtMDQNCiAgIGkuZS4sIHJlZGVmaW5lIFtSRkM0MzI4XSBUcmFmZmljIFBhcmFtZXRlcnMgYy10 eXBlIHdoZW4gdXNlZCB3aXRoDQogICBPVE4tVERNIGxhYmVscy4gT0RVZmxleChHRlApIG51bWJl ciBvZiB0cmlidXRhcnkgc2xvdHMgKE4pIGlzDQogICBlbmNvZGVkIGFzOg0KDQogICAuLi4gdGhl IEJpdF9SYXRlIGZpZWxkIGZvciBPRFVmbGV4KEdGUCkgTVVTVA0KICAgZXF1YWwgdG8gb25lIG9m IHRoZSA4MCB2YWx1ZXMgbGlzdGVkIGJlbG93Og0KDQogICAgICAgMSAqIE9EVTIudHM7IDIgKiBP RFUyLnRzOyAuLi47IDggKiBPRFUyLnRzOw0KICAgICAgIDkgKiBPRFUzLnRzOyAxMCAqIE9EVTMu dHMsIC4uLjsgMzIgKiBPRFUzLnRzOw0KICAgICAgIDMzICogT0RVNC50czsgMzQgKiBPRFU0LnRz OyAuLi47IDgwICogT0RVNC50cy4NCg0KMikgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt c2lnbmFsaW5nLWc3MDl2My0wNQ0KICAgaS5lLiwgdXNlIGEgbmV3IEMtdHlwZSBmb3IgT1ROLVRE TSBsYWJlbHMuICBFbmNvZGluZyBkZXRhaWxzDQogICB1bmNoYW5nZWQgZnJvbSBnNzA5djMtMDQu DQogICAoVGhpcyBvcHRpb24gYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiB0aGUgc2FtZSBjLXR5cGUg bmVlZGluZyB0bw0KICAgIGJlIHBhcnNlZCBiYXNlZCBvbiBsYWJlbC9zd2l0Y2hpbmcgdHlwZS4p DQoNCjMpIEZvbGxvdyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDYN CiAgIGkuZS4sICB1c2UgYSBuZXcgQy10eXBlIGZvciBPVE4tVERNIGxhYmVscy4gTiBpcyBkaXJl Y3RseSBjYXJyaWVkDQogICBmb3IgT0RVZmxleChHRlApIG9ubHkuDQoNCjQpIERpc2N1c3NlZCwg YnV0IG5vdCBpbiBhbnkgZHJhZnQNCiAgIFVzZSBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25h bGluZy1nNzA5djMtMDQgZW5jb2RpbmcgZm9yIGFsbA0KICAgYnV0IE9EVWZsZXgoR0ZQKSwgYW5k IGRlZmluZSBuZXcgT0RVZmxleChHRlApIHNwZWNpZmljIFRyYWZmaWMNCiAgIFBhcmFtZXRlcnMg YmFzZWQgb24gZzcwOXYzLTA2LCBwcmVzdW1hYmx5IHdpdGggdW51c2VkIGZpZWxkcw0KICAgcmVt b3ZlZC4NCiAgIChUaGlzIGFsc28gYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiB0aGUgc2FtZSBjLXR5 cGUgbmVlZGluZyB0byBiZQ0KICAgIHBhcnNlZCBiYXNlZCBvbiBsYWJlbCB0eXBlLCBidXQgbWVh bnMgdGhlcmUgYXJlIGRpZmZlcmVudCB0eXBlcw0KICAgIGJhc2VkIG9uIHNpZ25hbCB0eXBlLikN Cg0KT3B0aW9uIDEgYW5kIDIgZG8gbm90IGltcGx5IGFueSBjaGFuZ2VzIHRvIHJvdXRpbmcsIHdo aWxlIG9wdGlvbnMgMyBhbmQNCjQgbWF5LiAgUm91dGluZyBpbXBsaWNhdGlvbnMgd2lsbCBiZSBk aXNjdXNzZWQgYmFzZWQgb24gdGhlIHJlc3VsdHMgb2YNCnRoaXMgcG9sbCwgYW5kIG9ubHkgaWYg dGhlcmUgaXMgY29uc2Vuc3VzIHRvIHN1cHBvcnQgcG9zaXRpb25zIDMgb3IgNC4NCg0KV2UgaG9w ZSB0byBtYWtlIGEgY29uc2Vuc3VzIGNhbGwgYnkgdGhlIGVuZCBvZiB0aGUgd2VlaywgYnV0IHdp bGwNCmNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFzIG5lZWRlZC4NCg0KTXVjaCB0aGFua3MsDQpM b3UgKGFuZCBEZWJvcmFoKQ0KDQpPbiAxLzI4LzIwMTMgNTowOCBBTSwgRGFuaWVsZSBDZWNjYXJl bGxpIHdyb3RlOg0KPiAgQWxsLA0KPg0KPiBJIHRoaW5rIHRoZSBjaGFuZ2VzIHByb3Bvc2VkIGFy ZSBtZWFuaW5nZnVsIGFuZCB3b3VsZCBzdXBwb3J0IHRoZW0gaW4gYW4gaW5kaXZpZHVhbCBvciBl YXJseSBXRyBkcmFmdCwgYnV0IHRoZXkgZG9uJ3Qgc2VlbSB0byBwcm92aWRlIHNpZ25pZmljYXRp dmUgYWR2YW50YWdlcyB0byByaXNrIGludGVyd29ya2luZyBpc3N1ZXMgd2l0aCBlYXJseSBpbXBs ZW1lbnRhdGlvbnMuDQo+IE1vcmVvdmVyIHRoZSBjaGFuZ2VzIGRvbid0IGFsbG93IHVzIGdldHRp bmcgdG90YWxseSByaWQgb2Ygb2YgdGhlIGJpdF9yYXRlIGZpZWxkIGFzIGl0IGlzIHN0aWxsIG5l ZWRlZCBmb3IgT0RVZmxleCAoQ0JSKS4NCj4NCj4gTXkgMmMNCj4gRGFuaWVsZQ0KPg0KPg0KPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFphZmFyIEFsaSAoemFsaSkgW21h aWx0bzp6YWxpQGNpc2NvLmNvbV0NCj4+IFNlbnQ6IGx1bmVkw6wgMjggZ2VubmFpbyAyMDEzIDQu NDcNCj4+IFRvOiBMb3UgQmVyZ2VyDQo+PiBDYzogR3J1bWFuLCBGcmVkOyBGYXRhaSBaaGFuZzsg RGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FNUDsNCj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2ln bmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cg TGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGlu Zy1nNzA5djMtMDQNCj4+DQo+PiBIaSBMb3UtDQo+Pg0KPj4gUGxlYXNlIHNlZSBpbi1saW5lLg0K Pj4NCj4+IFRoYW5rcw0KPj4NCj4+IFJlZ2FyZHMuLi5aYWZhcg0KPj4NCj4+IE9uIDEvMjcvMTMg OTo0NiBQTSwgIkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4+DQo+Pj4g WmFmYXIsDQo+Pj4gICAgIElzIHlvdXIgY29tbWVudCB3aXRoIHJlc3BlY3QgdG8ganVzdCByb3V0 aW5nIG9yIGJvdGgNCj4+IHNpZ25hbGluZyBhbmQNCj4+PiByb3V0aW5nPw0KPj4NCj4+IEJvdGgs IGluY2x1ZGluZyBjb25zaXN0ZW5jeSBiZXR3ZWVuIHNpZ25hbGluZyBhbmQgcm91dGluZyBhdHRy aWJ1dGVzLg0KPj4NCj4+Pg0KPj4+IEFsc28sIHdoZW4geW91IHNheSAiaW1wbGVtZW50YXRpb25z IGJhc2VkIG9uIGRyYWZ0IHZlcnNpb25zIiwNCj4+IGRvIHRoZXNlDQo+Pj4gaW1wbGVtZW50YXRp b25zIGluY2x1ZGUgc3VwcG9ydCBmb3IgT0RVZmxleD8gIChXaGljaCBoYXMgcmVhbGx5IGJlZW4N Cj4+PiB0aGUgZm9jdXMgb2YgdGhlIGRpc2N1c3Npb24uKQ0KPj4NCj4+IFllcywgSSB3YXMgcmVm ZXJyaW5nIHRvIE9EVUZsZXguIEFzIHlvdSBrbm93LCBmaXhlZCBPRFUgaXMNCj4+IHNpZ25hbGVk IHZpYSBsZXZlbCAoMCBCVykgc28gaXRzIG5vdCBhbiBpc3N1ZS4NCj4+DQo+Pj4NCj4+PiBCVFcg SSB0b29rIEZyZWQncyBjb21tZW50cyBhcyByZWxhdGVkIHRvIGp1c3QgdGhlIG5ldw0KPj4gT1RO LXNwZWNpZmljIElTQ0QNCj4+PiBkZWZpbml0aW9ucyAoc2VjdGlvbiA0LjEuMiBvZiBvc3BmLWc3 MDl2My0wNSwgaW4gcGFydGljdWxhcikuICBOb3RlDQo+Pj4gdGhhdCBzZWN0aW9uIDQuMS4xIGFs cmVhZHkgY2FycmllcyBOIChudW1iZXIgb2YgT0RVcykgbm90DQo+PiBJRUVFIGZsb2F0aW5nDQo+ Pj4gcG9pbnQgcmVwcmVzZW50YXRpb25zIG9mIGF2YWlsYWJsZSBiYW5kd2lkdGguDQo+Pg0KPj4g V2hhdCBJIG1lYW50IGlzIFVucmVzZXJ2ZWQgQmFuZHdpZHRoIGF0IHByaW9yaXR5IHggYW5kIE1h eCBMU1ANCj4+IEJhbmR3aWR0aCBhdCBwcmlvcml0eSB4Lg0KPj4NCj4+Pg0KPj4+IE11Y2ggdGhh bmtzLA0KPj4+IExvdQ0KPj4+DQo+Pj4gT24gMS8yNy8yMDEzIDc6NDYgUE0sIFphZmFyIEFsaSAo emFsaSkgd3JvdGU6DQo+Pj4+IEFsbC0NCj4+Pj4NCj4+Pj4gVGhpcyBpbXBhY3RzIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiBkcmFmdCB2ZXJzaW9ucyAoYW5kDQo+Pj4+IGhlbmNl IGludGVyb3Agd2l0aCB0aGVzZSBpbXBsZW1lbnRhdGlvbnMgbW92aW5nIGZvcndhcmQpLg0KPj4g SU1PIHRoaXMgaXMNCj4+Pj4gYSBiaWdnZXIgY2hhbmdlIGZvciB1cyB0byBhc3N1bWUgYXQgdGhl IGxhc3QgY2FsbCBzdGFnZS4NCj4+IEZ1cnRoZXJtb3JlDQo+Pj4+IHdlIGhhdmUgYmVlbiB1c2lu ZyBJRUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCBmb3IgVW5yZXNlcnZlZA0KPj4+PiBCYW5kd2lk dGgvIE1heCBMU1AgQlcgaW4gSUVFRSBmbG9hdGluZyBwb2ludCBmb3JtYXQgZm9yIG90aGVyDQo+ Pj4+IHRlY2hub2xvZ2llcy4gT3ZlcmFsbCwgSSB0aGluayB0aGlzIGNoYW5nZSBzdWZmZXJzIGZy b20gdGhlDQo+PiAibGF3IG9mIGRpbWluaXNoaW5nIHJldHVybnMiLg0KPj4+Pg0KPj4+PiBUaGFu a3MNCj4+Pj4NCj4+Pj4gUmVnYXJkcyDFoCBaYWZhcg0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiAxLzI3 LzEzIDEwOjI4IEFNLCAiR3J1bWFuLCBGcmVkIg0KPj4gPGZyZWQuZ3J1bWFuQHVzLmZ1aml0c3Uu Y29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhpIExvdSwgRmF0YWksIERhbmllbGUsDQo+Pj4+Pg0K Pj4+Pj4gSSB1bmRlcnN0YW5kIHRoZSBsYXRlc3QgY2hhbmdlIHRvIHRoZSB3YXkgYmFuZHdpZHRo IGlzDQo+PiBzaWduYWxlZCBmb3INCj4+Pj4+IE9EVWZsZXgoR0ZQKSwgaS5lLiwgc2lnbmFsaW5n IHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3RzDQo+PiBOIGluc3RlYWQNCj4+Pj4+IG9mICB0 aGUgYmFuZHdpZHRoIHJhdGUgaW4gYnBzLiAgSSBiZWxpZXZlIHRoYXQgdGhpcyBzaW1wbGlmaWVz IHRoZQ0KPj4+Pj4gc2lnbmFsaW5nICBhbmQgaW50ZXJvcGVyYWJpbGl0eSBzbyBJJ20gaW4gYWdy ZWVtZW50IHdpdGgNCj4+IHRoaXMgY2hhbmdlLg0KPj4+Pj4NCj4+Pj4+IEhvd2V2ZXIsIGl0IHNl ZW1zIHdlIGFyZSBub3cgaW5jb25zaXN0ZW50IGJldHdlZW4gaG93IHdlDQo+PiByZXByZXNlbnQN Cj4+Pj4+IGJhbmR3aWR0aCBpbiByb3V0aW5nIGFuZCBzaWduYWxpbmcgZm9yIE9EVWZsZXgoR0ZQ KS4gIFJvdXRpbmcNCj4+Pj4+IGFkdmVydGlzZXMgIHRoZSBiYW5kd2lkdGggdXNpbmcgYSBmbG9h dGluZyBwb2ludCByZXByZXNlbnRhdGlvbiBvZg0KPj4+Pj4gYmFuZHdpZHRoLCB3aGlsZSAgc2ln bmFsaW5nIGlzIHVzaW5nIHRoZSBudW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3RzLg0KPj4+Pj4gSXQg c2VlbXMgdGhlIHNhbWUgIGJlbmVmaXRzIHdvdWxkIGJlIG9idGFpbmVkIGJ5DQo+PiBhZHZlcnRp c2luZyB0aGUgbWF4DQo+Pj4+PiBMU1AgYmFuZHdpZHRoIGFuZCAgdW5yZXNlcnZlZCBiYW5kd2lk dGggZm9yIE9EVWZsZXgoR0ZQKSBpbg0KPj4gdGVybXMgb2YNCj4+Pj4+IHRoZSBudW1iZXIgb2Yg dHJpYnV0YXJ5ICBzbG90cy4NCj4+Pj4+DQo+Pj4+PiBGcmVkDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogY2NhbXAtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4+PiBC ZWhhbGYgT2YgIExvdSBCZXJnZXINCj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMywg MjAxMyA5OjA4IEFNDQo+Pj4+PiBUbzogRmF0YWkgWmhhbmcNCj4+Pj4+IENjOiBDQ0FNUDsgZHJh ZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+ PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24NCj4+Pj4+IGRy YWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4NCj4+Pj4+IEZh dGFpLA0KPj4+Pj4NCj4+Pj4+IE9uIDEvMjMvMjAxMyA2OjQ5IEFNLCBGYXRhaSBaaGFuZyB3cm90 ZToNCj4+Pj4+PiBIaSBMb3UsDQo+Pj4+Pj4NCj4+Pj4+PiBGb3IgT0RVZmxleChDQlIpLCB0aGUg Zm9ybXVsYSBpcyBmcm9tIFtHLjcwOS0yMDEyXSBhbmQgaXQNCj4+IGhhcyBiZWVuDQo+Pj4+Pj4g ZGlzY3Vzc2VkIGJlZm9yZSwgc28gcGxlYXNlIHRydXN0IHRoYXQgdGhlcmUgaXMgbm8NCj4+IG9w cG9ydHVuaXR5IGZvcg0KPj4+Pj4+IG1pc2ludGVycHJldGF0aW9uLiAoTm90ZSB0aGF0IHRoZXJl IGFyZSB0d28gY2FzZXMsIG9uZSBpcw0KPj4+Pj4+IE9EVWZsZXgoQ0JSKSBhbmQgYW5vdGhlciBv bmUgaXMgT0RVZmxleChHRlApKS4NCj4+Pj4+Pg0KPj4+Pj4+IEluIGFkZHRpb24sIE9EVWZsZXgg Y2Fubm90IGJlIGNvbmNhdGVuYXRlZCBieSBbRy43MDktMjAxMl0uDQo+Pj4+Pg0KPj4+Pj4gVGhh bmtzIGZvciBjb25maXJtaW5nIG15IHVuZGVyc3RhbmRpbmcuICBUaGlzIHJhaXNlcyB0aGUNCj4+ IHF1ZXN0aW9uIG9mDQo+Pj4+PiBpZiB0aGUgbmV3IHRyYWZmaWMgc2hvdWxkIGp1c3QgYXBwbHkg dG8gT0RVRmxleD8gIENvcnJlY3QNCj4+IG1lIGlmIEknbQ0KPj4+Pj4gd3JvbmcsIGJ1dCBJIGJl bGlldmUgdGhlIFtSRkM0MzI4XSBpcyBzdWZmaWNpZW50IGluIGFsbA0KPj4gb3RoZXIgY2FzZXMu DQo+Pj4+PiBUaGlzIG1heSBhbHNvIG1ha2UgaXQgZWFzaWVyIGZvciBlYXJseSBpbXBsZW1lbnRh dGlvbnMgb2YNCj4+IHRoZSBkcmFmdA0KPj4+Pj4gYXMgdGhlbiB0aGV5IGNhbiBsaW1pdCBjb2Rl IGNoYW5nZXMgZnJvbSB0aGUgKC0wMykgcmV2IHRvDQo+PiBvbmx5IE9EVWZsZXggTFNQcy4NCj4+ Pj4+DQo+Pj4+PiBKdXN0IHRvIGJlIGNsZWFyLCBJJ20gcmVhbGx5IGp1c3QgKmFza2luZyogYWJv dXQgdGhpcy4gIEFzIEkgc2FpZA0KPj4+Pj4gYmVmb3JlLCBJJ20gb3BlbiBvbiBzcGVjaWZpY3Mu Li4NCj4+Pj4+DQo+Pj4+PiBBbnkgdGhvdWdodHMvY29tbWVudHM/IEF1dGhvcnM/ICBJbXBsZW1l bnRvcnM/DQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzLA0KPj4+Pj4gTG91DQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+PiBJIHdpbGwgaXNzdWUgYSBuZXcgdmVyc2lvbiB0b21vcnJvdyB0byBjYXB0dXJlIGFsbCB5 b3VyIGNvbW1lbnRzLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBCZXN0IFJlZ2FyZHMNCj4+Pj4+ Pg0KPj4+Pj4+IEZhdGFpDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5u ZXRdDQo+Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDEzIDI6MTEgQU0NCj4+ Pj4+PiBUbzogRmF0YWkgWmhhbmcNCj4+Pj4+PiBDYzogQ0NBTVA7IGRyYWZ0LWlldGYtY2NhbXAt Z21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6IFJl OiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+IGRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4+DQo+Pj4+Pj4gRmF0YWksDQo+Pj4+ Pj4NCj4+Pj4+PiBPbiAxLzIwLzIwMTMgOTo0MyBQTSwgRmF0YWkgWmhhbmcgd3JvdGU6DQo+Pj4+ Pj4+IEhpIExvdSwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gWW91IHNhaWQ6DQo+Pj4+Pj4+PiBidXQgeW91 J3JlIHNheXMgZW5jb2RlZCBhcyAoTipOb21pbmFsIFJhdGUpIHJpZ2h0PyBXYXQncyB0aGUNCj4+ Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gW0ZhdGFpXSBUaGUgb3JpZ2luYWwgd2F5IChpbiB2ZXJzaW9uIDA0JjA1KSBpcyBwdXR0aW5n DQo+PiAoTiogTm9taW5hbA0KPj4+Pj4+PiBSYXRlKSBpbiAiQml0X1JhdGUiIGZpZWxkIGZvciBP RFVmbGV4KEdGUCksIHRoZSB2YWx1ZSBpcyB0aGF0IHdlDQo+Pj4+Pj4+IGNhbiBnZW5lcmFsaXpl IHRvIGp1c3QgdXNlIG9uZSBzaW5nbGUgIkJpdF9SYXRlIiBmaWVsZCB0byBjYXJyeQ0KPj4+Pj4+ PiBJRUVFIGZsb2F0IG51bWJlciBmb3IgYm90aCBjYXNlcywgaXQgc2VlbXMgdGhhdCB5b3UNCj4+ IGRvbid0IGFncmVlIG9uDQo+Pj4+Pj4+IHRoaXMgdmFsdWUsIDotKQ0KPj4+Pj4+DQo+Pj4+Pj4g SSd2ZSBzZWVuIGRpZmZlcmVuY2VzIGluIGNhbGN1bGF0ZWQgZmxvYXRpbmcgcG9pbnQgdmFsdWVz IGZyb20NCj4+Pj4+PiBkaWZmZXJlbnQgIGltcGxlbWVudGF0aW9ucywgc28gSSBqdXN0IHdhbnQg dG8gZW5zdXJlIHRoYXQNCj4+IHN1Y2ggY2FzZXMNCj4+Pj4+PiBhcmUgYXZvaWRlZC4NCj4+Pj4+ PiBJJ20gb3BlbiB0byBzcGVjaWZpYyBzb2x1dGlvbnMgYW5kIGNlcnRhaW5seSB3aWxsIGRlZmZl ciBvbiB0aGUNCj4+Pj4+PiBzcGVjaWZpY3MgYXNzdW1pbmcgdGhlcmUgaXMgbm8gb3Bwb3J0dW5p dHkgZm9yDQo+Pj4+Pj4gbWlzaW50ZXJwcmV0YXRpb24vaW50ZXJvcCAgaXNzdWVzLiBJIGRvbid0 IHRoaW5rIHRoZQ0KPj4gb3JpZ2luYWwgcGFzc2VkDQo+Pj4+Pj4gdGhpcyB0aHJlc2hvbGQsIGku ZS4sOg0KPj4+Pj4+DQo+Pj4+Pj4gICAgICAgICAgTiA9IENlaWxpbmcgb2YNCj4+Pj4+Pg0KPj4+ Pj4+ICAgIE9EVWZsZXgoQ0JSKSBub21pbmFsIGJpdCByYXRlICogKDEgKyBPRFVmbGV4KENCUikg Yml0IHJhdGUNCj4+Pj4+PiB0b2xlcmFuY2UpDQo+Pj4+Pj4NCj4+Pj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gLS0tLS0t LS0tLQ0KPj4+Pj4+ICAgICAgICBPRFRVay50cyBub21pbmFsIGJpdCByYXRlICogKDEgLSBITyBP UFVrIGJpdCByYXRlDQo+PiB0b2xlcmFuY2UpDQo+Pj4+Pj4NCj4+Pj4+Pj4gLiBUaGVyZWZvcmUs IEkgKHdhcykgYW0gc2F5aW5nIHRoYXQgSSBhbSBnb2luZyB0byBhY2NlcHQgeW91cg0KPj4+Pj4+ PiBzdWdnZXN0aW9uIHRvIGNhcnJ5IE4gZm9yIE9EVWZsZXgoR0ZQKS4gV2UgYXJlDQo+PiBkaXNj dXNzaW5nIHdoZXJlIHRvDQo+Pj4+Pj4+IHB1dCBOIGZvciBPRFVmbGV4KEdGUCkuDQo+Pj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+Pj4gWW91IHNhaWQ6DQo+Pj4+Pj4+PiBiaXRzIGluIHRoZSBjb250cm9s IHBsYW5lIGFyZSBnZW5lcmFsbHkgY2hlYXAsIElNTyBpdCdzDQo+PiBiZXR0ZXIgdG8NCj4+Pj4+ Pj4+IGhhdmUgc2ltcGxlciBlbmNvZGluZyB0aGFuIHRvIG9wdGltaXplIGV2ZXJ5IGJpdCAob3Ig OCBpbiB0aGlzDQo+Pj4+Pj4+PiBjYXNlKS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gW0ZhdGFpXSBPSywg SSB3aWxsIGFkZCBhIG5ldyBmaWVsZCAodG8gb2NjdXB5IHRoZSByZXNlcnZlZCBiaXRzKQ0KPj4+ Pj4+PiB0byBjYXJyeSBOLg0KPj4+Pj4+DQo+Pj4+Pj4gQXMgeW91IHNlZSBmaXQuDQo+Pj4+Pj4N Cj4+Pj4+PiBKdXN0IHRvIGNsYXJpZnkgbXkgdW5kZXJzdGFuZGluZywgT0RVZmxleCBhbmQgVmly dHVhbA0KPj4gY29uY2F0ZW5hdGlvbg0KPj4+Pj4+IGNhbiAgbmV2ZXIgYmUgY29tYmluZWQgZm9y IHRoZSBzYW1lIHNpZ25hbCB0eXBlL2xldmVsLCByaWdodD8NCj4+Pj4+PiAoQWx0aG91Z2ggYW4g IE9EVWZsZXggY2xpZW50IHNpZ25hbCBjb3VsZCBiZSBjYXJyaWVkIG92ZXINCj4+IGEgdmlydHVh bA0KPj4+Pj4+IGNvbmNhdGVuYXRlZCAgT0RVaykuICBJcyB0aGlzIGNvcnJlY3Qgb3IgZGlkIEkg bWlzcyBzb21ldGhpbmcgaW4NCj4+Pj4+PiBHNzA5Pw0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzLA0K Pj4+Pj4+IExvdQ0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJl c3QgUmVnYXJkcw0KPj4+Pj4+Pg0KPj4+Pj4+PiBGYXRhaQ0KPj4+Pj4+Pg0KPj4+Pj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86 bGJlcmdlckBsYWJuLm5ldF0NCj4+Pj4+Pj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDE4LCAyMDEz IDE6NDIgQU0NCj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4+IENjOiBDQ0FNUDsgZHJh ZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+ Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+ PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4+Pj4+Pj4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gMS8xNS8yMDEzIDEwOjE2IFBNLCBGYXRhaSBaaGFu ZyB3cm90ZToNCj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUbyBhdm9pZCBt aXN1bmRlcnN0YW5kaW5nLCBJIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSBtb3JlIG9uIHRoZQ0KPj4+ Pj4+Pj4gZm9sbG93aW5nIHBvaW50Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4g SXQgaXMgYmV0dGVyIHRvIGhhdmUgY29uc2lzdGVudCBmb3JtYXQgYW5kIHRoZSBzYW1lIG1lYW5p bmcNCj4+Pj4+Pj4+Pj4+PiBvZiBvbmUNCj4+Pj4+Pj4gZmllbGQgZm9yIGJvdGggT0RVZmxleChD QlIpIGFuZCBHRlAuIFRoaXMgaXMgd2h5IHdlIGhhdmUgc2VjdGlvbg0KPj4+Pj4+PiA1LjENCj4+ Pj4+Pj4gJjUuMiB0byBkZXNjcmliZSB0aGUgY29tcGxleCBzdHVmZi4NCj4+Pj4+Pj4+Pj4+IEkg YWN0dWFsbHkgd2Fzbid0IHN1Z2dlc3RpbmcgdGhhdCBOIGJlIGNhcnJpZWQgaW4NCj4+IHRoZSBi aXQgcmF0ZQ0KPj4+Pj4+Pj4+Pj4gZmllbGQuDQo+Pj4+Pj4+Pj4+PiBUaGUgYml0IHJhdGUgZmll bGQgY2FuIGVpdGhlciBiZSBzZXQgYXMgZGVzY3JpYmVkIG9yIHRvIHplcm8NCj4+Pj4+Pj4+Pj4+ IChpLmUuLCAgaWdub3JlZCkuICBBdCB0aGUgdGltZSwgSSB3YXMgdGhpbmtpbmcgYWJvdXQNCj4+ IGNhcnJ5aW5nIE4NCj4+Pj4+Pj4+Pj4+IGluIHRoZSAgcmVzZXJ2ZWQgIGZpZWxkLiBCdXQgcGVy aGFwcyB0aGUgcmlnaHQgcGxhY2UNCj4+IGlzIE1ULCBpZg0KPj4+Pj4+Pj4+Pj4gbXkgdW5kZXJz dGFuZGluZyBpcyAgcmlnaHQgICh3b3VsZCBhbHdheXMgYmUgMQ0KPj4gb3RoZXJ3aXNlKS4gSSdt DQo+Pj4+Pj4+Pj4+PiBvcGVuIHRvIGVpdGhlci4uLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g W0ZhdGFpXSBXaHkgbm90IGp1c3QgdXNlICJiaXQgcmF0ZSJmaWVsZCB0byBjYXJyeQ0KPj4gIk4i YmVjYXVzZSAiTiINCj4+Pj4+Pj4+Pj4gaW1wbGllcyBiaXQgcmF0ZT8gIEkgYW0gT0sgaWYgeW91 IGxpa2UgdG8gdXNlIGEgbmV3DQo+PiBmaWxlZCAobGlrZQ0KPj4+Pj4+Pj4+PiAiVFMNCj4+Pj4+ Pj4+Pj4gTnVtYmVyIikgdG8gb2NjdXB5IHRoZSByZXNlcnZlZCBmaWVsZCBldmVuIHRob3VnaA0K Pj4gdGhhdCBJIHByZWZlcg0KPj4+Pj4+Pj4+PiB0aGUgIG9yaWdpbmFsIGFwcHJvYWNoIChpZS4s IHVzZSAiYml0IHJhdGUiZmllbGQgdG8gY2FycnkgIk4iKS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ IEFyZSB5b3UgcHJvcG9zaW5nIGRyb3BwaW5nIGNhcnJ5aW5nIGJpdCByYXRlcw0KPj4gcmVwcmVz ZW50ZWQgYXMgYW4NCj4+Pj4+Pj4+PiBJRUVFICBmbG9hdGluZyBwb2ludCBhbmQganVzdCBjYXJy eWluZyBOIGZvciBPRFVmbGV4Pw0KPj4gVGhpcyBzZWVtcw0KPj4+Pj4+Pj4+IHdvcmthYmxlICB0 byAgbWUsIGJ1dCB3ZSBzaG91bGQgZW5zdXJlIHRoYXQgdGhlcmUgYXJlIG5vDQo+Pj4+Pj4+Pj4g c2lnbmlmaWNhbnQgb2JqZWN0aW9ucy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBbRmF0YWldIFRoZXJl IGFyZSB0d28gdXNhZ2VzIGZvciAiIEJpdF9SYXRlICIgZmllbGQgYXMNCj4+IGRlc2NyaWJlZA0K Pj4+Pj4+Pj4gaW4gdGhlIGxpbmVzIDI4Ny0zMTAuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gKDEpICAg IEZvciBPRFVmbGV4KENCUiksIHRoZSBCaXRfUmF0ZSBmaWVsZCBpbmRpY2F0ZXMNCj4+IHRoZSBu b21pbmFsDQo+Pj4+Pj4+PiBiaXQNCj4+Pj4+Pj4+IHJhdGUgb2YgT0RVZmxleChDQlIpIGV4cHJl c3NlZCBpbiBieXRlcyBwZXIgc2Vjb25kLA0KPj4gZW5jb2RlZCBhcyBhDQo+Pj4+Pj4+PiAzMi1i aXQgIElFRUUgc2luZ2xlIHByZWNpc2lvbiBmbG9hdGluZy1wb2ludCBudW1iZXIuIEZvciB0aGlz DQo+Pj4+Pj4+PiBjYXNlLCB3ZSBNVVNUICB1c2UgIDMyLWJpdCBJRUVFIGZsb2F0aW5nIHBvaW50 IGluc3RlYWQgb2YNCj4+Pj4+Pj4+ICJOIihQbGVhc2Ugc2VlIG1vcmUgaW4gc2VjdGlvbiAgNS4x KS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSSBndWVzcyB5b3UgcmVhbGx5IHN0aWxsIG5lZWQgKHRvIGJl IGJhc2VkIG9uKSB0aGUgY2xpZW50IHNpZ25hbA0KPj4+Pj4+PiByYXRlIGF0IHRoZSBlZGdlcy4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAoMikgICAgRm9yIE9EVWZsZXgoR0ZQKSwgd2Ug Y2FuIGNoYW5nZSB0aGUgdGV4dCAodGhlDQo+PiBsaW5lcyBmcm9tIDMwNQ0KPj4+Pj4+Pj4gdG8N Cj4+Pj4+Pj4+IDMxMCkgYmFzZWQgb24geW91ciBzdWdnZXN0aW9uLCBpZS4sIHRoZSBCaXRfUmF0 ZSBmaWVsZA0KPj4gaXMgdXNlZCB0bw0KPj4+Pj4+Pj4gY2FycnkgICJOInRvIGluZGljYXRlIHRo ZSBub21pbmFsIGJpdCByYXRlIG9mIHRoZSAgT0RVZmxleChHRlApLg0KPj4+Pj4+Pg0KPj4+Pj4+ PiBidXQgeW91J3JlIHNheXMgZW5jb2RlZCBhcyAoTipOb21pbmFsIFJhdGUpIHJpZ2h0PyAgV2F0 J3MgdGhlDQo+Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+Pj4+ Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGVyZWZvcmUsIEkgYW0gcHJvcG9zaW5n IHVzaW5nIG9uZSBzaW5nbGUgZmlsZWQgKCJCaXRfUmF0ZSAiKQ0KPj4+Pj4+Pj4gZm9yIHRoZXNl IHR3byBjYXNlcywgaW4gdGhpcyB3YXksIHdlIGNhbiBsZWF2ZSB0aGUgIlJlc2VydmVkIg0KPj4+ Pj4+Pj4gYml0cyBmb3IgZnV0dXJlLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBiaXRzIGluIHRoZSBjb250 cm9sIHBsYW5lIGFyZSBnZW5lcmFsbHkgY2hlYXAsIElNTyBpdCdzDQo+PiBiZXR0ZXIgdG8NCj4+ Pj4+Pj4gaGF2ZSAgc2ltcGxlciBlbmNvZGluZyB0aGFuIHRvIG9wdGltaXplIGV2ZXJ5IGJpdCAo b3IgOCBpbiB0aGlzDQo+Pj4+Pj4+IGNhc2UpLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBMb3UNCj4+Pj4+ Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBIb3BlIHdlIGFyZSBub3cgYXQgdGhlIHNhbWUgcGFnZS4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gRmF0YWkNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+Pj4gQ0NB TVBAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2NhbXANCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pg0KPj4NCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0 DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j Y2FtcA0K From sergio.belotti@alcatel-lucent.com Wed Jan 30 02:33:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4D721F8788 for ; Wed, 30 Jan 2013 02:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.049 X-Spam-Level: X-Spam-Status: No, score=-7.049 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 m3tv1w5PQdkl for ; Wed, 30 Jan 2013 02:33:27 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id B54B921F878F for ; Wed, 30 Jan 2013 02:33:26 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0UAX6P2015168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Jan 2013 11:33:21 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 30 Jan 2013 11:33:05 +0100 From: "BELOTTI, SERGIO (SERGIO)" To: Fatai Zhang , Daniele Ceccarelli Date: Wed, 30 Jan 2013 11:33:03 +0100 Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZXCuS8hTs+eckmWtA0MM2hSFphf/XWAgAAfDYCAAAYXgIAA5eIAgACK3mCAABq0cA== Message-ID: References: <5106DED0.3090008@labn.net> <4A1562797D64E44993C5CBF38CF1BE48074CE1@ESESSMB301.ericsson.se> <51081AAF.8030601@labn.net> <4A1562797D64E44993C5CBF38CF1BE4807506B@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: CCAMP Subject: [CCAMP] R: Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 10:33:28 -0000 SGkgRmF0YWksDQogVGhpcyBpcyB0cnVlIGJ1dCBjbGVhcmx5IHdvdWxkIG5vdCBtYXRjaCBvbmUg b2YgeW91ciBtb3RpdmF0aW9uIG9mIHByZWZlcmVuY2UgLi50aGF0IGluIGZhY3QgSSBzaGFyZQ0K DQoiKDMpIEkgZG9uJ3QgdGhpbmsgb3B0aW9uIDMmNCBhcmUgYmV0dGVyIHRoYW4gb3B0aW9uIDEm MiBmb3IgaW50ZXJ3b3JraW5nIHdpdGggZWFybHkgaW1wbGVtZW50YXRpb25zLg0KDQpMZWF2ZSBh cGFydCBvdGhlciB3b3JrIG9uIHJvdXRpbmcgZm9yIHdoaWNoICwgd2l0aCBEYW5pZWxlLCB3ZSBz cGVudCB0aW1lIGluIHRoZXNlIG1vbnRocy4NClNvIEkgd291bGQgYWdhaW4gcHVzaCBmb3IgT3B0 aW9uIDIuDQoNCkNoZWVycw0KU2VyZ2lvDQoNCg0KDQpCZWxvdHRpIFNlcmdpbyAtIFN5c3RlbSBB cmNoaXRlY3QNCkFMQ0FURUwtTFVDRU5UICBPcHRpY3MgRGl2aXNpb24NCg0KLS0tLS1NZXNzYWdn aW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2Nh bXAtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEZhdGFpIFpoYW5nDQpJbnZpYXRvOiBt ZXJjb2xlZMOsIDMwIGdlbm5haW8gMjAxMyA5LjU4DQpBOiBEYW5pZWxlIENlY2NhcmVsbGk7IExv dSBCZXJnZXINCkNjOiBDQ0FNUA0KT2dnZXR0bzogUmU6IFtDQ0FNUF0gUG9sbCBvbiBPRFVGbGV4 LXJlbGF0ZWQgZW5jb2RpbmcgKHdhczogV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uIGRyYWZ0LWll dGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNCkNCg0KSGkgRGFuaWVsZSBhbmQgTG91 LA0KDQpUbyBhdm9pZCB3b3JrIGJhY2sgYW5kIGZvcnRoLCBJIHdvdWxkIHBvaW50IG91dCB0aGF0 IHdlIGNhbiBzdGlsbCBnZXQgdGhlIGNvaW5jaWRlbmNlIGJldHdlZW4gc2lnbmFsaW5nIGFuZCBy b3V0aW5nIGlmIHdlIGFkb3B0IG9wdGlvbiAzIGFuZCBjaGFuZ2Ugcm91dGluZyBkcmFmdC4NCg0K DQoNCg0KDQpCZXN0IFJlZ2FyZHMNCg0KRmF0YWkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWxlIENlY2NhcmVsbGkNClNlbnQ6IFdlZG5lc2Rh eSwgSmFudWFyeSAzMCwgMjAxMyA0OjM2IFBNDQpUbzogTG91IEJlcmdlcg0KQ2M6IENDQU1QDQpT dWJqZWN0OiBSZTogW0NDQU1QXSBQb2xsIG9uIE9EVUZsZXgtcmVsYXRlZCBlbmNvZGluZyAod2Fz OiBXRyBMYXN0IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxp bmctZzcwOXYzLTA0KQ0KDQpMb3UsDQoNCml0IHdhcyByZWFsbHkganVzdCBhIGpva2UsIG5vIGhp ZGRlbiBtZWFuaW5ncy4NCklmIHdlIGZpbmQgYSByZWFzb25hYmxlIHNvbHV0aW9uIGZvciBzaWdu YWxpbmcgdGhhdCBpbXBsaWVzIG1vZGlmaWNhdGlvbnMgdG8gdGhlIHJvdXRpbmcgd2Ugd2lsbCBt b2RpZnkgdGhlIHJvdXRpbmcgdG9vIChoZXJlIEkgYWdyZWUgd2l0aCBGcmVkIHRoYXQgYWxpZ25t ZW50IGJldHdlZW4gc2lnbmFsaW5nIGFuZCByb3V0aW5nIGlzIGEgU0hPVUxELCBpZiBub3QgYSBN VVNUKS4NCg0KSW5kZXBuZGVudGx5IGZyb20gY2hhbmdlcyB0byB0aGUgcm91dGluZyBpIHN0aWxs IGJlbGlldmUgdGhhdCBvcHRpb24gMiBpcyB0aGUgbW9zdCByZWFzb25hYmxlLiBUaGUgZmFjdCB0 aGF0IGl0IGlzIG9uZSBvZiB0aGUgb3B0aW9ucyB0aGF0IGRvZXMgbm90IGltcGx5IGNoYW5nZXMg dG8gdGhlIHJvdXRpbmcgaXMganVzdCBhIGNvaW5jaWRlbmNlLg0KDQpUaGFua3MsDQpEYW5pZWxl DQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IExvdSBCZXJnZXIgW21haWx0 bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPlNlbnQ6IG1hcnRlZMOsIDI5IGdlbm5haW8gMjAxMyAxOS41 NA0KPlRvOiBEYW5pZWxlIENlY2NhcmVsbGkNCj5DYzogQ0NBTVANCj5TdWJqZWN0OiBSZTogW0ND QU1QXSBQb2xsIG9uIE9EVUZsZXgtcmVsYXRlZCBlbmNvZGluZyAod2FzOiBXRw0KPkxhc3QgQ2Fs bCBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQp DQo+DQo+RGFuaWVsZSwNCj4gICAgICAgSm9raW5nIGFzaWRlLCBJIHRoaW5rIGl0IG1heSBhZGQg dmFsdWUgdG8gdGhlDQo+ZGlzY3Vzc2lvbiB0byBoaWdobGlnaHQgeW91ciByYXRpb25hbCBmb3Ig bm90IHdhbnRpbmcgdG8NCj5jaGFuZ2Ugcm91dGluZy4gIChZb3UgYXJlIGFmdGVyIGFsbCB0aGUg ZWRpdG9yIG9mIHRoZSByb3V0aW5nIGRyYWZ0LikNCj4NCj5JcyBpdDoNCj4tIEp1c3QgYXZvaWRp bmcgd29yayBmb3IgdGhlIGVkaXRvciAoaS5lLiwgeW91ciBqb2tlLi4uKT8NCj4tIE1pbmltaXpp bmcgYSBjaGFuZ2UgYXQgdGhpcyBsYXRlIGRhdGU/DQo+LSBNaW5pbWl6aW5nIGltcGFjdCBvbiBh biBlYXJseSBpbXBsZW1lbnRhdGlvbj8NCj4tIFNvbWV0aGluZyBjb21wbGV0ZWx5IGRpZmZlcmVu dD8NCj4NCj5JZiB5b3UgZG9uJ3QgbWluZCBzaGFyaW5nLi4uDQo+DQo+VGhhbmtzLA0KPkxvdQ0K Pg0KPk9uIDEvMjkvMjAxMyAxOjMxIFBNLCBEYW5pZWxlIENlY2NhcmVsbGkgd3JvdGU6DQo+PiBP cHRpb24gMiBmb3IgbWUgdG9vLg0KPj4NCj4+IE1haW4gcmVhc29uPyBJIGRvbid0IGhhdmUgdG8g Y2hhbmdlIHRoZSByb3V0aW5nIElEISA6LSkNCj4uLi5vYnZpb3VzbHkgam9raW5nLg0KPj4NCj4+ IE90aGVyIHJlYXNvbnM/IEFncmVlIHdpdGggRmF0YWkgYW5kIFphZmFyLiBBbmQgcHJlZmVyIDIp IHRvDQo+MSkgYmVjYXVzZSBkZWZpbmVzIGEgbmV3IEMtdHlwZS4NCj4+DQo+PiBCUg0KPj4gRGFu aWVsZQ0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IGNjYW1w LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+ IEJlaGFsZiBPZiBaYWZhciBBbGkgKHphbGkpDQo+Pj4gU2VudDogbWFydGVkw6wgMjkgZ2VubmFp byAyMDEzIDE3LjQxDQo+Pj4gVG86IExvdSBCZXJnZXI7IENDQU1QDQo+Pj4gU3ViamVjdDogUmU6 IFtDQ0FNUF0gUG9sbCBvbiBPRFVGbGV4LXJlbGF0ZWQgZW5jb2RpbmcgKHdhczogV0cgTGFzdA0K Pj4+IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcw OXYzLTA0KQ0KPj4+DQo+Pj4gSGkgTG91LCBDLWNhbXBlcnM6DQo+Pj4NCj4+PiBJIHdvdWxkIHBp Y2sgT3B0aW9uIDI7IGl0J3MgY2xlYW5lciBhbmQgIGFkZHJlc3NlcyB0aGUNCj5pc3N1ZSByZWxh dGVkDQo+Pj4gdG8gb3ZlcmxvYWRpbmcgdGhlIHNhbWUgYy10eXBlLg0KPj4+DQo+Pj4gVGhhbmtz DQo+Pj4NCj4+PiBSZWdhcmRz4oCmWmFmYXINCj4+Pg0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiAibGJlcmdlckBsYWJuLm5ldCIgPGxiZXJnZXJAbGFibi5u ZXQ+DQo+Pj4gRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDEzIDM6MjUgUE0NCj4+PiBUbzog ImNjYW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+DQo+Pj4gU3ViamVjdDogW0NDQU1QXSBQ b2xsIG9uIE9EVUZsZXgtcmVsYXRlZCBlbmNvZGluZyAod2FzOiBXRw0KPkxhc3QgQ2FsbA0KPj4+ IGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNCkN Cj4+Pg0KPj4+PiBBbGwsDQo+Pj4+ICAgIFdlIHdvdWxkIGxpa2UgdG8gdHJ5IHRvIGNsb3NlIHRo ZSBkaXNjdXNzaW9uIG9uIHRoZQ0KPj4+IEcuNzA5IGRyYWZ0cyBzbw0KPj4+PiB0aGF0IHdlIGNh biBtb3ZlIHJhcGlkbHkgdG93YXJkcyBwdWJsaWNhdGlvbiByZXF1ZXN0LiAgVGhlDQo+Pj4+IGRp c2N1c3Npb24gb2YgKG9uZSBvZiBteSkgTEMgY29tbWVudHMgaGFzIHJlc3VsdGVkIGluIHNldmVy YWwNCj4+Pj4gb3B0aW9ucyBmb3IgdGhlIHNpZ25hbGluZyBPRFUtcmVsYXRlZCB0cmFmZmljIHBh cmFtZXRlcnMsIGFuZCB0aGUNCj4+Pj4gcG9pbnQgaGFzDQo+Pj4gYmVlbiByYWlzZWQNCj4+Pj4g dGhhdCByZWFsaWduaW5nIHJvdXRpbmcgd2l0aCBzaWduYWxpbmcgc2hvdWxkIGJlIGRpc2N1c3Nl ZC4NCj4+Pj4NCj4+Pj4gUGxlYXNlIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBvYmplY3RpdmUgb2Yg YW55IFBTIGlzDQo+Pj4+IGludGVyb3BlcmFiaWxpdHksIGFuZCB0aGF0IHRoZXJlIG1heSBiZSBl YXJseQ0KPmltcGxlbWVudGF0aW9ucyB0aGF0IG1hdGNoIGc3MDl2My0wNC4NCj4+Pj4NCj4+Pj4g VGhlIGJhc2ljIHF1ZXN0aW9uIGlzIG9uZSBvZiBpZiBOLCB0aGUgbnVtYmVyIG9mIHRpbWUgc2xv dHMgbmVlZGVkDQo+Pj4+IHRvIHN1cHBvcnQgYSBPRFVmbGV4KEdGUCkgc2lnbmFsLCBzaG91bGQg YmUgY2FycmllZCBhcyBhDQo+Y2FsY3VsYXRlZCBJRUVFDQo+Pj4+IGZsb2F0aW5nIHBvaW50IG51 bWJlciBvciBkaXJlY3RseS4gICBPcHRpb25zIDEgYW5kIDIgYmVsb3cNCj5yZWZsZWN0IHRoZQ0K Pj4+PiBmb3JtZXIsIG9wdGlvbnMgMyBhbmQgNCBtYXRjaCB0aGUgbGF0dGVyLiAgSXQgaXMgd29y dGggbm90aW5nDQo+Pj4gdGhhdCBvbmx5DQo+Pj4+IG9wdGlvbnMgMSBhbmQgMiBhcmUgcHJvcG9z ZWQgZm9yIE9EVWZsZXgoR0ZQKSwgaS5lLiwgTiBtdXN0IGJlDQo+Pj4+IGNhbGN1bGF0ZWQgZm9y IE9EVWZsZXgoQ0JSKSBzaWduYWwgdHlwZXMgd2l0aCBhbGwgb3B0aW9ucy4NCj4+Pj4NCj4+Pj4g UGxlYXNlIHN0YXRlIHlvdXIgc3VwcG9ydCBmb3Igb25lIHRoZSBvcHRpb25zIGFuZCwgaWYgeW91 DQo+d2lzaCwgdGhlDQo+Pj4+IGp1c3RpZmljYXRpb24gZm9yIHlvdXIgcG9zaXRpb246DQo+Pj4+ DQo+Pj4+IDEpIEZvbGxvdyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMt MDQNCj4+Pj4gICBpLmUuLCByZWRlZmluZSBbUkZDNDMyOF0gVHJhZmZpYyBQYXJhbWV0ZXJzIGMt dHlwZSB3aGVuIHVzZWQgd2l0aA0KPj4+PiAgIE9UTi1URE0gbGFiZWxzLiBPRFVmbGV4KEdGUCkg bnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cyAoTikgaXMNCj4+Pj4gICBlbmNvZGVkIGFzOg0KPj4+ Pg0KPj4+PiAgIC4uLiB0aGUgQml0X1JhdGUgZmllbGQgZm9yIE9EVWZsZXgoR0ZQKSBNVVNUDQo+ Pj4+ICAgZXF1YWwgdG8gb25lIG9mIHRoZSA4MCB2YWx1ZXMgbGlzdGVkIGJlbG93Og0KPj4+Pg0K Pj4+PiAgICAgICAxICogT0RVMi50czsgMiAqIE9EVTIudHM7IC4uLjsgOCAqIE9EVTIudHM7DQo+ Pj4+ICAgICAgIDkgKiBPRFUzLnRzOyAxMCAqIE9EVTMudHMsIC4uLjsgMzIgKiBPRFUzLnRzOw0K Pj4+PiAgICAgICAzMyAqIE9EVTQudHM7IDM0ICogT0RVNC50czsgLi4uOyA4MCAqIE9EVTQudHMu DQo+Pj4+DQo+Pj4+IDIpIEZvbGxvdyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1n NzA5djMtMDUNCj4+Pj4gICBpLmUuLCB1c2UgYSBuZXcgQy10eXBlIGZvciBPVE4tVERNIGxhYmVs cy4gIEVuY29kaW5nIGRldGFpbHMNCj4+Pj4gICB1bmNoYW5nZWQgZnJvbSBnNzA5djMtMDQuDQo+ Pj4+ICAgKFRoaXMgb3B0aW9uIGFkZHJlc3NlcyB0aGUgaXNzdWUgb2YgdGhlIHNhbWUgYy10eXBl IG5lZWRpbmcgdG8NCj4+Pj4gICAgYmUgcGFyc2VkIGJhc2VkIG9uIGxhYmVsL3N3aXRjaGluZyB0 eXBlLikNCj4+Pj4NCj4+Pj4gMykgRm9sbG93IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFs aW5nLWc3MDl2My0wNg0KPj4+PiAgIGkuZS4sICB1c2UgYSBuZXcgQy10eXBlIGZvciBPVE4tVERN IGxhYmVscy4gTiBpcyBkaXJlY3RseSBjYXJyaWVkDQo+Pj4+ICAgZm9yIE9EVWZsZXgoR0ZQKSBv bmx5Lg0KPj4+Pg0KPj4+PiA0KSBEaXNjdXNzZWQsIGJ1dCBub3QgaW4gYW55IGRyYWZ0DQo+Pj4+ ICAgVXNlIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNCBlbmNvZGlu ZyBmb3IgYWxsDQo+Pj4+ICAgYnV0IE9EVWZsZXgoR0ZQKSwgYW5kIGRlZmluZSBuZXcgT0RVZmxl eChHRlApIHNwZWNpZmljIFRyYWZmaWMNCj4+Pj4gICBQYXJhbWV0ZXJzIGJhc2VkIG9uIGc3MDl2 My0wNiwgcHJlc3VtYWJseSB3aXRoIHVudXNlZCBmaWVsZHMNCj4+Pj4gICByZW1vdmVkLg0KPj4+ PiAgIChUaGlzIGFsc28gYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiB0aGUgc2FtZSBjLXR5cGUgbmVl ZGluZyB0byBiZQ0KPj4+PiAgICBwYXJzZWQgYmFzZWQgb24gbGFiZWwgdHlwZSwgYnV0IG1lYW5z IHRoZXJlIGFyZSBkaWZmZXJlbnQgdHlwZXMNCj4+Pj4gICAgYmFzZWQgb24gc2lnbmFsIHR5cGUu KQ0KPj4+Pg0KPj4+PiBPcHRpb24gMSBhbmQgMiBkbyBub3QgaW1wbHkgYW55IGNoYW5nZXMgdG8g cm91dGluZywgd2hpbGUNCj4+PiBvcHRpb25zIDMgYW5kDQo+Pj4+IDQgbWF5LiAgUm91dGluZyBp bXBsaWNhdGlvbnMgd2lsbCBiZSBkaXNjdXNzZWQgYmFzZWQgb24gdGhlDQo+Pj4gcmVzdWx0cyBv Zg0KPj4+PiB0aGlzIHBvbGwsIGFuZCBvbmx5IGlmIHRoZXJlIGlzIGNvbnNlbnN1cyB0byBzdXBw b3J0DQo+cG9zaXRpb25zIDMgb3IgNC4NCj4+Pj4NCj4+Pj4gV2UgaG9wZSB0byBtYWtlIGEgY29u c2Vuc3VzIGNhbGwgYnkgdGhlIGVuZCBvZiB0aGUgd2VlaywgYnV0IHdpbGwNCj4+Pj4gY29udGlu dWUgdGhlIGRpc2N1c3Npb24gYXMgbmVlZGVkLg0KPj4+Pg0KPj4+PiBNdWNoIHRoYW5rcywNCj4+ Pj4gTG91IChhbmQgRGVib3JhaCkNCj4+Pj4NCj4+Pj4gT24gMS8yOC8yMDEzIDU6MDggQU0sIERh bmllbGUgQ2VjY2FyZWxsaSB3cm90ZToNCj4+Pj4+ICBBbGwsDQo+Pj4+Pg0KPj4+Pj4gSSB0aGlu ayB0aGUgY2hhbmdlcyBwcm9wb3NlZCBhcmUgbWVhbmluZ2Z1bCBhbmQgd291bGQNCj4+PiBzdXBw b3J0IHRoZW0gaW4NCj4+Pj4+IGFuIGluZGl2aWR1YWwgb3IgZWFybHkgV0cgZHJhZnQsIGJ1dCB0 aGV5IGRvbid0IHNlZW0gdG8gcHJvdmlkZQ0KPj4+Pj4gc2lnbmlmaWNhdGl2ZSBhZHZhbnRhZ2Vz IHRvIHJpc2sgaW50ZXJ3b3JraW5nIGlzc3VlcyB3aXRoIGVhcmx5DQo+Pj4+PiBpbXBsZW1lbnRh dGlvbnMuDQo+Pj4+PiBNb3Jlb3ZlciB0aGUgY2hhbmdlcyBkb24ndCBhbGxvdyB1cyBnZXR0aW5n IHRvdGFsbHkgcmlkIG9mIG9mIHRoZQ0KPj4+Pj4gYml0X3JhdGUgZmllbGQgYXMgaXQgaXMgc3Rp bGwgbmVlZGVkIGZvciBPRFVmbGV4IChDQlIpLg0KPj4+Pj4NCj4+Pj4+IE15IDJjDQo+Pj4+PiBE YW5pZWxlDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+Pj4+IEZyb206IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxpQGNpc2NvLmNvbV0NCj4+ Pj4+PiBTZW50OiBsdW5lZMOsIDI4IGdlbm5haW8gMjAxMyA0LjQ3DQo+Pj4+Pj4gVG86IExvdSBC ZXJnZXINCj4+Pj4+PiBDYzogR3J1bWFuLCBGcmVkOyBGYXRhaSBaaGFuZzsgRGFuaWVsZSBDZWNj YXJlbGxpOyBDQ0FNUDsNCj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1n NzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0 IENhbGwgY29tbWVudHMgb24NCj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGlu Zy1nNzA5djMtMDQNCj4+Pj4+Pg0KPj4+Pj4+IEhpIExvdS0NCj4+Pj4+Pg0KPj4+Pj4+IFBsZWFz ZSBzZWUgaW4tbGluZS4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcw0KPj4+Pj4+DQo+Pj4+Pj4gUmVn YXJkcy4uLlphZmFyDQo+Pj4+Pj4NCj4+Pj4+PiBPbiAxLzI3LzEzIDk6NDYgUE0sICJMb3UgQmVy Z2VyIiA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+Pj4gWmFmYXIsDQo+ Pj4+Pj4+ICAgICAgICAgSXMgeW91ciBjb21tZW50IHdpdGggcmVzcGVjdCB0byBqdXN0IHJvdXRp bmcgb3IgYm90aA0KPj4+Pj4+IHNpZ25hbGluZyBhbmQNCj4+Pj4+Pj4gcm91dGluZz8NCj4+Pj4+ Pg0KPj4+Pj4+IEJvdGgsIGluY2x1ZGluZyBjb25zaXN0ZW5jeSBiZXR3ZWVuIHNpZ25hbGluZyBh bmQgcm91dGluZw0KPj4+IGF0dHJpYnV0ZXMuDQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQWxz bywgd2hlbiB5b3Ugc2F5ICJpbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZHJhZnQgdmVyc2lvbnMi LA0KPj4+Pj4+IGRvIHRoZXNlDQo+Pj4+Pj4+IGltcGxlbWVudGF0aW9ucyBpbmNsdWRlIHN1cHBv cnQgZm9yIE9EVWZsZXg/ICAoV2hpY2ggaGFzIHJlYWxseQ0KPj4+Pj4+PiBiZWVuIHRoZSBmb2N1 cyBvZiB0aGUgZGlzY3Vzc2lvbi4pDQo+Pj4+Pj4NCj4+Pj4+PiBZZXMsIEkgd2FzIHJlZmVycmlu ZyB0byBPRFVGbGV4LiBBcyB5b3Uga25vdywgZml4ZWQgT0RVIGlzDQo+Pj4gc2lnbmFsZWQNCj4+ Pj4+PiB2aWEgbGV2ZWwgKDAgQlcpIHNvIGl0cyBub3QgYW4gaXNzdWUuDQo+Pj4+Pj4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gQlRXIEkgdG9vayBGcmVkJ3MgY29tbWVudHMgYXMgcmVsYXRlZCB0byBqdXN0 IHRoZSBuZXcNCj4+Pj4+PiBPVE4tc3BlY2lmaWMgSVNDRA0KPj4+Pj4+PiBkZWZpbml0aW9ucyAo c2VjdGlvbiA0LjEuMiBvZiBvc3BmLWc3MDl2My0wNSwgaW4NCj4+PiBwYXJ0aWN1bGFyKS4gIE5v dGUNCj4+Pj4+Pj4gdGhhdCBzZWN0aW9uIDQuMS4xIGFscmVhZHkgY2FycmllcyBOIChudW1iZXIg b2YgT0RVcykgbm90DQo+Pj4+Pj4gSUVFRSBmbG9hdGluZw0KPj4+Pj4+PiBwb2ludCByZXByZXNl bnRhdGlvbnMgb2YgYXZhaWxhYmxlIGJhbmR3aWR0aC4NCj4+Pj4+Pg0KPj4+Pj4+IFdoYXQgSSBt ZWFudCBpcyBVbnJlc2VydmVkIEJhbmR3aWR0aCBhdCBwcmlvcml0eSB4IGFuZCBNYXggTFNQDQo+ Pj4+Pj4gQmFuZHdpZHRoIGF0IHByaW9yaXR5IHguDQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g TXVjaCB0aGFua3MsDQo+Pj4+Pj4+IExvdQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiAxLzI3LzIwMTMg Nzo0NiBQTSwgWmFmYXIgQWxpICh6YWxpKSB3cm90ZToNCj4+Pj4+Pj4+IEFsbC0NCj4+Pj4+Pj4+ DQo+Pj4+Pj4+PiBUaGlzIGltcGFjdHMgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGJhc2VkIG9u IGRyYWZ0DQo+Pj4gdmVyc2lvbnMgKGFuZA0KPj4+Pj4+Pj4gaGVuY2UgaW50ZXJvcCB3aXRoIHRo ZXNlIGltcGxlbWVudGF0aW9ucyBtb3ZpbmcgZm9yd2FyZCkuDQo+Pj4+Pj4gSU1PIHRoaXMgaXMN Cj4+Pj4+Pj4+IGEgYmlnZ2VyIGNoYW5nZSBmb3IgdXMgdG8gYXNzdW1lIGF0IHRoZSBsYXN0IGNh bGwgc3RhZ2UuDQo+Pj4+Pj4gRnVydGhlcm1vcmUNCj4+Pj4+Pj4+IHdlIGhhdmUgYmVlbiB1c2lu ZyBJRUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCBmb3IgVW5yZXNlcnZlZA0KPj4+Pj4+Pj4gQmFu ZHdpZHRoLyBNYXggTFNQIEJXIGluIElFRUUgZmxvYXRpbmcgcG9pbnQgZm9ybWF0IGZvciBvdGhl cg0KPj4+Pj4+Pj4gdGVjaG5vbG9naWVzLiBPdmVyYWxsLCBJIHRoaW5rIHRoaXMgY2hhbmdlIHN1 ZmZlcnMgZnJvbSB0aGUNCj4+Pj4+PiAibGF3IG9mIGRpbWluaXNoaW5nIHJldHVybnMiLg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IFRoYW5rcw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFJlZ2FyZHMgxaAgWmFm YXINCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gMS8yNy8xMyAxMDoyOCBBTSwgIkdy dW1hbiwgRnJlZCINCj4+Pj4+PiA8ZnJlZC5ncnVtYW5AdXMuZnVqaXRzdS5jb20+IHdyb3RlOg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBIaSBMb3UsIEZhdGFpLCBEYW5pZWxlLA0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gSSB1bmRlcnN0YW5kIHRoZSBsYXRlc3QgY2hhbmdlIHRvIHRoZSB3YXkgYmFuZHdp ZHRoIGlzDQo+Pj4+Pj4gc2lnbmFsZWQgZm9yDQo+Pj4+Pj4+Pj4gT0RVZmxleChHRlApLCBpLmUu LCBzaWduYWxpbmcgdGhlIG51bWJlciBvZiB0cmlidXRhcnkgc2xvdHMNCj4+Pj4+PiBOIGluc3Rl YWQNCj4+Pj4+Pj4+PiBvZiAgdGhlIGJhbmR3aWR0aCByYXRlIGluIGJwcy4gIEkgYmVsaWV2ZSB0 aGF0IHRoaXMNCj5zaW1wbGlmaWVzDQo+Pj4+Pj4+Pj4gdGhlIHNpZ25hbGluZyAgYW5kIGludGVy b3BlcmFiaWxpdHkgc28gSSdtIGluIGFncmVlbWVudCB3aXRoDQo+Pj4+Pj4gdGhpcyBjaGFuZ2Uu DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBIb3dldmVyLCBpdCBzZWVtcyB3ZSBhcmUgbm93IGluY29u c2lzdGVudCBiZXR3ZWVuIGhvdyB3ZQ0KPj4+Pj4+IHJlcHJlc2VudA0KPj4+Pj4+Pj4+IGJhbmR3 aWR0aCBpbiByb3V0aW5nIGFuZCBzaWduYWxpbmcgZm9yIE9EVWZsZXgoR0ZQKS4gIFJvdXRpbmcN Cj4+Pj4+Pj4+PiBhZHZlcnRpc2VzICB0aGUgYmFuZHdpZHRoIHVzaW5nIGEgZmxvYXRpbmcgcG9p bnQNCj5yZXByZXNlbnRhdGlvbg0KPj4+Pj4+Pj4+IG9mIGJhbmR3aWR0aCwgd2hpbGUgIHNpZ25h bGluZyBpcyB1c2luZyB0aGUgbnVtYmVyIG9mDQo+Pj4gdHJpYnV0YXJ5IHNsb3RzLg0KPj4+Pj4+ Pj4+IEl0IHNlZW1zIHRoZSBzYW1lICBiZW5lZml0cyB3b3VsZCBiZSBvYnRhaW5lZCBieQ0KPj4+ Pj4+IGFkdmVydGlzaW5nIHRoZSBtYXgNCj4+Pj4+Pj4+PiBMU1AgYmFuZHdpZHRoIGFuZCAgdW5y ZXNlcnZlZCBiYW5kd2lkdGggZm9yIE9EVWZsZXgoR0ZQKSBpbg0KPj4+Pj4+IHRlcm1zIG9mDQo+ Pj4+Pj4+Pj4gdGhlIG51bWJlciBvZiB0cmlidXRhcnkgIHNsb3RzLg0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4gRnJlZA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gRnJvbTogY2NhbXAtYm91bmNlc0Bp ZXRmLm9yZw0KPlttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+Pj4+Pj4+PiBC ZWhhbGYgT2YgIExvdSBCZXJnZXINCj4+Pj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkg MjMsIDIwMTMgOTowOCBBTQ0KPj4+Pj4+Pj4+IFRvOiBGYXRhaSBaaGFuZw0KPj4+Pj4+Pj4+IENj OiBDQ0FNUDsNCj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djNAdG9v bHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0IENhbGwg Y29tbWVudHMgb24NCj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1n NzA5djMtMDQNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEZhdGFpLA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gT24gMS8yMy8yMDEzIDY6NDkgQU0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4+Pj4+PiBI aSBMb3UsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEZvciBPRFVmbGV4KENCUiksIHRoZSBmb3Jt dWxhIGlzIGZyb20gW0cuNzA5LTIwMTJdIGFuZCBpdA0KPj4+Pj4+IGhhcyBiZWVuDQo+Pj4+Pj4+ Pj4+IGRpc2N1c3NlZCBiZWZvcmUsIHNvIHBsZWFzZSB0cnVzdCB0aGF0IHRoZXJlIGlzIG5vDQo+ Pj4+Pj4gb3Bwb3J0dW5pdHkgZm9yDQo+Pj4+Pj4+Pj4+IG1pc2ludGVycHJldGF0aW9uLiAoTm90 ZSB0aGF0IHRoZXJlIGFyZSB0d28gY2FzZXMsIG9uZSBpcw0KPj4+Pj4+Pj4+PiBPRFVmbGV4KENC UikgYW5kIGFub3RoZXIgb25lIGlzIE9EVWZsZXgoR0ZQKSkuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IEluIGFkZHRpb24sIE9EVWZsZXggY2Fubm90IGJlIGNvbmNhdGVuYXRlZCBieSBbRy43MDkt MjAxMl0uDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaGFua3MgZm9yIGNvbmZpcm1pbmcgbXkgdW5k ZXJzdGFuZGluZy4gIFRoaXMgcmFpc2VzIHRoZQ0KPj4+Pj4+IHF1ZXN0aW9uIG9mDQo+Pj4+Pj4+ Pj4gaWYgdGhlIG5ldyB0cmFmZmljIHNob3VsZCBqdXN0IGFwcGx5IHRvIE9EVUZsZXg/ICBDb3Jy ZWN0DQo+Pj4+Pj4gbWUgaWYgSSdtDQo+Pj4+Pj4+Pj4gd3JvbmcsIGJ1dCBJIGJlbGlldmUgdGhl IFtSRkM0MzI4XSBpcyBzdWZmaWNpZW50IGluIGFsbA0KPj4+Pj4+IG90aGVyIGNhc2VzLg0KPj4+ Pj4+Pj4+IFRoaXMgbWF5IGFsc28gbWFrZSBpdCBlYXNpZXIgZm9yIGVhcmx5IGltcGxlbWVudGF0 aW9ucyBvZg0KPj4+Pj4+IHRoZSBkcmFmdA0KPj4+Pj4+Pj4+IGFzIHRoZW4gdGhleSBjYW4gbGlt aXQgY29kZSBjaGFuZ2VzIGZyb20gdGhlICgtMDMpIHJldiB0bw0KPj4+Pj4+IG9ubHkgT0RVZmxl eCBMU1BzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSnVzdCB0byBiZSBjbGVhciwgSSdtIHJlYWxs eSBqdXN0ICphc2tpbmcqIGFib3V0IHRoaXMuDQo+Pj4gQXMgSSBzYWlkDQo+Pj4+Pj4+Pj4gYmVm b3JlLCBJJ20gb3BlbiBvbiBzcGVjaWZpY3MuLi4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEFueSB0 aG91Z2h0cy9jb21tZW50cz8gQXV0aG9ycz8gIEltcGxlbWVudG9ycz8NCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+PiBMb3UNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+IEkgd2lsbCBpc3N1ZSBhIG5ldyB2ZXJzaW9uIHRvbW9ycm93IHRvIGNhcHR1cmUgYWxs DQo+Pj4geW91ciBjb21tZW50cy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g QmVzdCBSZWdhcmRzDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+ Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPj4+Pj4+Pj4+ PiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgMjoxMSBBTQ0KPj4+Pj4+Pj4+PiBU bzogRmF0YWkgWmhhbmcNCj4+Pj4+Pj4+Pj4gQ2M6IENDQU1QOw0KPj4+Pj4+Pj4+PiBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+ Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+Pj4+ Pj4+IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+PiBGYXRhaSwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gT24gMS8yMC8yMDEz IDk6NDMgUE0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4gSGkgTG91LA0KPj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFlvdSBzYWlkOg0KPj4+Pj4+Pj4+Pj4+IGJ1dCB5b3UncmUgc2F5 cyBlbmNvZGVkIGFzIChOKk5vbWluYWwgUmF0ZSkgcmlnaHQ/DQo+V2F0J3MgdGhlDQo+Pj4+Pj4+ Pj4+Pj4gdmFsdWUgb2YgIHRoaXMgdnMganVzdCBjYXJyeWluZyBOPw0KPj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+IFtGYXRhaV0gVGhlIG9yaWdpbmFsIHdheSAoaW4gdmVyc2lvbiAwNCYwNSkgaXMg cHV0dGluZw0KPj4+Pj4+IChOKiBOb21pbmFsDQo+Pj4+Pj4+Pj4+PiBSYXRlKSBpbiAiQml0X1Jh dGUiIGZpZWxkIGZvciBPRFVmbGV4KEdGUCksIHRoZQ0KPnZhbHVlIGlzIHRoYXQNCj4+Pj4+Pj4+ Pj4+IHdlIGNhbiBnZW5lcmFsaXplIHRvIGp1c3QgdXNlIG9uZSBzaW5nbGUgIkJpdF9SYXRlIg0K PmZpZWxkIHRvDQo+Pj4+Pj4+Pj4+PiBjYXJyeSBJRUVFIGZsb2F0IG51bWJlciBmb3IgYm90aCBj YXNlcywgaXQgc2VlbXMgdGhhdCB5b3UNCj4+Pj4+PiBkb24ndCBhZ3JlZSBvbg0KPj4+Pj4+Pj4+ Pj4gdGhpcyB2YWx1ZSwgOi0pDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEkndmUgc2VlbiBkaWZm ZXJlbmNlcyBpbiBjYWxjdWxhdGVkIGZsb2F0aW5nIHBvaW50DQo+dmFsdWVzIGZyb20NCj4+Pj4+ Pj4+Pj4gZGlmZmVyZW50ICBpbXBsZW1lbnRhdGlvbnMsIHNvIEkganVzdCB3YW50IHRvIGVuc3Vy ZSB0aGF0DQo+Pj4+Pj4gc3VjaCBjYXNlcw0KPj4+Pj4+Pj4+PiBhcmUgYXZvaWRlZC4NCj4+Pj4+ Pj4+Pj4gSSdtIG9wZW4gdG8gc3BlY2lmaWMgc29sdXRpb25zIGFuZCBjZXJ0YWlubHkgd2lsbA0K Pj4+IGRlZmZlciBvbiB0aGUNCj4+Pj4+Pj4+Pj4gc3BlY2lmaWNzIGFzc3VtaW5nIHRoZXJlIGlz IG5vIG9wcG9ydHVuaXR5IGZvcg0KPj4+Pj4+Pj4+PiBtaXNpbnRlcnByZXRhdGlvbi9pbnRlcm9w ICBpc3N1ZXMuIEkgZG9uJ3QgdGhpbmsgdGhlDQo+Pj4+Pj4gb3JpZ2luYWwgcGFzc2VkDQo+Pj4+ Pj4+Pj4+IHRoaXMgdGhyZXNob2xkLCBpLmUuLDoNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gICAg ICAgICAgTiA9IENlaWxpbmcgb2YNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gICAgT0RVZmxleChD QlIpIG5vbWluYWwgYml0IHJhdGUgKiAoMSArIE9EVWZsZXgoQ0JSKSBiaXQgcmF0ZQ0KPj4+Pj4+ Pj4+PiB0b2xlcmFuY2UpDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4gLS0tLS0t LS0tLQ0KPj4+Pj4+Pj4+PiAgICAgICAgT0RUVWsudHMgbm9taW5hbCBiaXQgcmF0ZSAqICgxIC0g SE8gT1BVayBiaXQgcmF0ZQ0KPj4+Pj4+IHRvbGVyYW5jZSkNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+IC4gVGhlcmVmb3JlLCBJICh3YXMpIGFtIHNheWluZyB0aGF0IEkgYW0gZ29pbmcgdG8NCj5h Y2NlcHQgeW91cg0KPj4+Pj4+Pj4+Pj4gc3VnZ2VzdGlvbiB0byBjYXJyeSBOIGZvciBPRFVmbGV4 KEdGUCkuIFdlIGFyZQ0KPj4+Pj4+IGRpc2N1c3Npbmcgd2hlcmUgdG8NCj4+Pj4+Pj4+Pj4+IHB1 dCBOIGZvciBPRFVmbGV4KEdGUCkuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4gWW91IHNhaWQ6DQo+Pj4+Pj4+Pj4+Pj4gYml0cyBpbiB0aGUgY29udHJvbCBwbGFuZSBhcmUg Z2VuZXJhbGx5IGNoZWFwLCBJTU8gaXQncw0KPj4+Pj4+IGJldHRlciB0bw0KPj4+Pj4+Pj4+Pj4+ IGhhdmUgc2ltcGxlciBlbmNvZGluZyB0aGFuIHRvIG9wdGltaXplIGV2ZXJ5IGJpdCAob3INCj4+ PiA4IGluIHRoaXMNCj4+Pj4+Pj4+Pj4+PiBjYXNlKS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ PiBbRmF0YWldIE9LLCBJIHdpbGwgYWRkIGEgbmV3IGZpZWxkICh0byBvY2N1cHkgdGhlIHJlc2Vy dmVkDQo+Pj4+Pj4+Pj4+PiBiaXRzKSB0byBjYXJyeSBOLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBBcyB5b3Ugc2VlIGZpdC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSnVzdCB0byBjbGFyaWZ5 IG15IHVuZGVyc3RhbmRpbmcsIE9EVWZsZXggYW5kIFZpcnR1YWwNCj4+Pj4+PiBjb25jYXRlbmF0 aW9uDQo+Pj4+Pj4+Pj4+IGNhbiAgbmV2ZXIgYmUgY29tYmluZWQgZm9yIHRoZSBzYW1lIHNpZ25h bCB0eXBlL2xldmVsLCByaWdodD8NCj4+Pj4+Pj4+Pj4gKEFsdGhvdWdoIGFuICBPRFVmbGV4IGNs aWVudCBzaWduYWwgY291bGQgYmUgY2FycmllZCBvdmVyDQo+Pj4+Pj4gYSB2aXJ0dWFsDQo+Pj4+ Pj4+Pj4+IGNvbmNhdGVuYXRlZCAgT0RVaykuICBJcyB0aGlzIGNvcnJlY3Qgb3IgZGlkIEkgbWlz cw0KPj4+IHNvbWV0aGluZyBpbg0KPj4+Pj4+Pj4+PiBHNzA5Pw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4+IExvdQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4gRmF0YWkNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRv OmxiZXJnZXJAbGFibi5uZXRdDQo+Pj4+Pj4+Pj4+PiBTZW50OiBGcmlkYXksIEphbnVhcnkgMTgs IDIwMTMgMTo0MiBBTQ0KPj4+Pj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4+Pj4+PiBD YzogQ0NBTVA7DQo+Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1n NzA5djNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdH IExhc3QgQ2FsbCBjb21tZW50cyBvbg0KPj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1zaWduYWxpbmctZzcwOXYzLTA0DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+PiBPbiAxLzE1LzIwMTMgMTA6MTYgUE0sIEZhdGFpIFpoYW5nIHdyb3Rl Og0KPj4+Pj4+Pj4+Pj4+IEhpIExvdSwNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFRvIGF2 b2lkIG1pc3VuZGVyc3RhbmRpbmcsIEkgd291bGQgbGlrZSB0byBjbGFyaWZ5DQo+Pj4gbW9yZSBv biB0aGUNCj4+Pj4+Pj4+Pj4+PiBmb2xsb3dpbmcgcG9pbnQuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+PiBJdCBpcyBiZXR0ZXIgdG8gaGF2ZSBjb25zaXN0ZW50 IGZvcm1hdCBhbmQgdGhlIHNhbWUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gbWVhbmluZyBvZiBvbmUNCj4+ Pj4+Pj4+Pj4+IGZpZWxkIGZvciBib3RoIE9EVWZsZXgoQ0JSKSBhbmQgR0ZQLiBUaGlzIGlzIHdo eSB3ZSBoYXZlDQo+Pj4+Pj4+Pj4+PiBzZWN0aW9uDQo+Pj4+Pj4+Pj4+PiA1LjENCj4+Pj4+Pj4+ Pj4+ICY1LjIgdG8gZGVzY3JpYmUgdGhlIGNvbXBsZXggc3R1ZmYuDQo+Pj4+Pj4+Pj4+Pj4+Pj4g SSBhY3R1YWxseSB3YXNuJ3Qgc3VnZ2VzdGluZyB0aGF0IE4gYmUgY2FycmllZCBpbg0KPj4+Pj4+ IHRoZSBiaXQgcmF0ZQ0KPj4+Pj4+Pj4+Pj4+Pj4+IGZpZWxkLg0KPj4+Pj4+Pj4+Pj4+Pj4+IFRo ZSBiaXQgcmF0ZSBmaWVsZCBjYW4gZWl0aGVyIGJlIHNldCBhcyBkZXNjcmliZWQgb3IgdG8NCj4+ Pj4+Pj4+Pj4+Pj4+PiB6ZXJvIChpLmUuLCAgaWdub3JlZCkuICBBdCB0aGUgdGltZSwgSSB3YXMN Cj50aGlua2luZyBhYm91dA0KPj4+Pj4+IGNhcnJ5aW5nIE4NCj4+Pj4+Pj4+Pj4+Pj4+PiBpbiB0 aGUgIHJlc2VydmVkICBmaWVsZC4gQnV0IHBlcmhhcHMgdGhlIHJpZ2h0IHBsYWNlDQo+Pj4+Pj4g aXMgTVQsIGlmDQo+Pj4+Pj4+Pj4+Pj4+Pj4gbXkgdW5kZXJzdGFuZGluZyBpcyAgcmlnaHQgICh3 b3VsZCBhbHdheXMgYmUgMQ0KPj4+Pj4+IG90aGVyd2lzZSkuIEknbQ0KPj4+Pj4+Pj4+Pj4+Pj4+ IG9wZW4gdG8gZWl0aGVyLi4uDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IFtGYXRh aV0gV2h5IG5vdCBqdXN0IHVzZSAiYml0IHJhdGUiZmllbGQgdG8gY2FycnkNCj4+Pj4+PiAiTiJi ZWNhdXNlICJOIg0KPj4+Pj4+Pj4+Pj4+Pj4gaW1wbGllcyBiaXQgcmF0ZT8gIEkgYW0gT0sgaWYg eW91IGxpa2UgdG8gdXNlIGEgbmV3DQo+Pj4+Pj4gZmlsZWQgKGxpa2UNCj4+Pj4+Pj4+Pj4+Pj4+ ICJUUw0KPj4+Pj4+Pj4+Pj4+Pj4gTnVtYmVyIikgdG8gb2NjdXB5IHRoZSByZXNlcnZlZCBmaWVs ZCBldmVuIHRob3VnaA0KPj4+Pj4+IHRoYXQgSSBwcmVmZXINCj4+Pj4+Pj4+Pj4+Pj4+IHRoZSAg b3JpZ2luYWwgYXBwcm9hY2ggKGllLiwgdXNlICJiaXQgcmF0ZSJmaWVsZA0KPj4+IHRvIGNhcnJ5 ICJOIikuDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IEFyZSB5b3UgcHJvcG9zaW5nIGRy b3BwaW5nIGNhcnJ5aW5nIGJpdCByYXRlcw0KPj4+Pj4+IHJlcHJlc2VudGVkIGFzIGFuDQo+Pj4+ Pj4+Pj4+Pj4+IElFRUUgIGZsb2F0aW5nIHBvaW50IGFuZCBqdXN0IGNhcnJ5aW5nIE4gZm9yIE9E VWZsZXg/DQo+Pj4+Pj4gVGhpcyBzZWVtcw0KPj4+Pj4+Pj4+Pj4+PiB3b3JrYWJsZSAgdG8gIG1l LCBidXQgd2Ugc2hvdWxkIGVuc3VyZSB0aGF0IHRoZXJlIGFyZSBubw0KPj4+Pj4+Pj4+Pj4+PiBz aWduaWZpY2FudCBvYmplY3Rpb25zLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gW0ZhdGFp XSBUaGVyZSBhcmUgdHdvIHVzYWdlcyBmb3IgIiBCaXRfUmF0ZSAiIGZpZWxkIGFzDQo+Pj4+Pj4g ZGVzY3JpYmVkDQo+Pj4+Pj4+Pj4+Pj4gaW4gdGhlIGxpbmVzIDI4Ny0zMTAuDQo+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+PiAoMSkgICAgRm9yIE9EVWZsZXgoQ0JSKSwgdGhlIEJpdF9SYXRlIGZp ZWxkIGluZGljYXRlcw0KPj4+Pj4+IHRoZSBub21pbmFsDQo+Pj4+Pj4+Pj4+Pj4gYml0DQo+Pj4+ Pj4+Pj4+Pj4gcmF0ZSBvZiBPRFVmbGV4KENCUikgZXhwcmVzc2VkIGluIGJ5dGVzIHBlciBzZWNv bmQsDQo+Pj4+Pj4gZW5jb2RlZCBhcyBhDQo+Pj4+Pj4+Pj4+Pj4gMzItYml0ICBJRUVFIHNpbmds ZSBwcmVjaXNpb24gZmxvYXRpbmctcG9pbnQgbnVtYmVyLg0KPj4+IEZvciB0aGlzDQo+Pj4+Pj4+ Pj4+Pj4gY2FzZSwgd2UgTVVTVCAgdXNlICAzMi1iaXQgSUVFRSBmbG9hdGluZyBwb2ludCBpbnN0 ZWFkIG9mDQo+Pj4+Pj4+Pj4+Pj4gIk4iKFBsZWFzZSBzZWUgbW9yZSBpbiBzZWN0aW9uICA1LjEp Lg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEkgZ3Vlc3MgeW91IHJlYWxseSBzdGlsbCBuZWVk ICh0byBiZSBiYXNlZCBvbikgdGhlIGNsaWVudA0KPj4+Pj4+Pj4+Pj4gc2lnbmFsIHJhdGUgYXQg dGhlIGVkZ2VzLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICgyKSAg ICBGb3IgT0RVZmxleChHRlApLCB3ZSBjYW4gY2hhbmdlIHRoZSB0ZXh0ICh0aGUNCj4+Pj4+PiBs aW5lcyBmcm9tIDMwNQ0KPj4+Pj4+Pj4+Pj4+IHRvDQo+Pj4+Pj4+Pj4+Pj4gMzEwKSBiYXNlZCBv biB5b3VyIHN1Z2dlc3Rpb24sIGllLiwgdGhlIEJpdF9SYXRlIGZpZWxkDQo+Pj4+Pj4gaXMgdXNl ZCB0bw0KPj4+Pj4+Pj4+Pj4+IGNhcnJ5ICAiTiJ0byBpbmRpY2F0ZSB0aGUgbm9taW5hbCBiaXQg cmF0ZSBvZiB0aGUNCj4+PiBPRFVmbGV4KEdGUCkuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4g YnV0IHlvdSdyZSBzYXlzIGVuY29kZWQgYXMgKE4qTm9taW5hbCBSYXRlKSByaWdodD8NCj5XYXQn cyB0aGUNCj4+Pj4+Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gVGhlcmVm b3JlLCBJIGFtIHByb3Bvc2luZyB1c2luZyBvbmUgc2luZ2xlIGZpbGVkDQo+Pj4gKCJCaXRfUmF0 ZSAiKQ0KPj4+Pj4+Pj4+Pj4+IGZvciB0aGVzZSB0d28gY2FzZXMsIGluIHRoaXMgd2F5LCB3ZSBj YW4gbGVhdmUgdGhlDQo+IlJlc2VydmVkIg0KPj4+Pj4+Pj4+Pj4+IGJpdHMgZm9yIGZ1dHVyZS4N Cj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBiaXRzIGluIHRoZSBjb250cm9sIHBsYW5lIGFyZSBn ZW5lcmFsbHkgY2hlYXAsIElNTyBpdCdzDQo+Pj4+Pj4gYmV0dGVyIHRvDQo+Pj4+Pj4+Pj4+PiBo YXZlICBzaW1wbGVyIGVuY29kaW5nIHRoYW4gdG8gb3B0aW1pemUgZXZlcnkgYml0IChvcg0KPj4+ IDggaW4gdGhpcw0KPj4+Pj4+Pj4+Pj4gY2FzZSkuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4g TG91DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gSG9wZSB3ZSBhcmUg bm93IGF0IHRoZSBzYW1lIHBhZ2UuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gRmF0YWkNCj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+PiBDQ0FN UCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+PiBDQ0FNUEBpZXRmLm9yZw0KPj4+Pj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IENDQU1Q IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4NCj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4g Q0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pg0KPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0 DQo+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NjYW1wDQo+Pj4NCj4+DQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NB TVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAN Cg== From giomarti@cisco.com Wed Jan 30 06:55:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C50021F8A03 for ; Wed, 30 Jan 2013 06:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 UdC0BcUok4Xx for ; Wed, 30 Jan 2013 06:55:18 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 555A721F84C2 for ; Wed, 30 Jan 2013 06:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3234; q=dns/txt; s=iport; t=1359557718; x=1360767318; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Vll296foxtcKbp5O+s4kGljEARUecGlV+NvBAD/DFBU=; b=fCm6tSR8vjs6pPfMYw5mRnbQtq94IF1g1548s78yQvHJ8HGgTcsYf3sn RCqQvOTO31OAJ7424uVOmCQb/lHcI0PcSY3nmEBoprVN0l4TEvR5k3lxZ CsTYUYWLxfo7/Ohp8St2ZGtVpYELATm42Bf3HwVf0WfPXU6BC67MBCIl0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPozCVGtJXHA/2dsb2JhbABFgkm8SxZzgh8BAQQBAQFrCxACAQgEHh0HJwsUEQEBBA4FCIgJDMFbBI0PgxphA6ZYgneBbzU X-IronPort-AV: E=Sophos;i="4.84,569,1355097600"; d="scan'208,217";a="170534552" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jan 2013 14:55:18 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0UEtHLO000438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jan 2013 14:55:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 08:55:17 -0600 From: "Giovanni Martinelli (giomarti)" To: "BRUNGARD, DEBORAH A" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: Ac36Y0THF366bQJXRBinToGRQUxfKQEyNbOA Date: Wed, 30 Jan 2013 14:55:16 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D246CCC@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.172.227] Content-Type: multipart/alternative; boundary="_000_0D7F95913F470A4B83AB5F5833A4390D246CCCxmbrcdx14ciscocom_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:55:22 -0000 --_000_0D7F95913F470A4B83AB5F5833A4390D246CCCxmbrcdx14ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable yes/support ~G On Jan 24, 2013, at 19:47 , "BRUNGARD, DEBORAH A" > wrote: All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g =93yes/support=94 or =93no/do not support=94. If indicating no, please st= ate your technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR =93still being documen= ted=94. Thanks, Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_0D7F95913F470A4B83AB5F5833A4390D246CCCxmbrcdx14ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable yes/support

~G

On Jan 24, 2013, at 19:47 , "BRUNGARD, DEBORAH A" <db3546@att.com> wrote:

All,
 
This is start a two week poll on making draft-ali-ccamp-te-metric-reco= rding-03 a ccamp working group document. Please send email to the list indi= cating =93yes/support=94 or =93no/do not support=94. If indicating no, plea= se state your technical reservations with the document.
 
The poll ends Thursday, Feb. 7th.
 
Note, as stated by some of the authors, there is IPR =93still being do= cumented=94.
 
Thanks,
Deborah and Lou
 
 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.or= g/mailman/listinfo/ccamp

--_000_0D7F95913F470A4B83AB5F5833A4390D246CCCxmbrcdx14ciscocom_-- From giomarti@cisco.com Wed Jan 30 06:56:05 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7138D21F8A9B for ; Wed, 30 Jan 2013 06:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 BFkTdo1hRnex for ; Wed, 30 Jan 2013 06:56:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DAF9D21F8A68 for ; Wed, 30 Jan 2013 06:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3215; q=dns/txt; s=iport; t=1359557765; x=1360767365; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=96979uKrIdz3swQRWM4ssJ3koBFWanpoyVfLIfHeAXk=; b=DhutDmMTQ+r/T01tbIJ/pcgTMVXyHemT2EMORJUGz3J+XQun4vtnpK6Q 7lbzf6ucVwYigDr4PxyrDuN95jWNn/xKhtfurXzco80TWT8io/FL1rsNZ p2UEcSI95GHBp4yJ9ppNcINB8q1RDUfco6wpeGeHaDJq/iZUxdfHO4iER s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPozCVGtJV2Z/2dsb2JhbABFgkm8SxZzgh8BAQQBAQFrCxACAQgEHh0HJwsUEQEBBA4FCIgJDMFbBI0PgxphA6ZYgneBbzU X-IronPort-AV: E=Sophos;i="4.84,569,1355097600"; d="scan'208,217";a="170534971" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jan 2013 14:56:04 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0UEu4iP008445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jan 2013 14:56:04 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 08:56:04 -0600 From: "Giovanni Martinelli (giomarti)" To: "BRUNGARD, DEBORAH A" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document Thread-Index: Ac36YpzyB19srrPaSouArquCC8tVHQEyZqkA Date: Wed, 30 Jan 2013 14:56:04 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D246CDF@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.172.227] Content-Type: multipart/alternative; boundary="_000_0D7F95913F470A4B83AB5F5833A4390D246CDFxmbrcdx14ciscocom_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:56:05 -0000 --_000_0D7F95913F470A4B83AB5F5833A4390D246CDFxmbrcdx14ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable yes/support ~G On Jan 24, 2013, at 19:42 , "BRUNGARD, DEBORAH A" > wrote: All, This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-0= 2 a ccamp working group document. Please send email to the list indicating = =93yes/support=94 or =93no/do not support=94. If indicating no, please stat= e your technical reservations with the document. The poll ends Thursday, January 31st. Note, as stated by some of the authors, IPR has been disclosed in complianc= e with IETF IPR rules. Thanks, Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_0D7F95913F470A4B83AB5F5833A4390D246CDFxmbrcdx14ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable yes/support

~G

On Jan 24, 2013, at 19:42 , "BRUNGARD, DEBORAH A" <db3546@att.com> wrote:

All,
 
This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobj= ect-02 a ccamp working group document. Please send email to the list indica= ting =93yes/support=94 or =93no/do not support=94. If indicating no, please= state your technical reservations with the document.
 
The poll ends Thursday, January 31st.
 
Note, as stated by some of the authors, IPR has been disclosed in comp= liance with IETF IPR rules.
 
Thanks,
Deborah and Lou
 
 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.or= g/mailman/listinfo/ccamp

--_000_0D7F95913F470A4B83AB5F5833A4390D246CDFxmbrcdx14ciscocom_-- From mkattan@cisco.com Wed Jan 30 06:59:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899A121F872D for ; Wed, 30 Jan 2013 06:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 BmBQmH8EM7re for ; Wed, 30 Jan 2013 06:59:25 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DE97B21F86AE for ; Wed, 30 Jan 2013 06:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7879; q=dns/txt; s=iport; t=1359557965; x=1360767565; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7Sk71BKNCOIlYXwly1r1X+aTzp2fL14yYkgOAp/x2D8=; b=DP0WMMnwlc1P/B6VgK/vn89AeFL9JCDhYVje1c+AwvLlNnEphbaCH6RU FVNS8kxsptzATMPgwUdmiD2dF4PXRkl7MARx7JwLCiKDkc3Nr1JSOPkvs D004shhW4M+GBwEg5PBk1mRI0eYsn+5GofiVV47tv0PrGdFpjvRDpmFkP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPozCVGtJXG//2dsb2JhbABFgkm8SxZzgh4BAQEEAQEBKkELEAIBCBEEAQELHQcnCxQJCAEBBA4FCIgJDMFbBI0PgxphA6ZYgneBbzU X-IronPort-AV: E=Sophos;i="4.84,569,1355097600"; d="scan'208,217";a="170505203" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 30 Jan 2013 14:59:22 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0UExMx9019508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jan 2013 14:59:22 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.20]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 08:59:21 -0600 From: "Moustafa Kattan (mkattan)" To: "Giovanni Martinelli (giomarti)" , "BRUNGARD, DEBORAH A" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: Ac36Y0THF366bQJXRBinToGRQUxfKQEyNbOAAAxv00A= Date: Wed, 30 Jan 2013 14:59:21 +0000 Message-ID: <62F90F515D6344418F40C9828AF3AAB8236C16@xmb-aln-x14.cisco.com> References: <0D7F95913F470A4B83AB5F5833A4390D246CCC@xmb-rcd-x14.cisco.com> In-Reply-To: <0D7F95913F470A4B83AB5F5833A4390D246CCC@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.38.218] Content-Type: multipart/alternative; boundary="_000_62F90F515D6344418F40C9828AF3AAB8236C16xmbalnx14ciscocom_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:59:26 -0000 --_000_62F90F515D6344418F40C9828AF3AAB8236C16xmbalnx14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, support. From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= iovanni Martinelli (giomarti) Sent: Wednesday, January 30, 2013 6:55 PM To: BRUNGARD, DEBORAH A Cc: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 = WG document yes/support ~G On Jan 24, 2013, at 19:47 , "BRUNGARD, DEBORAH A" > wrote: All, This is start a two week poll on making draft-ali-ccamp-te-metric-recording= -03 a ccamp working group document. Please send email to the list indicatin= g "yes/support" or "no/do not support". If indicating no, please state your= technical reservations with the document. The poll ends Thursday, Feb. 7th. Note, as stated by some of the authors, there is IPR "still being documente= d". Thanks, Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_62F90F515D6344418F40C9828AF3AAB8236C16xmbalnx14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, support.<= /span>

 <= /p>

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Giovanni Martinelli (giomarti)
Sent: Wednesday, January 30, 2013 6:55 PM
To: BRUNGARD, DEBORAH A
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-record= ing-03 WG document

 

yes/support

 

~G

 

On Jan 24, 2013, at 19:47 , "BRUNGARD, DEBORAH = A" <db3546@att.com> wrote:=



All,

 

This is start a two week poll on making= draft-ali-ccamp-te-metric-recording-03 a ccamp working group document. Ple= ase send email to the list indicating “yes/support” or “n= o/do not support”. If indicating no, please state your technical reservat= ions with the document.

 

The poll ends Thursday, Feb= . 7th.

 

Note, as stated by some of the authors,= there is IPR “still being documented”.

 

Thanks,

Deborah and Lou

 

 

_____________________________________= __________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.or= g/mailman/listinfo/ccamp

 

--_000_62F90F515D6344418F40C9828AF3AAB8236C16xmbalnx14ciscocom_-- From ry-matsunaga@kddi.com Wed Jan 30 20:33:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16A721F862B for ; Wed, 30 Jan 2013 20:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=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 U0GIDx3bMUmN for ; Wed, 30 Jan 2013 20:33:35 -0800 (PST) Received: from UTMC1102.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 107D521F8626 for ; Wed, 30 Jan 2013 20:33:34 -0800 (PST) Received: from UTMC1132 (unknown [10.5.16.195]) by UTMC1102.kddi.com (Postfix) with SMTP id 4027A1D63; Thu, 31 Jan 2013 13:33:33 +0900 (JST) Received: from UTMC1123.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id D64BB1A8A; Thu, 31 Jan 2013 13:33:30 +0900 (JST) Received: from LTMC1005.kddi.com (unknown [10.5.16.216]) by UTMC1123.kddi.com (Postfix) with ESMTP id BAA9819A8; Thu, 31 Jan 2013 13:33:30 +0900 (JST) Received: from LTMC1005.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id r0V4XUo8007357; Thu, 31 Jan 2013 13:33:30 +0900 Received: from LTMC1005.kddi.com.mid_14576103 (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id r0V4NT9k031249; Thu, 31 Jan 2013 13:23:29 +0900 Received: from KDDI-1202PC0731 ([10.200.130.5] [10.200.130.5]) by post-zip.kddi.com with ESMTPA; Thu, 31 Jan 2013 13:23:29 +0900 To: db3546@att.com From: Ryuji Matsunaga References: <201301311315.EDC60163.LVBtLFJNL@kddi.com> In-Reply-To: <201301311315.EDC60163.LVBtLFJNL@kddi.com> Message-Id: <201301311323.HGG12436.tHOVBZUTBBNS@kddi.com> X-Mailer: Winbiff [Version 2.51 PL4] X-Accept-Language: ja,en,zh Date: Thu, 31 Jan 2013 13:23:29 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-SA-MID: 14576103 X-WAuditID: 1301311333310000218337 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WGdocument X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ry-matsunaga@kddi.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 04:33:35 -0000 yes/support Regards, Ryuji Matsunaga > From: "BRUNGARD, DEBORAH A" > To: "ccamp@ietf.org" > Cc: > Subject: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp- > subobject-02 a WGdocument > Date: Thu, 24 Jan 2013 18:42:51 +0000 > > > > All, > > This is start a two week poll on making draft-ali-ccamp-xro-lsp- > subobject-02 a ccamp working group document. Please send email > to the list indicating "yes/support" or "no/do not support". If > indicating no, please state your technical reservations with the > document. > > The poll ends Thursday, January 31st. > > Note, as stated by some of the authors, IPR has been disclosed > in compliance with IETF IPR rules. > > Thanks, > Deborah and Lou > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > ------- End of Forwarded Message > > > > All, > > This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. > > The poll ends Thursday, January 31st. > > Note, as stated by some of the authors, IPR has been disclosed in compliance with IETF IPR rules. > > Thanks, > Deborah and Lou > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > -- Ryuji Matsunaga e-mail:ry-matsunaga@kddi.com Tel:080-5070-9666 --------------------------------------------------------------- $BCm0U!'$3$NEE;R%a!<%k$K$O!"(BKDDI$B3t<02qpJs$,4^$^$l$F$$$k(B $B>l9g$,M-$j$^$9!#@5<0$J%a!<%kl9g!"%a!<%kJ#@=!"(B $B!!!!!!:FG[?.$^$?$O>pJs$N;HMQ$r8G$/6X$8$F$*$j$^$9!#(B $B%(%i! X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69CE21F86DA for ; Wed, 30 Jan 2013 20:33:43 -0800 (PST) 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=1.300, BAYES_00=-2.599, 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 2qciC4kfqzk0 for ; Wed, 30 Jan 2013 20:33:43 -0800 (PST) Received: from UTMC1104.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8E121F86D2 for ; Wed, 30 Jan 2013 20:33:42 -0800 (PST) Received: from UTMC1131 (unknown [10.5.16.192]) by UTMC1104.kddi.com (Postfix) with SMTP id 49BA428F4; Thu, 31 Jan 2013 13:33:42 +0900 (JST) Received: from UTMC1124.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 9EAD41C4B; Thu, 31 Jan 2013 13:33:36 +0900 (JST) Received: from LTMC1005.kddi.com (unknown [10.5.16.216]) by UTMC1124.kddi.com (Postfix) with ESMTP id 79F881C0F; Thu, 31 Jan 2013 13:33:36 +0900 (JST) Received: from LTMC1005.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id r0V4Xa9o007441; Thu, 31 Jan 2013 13:33:36 +0900 Received: from LTMC1005.kddi.com.mid_14576111 (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id r0V4NZMl031326; Thu, 31 Jan 2013 13:23:35 +0900 Received: from KDDI-1202PC0731 ([10.200.130.5] [10.200.130.5]) by post-zip.kddi.com with ESMTPA; Thu, 31 Jan 2013 13:23:34 +0900 To: db3546@att.com From: Ryuji Matsunaga References: <201301311314.AFH04154.LFNBLLVtJ@kddi.com> In-Reply-To: <201301311314.AFH04154.LFNBLLVtJ@kddi.com> Message-Id: <201301311323.DIG30296.StNZTUOBVBBH@kddi.com> X-Mailer: Winbiff [Version 2.51 PL4] X-Accept-Language: ja,en,zh Date: Thu, 31 Jan 2013 13:23:34 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-SA-MID: 14576111 X-WAuditID: 1301311333360000113763 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WGdocument X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ry-matsunaga@kddi.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 04:33:43 -0000 yes/support Regards, Ryuji Matsunaga > From: "BRUNGARD, DEBORAH A" > To: "ccamp@ietf.org" > Cc: > Subject: [CCAMP] Poll on making draft-ali-ccamp-te-metric- > recording-03 WGdocument > Date: Thu, 24 Jan 2013 18:47:33 +0000 > > > > All, > > This is start a two week poll on making draft-ali-ccamp-te- > metric-recording-03 a ccamp working group document. Please send > email to the list indicating "yes/support" or "no/do not support > ". If indicating no, please state your technical reservations > with the document. > > The poll ends Thursday, Feb. 7th. > > Note, as stated by some of the authors, there is IPR "still > being documented". > > Thanks, > Deborah and Lou > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > ------- End of Forwarded Message > > > > All, > > This is start a two week poll on making draft-ali-ccamp-te-metric-recording-03 a ccamp working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. > > The poll ends Thursday, Feb. 7th. > > Note, as stated by some of the authors, there is IPR "still being documented". > > Thanks, > Deborah and Lou > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > -- Ryuji Matsunaga e-mail:ry-matsunaga@kddi.com Tel:080-5070-9666 --------------------------------------------------------------- $BCm0U!'$3$NEE;R%a!<%k$K$O!"(BKDDI$B3t<02qpJs$,4^$^$l$F$$$k(B $B>l9g$,M-$j$^$9!#@5<0$J%a!<%kl9g!"%a!<%kJ#@=!"(B $B!!!!!!:FG[?.$^$?$O>pJs$N;HMQ$r8G$/6X$8$F$*$j$^$9!#(B $B%(%i! X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160ED21F86CA for ; Wed, 30 Jan 2013 21:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3VX+tlrCitL for ; Wed, 30 Jan 2013 21:31:09 -0800 (PST) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6968221F86C8 for ; Wed, 30 Jan 2013 21:31:09 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0328.009; Wed, 30 Jan 2013 21:31:08 -0800 From: Iftekhar Hussain To: "db3546@att.com" Thread-Topic: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document Thread-Index: AQHN/tMUcKt/ygq+p0u2yJO9wrgT1Zhi6ebg Date: Thu, 31 Jan 2013 05:31:08 +0000 Message-ID: References: <5108E5B2.5000807@cisco.com> In-Reply-To: <5108E5B2.5000807@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 05:31:10 -0000 Yes/support Regards, Iftekhar (2013/01/25 3:47), BRUNGARD, DEBORAH A wrote: > All, > This is start a two week poll on making draft-ali-ccamp-te-metric-recordi= ng-03 a ccamp working group document. Please send email to the list indicat= ing "yes/support" or "no/do not support". If indicating no, please state yo= ur technical reservations with the document. > The poll ends Thursday, Feb^. 7th. > Note, as stated by some of the authors, there is IPR "still being documen= ted". > Thanks, > Deborah and Lou >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From dieter.beller@alcatel-lucent.com Thu Jan 31 04:52:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3173121F8510 for ; Thu, 31 Jan 2013 04:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.791 X-Spam-Level: X-Spam-Status: No, score=-8.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8] 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 22DRw8Vy3dMW for ; Thu, 31 Jan 2013 04:52:58 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1A44821F84E9 for ; Thu, 31 Jan 2013 04:52:57 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0VCqVRX020641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Jan 2013 13:52:50 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 31 Jan 2013 13:52:38 +0100 Received: from [149.204.106.184] (135.239.27.12) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 Jan 2013 13:52:38 +0100 Message-ID: <510A6915.9040000@alcatel-lucent.com> Date: Thu, 31 Jan 2013 13:52:37 +0100 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A" References: In-Reply-To: X-SubSwitch: [CCAMP]; [CCAMP] Content-Type: multipart/related; boundary="------------060706010300040305080800" X-Originating-IP: [135.239.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-xro-lsp-subobject-02 a WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 12:52:59 -0000 --------------060706010300040305080800 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit yes/support


Thanks,
Dieter
On 24.01.2013 19:42, BRUNGARD, DEBORAH A wrote:
All,
This is start a two week poll on making draft-ali-ccamp-xro-lsp-subobject-02 a ccamp working group document. Please send email to the list indicating 搚es/support or 搉o/do not support. If indicating no, please state your technical reservations with the document.
The poll ends Thursday, January 31st.
Note, as stated by some of the authors, IPR has been disclosed in compliance with IETF IPR rules.
Thanks,
Deborah and Lou

--

DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) Hans-J鰎g Daub Dr. Rainer Fechner Andreas Gehe

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.
--------------060706010300040305080800 Content-Type: image/jpeg; name="Corporate-sig-logo.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Corporate-sig-logo.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoL EAACAQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOh sfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5 OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX 2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRx CEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVW N4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiI mKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A3+Pfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69 1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvnsm0T1ExVp4aKgx+P pIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBVRQWdjhVBPl09 bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnDsnYeNhlS t353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs6eNO xxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ 7Acje43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BIN KHjT7QSPl1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3 PH4/Pq/b0eT0e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT 51rSnRWch3x82aXqD5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7 jxFdV1j4TJaq6J6L7a/lkQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1 +i9/YvC0VVt7r6j2f9umY7C/jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4K Yys7u617g3DtL45dIN8iev44/kN1HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWp jPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72i yUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfPqn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0d L3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkFWRjEDeM1aInut0WtK46Hyr7F+REPyX2R 1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvWb0i7jz1LWYYx1K5iFkpWMrKQhgZZ PdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh1/HTdgdV0u+MRhIO0YOz5aBN t4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0HFV/Gyr6SrN75T5Mnsfb0 E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/In5+r8YMp2ZT/AAAo JPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6Pfut0WtK4+zox q9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNESRCCZCQv utUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9ppiTtr KyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y 8h8B8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm 1HVSyx+/dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr 5+uzTrn9ttjaeJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b3 10AfkPsCeDoPqKv3bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaH yVl787t2HP8AGeli6R2R1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoW YI8c6BPdaoKcc9BLi++PnVU9IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq 0W8o6WTC9mVWJ29j8dkP4JjmWtL5E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11t fcXx07THcm1UqPkPv7J7Xq8luHYNbtE0L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q9 5/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Ti z91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZn ObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8AY6S1D3l8yKjY/wAOs3UfC+Cm3h3H urA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0zOT4L+V1ce63Rc5+zrXk/m+/N PFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27fkrt/dO69n7RzOydsQYf 4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQveG1+kG+YX8475J7R HyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWqqJI09+69QUqR Wi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou3N0bl7bh 7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP/n3f If4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D 2f1juzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1q iUOe2or506MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7ox c9PgMzNkcNHFkIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi0 6hgjpyeOGOR0t38SEEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2f Uz/7L/2dlPieazAU9AaOT+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z 9H8DvlB/M/h762NkqPau5e3uv9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7c FNU1VJjK2i/ap6emp5EqT7reldQT+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F /HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0 w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cu LyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7/hQ7W75qfjn8beq9vy1mal7A7yo6KvpK KlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+8sfulw7fFzVu283xVTabWSHbgiNI pkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt742fyrYqvMb7+RvyK33s7fPy0o NgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHkq9o6Srnp8od3vMvNvOF3 vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXbS7xhbWJSI9Qr8u0c Kk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5Jtr9LVf9/cbi 8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WVoZGuKSXY 8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv/u5/ EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r 3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf uvde9+691737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7Ahl pnTdC5HaVFFjpVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w 8FNt+u3vjtqYfY2O3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjN z7Oqcl8PuhpZthbewm09sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63 rb1PSw3N8BfhPvPcvbe8N2fFforce5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3 FUlcKtl+7NZSQTmQywxuvuvam9TjpWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP 2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7i fx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/ g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSxHX2Dx22tgxYlkpBTRVmx9vYejosPVtG1 XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+3Oz9uZ/aXY2+JuvduT5TfO392U70 m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnTL13/AC+vhL1NjosR1z8Yen9p 4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4o8aaiT7dYw7X91ssx4np T9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ33Xzz0xqTuyh2hQxY pK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7LVQlpsPg947Zo 6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBcotNTQuQSV BoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ2D2x HndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3 b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U 49O+U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN 25jcvXfa4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMi apnXUqqFLJErN1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h /wANi+4/0ufxn++n9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sN WPpdHg+Bq4avB/Hpp4v6mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697 917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X uve/de697917r3v3XugA+RP/AB59D/zID/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/ ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8A N3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/an4/9v8X59C17IumOv//Z --------------060706010300040305080800-- From dieter.beller@alcatel-lucent.com Thu Jan 31 04:53:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E070021F8633 for ; Thu, 31 Jan 2013 04:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.791 X-Spam-Level: X-Spam-Status: No, score=-6.791 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 B8eqN2RGyz67 for ; Thu, 31 Jan 2013 04:53:36 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id E623A21F85E2 for ; Thu, 31 Jan 2013 04:53:35 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0VCodqJ019166 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Jan 2013 13:53:31 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 31 Jan 2013 13:53:09 +0100 Received: from [149.204.106.184] (135.239.27.11) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 31 Jan 2013 13:52:46 +0100 Message-ID: <510A691D.1010703@alcatel-lucent.com> Date: Thu, 31 Jan 2013 13:52:45 +0100 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A" References: In-Reply-To: Content-Type: multipart/related; boundary="------------060105050105050200060201" X-Originating-IP: [135.239.27.11] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Poll on making draft-ali-ccamp-te-metric-recording-03 WG document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 12:53:37 -0000 --------------060105050105050200060201 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit yes/support


Thanks,
Dieter


On 24.01.2013 19:47, BRUNGARD, DEBORAH A wrote:
All,
This is start a two week poll on making draft-ali-ccamp-te-metric-recording-03 a ccamp working group document. Please send email to the list indicating 搚es/support or 搉o/do not support. If indicating no, please state your technical reservations with the document.
The poll ends Thursday, Feb. 7th.
Note, as stated by some of the authors, there is IPR 搒till being documented.
Thanks,
Deborah and Lou

--

DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) Hans-J鰎g Daub Dr. Rainer Fechner Andreas Gehe

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.
--------------060105050105050200060201 Content-Type: image/jpeg; name="Corporate-sig-logo.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Corporate-sig-logo.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoL EAACAQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOh sfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5 OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX 2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRx CEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVW N4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiI mKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A3+Pfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69 1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvnsm0T1ExVp4aKgx+P pIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBVRQWdjhVBPl09 bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnDsnYeNhlS t353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs6eNO xxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ 7Acje43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BIN KHjT7QSPl1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3 PH4/Pq/b0eT0e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT 51rSnRWch3x82aXqD5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7 jxFdV1j4TJaq6J6L7a/lkQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1 +i9/YvC0VVt7r6j2f9umY7C/jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4K Yys7u617g3DtL45dIN8iev44/kN1HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWp jPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72i yUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfPqn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0d L3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkFWRjEDeM1aInut0WtK46Hyr7F+REPyX2R 1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvWb0i7jz1LWYYx1K5iFkpWMrKQhgZZ PdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh1/HTdgdV0u+MRhIO0YOz5aBN t4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0HFV/Gyr6SrN75T5Mnsfb0 E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/In5+r8YMp2ZT/AAAo JPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6Pfut0WtK4+zox q9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNESRCCZCQv utUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9ppiTtr KyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y 8h8B8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm 1HVSyx+/dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr 5+uzTrn9ttjaeJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b3 10AfkPsCeDoPqKv3bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaH yVl787t2HP8AGeli6R2R1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoW YI8c6BPdaoKcc9BLi++PnVU9IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq 0W8o6WTC9mVWJ29j8dkP4JjmWtL5E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11t fcXx07THcm1UqPkPv7J7Xq8luHYNbtE0L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q9 5/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Ti z91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZn ObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8AY6S1D3l8yKjY/wAOs3UfC+Cm3h3H urA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0zOT4L+V1ce63Rc5+zrXk/m+/N PFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27fkrt/dO69n7RzOydsQYf 4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQveG1+kG+YX8475J7R HyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWqqJI09+69QUqR Wi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou3N0bl7bh 7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP/n3f If4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D 2f1juzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1q iUOe2or506MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7ox c9PgMzNkcNHFkIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi0 6hgjpyeOGOR0t38SEEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2f Uz/7L/2dlPieazAU9AaOT+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z 9H8DvlB/M/h762NkqPau5e3uv9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7c FNU1VJjK2i/ap6emp5EqT7reldQT+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F /HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0 w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cu LyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7/hQ7W75qfjn8beq9vy1mal7A7yo6KvpK KlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+8sfulw7fFzVu283xVTabWSHbgiNI pkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt742fyrYqvMb7+RvyK33s7fPy0o NgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHkq9o6Srnp8od3vMvNvOF3 vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXbS7xhbWJSI9Qr8u0c Kk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5Jtr9LVf9/cbi 8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WVoZGuKSXY 8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv/u5/ EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r 3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf uvde9+691737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7Ahl pnTdC5HaVFFjpVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w 8FNt+u3vjtqYfY2O3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjN z7Oqcl8PuhpZthbewm09sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63 rb1PSw3N8BfhPvPcvbe8N2fFforce5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3 FUlcKtl+7NZSQTmQywxuvuvam9TjpWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP 2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7i fx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/ g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSxHX2Dx22tgxYlkpBTRVmx9vYejosPVtG1 XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+3Oz9uZ/aXY2+JuvduT5TfO392U70 m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnTL13/AC+vhL1NjosR1z8Yen9p 4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4o8aaiT7dYw7X91ssx4np T9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ33Xzz0xqTuyh2hQxY pK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7LVQlpsPg947Zo 6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBcotNTQuQSV BoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ2D2x HndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3 b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U 49O+U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN 25jcvXfa4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMi apnXUqqFLJErN1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h /wANi+4/0ufxn++n9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sN WPpdHg+Bq4avB/Hpp4v6mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697 917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X uve/de697917r3v3XugA+RP/AB59D/zID/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/ ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8A N3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/an4/9v8X59C17IumOv//Z --------------060105050105050200060201-- From rrao@infinera.com Thu Jan 31 11:19:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AC821F8528 for ; Thu, 31 Jan 2013 11:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6] 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 s2JMEULHTWKv for ; Thu, 31 Jan 2013 11:19:42 -0800 (PST) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id D303B21F8521 for ; Thu, 31 Jan 2013 11:19:42 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0328.009; Thu, 31 Jan 2013 11:19:41 -0800 From: Rajan Rao To: Khuzema Pithewan , Lou Berger , "Gruman, Fred" Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Thread-Index: AQHN/ZW/RO6uR3R3x0CH9+YHO7694phhCa6AgAAUpoCAAA6YgIAAFdKAgAAbJACAAJgmgIAB3law Date: Thu, 31 Jan 2013 19:19:41 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D3FAF44A8@SV-EXDB-PROD1.infinera.com> References: <5106DED0.3090008@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33126F@RCHEXMBP1.fnc.net.local> <51081917.3080601@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33153D@RCHEXMBP1.fnc.net.local> <5108422A.3090704@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:19:44 -0000 UHJlZmVyIG9wdGlvbiMxIG9yICMyLg0KDQpUaGFua3MNClJhamFuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtodXplbWEgUGl0aGV3YW4NClNlbnQ6IFR1 ZXNkYXksIEphbnVhcnkgMjksIDIwMTMgMTA6NDcgUE0NClRvOiBMb3UgQmVyZ2VyOyBHcnVtYW4s IEZyZWQNCkNjOiBDQ0FNUA0KU3ViamVjdDogUmU6IFtDQ0FNUF0gUG9sbCBvbiBPRFVGbGV4LXJl bGF0ZWQgZW5jb2RpbmcgKHdhczogV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNCkNCg0KSSB3b3VsZCBwcmVmZXIgb3B0aW9u IzEvMi4NCg0KVGhhbmtzDQpLaHV6ZW1hDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIExvdSBCZXJnZXINClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAzMCwg MjAxMyAzOjEyIEFNDQpUbzogR3J1bWFuLCBGcmVkDQpDYzogQ0NBTVANClN1YmplY3Q6IFJlOiBb Q0NBTVBdIFBvbGwgb24gT0RVRmxleC1yZWxhdGVkIGVuY29kaW5nICh3YXM6IFdHIExhc3QgQ2Fs bCBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQp DQoNCkZyZWQsDQoNCkNvbmZpcm1lZC4gIE9wdGlvbiAyIGhhZCBhIHNob3J0ZW5lZCBmb3JtIG9m IHRoZSB0ZXh0IG9mIG9wdGlvbiAxIHRoYXQgZnVsbHkgc3BlbGxlZCBpdCBvdXQuICBTb3JyeSBm b3IgdGhlIGNvbmZ1c2lvbi4NCg0KTG91DQoNCk9uIDEvMjkvMjAxMyAzOjA0IFBNLCBHcnVtYW4s IEZyZWQgd3JvdGU6DQo+IEhpIExvdSwNCj4gDQo+IEp1c3QgdG8gY29uZmlybSwgeW91ciBvcHRp b24gMiB3aGVyZSB5b3Ugc3RhdGUgInVzZSBhIG5ldyBDLXR5cGUgZm9yIE9UTi1URE0gbGFiZWxz IiwgaXQgd2FzIG5vdCB0aGUgaW50ZW50IHRvIGhhdmUgYSBuZXcgYy10eXBlIGZvciB0aGUgbGFi ZWwgaXRzZWxmLCBidXQgYSBuZXcgYy10eXBlIGZvciB0aGUgc2VuZGVyLXRzcGVjL2Zsb3dzcGVj ICh0cmFmZmljIHBhcmFtZXRlcnMpLiBJZiBzbywgSSBtaXN1bmRlcnN0b29kIHRoZSBvcHRpb24g YW5kIG5vdyB1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbHMuDQo+IA0KPiBUaGFua3MsDQo+IEZyZWQN Cj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvdSBCZXJnZXIgW21h aWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI5LCAyMDEz IDEyOjQ3IFBNDQo+IFRvOiBHcnVtYW4sIEZyZWQNCj4gQ2M6IFphZmFyIEFsaSAoemFsaSk7IEND QU1QDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFBvbGwgb24gT0RVRmxleC1yZWxhdGVkIGVuY29k aW5nICh3YXM6IFdHIExhc3QgDQo+IENhbGwgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KPiANCj4gRnJlZCwNCj4gCVRoYW5rcyBmb3IgdGhl IGlucHV0Lg0KPiANCj4gT24gMS8yOS8yMDEzIDEyOjU0IFBNLCBHcnVtYW4sIEZyZWQgd3JvdGU6 DQo+PiBIaSBMb3UsDQo+Pg0KPj4gSSBhbSBub3QgY2xlYXIgb24gb3B0aW9uIDIgYXMgd2hlbiBJ IGxvb2sgaW50byBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDUsIHRo ZSBJQU5BIHNlY3Rpb24gc2hvd3MgdGhlIGMtdHlwZSBmb3IgdGhlIEdFTkVSQUxJWkVfTEFCRUwg ZGVmaW5lZCBpbiBSRkMgMzQ3Mywgbm90IGEgbmV3IGMtdHlwZS4NCj4+DQo+PiBPVE4tVERNIEdl bmVyYWxpemVkIExhYmVsIE9iamVjdDogDQo+Pg0KPj4gICAgICAgIG8gT1ROLVRETSBHZW5lcmFs aXplZCBMYWJlbCBPYmplY3Q6IENsYXNzID0gMTYsIEMtVHlwZSA9IDIgKHNlZSANCj4+ICAgICAg ICAgIFNlY3Rpb24gNS4xKQ0KPj4NCj4gDQo+IEkgZGlkbid0IG5vdGljZSB0aGF0IGluY29uc2lz dGVuY3kuICBQZXINCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2Ft cC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA1I3NlY3Rpb24tNToNCj4gIFRoZSB0cmFmZmljIHBh cmFtZXRlcnMgZm9yIE9UTi1URE0gY2FwYWJsZSBTd2l0Y2hpbmcgVHlwZSBhcmUgY2FycmllZCAN Cj4gaW4gdGhlIE9UTi1URE0gU0VOREVSX1RTUEVDIGFuZCBGTE9XU1BFQyBvYmplY3RzLiBUaGUg b2JqZWN0cyBoYXZlIHRoZSANCj4gZm9sbG93aW5nIGNsYXNzIGFuZCB0eXBlOg0KPiANCj4gICAg IC0gIE9UTi1URE0gU0VOREVSX1RTUEVDIE9iamVjdDogQ2xhc3MgPSAxMiwgQy1UeXBlID0gNyAo VEJBKQ0KPiAgICAgLSAgT1ROLVRETSBGTE9XU1BFQyBPYmplY3Q6IENsYXNzID0gOSwgQy1UeXBl ID0gNyAoVEJBKQ0KPiANCj4gTG91DQo+IA0KPj4gSSdtIG9wZW4gdG8gZWl0aGVyIGNhcnJ5aW5n IE9EVWZsZXgoR0ZQKSBiYW5kd2lkdGggYXMgZmxvYXRpbmctcG9pbnQgb3IgaW50ZWdlciBOLCBi dXQgd291bGQgbGlrZSB0byBzZWUgY29uc2lzdGVuY3kgYmV0d2VlbiByb3V0aW5nIGFuZCBzaWdu YWxpbmcgZG9jdW1lbnRzLg0KPj4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gRnJlZA0KPj4NCj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+PiBCZWhhbGYgT2YgWmFmYXIg QWxpICh6YWxpKQ0KPj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyOSwgMjAxMyAxMDo0MSBBTQ0K Pj4gVG86IExvdSBCZXJnZXI7IENDQU1QDQo+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBQb2xsIG9u IE9EVUZsZXgtcmVsYXRlZCBlbmNvZGluZyAod2FzOiBXRyBMYXN0IA0KPj4gQ2FsbCBjb21tZW50 cyBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQpDQo+Pg0KPj4g SGkgTG91LCBDLWNhbXBlcnM6IA0KPj4NCj4+IEkgd291bGQgcGljayBPcHRpb24gMjsgaXQncyBj bGVhbmVyIGFuZCAgYWRkcmVzc2VzIHRoZSBpc3N1ZSByZWxhdGVkIA0KPj4gdG8gb3ZlcmxvYWRp bmcgdGhlIHNhbWUgYy10eXBlLg0KPj4NCj4+IFRoYW5rcw0KPj4NCj4+IFJlZ2FyZHPigKZaYWZh cg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogImxiZXJn ZXJAbGFibi5uZXQiIDxsYmVyZ2VyQGxhYm4ubmV0Pg0KPj4gRGF0ZTogTW9uZGF5LCBKYW51YXJ5 IDI4LCAyMDEzIDM6MjUgUE0NCj4+IFRvOiAiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9y Zz4NCj4+IFN1YmplY3Q6IFtDQ0FNUF0gUG9sbCBvbiBPRFVGbGV4LXJlbGF0ZWQgZW5jb2Rpbmcg KHdhczogV0cgTGFzdCBDYWxsIA0KPj4gY29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1zaWduYWxpbmctZzcwOXYzLTA0KQ0KPj4NCj4+PiBBbGwsDQo+Pj4gCVdlIHdvdWxkIGxpa2Ug dG8gdHJ5IHRvIGNsb3NlIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBHLjcwOSBkcmFmdHMgc28gDQo+ Pj4gdGhhdCB3ZSBjYW4gbW92ZSByYXBpZGx5IHRvd2FyZHMgcHVibGljYXRpb24gcmVxdWVzdC4g IFRoZSANCj4+PiBkaXNjdXNzaW9uIG9mIChvbmUgb2YgbXkpIExDIGNvbW1lbnRzIGhhcyByZXN1 bHRlZCBpbiBzZXZlcmFsIA0KPj4+IG9wdGlvbnMgZm9yIHRoZSBzaWduYWxpbmcgT0RVLXJlbGF0 ZWQgdHJhZmZpYyBwYXJhbWV0ZXJzLCBhbmQgdGhlIA0KPj4+IHBvaW50IGhhcyBiZWVuIHJhaXNl ZCB0aGF0IHJlYWxpZ25pbmcgcm91dGluZyB3aXRoIHNpZ25hbGluZyBzaG91bGQgYmUgZGlzY3Vz c2VkLg0KPj4+DQo+Pj4gUGxlYXNlIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBvYmplY3RpdmUgb2Yg YW55IFBTIGlzIA0KPj4+IGludGVyb3BlcmFiaWxpdHksIGFuZCB0aGF0IHRoZXJlIG1heSBiZSBl YXJseSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBtYXRjaCBnNzA5djMtMDQuDQo+Pj4NCj4+PiBUaGUg YmFzaWMgcXVlc3Rpb24gaXMgb25lIG9mIGlmIE4sIHRoZSBudW1iZXIgb2YgdGltZSBzbG90cyBu ZWVkZWQgDQo+Pj4gdG8gc3VwcG9ydCBhIE9EVWZsZXgoR0ZQKSBzaWduYWwsIHNob3VsZCBiZSBj YXJyaWVkIGFzIGEgY2FsY3VsYXRlZCBJRUVFDQo+Pj4gZmxvYXRpbmcgcG9pbnQgbnVtYmVyIG9y IGRpcmVjdGx5LiAgIE9wdGlvbnMgMSBhbmQgMiBiZWxvdyByZWZsZWN0IHRoZQ0KPj4+IGZvcm1l ciwgb3B0aW9ucyAzIGFuZCA0IG1hdGNoIHRoZSBsYXR0ZXIuICBJdCBpcyB3b3J0aCBub3Rpbmcg dGhhdCANCj4+PiBvbmx5IG9wdGlvbnMgMSBhbmQgMiBhcmUgcHJvcG9zZWQgZm9yIE9EVWZsZXgo R0ZQKSwgaS5lLiwgTiBtdXN0IGJlIA0KPj4+IGNhbGN1bGF0ZWQgZm9yIE9EVWZsZXgoQ0JSKSBz aWduYWwgdHlwZXMgd2l0aCBhbGwgb3B0aW9ucy4NCj4+Pg0KPj4+IFBsZWFzZSBzdGF0ZSB5b3Vy IHN1cHBvcnQgZm9yIG9uZSB0aGUgb3B0aW9ucyBhbmQsIGlmIHlvdSB3aXNoLCB0aGUgDQo+Pj4g anVzdGlmaWNhdGlvbiBmb3IgeW91ciBwb3NpdGlvbjoNCj4+Pg0KPj4+IDEpIEZvbGxvdyBkcmFm dC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4+PiAgIGkuZS4sIHJlZGVm aW5lIFtSRkM0MzI4XSBUcmFmZmljIFBhcmFtZXRlcnMgYy10eXBlIHdoZW4gdXNlZCB3aXRoDQo+ Pj4gICBPVE4tVERNIGxhYmVscy4gT0RVZmxleChHRlApIG51bWJlciBvZiB0cmlidXRhcnkgc2xv dHMgKE4pIGlzDQo+Pj4gICBlbmNvZGVkIGFzOg0KPj4+DQo+Pj4gICAuLi4gdGhlIEJpdF9SYXRl IGZpZWxkIGZvciBPRFVmbGV4KEdGUCkgTVVTVA0KPj4+ICAgZXF1YWwgdG8gb25lIG9mIHRoZSA4 MCB2YWx1ZXMgbGlzdGVkIGJlbG93Og0KPj4+DQo+Pj4gICAgICAgMSAqIE9EVTIudHM7IDIgKiBP RFUyLnRzOyAuLi47IDggKiBPRFUyLnRzOw0KPj4+ICAgICAgIDkgKiBPRFUzLnRzOyAxMCAqIE9E VTMudHMsIC4uLjsgMzIgKiBPRFUzLnRzOw0KPj4+ICAgICAgIDMzICogT0RVNC50czsgMzQgKiBP RFU0LnRzOyAuLi47IDgwICogT0RVNC50cy4NCj4+Pg0KPj4+IDIpIEZvbGxvdyBkcmFmdC1pZXRm LWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDUNCj4+PiAgIGkuZS4sIHVzZSBhIG5ldyBD LXR5cGUgZm9yIE9UTi1URE0gbGFiZWxzLiAgRW5jb2RpbmcgZGV0YWlscw0KPj4+ICAgdW5jaGFu Z2VkIGZyb20gZzcwOXYzLTA0Lg0KPj4+ICAgKFRoaXMgb3B0aW9uIGFkZHJlc3NlcyB0aGUgaXNz dWUgb2YgdGhlIHNhbWUgYy10eXBlIG5lZWRpbmcgdG8NCj4+PiAgICBiZSBwYXJzZWQgYmFzZWQg b24gbGFiZWwvc3dpdGNoaW5nIHR5cGUuKQ0KPj4+DQo+Pj4gMykgRm9sbG93IGRyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNg0KPj4+ICAgaS5lLiwgIHVzZSBhIG5ldyBD LXR5cGUgZm9yIE9UTi1URE0gbGFiZWxzLiBOIGlzIGRpcmVjdGx5IGNhcnJpZWQNCj4+PiAgIGZv ciBPRFVmbGV4KEdGUCkgb25seS4NCj4+Pg0KPj4+IDQpIERpc2N1c3NlZCwgYnV0IG5vdCBpbiBh bnkgZHJhZnQNCj4+PiAgIFVzZSBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5 djMtMDQgZW5jb2RpbmcgZm9yIGFsbA0KPj4+ICAgYnV0IE9EVWZsZXgoR0ZQKSwgYW5kIGRlZmlu ZSBuZXcgT0RVZmxleChHRlApIHNwZWNpZmljIFRyYWZmaWMNCj4+PiAgIFBhcmFtZXRlcnMgYmFz ZWQgb24gZzcwOXYzLTA2LCBwcmVzdW1hYmx5IHdpdGggdW51c2VkIGZpZWxkcw0KPj4+ICAgcmVt b3ZlZC4NCj4+PiAgIChUaGlzIGFsc28gYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiB0aGUgc2FtZSBj LXR5cGUgbmVlZGluZyB0byBiZQ0KPj4+ICAgIHBhcnNlZCBiYXNlZCBvbiBsYWJlbCB0eXBlLCBi dXQgbWVhbnMgdGhlcmUgYXJlIGRpZmZlcmVudCB0eXBlcw0KPj4+ICAgIGJhc2VkIG9uIHNpZ25h bCB0eXBlLikNCj4+Pg0KPj4+IE9wdGlvbiAxIGFuZCAyIGRvIG5vdCBpbXBseSBhbnkgY2hhbmdl cyB0byByb3V0aW5nLCB3aGlsZSBvcHRpb25zIDMgDQo+Pj4gYW5kDQo+Pj4gNCBtYXkuICBSb3V0 aW5nIGltcGxpY2F0aW9ucyB3aWxsIGJlIGRpc2N1c3NlZCBiYXNlZCBvbiB0aGUgcmVzdWx0cyAN Cj4+PiBvZiB0aGlzIHBvbGwsIGFuZCBvbmx5IGlmIHRoZXJlIGlzIGNvbnNlbnN1cyB0byBzdXBw b3J0IHBvc2l0aW9ucyAzIG9yIDQuDQo+Pj4NCj4+PiBXZSBob3BlIHRvIG1ha2UgYSBjb25zZW5z dXMgY2FsbCBieSB0aGUgZW5kIG9mIHRoZSB3ZWVrLCBidXQgd2lsbCANCj4+PiBjb250aW51ZSB0 aGUgZGlzY3Vzc2lvbiBhcyBuZWVkZWQuDQo+Pj4NCj4+PiBNdWNoIHRoYW5rcywNCj4+PiBMb3Ug KGFuZCBEZWJvcmFoKQ0KPj4+DQo+Pj4gT24gMS8yOC8yMDEzIDU6MDggQU0sIERhbmllbGUgQ2Vj Y2FyZWxsaSB3cm90ZToNCj4+Pj4gIEFsbCwNCj4+Pj4NCj4+Pj4gSSB0aGluayB0aGUgY2hhbmdl cyBwcm9wb3NlZCBhcmUgbWVhbmluZ2Z1bCBhbmQgd291bGQgc3VwcG9ydCB0aGVtIA0KPj4+PiBp biBhbiBpbmRpdmlkdWFsIG9yIGVhcmx5IFdHIGRyYWZ0LCBidXQgdGhleSBkb24ndCBzZWVtIHRv IHByb3ZpZGUgDQo+Pj4+IHNpZ25pZmljYXRpdmUgYWR2YW50YWdlcyB0byByaXNrIGludGVyd29y a2luZyBpc3N1ZXMgd2l0aCBlYXJseSANCj4+Pj4gaW1wbGVtZW50YXRpb25zLg0KPj4+PiBNb3Jl b3ZlciB0aGUgY2hhbmdlcyBkb24ndCBhbGxvdyB1cyBnZXR0aW5nIHRvdGFsbHkgcmlkIG9mIG9m IHRoZSANCj4+Pj4gYml0X3JhdGUgZmllbGQgYXMgaXQgaXMgc3RpbGwgbmVlZGVkIGZvciBPRFVm bGV4IChDQlIpLg0KPj4+Pg0KPj4+PiBNeSAyYw0KPj4+PiBEYW5pZWxlDQo+Pj4+DQo+Pj4+DQo+ Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogWmFmYXIgQWxpICh6 YWxpKSBbbWFpbHRvOnphbGlAY2lzY28uY29tXQ0KPj4+Pj4gU2VudDogbHVuZWTDrCAyOCBnZW5u YWlvIDIwMTMgNC40Nw0KPj4+Pj4gVG86IExvdSBCZXJnZXINCj4+Pj4+IENjOiBHcnVtYW4sIEZy ZWQ7IEZhdGFpIFpoYW5nOyBEYW5pZWxlIENlY2NhcmVsbGk7IENDQU1QOyANCj4+Pj4+IGRyYWZ0 LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZw0KPj4+Pj4g U3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIGNvbW1lbnRzIG9uDQo+Pj4+PiBkcmFm dC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDQNCj4+Pj4+DQo+Pj4+PiBIaSBM b3UtDQo+Pj4+Pg0KPj4+Pj4gUGxlYXNlIHNlZSBpbi1saW5lLg0KPj4+Pj4NCj4+Pj4+IFRoYW5r cw0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMuLi5aYWZhcg0KPj4+Pj4NCj4+Pj4+IE9uIDEvMjcvMTMg OTo0NiBQTSwgIkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4+Pj4+DQo+ Pj4+Pj4gWmFmYXIsDQo+Pj4+Pj4gCUlzIHlvdXIgY29tbWVudCB3aXRoIHJlc3BlY3QgdG8ganVz dCByb3V0aW5nIG9yIGJvdGgNCj4+Pj4+IHNpZ25hbGluZyBhbmQNCj4+Pj4+PiByb3V0aW5nPw0K Pj4+Pj4NCj4+Pj4+IEJvdGgsIGluY2x1ZGluZyBjb25zaXN0ZW5jeSBiZXR3ZWVuIHNpZ25hbGlu ZyBhbmQgcm91dGluZyBhdHRyaWJ1dGVzLg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEFsc28sIHdo ZW4geW91IHNheSAiaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIGRyYWZ0IHZlcnNpb25zIiwNCj4+ Pj4+IGRvIHRoZXNlDQo+Pj4+Pj4gaW1wbGVtZW50YXRpb25zIGluY2x1ZGUgc3VwcG9ydCBmb3Ig T0RVZmxleD8gIChXaGljaCBoYXMgcmVhbGx5IA0KPj4+Pj4+IGJlZW4gdGhlIGZvY3VzIG9mIHRo ZSBkaXNjdXNzaW9uLikNCj4+Pj4+DQo+Pj4+PiBZZXMsIEkgd2FzIHJlZmVycmluZyB0byBPRFVG bGV4LiBBcyB5b3Uga25vdywgZml4ZWQgT0RVIGlzIA0KPj4+Pj4gc2lnbmFsZWQgdmlhIGxldmVs ICgwIEJXKSBzbyBpdHMgbm90IGFuIGlzc3VlLg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEJUVyBJ IHRvb2sgRnJlZCdzIGNvbW1lbnRzIGFzIHJlbGF0ZWQgdG8ganVzdCB0aGUgbmV3DQo+Pj4+PiBP VE4tc3BlY2lmaWMgSVNDRA0KPj4+Pj4+IGRlZmluaXRpb25zIChzZWN0aW9uIDQuMS4yIG9mIG9z cGYtZzcwOXYzLTA1LCBpbiBwYXJ0aWN1bGFyKS4gIA0KPj4+Pj4+IE5vdGUgdGhhdCBzZWN0aW9u IDQuMS4xIGFscmVhZHkgY2FycmllcyBOIChudW1iZXIgb2YgT0RVcykgbm90DQo+Pj4+PiBJRUVF IGZsb2F0aW5nDQo+Pj4+Pj4gcG9pbnQgcmVwcmVzZW50YXRpb25zIG9mIGF2YWlsYWJsZSBiYW5k d2lkdGguDQo+Pj4+Pg0KPj4+Pj4gV2hhdCBJIG1lYW50IGlzIFVucmVzZXJ2ZWQgQmFuZHdpZHRo IGF0IHByaW9yaXR5IHggYW5kIE1heCBMU1AgDQo+Pj4+PiBCYW5kd2lkdGggYXQgcHJpb3JpdHkg eC4NCj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBNdWNoIHRoYW5rcywNCj4+Pj4+PiBMb3UNCj4+Pj4+ Pg0KPj4+Pj4+IE9uIDEvMjcvMjAxMyA3OjQ2IFBNLCBaYWZhciBBbGkgKHphbGkpIHdyb3RlOg0K Pj4+Pj4+PiBBbGwtDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoaXMgaW1wYWN0cyBleGlzdGluZyBpbXBs ZW1lbnRhdGlvbnMgYmFzZWQgb24gZHJhZnQgdmVyc2lvbnMgDQo+Pj4+Pj4+IChhbmQgaGVuY2Ug aW50ZXJvcCB3aXRoIHRoZXNlIGltcGxlbWVudGF0aW9ucyBtb3ZpbmcgZm9yd2FyZCkuDQo+Pj4+ PiBJTU8gdGhpcyBpcw0KPj4+Pj4+PiBhIGJpZ2dlciBjaGFuZ2UgZm9yIHVzIHRvIGFzc3VtZSBh dCB0aGUgbGFzdCBjYWxsIHN0YWdlLg0KPj4+Pj4gRnVydGhlcm1vcmUNCj4+Pj4+Pj4gd2UgaGF2 ZSBiZWVuIHVzaW5nIElFRUUgZmxvYXRpbmcgcG9pbnQgZm9ybWF0IGZvciBVbnJlc2VydmVkIA0K Pj4+Pj4+PiBCYW5kd2lkdGgvIE1heCBMU1AgQlcgaW4gSUVFRSBmbG9hdGluZyBwb2ludCBmb3Jt YXQgZm9yIG90aGVyIA0KPj4+Pj4+PiB0ZWNobm9sb2dpZXMuIE92ZXJhbGwsIEkgdGhpbmsgdGhp cyBjaGFuZ2Ugc3VmZmVycyBmcm9tIHRoZQ0KPj4+Pj4gImxhdyBvZiBkaW1pbmlzaGluZyByZXR1 cm5zIi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhbmtzDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFJlZ2FyZHMg xaAgWmFmYXINCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gMS8yNy8xMyAxMDoyOCBBTSwg IkdydW1hbiwgRnJlZCINCj4+Pj4+IDxmcmVkLmdydW1hbkB1cy5mdWppdHN1LmNvbT4gd3JvdGU6 DQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBIaSBMb3UsIEZhdGFpLCBEYW5pZWxlLA0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IEkgdW5kZXJzdGFuZCB0aGUgbGF0ZXN0IGNoYW5nZSB0byB0aGUgd2F5IGJhbmR3aWR0 aCBpcw0KPj4+Pj4gc2lnbmFsZWQgZm9yDQo+Pj4+Pj4+PiBPRFVmbGV4KEdGUCksIGkuZS4sIHNp Z25hbGluZyB0aGUgbnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cw0KPj4+Pj4gTiBpbnN0ZWFkDQo+ Pj4+Pj4+PiBvZiAgdGhlIGJhbmR3aWR0aCByYXRlIGluIGJwcy4gIEkgYmVsaWV2ZSB0aGF0IHRo aXMgc2ltcGxpZmllcyANCj4+Pj4+Pj4+IHRoZSBzaWduYWxpbmcgIGFuZCBpbnRlcm9wZXJhYmls aXR5IHNvIEknbSBpbiBhZ3JlZW1lbnQgd2l0aA0KPj4+Pj4gdGhpcyBjaGFuZ2UuDQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4gSG93ZXZlciwgaXQgc2VlbXMgd2UgYXJlIG5vdyBpbmNvbnNpc3RlbnQgYmV0 d2VlbiBob3cgd2UNCj4+Pj4+IHJlcHJlc2VudA0KPj4+Pj4+Pj4gYmFuZHdpZHRoIGluIHJvdXRp bmcgYW5kIHNpZ25hbGluZyBmb3IgT0RVZmxleChHRlApLiAgUm91dGluZyANCj4+Pj4+Pj4+IGFk dmVydGlzZXMgIHRoZSBiYW5kd2lkdGggdXNpbmcgYSBmbG9hdGluZyBwb2ludCByZXByZXNlbnRh dGlvbiANCj4+Pj4+Pj4+IG9mIGJhbmR3aWR0aCwgd2hpbGUgIHNpZ25hbGluZyBpcyB1c2luZyB0 aGUgbnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cy4NCj4+Pj4+Pj4+IEl0IHNlZW1zIHRoZSBzYW1l ICBiZW5lZml0cyB3b3VsZCBiZSBvYnRhaW5lZCBieQ0KPj4+Pj4gYWR2ZXJ0aXNpbmcgdGhlIG1h eA0KPj4+Pj4+Pj4gTFNQIGJhbmR3aWR0aCBhbmQgIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGZvciBP RFVmbGV4KEdGUCkgaW4NCj4+Pj4+IHRlcm1zIG9mDQo+Pj4+Pj4+PiB0aGUgbnVtYmVyIG9mIHRy aWJ1dGFyeSAgc2xvdHMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRnJlZA0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+ Pj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGll dGYub3JnXSBPbiANCj4+Pj4+Pj4+IEJlaGFsZiBPZiAgTG91IEJlcmdlcg0KPj4+Pj4+Pj4gU2Vu dDogV2VkbmVzZGF5LCBKYW51YXJ5IDIzLCAyMDEzIDk6MDggQU0NCj4+Pj4+Pj4+IFRvOiBGYXRh aSBaaGFuZw0KPj4+Pj4+Pj4gQ2M6IENDQU1QOw0KPj4+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQo+Pj4+Pj4+PiBTdWJqZWN0OiBS ZTogW0NDQU1QXSBXRyBMYXN0IENhbGwgY29tbWVudHMgb24NCj4+Pj4+Pj4+IGRyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEZhdGFp LA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIDEvMjMvMjAxMyA2OjQ5IEFNLCBGYXRhaSBaaGFuZyB3 cm90ZToNCj4+Pj4+Pj4+PiBIaSBMb3UsDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBGb3IgT0RVZmxl eChDQlIpLCB0aGUgZm9ybXVsYSBpcyBmcm9tIFtHLjcwOS0yMDEyXSBhbmQgaXQNCj4+Pj4+IGhh cyBiZWVuDQo+Pj4+Pj4+Pj4gZGlzY3Vzc2VkIGJlZm9yZSwgc28gcGxlYXNlIHRydXN0IHRoYXQg dGhlcmUgaXMgbm8NCj4+Pj4+IG9wcG9ydHVuaXR5IGZvcg0KPj4+Pj4+Pj4+IG1pc2ludGVycHJl dGF0aW9uLiAoTm90ZSB0aGF0IHRoZXJlIGFyZSB0d28gY2FzZXMsIG9uZSBpcw0KPj4+Pj4+Pj4+ IE9EVWZsZXgoQ0JSKSBhbmQgYW5vdGhlciBvbmUgaXMgT0RVZmxleChHRlApKS4NCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IEluIGFkZHRpb24sIE9EVWZsZXggY2Fubm90IGJlIGNvbmNhdGVuYXRlZCBi eSBbRy43MDktMjAxMl0uDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhhbmtzIGZvciBjb25maXJtaW5n IG15IHVuZGVyc3RhbmRpbmcuICBUaGlzIHJhaXNlcyB0aGUNCj4+Pj4+IHF1ZXN0aW9uIG9mDQo+ Pj4+Pj4+PiBpZiB0aGUgbmV3IHRyYWZmaWMgc2hvdWxkIGp1c3QgYXBwbHkgdG8gT0RVRmxleD8g IENvcnJlY3QNCj4+Pj4+IG1lIGlmIEknbQ0KPj4+Pj4+Pj4gd3JvbmcsIGJ1dCBJIGJlbGlldmUg dGhlIFtSRkM0MzI4XSBpcyBzdWZmaWNpZW50IGluIGFsbA0KPj4+Pj4gb3RoZXIgY2FzZXMuICAN Cj4+Pj4+Pj4+IFRoaXMgbWF5IGFsc28gbWFrZSBpdCBlYXNpZXIgZm9yIGVhcmx5IGltcGxlbWVu dGF0aW9ucyBvZg0KPj4+Pj4gdGhlIGRyYWZ0DQo+Pj4+Pj4+PiBhcyB0aGVuIHRoZXkgY2FuIGxp bWl0IGNvZGUgY2hhbmdlcyBmcm9tIHRoZSAoLTAzKSByZXYgdG8NCj4+Pj4+IG9ubHkgT0RVZmxl eCBMU1BzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEp1c3QgdG8gYmUgY2xlYXIsIEknbSByZWFsbHkg anVzdCAqYXNraW5nKiBhYm91dCB0aGlzLiAgQXMgSSANCj4+Pj4+Pj4+IHNhaWQgYmVmb3JlLCBJ J20gb3BlbiBvbiBzcGVjaWZpY3MuLi4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBbnkgdGhvdWdodHMv Y29tbWVudHM/IEF1dGhvcnM/ICBJbXBsZW1lbnRvcnM/DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhh bmtzLA0KPj4+Pj4+Pj4gTG91DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJIHdpbGwg aXNzdWUgYSBuZXcgdmVyc2lvbiB0b21vcnJvdyB0byBjYXB0dXJlIGFsbCB5b3VyIGNvbW1lbnRz Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBCZXN0IFJlZ2FyZHMNCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRv OmxiZXJnZXJAbGFibi5uZXRdDQo+Pj4+Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIz LCAyMDEzIDI6MTEgQU0NCj4+Pj4+Pj4+PiBUbzogRmF0YWkgWmhhbmcNCj4+Pj4+Pj4+PiBDYzog Q0NBTVA7DQo+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYz QHRvb2xzLmlldGYub3JnDQo+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBD YWxsIGNvbW1lbnRzIG9uDQo+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxp bmctZzcwOXYzLTA0DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBGYXRhaSwNCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+IE9uIDEvMjAvMjAxMyA5OjQzIFBNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+Pj4+ Pj4gSGkgTG91LA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBZb3Ugc2FpZDoNCj4+Pj4+Pj4+Pj4+ IGJ1dCB5b3UncmUgc2F5cyBlbmNvZGVkIGFzIChOKk5vbWluYWwgUmF0ZSkgcmlnaHQ/IFdhdCdz IHRoZSANCj4+Pj4+Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1c3QgY2FycnlpbmcgTj8NCj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gW0ZhdGFpXSBUaGUgb3JpZ2luYWwgd2F5IChpbiB2ZXJzaW9u IDA0JjA1KSBpcyBwdXR0aW5nDQo+Pj4+PiAoTiogTm9taW5hbA0KPj4+Pj4+Pj4+PiBSYXRlKSBp biAiQml0X1JhdGUiIGZpZWxkIGZvciBPRFVmbGV4KEdGUCksIHRoZSB2YWx1ZSBpcyB0aGF0IA0K Pj4+Pj4+Pj4+PiB3ZSBjYW4gZ2VuZXJhbGl6ZSB0byBqdXN0IHVzZSBvbmUgc2luZ2xlICJCaXRf UmF0ZSIgZmllbGQgdG8gDQo+Pj4+Pj4+Pj4+IGNhcnJ5IElFRUUgZmxvYXQgbnVtYmVyIGZvciBi b3RoIGNhc2VzLCBpdCBzZWVtcyB0aGF0IHlvdQ0KPj4+Pj4gZG9uJ3QgYWdyZWUgb24NCj4+Pj4+ Pj4+Pj4gdGhpcyB2YWx1ZSwgOi0pDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJJ3ZlIHNlZW4gZGlm ZmVyZW5jZXMgaW4gY2FsY3VsYXRlZCBmbG9hdGluZyBwb2ludCB2YWx1ZXMgZnJvbSANCj4+Pj4+ Pj4+PiBkaWZmZXJlbnQgIGltcGxlbWVudGF0aW9ucywgc28gSSBqdXN0IHdhbnQgdG8gZW5zdXJl IHRoYXQNCj4+Pj4+IHN1Y2ggY2FzZXMNCj4+Pj4+Pj4+PiBhcmUgYXZvaWRlZC4NCj4+Pj4+Pj4+ PiBJJ20gb3BlbiB0byBzcGVjaWZpYyBzb2x1dGlvbnMgYW5kIGNlcnRhaW5seSB3aWxsIGRlZmZl ciBvbiANCj4+Pj4+Pj4+PiB0aGUgc3BlY2lmaWNzIGFzc3VtaW5nIHRoZXJlIGlzIG5vIG9wcG9y dHVuaXR5IGZvciANCj4+Pj4+Pj4+PiBtaXNpbnRlcnByZXRhdGlvbi9pbnRlcm9wICBpc3N1ZXMu IEkgZG9uJ3QgdGhpbmsgdGhlDQo+Pj4+PiBvcmlnaW5hbCBwYXNzZWQNCj4+Pj4+Pj4+PiB0aGlz IHRocmVzaG9sZCwgaS5lLiw6DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgICAgICAgICBOID0gQ2Vp bGluZyBvZg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAgT0RVZmxleChDQlIpIG5vbWluYWwgYml0 IHJhdGUgKiAoMSArIE9EVWZsZXgoQ0JSKSBiaXQgcmF0ZQ0KPj4+Pj4+Pj4+IHRvbGVyYW5jZSkN Cj4+Pj4+Pj4+PiAgICANCj4+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4gLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+ ICAgICAgICBPRFRVay50cyBub21pbmFsIGJpdCByYXRlICogKDEgLSBITyBPUFVrIGJpdCByYXRl DQo+Pj4+PiB0b2xlcmFuY2UpDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gLiBUaGVyZWZvcmUsIEkg KHdhcykgYW0gc2F5aW5nIHRoYXQgSSBhbSBnb2luZyB0byBhY2NlcHQgeW91ciANCj4+Pj4+Pj4+ Pj4gc3VnZ2VzdGlvbiB0byBjYXJyeSBOIGZvciBPRFVmbGV4KEdGUCkuIFdlIGFyZQ0KPj4+Pj4g ZGlzY3Vzc2luZyB3aGVyZSB0bw0KPj4+Pj4+Pj4+PiBwdXQgTiBmb3IgT0RVZmxleChHRlApLg0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFlvdSBzYWlkOg0KPj4+Pj4+Pj4+Pj4g Yml0cyBpbiB0aGUgY29udHJvbCBwbGFuZSBhcmUgZ2VuZXJhbGx5IGNoZWFwLCBJTU8gaXQncw0K Pj4+Pj4gYmV0dGVyIHRvDQo+Pj4+Pj4+Pj4+PiBoYXZlIHNpbXBsZXIgZW5jb2RpbmcgdGhhbiB0 byBvcHRpbWl6ZSBldmVyeSBiaXQgKG9yIDggaW4gDQo+Pj4+Pj4+Pj4+PiB0aGlzIGNhc2UpLg0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBbRmF0YWldIE9LLCBJIHdpbGwgYWRkIGEgbmV3IGZpZWxk ICh0byBvY2N1cHkgdGhlIHJlc2VydmVkDQo+Pj4+Pj4+Pj4+IGJpdHMpIHRvIGNhcnJ5IE4uDQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBBcyB5b3Ugc2VlIGZpdC4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ IEp1c3QgdG8gY2xhcmlmeSBteSB1bmRlcnN0YW5kaW5nLCBPRFVmbGV4IGFuZCBWaXJ0dWFsDQo+ Pj4+PiBjb25jYXRlbmF0aW9uDQo+Pj4+Pj4+Pj4gY2FuICBuZXZlciBiZSBjb21iaW5lZCBmb3Ig dGhlIHNhbWUgc2lnbmFsIHR5cGUvbGV2ZWwsIHJpZ2h0Pw0KPj4+Pj4+Pj4+IChBbHRob3VnaCBh biAgT0RVZmxleCBjbGllbnQgc2lnbmFsIGNvdWxkIGJlIGNhcnJpZWQgb3Zlcg0KPj4+Pj4gYSB2 aXJ0dWFsDQo+Pj4+Pj4+Pj4gY29uY2F0ZW5hdGVkICBPRFVrKS4gIElzIHRoaXMgY29ycmVjdCBv ciBkaWQgSSBtaXNzIHNvbWV0aGluZyANCj4+Pj4+Pj4+PiBpbiBHNzA5Pw0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+IExvdQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+PiBGYXRhaQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdl ckBsYWJuLm5ldF0NCj4+Pj4+Pj4+Pj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDE4LCAyMDEzIDE6 NDIgQU0NCj4+Pj4+Pj4+Pj4gVG86IEZhdGFpIFpoYW5nDQo+Pj4+Pj4+Pj4+IENjOiBDQ0FNUDsN Cj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRvb2xz LmlldGYub3JnDQo+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBj b21tZW50cyBvbg0KPj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1n NzA5djMtMDQNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g T24gMS8xNS8yMDEzIDEwOjE2IFBNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4+Pj4+Pj4+Pj4+IEhp IExvdSwNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBUbyBhdm9pZCBtaXN1bmRlcnN0YW5kaW5n LCBJIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSBtb3JlIG9uIA0KPj4+Pj4+Pj4+Pj4gdGhlIGZvbGxv d2luZyBwb2ludC4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IEl0 IGlzIGJldHRlciB0byBoYXZlIGNvbnNpc3RlbnQgZm9ybWF0IGFuZCB0aGUgc2FtZSANCj4+Pj4+ Pj4+Pj4+Pj4+PiBtZWFuaW5nIG9mIG9uZQ0KPj4+Pj4+Pj4+PiBmaWVsZCBmb3IgYm90aCBPRFVm bGV4KENCUikgYW5kIEdGUC4gVGhpcyBpcyB3aHkgd2UgaGF2ZSANCj4+Pj4+Pj4+Pj4gc2VjdGlv bg0KPj4+Pj4+Pj4+PiA1LjENCj4+Pj4+Pj4+Pj4gJjUuMiB0byBkZXNjcmliZSB0aGUgY29tcGxl eCBzdHVmZi4NCj4+Pj4+Pj4+Pj4+Pj4+IEkgYWN0dWFsbHkgd2Fzbid0IHN1Z2dlc3RpbmcgdGhh dCBOIGJlIGNhcnJpZWQgaW4NCj4+Pj4+IHRoZSBiaXQgcmF0ZQ0KPj4+Pj4+Pj4+Pj4+Pj4gZmll bGQuDQo+Pj4+Pj4+Pj4+Pj4+PiBUaGUgYml0IHJhdGUgZmllbGQgY2FuIGVpdGhlciBiZSBzZXQg YXMgZGVzY3JpYmVkIG9yIHRvIA0KPj4+Pj4+Pj4+Pj4+Pj4gemVybyAoaS5lLiwgIGlnbm9yZWQp LiAgQXQgdGhlIHRpbWUsIEkgd2FzIHRoaW5raW5nIGFib3V0DQo+Pj4+PiBjYXJyeWluZyBODQo+ Pj4+Pj4+Pj4+Pj4+PiBpbiB0aGUgIHJlc2VydmVkICBmaWVsZC4gQnV0IHBlcmhhcHMgdGhlIHJp Z2h0IHBsYWNlDQo+Pj4+PiBpcyBNVCwgaWYNCj4+Pj4+Pj4+Pj4+Pj4+IG15IHVuZGVyc3RhbmRp bmcgaXMgIHJpZ2h0ICAod291bGQgYWx3YXlzIGJlIDENCj4+Pj4+IG90aGVyd2lzZSkuIEknbQ0K Pj4+Pj4+Pj4+Pj4+Pj4gb3BlbiB0byBlaXRoZXIuLi4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+IFtGYXRhaV0gV2h5IG5vdCBqdXN0IHVzZSAiYml0IHJhdGUiZmllbGQgdG8gY2FycnkN Cj4+Pj4+ICJOImJlY2F1c2UgIk4iDQo+Pj4+Pj4+Pj4+Pj4+IGltcGxpZXMgYml0IHJhdGU/ICBJ IGFtIE9LIGlmIHlvdSBsaWtlIHRvIHVzZSBhIG5ldw0KPj4+Pj4gZmlsZWQgKGxpa2UNCj4+Pj4+ Pj4+Pj4+Pj4gIlRTDQo+Pj4+Pj4+Pj4+Pj4+IE51bWJlciIpIHRvIG9jY3VweSB0aGUgcmVzZXJ2 ZWQgZmllbGQgZXZlbiB0aG91Z2gNCj4+Pj4+IHRoYXQgSSBwcmVmZXINCj4+Pj4+Pj4+Pj4+Pj4g dGhlICBvcmlnaW5hbCBhcHByb2FjaCAoaWUuLCB1c2UgImJpdCByYXRlImZpZWxkIHRvIGNhcnJ5 ICJOIikuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBBcmUgeW91IHByb3Bvc2luZyBkcm9w cGluZyBjYXJyeWluZyBiaXQgcmF0ZXMNCj4+Pj4+IHJlcHJlc2VudGVkIGFzIGFuDQo+Pj4+Pj4+ Pj4+Pj4gSUVFRSAgZmxvYXRpbmcgcG9pbnQgYW5kIGp1c3QgY2FycnlpbmcgTiBmb3IgT0RVZmxl eD8NCj4+Pj4+IFRoaXMgc2VlbXMNCj4+Pj4+Pj4+Pj4+PiB3b3JrYWJsZSAgdG8gIG1lLCBidXQg d2Ugc2hvdWxkIGVuc3VyZSB0aGF0IHRoZXJlIGFyZSBubyANCj4+Pj4+Pj4+Pj4+PiBzaWduaWZp Y2FudCBvYmplY3Rpb25zLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFtGYXRhaV0gVGhlcmUg YXJlIHR3byB1c2FnZXMgZm9yICIgQml0X1JhdGUgIiBmaWVsZCBhcw0KPj4+Pj4gZGVzY3JpYmVk DQo+Pj4+Pj4+Pj4+PiBpbiB0aGUgbGluZXMgMjg3LTMxMC4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+PiAoMSkgICAgRm9yIE9EVWZsZXgoQ0JSKSwgdGhlIEJpdF9SYXRlIGZpZWxkIGluZGljYXRl cw0KPj4+Pj4gdGhlIG5vbWluYWwNCj4+Pj4+Pj4+Pj4+IGJpdA0KPj4+Pj4+Pj4+Pj4gcmF0ZSBv ZiBPRFVmbGV4KENCUikgZXhwcmVzc2VkIGluIGJ5dGVzIHBlciBzZWNvbmQsDQo+Pj4+PiBlbmNv ZGVkIGFzIGENCj4+Pj4+Pj4+Pj4+IDMyLWJpdCAgSUVFRSBzaW5nbGUgcHJlY2lzaW9uIGZsb2F0 aW5nLXBvaW50IG51bWJlci4gRm9yIA0KPj4+Pj4+Pj4+Pj4gdGhpcyBjYXNlLCB3ZSBNVVNUICB1 c2UgIDMyLWJpdCBJRUVFIGZsb2F0aW5nIHBvaW50IGluc3RlYWQgDQo+Pj4+Pj4+Pj4+PiBvZiAi TiIoUGxlYXNlIHNlZSBtb3JlIGluIHNlY3Rpb24gIDUuMSkuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IEkgZ3Vlc3MgeW91IHJlYWxseSBzdGlsbCBuZWVkICh0byBiZSBiYXNlZCBvbikgdGhlIGNs aWVudCANCj4+Pj4+Pj4+Pj4gc2lnbmFsIHJhdGUgYXQgdGhlIGVkZ2VzLg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ICgyKSAgICBGb3IgT0RVZmxleChHRlApLCB3ZSBjYW4g Y2hhbmdlIHRoZSB0ZXh0ICh0aGUNCj4+Pj4+IGxpbmVzIGZyb20gMzA1DQo+Pj4+Pj4+Pj4+PiB0 bw0KPj4+Pj4+Pj4+Pj4gMzEwKSBiYXNlZCBvbiB5b3VyIHN1Z2dlc3Rpb24sIGllLiwgdGhlIEJp dF9SYXRlIGZpZWxkDQo+Pj4+PiBpcyB1c2VkIHRvDQo+Pj4+Pj4+Pj4+PiBjYXJyeSAgIk4idG8g aW5kaWNhdGUgdGhlIG5vbWluYWwgYml0IHJhdGUgb2YgdGhlICBPRFVmbGV4KEdGUCkuDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IGJ1dCB5b3UncmUgc2F5cyBlbmNvZGVkIGFzIChOKk5vbWluYWwg UmF0ZSkgcmlnaHQ/ICBXYXQncyB0aGUgDQo+Pj4+Pj4+Pj4+IHZhbHVlIG9mICB0aGlzIHZzIGp1 c3QgY2FycnlpbmcgTj8NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+PiBUaGVyZWZvcmUsIEkgYW0gcHJvcG9zaW5nIHVzaW5nIG9uZSBzaW5nbGUgZmlsZWQg KCJCaXRfUmF0ZQ0KPj4+Pj4+Pj4+Pj4gIikgZm9yIHRoZXNlIHR3byBjYXNlcywgaW4gdGhpcyB3 YXksIHdlIGNhbiBsZWF2ZSB0aGUgIlJlc2VydmVkIg0KPj4+Pj4+Pj4+Pj4gYml0cyBmb3IgZnV0 dXJlLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBiaXRzIGluIHRoZSBjb250cm9sIHBsYW5lIGFy ZSBnZW5lcmFsbHkgY2hlYXAsIElNTyBpdCdzDQo+Pj4+PiBiZXR0ZXIgdG8NCj4+Pj4+Pj4+Pj4g aGF2ZSAgc2ltcGxlciBlbmNvZGluZyB0aGFuIHRvIG9wdGltaXplIGV2ZXJ5IGJpdCAob3IgOCBp biANCj4+Pj4+Pj4+Pj4gdGhpcyBjYXNlKS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gTG91DQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gSG9wZSB3ZSBhcmUgbm93IGF0IHRo ZSBzYW1lIHBhZ2UuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEJlc3Qg UmVnYXJkcw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEZhdGFpDQo+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+ IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NjYW1wDQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+Pj4+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBDQ0FN UEBpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+PiBDQ0FNUEBpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+DQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gQ0NBTVAg bWFpbGluZyBsaXN0DQo+PiBDQ0FNUEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpD Q0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cA0K